Embedded Control Systems Design/Automotive

Introduction

For the design of embedded automotive systems, the entire vehicle system is usually split up into four different functional areas, which could be separated during the design phase:

• Chassis
• Drive-train
• Body
• Telematics

Each of these areas will have different priorities and requirements and these areas will usually also be covered by different design teams. It is important to point out that whereas these areas where completely separated in the past, new functions and legislations are forcing these different areas to communicate with each other. The design requirements for these areas are very different and it is crucial to make the distinction between the requirements due to legislation and those due to competition. A lot of the demands for the drive-train and body (passive safety) areas will be due to legislation, and can thus be considered as hard constraint. Many of the requirements for chassis and telematics on the other hand are due to manufacturer-competition and offer more design-freedom.

System requirements

This section will not elaborate on the different functional requirements of all the different vehicle-systems. Rather an overview of the most important system level requirements of the vehicle will be given and how this affects the requirements of the embedded control systems:

• Safety

The demand for safety will impose some important functional and non-functional constraints on the embedded systems of the drive-train and chassis. These demands aren’t usually driven by legislation but by competition between manufacturers.

• • Hard real-time constraints: it is imperative that all safety related systems comply to real-time constraints. Systems like ABS should be able to react within mere milliseconds to ensure a timely intervention. This not only puts a constraint on the processors-speed, but also on the speed of the communication system used throughout the car, because these systems often rely on input signals from other systems and need to send outputs to different systems as well (e.g. ESC-system must communicate with engine management).
  • Fault-detection: every sub-system of a safety-critical function should be capable of auto-diagnosing of its function and should be able to switch to a safe shutdown condition in case of failure. Obviously also the communication system should be able to perform data-transfer checks. Legislation dictates that if a fault is detected, this should also be shown to the driver (MIL Malfunction Indicator Lamp) and be stored in the fault-memory of the controller.
  • Redundancy: critical sensors, like the throttle in drive-by-wire systems, should have redundancy to minimize malfunction probability.
  • Reset-time? Start-up-time?

• Cost

As in all industries manufacturing cost is also very important in automotive.

• Emissions / fuel-economy

The main driver behind emissions-constraints has always been legislation, even though more recently fuel-economy has become an increasingly more important sales-argument. A very important aspect of this legislation is the On-board diagnostics (OBD), which monitors the engine-system continuously to ensure compliance with emission-laws in everyday use. Some of the most important demands for the drive-train-system are:

• • Monitoring of emission-related electrical components (e.g. short-circuits) and storage of fault (OBD 1).
  • Monitoring of system functionality (e.g. plausibility check of sensor-signals) (OBD 2)
  • Components used to monitor emission-related components of which affect diagnosis must be monitored. (OBD 2)
  • Monitoring frequency is usually prescribed by law.
  • Malfunctioning must be displayed to the driver by MILs (Malfunction Indication Light).

• Time to market

Drive for shorter time to market pushes the system development towards more interchangeable components. This is currently very difficult because there are no clear communication standards. Bus-communication systems have made it a lot easier to introduce new functionalities into existing systems.

• Passenger comfort

Passenger comfort is also very important in automotive due to competitive reasons. These requirements mostly apply to systems in the interior and telematics area. This gives also some constraints on the embedded systems:

• • Soft real-time constraints: many non-critical systems (e.g. electric windows, electric mirrors...) have prescribed timing constraints, but violating these constraints doesn’t have serious effect. A lot of these systems for example have to react within 100ms, with is the limit of delays a human can perceive.

Design process

Embedded systems in automotive usually follow a model-driven design workflow (as introduced in section The design process ).

Functional requirements should generally be taken into account during the functional design stage. This also includes fail-safe modes.

The timing constraints should be taken into account during the implementation stage. It is very important to make sure the hardware is capable of reaching the timing constraints, but is not to performant either. Also the demands for the communication-speed should be taken into account during this phase. If the communication-speed is very critical it might even be necessary to include a detailed model of the communication network in the original vehicle model. All the monitoring functions for hardware malfunctioning can only be designed during this stage as well. Crucial functions that have to meet real-time constraints will usually require their own hardware to assure real-time operation, so this is a constraint that should be taken into account from the start of the design. This might be very difficult in practice.

A very important design-phase is the configuration of the communication between the different vehicle-systems. Due to the ever increasing amount of signals and lack of standardization this is currently very time-consuming. The AUTOSAR standard is meant to strongly facilitate this stage.

Hardware

Originally, cars were equipped with single signal cables. As electronic systems increased in number and complexity, this approach was no longer acceptable due to cost, weight and complexity. This is why manufactures have switched to bus-systems (e.g. CAN-bus) for in-car communication between the different systems. There are usually several buses in one vehicle, each system adapted to the speed demands of particular system-groups. More information on these bus-systems can be found in the chapter on field-buses.

