How to Architect Software for Safety

How to Architect Software for Safety

The temptation to jump in and start coding is always great. For both safety and security if you take this approach you may pay for it later. Designing a proper software architecture can...

  • Simplify interfaces
  • Reduce the amount of code which has to be considered as safety related
  • Facilitate modularization
  • Facilitate test and verification
  • Facilitate easier change manage for non-safety related software
  • Allow for a tighter hardware design
  • Simplify the code

As regards the goal of simplification I love the quote below although I still have to read it twice

 Figure 1 - A good quotation on software design

The V model from IEC 61508-3 shows the software architecture step as the step between capturing the requirements and software design. It is the step which decides the basic software safety strategy including the use of redundancy and diversity. It also involves allocating the functionality to the major elements and sub-systems and deciding how they will be interconnected.

Figure 2 - V model from IEC 61508-3:2010

Some of the best descriptions of software architecture are given in the machinery standard IEC 62061 including the figure below. The figure is not dedicated to software but I think it still gets the idea across.

Figure 3 - Extract from the machinery safety standard IEC 62061

If the architecture doesn’t support sufficient separation between safety and non-safety software, then all the software will need to be developed to the safety standards. If the software is of mixed safety integrity, then an architecture which doesn’t support a claim for sufficient independence will lead to all software having to be developed to the highest safety integrity of any module.

Obviously, the software architecture will need to coordinate with the hardware architecture. If the system contains three uC/uP with one to run the control software and two to each run a safety channel, then the individual uC/uP can each have their own software architecture with sufficient separation/independence largely demonstrated by default. Achieving the same thing in a single processor will need much more architectural planning. 

In addition to the partitioning into sub-systems and elements the architecture shall also describe the control flow but that will makes a future blog topic.

This week’s video is at and discusses the rad hard design of the SpaceX rockets and their software architectures.

For next time, the discussion will be on software independence/demonstrating sufficient separation.