Verifying the border line between auto hardware, software | ||||
| By Swapnil Sapre | ||||
 Page 1 of 2 | ||||
| Automotive DesignLine (02/16/2010 10:24 AM EST) | ||||
| | ||||
| I have long been ardent fan of Toyota Motor Corp.'s manufacturing know-how. Toyota was the first car maker to streamlin manufacturing processes and the quality matrix in its factories. It also established a work flow and performance management for its workers while implementing a methodology to track production. This was indeed very different from Ford, GM and European car makers who instead stressed luxury, customization and other selling points. Toyota dominated the auto market thanks to its new process implementation techniques, later referred to as the "Toyota Way." Now, Toyota is in news almost daily because of bugs that have been found in key components like electronic throttles and brakes. The result has been massive and expensive recalls. Experts and technologists say software bugs likely contributed to problems with a range of Toyota vehicles. Being a hardware engineer, including VLSI chip verification, I am not frequently exposed to software test cycles. But considering the current raft of software standards, I presume that test flow must be as robust as it is in hardware verification. Software validation has been formalized many times, by the Software Engineering Institute and the Capability Maturity Model Integration spec and in many other ways. It should be a much more mature practice than ASIC validation. Still, I doubt that ASIC functional verification has many features generally lacking in software verification. I am unaware of executable, metric-driven verification plans, functional coverage and constrained-random test generation typically being used in software development. However, many problems occur when hardware meets software, especially in automotive applications. This is where advanced, functional verification methodologies from the hardware world can be very useful. The problem is bound to occur most frequently when there is an integration of software and hardware. ASIC designers lack the rigor or methods for software validation to apply to drivers and other components that are being validated. Software engineers don't understand everything about the hardware. Combine that with the task of integrating legacy control systems and you get a sense of how difficult hardware-software can be. A Toyota presentation titled, "High Confidence Powertrain Control Software Development," addressed an earlier power train control bug and the verification problems associated with it. The presentation was given at a 2006 Supervisory Control and Data Acquisition conference. It was written by three Toyota engineers and is very revealing.
| ||||
Verifying the border line between auto hardware, software