Most functionalities are currently programmed in a microcontroller with program memory (EPROM or flash ). Due to the wide array of functionalities, there is a wide range of sensors in modern cars. Sensors on safety-critical components (like ESP-sensor) are required to have internal self-monitoring functions as well.

Autosar

Present Problems

Current vehicular systems are characterized by proprietary solutions: applications in different vehicular systems use other interfaces or other communication standards. This leads to suppliers that develop and maintain separate software for each system instead of using the same software on every system and dealing with compatibility issues of communication, function and signal definitions.

OEMs have the task of integrating the different systems and guaranteeing the deterministic functioning of the integrated system. This task is often burdened by the different diagnostic services for applications of different suppliers. With the growth in the number of embedded control systems and the degree of interaction, further proliferation of proprietary solutions will require more resources and it will become more difficult to guarantee the deterministic functioning of the integrated system.

There is also a trend to more flexibility for the customers; customers want to chose from different options. This leads to many small variations of one basic vehicular system, which requires a lot of design effort in modern systems with a low level of modularity and implementation-flexibility.

To cope with these problems, automobile manufacturers, suppliers and tool developers have joined forces to develop a new standard. This project is named Autosar, which is an acronym for AUTomotive Open System Architecture. On the Wikipedia article of Autosar, the goals and technical information of Autosar are explained.

The Autosar Standard

The Autosar standard is meant to be a breakthrough that should allow a paradigm shift in vehicular system design and should lead to improvement of functionalities and higher safety.

Terminology

The Autosar project introduces its own terminology, which shall be used throughout the rest of this text. More information can be found on the Wikipedia article of Autosar.

Autosar Methodology: a 4-step methodology that can be used to create the vehicular system architecture starting from the design-model.

Basic software: Standardized software that doesn’t has any functionalities that are noticeable to the end-user but offers hardware-dependent and hardware-independent services.

Runtime environment: implementation of the possible communication paths on a software level.

Application software: The software that implements the actual functionalities, which are noticeable for the end-users.

Analysis of the Standard

Reusability

The Autosar project has chosen to standardize the communication and the non-functional software, such as the runtime environment and the basic software. The functional software, namely the application software, is only standardized by its interfaces.

This has several implications:

• OEMs can build a vehicular system by choosing the best soft- and hardware for each specific application, without having compatibility problems. This means that the integration cost decreases. In addition, maintenance is easier to execute because the diagnostic services can be standardized for all application instead of being supplier dependent.

• Suppliers can still compete on implementation of the application software components. This should lead to better components. Also because of the clear interfaces, suppliers can build, debug, and maintain one version of their application software for all the different vehicular systems, which reduces proliferation of software. Due to the clear interfaces, there is also more option to partition development between suppliers or between teams of a supplier.

• Hardware suppliers can still compete on the best hardware, only the basic software necessary to use the hardware will be standardized, but there will be options to protect specific software (for example special software to cancel non-linear effect of actuators).

• New companies can easily enter the market because of the clear set domains. A company should only be an expert on his domain.

Safety

To raise the safety of a vehicular system designed according to the Autosar standards, several safety measures are included^[1].

• Safety Integrity Functions, which are safety measures to be present in AUTOSAR, independent of the application context. These functions support the correct execution of application functions and safety functions. In general, the functions are related to protection of resources, monitoring, and self-testing. Extra safety measures of this category need to be taken due to the change in system complexity. For example, if two applications can use the same resources and share memory, it will be necessary to build in some safety; for example to prevent write access to data segments of other applications.^[2].

• Support of Safety Functions that are dependent on the application context. This means the support of typical safety functions of systems from the different applications, like a fast reset for critical applications.

• General Safety Requirements like local detection of faults without propagation.

Safety features can automatically be added to all vehicular software, which is a big advantage over the existing approach to vehicular software design.

The clear set of standards and interfaces reduces the chance of faults due to wrong interaction between applications.

Design in Autosar

Component based design

The Autosar project introduces the concept of component based software design in vehicular software design. This is a necessary change due to the growing complexity of the vehicular systems, which leads to a need for teamwork.

• In component-based design, it is clear what each component should do, so the design can easily be divided over different teams. In addition, the interfaces are standardized which guarantees consistency in data exchange.

• The meta-model simplifies teamwork. The formal description of the vehicular systems makes sure that the structure of the information can clearly be visualized and that consistency of the information is guaranteed.

• Component-based software design facilitates the use of model-based design. Thus the use of model-based design, which is a current standard in vehicular system design, can be expanded.

• Component-based design shifts automotive software development from an ECU-based approach to a function-based approach and makes it possible to write application software independent of the used ECU.

The four fundamental "concerns" of system design

