Problem Formulations for QoS Management in Automatic ... - CiteSeerX

TRITA-MMK 2000:3 ISSN 1400-1179 ISRN KTH/MMK--00/3--SE

Problem Formulations for QoS Management in Automatic Control

by Martin Sanfridson

DAMEK

Stockholm 2000

Technical Report Mechatronics Lab Department of Machine Design Royal Institute of Technology, KTH S-100 44 Stockholm Sweden

Mechatronics Lab Department of Machine Design Royal Institute of Technology S-100 44 Stockholm, Sweden Author(s)

Martin Sanfridson [email protected]

TRITA-MMK 2000:3 ISSN 1400-1179 ISRN KTH/MMK/R--00/3--SE Document type

Date

Technical Report

2000-03-15

Supervisor(s) Prof. Jan Wikander, Doc. Martin Törngren Sponsor(s)

NUTEK Title

Problem Formulations for QoS Management in Automatic Control Abstract

Quality-of-service management is a method where applications negotiate with a broker for resources. How can the notion of QoS, which comes from multimedia and telecommunication areas, be applied to automatic control? What are the advantages, drawbacks and problems that arise? In a QoS framework applications negotiate with a broker to get serviced at a specified level of quality. QoS is often associated with distributed computer systems. The notion of QoS has features which makes it interesting for use in control of dynamic systems: it provides graceful degradation, the application is decoupled from resource availability and capacity, and QoS level adjustment is a way to increase overall system utilization. This report is a problem formulation and a small survey of what has been done in the area of quality-of-service. The idea of the QoS framework can be applied to almost any computer control system with a need for flexibility and with a possibility to adapt to changes in the system and to the external environment. Examples can be found in the process industry, where it is common to use distributed computer control systems. Embedded control systems in vehicles and robots where the external environment frequently is changing, is also of interest for the QoS framework. Some topics for future research in the area are identified in this report. Control theory can be better tailored to the QoS negotiation policy. Is there any particular scheduling strategy which is suitable? How should a heuristic QoS management be constructed? Can QoS improve the fault tolerance, or does it make fault tolerance impossible? Is it possible to have a decentralized broker? The quality is difficult to measure objectively. How should different ways to specify quality be combined to allow a mix of applications in a good way?

Keywords

Language

QoS, quality-of-service, automatic control, feedback control, timing problem, scheduling

English

1 Introduction 1.1 Outline of the report An introduction with a motivation for applying QoS (quality-of-service) to automatic control applications will be given first. The next section continues with a survey of what has been written in the area, with a focus towards automatic control. The third section formulates problems and challenges of QoS when applied to automatic control. The fourth section contains summary and ideas for further work. In the appendix, a list of definitions taken from an ISO/IEC draft is reproduced and interpreted. The terminology in this section and in the rest of the report follows the ISO/IEC draft, but the reader should be aware that other terms and definitions exist.

1.2 Introduction to QoS QoS management involves setting up (QoS establishment, also called negotiation) and maintaining (QoS maintenance, also called renegotiation) a contract which states that a request from an application, i.e. to execute a task or to communicate, will get serviced at a specified level of quality. There can be a set of discrete levels or a continuous value within a specified range. Quality can be subjective or objective and can mean different things for different applications. In this paper quality is primarily thought of as control performance. The maintenance is a way to repeatedly allocate tasks or messages to resources to e.g. achieve graceful degradation when the usage of resources is near maximum capacity. QoS management can be applied both to scheduling of nodes and communication in a network. The adaption mechanism, handled by a broker, is located to the operating system. The broker cooperates with the applications. The negotiation between broker and application can be seen as a feedback path. The use of QoS does not imply any specific scheduling policy. The performance requirement, QoS target, of the application, is sent to a broker at the service provider which determines at what level an application’s request can be serviced. The type of quality is termed QoS characteristic. It is understood that all applications negotiate with the broker. The QoS characteristic is a quantifiable abstraction of a quality measure used by the service provider in the negotiation. QoS targets can be specified for a range of discrete values (QoS levels). Figure 1 gives the picture of the basic concept. The complexity of the negotiation can easily be increased by considering that one application can have multiple characteristics and multiple ways to control one characteristic.

1

Action: Negotiation Service Service Service User User User

Data: Requirements

Service Provider

