Design Article
Verifying the border line between auto hardware, software
Swapnil Sapre
2/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.
|
|
|
|
|
TiMan
2/16/2010 1:27 PM EST
More than just software-- manufacturers must maintain long-term relationships with suppliers (per W.E. Deming), or bad things happen. This is why outsourcing to china and elsewhere scares me so much.
Sign in to Reply
Joe Fox
2/16/2010 1:37 PM EST
This is no different then the requirements we've had in aircraft avionics for thirty years. It's easy to build a product that has multiple standalone system (propulsion, electrical power, radios, engine control, etc). It's much more difficult when those systems are integrated with common controllers and busses. As the automotive industry pursues increased levels of integration, they are going to have to adopt the tectniques of the aerospace industry w.r.t. tiered integrtaion labs, real requirements verification, multiple system integration lines, etc. They are also going to have to be much more diligent in the development, verification, AND maintenance of appropriate interface documentation. It's not cheap, but it is required to manage the inherent complexity of deeply integrated electromechanical systems.
Sign in to Reply
JakeClarke
2/16/2010 7:28 PM EST
Interestingly, Audi was plagued with both throttle and brake problems about 25 years ago. It was never concluded publicly, but when the throttle is wide open, the brakes have NO vacuum assist. I'm not sure if this is true in the case of Toyota, but it may be worth looking into.
Sign in to Reply
winterho
2/17/2010 9:39 AM EST
Verification methodologies used in the hardware world like executable, metric-driven verification plans, functional coverage and constrained-random test generation are now available for software validation and test.
Cadence Design Systems offer a product called ISX http://www.cadence.com/products/sd/isx/pages/default.aspx that is indeed very usefu finding bugs where hardware meets software.
If anyone is interested in finding out more, visit one of the conferences embedded world http://www.embedded-world.eu/program/day-1.html?program_id=2126 in Nuremberg or CDNLive http://www.cadence.com/cdnlive/eu/2010/pages/default.aspx in Munich, Germany.
Or contact me directly at markus@cadence.com
Sign in to Reply
BPA
2/18/2010 11:02 AM EST
The author has contradicted himself. In para. 6, he says that ASIC functional verification lacks the "executable, metric-driven verification plans, functional coverage and constrained-random test generation typically being used in software development." Then at the end he says, "The central problem for the future is that software verification has no formalized methodology." So which is it?
In my experience, software testing is not ad-hoc. We design our software to meet detailed requirements and specifications and develop specific tests to ensure that they are met.
Sign in to Reply
hiTech
3/6/2010 6:10 PM EST
ARINC DO-178B (being upgraded to DO-178C) for SW and DO-254 for ASICs / FPGAs have been formally adapted by the FAA and Boeing for flight safety critical SW and SW associated FPGA/ASIC systems (Boeing 777 and 787). Some aspects of these standards may be applicable to guide development, testing, and certification of automotive safety critical subsytems
Sign in to Reply