Due to the increasing complexity of vehicular systems, there is a need to explicitly control the interaction process instead of implicit definition of the interaction embedded in the different subsystems itself.

In this context, the concept of the four fundamental "concerns" of system design is introduced. These represent the different layers in the interaction-process.

Explicit layers facilitate the design of vehicular systems due to the better overview of the interaction process. Especially changes in the vehicular system, which requires changes in coordination, are more straightforward.

• Communication depends on the used protocols, interfaces and agreements about data exchange formats. This is specified in the standard.

• Computation depends on the application software components.

• Configuration is dependent on the system designer and the used tool-chains for the methodology. The system designer designs the physical topology of the ECU-network and decides which applications he wants to add to the vehicular system. When following the methodology, the optimization algorithm in the selected tool-chain determines the distribution of the different application over the different ECU’s.

• Coordination is specified in the runtime environment. The runtime environment is the implementation of the configuration, has the possibility to manage both inter- and intra-ECU communication and can call the different applications to handle communication at their communication ports.

The application software only affects the computation step and is therefore not aware of the computation and configuration layers. This makes it possible to create application software that is unaware of the number of interaction partners. In this way, there is a clear separation between the communication and functionality.

The explicit control of interaction makes it possible to add applications to the vehicular system without the need to change some of the application software that interacts with the new application. The necessary changes are situated in the run time environment, which is automatically adjusted in the ECU-configuration step when using the Autosar methodology.

Influence on system complexity

The AUTOSAR-standards also change the complexity of the vehicular system. Modern vehicle are of the type distributed hardware distributed software.

AUTOSAR sees the system as different applications running on one virtual platform. The standards make it possible to translate the virtual platform to a real implementation on the different ECU’s, where it is possible that some applications run on the same ECU. This methodology paves the way for a shift to systems with distributed hardware – central software.

This new model of a vehicle system has some implications for the safety.

The sharing of ECU’s is also necessary from a practical point of view. The number of embedded control systems in vehicles keeps rising, but the number of ECU’s in vehicles is reaching a limit. The cost is too high and the space in vehicles is limited. With Virtualization tools, as provided by AUTOSAR, there are possibilities to strictly separate functions on an ECU without loss of safety. This can open the path to less (but more powerful) ECU’s^[3].

Practical Aspects

OEM’s

The Autosar standardization is a severe change in approach of a vehicular system design. This makes it difficult to adapt an existing vehicular system to an Autosar compatible architecture. According to the roll out plan of the Autosar Core Partners, the OEM’s will not switch to an Autosar compatible system in one day, but they will start with the integration of one Autosar compatible ECU for one of the big subsystems (verwijzing) in a classically designed E/E-architecture. In this way, experience can be built, then an entire subsystem and eventually the entire vehicular-system can become Autosar compatible^[4].

Suppliers

The lack of existing Autosar compatible vehicular systems makes it difficult for suppliers to test new components that are supposed to be Autosar compatible. To tackle this problem, some companies group together in projects to generate an Autosar compatible test bench where the different companies can test their soft- and hardware. An example is the SWAP-project, where eight Swedish companies with the necessary and complementing competence to design a professional test bench, have joined forces^[5].

The future

Looking further in the future, these trends seem to continue. Cybercars or driverless cars for example need to know the state of the whole vehicle to control the vehicle in an optimal way. This can only happen when there is central software.

In the far future, there might be a trend toward communication between cars and between cars and road infrastructure.

An example is a fleet of cybercars. A fleet of such vehicles forms a managed transportation system, for passengers or goods, on a network of roads with on-demand and door-to-door capability^[6]. This kind of system belongs to the class of ‘distributed hardware – central software’. The fleet problems concern essentially the following elements^[7]: - vehicle allocation to a particular demand, - vehicle relocation after a trip, - deadlock avoidance, - demand management and fare collection, - distributed versus central management, - communication architecture.

Instead of a fleet of cars which are controlled by a central management system, one can imagine that there will also be a quest for autonomous cars who only communicate with their surroundings and possible a central system to gather traffic information. This car can then decide autonomous what action he should undertake.

Experiments in this area are currently conducted by Mercedes-Benz. Their engineers are working on a system called "Interactive Vehicle Communication" which allows cars to communicate with one another. The current status of their research is shown in their concept car "ESF". The exchange of data between different cars is via 'ad hoc' networks that are formed between vehicles over short distances. These WLAN require no extra external infrastructure. Transmission occurs at a frequency of 5.9GHz over a distance of up to 500 metres. Of course this distance is expanded if different cars are communicating with each other and messages are passed on.

Currently there is a project in Frankfurt called "simTD" ^[8]. Different German car manufacturers are taking part in this test where up to 400 cars are communicating with each other. The main purpose of this test is to improve safety on the road.

References

Embedded Control Systems Design