Action: Delivered Service FIGURE 1. The service user negotiates with the service provider to deliver service which fulfils the requirements of the user. See the appendix for more definitions.

The application can in this context be a controller with the loop closed over a network; the quality measure (QoS characteristics) of the application is primarily control performance e.g. measured as variance of the control error.

1.3 QoS applied to automatic control Because of the dynamics in the process, the information contents of a signal (a measurement for example) do not decrease abruptly, but gradually with time. A single late or vacant sample does not in general lead to a catastrophe. An early measured value or actuation does not necessarily constitute any improvement to control performance. Delay is something to avoid because the magnitude of the phase angle increases. The deadlines of messages containing signals such as measured value and control output are not generally hard. There are other important messages in a control application, e.g. mode change request, where it could be more important to apply a hard deadline. A constant delay and jitter in a feedback control loop make control performance deteriorate. A constant delay can be accounted for to some extent, when designing the controller, but a varying delay is difficult to compensate for. The sampling period is an important design variable in discrete control design. The choice of sampling period is determined by some rule of thumb: e.g the number of samples per rise time of the closed loop system should be between 4 and 10. More such rules are found in [Computer Controlled Systems, 1990]. These rules give a large negotiable range of QoS levels. An explicit mapping between the timely properties of the feedback system (such as period and jitter) and its qualities, can give a larger degree of freedom to the designer to make trade-off between applications. Timing problems can be divided into control delay, jitter and effects of transient errors, see [Wittenmark et al., 1995] and [Törngren, 1998]. Control delay is the time between the sampling instance and the corresponding actuation. One important goal in controller design is to keep the control delay as short as possible. Jitter is defined by IEEE as “time-related, abrupt, spurious variations in the duration of any specified related interval”, and arises e.g. due to the clock drift, the scheduling algorithm and the use of specific hardware (e.g. cache memory). Transient errors can occur if a message on a network is corrupted. In the analysis and design of controllers, control delay and jitter are often assumed to be negligible and it is assumed that there are no transient errors.

2

What are the advantages of QoS? It provides graceful degradation, the application is decoupled from resource availability and capacity, and QoS level adjustment is a way to increase overall system utilization. The property of graceful degradation can for example be utilized to recover from a subsystem failure; the idea is that a system which experiences a permanent failure still ought to fulfil its mission, but with a lower quality than would be normally expected. The decoupling of hardware resources from the code can for example facilitate redesign and upgrade during the lifetime of the product. Variants of a product rendering a large number of combinations of machine elements, hardware and software, might be easier to maintain if the property of decoupling is used in a clever way. What are the drawbacks of QoS? One question is if it is applicable to safety-critical applications. The flexibility of QoS contrasts to the need for predictability. It is a possibility to use QoS in the decision to migrate tasks to other nodes after a subsystem failure. The QoS framework does not assume any specific scheduling strategy and suitability to safety-critical applications depends on the fault-tolerance given by the scheduling strategy. Another drawback is that it seems as the broker in a distributed system has to be centralized. This is not specific to control applications. The quality can also be difficult to measure objectively. A typical embedded computer control system have tasks and messages for applications not intended for automatic control. The broker has to weigh applications with fundamentally different QoS characteristics to find an optimal (or feasible) distribution of resources. How should applications for control and for other purposes be mixed?

2 Related work on QoS The QoS concept comes from the research area of networked multimedia and telecommunication systems, where high-speed networks are of major research interest. Research progress in these areas could be transferred to other areas. A few authors have combined QoS with automatic control. Many authors deal with the problem to guarantee a bandwidth requirement on a scarce resource and not with synchronization issues. In [Aurrecoechea et al., 1997] a list of specifications of QoS policies and requirements for communication in multimedia is given, and is here outlined in short: • Flow synchronization - Synchronization tightness between multiple flows. E.g. the phase lag between two concurrent task chains must be small. • Flow performance - Performance requirements are specified for e.g. bandwidth, jitter and loss rate. • Level of service - The degree of end-to-end resource commitment required. This can be e.g. deterministic, predictive or best effort. The level is a specification on the degree of guaranteed service. • Management policy - Heuristic algorithms govern the behaviour in various situations, for example what actions to take if a contracted QoS is violated; what should be done if a request can not be serviced? • Cost of service - The price paid by an application for using a level of service. Without paying a price the user will select the highest level of quality.

