The implementation of Industry 4.0 continues to focus on the linking of industrial production to the internet and the Cloud, and this has transformed the Internet of Things (IoT) into the ‘Industrial Internet of Things (IIoT’), according to Gavin Stoppel.
The revolutionary approach of Industry 4.0 should not be a one-time fundamental change, but rather an openness of industry to permanent change.
Connecting to the internet boosts the functionality and performance of an industrial plant and its machinery, enabling seamless integration in the form of digital, value-added networks. Within this, edge devices play a key role as they are used directly in the production module in the area of plant and machinery.
Edge devices are tasked with lifecycle services such as predictive maintenance, performance management, asset tracking or spare part management. However, they can also be used more generally to enable process optimisation through Cloud-based services. The key factors here are the open interfaces of the edge devices, along with extensive standardisation of the integration. Intelligent systems can be used uniformly by different software systems, as well as being seamlessly integrated into the manufacturing environment.
It is fair to say that IT edge devices are good all-rounders as they can be used universally for all services. However, there is one exception to this rule – automation. On the face of it, this appears to be a contradiction, since Industry 4.0 is often seen as being the use of technology to power all functions within the industrial sector. Also, converged Ethernet networks have been implemented for several years. A decisive step in this is TSN (Time Sensitive Networks), which allow the Ethernet network to be universally integrated into real-time areas. So why shouldn’t the IT edge device be used universally, including automation? Or why shouldn’t the programmable logic controller (PLC) also be used universally as an IT edge device?
As a rule, the basic control structure with the deployed control system remains unchanged over many years, something which is necessary not least in light of safety aspects. It is unusual for a completely new PLC to be installed during the life cycle to increase performance. This is usually only customary after several years, in the course of refurbishment.
By contrast, the installation of an IT edge device usually constitutes an expandable platform which is constantly adapted and built out during the life cycle of a machine via the use of additional services. Software updates in short intervals are also common here. However, no new commissioning of the machine takes place, since safety-relevant aspects are not affected. The software used also meets the necessary standards in the IT environment. OPC UA constitutes an intersection in communication with industrial devices, even if signs are already on the horizon that this communication standard is not the only one that will be used by IT in the industrial environment. IIoT standards such as MQTT are also finding in-roads here.
Consequently, the IT edge device turns out to be completely built and operated according to IT paradigms. Most of all, it is not rigid or unchanged in the life cycle of a machine or plant. It will continuously evolve with lifecycles far below those of automation devices. This is necessary to keep up with IT. But that would mean that even a PLC – an intelligent drive in a machine – will be replaced within five years so it can be up to date with the latest IT standards. This is neither economically viable nor technically feasible.
The decoupling of IT edge devices and automation devices provides further advantages in plant operation.
If the production process is to be optimised by new services, access to the automation devices is necessary. This requires suitable interfaces, including a semantic description of the devices. Creating these is going to be one of the foremost future requirements because in most of today’s applications, the automation device and the edge device operate completely separately, mostly with their own, dedicated sensors.
This is not an ideal solution, as both devices have their valid advantages. But their use is not only based on co-existence; their cooperation is crucial. Otherwise, it comes down to a fight that only an edge device with integrated automation control – meaning an all-rounder – can win. But these jack-of-all-trades solutions have already proven, more often than not, to be lame ducks. Therefore the preference remains for reliance on fast edge devices, which provide the requisite ability for the system or machine to learn over its entire life cycle.
In addition, implementing IIoT at an organisational level adds new network and operational security challenges to a computing environment, by introducing network and cloud connectivity at the shop floor level. Unfortunately, unlike IT networks which can look back on 25 years of security there are significant challenges with very few specific instructions how to implement IIoT securely at the device, network and system levels.
With the MICA from HARTING, thought has already been given into how it can be securely integrated into manufacturing and production environments. MICA (Modular Industry Computing Architecture) is an open-source, edge computing device which can be customised with custom hardware, software and interfaces to suit individual requirements. As a result, it provides a quick and easy solution to implement digitisation projects directly at facilities and machines.
The key to securely rolling out IIoT is taking a thorough look at the environment and identifying and mitigating potential threat vectors. A useful way of tackling this is to identify thread boundaries, usually contact or handoff points between different systems, and securing them and zones between the boundaries. In the case of IIoT, you can identify the threat zones as being between the machine and MICA and the backend, e.g. the Cloud, and between the backend and remote users.
The backend area is usually the normal corporate network, public internet or private and public clouds. Security in this zone is covered by standard IT security practices. You should consider how best to secure the data coming from and going to the MICA. Examples of possible solutions include firewalls, traffic monitors, and in some cases, even intrusive methods such as deep packet inspection (DPI). Conversely, you may also want to tunnel data from the MICA through portions of the backend zone using techniques such as virtual private networks, SSH tunnels or other forms of encryption.
