EETimes

Embedded Systems November 2000 Vol13_12

Issue link: http://dc.ee.ubm-us.com/i/71849

Contents of this Issue

Navigation

Page 30 of 189

As technology becomes more and more ubiquitous, with more of that technology being controlled by software, a greater portion of the risl< we face is ultimately in the hands of software engineers. inju•-y, loss of life, or unacceptable loss of proper ty. o how significan t has the risk become? Conside r that software is now commonly found in the control sys- tems of nuclear power plants, com- mercial ai rcraft, automobiles, medical devices, defense systems, and air traffic control systems. It's likely that almost everyone has at one time or another put themselves, their lives, or their property into the hands of the engi- neers that built the software conu-ol- ling these systems. The spread of soft- ware into safety-critical sys tems is like- ly to continue, despite the risks. Hazards, accidents, and risks A hazard is a set of conditions, or a state, that could lead to an accident, given the right envi ronmental trigger or set of events. An accident is the real- ization of the negative potential inher- ent in a hazard. For example, a pan of hot wate r on a stove is a hazard if its handle is accessible to a toddler. But there 's no accident until the toddler reaches up and grabs the handle. In software, faults or defects a re errors that exist within a system, while a failure is an error or problem that is observable in the behavior of the sys- tem. A faul t can lie dormant in a oft- ware ystem for years before the right set of environmental conditions cause the p.-oblem to manifest itself in the f- Risks can be addressed at three fu n- damental levels: • The likelihood that a hazard will occur • If a hazard occurs, the likelihood that the hazard will lead to an acci- dent • If an accident occurs, the level of loss associated with the accident As we build safety-c ritical software, we need to be concerned wi th mitigating risk at each of these levels. Software in safety-critical devices \ \Th en we build safety-cri tical software, it is imperative that we ensure an acceptable level of risk. That doesn't mean that risk won 't exist. But we will have taken care at each of the three levels to eliminate the • degrade wi th use (such as the way tires or brake shoe will gradually wea• · out until it's time to replace them). Software may break immedi- ately upon instal la tion due to unfore- seen environmental or usage condi- tions. It may work reliably until a use• tries something unexpected. It may work well fo r years until some operat- ing condition suddenly changes. It may fa il in termitten tly as sporadic environmental conditions come and go. With all of these legitimate con- ·isks where pos- sible and to reduce the risks tJ1at are unavoidable. In doing so, we must concern ourselves with the interaction of the controlling software with th e rest of the system. Software, by itself, never poses a threat to life or limb. It needs some help from mechanical sys- tems to do that. In assessing the level of risk inher- unctioning system (think Y2K). • Our ultimate concern here is not whether hazards should exist, or whether software faul ts should exist. You can debate whe ther they should or should not, and you can even argue whether it's theoretically possible to eliminate them at all. But the reali ty is that they do exist, that they represent risk, and that we have to deal with that risk. ent in turning over safety-critical con- trol functions to software, it is valu- able to compare the u·ack record of software with other types of engineer- ing. Softwa re is indeed unique in many ways. As Frederick Brooks poin t- ed out, certain essential cha racteris- ti cs of software are unique and chal- lengin g. (1] As a resul t, when com- pared to othe r engineering fi elds, software tends to have more errors, those errors tend to be more perva- sive, and they tend to be more trou- blesome. In addi tion, it is difficul t to predi ct the failure of software because it doesn 't gracefully or predictably cerns over software, it begs the ques- tion, "Why use software in safety-criti- cal systems at all ?" l f a risk is worth tak- ing, it's because some return or advan- tage accompanies the risk. One of the most significant reasons for using soft- ware in embedded devices (whether safety-cri tical or not) is that a higher level of sophistication and control can be achieved at a cheaper cost than is possible with hard-wired electroni cs or custom designed mechanical features. As we come to expect more out of embedded devices, oftware is current- ly the best way to keep up with the steep growth in complexity. In a changing e nvironment, devices must e ithe r adapt or face early obsolescence. Ha rd-wi red devices must be either replaced or face expen- sive upgrades. On the other hand, software can be upgraded relatively easily, without swapping out expensive hardware components. Finally, because of the powe r and flexibili ty of software, devices can deliver a great deal of information to users and technicians. Such software- conu-olled devices can gathe r useful in formation, in terpret it, perform diagnostics, or present more elegant interfaces to th e user, at a more acceptable cost than is possible with hardware. Embedded Systems Programming NOVEMBER 2ooo 29 -

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems November 2000 Vol13_12