Freedom from Interference in Embedded Software


A leading automotive supplier of electronic steering wheel locks was faced with the challenge of adapting the software for an existing system to a new model series from the automotive manufacturer. The software was to be adapted in compliance with the ISO 26262 safety norm. 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 ASIL-A/ASIL-B(D); other parts of the software came from third-party providers or needed to be developed in line with pertinent QM requirements. The project team then had to ensure that the QM software did not interfere with the safety-relevant software components in such a way as to jeopardize the safety goals. The hardware was to remain the same.



Project Duration/Volume (employee months)

3 years

Approx. 20 man-days

Any Questions?

Any questions about our engineering service offers? Feel free to call us!

Contact card openContact card close


To achieve this, the safety expert from Method Park, together with the customer’s software architect, analyzed the software to identify potential interferences and to define appropriate countermeasures to prevent/detect any interference. The safety expert monitored the subsequent implementation of these measures.
The safety expert from Method Park and the software architect conducted a joint critical path analysis (CPA). Starting with the hardware-software interface (HIS), 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 safety expert from Method Park 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 components with different classifications were fragmented. The number of partitions was reduced to two, to thereby 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 safety expert from Method Park systematically analyzed the software architecture for any potential interference between the partitions. He used a SW-FMEA for this analysis. Here, he in particular considered errors that affect jointly used resources and interfaces (RAM, computing time, HSI, software interfaces), and can thereby inadvertently lead to critical behavior in the ASIL software components.
There are 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, since 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 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 thereby covered.
Together with the software architect and the project’s safety manager, the safety expert from Method Park defined appropriate countermeasures for each potential interference identified. The measures defined were adopted in the project as safety-relevant requirements for the software architecture/software components.
The safety expert from Method Park also supported the customer throughout the course of the project with the implementation of the defined requirements. This proved invaluable, since not all of the measures originally defined could be implemented as planned, and late changes to the system requirements also changed the initial situation.


Define safety-critical software components

Definition of partitions

Analysis of potential interference

Definition of preventative measures

Verification of the measures



More Information

Automotive SPICE


Ultimately, the customer’s safety manager and an independent agency (TÜV) were satisfied with the effectiveness of the measures and the software could consequently be successfully delivered. 



Safety goals not jeopardized by QM software

Adapted software meets ISO 26262