A Master Plan for all functional Safety Standards and Levels

A Master Plan for all functional Safety Standards and Levels

Feb 14, 2023

The certification of the functional safety of a system is complex. All the manufacturers involved have to contribute to comply with standards - from the hardware with its BSPs and drivers, through the hypervisor and operating system, to the application code of the OEM and third-party supplier. The operating system, which is optimized specifically for the hardware, and the hypervisor used in mixed-critical systems have a key function here - lying between the hardware and the application. If this all-connecting functional block is developed according to a harmonized master plan that can be applied to all standards and levels of functional safety, OEMs will reach their goal faster and more reliably in the specific certification task. Such a master plan is of full value if sub-functions of a mixed-critical system are to achieve different safety levels and security certification is to be covered in addition to safety certification.

The software development processes are largely identical for each functional safety application. However, what is specifically required for the respective industry certification is often very specific. Even if a software meets the highest requirements, such as DO 178C level A, which is used in the aviation industry, it cannot be used 1:1 for ISO 26262 certification in the automotive industry, because there are nuances in the basic requirements as well as major differences in the specific certification and the documentation required for it, which must be met precisely.

Meeting different Safety Levels

Heterogeneous requirements naturally also exist within each individual certification standard due to the different safety levels. In avionics, for example, there is as mentioned above DO-178C Level A, which was created for protection against a "catastrophic effect" - specifically, for protection against an aircraft crash. Highly redundant systems and software must be developed for this purpose. For DO-178C Level D, which applies to software that only slightly alters the safety margin in the event of failure - for example, slightly alters the workload of the crew, causes inconvenience to passengers or leads to a routine flight plan change - the requirements are significantly lower. Expenditures that you have to make for the highest level you don't want to make for lower levels because, of course, they cost time and money. A similar concept is followed by virtually every certification standard in the individual industry sectors. For example, the automotive industry's ISO 26262 ASIL-D applies for the highest functional safety level, while ASIL-A is for the lowest level.

Nevertheless, one and the same master process model can be used to fulfill all requirements of the different functional safety standards and levels by means of standardized procedures. The process must only be able to take the route required for the specific use case in order to create the required result of a standard-compliant certifiable solution with minimum effort - regardless of which standard is to be achieved.

Serving different Industries

Such a cross-industry process model is of interest, for example, to solution providers who develop control systems with integrated situation recognition. After all, they want to sell their technology with immense growth potential in as many industries as possible: From autonomous collaborative robots (IEC 61508) and image-guided surgical robotics (IEC 62304) to automated guided in-plant logistics vehicles and autonomous agricultural machinery to autonomous railroads (EN 50128), aircraft (DO178C) and drones, and of course for motor vehicles (ISO26262), which are currently probably the largest application field of all, as numerous new solutions are being developed for e-mobility and autonomous driving. And even in the automotive sector, there are different requirements for functional safety due to the different levels of autonomy.

If the issue for example is collision avoidance with increasingly complex logic for decision making based on data from a wide variety of sensors used for environmental detection, the task of developing ASIL D compliant logic becomes extremely complex, which is why approaches are already being discussed on how to perform environmental detection using specific methods (e.g., SOTIF tests, HARA analyses) without the complex development requirements of ISO26262. [1]

Certifiable functional safety is therefore not a simple task, if only because of the variety of possible different requirements and the associated necessary solution approaches. Rather, it requires profound know-how regarding the individual standards and their different security levels. Also, it depends on the resulting different requirements for software functionality and the processes of how to achieve functional safety and last but not least, how to document this in a certifiable manner.

Moreover, the requirements naturally do not only relate to the actual application code. Rather, the solution must be considered in its entirety. In the case of embedded and edge computing systems, the interaction of hardware, operating system and third-party software with the application code of the solution provider is therefore also always important.

Developing mixed-critical Applications

Tasks are also becoming increasingly complex, due to more highly integrated processor technology, the tasks are also becoming increasingly complex: Whereas individual tasks of an overall solution used to be distributed discretely to dedicated controllers depending on their level of functional safety, and certifications were tackled individually, the goal today is to integrate mixed-critical systems on heterogeneous SoCs (system-on-chip). As a result, the tasks and interdependencies multiply, so that holistic approaches to solutions must be found. Otherwise, it is possible to get bogged down and the potential for increasing efficiency cannot be exploited if different approaches are selected for individual subtasks.

So how do you approach certification as efficiently as possible in the face of increasing complexity? Basically, the process can be divided into four phases, regardless of the complexity of the overall solution. First comes the basic planning, then the actual development, followed by the analysis and verification of the result, and finally, at the end of the process, the system is qualified for certification.

Orchestrating all Process Participants

The foundations of successful certification must be developed as early as the planning phase begins. After defining the targeted standards and certification processes, the first step is to analyze the expertise of all partners involved in relation to the targeted standards. If necessary, identified weaknesses can be remedied or alternatives found within the framework of the project. The interaction of all partners is also important, from those in charge of the hardware with safety certification to those in charge of the certifiable operating system and the application software, since all parties usually have different interests and want to minimize their efforts. Here, a common understanding with regard to responsibilities must be created and tasks clearly assigned. Finally, each purchased component also has "usage constraints" that must be observed or coordinated between the individual entities.

