Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 76 2009-10-13 76 Model-Based Design for Embedded Systems Having determined a response time interval across the SC for each task, the second phase of the global system analysis is performed as usual, describ- ing the traffic timing behavior at task outputs, by using event models. Afterward, the calculated output event models are propagated to the con- nected components, where they are used as activating event models for the subsequent global iteration. If after an iteration all calculated output event models remain unmodified, convergence is reached. As the propa- gated event models contain all potential event timings—during and after the transition—the calculated task response times are considered valid. 3.6 Sensitivity Analysis As a result of an intensive HW/SW component reuse in the design of embed- ded systems, there is a need for analysis methods that, besides validating the performance of a system configuration, are able to predict the evolution of the system performance in the context of modifications of component prop- erties. The system properties represent intrinsic system characteristics deter- mined by the configuration of the system components and the system’s inter- action with the environment. These include the execution/communication time intervals of the computational/communication tasks, the timing param- eters of the task activation models, or the speed factor of the HW resources. These properties are used to build the performance model of the system. Based on this, the system quality is evaluated using a set of performance metrics such as response times, path latencies, event timings at components’ outputs, and buffer sizes. These are used to validate the set of performance constraints, determined by local and global deadlines, jitter and buffering constraints, and so on. The sensitivity analysis of real-time systems investigates the effects on the system quality (e.g., end-to-end delays, buffer sizes, and energy consump- tion) when subjected to system property variations. It will in the following be used to cover two complementary aspects of real-time system designs: performance characterization and the evaluation of the performance slack. 3.6.1 Performance Characterization This aspect investigates the behavior of the performance metricswhenapply- ing modifications of different system properties. Using the mathematical properties of the functions describing the performance metrics, one can show the dependency between the values of the system properties specified in the input model and the values of the performance metrics. This is especially important for system properties leading to a discontinuous behavior of the Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 77 2009-10-13 Formal Performance Analysis 77 performance metrics. The system designer can efficiently use this informa- tion to apply the required modifications without critical consequences on the system’s performance. Of special interest is the characterization of system properties whose vari- ation leads to a nonmonotonic behavior of the performance metrics, referred to as timing anomalies. Such anomalies mostly occur because of inter-task functional dependencies, which are directly translated into timing depen- dencies in the corresponding performance model. The analyses of timing anomalies become relevant in the later design phases, when the estimated property values turn into concrete, fixed values. It is important for the system designer to know the source of such anomalies and which of the property values correspond to nonmonotonic system performance behavior. Since it divides the nonmonotonic—performance unpredictable—design configu- ration space into monotonic—performance predictable—subspaces, timing anomaly analysis is an important element of the design space exploration process. 3.6.2 Performance Slack In addition to performance characterization, sensitivity analysis determines the bound between feasible and infeasible property values. This bound is called the sensitivity front. The maximum amount by which the initial value of a system property can be modified without jeopardizing the system feasi- bility is referred to as performance slack. In general, to preserve the predictability, the modification of the design data is performed in isolation. This means, the system designer assumes the variation of a single system characteristic at a time, for example, the imple- mentation of a software component. In general, in terms of performance, this corresponds to the variation of a single system property, for example, the worst-case execution time of the modified task. Such modifications are subject to one-dimensional sensitivity analysis. When the modification of a single system property has only local effects on the performance metrics, the computation of the performance slack is quite simple. Several formal meth- ods were previously proposed [3,48]. However, in some other situations, the variation of the initial value affects several local and global performance met- rics. Therefore, in order to compute the performance slack, sensitivity anal- ysis has to be assisted by an appropriate system-level performance analysis model. In many design scenarios though, changing the initial design data cannot be performed in isolation, such that a required design modification involves the simultaneous variation of several system characteristics, and thus system properties. For example, changes in the execution time of one task may coin- cide with a changed communication load of another task. Such modifications are the subject of multidimensional sensitivity analysis. Since the system per- formance metrics are represented as functions of several system properties Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 78 2009-10-13 78 Model-Based Design for Embedded Systems and the dependency between these properties is generally unknown, the sensitivity front is more difficult to determine. In general, the complexity of the sensitivity analysis exponentially increases with the number of variable properties in the design space. Based on the design strategy, two scenarios for using the performance slack are identified: • System robustness optimization: Based on the slack values, the designer defines a set of robustness metrics to cover different possible design scenarios. In order to maximize the system robustness at a given cost level, the defined robustness metrics are used as optimization objec- tives by automatic design space exploration and optimization tools [12]. The scope is to obtain system configurations with less sensitivi- ties to later design changes. More details are given in Section 3.7. • System dimensioning: To reduce the global system cost, the system designer can decide to use the performance slack for efficient system dimensioning. In this case, instead of looking for system configurations that can accommodate later changes, the performance slack is used to optimize the system cost by selecting cheaper variants for processors, communication resources, or memories. A sufficient slack may even suggest the integration of the entire application on alternative plat- forms, reducing the number of hardware components [30]. Note that lower cost implies lower hardware costs on one side, and lower power consumption and smaller size on the other. The sensitivity analysis approach has been tailored differently in order to achieve the previous design goals. Thus, to perform robustness optimization, the sensitivity analysis was integrated into a global optimization framework. For the evaluation of the robustness metrics it is not necessary to accurately determine the sensitivity front. Instead, using stochastic analysis, the sensi- tivity front can be approximated using two bounds for the sensitivity front: the lower bound determines the minimum guaranteed robustness (MGR), while the upper bound determines the maximum possible robustness (MPR). The benefit of using a stochastic analysis instead of an exact analysis is the nonexponential complexity with respect to the number of dimensions, which makes it suitable for a large number of variable system properties. Details about the implementation are given in [12]. For the second design scenario, the exact sensitivity front is required in order to perform the modifications of the system properties. Compared to previous formal sensitivity analysis algorithms, the proposed approach uses a binary search technique, ensuring complete transparency with respect to the application structure, the system architecture, and scheduling algo- rithms. In addition, the compatibility with the system-level performance analysis engine allows analysis of systems with global constraints. The one-dimensional sensitivity analysis algorithms are also used to bound the search space investigated by the stochastic sensitivity analysis approach. Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 79 2009-10-13 Formal Performance Analysis 79 The advantage of the exact analysis, when compared to the stochastic analysis, is the ability to handle nonmonotonic search spaces. A detailed description of the sensitivity analysis algorithms for different system prop- erties can be found in [31]. 3.7 Robustness Optimization In the field of embedded system design, robustness is usually associated with reliability and resilience. Therefore, many approaches to fault tolerance against transient and permanent faults with different assumptions and for different system architectures can be found in the literature (e.g., in [9,22,28]). These approaches increase the system robustness against effects of external interferences (radiation, heat, etc.) or partial system failure, and are, there- fore, crucial for safety critical systems. In this chapter, a different notion of robustness for embedded systems is introduced and discussed: robustness to variations of system properties. Informally, a system is called robust if it can sustain system property modi- fications without severe consequences on system performance and integrity. In contrast to fault tolerance requiring the implementation of specific meth- ods such as replication or reexecution mechanisms [18] to ensure robust- ness against faults, robustness to property variations is a meta problem that does not directly arise from the expected and specified functional system behaviors. It rather represents an intrinsic system property that depends on the system organization (architecture, application mapping, etc.) and its con- figuration (scheduling, etc.). Accounting for property variations early during design is key, since even small modifications in systems with complex performance dependencies can have drastic nonintuitive impacts on the overall system behavior, and might lead to severe performance degradation effects [29]. Since performance eval- uation and exploration do not cover these effects, it is clear that the use of these methods alone is insufficient to systematically control system perfor- mance along the design flow and during system lifetime. Therefore, explicit robustness evaluation and optimization techniques that build on top of per- formance evaluation and exploration are needed. They enable the designer to introduce robustness at critical positions in the design, and thus help to avoid critical performance pitfalls. 3.7.1 Use-Cases for Design Robustness In the following, we discuss situations and scenarios where robustness of hardware and run-time system performance against property variations is expected and is crucial to efficiently design complex embedded systems. Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 80 2009-10-13 80 Model-Based Design for Embedded Systems Unknown quality of performance data: First, robustness is desirable to account for data quality issues in early design phases, where data that are required for performance analysis (e.g., task execution times and data rates) are often estimated or based on measurements. As a result of the unknown input data quality, also the expressiveness and accuracy of performance analysis results are unknown. Since even small deviations from estimated property values can have severe consequences on the final system performance, it is obvious that robustness against property variations leverages the applicability of for- mal analysis techniques during design. Clearly, design risks can be consid- erably reduced by identifying performance critical data and systematically optimizing the system for robustness. Maintainability and extensibility: Secondly, robustness is important to ensure system maintainability and extensibility. Since major system changes in reac- tion to property variations are not usually possible during late design phases or after deployment, it is important to choose system architectures and configurations that offer sufficient robustness for future modifications and extensions, as early on as possible. For instance, the huge number of feature combinations in modern embedded systems has led to the problem of prod- uct and software variants. Using robustness optimization techniques, sys- tems can be designed, at the outset, to accommodate additional features and changes. Other situations where robustness can increase system maintain- ability and extensibility include late feature requests, product and software updates (e.g., new firmware), bug fixes, and environmental changes. Reusability and modularity: Finally, robustness is crucial to ensure component reusability and modularity. Even though these issues can be solved on the functional level by applying middleware concepts, they are still problematic from the performance verification point of view. The reason is that system performance is not composable, prohibiting the straightforward combina- tion of individually correct components in a cut-and-paste manner to whole systems. In this context, robustness to property variations can facilitate the reuse of components across product generations and families, and simplify platform porting. 3.7.2 Evaluating Design Robustness Sensitivity analysis has already been successfully used for the evaluation and optimization of specific system robustness aspects. In [26], for instance, the authors present a sensitivity analysis technique calculating maximum input rates that can be processed by stream-processing architectures with- out violating on-chip buffer constraints. The authors propose to integrate this technique into automated design space exploration to find architectures with optimal stream-processing capabilities, which exhibits a high robust- ness against input rate increases. Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 81 2009-10-13 Formal Performance Analysis 81 In this chapter, sensitivity analysis is systematically utilized for general robustness evaluation and optimization purposes. More precisely, instead of consuming the available slack for system dimensioning, and thus cost minimization, the slack is distributed so that the system’s capability of sup- porting property variations is maximized. Using sensitivity analysis as a basis for robustness evaluation and optimization has two important advan- tages compared to previous approaches. 1. State-of-the-art modular sensitivity analysis techniques capture com- plex global effects of local system property variations. This ensures the applicability of the proposed robustness evaluation and optimization techniques to realistic performance models, and increases the expres- siveness of the results. 2. Rather than providing the system behavior for some isolated dis- crete design points [4,7], sensitivity analysis characterizes continuous design subspaces with identical system states. It thus covers all possible system-property variation scenarios. 3.7.3 Robustness Metrics In order to optimize robustness, we need, on the one hand, expressive robust- ness metrics and, on the other hand, efficient optimization techniques. In general, robustness metrics shall cover different design scenarios. 3.7.3.1 Static Design Robustness The first considered design scenario assumes that system parameters are fixed early during design and cannot be modified later (e.g., at late design stages or after deployment) to compensate for system property modifica- tions. This scenario is called static design robustness (SDR). The SDR metric expresses the robustness of parameter configurations with respect to the simultaneous modifications of several given system prop- erties. Since the exact extent of system property variations can generally not be anticipated, it is desirable that the system supports as many as possible modification scenarios. This shall be transparently expressed by the SDR metric: the more different modification scenarios represent feasible system states for a specific parameter configuration, the higher the corresponding SDR value. Note that the SDR optimization yields a single parameter config- uration possessing the highest robustness potential for the considered system properties. 3.7.3.2 Dynamic Design Robustness The SDR metric assumes static systems with fixed parameter configurations. However, the system may react to excessive system property variations with dynamic counteractions, such as parameter reconfigurations, which poten- tially increases the system’s robustness. When such potential designer or Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 82 2009-10-13 82 Model-Based Design for Embedded Systems system counteractions are included in the robustness evaluation, this view is expressed with the dynamic design robustness (DDR). The DDR metric expresses the robustness of given systems with respect to the simultane- ous modifications of several system properties that can be achieved through reconfiguration. Consequently, it is relevant for the design scenario where parameters can be (dynamically) modified during design or after deploy- ment. Obviously, the DDR metric depends on the set of possible parame- ter configurations, C (“counteractions”), that can be adopted through recon- figuration. For instance, it may be possible to react to a property variation by adaptation of scheduling parameters (e.g., adaptive scheduling strate- gies [25] and network management techniques [8]) or application remapping. Application scenarios for the DDR metric include the evaluation of dynamic systems and, more generally, the assessment of the design risks con- nected to specific components. More precisely, already during early design, the DDR metric can be used to determine bounds for property values of spe- cific components ensuring their correct functioning in the global context. This information efficiently facilitates feasibility and requirements analysis and greatly assists the designer in pointing out critical components requiring spe- cial focus during specification and implementation. Another use-case con- cerns reconfigurable systems. The DDR metric can be used to maximize the dynamic robustness headroom for crucial components. Obviously, by choos- ing a system architecture offering a high DDR for crucial system parts early, the designer can significantly increase system stability and maintainability. Note that the DDR optimization yields multiple parameter configura- tions, each possessing partially disjoint robustness properties. For instance, one parameter configuration might exhibit high robustness for some sys- tem properties, whereas different parameter configurations might offer more robustness for other system properties. Figure 3.10a and b visualize the conceptual difference between the notions of the SDRand the DDR by meansof a simpleexample. Figure 3.10ashows the feasibleregionoftwopropertiesp 1 andp 2 ,i.e.,theregioncontainingallfeasible property value combinations, of a given parameter configuration. This corre- sponds to the static robustness, where a single parameter configuration with high robustness needs to be chosen. Figure 3.10b visualizes the dynamic robustness. In the considered case, there exist two additional parameter configurationsintheunderlyingreconfigurationspacewithinterestingrobust- ness properties. Both new parameter configurations contain feasible regions that are not covered by the first parameter configuration. The union of all three feasible regions corresponds to the dynamic robustness. 3.8 Experiments In this section, the formal methods presented in this chapter are applied to the example system illustrated in Figure 3.11. The entire system consists Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 83 2009-10-13 Formal Performance Analysis 83 #1 Feasible region configuration #1 16 14 12 10 8 6 4 2 0 Property p 1 (a) (b) Property p 2 0246810121416 #2 #1 Configuration #1 Feasible regions : Configuration #3 Configuration #2 #3 16 14 12 10 8 6 4 2 0 Property p 1 Property p 2 0 2 4 6 8 10 12 1614 FIGURE 3.10 Conceptual difference between the SDR and the DDR for two considered system properties subject to maximization. Shared memory HW IP1 IP2 SigOut ECU1 eval1ctrl1 eval2ctrl2 calc ctrl3 exec2 exec1 mon2 mon3 mon1 Multicore ECU ECU4 CAN Bus C5 C4 C3 C2 C1 ECU2 ECU3 Sens3 Sens2 Sens1 Act2 Act1 ESP Parking assistant FIGURE 3.11 A hypothetical example system. Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 84 2009-10-13 84 Model-Based Design for Embedded Systems of four ECUs and one multicore ECU that are connected via a CAN bus. Additionally, there are two IP components that also communicate over the CAN bus. We assume that two applications from the automotive domain are running on this platform. The Sensors 1 and 2 collect the ESP-related data, which are preprocessed on ECU2. These data are then sent to the multicore ECU where the data are evaluated and appropriate control data are peri- odically generated based on the evaluated data. These data are then sent to ECU1 where the commands are processed. Sensor 3 collects data relevant for a parking-assistant application. The collected data are preprocessed on ECU3 and sent to ECU4, where the data are further processed before they are passed as an audio signal to the driver. In the following, we will assume that these two applications are running mutually exclusive. For example, as soon as the driver shifts into the reverse gear, the parking-assistant application (Scenario 2) becomes active, and the ESP (Scenario 1) is deactivated. The tasks on ECU1 are scheduled according to a round-robin scheduling policy, while all other ECUs implement a static-priority preemptive schedul- ing policy. Core execution and communication times, and the scheduling parameters (priority and time slot size) of all tasks in the system are specified in Table 3.1. Additionally, for tasks on the multicore ECU, the memory access time is explicitly given for each task, to allow considering the contention on the shared memory. (On single-core ECUs, the memory access time is contained in the core execution time.) For the communication, we assume that the transmission mode of the communication layers is direct and that TABLE 3.1 Core Execution/Communication Time and Memory Access Time Per Task Task Exec./Comm. Memory Access Scheduling HW Name Time (in ms) Time Parameter Multicore ECU ctrl1 [10:22] [0:2] Prio: High ctrl2 [20:20] [0:1] Prio: Low eval1 [12:14] [0:4] Prio: High eval2 [26:26] [0:6] Prio: Low ECU1 exec1 [20:20] — Time Slot size: 5 exec2 [30:30] — Time Slot size: 10 ECU2 mon1 [10:15] — Prio: High mon2 [12:18] — Prio: Low ECU3 mon3 [20:20] — Prio: High ECU4 calc [1:1] — Prio: High ctrl3 [20:20] — Prio: Low CAN Bus C1 [6:6] — Prio: Highest C2 [5:5] — Prio: High C3 [10:10] — Prio: Med C4 [10:10] — Prio: Low C5 [7:7] — Prio: Lowest Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 85 2009-10-13 Formal Performance Analysis 85 all sending tasks produce triggering signals. This implies that whenever the sending tasks produce an output value, the transmission of a message is trig- gered. We suppose that Sensor 1 produces a new signal every 75 ms, Sensor 2 every 80 ms, and Sensor 3 every 75 ms. The hardware component activating the task calc on ECU4 performs this calculation every 2 ms and the control tasks ctrl1 and ctrl2 are activated every 100 ms and 120 ms, respectively. The system is subject to two end-to-end latency constraints. The latency of the parking-assistant application (Sens3 → SigOut) may not exceed 150 ms, whereas the communication between the two IP components (IP1 → IP2) must not last longer than 35 ms. 3.8.1 Analyzing Scenario 1 Initially, assume that in previous product generations the parking-assistant application used a dedicated communication bus, and, thus, only the ESP application initially needs to be contained in the model. In this setup, when accounting for the communication of the ESP applica- tion and the communication between the two IP components, the bus load is only 47.21% and the maximum latency for the communication between IP1 and IP2 is 29 ms. Our analysis yields that all response times and end-to-end latencies remain within the given constraints. By using the HEMs, we obtain very accurate input event models for the receiving tasks (exec1 and exec2). For example, Figure 3.12 illustrates the maximum number of message arrivals vs. signal arrivals for ECU1. The upper curve (marked by circles) represents the maximum number of 14 12 10 8 6 4 2 0 0 71 142 213 284 355 Time interval Event number 426 497 568 639 710 η + -frame arrivals η + -signals_ctrl1 η + -signals_ctrl2 FIGURE 3.12 Message arrivals at ECU1 vs. signal arrivals. . poten- tially increases the system’s robustness. When such potential designer or Nicolescu /Model-Based Design for Embedded Systems 67842_C003 Finals Page 82 2009-10-13 82 Model-Based Design for. per- formance metrics are represented as functions of several system properties Nicolescu /Model-Based Design for Embedded Systems 67842_C003 Finals Page 78 2009-10-13 78 Model-Based Design for Embedded. Nicolescu /Model-Based Design for Embedded Systems 67842_C003 Finals Page 76 2009-10-13 76 Model-Based Design for Embedded Systems Having determined a response time interval across the SC for each