Methodology and Major Sources of DataAnd from today's AutoGuide.com :
An initial Internet Search using Google was performed, and major sources of data were found in the first phase. The most fruitful sources of data were:
● The Proceedings of the Software Engineering for Automotive Systems Workshops in the International Conference of Software Engineering [1,2,3,4]
● Society of Automotive Engineers of Japan On-Demand Library [5]
The second phase involved review of the (several hundred) papers and abstracts found in the first phase, usually from the major data sources, and further papers found as article references were identified.
The third phase involved review of these referenced papers where available on-line, sifting out the most important data, and summarising the issues and conclusions in a preliminary report.
Trends Identified
...
3. Increased Recognition of Value of Software Development
The Keynote presentation at the 4th Workshop on Software Engineering for Automotive Systems [16] reported that the cost of Software relative to Hardware is now typically 3:1. It also reported that the cost of remedying software defects causing product recalls is growing at an alarming rate. We are in the Horsepower and Buggy era.
Commercial considerations are driving software development, in order to provide market differentiation between similar products from different suppliers.
Recent market research published by IBM [21] shows that 90 percent of automotive innovation is expected to come from electronics by 2010. Electronics can increase automakers' ability to differentiate automobiles in an increasingly competitive marketplace. With the constantly rising amount of software code in automobiles, electronics expertise and reliable process development among suppliers have become vital.
As stated by IBM spokesmen in an article in the New York Times [28], IBM also predicts that by 2010, almost all cars will have essentially the same mechanical systems. What will make the cars different will be software that operates the systems in ways specific to the brand of car. With so much of a vehicle's identity riding on computer code, carmakers must get the software right.
...
5. Recognition of Unique Attributes of Automotive Software Development
There is widespread recognition and agreement within the Industry on the characteristics of the Automotive Software Domain that make it so challenging and unique. The Emaus speech [23] summarised in one slide the Unique Attributes of Automotive Software Development, and the consequences thereof:The last line is a comment on the current state of Software Development Methodology in the Advanced Automotive domain : that in the main it is amateurish and haphazard.This may help to explain why so many cowboys are in automotive software
- For the typical vehicle program, automotive module requirements begin at this state:
- 80 percent is known and 20 percent is unknown
- The software developer only knows 4/5 of what is needed and the rest later
- The date of “later” is not defined
- The size of the “later” is not defined
- Few in the industry expect this to change
- Why? Last minute feature additions or changes are common
- This is the normal business process of developing software
6. An Increasingly Litigious Environment
Although a careful search has revealed no publicised cases of software being directly to blame for a serious automotive mishap, the current “state of the art” of software development in the automotive domain leaves car manufacturers very vulnerable to litigation. According to Chrysler Group President Tom LaSorda [30], it has been estimated that the cost of litigation already exceeds $500 US per car in the USA.
Unlike avionics, where there are industry safety standards and techniques for software development (DO-178B) and formal proof of correctness required in key areas, no professional expert witness could say under oath that automotive software is being developed in accordance with safety-critical software “best practices”. It is not enough to be actually safe, the software must be seen to be safe, otherwise the manufacturers may be held partially liable even if entirely blameless, as noted in the San Francisco Chronicle as early as 1988 [26]
...
Fear of litigation has already caused a “split” in features offered within the USA as opposed to Japan and Europe. As the New York Times [32] recently reported :Fear of legal action has also stopped Toyota from offering its Intelligent Parking Assist feature, which is now available on the hybrid gaselectric Prius model sold in Japan....
Toyota has announced that it has received subpoenas from both the U.S. Grand Jury and the Securities and Exchange Commission (SEC) over documents related to “unintended acceleration” issues with millions or cars, as well as the braking system on the Prius.From Gizmodo a fortnight ago:
Toyota just announced a recall of its 2010 hybrid cars. Four hundred thousand worth. The reason? A change in "brake feeling" caused by faulty antilock braking software. There is no fix for cars on the road yet.Some important things to note:
This problem, unrelated to the sticky gas pedal issue that other drivers complained about. But I'm still wondering what exactly is bothering our Prius-loving friend Woz, who claims he has a faulty cruise control issue that is software related, not mechanical.
Remember that old joke about if cars were as crash prone as computers? Yeah, not funny in 2010.
That this was the situation 4 years ago. It may have improved since then.
That NONE of the car-makers were any better at the time. They were all as bad as each other.
However... the AutoCRC decided that this effort wasn't important in an Australian context. The local automotive electronics maker had just ceased trading, and any such research would be best conducted overseas.
I wonder if Toyota would be interested in re-starting the project? Or for that matter, anyone else? The thing is, that all the auto manufacturers keep such research a closely guarded trade secret. For all I know, it may already have been done.
From Breitbart:
Toyota Motor said Thursday it was staring at a two-billion-dollar hit from a global safety recall that has now spread to Britain and battered the credibility of the world's biggest carmaker.If they haven't... maybe they should, hmm?
Accelerator problems with its vehicles have tarnished Toyota's vaunted reliability record, raising questions about whether it sacrificed quality in its successful drive to overtake General Motors as the world's number one.
...
Members of the US Congress have scheduled hearings into Toyota's recall crisis, and want proof that the problems with the accelerator pedal are mechanical and not a more complex one related to electronics or software.
Apple co-founder Steve Wozniak said this week he believed Toyota's troubles with the defective accelerator might be linked to "some bad software" after his Prius sped up while in cruise-control. Related article: Toyota may have software trouble
Now new concerns are being raised about the brakes on the Prius, Toyota's flagship hybrid car which is in the vanguard of the company's push to produce a new generation of greener vehicles.
3 comments:
Interesting... I'm in the software side of medical devices (which is regulated), and we've taken a lot of ideas from the automotive industry... but we've taken more from their assembly line software, electronics, etc. (which is again regulated, if the regulations are mostly different) than their actual products.
Maybe they should do the same.
The problem with Toyota is not the obvious electronic problem but their refuseal to admit it. Fixing 8 million computers will bankrupt them.
Big companies use government regulation to force out the smaller competition. I hope that they are not considered too big to fail.
PJC
Zimbel - I once participated in a safety review of a new LASIK device.
I'm familiar with the various regulations involving medical devices here. The requirements for formal proof of correctness, for example.
I don't think enough emphasis is put on failure modes of operation, but otherwise they're as safe as we can make them.
Testing such failure modes is difficult though. With multiple lines of defence, when nothing you can predict would get through the first two lines, how do you test the other three? If you could figure out a way to do it, you'd modify the first or second lines to prevent it instead.
FedSat never did get an event that triggered line 3, before the end of its life. Much of the code was never executed. So we don't know if that works or not. It did in unit testing, but integration testing couldn't come up with a scenario that triggered it, not without deliberate changing of the rest of the code, thus invalidating the integration test.
Post a Comment