3

The paper also argues for a generalized framework for all kinds of applications and stresses the end-to-end issue: much work has been devoted to individual layers (e.g. communication or scheduling) and not to the overall architecture. Below is a list of principles that should govern the typical features in a multimedia system: • Integration principle - Each subsystem in the chain of flow has to provide QoS configurability. • Separation principle - States that the work done by the applications and the QoS management should be functionally separated in the framework. • Transparency principle - Applications should be isolated from the underlying complexity of QoS specification, control and management. • Multiple time scales principle - Functions have different time scales, e.g. control and management. • Performance principle - Some artifacts (e.g. components, protocols) have to be avoided not to cripple high performance; this is not a very clear principle. An algorithm can have a flexible computation time, for example: a longer computation time renders a more accurate answer or a change of compression algorithms gives a shorter computation time with a lower compression rate. The application is adaptive if it itself can increase or decrease the amount of resources it requires while running. This is called imprecise computations in [Liu et al., 1991] and called best effort QoS management in [Diot et Seneviratne, 1997]. In the latter paper guaranteed QoS management denotes a QoS negotiation model where all requirements of the applications are know by a central coordinating management function. The problem with best effort is that the distribution of resources can be unfair and fluctuate cyclically if decisions are made from feedback information. The resource management should have information about the whole system. [Diot et Seneviratne, 1997] argues that neither the best effort nor the guaranteed model of QoS is efficient, hence a combined model is proposed; the adaptive applications run in a two level hierarchy: A global level to interact with users and an application level where each application adapts to the resources give by the global level. The global level has an admission and information function and the local level controls the actual resource management. A paper not totally devoted to multimedia applications is [Hull et al., 1998]. It extends the QoS model to encompass output quality to depend explicitly on input quality. If the quality is low on the input side, then the output will suffer from low quality if the processing between input and output does not enhance quality. A user node (consumer only) is connected with a source node (producer only) via other nodes, which are both producers and consumers at the same time. This can be described with the usual precedence graph. A reward is constructed as a function of both the resource allocation for the task and of the input quality. The paper discusses how to compare QoS characteristics if they depend on each other. For example, the control of one characteristic can have impact on the quality of another characteristic. A parameter might only be applicable if other parameters are within specified boundaries, e.g. it is irrelevant to use the characteristic computational delay if the period is too long to guarantee stability of the application. These two things can e.g. be visualized by a multi-dimensional graph. The need for a simple schedulability test is also stressed in the paper.

4

QoS in automatic control is treated in [Abdelzaher et al., 1997] which seems to be the first paper with this combination. The QoS model proposed is used together with a service which manages a pool of distributed processing resources. The idea is to give each task the best level of service while maintaining a satisfactory distribution of tasks on the processing resources. The contention between different applications is based on rewards depending on guaranteed level of service. The total reward for the manager should be as high as possible. An application adds a high reward to the total reward if serviced at a high level. This is a basic working principle of any QoS management algorithm. In this algorithm 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. A rejection penalty can be thought of as a negative reward value. The broker tries to increase the degree of satisfaction of the total system by having as high reward and as few rejections as possible. In case of overload the broker can renegotiate QoS levels with the applications. If the optimization algorithm on one processing unit rejects a request, it can be transferred by the load-sharing algorithm to another processor. From a control point of view an interesting feature is that different code modules can be invoked depending on the selected QoS level, i.e. depending on the sampling period. Computational redundancy intended for fault-tolerance purposes is a natural pool of resources in case of temporary partial overload as long as a fault is not prevalent. The simulation of an F16 fighter aircraft exemplifies the model. It is shown that the proposed model outperforms binary admission schemes and achieves higher “application perceived system utility”. The latter is subject to further study: quantification should be used to compute reward and penalty values but that is not exercised in the paper. A paper which does not explicitly mention QoS is [Seto et al., 1994], where a model to select control task periods (sampling periods) is proposed. The periods are allowed to vary within a range, to optimize the use of limited computational resources. The performance of a sampled controller depends on the sampling period. The function to be optimized is the weighted sum of individual quadratic loss functions (which often is equivalent to an energy relation). The optimization is based on a monotonically decreasing convex time value function which is the difference between the performance index for the sampled controller and the performance index for the continuous time optimal controller. A quadratic loss function can be used to transform a mathematical description of the process behaviour to an exponential decay function. The transformation is in most cases non-trivial and involves several approximations. A weighted sum of decreasing convex time value functions is formed to relate the importance of the tasks. A task for non-control purpose which do not have performance indices or cannot change period can not take part in the optimization. A schedule (in this case Earliest Deadline First) is then employed. A feasible schedule is found by altering the periods and at the same time optimizing the weighted sum (weights must be assigned first). Close to QoS is the notion of benefit function. The paper [Jensen, 1992] disagrees with the common use of “hard” versus “soft” deadlines, where “soft” means non-deterministic and includes everything that does not fall under the “hard” category. This division is oversimplified and unrealistic and will lead to a non-cost-effective solution for asynchronous decentralized real-time systems. Instead, the operating system together with the application must make a “best effort” and adapt to a dynamic situation by making trade-offs between “situation coverage” and optimality (the system performs best if all the cost of hard deadlines are met); the goal is to finish the mission in an acceptable

