Problems and trends in automotive control

An automobile as control environment consists of a set of sensors and executing mechanisms. Any control task in an automobile can be represented as Figure 1. For solving control tasks a set of local systems that control vehicle parameters is used. Every local system is a closed control loop. Control criteria often include parameters that are not controlled by the local system itself.

An automobile as control environment consists of a set of sensors and executing mechanisms. Any control task in an automobile can be represented as (refer to Figure 1). For solving control tasks a set of local systems that control vehicle parameters is used. Every local system is a closed control loop. Control criteria often include parameters that are not controlled by the local system itself.

All vehicle local systems influence each other through parameters that are used in control criteria. The more accurately connections between local systems are defined, the more precise and sustainable is each of the systems. Revision of the entire model of control tasks in an automobile requires introduction of a control loop of all local systems. As a model of control tasks in an automobile we assume a set of local systems unified by a single control loop.

1. Brief review of methods of solutions of control tasks

At the present moment the development of automobiles takes the path of extensive set of options and poorly interconnected systems implementing these options. Local control systems in this case utilize shared data resources, individual computing resources and intersect via executing mechanisms.

System intersection via executing mechanisms demands necessity of solving supervisory access tasks. These tasks require additional computing and time resources. A shared resource in the digital system built by the channel principle is the communication channel itself. Solution of the channel conflicts demands the same resources.

2. An automobile as a set of two information streams

Vehicle control system includes two information streams. The first one is a data stream:

• Data about a vehicle state;
• Data about a current state of a local system;
• Data about a required vehicle state;
• Data about a required state of a local system.

The second stream is a command stream:

• Command streams of local systems;
• Command streams of control of local systems.

Total capacity of all these streams defines the necessary volume of the communication channel. Capacity of the command stream defines the necessary computing capacities.

2.1. Problems of interaction of data streams.

Data about a current vehicle state and its local systems must be synchronized with a time scale of control tasks of local systems. If every local system operates in its time scale, then the task of data synchronization does not possess a shared solution. One of the obvious solutions is transmission of this function to the communication channel. This leads to the necessity of synchronization of data streams of local systems by the communication channel.

Data about the required vehicle state and its local systems appear as a result of processing of discrete current states. On the other hand, they must be continuous for implementation. This discrepancy can be solved by data extrapolation in an automobile.

2.2. Definition of the vehicle architecture

A vehicle architecture is a set of three components:

• Topology of connections between architecture elements (sensors, executing mechanisms, control units);
• Structure of a data stream between control units (CU);
• CU- and task-segmented structure of a command stream.

2.3. Choosing optimal informational architectures according to SAE requirements

SAE classifies automotive tasks into 3 levels:

• Level A—tasks of direct control without feedback;
• Level B—local closed tasks;
• Level C—motion control tasks.

Every level of tasks complies with its optimal architecture and requirements to the volume of transmitted information and computing power for its processing. It is possible to demonstrate that level C optimal structure would include level A and B architectures with corresponding coordination of time scale. Therefore, optimal structure for level C with three time scales will be optimal for all control tasks.

3. AVAS architecture (developed by Finprom-Resource Saratov, Russia)

Physical topology of the AVAS (Adaptable Vehicle Associated System) architecture is a single-wire network with homogeneous components. Every network component is an identical CU that is connected according to the star topology with its own set of sensors and executing mechanisms. A network component is connected with its own set by the territorial criterion. A set consists of sensors and executing mechanisms of different vehicle systems. Informational topology is represented on Fig. 2. Such informational structure permits to:

• fragment tasks into a multitude of parallel processes;
• increase computing power of such network;
• include into the network a system that operates via CAN, LIN, etc. communication protocols.

Information window and time scales for tasks of levels A, B, C are organized on the AVAS channel level. Time scales are defined in the window of task zone of different classes. Fragmentation of the window into zones is also an AVAS function. For every control unit the window zones are available for changes from its side at any moment of time.

4. Technology of solving tasks of levels A, B, C.

