Chapter 2. Layers of integrated vehicle control

The complex tasks of a vehicle control must be structured in a way that the logical steps are built on one another and the complexity can be simplified by abstracting substructures. The levels of intelligent vehicle control defined by Prof. Palkovics [20] is suitable to provide a general overview of the subject, later the different layers of intelligent vehicle control are described in a way they depend on each-other.

For achieving an integrated control a possible solution could be to set the design problem for the whole vehicle and include all the performance demands in a single specification. Besides the complexity of the resulting problem, which cannot be handled by the existing design tools, the formulation of a suitable performance specification is the main obstacle for this direct global approach. In the framework of available design techniques formulation and successful solution of complex multi-objective control tasks are highly nontrivial.

From control design point-of-view the integrated vehicle control consists of five potentially distinct layers[16]:

Research into integrated control basically focuses on the fifth layers; however the components of any integration belong to the third and fourth layer. The components in the first two layers are assumed to exist. Note, that to some extent the layers may be classified by the degree of centralization, e.g. centralized, supervisory or decentralized.

During the implementation of the designed control algorithms additional elements from information technology and communication will be included in the control process. In the classical control algorithms a lossless link is assumed to exist between the system and control these algorithms are concerned mostly with delays, parametrical uncertainties, measurement noise and disturbances.

The performance of the implemented control is heavily affected by the presence of the communication mechanism (third layer), the network sensors and actuators, distributed computational algorithms or hybrid controllers. It is useful to incorporate knowledge about the implementation environment during the controller design process, for example dynamic task management, adaptability to the state (faults) of sensors and actuators, the demands imposed by a fault tolerant control, the structural changes occurring in the controlled system.

From architectural design point of view the model based simulation of the planned architecture provides an early stage feedback about the potential bottlenecks in the design [21] [22]. Early stage simulation can reveal hidden mistakes that could turn out only after system implementation. When modification should be made on the implemented system due to the results of the safety analysis, it has much higher costs. The simulation based analysis needs lower costs, but takes time to prepare and carry out the simulations. The main advantage is that the simulation based analysis can be carried out from the early stage of the development. Certainly at the beginning of a system development, the system architecture is in its initial stage; therefore simulation model may also be inaccurate. The system design engineering and the safety engineering are parallel processes; the system model for the safety simulations is getting more and more accurate during the development. And there is a continuous feedback from the safety engineering to the system design engineering [23][24].

The software technology is not simply a software implementation of the control algorithm. The implementation and the software/hardware environment are also a dynamic system, which has an internal state and which respond to inputs and produces outputs. If the actual plant is combined with an embedded controller through the sensor and actuator dynamics, a distributed hybrid system is created. With this approach the control design is closely connected with software design. The control design is evolving through the development of hybrid optimal control, observability/controllability analysis, and software design is being facilitated by distributed computing and messaging services, real-time operating systems and distributed object models.

In the different prototype implementation of autonomous or highly automated vehicles a strictly defined layer structure can be observed that definitely corresponds to the above mentioned layer structure even if some layers are merged together for simplicity. The following figure shows the PEIT approach of the vehicle control layer structure[25]:

The PEIT architecture differentiates 3 different layers, namely the PEIT application layer, the powertrain interface and the integrated powertrain layer. The integrated powertrain layer contains 4 intelligent actuators, the drive-by-wire, the shift-by-wire, the brake-by-wire and the steer-by-wire systems. Important to notice that in the PEIT architecture the engine and transmission actuators are single subsystems, while the brake and steering systems are redundant subsystems. This is due to the requirement of availability based on the safety critical categorization of the subsystems. In case of the engine there is no backup function, in case of a transmission system there is only a “limp home” function which serves as a limited (e.g. one fixed gear) but useful functionality to maintain the movability of the vehicle. When it comes to the brake or the steering system it is obvious that any malfunction can result in serious consequences, so these systems must be designed in a way that they tolerate at least one failure. This is why safety critical systems have fault-tolerant architecture. There are different possible realizations of a fault tolerant system, one is simply using redundancy. In this case there are two parallel system elements that work simultaneously and in case of a failure one system can take over the control from the broken one. There is also a redundant powertrain controller can be found in the integrated powertrain layer, further dividing the layer into 2 sublayers. Referring back to the Prof. Palkovics the powertrain controller implements the vehicle level control, while the by-wire systems underneath are the intelligent actuators.

The HAVEit layer structure [6] is a further optimized, extended and structured architecture, where there are basically two main layers, namely the command layer and the execution layer. The interface in between is specifically called the “motion vector”. Even if there are a lot of other functions involved, the basic idea is that the command layer specifies the motion vector, which has to be followed by the vehicle that is carried out by the execution layer.