5

way and not use costly methods. A deadline should be expressed with a benefit function but it does not have to be a monotonically decreasing convex function as in [Seto et al., 1994]. The importance of a function, which is orthogonal to its urgency, can be expressed as a scaling of the benefit function. In this way different applications can be weighted according to both importance and slack time. An idea is to apply micro economic models, [Fulp et al., 1998]: producers own resources which consumers pay for. The idea is not new, but it is an approach to distribute the QoS negotiation. The producers charge continuously consumers with a price which reflects the supply and demand. Consumers use a “budget flow” (e.g. in dollars per time units) to pay the producers. Admission control is exercised by a minimum price. Price stability and pareto optimality are imperative goals for this strategy. This “network economics” view does not contribute with any useful solutions from the theory of economics, but is merely a different way to look at the problem. In [Abdelzaher et al., 1998], the contract between the broker and an application specifies both reward value and violation penalty for a QoS level. The violation penalty is paid if the service level can not be held. A rejection penalty, which is the cost to throw away a request for execution, is thus avoided, cf. [Abdelzaher et al., 1997]. It is argued that the method of rejection penalty does not apply to many applications because no contract has been established. Furthermore, starving of low prioritized messages and tasks should be avoided. To adapt fast to load changes a fast feedback loop monitors the load and cooperates with the time consuming and slow periodic optimization algorithm. It is claimed that the general QoS optimization is NP-complete, because it derives from the multiple-knapsack problem. A classification of QoS applications is made in [Rajkumar et al., 1998]. An application can have single or multiple QoS characteristics (in the paper called dimensions), e.g. response time, and also single or multiple resources, e.g. CPU and network. Applications are independent of each others and have a convex utility function. The total reward is computed by taking the sum of weighted utility functions. It is proved that finding the optimal resource allocation is NP-hard (the knap-sack problem). If the additional benefit from adding a characteristic always is very high, it seems reasonable to include this characteristic as a minimum requirement and exclude it from the calculation of the total utilization. Trade-offs between resources should be possible, e.g. CPU time can be traded with network bandwidth by the use of compression algorithms.

3 Problems and challenges The majority of the papers about QoS deal with multimedia or telecommunication applications. What are the differences and similarities between multimedia and telecommunication compared to control applications? First of all the hardware and the operating systems and network protocols are generally more homogenous in control applications, especially if they are embedded. Problems in the area of multimedia and telecommunication arise due to heterogeneous systems: different network types and scheduling policies are used along the transmission path. This requires some sort of translation services between standards, [Nahrstedt, 1995] gives an overview. Typical multimedia or telecommunication applications can of course be used together with control; one example is tele-operation of a vehicle. The end-to-end delay and jitter are in both cases the fundamental issues. In an embedded system the number of tasks are 6

often known pre-runtime and this reduces the need for the flexibility the QoS approach gives. There is a possibility that the quality can be measured or estimated in a control system and be used as a performance index to find optimal and objective QoS levels for the system.

