The airline industry has been using fly-by-wire systems for many years with a good deal of success.  This success, however; has not come without its significant cost, including its deaths.  More recently, there has been a move toward converting land-based vehicles – cars, trucks, and commercial vehicles – to drive-by-wire systems.  “By-Wire,” as a general definition, is removing existing, mechanically controlled functions and replacing those functions with software controlled sensors that react to the environment and commands interpreted from driver input.  In the case of drive-by-wire, its impending and actual use is the result of two factors. The first factor being the increase in vehicle emissions standards, and the second being the decreased costs of an electronically based system. As we move toward a more technology-based world, we defer more and more control to electronic systems that control basic and safety critical aspects of our lives.  They can be used in a multitude of places on a car, from electronic sensors in the acceleration peddle, to braking sensors/motors, to electronic steering controls, and much more.


Pros and Cons

The advantages of the drive-by-wire are many.  As demonstrated by our military/commercial aircrafts, fly-by-wire technology has been used to increase the handling of aircraft and effectively allowed us to place craft into flight that would not have left the ground without fly-by-wire technologies. These same concepts are now being applied to drive-by-wire systems. The steering controls of current automobiles have been “tried and proven true” over the years, however; a by-wire system could dramatically increase the steering abilities of people in a critical situation even before they believe they needed it. This would allow the person driving the vehicle to concentrate more on the strategies involved in driving, rather than the nuances of it.


            The primary difficulty with this new and complex help is quite simple,  “… a drive-by-wire system is only as good as the programmers and manufacturers who design it.”[1] When a drive-by-wire system is being implemented there are many unique testing and engineering considerations. Even after you have answered basic questions such as: Do you remove all safety interlocks? Can one make a safety critical system robust when the software engineers do not plan for or forget to plan for an unknown situation? There are the significant questions about when to take control from the human being and how much control to take.


            Another difficulty with using software is that the software could fail, no matter how many times it’s tested. What we have to worry about is the degree of impact of this failure.  It’s well and good to say that all technologies fail and this one is bound to too, but the point becomes how much will the failure of a this system cost us in lives and injury. We already have a technology that has been tested and found reliable, and to push forward into this unknown area, knowing that it will cost lives and/or injury to others, could be a price the world is not willing to make for it’s comforts.  Some would suggest that consumers know about the problems complex software can create.  However, the problem is that most people do not know the cost of software controlled systems and it is up to those who create the software to make the systems safe.  Some automotive companies are planning to release their complete drive-by-wire systems as early as 2005. Partial drive by wire systems will be released to the public as early as next year (2003). These early models will have a safety back up system that is still mechanical, however; the removal of all mechanical safety backups is inevitable.


            As proof of this consider the fact that the concept of a Time Triggered Architecture (TTA is being employed; a system that is fault tolerant without mechanical backups,.  The following excerpt describes what a time triggered architecture is:

The fulfillment of this tough requirement together with cost-effectiveness and the "keep it simple as possible" safety principle consequently leads to a time-triggered architecture. Time-triggered means that actions concerning input sampling, computing and provision of results are executed at predefined points in time. An exact time schedule is then always guaranteed, the needed system bandwidth is limited at any point of time, and a system overload is impossible[2]


The only problem with this TTA is that it must be error free.  There is no place for errors and calculations take valuable time away from a system performance that could mean the difference between life and death.  Currently there is no standardized time triggered protocol.


Hypothetical Case

Roddenberry trucking company has been using the newest Frightliner line of trucks that incorporates a drive-by-wire system that controls the braking, steering, and transmission shifting of the commercial vehicle. At Christmas time, Roddenberry trucking receives a large order that is to be shipped immediately.  Roddenberry trucking estimates that the shipment will take 2 3/8ths truckloads to ship. At present, they only have two trucks available for the shipment, but they have to send the entire shipment to keep their contract.  In previous years, using standard trucks without the drive-by-wire systems, the trucks were simply overloaded.  Each truck would essentially carry a load and a half to complete the shipment.


            When Frightliner trucks, INC. developed the by-wire system for the brakes, they placed weight sensors to calculate the amount of cargo present at any given time.  As a legislated standard, no frightliner or other commercial vehicle could exceed an 80,000 lb. gross weight limit. The braking system used the measurement from the weight and speed sensors to calculate the maximum force needed to apply proper braking pressures to slow the vehicle without overheating the brakes.  


            En route, the two Frightliners proceed together to reach their destination. As they reach their destination in San Francisco, which is on a very steep hill, the calculations that execute when the driver applies brake pressure, encounter an error.  The developers of the software read the requirements as 80,000 lb. gross weight at any time,  not taking into account the truck could be overloaded.   The weight sensor reads an overweight variable into the calculation. Due to a mathematical truncation error in the braking calculation, the system applies less braking power than required for the current weight load. The brakes engage, but with less force for a long period of time causing the brakes to overheat.  Between the calculation error and the overheating of the brakes, there is no means of stopping the vehicles.  With the failure of the brakes, the trucks move into town where they impact with the waiting vehicles at the next traffic light.  Despite the fact that the trucks were overloaded and the primary failure was caused by the weight, are there any other persons that should be held liable for the crash?



One’s immediate reaction would be to say, “No”.  The trucking company had no legal right to overload the vehicles past the maximum weight allowed by law.  However, while overloading the trucks was a direct contributor to the fatal crash mentioned above the software engineers involved with producing the software used in the system did have a major role in the failure of the system and the crash that occurred.


The crash modeled for you occurred because of an unhandled error in the drive-by-wire software system.  There are several points within the Software Engineering Code of Ethics and Professional Practice (SECEPP) that address a software engineer’s responsibility where errors are concerned.  Principle 6.08 of the SECEPP provides a guideline for software engineers that urge them toTake responsibility for detecting, correcting, and reporting errors in software and associated documents on which they work.”[3]  It was initially the responsibility of the software engineers to ensure the safety of the system that they produced and the overloading of the truck was just a means of revealing an untested error.


 Principle 3.10 encourages software engineers to thoroughly test a piece of software to ensure it is safe.  In the case of Frightliners this was not the situation. The Frightliner engineers should have tested the software in a manner that would have uncovered the error that occurred when software was overtaxed.  The limit for commercial vehicles was set legislatively, but the actual ability of the vehicles seemed to have been ignored and known only by the company that used the trucks.


Identifying the fact that the software engineers used codified governmental controls rather than the abilities of the vehicle to temper their testing, one should also consider principle 3.07 of the SECEPP as a guideline that should have been referenced.  This principle encourages software engineers to “Strive to fully understand the specifications for software on which they work.”3  The software engineers used a government document to derive the specifications for the software rather than actually testing the vehicle for its capabilities and the possible values that their software could incur.  This resulted in lack of testing for a range of values they considered to be unattainable.


Software engineers have a responsibility to do their best when designing and testing a safety critical system.  In this case, the software engineers avoided or ignored guidelines that could have helped them perform tasks essential to producing a safe piece of software.  Also, humans make mistakes when programming and those mistakes are sometimes found only after the software has been implemented.  “A common mistake in engineering, in this case and many others, is to put too much confidence in software.”[4]   Practicing software engineers need take into consideration that if one creates software, one must be prepared to test it thoroughly so that the seemingly small mistakes do not cause catastrophic problems.




Brauer, Karl. 25 Jan. 2001. “Why Drive-by-Wire?



Heiner, Günter, et al. “Time-Triggered Architecture for Safety-Related Distributed Real-

Time Systems in Transportation Systems



 Johnson, Deborah G., Helen Nissenbaum. Computer,  Ethics &  Social Values.

 New Jersey: Prentice Hall, Prentice Hall, 1995


“Software Engineering Code of Ethics and Professional Practice”. Ver 5.2.



Copyright 2002 Richard Burgin, Will Valdez.  This case may be published without permission and at no cost as long as it carries this copyright notice.










[4] Johnson “An Investigation of the Therac-25 Accidents”