Unformatted Attachment Preview
Death-By-Wire
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. “ByWire,” 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,
flyby-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?