Software components can be impolite, if not downright delinquent. For instance, a component might:- rob other components of CPU time
- rob other components of file descriptors and other system resources
- access the private memory of other components
- corrupt data shared with other components
- create a deadlock or livelock situation with other components
Shameful, I know. But in all seriousness, this sort of behavior can wreak havoc in a safety-critical system. For instance, let's say that a component starts to perform a CPU-intensive calculation just as the system enters a failure condition. Will that component hog the CPU and prevent an alarm process from running?
The answer, of course, is that it damn well better not.
It becomes important, then, to prevent components from interfering with one another. In fact, this principle is baked into the ISO 26262 functional safety standard for road vehicles, which defines interference as:
- "...the presence of cascading failures from a sub-element with no ASIL [Automotive Safety Integrity Level] assigned, or a lower ASIL assigned, to a sub-element with a higher ASIL assigned leading to the violation of a safety requirement of the element”
To put it crudely, less important stuff can't stop more important stuff from happening.
So how do you prevent interference? One approach is through isolation. For instance, a system may implement spatial isolation between application processes. This would include mechanisms for interprocess communication and interprocess locking that prevent one process from inadvertently affecting another.
Mind you, there are multiple types of interference, so you need to implement multiple forms, or axes, of isolation. Time for a picture:
In general, you need to determine what does, and what doesn't, need to be isolated. You also need to identify which components are apt to be delinquent and build a cage around them to protect more critical components. Which brings me to a recent paper by my inestimable colleagues Chris Hobbs and Yi Zheng. It's titled "Protecting Software Components from Interference in an ISO 26262 System," and it explores techniques that can help you:
- implement the component isolation required by ISO 26262
- demonstrate that such isolation has been implemented
And while you're at it, check out the other titles in our "safe" whitepaper series. These include "The Dangers of Over-Engineering a Safe System" and "Ten Truths about Building Safe Embedded Software Systems."
And don't worry: there's nothing delinquent about downloading all of them.
This post originally appeared in the QNX auto blog.
