Independence of software elements for IEC 61508 on CPU without memory protection unit

Question

Is it possible to justify independence of software elements by IEC 61508, part 3, Annex F, such that the safety-related components can be rated SIL 2 and the non-safety components (eg UI, comms.) can be left unrated, and still have an overall result that is rated as SIL 2?

In particular I am interested in views on this when the safety and non-safety elements are all running on a single processor, and the processor does not implement any form of hardware memory protection. There are all sorts of things one could do to ensure that there is non-interference of software elements, such as ensuring data integrity, data passing is strictly controlled and verified, task scheduling is deterministic (non-safety tasks guaranteed to terminate), and so on.

Would such techniques rigorously applied be sufficient?

Answer 1

This is a question that doesn't have a definite answer. The answer is merely opinion based or depends on specific conditions.

If you have a company/organization that will do the assessment or certification you should ask them ( edit for clarification: ) if your approach is OK. As far as I understand the standards for the development of safety-critical devices you have to document that you considered all possible risks and how you detect or prevent the possible faults.

In a project to be certified to conform to a similar standard we put all safety-related data and code into specific memory sections and "lock" the safety-related data section by calculating a CRC after leaving the safety-related functions and check the CRC before entering again.

Additionally we check that the function to "lock" the data is called from the safety-related code section only by checking the return address. Any unexpected modification of the safety-related data will be detected, and the device will enter a safe state.

In our case this approach was sufficient to convince the people responsible for checking our software development.

Edit (to answer a comment)

Of course we are convinced ourselves that this solution is sufficient for the described purpose in the affected device.

This mechanism is only one part of the safety concept of the device.

The CRC mechanism described here is used to protect safety-related data in RAM against unwanted modification by non-safety functions to ensure independence of the safety-related functions from the non-safety functions. (It is not related to protecting the binary program in flash memory against modification. Of course we also do this using ECC flash and CRCs.)

Another edit: We also check periodically that the safety-related peripheral registers are not modified unexpectedly.

We have lots of other safety measures in the hardware and software, but these are not related to the question how to justify independence of software parts without an MPU.

The device which uses the technique described here conforms to a different standard with a safety level approx.between SIL 1 and SIL 2.

Of course every user must check if this solution is sufficient for a specific device.

Answer 2

If there is any safety-related firmware present in a MCU, then all of its software is safety-related. Period.

Common sense dictates that any bug anywhere in your code could cause runaway code, stack overflows, out of bounds access, spurious interrupts and so on. Not to mention bugs related to the interface between safety and non-safety related parts.

To make an argument about independence in a system where you would treat some parts of the software as less critical, you would need something like multiple cores executing code in different memory areas, without the slightest possibility to affect each other in any way. Which in turn would be a strange and needlessly complex design.

The normal approach is rather to set the same quality standard for every part of the code. Meaning that if you need to run some non-critical code in some non-verified stack or 3rd party lib, you should probably consider moving that to a separate physical chip. Keep the safety related parts as small and simple as possible.