Sensing
When dumb sensors are not adequate, some intelligent processing at the sensor node or gateway may be required. A smart device will consider variations of a sensor’s dynamic range, filters, trigger threshold points and conditional AND/OR events that relate multiple sensor data together. Static configurations may not be sufficient to process all the scenarios that are presented within the manufacturing environment. The sensor node settings may need to change based on dynamic external operational events (Taranovich S.). Any adaptation to the sensor information should be planned within the IIoT architecture design phase. The spatial placement of sensors, both in absolute terms throughout the operation and relative to other sensors must be ascertained in advance of deployment.
algorithms and filtering
Although algorithms and data filtering could take place within the cloud, it often makes more sense to accomplish this activity earlier along the data ingestion pipeline within the gateway or sensor node if processing power is available (Grizhnevich A). For example, vibration sensing nodes located on machinery may change their filter response or decimation mode depending upon a change in activity on the machine. If the sampling rate of a temperature sensor is more frequent than needed, an averaging algorithm can be invoked to extend the dynamic range of the sensor at the expense of less frequent samples. These aspects of data requirements and sensor configurations should be well understood at the time of architecture design to embed any low-level algorithms at the sensor or gateway.
Data Communication
A smart device must include a communication plan for data to and from the sensor edge nodes, all the way to the cloud. Getting data from the edge sensor nodes and gateways into the cloud is paramount to the success of the smart IIoT system. While this communication could either be wireless or wired, the integrity of the data transmission must be maintained. While interpolation of missing data is possible, it is often not preferred. Therefore, a robust wireless link >99.99% is typically required in the presence of known RF interference. The architecture planning should account for any changes in the manufacturing environment that could inhibit this link integrity such as changes in significant metal structures, walls, and new equipment.
If an RF solution is simply not an option, a wired industrial ethernet connection may be a second choice. This will require the added hassle of additional cables. But it will remove any uncertainty of an RF communications link.
Cloud
The cloud is the final aggregation point where data fusion across all sensor nodes can take place. Broadly encompassing all ingestion points, the data can be parsed and analyzed across a single machine, a unique operational section, a full factory or across an entire enterprise. Large enterprises may have their own internal cloud platform that provides a proprietary advantage. Others can leverage open cloud platforms that provide sophisticated dashboards, analytics packages, mobile applications and support structures. As seen in FIGURE 1.
Part of the smart device design needs to plan the rate and quantify the amount of data that is sent to the cloud. If events are time critical within the operation for control feedback, then the transmission latency must be minimized to the cloud. (Saviant) A timing measurement analysis that simulates the time required for sensed data to reach the cloud analytics dashboard may be needed to understand the overall system latency. Similarly, any data with synchronous timing ambiguity across disparate sensing devices must also be planned.
Analytics
If the sensed behavior is known, such as a predictable mechanical failure or an inefficient operation, then a trained analytical model can be used against this known expectation of data. A more challenging analytics approach occurs when the expected behavior itself is unknown and the model must be formed from ongoing new data (Shi-Wan Lin). Artificial intelligence methods can ingest new data and re-train existing legacy models to adapt for new incoming information. This allows the data modelling to stay current as new changes obsolete prior observations or make them less relevant than more recent data.
Once the complete dataset can be obtained from the relevant sensor sources, a data model is employed to extract insights. The input to the model should be all the predictor information needed to answer our second fundamental design question from above. The output of the model should eventually be adequate to solve the problem identified in our first fundamental question.
Security
The security of the overall manufacturing IIoT must be included as a process within all steps of the architecture design. In order to be effective, the security of the system cannot be an afterthought of the design as a wrapper or password. Every step in the communication chain, for both hardware and software, has the potential for unauthorized access (Beavers, Maclean 2018). Therefore, a critical assessment of the security needs and risks should be embedded in each phase of the smart architecture planning.
After the smart architecture design planning is complete, the answers to the two fundamental IIoT questions should have a pathway to be realized. All the hardware, software and information generated by the IIoT deployment should be focused on solving the manufacturing problem(s) identified. With the end-goal in mind as the leading reason for the IIoT effort, the smart device design phase should not be open-ended, but have a targeted reason for deployment with clear data evidence to make informed decisions going forward.
WE ARE MAKING
THE UNKNOWN KNOWN
THROUGH ADVANCEMENTS IN DATA.
Results Engineering is an IIoT/Industry 4.0 systems integrator that has been working in plants for the last 30 years. Our role is to guide our clients on the path to IIoT implementations, achieving ultimate plant control.