28 Apr A Guide to Data Analytics For Manufacturing – Working at the Edge
This is the third in a series of blog posts on Data Platforms for Manufacturing. Throughout this series, I will try to explain my own learning process and how we are applying these technologies in an integrated offering at Critical Manufacturing.
For reasons that I started exploring in the first post of this series, many companies seem to be strategically lost among the various digitization initiatives and experiencing severe difficulties in achieving results from the investments made, particularly in the topic of Data Analytics and IoT.
Contrary to what happened in the previous industrial revolutions, manufacturing has lagged in implementing the base technologies underlying this data transformation. Significant amounts of generated data are being stored with no immediate plans for being used: this is dark data.
With today’s post, we’re getting closer to main elements of the data platform, but need to discuss one last element outside of it: Edge solutions.
Working at the Edge
One of the most important challenges of a Data Platform happens even before the data reaches the platform. In a pure centralized solution, the data must be sent from a device to a server to be processed, with the output eventually being pushed back to the device. With edge solutions, a portion of the processing happens close to where the data is being generated, creating a ‘hybrid’ solution.
While manufacturing increasingly relies on actionable insights and near real time data for decision making, it requires modern solutions that can rapidly generate and process huge amounts of data. Edge solutions are a critical element of the entire data platform (although “outside” of the platform itself), with the ability to perform a wide range of operations on the “edge” of a customer’s network, as near as possible to where the data is being generated.
These challenges are not unique for manufacturing, making Edge computing a fast growing market
Edge computing is extremely important for a number of reasons:
Latency – If the data is not processed near the point of origin and has to be sent to a distant server, whether cloud or on premises, the latency caused by the network between the device and the central processing can be significant and have consequences, particularly in cases where faster responses or decision making is required.
Cost – If data is generated at a very high rate, processing it at the edge reduces the costs of ingesting and analyzing large amounts of data, both in the network and in the processing layer.
Security – Security issues are also becoming a concern, particularly when sensitive data needs to be sent across the network, often with insecure communication, being the network-level security the main security concern when adopting IoT. If an edge computing device does not have built-in support for encrypted communications, retaining some level of data locally may be used to circumvent compliance or possible security breaches.
Debugging – Assessing the correctness of the operation of the IoT device is another very important element, because the consequences of a possible malfunction might create significant problems. Therefore, with software running at the edge, it is possible to minimize such effects.
Availability – In many IoT deployments, the network connection is not reliable. In these cases, edge solutions include storage options to hold data temporarily until a connection is restored.
Manufacturing is (usually) not a greenfield
The data platforms, and the edge solutions, within the context of manufacturing, particularly in discrete segments, will not be applied in a greenfield. While there can be cases of simple IoT devices that may be added to legacy equipment to collect some basic information, the majority of the data sets will be sent to the data platform by a locally existing process control solution, such as a PLC.
What this means is that an edge solution needs to be able to talk to whatever interface the controlling solution has. While in general OPC is an interoperability standard for the secure and reliable exchange of data in the industrial automation space, with OPC-UA being the most used, it is by no means ubiquitous. In fact, the number of interfaces specific to some manufacturing segments abound, such as SECS/GEM for the semiconductor industry, or IPC CFX for electronics assembly. To these we add then the more IoT-specific protocols such as MQTT, AMQP or BLE, and other older and less capable interfaces like TCP/IP, database or even file based. The edge solution has the responsibility to deal with all the complexity caused by the different interfaces and isolate those details from the higher processing layers.
Moreover, while some of above software run on industrial computers, PC’s or even servers, some of the IIoT solutions run in much simpler hardware platforms, such as in a Raspberry Pi.
The other aspect involved in manufacturing, which may differ significantly from other industries, is the fact that the software is also controlling the manufacturing processes and not simply collecting data for analysis. While there are several control loops possible, the wider software-based control loops involve interacting with other software solutions running at higher levels, such as the MES. This, known in some industries as software interlocking, requires a certain level of processing and workflow capabilities, which must also run at the edge.
Edge will decisively contribute to the IT and OT convergence
While IT and OT are still not widely known terms outside the analyst community, these can be easily explained.
IT stands for Information Technology and in this context consists of computing / processing systems such as Manufacturing Execution Systems or Operations Management (MES / MOM), Quality Management (QMS), Asset Management or Performance Management (EAM / APM), etc. that contain data such as jobs, resources, quality parameters, schedules, and materials.
OT consists of the hardware and software solution required for operating and monitoring production systems such as SCADA (Supervisory Control and Data Acquisition), DCS (Distributed Control Systems), and ICS (Industrial Control Systems).
IT and OT have been traditionally managed separately within different organizations and with different (sometimes even conflicting) objectives. Edge solutions contribute to the convergence of IT and OT onto common platforms and dataflows, allowing easier communication and actions.
Within this context, as will be explained in one of the later blog posts dealing with data science topics, one of the objectives of the data platform is to create robust Machine Learning models and algorithms, which can then be automated on the edge solutions, guaranteeing swift control actions upon every new data point collected. Manufacturers that can integrate OT/IT systems and teams are the ones that will succeed in seizing the transformation that all the generated data can bring.
The Necessary Characteristics of an Edge Solution
Given all the aspects mentioned before, there are three main characteristics that an Edge solution needs to consider
Given the variety of hardware types designed to operate next to the equipment or the IoT sensors, some with very basic resources, an edge solution must be very lightweight and low footprint and ideally, be a cross-platform solution.
Because the solution needs to connect to a variety of different integration protocols, it shall ideally separate the driver, responsible for the communication, from the controller, the software that collects, manages and orchestrates the data. Then, new drivers can be created and added to communicate with the new or more industry specific protocols.
As devices in manufacturing are not simply collecting sensor data and shall perform transformation, buffering, calling or receiving instruction from other software solutions, etc., these require edge solutions that are capable of running automation workflows. These shall ideally be re(configurable) and able to perform workflow debugging to detect possible malfunctions.
Given the amount of dispersed automation solutions across the shop-floor, and the interaction necessary with other systems, it must be possible to perform central management of such solutions, including monitoring, debugging, simulation and automatic deployment of drivers, controllers and master-data.
For all the above reasons, the existing software solutions, sometimes known in the industry as “Equipment Integration” applications, continue to be used. The older ones will likely have to be enhanced to cope with above requirements but shall not be replaced by simpler generic IoT-data-collection-only devices. These are likely to be the most important “data sources” for the Data Platforms, although, as we’ll see later, are by no-means the only ones required to derive true actionable insights. In the next post of this series, we’ll introduce you to the wonderful world of streaming analytics.
Should you want to continue reading this and other Industry 4.0 posts, subscribe here and receive notifications of new posts by email.