Writing the unwritten: automotive software governance
Eric Jensen explores how huge improvements in vehicle software are leading to equally huge improvements in reliability, security and maintainability
Many of the everyday household devices and services needed to make the world go around are completely dependent on software. The efficiency, reliability, fitness for purpose and adaptability to new conditions of physical products depend on our methods for developing, debugging, maintaining, and most importantly securing the software embedded within them.
Software may be the lifeblood of devices, but with the rapid rise of their influence in our lives, and complexity of their operation, comes a need for greater visibility and control. A method of software governance must be defined and the requirement of such a method is to 21st-century technology what materials science and quality assurance practices were to 20th-century industrial activity.
The need for this software governance is nowhere more pressing than in the automotive industry. As vehicles become increasingly computerised, fitted with high-performance chips, processors and sensors to provide optimum driving experiences, they are also filled with software that controls all aspects of the vehicle. The exponential increase of software within modern vehicles has serious safety implications for us all, as any fault or vulnerability in the code could have dangerous consequences.
Product engineers, vehicle owners, regulators, and liability lawyers all have different but important interests in knowing what software is installed on which computers in each car, how it came to be there and who has modified or upgraded it. The alternative is chaos, which is largely the present condition of the industry.
“We stand on the verge of a transformative set of changes brought about by autopilot software capable of autonomously controlling some forms of ‘driving’.”
We stand on the verge of a transformative set of changes brought about by autopilot software capable of autonomously controlling some forms of ‘driving’. Even today, the automobile is already a constellation of computers and an ecology of software. Though currently designed for human operation and control, the modern car includes dozens of computers receiving input from hundreds of sensor devices, regulating everything from brakes to entertainment systems, all under the control of innumerable software components.
Some of these devices are embedded in components sold to the OEM by suppliers, who also provide all the software that those computers run; some are designed and placed in the vehicle by the OEM itself. Processors in both classes can be special-purpose machines, designed to run a narrow suite of software, as well as general-purpose processors like those in laptops or tablets running a conventional operating system. The hardware, running repertoires of software, is interconnected by diverse networking structures, ranging from analog switching over dedicated wires to wireless connections to the public mobile Internet.
There is no general systems-engineering discipline that governs this in-vehicle network. Subsystems as different as door locks and ignition systems may receive control signals from the same computer receiving wireless inputs from a key fob, for example. Passengers bring a myriad of devices into the their cars including phones, tablets and IoT devices that interface directly with the car’s on-board diagnostics (OBD) port. It is possible for these devices to be compromised, and through flaws in the vehicle security model, access can be gained to control systems such as steering or braking. This is a frightening prospect both for drivers and the public at large.
The vehicle’s connection to external networks potentially carries information crucial to collision-avoidance and traffic management, but is also capable of fundamentally compromising passengers’ privacy. Software modifications designed to protect passenger privacy should be enabled, while safety-critical uses of similar data must not be blocked or inhibited. In the near future, as ‘smart road’ technology increasingly appears on some, but not all, streets and motorways, the software environment of the automobile will be decisively affected, moment-to-moment, by the particular route on which it is traveling.
The complexity of this array of computers and networks demands powerful practices and mechanisms of software governance. However, there is a way forward. The pace of innovation in the automotive sector has accelerated to the point where it is only economically feasible to compete by using shared and open code.
The industry can benefit from the use of a software governance system based on ‘free and open source’ software (FOSS). FOSS is software produced and distributed under rules that give purchasers and users both the legal rights and technical enablements necessary to study, improve and share. FOSS has become the most important infrastructure basis for software over the last generation.
“The pace of innovation in the automotive sector has accelerated to the point where it is only economically feasible to compete by using shared and open code.”
In the automotive software environment, new technical capabilities in FOSS packaging can help to guarantee manufacturers’, owners’ and regulators’ precise knowledge of which version of what software is installed and operating in any vehicle at any moment. It can enable efficient, secure and reliable updates to be performed ‘over the air’ or offline; limit the access rights of individual software components with precise granularity; determine who has serviced or modified that software; restore erroneously or incompletely modified software to a known, reliable state; and even install or revert software upgrades and fixes during vehicle operation.
One example of software packing that can enable effective software governance is called ‘snaps’. Snaps encapsulate an application program and all its dependencies, both the libraries it links to and the static data and configuration files it requires to execute, in a compressed, read-only file system. Once installed, the code and data representing the application cannot be changed. An entire system, consisting of a ‘kernel snap’ for the OS kernel, a ‘core snap’ for basic system facilities, and a series of application programs can thus be ‘snapped together’ to create a device in a verifiable base state, guaranteed to remain uncorrupted and uninvaded by malware throughout its installed life.
The issue of software governance in automobiles represents the leading edge of similar issues throughout society, as the automotive industry once again explores the frontiers of technology and powers social change. In many cases, however, today’s method of software governance is insufficient. When the method is to govern software interactions by using only non-FOSS software and exercising control over the entire in-vehicle network, the benefits of user innovation are stifled, and the security of the network cannot be independently verified.
“If we ignore the need for software governance, the result can be a dangerously insecure and unstable in-vehicle network”
If we ignore the need for software governance, the result can be a dangerously insecure and unstable in-vehicle network. Simple changes in how software for cars is packaged and distributed can make an enormous difference in increasing reliability, security and maintainability of vehicles, and in providing for valuable forms of user innovation, through tinkering, adaptation and improvement.
Eric Jensen is Head of IoT Product Development at Canonical - the company behind Ubuntu