The increasing integration ability of the Internet of Everything plus the advancement of Machine Learning (ML) and Artificial Intelligence (AI) are making Industry 4.0 close to a reality. Though there is not a set definition for Industry 4.0, it can be understood by looking at some of the “smart” use cases of a manufacturing plant:
- Auto re-adjust quality parameters of the production line for the particular batch of the products in real time, especially valid for high value customers.
- Auto re-prioritization of the order for processing at the plant depending on availability of raw materials – especially valid for high value customers. Initiate a supply chain workflow at the edge which asynchronously propagates to the cloud as per workflow orchestration.
- Train product quality control signals in the cloud using data from all the plants combined with business context in the cloud, and then infer the ML at the edge in real time to automate quality control.
Implementation of the above use cases is not possible in traditional manufacturing plants. The objectives of Industry 4.0 (also known as “smart manufacturing”) are to increase productivity, improve product quality, immediate response to the customer demand, ensure worker safety, and so on.
Third generation factories already have condition monitoring and fault diagnostics. Smart manufacturing adds self-analytics and predictive capabilities to self-automate the operation as well as provide insights to management with nearly zero down time.
Edge Computing with IoT Data
Manufacturing plants produce huge amounts of machine data. The IoT data itself does not have any meaning. It needs context – for example, which asset it belongs to, what order it should be executed in, and which operational and quality thresholds are required. Many times, business context is stored in the cloud or data center whereas operational and quality thresholds may be stored at the manufacturing site.
Edge computing is about bringing the computation closer to the data, i.e., running computation at the plant. Edge computing ingests IoT data at the plant, pre-processes it, co-relates the data using business context of that particular plant, and provides insight in real time so that action can be taken within milli-seconds. So, the edge not only needs to crunch analytics in real time to automate the manufacturing processes, but it also needs to bring business context from the cloud to the edge so that processing can be done in a low latency environment while plant operations can continue to run even with intermittent connectivity to the cloud.
Cloud – why it is important?
Companies are putting their business applications in the cloud. This is the heart of the business operations which controls all plants customers’ orders, inventory, purchase, supply chain, and other operations irrespective of manufacturing plants. This is where aggregated IoT data are gathered from all the plants. Using business context and IoT data, it is possible to analyze patterns, trigger business workflows or train ML models for better predictions. Having this type of rich data sets help companies to innovate and expand into the new markets. In addition, the cloud can be used as a repository of IoT data for quality and audit purposes.
Moreover, the cloud provides the single-entry point of creation, management, and deployment of application configurations for the cloud and the edge. So, the edge without the cloud will not provide a complete solution for smart manufacturing. As described in the use cases above, to derive business values the computation must cross the edge and cloud boundaries.
Edge-Cloud Interoperability – Technical Challenges
Conceptually, edge-cloud interoperability means that a “Job” or “Application” can run either in the edge or in the cloud or in both. In the manufacturing landscape where IoT data are sent using many different protocols (including proprietary) and computing resources are finite, it is hard to make the cloud and the edge part of one Serverless (or Function as a Service) computation unit. Moreover, the concept in edge-cloud interoperability is more of an orchestration of computation optimization closer to the data rather than hardware agnostic.
One major hurdle to achieve interoperability is the need of a common data model across the edge to the cloud. Many times, due to the use of discrete software services in the overall end-to-end solution, it is hard to find a common data model. Another big challenge is to bring business context from the cloud to the edge so that the edge can run independently even with an intermittent connection. This is because it needs to understand the internal workings of the business applications.
At a high level, the architectural considerations for edge-cloud interoperability can be described as follows:
1. Extended Infrastructure
A cloud application landscape must be aware of the edge and vice versa. For users, cloud applications are just one instance of the application even if it could be running in infinite compute and storage. Whereas, every “edge” runs independently and is visible to its users. An edge usually has its own business workflow and is limited to its specific needs. Similarly, all edges look for the cloud to provide the data storage, run complex business workflows, train the ML/AI models, and facilitate other similar types of operations.
The cloud emphasizes the completeness of the business workflow whereas the edge emphasizes the real time operations. Some level of interoperability between the run-time services of the cloud and the edge is expected for an interoperable “Job” to run. Above all, it is very important for the cloud and the edge to continue to synchronize even if there is intermittent connectivity.
Manageability of edge compute and “Jobs” across the edge landscape may bring huge challenges especially when state of the computation and business data fabric needs to be maintained across the landscape.
2. Asset and Data Model
In manufacturing, often machineries are digitized using an asset data model. Assets are modelled in a hierarchy. This means a machine can have multiple parts, a part can have multiple sub parts, and so on. Any asset in this hierarchy may have sensor(s) and sends data about the part(s).
Data model refers to how IoT data are interpreted or serialized across the edge and the cloud. Various machines send different types of data along with sensor IDs. So, when an edge processor receives the data from a sensor, it needs to pre-preprocess the data and corelate them with asset data so that business context can be derived.
3. Job Orchestration
This is the heart of edge-cloud interoperability. It involves defining where a “Job” runs, what extended capabilities are needed for a “Job” to run, how to determine whether a message has already been processed by an edge, how a business workflow at the edge synchronizes with business workflow in the cloud, and so on.
Here I have attempted to look into the edge-cloud interoperability and its technical challenges. At SAP, our strategy is to hide most of the infrastructure complexity and let users to configure a cloud business application or service to run either in the cloud or edge.