General scheme of task representation is shown on Fig. 1. The structure of level A tasks is characterized by the coordinate control. This means that an output signal depends only on an input signal, which is independent of control object state. The feedback is absent.

When integrating level A tasks into a ubiquitous control system the necessity to synthesize control signals on the base of all parameters of the control system. As a result, a virtual command complex on controlling level A systems is created. We are not giving a strict mathematical grounding of this solution as it goes beyond the limits of this article.

This program complex in the AVAS structure provides an infinite multitude of service AVAS functions. The main task of the program complex A is a synthesis of control signals.

The task of level B includes local control tasks that are not directly connected with vehicle motion and control. As compared to level A, a dependence of control signals on a current system state is introduced. The main characteristic of these systems is the size of the bandwidth in the AVAS system. Exactly AVAS defines the minimum time scale when synchronizing these systems and lays in the range of 10–20Hz.

Integration of level B systems leads to the development of virtual program complex B that is similar to level A. The main task of the program complex B is service functions, safety functions and telemetry.

Level C task includes complexes of local control tasks connected with vehicle motion and control. As compared to A and B levels, synchronization is introduced. Synchronization means coincidence and convergence of variables of two or more systems or coordinated change of some quantity system characteristics.

The goal of control in level C is correspondence of functioning of control equipment to the specified mathematical law—an objective function. This differs level C control from level A and B control where control is implemented by the specific parameters.

Integration of level C systems leads to the development of a more complicated complex of the objective functions’ control in vehicle systems. This complex has a bandwidth up to 200 Hz. Besides, it must include at least two time scales coinciding with the level B time scale (approximately 50 Hz) and its own time scale (approximately 500 Hz).

AVAS technology includes hardware whose computing power grows with the number of solved tasks. AVAS architecture complies with the structure of tasks for level C and solves level A and B tasks as particular cases. The general aspect for all classes of tasks is the availability of a single program complex based on distributed computing environment with a built-insynchronization for solving tasks of all levels.

5. Methodology of utilizing AVAS.

Methodology of utilizing AVAS is primarily a methodology of integrating vehicle tasks and nodes into a ubiquitous control system. In all cases similar integration technique is used. As a technological base for this in AVAS a MATLAB package is used where every vehicle node or option is first represented as a model. Then this model is integrated with the AVAS model and models of other vehicle nodes and options. Integration criteria include:

• Invariance of characteristics of control loops when integrating a new task;
• Invariance of characteristics of nodes in the system when integrating new units.

AVAS utilizes methodology of fragmenting a ubiquitous control system into parallel processes by the criterion of the smallest data stream between them. The number of such parallel processes coincides with the number of AVAS control units. As a result of the operation, a package of programs is received that can be loaded into AVAS control units for a specific car brand.

6. Received technical results and limitations of the AVAS system.

Received technical results are shown in Table 1. AVAS structure is shown on Fig. 3.

7. Virtual vehicle model as a goal of development of the AVAS architecture.

A distinctive feature of AVAS is that it has 2 interfaces:

• Interface of control tasks;
• Interface of vehicle nodes;
• Invariance of these interfaces from control tasks and nodes;
• Multidimensional system of synchronization.

Multidimensional system of synchronization includes entire AVAS channel level, shared information window and synchronization system of computing processes. The following are synchronized:

• Tasks between each other;
• Vehicle tasks and nodes;
• Vehicle nodes between each other;
• Computing processes.

The first two kinds of synchronization are provided by synchronization of data streams and the other two—by synchronization of moments of launching computing processes. From the point of view of tasks, two interfaces and a synchronization system form a virtual vehicle model. The same model gives to nodes a unified interface of tasks.

From the technical point of view, virtual vehicle model is a flexible and powerful tool both for automotive designers and designers of systems and options in an automobile.

Conclusion

The article analyzes problems and trends in the sphere of control in automotive systems. The format of the article does not imply the detailed examination of all aspects of the problem and provide a full justification of methods of solutions. At the present moment we are preparing further materials concerning this research area and we welcome dialog with the interested readers.