Control Performance-Aware System Level Design

Transcription

1 Control Performance-Aware System Level Design Nina Mühleis, Michael Glaß, and Jürgen Teich Hardware/Software Co-Design, University of Erlangen-Nuremberg {nina.muehleis, glass, Abstract Control applications are more and more an integral part of modern embedded systems. As a result, considering the quality of control applications as a design objective while respecting design constraints like stability becomes mandatory. The work at hand proposes a fullyautomatic toolflow at the Electronic System Level (ESL) that enables the optimization of a system implementation with quality of control being introduced as a principal design objective. The existing gap between mathematically well-defined models used for system synthesis and exploration on the one side, and common techniques for the analysis of control quality on the other, is bridged by employing a virtual prototype of the system implementation. A case-study gives evidence of the applicability and efficiency of the proposed methodology. I. INTRODUCTION In modern means of transport like the automotive and avionics domain, more and more control applications are carried out by heterogeneous distributed embedded systems that may consist of up to hundreds of Electronic Control Units (ECUs) as well as various sensors, actuators, and bus systems. For example, X-by-Wire applications substitute mechanical and hydraulic systems for steering or braking by distributed hardware/software systems that execute control tasks on ECUs and communicate via shared media. Here, the quality of the control applications is one of the key factors that determine their applicability and quality. Designing such complex systems has become a challenging task that requires computer-assistance. In recent years, Design Space Exploration (DSE) approaches at the Electronic System Level (ESL) have been developed that automatically investigate the tremendous design space and search for implementations that are optimal with respect to several and often conflicting design objectives. Not only design objectives like monetary costs, power consumption, or dependability have to be taken into account. In fact, it is typically a much harder task to respect given design constraints arising from mounting space limitations, wiring, or the stability of control applications. In a process termed system synthesis, the architecture, task binding, message routing, and scheduling of a candidate implementation is derived and evaluated with respect to given design objectives and constraints. Given the immense degree of freedom present during system synthesis, the characteristics of each candidate implementation may vary significantly. Note that DSE and system synthesis typically require mathematically well-defined models like graph-based representations and well-defined Models of Computation. Since control performance is of utmost importance, a particularly interesting task during system synthesis is controller synthesis. In system level design of control applications, the controller itself is typically implemented as a set of periodic tasks that communicate via periodic messages. However, in modern embedded systems, there is no dedicated subsystem per control application present, but the tasks of different applications have to share computation as well as communication resources, causing varying end-to-end latencies. To achieve good control performance, these delays have to be taken into account during controller synthesis. This is known as Control-Scheduling-Co-Design [1]. Here, it is well known that not only the maximum or average delay contributes to the controller performance, but also the distribution of the delays [2]. Known approaches to the analysis of control performance typically assume a fixed architecture and task mapping while taking into account the effects of different scheduling strategies [3], [4]. However, given the significant variance in architecture, task mapping, routing, and scheduling considered in this work, there exists a huge gap between the model of the implementation and the required data for the control performance analysis. Contribution. This work closes the gap between the Design Space Exploration (DSE) model and the control performance analysis by a fully-automatic employment of a virtual prototype of the implementation. The virtual prototype is an automatically derived executable model of the implementation that takes the current architecture, task binding, message routing, and scheduling into account simultaneously. Using the virtual prototype, all required data, particularly, the distribution of delays are determined. The resulting toolflow implements an ESL design methodology that is capable of concurrently optimizing control quality as a principal design objective together with classic design objectives. Moreover, it enables to automatically take all design constraints like the stability of the control application into account. Outline. The rest of the paper is structured as follows: Section II discusses related work. Section III introduces the ESL design approach and the system and analysis models. The virtual prototyping approach that bridges the gap between ESL design and control quality analysis is presented in Sec. IV. Sec. V presents experimental results before the paper is concluded in Sec. VI.

2 II. RELATED WORK Improving controller performance in distributed embedded system is a widely studied area. This is typically done by optimizing the scheduling parameters such as periods or priorities. In [5], several control tasks running on a single processor are analyzed. Here, the control performance is improved by finding optimal periods for each controller. However, this approach does not take the delays of the control loops into account. Furthermore, only the periods but not the priorities are determined. Analytical solutions to improve control performance by considering timing delays are employed in [6]. In [4], an analytical approach is presented that improves three instead of just one control quality metric as done in other approaches. In [3], [7], the authors present a methodology to consider delay distributions and not just worst case delays while optimizing the control performance. This is done by simulation. The periods and priorities of the control tasks are determined so that one cost function is minimized. However, the mapping of the tasks to the architecture is fixed. In [8], the authors define a three-level concept to analyze and implement distributed control systems: (1) the control system level, (2) the physical architecture, and (3) the scheduling analysis. This approach focuses on finding a correct and robust implementation of a control application. However, no optimization possibilities are taken into account. III. SYSTEM LEVEL DESIGN This work introduces control quality as a principal design objective into Electronic System Level (ESL) design. The vast majority of ESL design approaches, see [9] for a survey, is inspired by the Y-chart approach as depicted in Fig. 1. Given is an application that models the functionality and an architecture that models the available resources. A Design Space Exploration (DSE) aims to offer a set of high-quality system-level implementations to the designer who choses one (or several) to be refined in the next lower level of abstraction. The set of high-quality implementations results from the presence of multiple, often conflicting objectives that makes DSE a Multi-Objective Optimization Problem. During DSE, implementations are obtained by mapping the application onto the architecture in a process termed system synthesis. The quality of each implementation with respect to given objectives and its compliance with given design constraints is determined in an evaluation step. Introducing a novel design objective (design constraint) requires (a) an adequate modeling and consideration during system synthesis and (b) providing an evaluation technique to quantify the design objective (to check for compliance with the design constraint). This section introduces the used system model and system synthesis approach. Afterwards, the proposed modeling of feedback control systems and the employed control quality analysis technique are presented. Fig. 1. application system synthesis architecture design space exploration evaluation system-level implementation Overview of the Design Space Exploration A. System Model and System Synthesis For the DSE, a specification defines the available hardware components as well as the processing tasks that need to be distributed in the system. This graph-based specification (see Fig. 2(b)) consists of the architecture, the application, and a relation between these two views, the mapping constraints: The architecture is modeled by a graph g a (R, E a ) and represents all available interconnected components, i. e., hardware resources. The vertices r 1,..., r R R represent the resources, e. g., ECUs, buses, sensors or actuators. The edges E a model available communication links between resources. The application is modeled by an application graph g t (T C, E t ) that represents the behavior of the system. The vertices t 1,..., t T T denote processing tasks and the vertices c 1,..., c C communication tasks. The directed edges e E t (T C) (C T ) denote data dependencies between tasks. The relation between architecture and application is given by a set of mapping edges E m. Each mapping edge m 1,..., m Em E m is a directed edge from a task to a resource, with a mapping m = (t, r) E m indicating that a specific task t can be mapped to hardware resource r. From the specification of the system that implicitly includes all design alternatives, a system level implementation has to be deduced, respectively synthesized. This implementation corresponds to the found hardware/software system that will be implemented. The synthesis thereby involves the following steps: The allocation α R denotes the subset of the available resources that are actually used and implemented in the embedded system. The binding β E m is a subset of the mapping edges in which each processing task is bound to a hardware resource that executes this task at runtime. The routing γ R of each communication task is a subset of resources over which a communication

3 t s r sen1 r sen2 controller sensor c sc w m actuator u x plant y t c c ca r cpu1 r cpu2 t a application r act architecture (a) controller (b) specification Fig. 2. Shown is (a) a controller as a state space model. Its proposed transformation into a specification, see (b), is depicted by dotted edges. The resulting application consist of three tasks with a sensor task t s modeling the sensor, a control task t c modeling the controller including the input vector, and an actuator task t a modeling the actuator. An architecture is depicted in the specification as well, consisting of two different sensors suitable to carry out the sensor task, two CPUs suitable to execute the control task, and an actuator that carries out the actuator task. The possible mapping of tasks to resources is depicted by the dashed edges. task is routed. The schedule φ can be either static (with predefined start times of the tasks) or dynamic (with assigned periods or deadlines to the tasks). Thus, an implementation is given as a tuple (α, β, γ, φ). B. Feedback Control Systems In this paper, focus is put on applications that serve as feedback controllers represented in the state space model. The structure of a quite general control system is given in Fig. 2(a): The current state of the system x is sampled by a sensor and a controller computes the new control signal which is send to an actuator. The actuator generates the control law u which affects the behavior of the physical system that is also called plant. The most general state-space representation of a dynamic system is given in Eq. (1) and (2). y(t) = C x(t) (1) ẋ(t) = A x(t) + B u(t) (2) Here, x is called the state vector, y the output vector, u the control vector, and A, B, and C are matrices. The control vector u is determined by Eq. (3). u(t) = R x(t) + M w (3) Here, R is the control matrix and w the input vector. The task of the control engineer is to assign the control matrix R such that the system shows its desired behavior. C. Control Loop Model To take into account feedback control systems during DSE, this section proposes a method to integrate control loops using a graph-based representation, i. e., as an application graph g t (T C, E t ). In a multi feedback controller design problem, a system specification consists of a set of plants P where each plant p P can be described by a continuous-timelinear model as introduced in Eq. (1) and (2). Thus, the application graph g t of such a system is defined as: g t = p P a p (4) Here, each plant p is controlled by an application, modeled as a control application graph a p. Looking at a single control application, the control application graph a p has to represent the control loop of its state space model according to Fig. 2. Each control application graph a p describes the digital part of the feedback control system: the sensor sampling the state x p of plant p and preprocessing this data; the controller computing the control law; and the actuator generating the control signal u. This leads to the following definition of a control application graph a p of a feedback controller design problem for a plant p: The sensor tasks S p that model the sensors monitoring the plant p. Each vertex s p1,..., s Sp S p denotes one single sensor task. The controller tasks O p where each vertex o p1,..., o Op O p denotes a processing task computing a part of the control law. The actuator tasks U p where each vertex u p1,..., u Up U p denotes a processing task to generate one control signal for plant p. The communication tasks C p where each vertex c p1,..., c p Cp C p represents a data transfer. The directed edges e p E p (S p O p ) (O p O p ) (O p U p ) model the data dependencies between the tasks.

4 Thus, a control application graph a p is defined as a p ((S p O p U p C p ), E p ). Note that this definition allows multiple sensor, controller, and actuator tasks that may be required to control a single plant. D. Quality of Control Loops Evaluating feedback control systems requires a method to assign quality metrics to an implemented controller. Therefore, techniques from the well-studied area of control engineering, the optimal control theory, may be applied. Here, the matrix R, see Eq. (3), should be assigned such that an objective is minimized. One common objective is the quadratic cost J. J = 0 x(t) T Q x(t) + u(t) T W u(t) dt. (5) Consider a system being in state x s. The controller should find the control law u so that the system ends in state x e. Now, the quadratic cost estimates two criteria: (1) the delay for the transition from state x s to x e and (2) the control energy u that is needed to transfer the system from state x s to x e. The matrices Q and W prioritize the different states in the vector x and u. In classical control theory, the engineers consider just constant sensor-actuator delays when calculating the quadratic cost. Sensor-actuator delay addresses the time from sampling the actual state of the plant x and updating the control law u. This time is called end-to-end latency. For a constant end-to-end latency and a given sampling period h, it is possible to find a control matrix R that minimizes the cost J, see [10]. One example for such controllers are Linear Quadratic Regulators. Now, let several control applications be executed in parallel in a distributed fashion, resource contention on shared components like processors and buses influences the end-to-end latencies. Thus, the approach presented in this work takes varying sensor-actuator delays into account. For this purpose, MATLAB in combination with the Jitterbug toolbox [11] is used to compute the quadratic cost. The varying delay is modeled by a delay distribution that is respected by the toolbox. To calculate this delay distribution and determine the quality of a set of control applications, this paper proposes a method that employs virtual prototyping techniques. IV. VIRTUAL PROTOTYPING FOR QUALITY EVALUATION In order to consider control quality during DSE, the quadratic cost of feedback control systems is introduced as a principal design objective. The DSE iteratively generates implementations. Each implementation represents a concrete allocation, binding, schedule, and routing. In the presented approach, the implementation obtained by the system synthesis is used to generate a Virtual Prototype (VP). Besides the implementation, some parameters of the resources like their capacity in number of instructions per second and of the tasks like Fig. 3. system synthesis virtual prototype quality numbers control quality evaluation Control quality evaluation during Design Space Exploration their computational demand in number of instructions are required for the VP. The number of instructions that each control application has to execute may be estimated automatically using high-level synthesis techniques or manual reference implementations. Using the VP, a timing simulation for the control application determines the delay distribution that represents the delays occurring in the system caused by scheduling on resources and communication. This delay distribution is transfered to the control quality evaluation where the physical plants as well as the timing of the control applications are considered. As result, this evaluation returns a quality numbers, i. e., the quadratic cost to the system synthesis. Figure 3 gives an overview of this evaluation. A. Performance Simulation In order to calculate the delay distribution, a SystemC performance simulation that employs a VP of the system is applied. In general, the VP consists of an application enriched with architecture information. To execute a performance simulation for a VP, the concept of Virtual Processing Components (VPC) [12] is used, a custom library for performance simulation of SystemC models. VPC has to be configured with the implementation determined by the system synthesis. A VPC model consists of three components: (1) the resources in the system, (2) the mapping of the application to the resources, and (3) the routing that specify the communication paths. Each node in the architecture graph g a represents a resource modeled in the VPC library. Resources include communication as well as computation resources. To allow execution of multiple tasks running on one VPC resource, a scheduling policy for each VPC resource is determined from the implementation. Each node from the application graph g t is mapped to one VPC resource. This mapping is given by the implementation. For a proper timing simulation, the computation delay is determined by the mapping. This delay depends on attributes of the resources like the operations executed per second and of the task like the number of instructions. During simulation, execution times and communication delays are traced for each control application by the VPC. These delays vary in each period because of scheduling on communication and computation resource. For each control application, a delay distribution is

5 determined from the trace. This distribution is necessary to evaluate the control quality in the evaluator. B. Computation of Control Quality To determine the control quality, it is necessary to simulate the control applications in the physical environment. For this purpose, the MATLAB based toolbox Jitterbug [11] is applied. This toolbox is able to account for the delays caused by the digital system. The delays for the VP are received by the VPC simulation as described in the previous section. Each single control loop is evaluated separately and contributes to the quality of the whole system. For each control loop, Jitterbug needs three inputs: (1) the differential equation of the plant (physical system), (2) the controller, and (3) the delay distribution occurred for the control loop. Due to the fact that each control loop is evaluated separately, the overall quality is given as: J = p P λ p J p, (6) where P is the number of plants in the system and λ p is a weighting factor for control loop p. Note that the employed DSE could also take into account each J p as a principal design objective. However, increasing the number of design objectives by P may deteriorate the DSE. An important constraint is that each control loop has to be stable. The stability test is done by Jitterbug. Otherwise, the overall quality J is set to. As a result, a design constraint is introduced as: p P : J p 0 (7) V. EXPERIMENTAL RESULTS In this section, a case-study shows the applicability of the proposed design space exploration that considers control quality as a principal design objective. In the setup for the experiments, the architecture graph g a consists of six processing elements connected via a priority-based bus, i. e., CAN. The processing units vary in their capacity, i. e., the operations per second that can be executed and in their hardware costs. The application graph g t consists of ten control application graphs a p, each controlling a single plant p. Each control application consists of one sensor task s p, one controller task o p, and one actuator task u p. Furthermore, each application graph a p includes two communication tasks c p1 and c p2 representing the data transfer from s p to o p and o p to u p. The sensor and actuator tasks have a fixed mapping to one particular resource of the architecture g a. In contrast, the controller tasks o p may be mapped to each processing element. This leads to a design space of 6 10 = regarding the mapping possibilities of the controller alone. The communication tasks c p are mapped to the priority-based bus in g a. As plants, ten inverted pendulums are chosen. These are a common case study application in the area of control-scheduling-codesign [3], [7]. The plant of an inverted pendulum is expressed following Eq. (1) and Eq. (2) with the following parameters: A = [ 0 ] 1 g/l 0 (8) B = [0 g/l] (9) C = [1 0] (10) where g = 9.81m/s 2 is the constant of gravitation and l is the length of the inverted pendulum. The control matrix R from Eq. (3) was found by Linear-quadratic regulator (LQR) design which is supported by MATLAB. The task of the DSE is now to find a mapping and schedule so that the quadratic cost of the control application as well as the hardware cost of the resources is minimized. Therefore, the following parameters are varied during system synthesis: (1) the allocation of processing elements, (2) the mapping of control tasks, and (3) the priorities of the tasks including communication and processing tasks. Note that in this single bus system, the routing becomes trivial. The system synthesis forwards implementations to the evaluation. An implementation is feasible iff the system is scheduleable and all plants are stable. A. Design Space Exploration In addition to the control quality, it is possible to consider multiple objectives during DSE. For the following experiments, the overall hardware cost of the system, as well as the control quality are optimized simultaneously. For comparison, a reference implementation is obtained manually: First, the resources with minimum hardware cost are chosen on which the system is schedulable. The mapping of the application to the resource is done as follows: The highest priority is assigned to the application with the highest instruction count. Then, the task with the highest priority is mapped to the resource with the most number of instructions executable per second. This results in a control quality of 3, 387 and a hardware cost of 104 for the reference implementation. Now, Fig. 4 shows the the high-quality implementations found during DSE. The DSE is carried out using a meta-heuristic optimization approach, i. e., a Multi- Objective Evolutionary Algorithm as provided by the optimization framework OPT4J [13]. The number of generations is set to 500. Overall, the DSE finds 12 highquality design points as shown in Fig. 4. In Tab. I, the improvement of each high-quality implementation is compared to the reference implementation. All high-quality implementations exhibit a better control quality than the reference implementation. At the one extreme depicted as implementation C1, the control quality can be improved by up to 12 %. However, this solution is 44.3 % worse in hardware cost. For this design

6 180 C1 DSE reference TABLE I HIGH-QUALITY IMPLEMENTATIONS OBTAINED USING THE PROPOSED DSE. hardware cost C3 C4 C quadratic cost Fig. 4. High-quality implementations obtained by the control quality-aware DSE compared to the reference implementation. point, all processing elements are used, and, hence the load of each processing unit is low and contention is predominantly observed on the bus. This leads to a distribution of the end-to-end latencies with a lower variance, hence, increasing the control quality. In the other corner case, depicted as C2 in Fig. 4, only three resources are allocated, leading to a hardware cost reduction of about 25.2 % compared to the reference implementation. However, the chance that a task has to wait for access to the resource increases as multiple tasks compete.an increased variance in the end-to-end delays of the control loops, reduces the control quality. Investigating implementations C3 and C4, see Tab. I line 7 and 8 respectively, the control quality is improved by 8 % and 7 % either increasing hardware cost by 1, 9 % only or even decreasing hardware cost by 5, 9 %. In summary, the DSE finds 12 high quality solutions. In comparison to the reference implementation all solutions found by DSE are better in the control quality. Furthermore, the five solutions below the vertical line in Fig. 4 dominate the reference solution in both criteria. VI. CONCLUSION The quality of the control applications as well as essential requirements such as stability are becoming design aspects of utmost importance for future (distributed) embedded systems. As a remedy, this work proposes an approach at the Electronic System Level (ESL) that considers control performance as a principal design objective. This work presents an approach that closes the gap between a mathematically well-defined design space exploration model and a simulative control-performance analysis by a fully-automatic employment of a virtual prototype. The result is an automatic design flow, capable of optimizing multiple and often conflicting design objectives while respecting given design constraints like scheduling and stability. A case-study gives evidence of # Control Cost Improvement Quality (CQ) CQ Cost % % % % % % % % % % % % % -1.9 % % 5.9 % % 7.8 % % 15.5 % % 17.4 % % 25.2 % the importance of considering control performance as a principal design objective. The obtained high-quality implementations show an improvement in both investigated design objectives, control performance and hardware cost, with respect to a reference implementation. REFERENCES [1] K.-E. Årzén, A. Cervin, J. Eker, and L. Sha, An introduction to control and scheduling co-design, in Proceedings of IEEE Conf. on Decision and Control, vol. 5, 2002, pp [2] B. Wittenmark, J. Nilsson, and M. Törngren, Timing problems in real-time control systems, in In Proceedings of the American Control Conference, 1995, pp [3] S. Samii, A. Cervin, P. Eles, and Z. Peng, Integrated scheduling and synthesis of control applications on distributed embedded systems, in Proceedings of DATE 09, 2009, pp [4] H. Voit, R. Schneider, D. Goswami, A. Annaswamy, and S. Chakraborty, Optimizing hierarchical schedules for improved control performance, in Proceedings of SIES 10, [5] D. Seto, J. P. Lehoczky, L. Sha, and K. G. Shin, On task schedulability in real-time control systems, in Proceedings of RTSS 96, ser. RTSS 96, 1996, pp [6] E. Bini and A. Cervin, Delay-aware period assignment in control systems, in Proceedings of the 2008 Real-Time Systems Symposium, 2008, pp [7] S. Samii, P. Eles, Z. Peng, and A. Cervin, Quality-driven synthesis of embedded multi-mode control systems, in Proceedings of DAC 09, 2009, pp [8] P. Naghshtabrizi and J. a. P. Hespanha, Analysis of distributed control systems with shared communication and computation resources, in Proceedings of Conf. on American Control Conference, ser. ACC 09, 2009, pp [9] A. Gerstlauer, C. Haubelt, A. Pimentel, T. Stefanov, D. Gajski, and J. Teich, Electronic system-level synthesis methodologies, IEEE Trans. on CAD, vol. 28, no. 10, pp , [10] K. J. Astrom and B. Wittenmark, Computer-Controlled Systems: Theory and Design, 5th ed. Prentice Hall, 1996, isbn: [11] B. Lincoln and A. Cervin, Jitterbug: A tool for analysis of real-time control performance, in Proceedings of IEEE Conf. on Decision and Control, Las Vegas, NV, Dec [12] M. Streubühr, J. Gladigau, C. Haubelt, and J. Teich, Efficient Approximately-Timed Performance Modeling for Architectural Exploration of MPSoCs, in Advances in Design Methods from Modeling Languages for Embedded Systems and SoC s. Springer Netherlands, 2010, vol. 63, pp [13] Opt4J, The optimization framework for java, Version 1.3.