A software problem in the Autopilot of an electric Tesla S automobile has resulted in the first fatality attributed to a driverless vehicle. Apparently the public beta version of the technology failed to distinguish between an oncoming white semi that made a left turn across the road and open space. The car continued on course and the driver was killed instantly. Like nothing else, this tragic incident shows how critical software has become in the modern automobile.
While the driverless car is obviously not yet perfected, today’s automobiles contain vast amounts of software, much of which is already critical to safety and all of which must work reliably. Software now controls everything from engine elements to driver alerts for staying in the lane, passing, and safe distance following, to opening and closing windows, to entertainment systems.
Software also controls outside communication such as Bluetooth for hands-free telephone and connecting to the Internet. Any Internet connection raises serious security concerns, especially when it can grant access to vital systems in a moving car. For instance, in 2012, the GM OnStar system built into its vehicles was used at the request of police to shut down a stolen car as it was being pursued. If the police can break into a car, so can thieves and other hackers. In order to assure safety and reliability, it has become clear that automotive code must also be secure from outside tampering.
Of course, the automobile industry is huge, with many manufacturers of vehicles and the components and subsystems that are built into cars, many of which are supplied by third-party developers. As more subsystems that formerly contained no software—such as rolling the windows up and down—are now controlled by embedded code, a new paradox has arisen. These third-party and peripheral devices must have standards for a common interface so that they can communicate within the vehicle. At the same time, they must be secure