Extracting, Specifying and Predicting Software System Properties in Component Based Real-Time Embedded Software Development Ji Eun Kim Research and Technology Center Bosch LLC Pittsburgh, USA
[email protected]
Oliver Rogalla, Simon Kramer, Arne Hamann Corporate Research, Robert Bosch GmbH Schwieberdingen, Germany {Oliver.Rogalla, Simon.Kramer2, Arne.Hamann}@de.bosch.com
Abstract
1. Introduction
Bosch has established Component Based Software Development (CBSD) for automotive systems, which are resource constrained real-time embedded systems such as engine control systems. Classical CBSD approaches enable effective software reuse mainly in functional aspects by managing complexity with abstraction and encapsulation. However, to fully exploit the advantages of CBSD for real-time embedded systems, non-functional system properties such as timing and memory usage need to be addressed by the underlying component model. It is important that non-functional properties have a certain degree of precision to ensure hardware dimensioning and cost optimization for such systems. Static analysis methods used to extract or analyze nonfunctional properties (e.g., worst case execution time) in most cases introduce overestimation which is a hindrance for accurate prediction of non-functional properties. Therefore, accurate prediction of system properties requires specifying semantic context information such as modes in the component model to reduce overestimation. This paper describes how we extend the Bosch software component model to specify non-functional component properties with modes information. We demonstrate how mode dependent timing behavior is automatically extracted from the software, specified in the component specification and used for analysis and prediction in real-time embedded systems. This paper shows that semantic context information such as modes enhances performance analysis and prediction by ruling out infeasible worstcase situations that lead to overly conservative performance predictions.
ICSE’09, May 16-24, 2009, Vancouver, Canada 978-1-4244-3494-7/09/$25.00 © 2009 IEEE
Bosch has established Component Based Software Development (CBSD) for traditional automotive embedded systems [1][2] for the last years. The classic automotive systems such as engine control systems are characterized as resource constrained, real-time and safety critical systems. CBSD contributes to effective management of complexity, reduces time to market and increases productivity. These advantages are achieved by facilitating the reuse of components and their architecture, by raising the level of abstraction for software construction, and by sharing standardized services. However, to fully exploit the advantages of CBSD for resource constrained real-time systems, nonfunctional system properties such as timing and memory usage need to be addressed by the underlying component model. Bosch extended its existing component model (BlueArX) to specify non-functional properties of components and semantic context information. Bosch also employed several state-of-the-art analysis tools developed specifically for resource constrained realtime systems to extract and predict non-functional properties. These tools aid in the prediction of system properties during component composition to build a new product. Unfortunately, even state-of-the-art analysis tools (e.g., worst case execution time analysis tool) in most cases introduce overestimation that hinders accurate analysis and prediction. We introduced semantic context information (e.g., modes) to improve the accuracy of analysis and prediction. This paper demonstrates that semantic context information rules out infeasible worst-case situations that lead to overly conservative performance prediction. The remaining sections of the paper describe the basics of the Bosch component model (BlueArX) and our extensions to enhance prediction of system
28
Companion Volume
components. The scope and usage of the elements are determined by component interfaces. Figure 2.1 illustrates the static view of the component model.
properties; these are methods and tools we employed, enhanced or developed to extract non-functional properties and semantic context information automatically. Our proposed concepts are applied to an engine control system as a case-study.
Export interface (Provide interface)
2. Basics of Bosch Component Model
Structural component A
A
Body
The Bosch software component model, named BlueArX has been developed for traditional automotive domains (e.g., engine control systems and chassis systems) where resources are extremely constrained due to hardware cost. Furthermore, real-time, reliability and safety are considered as important nonfunctional requirements. These systems are closed control loop systems that receive physical values from sensors, process computations, and control actuators with new physical values. BlueArx focuses on the design time component model to support the aforementioned constraints and non-functional requirements [1].
Atomic component B is a subcomponent of component A Import interface (Require interface)
B
C
Atomic component C exports this element ... and owns this element ... and imports this element
Implicit connection by unique element name
Consistence checks: • name + type • computation method • value range • physical unit ...
Figure 2.1 Graphical representation of BlueArx (static view) Bosch automotive software systems use a special type of variable called message for communication between components. A component specifies its message access properties (read, write, or read/write) in its interface description.
2.1 Static View BlueArX provides two types of components: atomic components and structural components. An atomic component (components B and C in Figure 2.1) is a unit of specification, and has an implementation. It is a leaf in the software architecture tree. A structural component (component A in Figure 2.1) is a unit of specification, and has a decomposition. It represents a node in the software architecture tree. A component has interfaces and BlueArx divides interfaces into two types: import interfaces and export interfaces. An import interface specifies variables, messages, services, calibration parameters1 and other software elements required for the component to execute. An export interface specifies the same types of elements as an import interface that it provides to the system. A structural component is composed of one or several atomic components and/or structural components. A structural component can import and export a subset of interfaces from each atomic component and structural component. Software elements used in interfaces are declared in the body called Data Dictionary. A Data Dictionary is the collection of elements which are owned by the
2.2 Dynamic View BlueArx provides the specification of scheduling information to generate a system schedule that is used by the operating system. The component scheduling specification includes the mapping of services to periodic tasks (e.g., occurring every 1 ms, 2ms, 5ms) or event-triggered tasks (e.g., synchronous to engine rotation) and the order of services inside these tasks. The glue between the static and the dynamic view, as well as between the components and the operating system, are the runtime objects, called processes. They are mapped into different tasks in a defined order, and the tasks are then scheduled by an operating system called ERCOS [14]. ERCOS is specially designed to meet the functionality and performance requirements of automotive applications. It is compatible with OSEK specifications [15]. ERCOS provides two different types of tasks: 1) cooperative tasks where task changes take place at the borders of processes listed in the specified tasks and 2) preemptive tasks that may interrupt a lower-priority task at any point. Preemptive tasks always have a higher priority than cooperative tasks. Figure 2.2 shows how processes specified in the static view map to the dynamic view. For example, runtime object A is specified in an event-triggered task (Sync Task in the picture), B is specified as a process
1
Calibration parameters (value, map or curve) are usually stored in non-volatile memory and are used after compilation time to adjust the system behavior. They are often used in automotive domains and the values of the parameters influence the runtime performance of the system.
29
followed by C, E,F and G in 20 ms Task, and D is a process specified in 10 ms Task in the specification supporting the dynamic view.
Runtime object (Process)
B
D B2
C
information can be specified for each property. Semantic context information is also specified by referring to the modes.
E
F
A C2
G
AI Activation
OS
EE
20ms Task 10ms Task
AA
AA
Sync Task
D D
FF
G G
EE
BB C C D D
FF
D D
G G
BB C C D D
D D
Figure 2.2 Mapping of static and dynamic views of BlueArx Figure 3.1 Concept of an Analytic Interface
3. Extension to Non-Functional Properties and Semantic Context Information
class Analytic Interface
3.1 Analytic Interface Specification
SERV ICE
The analytic interface is associated to a specific component implementation. It becomes invalid if the implementation of a component is modified. In the context of a software-build-process the implementation of the component consists of the component specification and implementation (c and header files including synthesized code from models) of the component, as well as included libraries (e.g. mathlibraries, etc.). This must be taken into account for variants of components, when new code segments and/or new components are integrated in the component. In general this leads to a separate definition of the analytic interface for each variant. The analytic interface (AI in Figure 3.1) specifies the amount of resource consumption for several categories such as Worst Case Execution Time (WCET), code memory, data memory and stack memory for software components. Input to the analytic interface is the current context such as hardware dependencies, tool chains and the setting of constants and/or calibration parameters in which the component should be applied. As shown in Figure 3.1, the analytic interface is attached to a component and the specification can be used by an external analysis tool. Figure 3.2 illustrates the meta-model of analytic interface in UML. In our extension to BlueArX, properties are specified in the service level of each component and the context
1. .* PROPERTY
CONTEXT
MODES
1
WCET
STACK-USAGE
Figure 3.2 Meta-model for the Analytic Interface
3.1 Modes Specification Modes are associated with semantic context information that provides either different scheduling or different control strategies (see Section 5.1 for the modes concept) in closed loop real-time control systems. In case modes are used for different scheduling purposes, modes are specified in the dynamic view of the component specification in our current practice. For example, initialization mode, cyclic executive mode and shut-down mode have different scheduling policies and these modes are described in the dynamic view of the component specifications by specifying different tasks having different lists of processes. However, semantic context
30
information that is not defined as an explicit mode in the dynamic view also needs to be specified in the component specification for better software understanding [2] and analysis. We have extended BlueArX to specify modes on the component specifications where modes are used to determine control strategies. Examples of such modes in engine control systems can be different engine operation modes such as particulate filter regeneration mode and normal mode as well as different speed thresholds that lead to significantly different control algorithms.
Therefore, the extraction of relevant properties with minimal users’ effort is important to effectively analyze and predict a systems’ real-time behavior. Bosch has employed the state-of-the-art static analysis tool aiT [9] which is developed by AbsInt to analyze object code to extract the Worst Case Execution Time (WCET) of a component. This section provides the basics of WCET analysis and our approaches to improve the accuracy and usability of the aiT tool.
4.1 Worst Case Execution Time Analysis class Mode
COMPONE NT SPEC
OWNED ELEMENT
IM/EXPORT INTERFACE
MODE GROUP
0. .1
1. .* ELEMENT
The Worst Case Execution Time (WCET) is the longest time that a piece of software can take to run in a single thread of execution. Figure 4.1 shows the probability of different execution times of a piece of software. Given an execution time on the x-axis, the corresponding value on the y-axis is the probability that we observe this execution time in a randomly chosen execution. The measurement method tends to return the result of execution time with the highest probabilities, and thus is likely not able to accurately measure the exact worst case execution time. Static WCET analysis builds control-flow graphs from source or object code to determine the longest execution path of a single program. The analyzed WCETs in most cases introduce overestimation mainly due to inaccurate hardware models and missing information about data dependencies. Our contribution toward the reduction of overestimation applies domain knowledge and semantic context information which enhance data dependency information when using static WCET analysis tools.
DATA DICTI ONARY SPEC
MO DE
PRE-CONDITION
MODE EXP RESSION
Figure 3.3 Meta-model for Modes Figure 3.3 illustrates the meta-model of the extended component model in UML format. We introduce the mode element in the declaration part of the component specification (Data Dictionary Spec in Figure 3.3) and provide a means to import/export modes by referring to the modes throughout elements belonging to the interface part. Mode elements are also referenced by the analytic interface so that semantic context dependencies of the properties are able to be specified in addition to other context dependencies such as hardware features or tool chains. Figure 3.2 also shows how the analytic interface refers to the modes.
4. Automatic Properties
Extraction
of
Timing
Figure 4.1 Probability of execution time
In Component Based Software Development (CBSD), a new software product can be built by reusing existing software components with different configurations, modifying or extending the existing ones to provide new features of the software product.
4.2 Automatic characteristics
annotation
of
domain
One of the big challenges in state-of-the-art static analysis tools is usability. As discussed in Section 4.1, state-of-the-art static analysis tools usually introduce overestimation. This can be reduced by annotations
31
which exploit domain characteristics. However such annotations require manual effort and thus lead to poor usability that discourages a user to use the tool. As a solution we provide a proprietary tool that automatically generates these annotations. (Note that this process is a part of environment specs, value assumptions in Figure 4.3.) The tool gathers in a first step what has to be annotated. Then it looks for the needed information in the available data and finally generates the annotations. The generated annotations include annotations for usages of maps and curves or known memory content. For example, assume that a parameter2 used in a particular function has a significant influence (e.g., a parameter influences loop bound) on WCET analysis. The tool first looks for the usage of the function in the call tree. If it finds an occurrence of the function, it determines its start address in the program-memory and searches through the object code to find calls to it. For each call our tool generates an annotation to indicate the information where the values of the parameter used in the function are stored. Such information can for instance be found in specification files, meaning that they are set by an developer, or in data files, created by an calibration engineer and the end of the development process.
precise and accurate WCET analysis requires low-level information which is very difficult to obtain without tool support like that which is provided by our proprietary tool.
4.3. Automatic annotation of semantic context information For further reduction of overestimation, we provide semantic context information such as modes as a solution in the application level. The modes information allows us to distinguish different execution paths for the WCET analysis. In other words, the static analysis approach naturally takes the longest path of execution to calculate WCET. Modes information provides the control information which determines the semantically possible longest path. Figure 4.3 shows the WCET extraction process with annotation of modes. Our tool uses the modes specification to automatically annotate paths for different modes. code
WCET Analyzer
determine control flow
CFG
calculate execution times
environment specs, value assumptions
annotated CFG
Modes information
determine WCET
find the longest path
WCET
[example of annotation]
Figure 4.3 WCET extraction process with annotation of modes
instruction instruction0x12345678 0x12345678isisentered enteredwith witha4 a4==0x80011110; 0x80011110;
Figure 4.2 Screenshot of WCET tool and example of annotation
5. Semi-Automatic Extraction of Semantic Context Information on the Component
Figure 4.2 shows a screenshot of the aiT tool which Bosch employed for WCET analysis, and an example of annotation automatically generated by our proprietary tool. Each block represents a basic block in compiler terms (note that function name in each basic block is removed) and the graph represents a controlflow (call tree). The upper right box shows computed WCET result (Computed Worst-Case-Execution Time: 719 cycles). As seen in the example, the annotation for
We consider modes as one kind of semantic context information which influences software behavior and performance. In our definition, a mode is an interesting set of states. Given the fact that interesting or important implies different meanings to different stakeholders, we propose heuristics approaches to determine the important mode candidates. This section defines the concept of modes in our view as well as heuristics to extract important mode candidates, and describes our user interactive tool (XGen) that automates the extraction process.
2
Here parameter denotes a variable which is quasi-constant in the system (e.g. a calibration value). A static analysis would not be able to identify such variables as constant without further context information.
32
• Interviews with stakeholders: we interviewed software architects, system engineers, software function developers and resource engineers in order to get their views of the important modes. The interview results are formalized to concrete information (e.g., component or implementation naming conventions) that can be used by our tool. • Software architecture patterns: some components having a certain naming convention are often used to define the state machine of a subsystem or determine current modes of a subsystem. • Software modeling pattern: particular element types (e.g., switch element) are used to determine different control strategies. • Software implementation patterns: naming conventions often imply the usage of variables. For example state variables which are often used to determine current modes have a particular naming convention. • Statistic analysis of component specifications: variables frequently imported by other components imply such variables are used to control different paths of execution. • Distribution of execution time: software components having large differences of execution time imply that such components include modes that determine different execution paths. • Mode propagation patterns: globally well-known modes are often propagated to individual subsystems and then used for different control strategies within those subsystems. This propagation usually has certain patterns (e.g., using a specific library function to convert a global mode to a local mode).
5.1 Concept of Modes Modes influence software behavior in the following aspects in real-time embedded software systems: • Different scheduling: Components and processes belonging to their components are activated differently depending on the mode. For example, processes for the initialization mode can be different from the normal cyclic executive mode. In addition, the period and the order of execution of processes are also differently scheduled in different tasks for different modes. • Different control: Within a single component or process, the system determines different control strategies depending on the current mode. For example, the system can activate or deactivate a certain service depending on the different speed of engine; calibration parameters are set dependent on modes; different branches are taken depending on which mode the system is in.
5.2 Heuristics for Important Modes It is a challenge to determine the importance level of modes in an absolute and quantifiable manner because every stakeholder usually has a different opinion on the level of importance. In addition, closed loop control systems such as engine control systems contain numerous control conditions which are necessary to support accurate and precise control of systems. Some of these control conditions significantly influence behavior and performance of the system, while some of them do not. Therefore, we need knowledge to distinguish such conditions significantly influencing the system (we call such conditions important modes), from numerous non-critical control conditions. We introduce a heuristics engine as a reasoning framework that provides the user with reasonable results of important mode candidates with associated expected utility values (weights). Heuristics can be varied over different domains. Our heuristics for engine control systems exploit various types of information obtained from component based real-time embedded software development practices. In particular, the information for our heuristics engine consists of analyzed patterns from software architecture, modeling and implementation, component specifications, software implementation, execution time distribution as well as the results of interviewing different stakeholders, etc. The following are further details of some examples of heuristics which also can be also applied for other domains which utilize component based software development practices.
Note that heuristics can be different depending on the software practices of different domains and different organizations.
5.3 Semi-Automatic Candidates
Extraction
of
Mode
We developed a user interactive tool named XGen – eXtract and Generate modes to extract mode candidates by realizing the heuristics concepts and to generate new component specifications. At the heart of XGen is the heuristics engine, which tailors a common mechanism from the field of artificial intelligence known as the decision network (also referred to as an influence diagram) and expected utility value [8]. The influence diagram is constructed as a list of nodes that build and modify each other during the course of execution. The approach shifts a list of values and an associated expected utility value for each element through the execution of each heuristic node.
33
Figure 5.1 illustrates the tailored decision network used in XGen. Native chance nodes are the implementation of proposed heuristics discussed in the previous section. Since each node produced different types of information, we introduce the intermediate chance node concept that integrates the results from the native nodes as well as calculates corresponding expected utility values for the integrated results from multiple nodes. Intermediate chance nodes can also influence other intermediate chance nodes. XGen produces a candidate node as an intermediate chance node with a list of modes candidates having relevant information (e.g., exclusiveness of modes, modes expression, component name, etc). For example, software architectural patterns and software implementation patterns provide a list of expressions used for the mode candidates, then statistic analysis of software component specification pattern increases weights of the mode candidates which contain variables frequently imported by other components. Similarly components of having large distribution of execution time increase weights of the candidates belonging to their components. As executing the influence diagram, XGen provides the ranked list of modes candidates at the end. The XGen tool does not aim to support fully automatic generation of new modes specifications but it provides reasonable results of the modes candidates so that the user can make informed decisions concerning the modes of a component. XGen generates new specifications corresponding to the component model that specifies the rules of elements such as modes (see Section 3) after users’ final selection of important modes.
pattern provides partial hierarchy of the state machine by using dependencies for globally known modes and local subsystem modes. The XGen tool has been designed to support extensibility of heuristics because different domains need to have different heuristics. We provide a scheduling algorithm to construct heuristic nodes based on the configuration of pre-conditions and postconditions of each heuristic node. Different influence diagrams can be constructed by using the scheduling algorithm provided by XGen. Of course, corresponding modifications or additions should be applied in order to realize different heuristics for different domains.
6. Prediction of System Properties In Sections 4 and 5, we described how to extract non-functional properties that focus on the timing information and semantic context information, and our extensions to BlueArX to specify this information in the component specifications. This Section describes how we can use the new specifications to predict system properties. Note that we distinguish component properties using WCET analysis of components from system properties using schedulability analysis which provides a global view of performance.
6.1 Reasoning Framework for Schedulability Analysis Real-time systems require the satisfaction of timing constraints for correct system operation. It is imperative to know all computations/tasks will always finish in time. Unfortunately this is not obvious when employing highly optimized scheduling strategies. The utilization or load (percentage of time in the CPU is not idle) metric is not sufficient to satisfy real-time requirements. It is often seen that the tasks sporadically miss their deadlines at 80% utilization or below. Schedulability analysis is a method to check whether all tasks in the system satisfy their timing constraints.
user heuristic heuristic heuristic candidates
U
heuristic heuristic
legend
heuristic
T1
: native chance node
: intermediate chance node
: utility node
: decision node
T1
T1
Task1 T2
T2
Task2
T3
Task3
Figure 5.1 Tailored Decision Network (Influence Algorithm) in XGen
R C D
The heuristic of software modeling pattern provides exclusiveness of modes (for example, only one path is active for control elements (e.g., switch, if/else). In addition, the heuristic of mode propagation
T: Periods R: Response Time
C: Core Execution Times D: Dead Line
Figure 6.1 Example of schedulability analysis
34
Assuming a set of tasks, scheduling is the act of assigning certain tasks to the CPU based on the task parameters (e.g., priority) and a chosen scheduling policy (e.g., static priority preemptive scheduling). The property that all tasks in a system always satisfy their timing constraints is called schedulability. Examples for timing constraints are a deadline for a task relative to its activation or a constraint on the jitter around a fixed period of output events. The worst case response time of a task is typically not a local property – it does not only depend on the task itself but also on the other tasks mapped to the same CPU. Scheduling analysis computes the worst case response times of tasks and checks whether deadlines are met. Figure 6.1 illustrates an example of static priority preemptive scheduling for strictly periodic tasks. In this case schedulability is checked by comparing response times against deadlines given periods, priorities and worst case execution times.
customizations as a reasoning framework that aids analysis and prediction of timing properties.
7. Case Study Our proposed approaches in the previous Sections are applied to a real engine control system as a case study in this paper. This case study provides how the mode dependent timing analysis can be used in our Component Based Software Development (CBSD) practice.
7.1 Engine Control System
6.2 Prediction of System Properties Using Component specifications In our approach, we specify component properties (e.g., WCET) in the analytic interface and use the specification for a reasoning framework (e.g., scheduling analysis tool) when composing components to build a system. Figure 6.2 illustrates how the prediction of system properties is used in CBSD. Reasoning Frameworks
Schedulability WCET Memory ...
ECU
Analytic Interface
i
i
Sensor i Actuator
i
Prop19 Prop1 Prop1 Prop2 Prop29 Prop2 Prop3 Prop30 Prop3
Our engine control system provides two types of tasks: 1) time triggered tasks and 2) event triggered tasks. Time triggered tasks are periodically executed tasks (e.g., 1ms, 2ms etc). Event triggered tasks are triggered by specific angle positions of the engine (crankshaft) as interrupts. This case study provides the results of one of the event triggered tasks. Figure 7.1 shows configurations for different interrupts (S_0 Interrupt1 and S_1 Interrupt2) where the different containers are scheduled to be executed in a fixed order for a given interrupt and the different threshold values. For example, all containers are executed between Threshold_1 and Threshold_2 in S_0 Interrupt1 while container1, container4 and container6 are scheduled between Threshold_3 and Threshold_4 in S_0 Interrupt1. In short, a container is an array of pointers to processes. The given set of containers to be executed for an interrupt is stored in an interrupt table, which is an array that contains the index of the containers. Limited to execute once every two interrupt
container2
container3
container4
container5
container6
container3
container4
container5
container6
container5
container6
container1 container1
container2
container3
container1
container6 container6
container2
container6 container5
container4 container4
container5
Scheduling Interface
container1
OS
container4
Threshold_4
Threshold_3
container1
Figure 6.2 Prediction of system properties using component specification In detail, analytic interfaces capture context dependent component properties information with respect to system constraints, hardware features or tool chains. These context dependent properties are used for what-if analyses to answer questions like “Would the software still be schedulable for a six cylinder instead of a four cylinder engine?” without actually building the software system. In addition, semantic context information such as modes enables more accurate and precise prediction. Bosch employed the SymTA/S [17] tool from Symtavision [10] with
container3
container2
container1
Threshold_2
Threshold_1
S_0 Interrupt 1
S_1 Interrupt 2
Figure 7.1 Configuration of executables for different thresholds
35
Given the fact that the configuration of containers is set differently for different speed ranges, we define four different speed ranges (represented as intervals of two consecutive Threshold_n in Figure 7.1) as distinct modes for this component. In the high speed range, where the interrupt frequency is more frequent than in low speed range, the runtime budget for the execution of engine synchronous task is usually less than the one in the low speed range. The current practice compensates for this by switching off some containers or by activating some containers less frequently in high speed ranges.
7.2.2 Mode Dependent Schedulability Analysis The previous Section showed that the mode concept allows expressing WCET of processes much more precisely. In the context of a system timing analysis, the benefit becomes more obvious. In our case study we assume that the event triggered tasks S_0 and S_1 run with a period of 40 time units in Mode 1 (speed range less than Threshold_1 in Figure 7.1). For illustration we also define a periodic task which represents additional load from those tasks which are periodically triggered. Figure 7.3 shows the analysis 3 of response times.
7.2 Mode Dependent Timing Analysis This section describes two aspects in lieu of timing analysis. First we show the results of WCET analysis for a component when applying semantic context information to the analysis. Second, we show how we predict schedulability as a system property by exploiting component properties of WCETs and semantic context information. Figure 7.3 Activation of the S0 and S1 interrupts for a period of 40 time units.
7.2.1 Mode Dependent WCET Analysis Figure 7.2 illustrates WCETs for different modes given different interrupt types (note: execution times presented here represent normalized values). As the results show, there are strong relations between different modes and the WCET property of a component: WCET for Mode4 is lower than WCETs for Mode1 and Mode2 by 17%. A conservative design decision can be often made if the static WCET analysis tool is used without precise information. We verified that modes information is needed to provide proper annotations because it enables the static WCET analysis tool to select realistic critical paths with precise information. Therefore, effective use of modes information can enable the static WCET analysis tool to reduce overestimation and provide better predictions.
It is also possible to determine the overall load of the system (Figure 7.4). In our case we can observe a load of approximately 83%.
Figure 7.4 Result of a scheduling analysis for a time period of 40 time units in Mode 1
WCET for Different Modes 5
For illustrating the timing behavior on higher rotation rates of the crankshaft let us assume doubling the frequency of invocation of the S_0 and S_1 tasks. The timing behavior is illustrated in Figure 7.5.
4
WCET
Mode1 3
Mode2
2
Mode3 Mode4
1 0 S_0
S_1 3 Please note that we added some jitter to the invocation of the eventtriggered tasks.
Figure 7.2 WCET for different modes
36
Figure 7.5 Activation of the S_0 and S_1 for a period of 20 time units
Figure 7.7 Scheduling analyses for a time period of 20 time units assuming Mode 4
It now becomes clear that assuming the WCETbehavior of the S_0 and S_1 tasks in Mode 1 (WCET is 3.3 for S_0 and 4.2 for S_1 in Figure 7.2) lead to an overestimation of the CPU load. Figure 7.6 shows the what-if-analysis result for higher rotation rates of the crankshaft. In this case study, we obtain approximately 102% of CPU utilization, which is clearly not schedulable.
8. Future Work We proposed a generic way of specifying nonfunctional properties. Our work has been focused on timing aspects. Memory is also equally important for resource constrained real-time embedded systems, thus we need to research on this aspect as well.
9. Related Work In automotive domains, the AUTOSAR (AUTomotive Open System Architecture) consortium has been organized to provide an open and standardized automotive software architecture. Many automobile manufacturers, suppliers and tool developers participate in the AUTOSAR consortium to come up with solutions for reusable, exchangeable software components across vehicle platforms, car manufacturer and suppliers [3]. The upcoming AUTOSAR 4.0 release will also contain a meta-model extension for specifiying timing properties and constraints of software components, such as execution demands of runnables, timing of interrupts, etc. Obviously, methods for extracting and predicting these properties, as proposed in this paper, are crucial to fully benefit from these timing extensions in early development phases. TIMMO is developing a common, standardized infrastructure for handling of timing information during the design of embedded real-time systems in the automotive industry [4]. In contrast to AUTOSAR, TIMMO solely addresses timing issues. Consequently, the TIMMO timing model is more expressible and contains many advanced features allowing to precisely describe the timing behavior of component based systems. Also mode dependent timing, as discussed in this paper, is supported. It is expected that TIMMO results will strongly influence future AUTOSAR releases with respect to timing modeling.
Figure 7.6 What-if-analysis of schedulability analysis for a time period of 20 time units assuming Mode1 By using the mode concept it is possible to express in the component model the difference of execution time by referencing Mode4 (speed range between Threshold_3 and Threshold_4 in Figure 7.1). Here we will determine a CPU load of 98% and the system is still proven to be schedulable. Thus we can observe how performing schedulability analysis without considering modes can load to a conservative analysis. This may lead to overestimated runtime resource requirements and possibly choose more expensive hardware in the worst case scenarios hypothesized.
37
The PREDATOR consortium is developing methods for system design that increase system development productivity aiming in particular at predictable system properties for safety-critical embedded systems [5] Instead of developing complicated analyses for complicated architectures, the approaches from PREDATOR simplify architectures to get simple and accurate analyses. The mode concept is orthogonal to this work. Bosch participates in aforementioned consortiums together with other companies in automotive and avionic systems as well as academia to lead standardization of component based software development for automotive systems. Apart from them, the Architecture Analysis and Description Language (AADL) [12] and Predictable Assembly from Certifiable Components (PACC) [13] work from the Software Engineering Institute provide a way to specify non-functional properties of components for avionic systems and other domains. However, domain specific component models and relevant analysis methods/tools are required to make their proposed concepts useful enough to the accurate prediction of system performance. Also, neither of these two approaches considers semantic context information as a means to improve accuracy of analysis and prediction. The authors [18] [19] proposed mode dependent worst case execution time analysis. They consider modes on a very low level regarding different paths through functions as different modes. Our approach consider higher granularity of modes as semantic context information which significantly influence system properties. Also their approaches do not address legacy software implementation which is often difficult to extract semantic context information and properties.
case situations that lead to overly conservative performance predictions.
11. References [1] B. Weichel and M. Herrmann, “A Backbone in Automotive Software Development Based on XML and ASAM/MSR”, SAE 2004 World Congress [2] J. Kim et al, “Software Behavior Description of Real-Time Embedded Systems in Component Based Software Development”, In Proceedings of ISORC 2008 [3] AUTOSAR consortium, http://www.autosar.org [4] TIMMO consortium, http://www.timmo.org [5] PREDATOR consortium , http://www.predatorproject.eu [6] C. Ferdinand and R. Heckmann, “Worst-Case Execution Time – A tool Provider’s Perspective”, In Proceedings of ISORC 2008 [7] I. Crnkovic and M. Larsson, “Building reliable component-based software systems”, Artech House Publishers, 2002 [8] S. Russel and P. Norvig, “Artificial Intelligence – A Modern Approach”, 2nd Edition, Prentice Hall [9] aiT Worst-Case Execution Time Analyzer, http://www.absint.com/ait/ [10] SymTA/S, http://www.symtavision.com/ [11] ETAS ASCET-MD, http://www.etas.com/ [12] P. Feiler, “The SAE Architecture Analysis and Design Language Standard”, SAE Aerospace standard, November 2004 [13] Predictable Assembly from Certifiable Component (PACC), http://www.sei.cmu.edu/pacc/ [14] S. Poledna et al, “ERCOS: An Operating System for Automotive Applications”, SAE 1996 World Congress [15] OSEK (Opem Systems and the Corresponding Interfaces for Automotive Electronics), Operating System, 1995 [16] Robert Bosch GmbH, “Diesel-Engine Management 4th Edition”, Bentley Publishers, 2006 [17] R. Henia, A. Hamann, M. Jersak, R. Racu, K. Richter and R.Ernst. "System Level Performance Analysis - the SymTA/S Approach." In Proceedings Computers and Digital Techniques 2005 [18] Meoller, Peake, Nolin, Fredriksson and Schmidt, “Component-Based Context-Dependent Hybrid Property Prediction”, Workshop on Dependable Software Intensive Embedded systems 2005 [19] Ji, Wang, Liand Qi, “Automated WCET Analysis based on Program Modes”, In Proceedings of the 2006 international workshop on Automation of software test
10. Conclusion This paper describes how we extend the Bosch software component model (BlueArx) to specify nonfunctional component properties and modes information. It also describes how proposed concepts are used to predict system properties more precisely and accurately. The applicability of the proposed concepts is demonstrated with an engine control system. We demonstrate how mode dependent timing behavior is automatically extracted from the software, described in the component specification and used for analysis and prediction in real-time embedded systems. This paper has shown that semantic context information such as modes enhances performance analysis and prediction by ruling out infeasible worst-
38
