The embedded electronics and software content of automobiles is exploding. In order to keep up with this and meet time-to-market and safety requirements, manufacturers are embracing standards.
BY TOM WILLIAMS, EDITOR-IN-CHIEF
There are big changes happening in the automotive world that involve embedded systems and software. Of course, it’s not as if we are suddenly seeing microcontrollers in cars; they have, of course, been there for quite some time. They are in engine control, transmissions, braking systems, airbags and in all manner of “infotainment” systems and devices. For the most part, automobile manufacturers have treated these systems as internal, proprietary projects and that will continue at least partially for some aspects of vehicle design.
However, the proliferation of embedded control is accelerating to the point where considerations of cost, time- to-market, reliability and primarily safety are forcing a reevaluation of just how all these control systems will be designed into vehicles in the future. According to Jim McElroy, VP of Marketing of LDRA, some of today’s higher-end vehicles now have up to 100 electronic control units (ECUs) with huge numbers of sensors throughout the vehicle. These types of systems, McElroy says, “are leading to applications where there are actually more lines of code in some vehicles than there might be in an airplane.” It’s getting to the point where practically any function you can think of in a car—seat modules, power windows, and more—are under software control.
With such growth in sheer volume of code and complexity, automobile manufacturers are moving away from complete in-house proprietary development and turning to suppliers who can furnish the components they need. Not only is there an increasing need for ready-built components; there is also a vital need for component-based systems that are certified for reliability and above all for safety. Manufacturers simply cannot afford massive recalls such as those that have happened recently and which have been all over the press.
This is leading to systems that are developed in a more component-based systems approach, which means that there must be certain standards under which such components can be assembled into systems. One such emerging standard, which can be used as an example of how this trend is developing can be seen in the AUTomotive Open System Architecture (AUTOSAR). While AUTOSAR is far from universally adopted, its goals indicate the direction of embedded development for vehicles. It is aimed at establishing and infrastructure with reusable components and interfaces between functional modules such that multiple suppliers can offer products and services in a known environment.
The idea is that code can be developed as pieces of low-level functionality that, thanks to their standard interfaces, can be moved or placed in different ECUs depending on such things as performance requirements and the availability of performance in individual processors. While ECUs were originally designed with regard to their target functions, that is now changing so that with standards like AUTOSAR, this low-level functionality can be put in virtually any processing unit within the vehicle. Low-level function modules can then be aggregated into much more complex high-level applications.
Such a model, then, will require effective data communication between functional modules that is independent of the physical locations of the sensors, actuators and the software modules in the vehicle. AUTOSAR itself does not seem to define the actual bus or communications technology. It can be CAN bus or FlexRay or possibly the Media Oriented Systems Transport (MOST). The AUTOSAR runtime environment (RTE) does specify a virtual function bus (VFB), which presumably can be implemented on a choice of physical media. The advantage of the VFB is that it allows designers to put together a vehicle system without thinking in terms of ECUs. They assemble a collection of functional software components that due to the addressing scheme can accept sensor data and output control commands regardless of their actual location. The actual implementation of the communication bus depends on the manufacturer.
The emergence of standards comes from the need to develop functionally safe software and manufacturers want their suppliers to adhere to standards so that their software can be certified as both functional and safe and avoid recalls. One important standard that is gaining widespread usage is a functional safety standard for road vehicles ISO 29292. This standard defines functional safety for the life cycle of all automotive electronic and electrical equipment using an automotive-based risk assessment for determining risk classes or automotive safety integrity levels (ASILs).
LDRA is a supplier of static and dynamic analysis tools (Figure 1) that target automotive software development by tracking risk-based requirements to the ISO 26262 objectives to develop code that can be certified functionally safe. In addition to 26262 compliance, the tools can also check compliance to automotive coding standards like the Motor Industry Software Reliability Association (MISRA) specifications for C programming. It can further check for compliance with any manufacturer-defined coding requirements. Certified compliance not only ensures safety but also code portability between suppliers and different OEMs.
A comprehensive set of tools is used to input the requirements from standards-generated documents so they can be used to trace to their correct implementation in code as well as to generate test scenarios at all levels.
According to LDRA’s McElroy, “If they already have guidelines in place, we help them with static analysis capability to combine their own standards with potentially the MISRA standard or some other industry standard.” The software requirements for code development are generated from the risk analysis and are checked and called out during the static analysis.
ISO 26262 recommends a certain coverage level dependent on the risk of a particular software component within the system. This can be coordinated with the Automotive Safety Integrity Level (ASIL) classification. ASIL risk levels are assigned on the basis of the severity of possible injuries, the relative frequency of operation in which such injuries can occur and the controllability of the conditions, such as a driver’s ability to control them to prevent injury. The highest level is a combination of all these factors and is called ASIL D. Such a classification will require modified condition decision coverage (MCDC) and will require the most extensive coverage and testing.
Using LDRA’s unit and integration process, developers can verify the application as they are building it and can automatically generate test cases for the units that go into the vehicle. As they exercise test cases on components and components become aggregated into applications further test cases can be generated for those levels. Testing can be carried out on the host development system and in a simulator as well as on the target hardware using the same test cases.
As embedded automotive systems become more complex and pervasive, the push is to make them more modular and more adherent to standards. In that trend, there is also a push to make development and modeling tools more applicable over the different stages of development and system integration. All this is driven by the pressures of cost, time-to-market and the need for safety and reliability to avoid recalls.
Standards such as ISO 26262, AUTOSAR and MOST are becoming ever more attractive, although the latter two are not yet universally used. Nonetheless, AUTOSAR, driven by a number of European countries, is finding its way into the US. For compelling economic reasons, auto manufacturers increasingly find themselves cooperating on standards for safety, security and reliability while still competing on the implementation and creativity of their applications, which not only define the vehicle’s safety but also the driver experience.
An additional advantage is maintainability and upgradeability to enhance the driver experience. As a small example, a car has pressure sensors in each tire and when one senses low pressure it can turn on a symbol on the dashboard. But since each tire already has a sensor, the addition of an additional function component or (more likely) turning on a software switch for a fee could enable components already present to display the current pressure in each tire. So choices of options made at purchase could be easily supplied without delay.
As standards in automotive software become more established, we can expect to see added user experience in all aspects—basic functionality, safety, comfort and infotainment. Still in the distance is the driverless car, which some say is definitely coming but which others wish would not. But that’s a different topic.