More and more government regulations are currently being issued in relation to electronic devices. The aim is always to protect the consumer and ensure the usability of the devices. A brief overview of what has just been passed around the world:
And then there are special regulations regarding data security for IoT devices. Probably the best known here in Europe are
RED = Radio Equipment Directive; active since 2014, newly specified with regard to cyber security and data protection. Nothing definitive published yet, but will move in the direction of IEC 62443 or ETSI EN 303645.
CRA - Cyber Resilience Act - is primarily aimed at critical infrastructure and industrial control systems (ICS). Data must be secure (crypto), encryption where necessary and data must be private (protected).
NIS-2 - Affected economic sectors have been divided into three categories in the previous draft bill of the Act on the Implementation of the NIS-2 Directive and the Regulation of Essential Principles of Information Security Management in the Federal Administration (NIS-2 Implementation and Cybersecurity Strengthening Act or NIS2UmsuCG).
To put it simply, it can be said that the aforementioned regulations (plus others not listed here) will mean that products with software must have mandatory patch management (i.e. updates). And this must comply with a number of demanding boundary conditions - the patches must be made available within a tight time frame (at the time the vulnerability becomes known). And the vulnerability checks must be carried out continuously. It is also specified that decommissioning (more or less the deletion of all data) must take place at the end of the device's life.
However, these requirements have further consequences. Before we discuss these, let's take a brief look at an interesting development in the controller market - the fact that more and more controller providers are offering an open platform (or ecosystem, as they also call it).
Platform
In principle, all of these providers use the open Linux system and utilize the open interfaces to be able to run third-party applications in parallel with the actual controller. Technically speaking, these are mostly container systems. If you take a closer look, a few questions arise.
- On which device are the 3rd party apps executed? On the actual control unit or do they need an additional edge solution to be installed?
- Do the containers run on an open system, for example a runtime according to the OCI (Open Container Initiative) interface, or are proprietary systems (e.g. Snap) used?
- How are the different apps scheduled? Do you use the integrated features of the OS or do you use "tools" such as Excel tables?
- How is the load balanced between the real-time tasks and the other apps?
- Most of the Linuxes used here are created with Yocto. However, according to its own statement, Yocto is not a distribution, rather a tool for building a distro. Will the controller manufacturers now all become Linux distributors and take care of the maintenance of Linux?
I won't go into detail about the manufacturers' solutions here. That could be the case in another article. Back to the requirements of the legislative body - I have already pointed out that security patches must be made available on an ongoing basis. The CRA is still merciful with its 5 years in which updates must be provided. The reality in companies is different, where devices are used for 10 years or more. And this period must also be covered.
The CRA's documentation obligation will further increase the need for a well-maintained SBOM (Software Bill of Materials). And this must also be maintained over the entire service life.
The requirements of NIS-2 for mechanical engineering also affect the supply chain of the companies concerned, i.e. the suppliers of control systems, sensors, etc. And the Machinery Directive goes one step further, requiring proof that the machines are protected against manipulation. This definitely has an impact on the design of the devices, but also on how security is handled. From now on, this is no longer just an option, but a must.
Maintenance
And the patches are only a small part of the task. Roll-out management, for example, will be an exciting area, because the infrastructure must be in place. And then there are issues such as secure boot, on-boarding the devices, not to mention updating the apps (container). For security reasons, it must be ensured that only the devices that are known receive an update. The update must only come from reliable sources. Devices that are only sporadically connected to the network must also be able to receive an update. And in an emergency, it should be possible to install the update from another source, for example an USB stick. The maintenance of the Linux (update!) must also be answered. Continuous maintenance is a must here. All of this is a non-trivial task.
Overall, this raises the question of whether you want to enter into a new dependency relationship. In other words, replacing the previous OS supplier with the supplier of the control platform. And thus (possibly) giving away the advantages of open source.
Or whether it wouldn't be better to use vanilla Linux directly and thus keep your finger on the pulse of development (of Linux). Then you are sure to receive all updates and security patches.
Immutable System
The buzzword "immutable system" is currently on everyone's lips, especially in the IT world. This refers to a lightweight system whose components and configuration cannot be changed. Technically speaking, it is a "read only" system. Incidentally, this is an approach that has always been common in the OT sector. The systems are therefore very stable, their behavior is known and they are very secure against attacks.
Updates and changes are imported as a new instance of the OS in the form of an image as an atomic operation. The previous version often remains on the device as an emergency level in case the import does not work. This also applies if the update had been installed as a so-called delta update (which is often done to reduce the volume of data to be transferred).
Our Industrial Grade Linux (IGL) is such an immutable Linux OS. Everything that is needed is on board, but no more. And the applications can be executed either on the OS or in the form of containers. Of course, we stand for maximum openness, which means that we support the open OCI standard (and therefore also allow the use of Docker containers).
Workload
IT and OT world together? On one system? Yes, this works if the operating system used is real-time capable. And the right configuration is used to ensure that the OT part requiring real-time capabilities always has sufficient computing time. This is possible with Linux on-board resources. Therefore, nothing stands in the way of the parallel use of IT applications and OT control software on modern SoCs.
Workload Distribution
In the IT world, it has been standard practice for a long time to roll out applications (micro services) with suitable tools such as Kubernetes. Is this also possible on controllers in the embedded world? With real-time requirements? Yes, it is possible. However, minimum hardware requirements must be met. For example, the K8s process needs its own core. And then there are the cores for the real-time process(es) plus the cores for the micro services. See also our earlier blog on containers.
And what about other issues from the IT world such as load balancing or redundancy? This is also conceivable, provided the hardware and software requirements are in place. And if the determinisms for the real-time tasks can be guaranteed. Ask for further information and discussion.
Hardware separation
Another important question is the separation of tasks on the controller. Is it sufficient to work with containers, as is the case in IT, or is it not better to work with a hypervisor? The use of a hypervisor significantly increases security in the context of data integrity 
and separation of tasks. It also enables the use of additional, optimized software (keyword: bare metal or RTOS for MCUs) if necessary. If you use a hypervisor optimized for real-time tasks (i.e. for control) such as jailhouse, you have even more options. And since jailhouse is hardware agnostic, the platform can easily be swapped out as well.
This approach can also be used to implement the "Software Defined Manufacturing" idea. Here, the control system is viewed as IaaS (Industrial Control as a Service). Together with the real-time Ethernet technology TSN, old paradigms can be dissolved. The advantages for customers are independence from hardware, lower installation costs, simple scalability and the ability to use modern software technologies for the development and distribution of control software.
In other words, the automation pyramid will be replaced by a networked solution. The opening of a new world.
