QoS in Distributed Control of Safety-Critical Motion Systems
Abstract
Some critical topics of QoS in distributed feedback control will be studied in the project: heuristics for negotiation, scheduling, mix of QoS targets, quality measure, negotiation interval and change of service level. Simulation of a CAN bus and the vehicle dynamics control of a truck and semi-trailer combination is used to exemplify ideas and issues. 1. QoS in feedback control The objective of the research project [1] is to develop theories and models in order to provide a base of knowledge for distributed control implementation in real-time machinery. The research activities have, since the start in 1993, included investigations of strategies for design of fault-tolerance in time critical distributed computer systems; strategies for mapping control applications on distributed computer systems; modelling approaches which support distributed implementation of controllers; verification methods; control algorithms which are robust to variations in the control timing; and a time triggered distributed system. At present, the project involves a case study at Volvo, where we look at distributed architecture, timing problems and control algorithms for vehicle dynamics control, VDC. The QoS aspect is only one research direction. The purpose of the research is to bring out the advantages of using QoS (quality-of-service) in feedback control, but also to put forward a number of challenging critical issues which follow. The method is to investigate principles by means of simulation. There is no proposal of any heuristic scheduling algorithm, but rather a reasoning of how a QoS management functionality for (embedded) control systems could be constructed. QoS is an attractive run-time framework for the management of a shared resource. The notion originates from the multimedia/telecommunication discipline, and is easy to abuse. What are the advantages of QoS? It provides graceful degradation, the application is decoupled from resource availability and capacity, and accommodation of quality is a way to increase overall system utilization. Graceful degradation can for example be used when recovering from a subsystem failure; the system might fulfil its mission but with a lower quality than would be normally expected. The decoupling of hardware resources from the software implementation will facilitate redesign and upgrade during the life time of a product. A product family with a large number of combinations of machine elements, hardware and software, will be easier to maintain, if the software does not have to be tailored for each variant. QoS management involves setting up (negotiate) and maintaining (renegotiate) a contract which states that a request from an application, i.e. to execute a task, will be guaranteed service at a specified level of quality. The renegotiation between the broker and an application can be regarded as a feedback path. If circumstances in the monitored environment put new demands on the application, the broker acts as controller and renegotiates the contract. The negotiation can also be seen as a way to optimize the usage of a shared resource. QoS in automatic control was treated in [2] which seems to be the first paper with this combination. The proposed QoS model is used together with a service which manages a pool of distributed processing resources. The contention between different applications is based on rewards depending on guaranteed level of service. Rejection penalties determine if a new task is to be serviced or not, i.e. a mission critical task should have a high rejection penalty. In case of overload the broker can renegotiate QoS levels with the applications. If the local optimization algorithm rejects a request, it can be transferred by the load-sharing algorithm to another processor. From a control point of view an interesting point is that code modules are invoked depending on the selected QoS level. It is shown that the proposed model outperforms binary admission schemes and achieves higher “application perceived system utility”. What is missing in the paper is the mapping between controller performance and period or latency. The QoS framework does not imply any specific scheduling or synchronization policy. There are a multitude of scheduling strategies, is there anyone suitable for QoS? Vital parts of the negotiation will probably have to be heuristic algorithms. The idea is to study how the QoS management functionality should be structured. 2. Good or bad, better or worse Quality is here equal to performance of a control loop. The QoS targets have to depend on timing behaviours and they have to be possible to quantify or measure. The targets can be expressed indirectly by timing properties, or directly in terms of control performance. The latter is more accurate and elegant, but requires an explicit mapping from time related properties of the computer system to feedback control performance. In the former case the mapping is an approximation and in disciplines where the measurement of quality is governed by “application perceived system utility“, this becomes a necessity. An objective measurement of quality is a justification for applying the notion of QoS to feedback control. The timing properties that play a vital role in computer control can be divided into the timing problems: control delay, jitter, sampling period and effects of transient errors, see [3], [4] and [5]. An example is the selection of sampling period. The choice of sampling period is usually based on rules of thumb, because a small change in sampling period does not make a decisive quality improvement on the margin, see Figure 1. Hence, this could be divided into a range of negotiable QoS levels. When the period increases, the quality decreases and instability or loss of observability will follow, eventually. . FIGURE 1. The quality of a control application depends on sampling period, h, and delay, R, and their jitter respectively, ∆h and ∆R. The diagram shows the individual shapes primarily, not the relations. When the dynamics of the process change, the target quality can remain unaltered, but e.g. sampling period and jitter can be renegotiated. The idea is of course that the control engineer specifies the required quality, and not e.g. sampling period for each process mode. A challenging question is how to select, mix and measure QoS targets. To change a parameter and see what is happening to quality is not an acceptable solution; in order to guarantee the behaviour the quality must be predictable at the time of negotiation. The mapping from timing properties to quality is not easily found in the control literature, but there has been some research here. In an actual system, a control application will run simultaneously with other applications, which do not have the same type of quality measure. The question is: how should the broker compare apples with bananas? Besides period, delay, jitter and loss rate, fault tolerance would be a desirable target for a safety-critical application. This quality could be controlled partially by time redundancy (sending the same message twice) and by active replication on shared redundant hardware. 3. Case study: truck and semi-trailer A dynamic model of a truck and semi-trailer, Figure 2, is under development in cooperation with a major truck manufacturer. Q ua lit y Time (duration) ∆h, ∆R R h