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.
I was reading somewhere where some tech blogger (Tech Radar or something such as that) in the United States was suggesting car makers should dump QNX and other current interactive/infotainment systems and simply install iPads and Android based tablets. I guess you don't agree.
ReplyDeleteYou're right, Anonymous, I don't agree. It’s true that bringing in such devices could give the automaker the ability to upgrade frequently and to use app stores or other downloaded content. Problem is, this approach places no restrictions on what the user can do while driving, and that can be (very) dangerous. Also, devices like this aren’t built for the in-vehicle environment: they can’t satisfy automotive-grade standards for operation in extreme cold or heat, resistance to vibration and electrical interference, not to mention resistance to liquids and solvents. On top of that, mobile devices don’t have any interface to vehicle data — and access to such data can make or break a good navigation system, provide crucial statistics on vehicle maintenance, and help you drive safely. There best solution for an infotainment system is to leverage the assets of the vehicle while offering integration with a consumer device like a phone or tablet.
ReplyDelete