3.1 Measuring the QoS characteristic The QoS characteristic must be possible to measure or estimate. The characteristics have to be time dependant and possible to quantify as sampling time (control interval) and deadline for example. The characteristic can also be expressed indirectly in terms of control performance. This requires a mapping from time related qualities of the computer system to control performance related to the qualities of the process and the controller; for example, how much will control performance change when the sampling period and the task priority are changed? This is a more appealing way than specifying the characteristic directly in terms of computer related entities. It could also be possible to estimate control performance on-line with a kind of diagnostic feature. If the parameters of the process are changing over time, this might be an idea, because of the changing needs of the process, e.g. sampling interval depending on any flow or production rate. There are few references in this research area. The time related performance properties could be analysed in conjunction with control design. The performance for different QoS levels with respect to the timely interaction can either be known pre-runtime, e.g. for sampling period, or impossible to know pre-runtime, e.g. jitter in most cases.

3.2 Heuristics and scheduling The QoS framework does not imply any specific scheduling or synchronization policy. There are a multitude of scheduling strategies, is there any particular class of scheduling strategy which is suitable? Deadlines might very well be hard; this is not in contradiction to the notion of QoS. Off-line scheduling can on the other hand be disregarded. The negotiation forms a feedback path where vital parts of the negotiation will have to be heuristic algorithms. One question is how to compare negotiation algorithms that are invented. Ideas and guidelines how to reason about the negotiation heuristics can be borrowed from other research areas. It should be possible to have a generalized framework for different kinds of applications.

3.3 Invocation of the QoS management routine How often is it possible to change QoS levels without getting problems with e.g. a varying sampling period? The negotiation is a feedback system and might become unstable (oscillating) if badly designed. An unstable negotiation will certainly be bad for the applications. It is possible to get a computer system where the load of the resources is alternating (see [Diot et Seneviratne, 1997]) together with the level of quality. This is something which must be avoided. QoS seems to be applicable only when the execution or communication lifetime is long enough to make a QoS renegotiation affordable. The cost of the renegotiation can be derived from any transient degradation of quality 7

experienced at the change of the operating target. The renegotiation must not give too much overhead in scheduling. The duration of an overload must be long enough to undertake the cost involved in accommodating periods for other tasks; maybe tasks need to be moved to other nodes. A question is if QoS can help to solve weaknesses in an off-line calculation of worst case execution time, WCET. The change of level must be bumpless, in the same way as a mode change. A problem to solve is how to achieve bumpless transfer when sampling period and possibly controllers are switched. For a general technique for this and related problems, see [Hanus et al., 1987].

3.4 Control algorithm From a quality point of view, tasks can be classified in two categories: a) degenerate the task can not compensate for low input quality, and b) output quality improves if the task is allowed to continue to execute, see [Hull et al., 1998]. An example of the first category is the common PID controller and an example of the latter is the newer MPC, model predictive controller. The controller can make a best effort with the given resources and this knowledge can be used in the QoS management.

3.5 Combination of QoS characteristics If both sampling period and jitter are the QoS characteristics, how then to specify and use QoS levels with two degrees of freedom? [Hull et al., 1998] gives a short discussion on the subject. It is also possible that a QoS characteristic only has the values true or false and not a continuous range of levels. With multiple applications, given multiple characteristics and multiple resources, the complexity becomes high. In [Abdelzaher et al., 1997] the task period and deadline are used as the characteristics and a pool of distributed resources is used, but it is not clear exactly how they are mixed.

3.6 Fault tolerance The primary question is if QoS in a safety-critical application is possible at all. Fault tolerance is the important issue when designing a safety critical system. There is a spatial and a temporal dimension in a fault tolerant system. Redundant hardware cover up transient and permanent hardware failure. Tasks must be redirected to other nodes and messages must be sent through other channels if one piece of active hardware fails (passive redundancy). Redirecting tasks and increasing the sampling period of tasks in the remaining units is a way of coping with a loss of a unit, as proposed in [Wittenmark et al., 1995]. The task must of course be possible to migrate to other nodes. The migration can be preallocated. Can QoS improve fault tolerance by e.g. graceful degradation? Or is fault tolerance a binary requirement so vital it cannot be negotiated? A question is if it should be possible to reject an already “guaranteed” request if all applications already run at their lowest QoS level. This question is general to QoS and not specific to automatic control. If every task is run at its QoS level corresponding to its worst performance and the whole system has spare time and performs as required, then the system is not Pareto optimal (the term is borrowed from economics and is a weak optimality criterion), 8

which means that at least one task can be better off without making anyone else worse. If the system does not have any spare time left in the previous scenario, there can be no further graceful degradation and new arriving tasks or messages can not be serviced. All mission critical tasks must of course be guaranteed service.

