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 (e.g. 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?
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.