For mixed-critical applications based on heterogeneous SoCs, it must also be ensured that non-certifiable software components such as a Linux-based GUI are separated from safety-relevant instances using separation kernel and hypervisor technology. By moving them to a clean and safely separable partition which does not run critical code, it can be ensured that they have no impact on the parts of the system that need to be certified. The more functions one can exclude from certification in this way, the less effort is required. However, if the GUI is also to be functionally safe, it must become part of the safety engineering process. The more diverse and heterogeneous the safety requirements of an overall application are, the more important the master plan becomes.

The selection of the certification authority is also not insignificant, since it determines which foundations have to be created by when for the specific audits of the certification. It also makes sense to integrate the authorities directly into the processes during the planning phase. In this way, they can also directly check the planning documents to be set up. Namely, these are the safety plan, the development plans (development, verification and validation, quality and configuration management) and, in particular, the compliance tables, in which it is specified which processes are used to fulfill which parts of the standard.

Master Safety Plan and Compliance Tables for all Certification Requirements

It is precisely at this point that it is enormously beneficial to have a master safety plan for all certification requirements. Among other things, it defines how the operating system and its BSPs and hardware-related drivers are developed, validated, tested and documented. This can then take different routes depending on the standard and security level for which the solution is to be developed. The approach is supported by compliance matrices for each certification standard, which are based on a generic development concept.

The advantage for customers is that the effort required to create the safety plans is significantly minimized, as there is already a master plan that can be adapted for all standards. It has already been proven by numerous certifications that it fully meets the necessary requirements, wich offers customers corresponding process reliability. Finally, a master plan also creates the basis for being able to easily port certifications of one industry to other industries or to be able to raise originally lower safety levels to higher levels more easily, since everything interlocks. If, for example, we evaluate the possibility of certifying functions for autonomous driving for higher autonomy levels in the future than we are currently aiming for, then we can already lay the foundations for later upgrades within the framework of current developments. A master plan of this kind and adaptable compliance matrices also protect against dead ends in development that would not be recognized if the focus would be restricted to the specific project in question.

Synergy Effects between Safety and Security Certification

The processes used for safety certification can also be used for security certification. Conversely, this results in the advantage that safety developments which have been developed on the basis of a safety & security master plan already create essential foundations for security certification. For the security certification of a safety application, only those elements that have not already been processed via the safety certification need to be added. Such a holistically integrated solution approach offers the OEM significant efficiency gains, since everything is interlocked and coordinated.

Tasks that go beyond safety certification include the implementation of secure development to prevent infiltration by malicious code. It must also be ensured that vulnerabilities are NOT disclosed so that hackers don't get them handed on a platter to exploit. Also, additional vulnerability analyses or penetration tests are typically not part of a safety certification, but are essential for a security certification. The specification of how requirements should be designed and that there must be a code review to evaluate vulnerabilities can already be taken from the safety specifications. This means that projects with safety and security certification can be approached in a harmonized manner right from the start. When it comes to security, you can ultimately concentrate entirely on what is specifically required for security, which in turn brings with it the potential to increase efficiency.

In today's times, it will no longer be possible to separate safety and security from each other anyway, because there can no longer be any safety at all with IoT-connected devices without security. In this respect, master plans for holistic safety & security will become mandatory anyway. If application developers for safety have already had their OS design developed according to such a master plan, subsequent security certification can benefit from it.

Holistic Solution Kit

SYSGO is a company that performs safety and security certifications for its own operating system PikeOS as well as for customer specific I/O and hardware related drivers in cooperation with authorities and test laboratories and thus fully supports such a master plan. In addition, SYSGO also supports this principle for customer-specific solutions within system integration. Furthermore, with PikeOS it offers a real-time operating system and Type 1 real-time hypervisor bundle that has already been certified in many industries according to the highest levels of functional safety. The PikeOS separation kernel (version 5.1.3) also achieves the highest security levels against Common Criteria at Evaluation Assurance Level (EAL) 5+. With ELinOS, the company also offers an embedded Linux distribution that can host applications in mixed-critical applications which do not require primary certification. The entire mixed-critical application can also be developed in a single CODEO integrated development environment. Also, data exchange between functionally safe and other application code in different partitions can be orchestrated using dedicated "communication ports", so that message delivery is guaranteed. This is possible regardless of which OS or which type of processor (MMU or MPU) is to be communicated with. The complete interaction of mixed-critical applications is already incorporated into the safety & security master plans. The whole process is comprehensively flanked by consulting and training services within the scope of customer projects, so that OEMs reach their goal faster and more reliably than if they try to put together their specific solution package on the basis of heterogeneous components on their own. After all, it is the application code that is the decisive competitive factor. Everything else is better left to the experts, who provide customers with the technology toolkit and support them in creating hardware-specific, optimized operating system and hypervisor tailoring on a daily basis.

More informationen at www.sysgo.com/pikeos

Professional Articles