Modern control systems, and more generally cyber-physical systems, must address many challenges originating from the ever increasing complexity and diversity of the functionalities to be implemented and from the technological advancement of the hardware.

A good example is the automotive industry: the almost romantic mechanical car has evolved into the software-defined vehicle where electronic control systems are used for the most diverse purposes, from engine control to infotainment, from driving assistance to air conditioning, from connected automatic driving to accidents prevention.

The above mentioned challenges call for an adequate operating system, and Linux seems to tick all the boxes:

• its open-source nature offers a rapid evolution cycle, continuous maintenance, and quick bug-fixing, while at the same me eliminating development costs, without any vendor lock-in
• its hardware support already covers the greatest majority of applications
• its security features provide protection against malicious attacks, especially for interconnected and always-on embedded devices
• its scalability allows to select only the features or functionalities (“packages”) actually required for the specific needs of the intended application
• its extremely broad use in the most diverse and demanding contexts provides an absolutely non-episodical evidence of its reliability
• skilled and experienced developers are available on the market.

Unfortunately, at least until yesterday, Linux did not tick the most critical box: safety.

Whether it is machinery, railway signalling, automotive, biomedical (but also home appliances) any domain is subject to the prescriptions of standards, norms, regulations, and also laws, with which Linux did not comply. The attempts made or being made to address this issue share a common approach that can be summarised as one or the other of the many flavours of “reverse engineering”.

The common idea behind these attempts, although with different levels of sophistication, is to demonstrate by analysis and testing that Linux “does what it says on the tin”, with the added difficulty that Linux does not have any “ tin” where to read its intended functionalities, meaning that the design information is sparse and does not guarantee its completeness and correctness.

Such an approach is labour-intensive and time-consuming: just to name the most obvious issue, the almost infinite number of internal states of Linux requires an extremely extensive testing activity and an even more extensive analysis to demonstrate that such a testing activity is sufficiently exhaustive.

Even assuming that such an approach is successful, it would need to be repeated each time an update to Linux is issued, which happens quite frequently (and which is one of the advantages of Linux, as stated above); it is true that an appropriate impact analysis could reduce the effort required, but even such an impact analysis would take time and would be expensive.

This presentation shows a completely different approach where the “burden of the proof” is shifted from Linux to a “supervision software layer” detecting when Linux does not behave dependably.

In other words, rather than trying to demonstrate that Linux is dependable, the choice has been to detect when it isn’t.

The solution implemented leverages upon the features offered by advanced hardware (whether it is a microprocessor or a system on chip) to supervise the behaviour of Linux, namely its access to memory and processing resources.

Two main software elements implement this solution:

• a hypervisor provides Linux with virtualised memory and computation resources, hence the hypervisor has full control over the access to those resources by Linux
• a supervisor software analyses any attempt made by Linux to access memory or computation resources and detects when such an attempt is able to adversely affect the dependability of the safety function (in the acception given by EN 61508).

The most immediate advantage of this solution is that the dependability of the safety function performed by a cyber-physical system does not rely on Linux itself, but on the above-mentioned two software elements, while at the same time it allows to exploit all the features and advantages of Linux.

As a consequence, the effort required to build the safety argument and the related supporting evidence is reduced, because only the two above-mentioned software elements are directly involved, but also the update to a new version of Linux requires only a moderate effort and, above all, even if performed incorrectly it would not affect the safety but only the reliability.

Another remarkable advantage of this solution is that it allows to execute both safety-related (supervised) and non-safety-related (unsupervised) applications at the same time on the same Linux; the non-safety-related application is like any other application running on Linux and is not affected or functionally limited by the presence of the safety-related application.

However, the use of open source software brings the additional challenge of having to access different repositories to gather all the source code or binary files required, add the application software, and then compile and link them all to build a usable digital image, and all that while the dependability of the final product must be ensured through entire process.

For this purpose, this solution includes a software development kit that greatly streamlines and simplifies the entire process so that the user is freed from the effort of defining and implementing their own application engineering process coping with sparse and abstruse repositories.

In addition, the software development kit also provides features and functionalities supporting the development and testing of the application software, which further reduces the effort required to the user.

In summary, this is a complete and readily usable solution: it includes both the product itself and the application engineering tools.

This solution has proven successful: a minimum viable product (which can be considered a technological demonstrator) has been built and is functional while an independent assessor has confirmed not only the dependability of the softare, but also that a cyber-physical system implemented using this solution is able to:

• perform safety functions up to SIL2 according to EN 61508
• fulfil safety requirements up to ASILB according to ISO 26262.

This makes this solution suitable for almost any regulated industry, including automotive; a fully-featured version is currently being developed.

Although the independent assessment has been performed for SIL2/ASILB, this solution offers features and functionalities that can be exploited to implement the most appropriate fault detection and mitigation techniques achieving even higher levels of integrity.

Co-authors: 

• Muhammad Aqib Javaid Butt, Elektrobit Automotive GmbH
• Ulrich Kirchmaier, Elektrobit Automotive GmbH
• Michael Armbsruster, emlix GmbH
• Michel von Czettritz und Neuhaus, emlix GmbH
• Rainer Müller, emlix GmbH

Short Bio

Federico Arrighetti (Italian)

Working in dependability since year 2000:

• in Railways Command, Control and Signalling systems until 2022
• in automotive from 2022

2022 at Elektrobit Automotive (Munich - Germany) • Dependability expert for the SIL2 Linux solution EbcLfSA by

2018 at CT Software Engineering (formerly AST Engineering - Munich - Germany) • Consultant at Knorr-Bremse for the safety assessment of train braking systems

2016 at Parsons Group International Limited (Copenhagen - Denmark) • Consultant at Banedanmark (Danish Railway Company) for the safety activities related to the installation of ERTMS Level 2 on the entire Danish railway network

2011 at Alstom Transport UK (formerly Signalling Solutions) - Radlett (United Kingdom) • Product Manager for the introduction on the UK market of the object controller “Smart I/O”

2007 at Invensys Rail (formerly Westinghouse Rail Systems - Chippenham - United Kingdom) • Responsible for the safety assurance of the “DTG-R” system (Distance To Go-Radio) an Automatic Train Control system with automatic drive abilities

2006 at Sciro - (Rome - Italy) • Responsible for the Independent Safety Assessment activities of safety-critical railway signalling systems according to CENELEC norms

2004 at Mer Mec (Monopoli - Bari - Italy) • Verification & Validation and Safety Manager for the trackside subsystem of the Italian signalling system “SCMT” (similar to ERTMS Level 1)

2000 at Intecs (Pisa - Italy) • Consultant in various projects

• dependability activities for the radio remote control system “Locomote” by Åkerströms Björbo (Björbo - Sweden)
• support to the Italian subsidiary of Alstom Transport for the dependability of projects related to the Italian signalling system “SCMT” (similar to ERTMS Level 1) and ERTMS Level 2
• dependability activities for the “DBCA/CCS” (axle counter) developed by Ducati Sistemi (Casalecchio di Reno - Bologna - Italy)
• test engineer for the “Microlok II” by Union Switch & Signal used in the driverless unattended Copenhagen metro

Thursday, September 25, 3.00 PM