The main goal of this use case is to enable co-engineering between control engineers and real-time engineers. This might be called “resource constrained control”. In the following the necessity of this co-engineering is explained and a methodology implementing it is presented.
Problem Statement
Control design is usually performed assuming idealized timing assumptions, including sampling without jitter and negligible delay from controller input (sensing) to output (actuation), etc. Of course, each ECU does not only execute a single control application but performs several functionalities in parallel. Each of them is developed under the above stated assumptions.
In the case of a single core ECU, these control applications compete for processor time. Since only one controller application can be executed at the same time, a real-time kernel arbitrates the access to the processor according to a scheduling policy. This of course leads to increased and varying response times for the control applications due to preemptions, blocking effects, etc. Obviously, the idealized assumptions stated above do not hold under such circumstances.
In Figure 1 the effects of scheduling that lead to varying input-output delays are demonstrated.

Figure 1. Effect of scheduling on control performance
On the left-hand side, an activation graph of 3 tasks executing control applications is shown. As can be observed, the lowest priority task executes very irregularly due to preemptions of the two higher priority tasks.
On the right-hand side the impact on control quality is shown. The input-output delay between sampling and control varies drastically due to the preemptions. The executed control application does not succeed in adjusting the plant output (y) to the desired control input values (yref).
There are several possible solutions in such situations. Of course, the priority of the task executing the critical control application could be increased. But then, most certainly, another control application would fail. Another possibility is to decrease the sampling periods of the control applications. Then, however, the overall system load would increase and the deadlines of the control applications (which are usually equal to the periods of the tasks executing them) would be much harder to satisfy by the real-time kernel. Additionally, the number of control applications that can be accommodated by a single ECU would decrease using such an approach. This is not acceptable, since this leads to bad hardware utilization and, thus, increased cost per functionality.
Consequently, the question that is addressed by this use case is the following: How can we systematically integrate several control applications onto the same ECU while ensuring good control quality, adherence to real-time constraints and system extensibility for future features?
Co-Design Approach
The main idea of this use case is to perform co-design between control engineering and real-time engineering. The starting point for this approach is the following inherent conflict of goals:
1. For control engineering, short sampling intervals are ideal, since they approximate best the idealized assumptions stated above. This leads to better control quality.
2. For the real-time behavior of the global system, long sampling intervals are ideal, since the same computations for the control applications are repeated less often. This leads to less processor load, translating into less resource sharing and making it easier for the real-time kernel to satisfy all deadlines. Additionally, more slack for additional functionality is available on the ECU.
The possible maximum and minimum sampling rates can be determined analytically as follows. The minimum sampling rate for a control application depends on the time constants of the plant that is controlled. A rule of thumb is that the sampling rate of the controller should be 10 times smaller than the smallest time constant of the plant. But even higher sampling rates may be required if the Eigenvalues of the plant are placed badly, or if the plant is nonlinear. A control engineer may use an analysis model in MATLAB/Simulink to investigate the necessary minimum the sampling rate.
The maximum sampling rate for a control application, here called scheduling threshold, is bounded either
• by the computational capacity of the ECU executing the control application, meaning that it shall not be overloaded, or
• by real-time constraints of other tasks, that are violated due to the increased interference resulting from the higher sampling rate of the control application.
This maximum sampling rate can, for instance, be determined using scheduling analysis techniques. Please note that it might not make sense for all kinds of control applications to fully exploit the scheduling threshold, e.g. when the controlled system (aka plant) is changing its state relatively slowly like, for instance, in cabin temperature control. More precisely, in cases where the scheduling threshold permits a shorter sampling rate than the time constant of the plant, i.e. the response time of the plant to a control input, the time constant must be taken as lower bound for the sought-after ideal sampling rate rather than the scheduling threshold.
Figure 2 shows the minimum and the maximum sampling rates that span the search space, called co-design area, for the trade-off exploration between good control performance and good real-time behavior.

Figure 2. Co-design area between control engineering and real-time engineering
Resource Constrained Control Application Development
In order to systematically explore the above explained design space a new development paradigm for control applications is needed.
In the current state-of-practice, the controller design and implementation is done independently of timing and integration considerations. The system integrator takes the resulting software implementations, and must cope with the overall system’s timing behaviour. Practically, he has no degrees of freedom, since sampling rates, interdependencies between processes, etc. are inherently incorporated in the controller designs, and are, thus, immutable.
This use case stresses that the overall timing behaviour of a system, comprising of several control applications, shall be considered as explicit design goal.
To do so, a feedback loop between control design and system integration, taking into account the overall system’s timing behaviour, is necessary. Only then it is possible to choose controller designs offering at the same time
1. good control performance, and
2. good overall system timing behaviour offering slack for future functionalities. |