4 Summary and ideas for further work The notion of QoS in conjunction with automatic control has been discussed. Most papers on QoS management deal with multimedia and telecommunication applications. Feedback control applications share important time related demands on the computer system with these applications. Because of this, it is worth a try to apply the QoS framework to feedback control. QoS is most often applied to communication or the whole distributed computer system. A number of problems and questions arise. These are touched upon briefly in the following and points to future work in the area. In a QoS framework a number of applications negotiate with a broker for a feasible quality to be delivered. The notion of QoS has features which makes it interesting for use in distributed control of dynamic systems: it provides graceful degradation, the application is decoupled from resource availability and capacity, and QoS level adjustment is a possible way to increase overall system utilization. One problem is the scarcity of theory which tells how control performance depends on the timing interactions. The existing theory needs to be tailored to fit into the framework. There is a freedom to choose scheduling strategy within the QoS management. The question is: what is a suitable scheduling strategy. The scheduling affects the design of the QoS manager. Is it possible to formally prove or verify any supposed hard real-time guarantees, or at least performance, not only demonstrate it? This depends very much on the scheduling strategy used. Synchronization issues like precedence constraints and critical section also come with the scheduling strategy. Fault tolerance in (embedded) safety-critical systems must ensured. Can QoS improve the fault tolerance, or does it make fault tolerance impossible? A drawback is that it seems as the broker has to be centralized. This problem is generic and not specific to control applications. How can a decentralized broker be constructed? The quality can be difficult to measure objectively. This is more a generic problem, because the control theory gives us a tool to define goodness. The problem arises when control applications should co-exist with other applications and this is quite common.

5 References T. Abdelzaher, E. Atkins, K. G. Shin, “QoS Negotiation in Real-Time Systems and Its Application to Automated Flight Control”, pp. 228-238, IEEE, 1997.

9

T. Abdelzaher, K.G. Shin, “End-host Architecture for QoS-Adaptive Communication”, IEEE, 1998. C. Aurrecoechea, A. T. Campbell, L. Hauw, “A Survey of QoS Architectures“, Report from Columbia University New York NY 10027, 1997. K.-J. Åström, B. Wittenmark, “Computer Controlled Systems, Theory and Design”, 2nd edition, ISBN 0-13-172784-2, 1990. C. Diot, A. Seneviratne, “Quality of Service in Heterogenous Distributed Systems“, IEEE 1060-3425/97, p. 238 - 247, 1997. E. W. Fulp, M. Ott, D. Reininger, D.S. Reeves, “Paying for QoS: An Optimal Distributed Algorithm for Pricing Network Resources”, IEEE 1998. R. Hanus, M. Kinnaert, J.-L. Henrotte, “Conditioning Technique, a General Anti-Windup and Bumpless Transfer Method”, Automatica, Vol. 23, No. 6, pp. 729-739, 1987. D. Hull, A Shankar, K Nahrstedt, J. W. S. Liu, “An End-to-End QoS Model Management Architecture“, Report from Dep of Computer Science, University of Illinois, Urbana. 1998. D. Jensen, “Asynchronous Decentralized Realtime Computer Systems“, NATO Advanced study Institute on Real-Time Computing, Sint Maarten, 21p, October 1992. Open Distributed Processing - Reference Model Part 2: Foundations [ITU-T Rec ommendation X.902, ISO/IEC 10476-2]. J.- W. S. Liu, K.-J. Lin, W.-K. Shih, A. Chuang-shi Yu, "Algorithms for Scheduling Imprecise Computations", IEEE computer, p58-68, 1991. K. Nahrstedt, “End-to-end QoS Guarantees in Networked Multimedia Systems”, ACM Computing Surveys, Vol 27 no 4, December 1995. R. Rajkumar, C. Lee, J.P. Lehoczky, D.P. Siewiorek, “Practical Solutions for QoSbased Resource Allocation Problems”, IEEE 1998. D. Seto, J. P. Lehoczky, L. Sha, K. G. Shin, “On Task Schedulability in Real-Time Control Systems”, unknown publication place, not before 1994. M. Törngren, “Fundamentals of Implementing Real-Time Control Applications in Distributed Computer Systems”, Real-Time Systems 14, p219-250, Kluwer Academic Publishers, 1998. B. Wittenmark, J. Nilsson, M. Törngren, “Timing Problems in Real-Time Control Systems“, ACC 95, 1995.

