in Component Based Software Development. Ji Eun Kim ... Corporate Research, Robert Bosch GmbH ... extensively used for many years to develop software.
11th IEEE Symposium on Object Oriented Real-Time Distributed Computing (ISORC)
Software Behavior Description of Real-Time Embedded Systems in Component Based Software Development Ji Eun Kim, Rahul Kapoor Research and Technology Center Robert Bosch LLC
Martin Herrmann, Jochen Haerdtlein, Franz Grzeschniok, Peter Lutz Corporate Research, Robert Bosch GmbH
{JiEun.Kim, Rahul.Kapoor}@us.bosch.com
{Martin.Herrmann, Jochen.Haerdtlein, Franz.Grzeschniok,Peter.Lutz}@de.bosch.com level of abstraction for software construction, and by sharing standardized services. In automotive domains, the AUTOSAR (AUTomotive Open System Architecture) consortium has been organized to provide an open and standardized automotive software architecture. The AUTOSAR component model is specified as a ‘Software Component Template’ which provides a meta-model for the software component specification. 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][4]. Bosch has employed state-of-the-art Component Based Software Development (CBSD) during the last few years. A proprietary component model has been developed and is currently used in the Software Product Line (SPL) [6] practice of engine control systems. The CBSD practice is extended to other automotive domains such as chassis systems. The Bosch component model aims to support the representation of substantial aspects of the software architecture views as follows: - Static view: details of the interface, such as data structures, services and physical characteristics on different abstraction levels - Dynamic view: dynamic aspects such as tasks, services and operating conditions to provide scheduling information - Functional view: functionality of a component such as signal flows and functional relations [1]. Static view and dynamic view of a software system are well defined in so called “use-cases” of CBSD. Use-cases define rules for which entities of a component specification should be specified in accordance to software development processes as well as stakeholders’ interest. For example, component developers specify the static view of usecases when developing components. Resource engineers specify the dynamic view of use-cases by providing scheduling information. However, the current practice of CBSD does not provide concrete use-cases and a corresponding meta-model to make
Abstract Component Based Software Development (CBSD) has been established in the development of automotive real-time embedded applications at Bosch. CBSD together with Software Product Line (SPL) practice has improved software reuse, productivity, quality and complexity management, by raising the level of abstraction for software constructions and by sharing services. Although CBSD has contributed to the aforementioned improvement in the software development practice, the existing Bosch component model often requires software developers to take a close look at the implementation including models (e.g., ASCET-MD1) and even complex source code to understand software behavior and dependencies when reusing and adapting software components. This hinders the realization of the full benefits of CBSD, as the available information on the component level does not sufficiently describe important aspects of software behavior. This paper presents the concepts and case studies of ‘signal flows’ and ‘mode dependent signal flows’, which provide crucial software behavior information for real time embedded systems at the component level.
1. Introduction Component Technology (CT) has been extensively used for many years to develop software systems in desktop environments, office applications, and web-based distributed applications. Using CT, software systems can be built by assembling components developed in-house or by third parties. The advantages of CT include effective management of complexity, reduced time to market, increased productivity, improved quality, greater degree of consistency and a wider range of usability [5]. These advantages are achieved by facilitating the reuse of components and their architecture, by raising the 1 ASCET-MD is a software modeling tool developed by the ETAS group.
978-0-7695-3132-8/08 $25.00 © 2008 IEEE DOI 10.1109/ISORC.2008.69
307
The Bosch software component model provides the specification of scheduling information to generate a system scheduling. 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 functional view explicit from the implicit component specifications. This paper provides our proposed concept to support the functional view (software behavior) in the CBSD and a case study with an engine control system used in the real product.
2. Software Component Model
3. Software Behavior in the Component Specification
The Bosch software component model has been developed for the classic automotive domains (e.g., engine control systems and chassis systems) where the resources are extremely constrained due to hardware cost, and real-time, reliability and safety are considered as important non-functional requirements. These systems are closed control loop systems that receive physical values from sensors, process computations and control actuators with new physical values. The Bosch software component model focuses on the design time component model to support aforementioned constraints and nonfunctional requirements. This section provides relevant aspects of the existing component model that are necessary to understand our proposed concept. The Bosch software component model provides two types of components: atomic components and structural components. An atomic component is a unit of specification, and has an implementation. It is a leaf in the software architecture tree. A structural component is a unit of specification, and has a decomposition. It represents a node in the software architecture tree. A component has interfaces and the Bosch component model divides interfaces into two types: import interfaces and an export interfaces. An import interface specifies variables, messages, services, calibration parameters 2 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 systems. A structural component is composed of several atomic components and/or structural components. A structural component can import and export a subset of interfaces from each atomic component. Bosch software systems use global variables (messages) for communication between components. A component specifies its message access properties (read, write, or read/write) in its interface description. The data flow between the components can be extracted from this information.
3.1 Concept of signal flows A signal flow refers to externally observable flow of information in terms of application logic through a component [2]. Our concept considers three types of signal flows for engine control systems as follows: - Flow between components: this refers to a signal flow between software components - Component internal flow: this refers to a signal flow within a software component. This type of flow information helps to identify the dependencies of an output of a component to its input values - End-to-end flow: this refers to a signal flow that originates at a sensor, propagates through various software components and terminates at an actuator. It is possible to specify an end-to-end flow in terms of flow between components and component internal flow. Figure 3.1 illustrates these three types of flows. Sensors
ECU SW System SW Component
Actuators
A
S
A
S
A
S A S Flow between components Component internal flow End-to-end flow
Figure 3.1 Three types of signal flows
3.2 Concept of mode dependent signal flows We introduce mode dependent signal flows which can be applied to all three types of signal flows described above. In many cases, the signal flow through a system depends on the different modes of operation. This means that the flow of information may change its path depending on the mode in which the system is operating. As an example, Figure 3.2 shows that the signal flow through component A is different depending on whether the component is normal mode or failure mode.
2
Calibration parameter (value, map or curve) is usually stored in the non-volatile memory and used after compilation time to adjust the system behavior. It is often used in automotive domains and the values of the parameters influence on the runtime performance of the system.
308
Mode refers to a Boolean expression of one control source or a set of control sources and it changes the dependencies of signal flows. Figure 3.3 and Figure 3.4 illustrates a metamodel description of our concept in UML format.
Mode normal
Mode failure
Component A Input
Figure 3.2 Mode dependent signal flows Data
Mode dependent signal flows enable better understanding of the system and more precise flows analysis. It can help to manage the complexity of flow visualization by highlighting only those flows that are relevant to a particular mode. Moreover, since the path of execution through a component is mode dependent, certain properties of a flow (e.g., latency) also depend upon the mode in which the component is executing. Thus, specifying mode dependent properties of flows helps to make flow based analysis more precise.
Component
Constants
Mode
Flow
Control Info
Figure 3.4 Meta-model for modes
4. Case Study: Engine Control System This case study provides the results of the component specification of different kinds of flows. A diesel engine control system is used for this case study.
3.3 Component Specification Our concept defines the following elements to compose a signal flow in the component model. Flow specification of a component consists of one or more sources, one sink and dependencies between the sources and the sink (the entity could be an operation, a component or the entire system). Source is the origin of information and is an input to a component. A source is used for a computation or control, or both. Sink is the consumption of information and specifies a particular output of a component. Stop is also used for the consumption of information and means end of a flow. If a source is used in a condition expression, the type of source is called control source. Control source can restrain the number of flows. A sink does not have a sub-type unlike computation and control types for a source because the usage of a sink is not defined by the entity.
4.1 Signal flows between components The existing Bosch component model provides an implicit way of representing signal flows between components. As described in Section 2, our software systems communicate using global variables (messages). Thus, we extract signal flows between components by parsing interface specification and access properties (e.g., read/write access) of messages.
Computation Source
Source
Control Source
Variable
System Constant Dependency
1..n Flow
Property 0..n
1 Latency
Stop
Figure 4.1 Signal flows between components
1 1
Figure 4.1 illustrates an example of signal flows between components of a small subsystem. The signal flows between components are automatically generated by our in-house tool by exploiting the
Sink
Figure 3.3 Meta-model for signal flows
309
of the system in that mode. Corresponding elements in the flows visualization diagram shown in Figure 4.1 will be excluded for a particular mode. - Different controlling: Within a single component or service, 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 the engine; calibration parameters are switched for different modes; different branches are taken depending on modes. We observed that different controlling is often realized using ‘switch’ element of the ASCET-MD model. Figure 4.3 shows an example of component internal flows with and without modes information. The example demonstrates that a component internal signal flow can change depending on the mode. For example, O-3 depends on I-5, I-10, I-11, I-12, I-15, I-16 and I-17 in the first mode and all of those inputs plus I-3 in the second mode.
component specification as described. (Note that all the message names are removed in the import and export interfaces, and components and services information are renamed for confidentiality) The messages which are not connected between components are usually used by other components from different subsystems (which are not shown in this visualization).
4.2 Component internal flows In this case study, we extracted component internal flows by looking at software models written in ASCET-MD and visualized the results. An original software model written in ASCETMD for a component is shown in Figure 4.2. We first get the list of flows sources (I-1 .. I-17) from the import interface and the list of flows sinks (O-1 .. O6) from the export interface of the component specification. Then, all elements within the model are traced by using backward slicing from one sink to multiple sources. After that component internal signal flows are graphically visualized by connecting sources and sinks at the component level based on the backward slicing results. Figure 4.3 (a) shows all the component internal flows for one example component obtained throughout the procedure illustrated above.
sources (control) I-2
I-12 I-13 I-14 I-15
I-1 O-1
I-3 I-4
O-2
I-5 I-6 I-7
sources (computation)
O-3
I-8
sinks
I-9 I-10
O-4
I-11 O-5
I-12
O-6 I-15 I-16 I-17
(a) Component internal flows without modes
Figure 4.2 ASCET-MD model
Regeneration mode: {I-15 == REGENERATION} I-2
4.3 Mode dependent signal flows
Diagnostic mode: {I-12 > THRESHOLD}
I-12 I-13 I-14 I-15
I-2
I-1
In this case study, modes influence on software behavior in the following aspects: - Different scheduling: components and services belonging to a component are activated differently depending on the mode. For example, services for the initialization mode are different from normal cyclic executive mode. In addition, the period and the order of execution for services are also scheduled differently for different modes. Thus, signal flows vary in each mode, since different services often use different information. Note that this case study does not include the visualization results on this aspect, because it is easy to understand that certain components that are not executed in a particular mode are excluded from the signal flow visualization
I-12 I-13 I-14 I-15
I-1 O-1
I-3 I-4
I-3
O-1
I-4 O-2
I-5 I-6
I-5
O-2
I-6
I-7
O-3
I-7
I-8
I-8
I-9 I-10
I-9 I-10
O-4
I-11 I-12
O-3
O-4
I-11 O-5
I-12
O-6
O-5
O-6
I-15
I-15
I-16 I-17
I-16 I-17
(b) Mode dependent component internal flows
Figure 4.3 Mode dependent signal flows
310
5. Benefits
7. Related Work
This section summarizes the benefits of having signal flows and mode dependent signal flows in the component specification for closed control loop applications. Existing Bosch software component model and many other software component models used in embedded software development have provided abstract information of software components. These component models enabled a certain degree of reuse of software so far. However, in many cases more information is needed for more effective reuse of software components and to guarantee the correct software functionality. The signal flow information specified in the components can improve current practice of software reuse by providing crucial information for dependencies while preserving the level of abstraction needed for the component. The visualization of signal flow information enables better understanding of system functionality because software developers are able to know the dependencies between the elements in the interfaces of components without looking at the source code or models in detail. Therefore, it helps to understand the causes and effects of changes. Due to the natural complexity of the domain itself, there are many flows even within a small subsystem that make it difficult to understand the system when visualizing flow diagrams. We demonstrated that modes can reduce such complexity by representing the signal flows relevant to a specific interesting mode. In addition, we expect to use the signal flows information for various analysis such as end-to-end latency analysis, error propagation analysis, etc.
The concept for flows and mode specification in AADL and AUTOSAR is similar to the concept in our Bosch component model. Bosch worked and/or works closely with both technologies. Architecture Analysis and Description Language (AADL) is developed by Software Engineering Institute at Carnegie Mellon University. AADL introduces the hierarchical flows concept. AADL provides top-down approach. Flow specification represents flow sources, flow sink and flow paths. AADL defines a mode representing an operational state, which manifests itself as a configuration of contained components, connections, and modespecific property value associations [2]. The AUTOSAR software component model includes modes specification. In AUTOSAR, a mode specific behavior is determined by the configuration of runnable entities contained in the software component [3][4].
6. Future Work
9. References
An automotive software system such as an engine control system consists of thousands of components. It is a big challenge to extract signal flows and modes information from legacy software components without support from an automated tool. We looked at existing software and found several patterns of how signal flows are connected and propagated, and how the various modes are propagated from a global mode to a local mode to control a subsystem. We are currently developing a tool for automatic extraction of signal flows and modes information from component specifications and models.
[1] Bernhard Weichel and Martin Herrmann, “A Backbone in Automotive Software Development Based on XML and ASAM/MSR”, SAE 2004 World Congress [2] Peter Feiler, “The SAE Architecture Analysis and Design Language Standard”, SAE Aerospace standard, November 2004 [3] AUTOSAR consortium, http://www.autosar.org [4] AUTOSAR Software Component Template V 2.1 [5] Ivaca Crnkovic and Magnus Larsson, Building reliable component-based software systems, Artech House Publishers, 2002 [6] Paul Clements and Linda Northrop, Software Product Lines, Addison-Wesley, 2002 [7] Robert Bosch GmbH, Diesel-Engine Management 4th Edition, Bentley Publishers, 2006
8. Conclusion This paper introduces the current practice of component based software development for automotive systems at Bosch. We propose the concept to support software behavior description at the component level and demonstrate the usage and benefits using a real-world example (engine control system). The proposed concept to specify software behavior using ‘signal flows’ and ‘modes’ in the component model can improve software reuse and productivity by reducing the effort to look at the implementation details and effectively exploiting abstract information at the component level.
311
