Chapter 2. Layers of integrated vehicle control
2. Layers of vehicle control
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]:
1. The physical layout of local control based on hardware components, e.g. ABS/EBS, TCS, TRC, suspension.
2. Layout of simple control actions, e.g. yaw/roll stability, ride comfort, forward speed.
3. The connection layout of information flow from sensors, state estimators, performance outputs, condition monitoring and diagnostics.
4. The layout of control algorithms and methodologies with fault-tolerant synthesis, e.g. lane detection and tracking, avoiding obstacles
5. Layout of the integrated control design.
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].
Figure 2.2. Initial model of the HAVEit architecture simulation
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]:
Figure 2.3. Levels of intelligent vehicle control (Source: PEIT)
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.
Figure 2.4. HAVEit System Architecture and Layer structure (Source: HAVEit)
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.
2.1. Command layer
The command layer contains the high level algorithms for the longitudinal and the lateral control of the automated vehicle. The command layer calculates the desired acceleration and direction and communicates the results to the powertrain via the powertrain interface, which also provides feedback about the vehicle state for the high level control.
Based on the driver intention and the information coming from the perception layer the command layer defines the vehicle automation level and calculates the vehicle trajectory. The objective of the perception layer is to collect information about the external environment and the vehicle, thus providing information about vehicle status and objects in the surrounding environment. From this information the command layer determines the obtainable levels of vehicle automation and displays the options to the driver. Meanwhile the co-pilot calculates possible vehicle trajectories and prioritizes them based on the accident risk. The driver selects the desired level of vehicle automation from the available options via the HMI. Finally the mode selection unit decides the level of automation and selects the trajectory to be executed.
2.2. Motion Vector
The motion vector acts as an interface between the command layer and the execution layer. It is bidirectional, delivering longitudinal and lateral control commands to the powertrain and providing vehicle status feedback information for the higher level control.
This middle layer contains predefined data transfer for the control and the feedback of the powertrain. It includes commands for the vehicle control including the desired status of the powertrain and the required acceleration and torque. This interface also includes status feedback from the powertrain to the application layer providing important information whether the control action resulted in the required movement.
2.3. Execution Layer
The execution layer contains a full drivetrain control connected to intelligent actuators via a high speed communication network. As the implementation of a fully electronic interface (motion vector) for controlling the powertrain enables the replacement of the human driver for an electronic intelligence (auto-pilot), the execution layer cannot distinguish whether the commands are originated from a human driver or an auto-pilot.
The commands are coming through the same interface, so the execution layer has to execute only. Considering that there are safety critical subsystems can be found among the intelligent actuators a fault-tolerant architecture
is a prerequisite. This fault tolerant architecture not only includes duplicated powertrain controllers, steering and braking systems but also a redundant communication network, power supply and HMI to the driver. The following figure shows the powertrain control structure of the execution layer in the PEIT demonstrator vehicle[25].