Conventionally, the control systems of vehicle functions to be controlled are designed separately by the equipment manufacturers and component suppliers. One of the problems of independent design is that the performance demands, which are met by independent controllers, are often in interaction or even conflict with each other in terms of the full vehicle. As an example braking during a vehicle manoeuvre modifies the yaw and lateral dynamics, which requires steering action or, as another example, under/oversteering requires braking intervention. The second problem is that both hardware and software will become more complex due to the dramatically increased number of sensors and signal cables and these solutions can lead to unnecessary hardware redundancy.

The demand for the integrated vehicle control methodologies including the driver, vehicle and road arises at several research centres and automotive suppliers. The principle of integrated control with the CAN network was presented by Kiencke in [3]. The purpose of integrated vehicle control is to combine and supervise all controllable subsystems affecting vehicle dynamic responses. An integrated control system is designed in such a way that the effects of a control system on other vehicle functions are taken into consideration in the design process by selecting the various performance specifications. Recently, several important papers have been presented in this topic, see e.g. [4], [5], [6], [7], [8].

For achieving an integrated control a possible solution could be to set the design problem for the whole vehicle and include all the performance demands in a single specification. Besides the complexity of the resulting problem, which cannot be handled by the existing design tools, the formulation of a suitable performance specification is the main obstacle for this direct global approach. In the framework of available design techniques formulation and successful solution of complex multi-objective control tasks are highly nontrivial. Another solution to the integrated control is a decentralized control structure, in which there is a logical relationship between the individually-designed controllers. The communication between control components is performed by using the CAN bus (see Section 7.1). The advantage of this solution is that the components with their sensors and actuators can be designed by the suppliers independently. However, the local controllers require a group of sensors and hardware components, which may lead to different redundancies. The difficulty in the decentralized structure is that the control design leads to hybrid and switching methods with a large number of theoretical problems, see [8],[9],[10],11]. While stability of the control scheme assuming arbitrary switching can be ensured by imposing suitable dwell-times, it is hard to guarantee a prescribed performance level in general in the design process.

In more detail it means that

These principles are close to the low-cost demands of the vehicle industry. In this way it should be possible to generate redundancy in a distributed way at the system level, which is cheaper and more effective than simply duplicating key components.

Research into integrated control basically focuses on the fifth layer, however the components of any integration belong to the third and fourth layers. The components in the first two layers are assumed to exist. Note, that to some extent the layers may be classified by the degree of centralization, e.g. centralized, supervisory or decentralized.

During the implementation of the designed control algorithms additional elements from information technology and communication will be included in the control process. In the classical control algorithms a lossless link is assumed to exist between the system and control these algorithms are concerned mostly with delays, parametrical uncertainties, measurement noise and disturbances.

The performance of the implemented control is heavily affected by the presence of the communication mechanism, the network sensors and actuators, distributed computational algorithms or hybrid controllers. It is useful to incorporate knowledge about the implementation environment during the controller design process, for example dynamic task management, adaptability to the state (faults) of sensors and actuators, the demands imposed by a fault tolerant control, the structural changes occurring in the controlled system.

The software technology is not simply a software implementation of the control algorithm. The implementation and the software/hardware environment are also a dynamic system, which has an internal state and which respond to inputs and produces outputs. If the actual plant is combined with an embedded controller through the sensor and actuator dynamics, a distributed hybrid system is created. With this approach the control design is closely connected with software design. The control design is evolving through the development of hybrid optimal control, observability/controllability analysis, and software design is being facilitated by distributed computing and messaging services, real-time operating systems and distributed object models.

A reference control architecture for autonomous vehicles is presented in Figure 27. It shows how the software components should be identified and organized. This reference model is based on the general Real-time Control System (RCS) Reference Model Architecture, and has been applied to many kinds of applications, including autonomous vehicle control.

Another solution to the integrated control is a distributed (decentralized) control structure, in which there is a logical relationship between the individually-designed controllers. The communication between control components is performed by using the vehicle communication network (e.g. CAN bus). The advantage of this solution is that the components with their sensors and actuators can be designed by the suppliers independently. However, the local controllers require a group of sensors and hardware components, which may lead to different redundancies. The difficulty in the distributed structure is that the control design leads to hybrid and switching methods with a large number of theoretical problems, see [19][26][27][28]. While stability of the control scheme assuming arbitrary switching can be ensured by imposing suitable dwell-times, it is hard to guarantee a prescribed performance level in general in the design process.

Integrated control based on a distributed (decentralized) structure means that

These principles are close to the low-cost demands of the vehicle industry. In this way it should be possible to generate redundancy in a distributed way at the system level, which is cheaper and more effective than simply duplicating key components.