Page 50

EETE JAN 2014

Safe and secure at any speed? By Robert Dewar Four technology trends have come together to make the challenge of building safe cars more and more difficult. Embedded processors are now so inexpensive that software is taking over functions such as braking, which were once achieved solely by mechanical means. We expect cars to do more and more on their own. GPS systems, adaptive cruise control, lane following, and automatic parallel parking are features found on many high-end cars today. We are moving towards more sophisticated power systems, including fully electric cars and hybrid engines that require more elaborate control systems. We have to worry about security as well as safety. Any system where a bug can cause loss of life can potentially be hacked to deliberately cause such an accident. As a result of these trends, modern cars contain an extraordinary amount of on-board software. Published figures suggest for “How do we go about developing software that we can trust to not create hazardous conditions?” example that the Chevy Volt has more lines of embedded code than the advanced Boeing 787 “Dreamliner”. And like the software on an airplane, automotive systems are safety critical: an error can directly cause serious accidents. Unfortunately, news of software-related problems is starting to emerge; for example the recall of the 2013 Buick LaCrosse and Cadillac SRX because of unexpected transmission shifts. Of course automobile manufacturers are hardly eager to publicize such things, so there may be many more issues that we don’t know about. So what should be done? First, we should not be too pessimistic. The experience from other safety-critical domains, such as avionics systems, is rather impressive: no one has died as a result of a software implementation bug on a commercial plane. How was this achieved? By the rigorous application of well understood standards for the development of critical software (in the case of avionics, the relevant standard is DO-178B, now being replaced by DO-178C), and the “safety culture” ethic that has characterized the aviation industry since its inception. Analogously, you might presume that automotive software is subject to satisfying the requirements of a comparable rigorous standard. Well if you presume that, you will be disappointed. Automotive software is developed by the manufacturers or their suppliers, and, somewhat surprisingly, no meaningful external standards are imposed to certify the resulting systems. The software is regarded as strictly proprietary, and no external party can examine it closely to understand what it is doing. This may seem a bit shocking, but it’s not so easy to impose such external standards. So how do we go about developing safe software – i.e., software that we can trust to not create hazardous conditions? In the case of avionics, DO-178B calls for (among other things) a well-defined set of verification activities, with a focus on testing, to make sure the software satisfies its requirements. But is rigorous testing enough? Not when it comes to security. I recently saw a rather frightening demonstration where a CD was inserted into the CD player of a current production car. It played beautiful music, but as a side effect totally disabled the steering wheel. Now that Wifi and Bluetooth connections provide additional entry points to the software of a car, we need to be able to demonstrate that automotive systems are immune to this kind of hacking. Testing can never convince us that systems are secure; we can’t try every possible attack that anyone will think up in the future. Instead, we have to demonstrate with confidence that the software contains no vulnerabilities that could be exploited to create a safety hazard. This can only be achieved by the use of formal methods, which allow us to prove, with mathematical rigor, important properties of a program. The ability to prove individual properties is achievable today, partly because of better software and proof technologies, and partly because of the enormous computing power available for running automated proof systems. Programming languages play an important role here. Robert Dewar is President of AdaCore – www.adacore.com Publisher André Rousselot +32 27400053 andre.rousselot@eetimes.be Editor-in-Chief Julien Happich +33 169819476 julien.happich@eetimes.be EDITORS Nick Flaherty +44 7710236368 nick.flaherty@eetimes.be Christoph Hammerschmidt +49 8944450209 chammerschmidt@gmx.net Peter Clarke +44 776 786 55 93 peter.clarke@eetimes.be Paul Buckley +44 1962866460 paul@activewords.co.uk Jean-Pierre Joosting +44 7800548133 jean-pierre.joosting@eetimes.be Circulation & Finance Luc Desimpel luc.desimpel@eetimes.be Advertising Production & Reprints Lydia Gijsegom lydia.gijsegom@eetimes.be Art Manager Jean-Paul Speliers Acounting Ricardo Pinto Ferreira Regional Advertising Representatives Contact information at: http://www.electronics-eetimes.com/en/ about/sales-contacts.html European Business Press SA 7 Avenue Reine Astrid 1310 La Hulpe Tel: +32 (0)2 740 00 50 european Fax: +32 (0)2 740 00 59 business press www.electronics-eetimes.com VAT Registration: BE 461.357.437 RPM: Brussels Company Number: 0461357437 © 2014 E.B.P. SA ELECTRONIC ENGINEERING TIMES EUROPE is published 11 times in 2014 by European Business Press SA, 7 Avenue Reine Astrid, 1310 La Hulpe, Belgium Tel: +32-2-740 00 50 Fax: +32-2-740 00 59 email: info@eetimes.be. VAT Registration: BE 461.357.437. RPM: Nivelles. Volume 16, Issue 1 EE Times P 304128 It is is free to qualified engineers and managers involved in engineering decisions – see: http://www.electronics-eetimes.com/subscribe Copyright 2014 by European Business Press SA. All rights reserved. P 304128 50 Electronic Engineering Times Europe January 2014 www.electronics-eetimes.com


EETE JAN 2014
To see the actual publication please follow the link above