Control Theory

Considering the ECUs (in particular, closed-loop ECUs), it is inevitable to introduce the basics of control theory. Aristotle7 [Ack81] already started to think about the control theory [Ben79]. Following his statement “… if every instrument could accomplish its own work, obeying or an-

ticipating the will of others … chief workmen would not want servants, nor masters slaves”

[AR], his wish was to automatize the behavior of others (e.g., people, devices) using a set of clearly defined criteria. This is also the idea behind the development of embedded systems – to force them so that they work in a manner they are designed. If so, quality assurance for this de- velopment gains the priority too.

Control theory is an interdisciplinary branch of engineering and mathematics that deals with the

behavior of dynamic systems. The desired output of a system is called the reference. When one or more output variables of a system need to follow a certain reference over time, a controller manipulates the inputs to a system to obtain the desired effect on the output of the system. Control theory introduces a feedback. Feedback is a process whereby some proportion of the output signal of a system is passed (fed back) to the input. This is often used to control the dy- namic behavior of the system [SG03, MSF05]. A closed-loop controller uses feedback to con- trol states or outputs of a dynamic system. Its name is derived from the information path in the system: process inputs (e.g., voltage applied to an electric motor) have an effect on the process

7 _{Aristotle (384 B.C. – 322 B.C.) was a Greek philosopher, a student of Plato and teacher of Alexander the Great. He wrote}

on many different subjects, including physics, metaphysics, poetry, theater, music, logic, rhetoric, politics, government, ethics, biology and zoology [Ack81].

outputs (e.g., velocity or torque of the motor), which is measured with sensors and processed by the controller. The resulting control signal is used as input to the process, closing the loop. Closed-loop controllers have the following advantages over open-loop controllers [Kil05]:

− guaranteed performance

− rejection of disturbance (e.g., unmeasured friction in a motor) − capability to stabilize unstable processes

− reduced sensitivity to parameter variations − improved performance for reference tracking

A simple controller (see Figure 2.2) attempts to correct the error between a measured process variable (i.e., output – y(t)) and a desired setpoint (i.e., reference – r(t)) by calculating and then producing a corrective action (i.e., error – e(t)) that can adjust the process accordingly.

In particular, the output of the system y(t) is fed back to the reference value r(t), through a sen- sor measurement. The controller C then uses the error e(t) (i.e., difference between the refer-

ence and the output) to change the inputs u to the system under control P (e.g., a car).

- +

C P

r e u y

Figure 2.2: A Simple Closed–Loop Controller.

This situation is called a single-input-single-output (SISO) control system. Multi-Input-Multi- Output (MIMO) systems, with more than one input/output, are common. In such cases, vari- ables are represented through vectors instead of simple scalar values. For some distributed pa- rameter systems the vectors may be infinite-dimensional (typically functions).

Common closed-loop controller architecture, widely used in industrial applications, is the pro- portional-integral-derivative (PID) controller [Kil05]. Its name refers to the three terms operat- ing on the error signal to produce a control signal. Its general form is:

dt

de

K

dt

t

e

K

t

e

K

t

u

+

+

=

∫

)

(

)

(

)

(

where: KP – proportional gain

KI – integral gain

KD – derivative gain.

Larger KP typically means faster response since the larger the error, the larger the proportional

term compensation. An excessively large proportional gain will lead to process instability and oscillation. Larger KI implies steady-state errors are eliminated quicker. The trade-off is larger

overshoot. Larger KD decreases overshoot, but slows down transient response and may lead to

instability due to signal noise amplification in the differentiation of the error.

The desired closed-loop dynamics is obtained by adjusting the three parameters KP, KI and KD,

Model Software Hardware

2.2 Model-based Development

The development process of embedded systems usually occurs on at least three different levels. First a model of the system is built. It simulates the required system behavior and usually repre- sents an abstraction of the system. When the model is revealed to be correct, code is generated from the model. This is the software level. Eventually, hardware including the software is the product of the development. The reason for building those intermediate levels is the fact, that it is much cheaper and faster to modify a model than to change the final product. The entire proc- ess is called model-based development (MBD).

The multiple V-model [BN02, SZ06], based on the traditional V-Modell®, takes this phenome- non into account. The V-Modell is a guideline for the planning and execution of development projects, which takes into account the whole life cycle of the system. The V-Modell defines the results that have to be prepared in a project and describes the concrete approaches that are used to achieve these results [VM06]. In the multiple V-model, each specification level (e.g., model, software, final product) follows a complete V-development cycle, including design, build, and test activities as shown in Figure 2.3. The essence of the multiple V-model is that different physical representations of the same system on different abstraction levels are developed, aim- ing at the same final functionality. Then, the complete functionality can be tested on those dif- ferent platforms. Since certain detailed technical properties cannot be tested very well on the model, they must be tested on the prototype instead. Testing the various SUT representations often requires specific techniques and a specific test environment. Therefore, a clear relation between the multiple V-model and the different test environments exists.

Figure 2.3: The Multiple V-Model.