10

6 APPENDIX: Glossary of basic QoS Framework taken from ISO/IEC draft The QoS Framework by [Open distributed processing, OSI] defines terminology and concepts to assist in the design and specification of systems, but does not describe any QoS mechanism in detail. The guideline preceding the glossary is an attempt to make the terminology more digestible. Quality of Service (QoS) A set of qualities related to the collective behaviour of one or more objects.

6.1 Guideline to the glossary Note that some documents do not make a difference between the terms QoS parameter and QoS characteristic. The notion of QoS category has been introduced by ISO/IEC to catch the specific requirements typical for an application or a whole area of technology. Also note that there is nothing stated about reward functions, for example QoS level is not defined. The terms QoS negotiation and broker are not defined by ISO/IEC and hence not found in the glossary. Figure 2 shows the interaction between the user and the service provider. The user sets the QoS requirements for the QoS characteristics. Figure 3 zooms in on the block labelled QoS maintenance. The action of first setting up the service is called QoS establishment, thereafter the act of maintaining the specified requirements is called QoS maintenance. Service User QoS requirements

Service Provider QoS manager with a QoS policy

QoS establishment QoS maintenance

Delivered service

FIGURE 2. Overview of the negotiation process.

The QoS information is called QoS parameter between two entities and QoS context within an entity. QoS information is also classified into QoS requirements and QoS data.

6.2 QoS concepts and modelling definitions QoS attribute An attribute of a managed object relating to QoS. QoS category A group of user requirements that leads to the selection of a set of QoS requirements.

11

QoS characteristics A quantifiable aspect of QoS, which is defined independently of the means by which it is represented or controlled.

QoS operating target with a set of QoS characteristics

Setpoint characteristics QoS control

QoS enquiry QoS measurements

QoS monitoring

QoS alert

Measured characteristics QoS establishment QoS maintenance

QoS management functions FIGURE 3. A more detailed view of the negotiation process.

QoS management Any set of activities performed by a system or communications service to support QoS monitoring, control and administration. QoS mechanism A specific mechanism that may use protocol elements, QoS parameters or QoS context, possibly in conjunction with other QoS mechanisms, in order to support establishment, monitoring, maintenance, control, or enquiry of QoS. QoS policy A set of rules that determine the QoS characteristics and QoS management functions to be used.

6.3 Information-oriented definitions QoS context QoS information that is retained, interpolated or extrapolated by one or more entities and used in managing QoS: it is further classified into requirement context and data context. QoS data QoS information other than QoS requirements, e.g. warnings, QoS measures and information used in QoS enquiries. QoS information Information related to QoS: it is classified into QoS context (when retained in an entity) and QoS parameters (when conveyed between entities); and it is classified into QoS requirements (if it expresses a requirement for QoS) and QoS data (if it does not). QoS measure One or more observed values relating to a QoS characteristic. QoS parameter QoS information that is conveyed between entities as part of a QoS mechanism; parameters are classified into requirement parameters and data parameters; the information conveyed may relate to one or more QoS characteristics. 12

QoS requirement QoS information that expresses part or all of a requirement to manage one or more QoS characteristics, e.g. a maximum value, a target, or a threshold; when conveyed between entities, a QoS requirement is expressed in terms of QoS parameters. QoS operating target QoS information that represents the target values of a set of QoS characteristics derived from QoS requirements.

6.4 Management function definitions QoS alert The use of QoS mechanisms to signal to an entity that some limit has been reached or threshold crossed. QoS control The use of a mechanisms to modify conditions so that a desired set of QoS characteristics is attained for some systems activity, while that activity is in progress. QoS enquiry The use of QoS mechanisms to determine properties of the environment relating to QoS in which communications take place. QoS establishment The use of QoS mechanisms to create the conditions for some systems activity, before that activity occurs, so that a desired set of QoS characteristics is attained. QoS maintenance The use of QoS mechanisms to maintain a set of QoS characteristics at required values for some systems activity, while the activity is in progress. QoS management function A function specifically intended to meet a user or application requirement for QoS, provided by one or more QoS mechanisms. QoS monitoring The use of QoS measures to estimate the values of a set of QoS characteristics actually achieved for some systems activity.

13