Freedom From Interference in Embedded Software

The situation

A leading automotive supplier of electronic steering wheel locks was faced with the challenge of adapting the software to an existing system for a new model series from the automotive manufacturer. The software was to be adapted in compliance with the International Organization for Standardization (ISO) 26262 functional safety standard. No hardware redesign was planned. The existing system had a 16-bit microcontroller, with no hardware-based memory protection

Parts of the software were to be produced on the microcontroller in accordance with Automotive Safety Integrity Level (ASIL)-A/ASIL-B(D). Other parts of the software came from third-party providers or needed to be developed in line with pertinent quality management (QM) requirements. The project team then had to establish that the QM software did not interfere with the safety-relevant software components so as to jeopardize the safety goals. The hardware was to remain the same.

Project duration

Three years

Our approach

To achieve this, the safety expert from UL Solutions Software Intensive Systems (SIS), together with the customer’s software architect, analyzed the software to identify potential interferences and define appropriate countermeasures to prevent and detect any interference. The safety expert monitored the subsequent implementation of these measures.

The SIS safety expert from and the software architect conducted a joint critical path analysis (CPA). Starting with the hardware/software interface (HSI), they identified the safety-critical software parts. In addition to the software parts deemed system-critical from a functional perspective, this also included components that safeguard the error-free operation of the hardware. This entailed the diagnostic analysis of actuators and sensors and troubleshooting for the program and random access memory (ROM/RAM), arithmetic logic unit (ALU), clock, etc.

In the next step, the SIS safety expert and the customer’s software architect divided the software into separate partitions, based on the relevant ASIL classifications. Within each partition, the software was developed in accordance with the same ASIL classification. Software components with different classifications were fragmented. The number of partitions was reduced to two to reduce the resources required for the analysis and measures, whereby the software components within a given partition were all developed in accordance with the highest ASIL classification.

Once this partitioning was complete, the SIS safety expert systematically analyzed the software architecture for any potential interference between the partitions. He used a Software Failure Modes and Effects Analysis (SW FMEA) for this analysis. He particularly considered errors that could affect jointly used resources and interfaces (RAM, computing time, HSI, software interfaces), and could thereby inadvertently lead to critical behavior in the ASIL software components.

There is a series of measures for detecting or preventing such mutual interference. In this project, the only approach was to detect potential interference and prevent the safety goal being infringed, since no hardware-based memory protection was available. The hardware-based partitioning of the RAM was not an option because the microcontroller had no memory protection unit (MPU). Once the software’s QM components had been implemented, it therefore had to be assumed that potential errors could inadvertently change safety-critical content in the memory.

This initial situation significantly increased the resources required for the software but made it possible to safeguard the behavior of the software. It should be noted that the use of an MPU does not prevent any mutual interference either; only the resources RAM and HSI are covered.

Together with the software architect and the project’s safety manager, the SIS safety expert defined appropriate countermeasures for each potential interference identified. The defined measures were adopted in the project as safety-relevant requirements for the software architecture/software components.

The SIS safety expert also supported the customer throughout the course of the project with the implementation of the defined requirements. This was invaluable, as not all of the originally defined measures could be implemented as planned, and late changes to the system requirements also changed the initial situation.

Highlights of our approach include:

• Define safety-critical software components
• Definition of partitions
• Analysis of potential interference
• Definition of preventative measures
• Verification of the measures

Benefit

The customer’s safety manager and an independent agency were satisfied with the effectiveness of the measures. Consequently, the software could consequently be successfully delivered.

Key customer benefits included:

• The safety goals were not jeopardized by QM software.
• Assistance meeting ISO 26262 requirements.