Toyota conducts model test
Author : Tim Fryer
28 February 2011
As I understand it the problem of the mysteriously accelerating Toyotas remains at least partially unresolved after the ‘finger of blame’ stopped pointing at the electronics.
We covered the unfolding of the story 'Electronics are not to blame' a couple of weeks ago after it was announced that scientists had looked at the electronics and they were not blame for a number of Toyata’s models experiencing unintended acceleration.
As a general observation (i.e. NOT one based on the situation at Toyota) companies, or departments within companies, are reluctant to accept responsibility for anything, let alone the recall on safety grounds of millions of cars. And so as a natural cynic I am rarely surprised when enquiries of the ‘what-went-wrong’ type fail to pin point what actually did go wrong, or whose fault it was. This appears to be as true of governments, police forces, armies, especially international banks, as well as technology companies.
However, in the case of the Toyota electronics question they obviously decided it was worth getting the right answer rather than finding a way of burying the subject and so passed the problem over to the scientists at NASA.
One aspect of the work conducted by NASA was picked up in a blog by Paul Barnard of MathWorks, which was passed on to me in reply to our earlier article. Paul wrote:
"I just read the final report from the NASA Engineering and Safety Center (NESC) as part of the National Highway Transportation Safety Administration (NHTSA) investigation concerning unintended acceleration of Toyota vehicles. I was interested in the report because NASA used MATLAB and Simulink in their investigation. It’s pretty cool that MATLAB and Simulink were considered essential in a project of this magnitude.
The report focuses its investigation on two possible electronic failures. One was potential failures in the pedal position sensors and the other concerned a software malfunction in the main CPU. For the software malfunction, NESC looked for both coding defects and for algorithm flaws. This is where it gets interesting.
They looked at more than 280,000 lines of code from a representative Camry engine control unit. In order to verify the logic and understand the functionality of the code, the team used Model-Based Design. They built a high-fidelity model, using MATLAB and Simulink, for the software and the hardware to explore system design and implementation, failure causes and effects. Simulation scenarios were run and model responses were then compared to the actual vehicle responses to verify that the models were accurate. The software models provided insight into how the ECM was supposed to work. In effect, they used MATLAB to discover how the system is supposed to work and how it can fail. This allowed them to look for system vulnerabilities.
Beyond that, it was interesting to note that they found another benefit in using Model-Based Design.
The MBD approach also supported the dissemination of the software functions and behaviors to the team as a whole. Presentations of the software in this manner efficiently communicated the software within the MY 2005 Camry microcontrollers without exposing the native source code.
Improving team communication is often one of the reasons cited for adoption of Model-Based Design. Simulating the system models and using these models for design communication are two of the key values that Model-Based Design provides.
In the end, no major flaws in the control unit were detected, but now, there is a lot more understanding."
An engineering strategy for a scientific test!
Contact Details and Archive...