OSADL SIL2LinuxMP successfully kicked off

By: Nicholas Mc Guire

Certification Data Package to facilitate SIL2 certification of GNU/Linux

What is the OSADL Safety Critical Linux Working Group?

The OSADL Safety Critical Linux Working Group was founded in 2007 with the intent to assess the suitability of mainline GNU/Linux for safety-related systems and develop the strategies necessary to the point where they can be moved to industrial projects. The main focus initially was put on IEC 61508 (and derivatives) as this is the main interest of the OSADL members. It also is seen as a worthwhile starting point to aid certification against safety standards in general.

The group is led by OSADL's Safety Coordinator Nicholas Mc Guire.

Is GNU/Linux certification ever feasible?

The use of FLOSS/SOUP/COTS SW components, notably components of a complexity of the Linux kernel, is highly contended in safety industry. Initial reports from the UK Health and Safety Executive (HSE) in 2001 found GNU/Linux (at that time kernel 2.4.20) potentially suitable for SIL1/2 and with large efforts SIL3 according to IEC 61508 (Ed1). Much of the findings in this report have been addressed in the FLOSS community in the past decade. These activities, however, were not primarily due to the use in safety-related systems but simply due to the enormous challenges that a project of the size and complexity that GNU/Linux, most notably the kernel, constitutes. If the Linux community had not systematically moved to rigorous processes, this whole project would have exploded a long time ago. Fortunately, these Linux development processes are – surprise, surprise – not very different from what certification standards require except that they were not applied a priori. Nevertheless, there are significant challenges to make Linux suitable for the use in safety-related systems – so why do it? The answer comes from a maybe not quite expected side:

• Security demands are entering main standards (IEC 61508 Ed2, EN 50159 Ed 2, etc.) and while GNU/Linux has a strong security track-record with mainstream distributions attaining EAL 4+, this is often not in scope of traditional safety related OS/RTOS.
• Industries in the safety domain want to have a more competitive market and thus favor open solution vs closed solutions (vendor lock-in problem).
• The advent of multicore systems is inevitable – many of the traditional RTOS for safety simply have no answer to this.
• Linux provides functionality that is of interest for the continuous integration of systems and that is starting to include integration of safety and non-safety components.
• Availability of engineering power – it's easier to find a Linux programmer than someone who is able to handle an exotic RTOS.
• Long term availability – with Open Source you don't get merely a binary or the right to access the sources – you get the technology from the concept, the design, the workflow and tools and much more.

This list is incomplete and specific domains will have other reasons – the offerings that GNU/Linux has for industrial applications is tremendous. At the same time, clearly, there is no "one-fits-all" OS/RTOS on this planet, and Linux will not and cannot satisfy all requirements (functional, security, safety etc.). At the OSADL Safety Critical Linux Working Group we first were confronted with the following questions:

• Where is GNU/Linux suitable for the use in safety related systems?
• What are the conditions, the constraints and the limitations?
• How to get it certified – what strategic options are there?
• And where GNU/Linux simply is not appropriate?

In order to get answers to these questions, our main activities in the past years have been to bring specialists together from all over the world and discuss topics such as:

• Basics - Introduction to Safety with a focus on FLOSS usage
• Safety case strategies
• Use of formal methods
• Supportive arguments for Linux

In doing so, we have established links with relevant industries, academic partners and certification bodies to get their feedback and ideas on the topic which has resulted, for example, in regular safety workshops at the annual Embedded World conference in Nuremberg in the past years. Aside from these workshops and seminars we also have been working on establishing the know-how base on FLOSS in safety by holding safety tracks in the context of the annual Real Time Linux Workshop (RTLWS) which helped to understand the current state of activities in academia (Linux driver verification, use of formal methods in the Linux kernel, FLOSS tools targeting certification etc. "REF Safety-track Prague"). Please refer, for example, to the agenda of the RTLWS13 Safety Track that is available here (right column).

What is OSADL SIL2LinuxMP?

Based on the quite extensive body of information and data collected, we have now launched the first certification initiative dubbed SIL2LinuxMP which in a nutshell is:

This initiative was introduced at the OSADL Networking Day on June 27, 2012 – given the positive feedback from participants, the initial kick-off took place in Cologne on July 24 with a first administrative meeting with TÜV Rheinland on July 25, 2012. While this is at a very early stage, the positive resonance the initial presentations gave indicate that the time for a FLOSS-based safety-related platform is ripe. There are many open questions ahead, but the OSADL Safety Critical Linux Working Group is ready to take on the challenge.

How can a company participate?

Please contact the author, OSADL's Safety Coordinator Nicholas Mc Guire (safetyªosadl.org), if you would like to join. There are three levels of participation:

• Full participants may define particular hardware and kernel configuration requirements and will be able to provide individual hardware to be qualified.
• Reviewing participants will accompany the entire certification process to be developed and, thus, be able to use it in future projects.
• Academic participants also will accompany the entire certification process to be developed and, thus, be able to use it in future projects. In addition, academic participants may provide individual services such as consulting and formal and semi-formal testing of drivers and other kernel components.