Your questions answered: IIoT/Cloud series, Part 2: Edge, Fog and Cloud
In the parlance of industrial automation, “the edge” has emerged as a term of considerable currency. The edge is found where the action is, at or near the industrial process.
To relieve bandwidth constraints or inherent latencies, and to improve system security and reliability, computational resources – from gateways to multi-purpose devices to computers -are being stationed at the edge. These computational resources located at the edge can filter or process data so that only what’s needed is transmitted between production control or enterprise systems and the cloud.
Participating in the webinar were Charles (Chuck) C. Byers, associate CTO, Industrial Internet Consortium (IIC), a CFE Media content partner; Ed Kuzemchak, CTO and director of IoT, Software Design Solutions Inc.; and Steve Hilton, cofounder and president, MachNation. Kevin Parker, editor for IIoT for Engineers, served as moderator.
The webinar in its entirety can be viewed on the Control Engineering website. Some attendee questions asked during the webinar included the following.
1. Please discuss some specific differences between edge, fog and cloud. Are edge and fog the same?
Chuck Byers: Edge and fog are very similar technologies. Edge is often a single (or few) layers serving gateway functions for a limited set of IoT applications, while fog tends to be more hierarchal and supports multiple tenants. Fog tends to have slightly stronger security and orchestration. Edge is a more common term in the industry, so IIC is migrating to using edge for the superset of edge and fog.
Steve Hilton: We generally use the phrase “distributed architecture” to capture the concept that data ingestion and process can happen at different points in the IoT architecture.
Ed Kuzemchak: Some practitioners use ‘edge’ to describe the actual sensors and ‘fog’ to denote one layer of processing above that. But that distinction is getting less clear, so I support the IIC’s move to using Edge for both.
2. What are the most important IIoT-related protocols?
Byers: There are lots. Certainly, IP at the network layer is predominant. At the Transport layer, TCP, UDP, HTTP, CoAP, MQTT, OPC-UA are common. There are also frameworks like web services, OPC-UA, OneM2M and DDS used to interconnect system components.
3. Are users actually applying edge, fog and cloud applications?
Byers: Yes. There are many working edge systems in multiple vertical markets. Edge computing is already in volume deployment in smart grids, smart cities, intelligent transportation systems, healthcare, manufacturing, consumer and many other applications.
Hilton: In fact, we find it uncommon that an IIoT solution is only cloud or only edge. Most deployments make some use of both edge and cloud. This gives enterprises the flexible deployments and cost efficiencies.
Kuzemchak: Many legacy industrial control systems had some kind of edge/fog/cloud architecture even before IoT was named. Classic M2M systems are being recast as IIoT systems to take advantage of the common protocols and interoperability that Chuck mentions above.
4. In the Industrial Internet Consortium (IIC) architecture, what is the difference between security and privacy? How does that matter to an edge/fog device design?
Byers: There are differences. Security is often about preventing bad actors from taking unauthorized actions to influence the behavior of an IoT system. This means unauthorized users must be prevented from seeing internal states or controlling system configurations. It is highly concerned with making systems as hacker-proof as we can.
Privacy is more about the data flowing in networks than the networks themselves. Privacy software prevents data in motion or data at rest in IIoT systems from being read by unauthorized parties. This is especially important to conform to government privacy regulations like GDPR or HIPAA.
Hilton: For MachNation, security is primarily a technology-related issue. Privacy is an issue that is created by individual, societal and governmental expectations that can be solved by technology and other factors.
Kuzemchak: The application domain may determine that privacy is not a requirement in their system, but it is unlikely that any system can make the claim that security is not a requirement.
5. With edge and fog can we reduce our dependence on the cloud in the future?
Byers: Partially. As more critical compute, networking and storage functions move closer to the edge, we may be less reliant on cloud capacity, performance or reliability to provide them. Certain operations may be much more efficient or cheaper if run at the edge.
However, we will never eliminate the role of the cloud from IoT networks. There will always be a need for a highly scalable, elastic, overarching compute and storage infrastructure to perform the highest level of IIoT tasks.
Hilton: Enterprises should always start the IoT discussion by determining their business-related goals requirements. From the business goals, an enterprise can determine their IIoT architecture and technology requirements. By following this approach, we ensure that the right technology – whether edge, fog, or cloud — is used to meet the ultimate business goal.
Kuzemchak: It is all in the tradeoff of where the best place to do the processing lies, about gathering the necessary data, having the compute power available and utilizing the results.
6. Since there is so much software-related complexity in edge & fog, are a lot of home-grown applications being developed by users?
Byers: Yes, end users of edge systems often are the best experts on the systems they are controlling. This gives them the best perspectives on the data, control algorithms, and procedures needed to control the system. However, end users may not be as skilled on software development processes, or the edge-cloud infrastructures, so it often makes sense to collaborate with specialized IIoT programming help.
Hilton: In most cases, the ultimate IIoT application is either home-grown or developed by a services company for the enterprise. While there are IIoT platform vendors that supply sample IIoT applications, it is fairly uncommon that enterprises will use those applications as-is. Keep in mind that application development is not necessarily the most complex part of IIoT platform implementation. Often it is the integrations to legacy systems that provide the greatest development challenge. Most IIoT solutions are deployed in brownfield environments. As such, most enterprises require some fairly extensive southbound and northbound integrations.
Kuzemchak: At SDS, we see a lot of custom applications being built, but using the standard communications protocols, message brokers, and data analytics packages. But bringing them together to solve a specific need often requires a custom design.
7. What is the possibility of utilizing the sinoatrial node found in the human body that creates the body’s electricity, for tie-in to the IIoT network?
Byers: As a signal source, it is already in use. A device called an implantable cardioverter defibrillator (ICD) monitors the SA node and other electrical activity in the heart (sensing) and can provide a pacemaker pulse or a larger shock (actuation) if abnormal rhythms are detected. Sophisticated ICDs connect to your cell phone and thence to the Internet for continuous control and monitoring.
In terms of energy harvesting, the raw energy available from heart electrical activity is small, and I think many safer alternatives exist to harvest energy from within the body. Systems can take advantage of mechanical motions, pressure changes and respiration to make meaningful amounts of power, capable of running sophisticated compute and networking capabilities without ever having to implant a high capacity battery.
Kuzemchak: Agreed. You have a much better chance of collecting body heat or movement.