Library
Related Items
| Making Automotive Software Safe |
|
|
|
| Written by Bob Chabot | |||||||||||||||
| Wednesday, 12 May 2010 00:00 | |||||||||||||||
|
Automobiles today can have a hundred or more onboard computers spread across many integrated systems. Besides the mechanical and electronic hardware involved, there are thousands of electronic circuits and millions of lines of software code to develop, run, monitor, debug and safeguard. Should we be worried about the vehicles we drive? Software's Gone Viral According to leading automotive information technology (IT) and software engineering firms, such as the Fraunhofer Institute for Experimental Software Engineering (IESE), Horst-Gortz Institute and Robert Bosch GmbH, software is expected to continue to permeate vehicle systems. They say the cost of embedded IT content and associated electronics will exceed 50 percent of new car manufacturing costs by 2015.
A number of factors are driving these innovations: time to market reduction, cost optimization, quality improvement, safety conformance, passenger comfort, performance, environmental regulation compliance and vehicle intra- and interconnectivity. While they add functionality, they also increase complexity on embedded systems, as well as the need to ensure their security. Autmotive IT — the sofware, hardware, embedded hardware and firmware — monitors and manages vehicle systems. It must be robust, reliable and safe; hence, they are tested for mechanical, electrical, electromagnetic radiation, vibration and other sources of failure. Every few milliseconds, control software logic analyzes hundreds of inputs from the systems they monitor. Software quality must to be part of the design One metric that measures the size and complexity of a software program is 'source lines of code' (SLOC). Manfred Broy, a leading expert on automotive software and a professor at the Department of Informatics at the Technical University of Munich, Germany, offers these reference points:
Recent innovation now enables any automotive hardware to be virtually cloned. This enables software developers to write automotive software code — from operating systems to device drivers to interrupt handlers to application programs — without any real hardware being in place. As a result, programmers today have to debug and test software code, for both hardware and software. The increased workload and time-to-market pressures is not a good mix. "Fixing failures means first finding them," notes Jim Turley, an independent technology analyst and former editor of Embedded Systems Design and Microprocessor Report. Software developers spend nearly 40 percent of their time debugging (what we call that reprogramming) — more than any other task, be it programming, writing specifications or engineering. The challenge is finding software errors in the midst of millions of lines of code before vehicles are ever sold, or as soon as possible afterwards. "Debugging is equal parts art and science: The science is knowing how to fix flaws, while the art is knowing where to look," Turley adds. IT security often lags software development and release "During the past 10 years, the number of automaker recalls has quadrupled," says Dieter Rombach, director of Fraunhofer IESE. He insists that software integrity — from design to reliable, safe functionality in the marketplace — is critical to the industry's success. "Electronic systems and software are the major causes of this." He cites several drivers for this: Rising new vehicle values; high replacement expense associated with easily stolen or counterfeited components and systems; warranty issues from undetected post-sale chip-tuning and other unauthorized software modifications of vehicle functions; growing concern for privacy and in-car data protection; and emerging new business revenue opportunities that add more wireless vehicle functionality. Like tother industries, IT security within automotive domain has unfortunately lagged product launches. Rombach, Paar and others in the IT security field insist that much of the software and hardware in current cars has yet to be adequately protected against serious threats, such as manipulation, malfunction or malicious attacks. Potential attackers include those who have physical or remote access to an automotive device. They focus on trying to identify the secret encryption key, either by direct or indirect methods. Once knowledge of the key is obtained, the device can then be readily manipulated and/or cloned. Sadly, attackers all too often turn out to be vehicle owners, maintenance personnel, competitors and other organizations that dishonestly and illegitimately monitor and/or modify functionality for personal gain. Direct attacks, such as reverse engineering, attempt to read the cryptographic keys directly from the embedded device's various memories. Unlike conventional automotive reverse engineering, the recovery of just a single cryptographic key — only 16 bytes long or less — is often all that is needed to be successful.
It's like finding a needle in a mulitdimensional haystack The development of strong embedded security solutions is not an easy road to travel. Automotive IT and security design face computational, memory limits, cost and other tight constraints. The manufacturing supply chain — OEMs and their multiple layers of suppliers and toolmakers — requires an efficient exchange of design information, as each has implications that must be factored in. For example, who designs the security architecture and most importantly, who has control over the cryptographic keys and other IT security measures become very relevant. In addition, differences between automakers, proprietary boundaries, cumulative tolerance stack-up of assembled components and extreme operating environments challenge progress. IT security design also differs fundamentally from the engineering of most other technical automotive systems. In conventional automotive systems, a single non-optimum component will not normally invalidate the entire system. For software and IT security solutions, design integrity across and between systems is crucial. A single, seemingly minor flaw in IT security system design — a single line of software code out of the millions of lines in today's automobiles — might not affect the local system. But if not identified before or after launch, that bug could then render programming or security solutions in interconnected systems or controllers insecure, unreliable or worse. Shifting mindsets: Open standards can build safer systems Toyota's approach is typical of many automakers. "We take a holistic approach, looking at standards for whatever regional locations that we're in, as well as any international standards that may exist," says Kristen Tabar, general manager for Electronic System 2 Department at the Toyota Technical Center. "In cases where those standards or regulations are lacking, we even go beyond that and create our own test standards, based on our know-how or experience in the real world environment that the vehicle will see."
Standards are poised to play a significant role in the evolution of automotive functionality and vehicle-to-vehicle connectivity. While comprehensive, global software standards and security processes do not yet exist across the board for automakers in any country, let alone on a global scale, the momentum is building. Manufacturing, servicing, monitoring by regulators (for compliance and public safety purposes) and consumers all stand to benefit. If automotive source code was open and available to anyone, leveraging open source software for both vehicle development and IT security would enable the collective community to assist in discovering bugs, augmenting the efforts and expertise of the much smaller population of automaker and other personnel currently on the watch. In addition, open standards would enable software to operate across different OEM platforms. Granted, sharing what some OEMs currently consider to be proprietary intellectual property with competitors would require a change in mindsets, but the collaboration would reduce development costs for common software applications for all, as well as those downstream. Importantly, IT security measures would still provide the necessary protections and safeguards. Inviting, responding to and incorporating user experience (UX) into the design equation is another change agent that is beginning to gain traction. Looking at software and security issues from a UX point-of-view, rather than just from the vehicle system's viewpoint, addresses an obvious design gap: It is human operators that interact with vehicle sensors, actuators and computer modules. At best, even if software systems and security reliability were to approach being 100 percent error-free, perfection would remain unreachable. Despite all the automatic mechanical, electronic and other fail-safes built into systems, people are the ultimate backup. Proponents say that integrating how people behave in real-world situations into design would go a long ways to realizing safer and more reliable performance. While average or even a range of typical behaviors can be designed in, it is the exceptions outside the norms that are more difficult to account for and manage. "Providing failure safety in electrical and electronic automotive systems is the greatest challenge for automotive developers in this decade," Rombach stresses. Software will continue to become increasingly complex and require continual updates. The wireless Web, ongoing electrification of the automobile and changing software universe will continue to have far-reaching implications on vehicles and those who build and maintain them. Already we are seeing the spectre that could ensue. "Many recalls today are software related," he continues. "That trend will continue unabated in coming years unless we act now." (Editor's Note: Bob Chabot is a freelance writer, editor and e-producer for Techs4Tomorrow, MOTOR Magazine, AutoInc., NASTF and other custom publications.)
|
Polls
NASTF Information





CARCHITECTURE



