Jalopnik.com reported over the weekend that one of Google’s self-driving cars was involved in a fender bender near the company’s Mountain View headquarters last week. The article includes a photo of the Google self-driving Toyota Prius stopped behind another Prius with several people and a police officer standing around the two cars. Four cars were reportedly involved in the collision. Google told BusinessInsider.com that a person was driving the Google vehicle at the time of the accident. However, the incident serves as a strong and clear reminder that apps and software development can have far-ranging consequences.
Now it’s pretty easy to see the liability issues surrounding a self-driving-car app. This four-car collision, whether caused by the app or a human driver, reminds us that apps and software now permeate everything we do in this world and some of our activities can definitely and deeply affect the lives of others. Yet there’s no denying that a lot of software is developed as though we were still in the 1970s. A lot of software development looks more like quilting than engineering. With a communal quilt, several quilters get together, sew their pieces of the quilt, and then the whole quilt is assembled from those pieces. Engineering development should look more rigorous than a quilting bee, with clear requirements, testing at each development stage, and measurable results from code reviews and bug fixes. (For more in-depth coverage of better firmware development, be sure to take a look—a long look—at Jack Ganssle’s web site www.ganssle.com.)
Now Google isn’t the only company working on the knotty problems of autonomous vehicles. Last April, Byron Shaw who is Managing Director of Advanced Technology at General Motors of Silicon Valley, spoke about such vehicles at the IDC Smart Technology Conference held in San Francisco. (See “Future cars: The word from GM at IDC’s Smart Technology World conference”) During his speech, Shaw said that to make cars that won’t crash, you need drivers that don’t get distracted or fall asleep. Computers can do that, but can we make software that’s so good it won’t ever crash a car?
The short answer is “no.” In the history of engineering, we’ve never engineered bridges that never fall down, skyscrapers that never collapse, and planes that never fall out of the sky. We cannot engineer perfect artifacts in any engineering discipline. But we can make things a lot better by adding and enforcing engineering rigor to projects. That’s why most bridges stay up. That’s why aircraft can now routinely land themselves using software. That’s why rockets break the bounds of the earth running software. That’s why medical diagnostic machines deliver imagery worthy of science fiction stories from only 50 years ago without cooking the patient with radiation—with a heavy dose of software. We can make good stuff when driven to do so.
However, real software engineering for embedded systems is going to require a bigger commitment to engineering tools than we’ve presently got. That’s the basis behind the idea of System Realization contained within EDA360 and it’s the reason Cadence rolled out the System Development Suite earlier this year.
The software content in all manner of products is staggering at this point. With multiple processors on every SoC in both heterogeneous and homogeneous configurations, stitching together big chunks of software must transcend the quilting-bee level. Advanced software-development tools such as the Cadence Virtual System Platform will be a key tool in the battle to improve software quality.
Keep the shiny side up and the dirty side down.