Embedded Systems November 2000 Vol13_12

Issue link:

Contents of this Issue


Page 33 of 189

Yes, he was engaging in a relatively hazardous activity (swinging through the jungle on vines), but the problem was typically one of inattention to the events in process. property, the idea ofli censing software engineers is increasingly appealing. Approaches to safety The previous section laid out some se rious issues associated with software. We would argue that the first four (complexi ty, error sensitivi ty, difficult to test, correlated failu res) are essen- tial to the nature of software, and aren't going away any time soon. The fifth one (lack of professional stan- dards) can certainly be resolved under the proper social conditions. So if software is so difficult to get right, do we stand a fighting chance? Of course. But the first step is to unde rstand where the challenges lie. Then we can reasonably pursue solu- tions. The value of software in safety- critical systems is huge, but it has to be balanced against the risks. The follow- ing sections deal with approaches that may hold promise as we seek to improve the quali ty and safety of soft- ware in embedded systems. Hazard analysis. In the old "George of the Jungle" cartoons, our hero rou- tinely smacked face first in to oncom- ing trees. Yes, he was engaging in a rel- atively hazardo us activity (swinging through the j ungle on vines), but the problem was typically one of inatten- tion to the events in process. In other words, he performed relatively poor hazard analysis. The keys to hazard analysis involve, fi rst of all , being aware of the hazards. As obvious as that is, a certain per- centage of acciden ts could have been avoided by simply being aware in the fi rst place of potential hazards. Once a hazard has been identified , the likeli- hood of an accident stemming from it needs to be assessed, and the criticali- ty of an accident should one occur. Once the hazards are understood at this level, devices can be designed that either eliminate the hazards or con- trol them to avoid accidents. The process of risk management must be on-goin g, constantly gauging th e derived value against the potential risk. In order to build safe embedded systems, hazards must be discovered early in the software life cycle. Safety critical areas must be identified so that extra care can be given to exploring the implications of the application of software to this particular domain. Within these safety-critical areas, spe- cific potential hazards must be identi- fi ed. These analyses become founda- tional pieces that feed into the design of the system. The software can now be designed in such a way that these p otential hazards can either be avoid- ed or controlled . A number of approaches can be used to discover potential hazards, including subsystem hazard analysis, system hazard analysis, designs and walkthrou gh , checkli sts, fault tree analysis, event tree analysis, and cause- conseque nce diagrams (which use fault and event trees) .3 Once you understand the potential hazards within a system, design deci- sions can be made to mitigate the risks associated with these hazards. The fol- lowing are examples: • Automatic controls can be built in to handle hazardous conditions. For example, home electrical sys- tems have breakers that will break a circuit if the draw of curre nt becomes too great. This provides a mechanism to protect against elec- trocution or fi re hazards. Similarly, an embedded device may have hardware o r mechanism overrides for certain safety-critical featu res, rather than depending strictly o n software logic fo r protection • Lockouts are mechanisms or logic designed to prevent enu·ance into an unsafe state. In software, a par- 32 NOVEMBER 2000 Embedded Systems Programming ticular safety-critical section of code may be protected by some access conu·ol mechanism that will permit entrance into the critical section only when doing so would not put the system in to an unsafe state • Lockins are similar mechanisms that enforce the continuation of a safe state. As an example, a lockin might rej ect any input o r stimulus that would cause a currently safe state to be compromised • Interlocks are mechanisms that consu·ain a sequence of events in such a way that a hazard is avoided . As an example, most new au tomo- biles require that tl1e brake pedal be depressed before the key can be turned to start th e car. This is designed to avoid the hazard of children turning the key in an igni- tion when they are too small to control or stop the vehicle Testing. Testing involves actually run- ning a system in a specifically o rches- trated fashio n to see what it will do in a given situation. A number of chal- lenges are inherent in testing, and they strike at the heart of why it's essential that quali ty be buil t in to soft- ware as it's created, rather than tested in after the fact. The following are a number of dange ro us assumptions that are frequently made, and which testing will not fix: • The software specification is cor- rect. If it is not correct, verifyi ng that a software im plementation matches its specification may not actually provide information about the risks that resul t from prospec- tive hazards • It is possible to predict the usage environment of the system. Certainly, much can be known abou t tl1e envimnment, but it's not possible to predict the actual usage. Fail ures can happen as a resul t of changes in things as simple as oper- ator typing speed and ambien t room temperature

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems November 2000 Vol13_12