My conclusion is that the auto industry with regards to the computerization is following the road taken previously by the medical devices and aircraft industry. Following to the letter, meaning that they kill a critical mass of people until they are forced to adopt the quality control processes adequate to tasks the software is given.
For years they used a limited set of very specialized software developed for the basic engine control. There are fewer engine design entities than the automakers, and the software came even from a smaller pool of design outfits. So there were just few packages out there, very well tested. Then the innovation pace in automotive picked up. They added ABS to the mix (but this still usually is a dual-control system: foot-to-hydrolic + computer assist). The situation started to unravel with stability-control. Then came multimedia, GPS, infotaiment all done by people who never practised and frequently had no concept of safety-critical software design. In other words we will have cars driven by software designed by the same people who do the APPS ...
I was at a TI seminar yesterday which included a session on their Hercules micros and their SafeTI program. The Hercules processors are intended to address the safety market with dual processors executing in lock step along with error correcting memory and more. The presenter did imply that if this processsor had been used then the Toyota acceleration issue may have been avoided.
As cars become computers on wheels, maybe it's time for such discussions.
TI also briefly discussed the general safety standard IEC61508 and the Automotive one ISO 26262. So there are certainly standards and there must have been discussions behind them. I don't know about the Automotive one, but I have seen bits about IEC61508 and it does seem to cover all the current approaches that should be used to create safe equipment.
Time to market pressure is very demanding driving most designer and supply chain people crazy. Even before QA getting final 1.0 version or less full version, product launch dates are fixed. QA has very little option but to sign-off product with few remarks.
Another aspect is that product needs lot many test engineers as compare to what they have now. As we did simultaneous engineering as a new concept, simltaneous test engineering should be new emerging branch.
There are a ton of social media networks and public forums out there on the Web -- where many of us hang out and casually throw in our two cents.
But there are no others like EE Times' forum.
Here's the proof.
We compiled hundreds of messages posted -- scattered all over the places -- to a series of stories we wrote on Toyota's unintended acceleration case most recently tried in Oklahoma. These messages are smart, thoughtful and informative. And educational.
As a reporter, I must confess that every day, I learn just as much from reading our community members' comments. If you need to find out what engineers, responsible for making design choices every day, actually think about Toyota's unintended acceleration case, you can find it all in here. (and a lot more that we didn't have space to bring over to this comilation)
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.