Software-enabled features in automotive and other embedded systems continue to grow in size and complexity. This growth calls for corresponding improvements in development approaches and tools if we are to ensure cost and time efficiency throughout the entire lifecycle. Notable bottlenecks include the integration of different subsystems and the consolidation of various engineering aspects, where tool support is becoming ever more important.
Integrating high-level development information across tools is only possible with a model-based approach to system development and quality management. For architecture models of embedded software systems, such an approach not only captures the software functionality, but also its corresponding engineering concerns, such as requirements, resource deployment, timing and safety, variability, etc.
The focus is raised from the implementation details of individual features to the design of the entire system as an integrated whole. By formalizing architectural artifacts and clarifying the formalisms used, a model-based approach also makes it possible to ensure the consistency and completeness of system descriptions, offer early predictions about system behaviors and properties, and enable formal design space exploration and optimization.
In this article we present our experiences on how companies can ease the transition to model-based architecture design and begin reaping its benefits. We take automotive E&E (Electric & Electronic) systems as an example here, but the principles and tool support are not limited to the automotive domain.
Integrating with current processes and implementations
One of the first questions companies face is how to define architectures when existing designs and implementations are available. Three mutually complementary mechanisms can be used to help align the planned architecture with its design and implementation solutions.
With the first mechanism, existing designs and implementations are used to create initial architecture models. In our example of automotive systems the module designs are Simulink models.
We extract only the parts relevant to architecture, such as the hierarchical composition of modules and their communication via ports. This process is automated in MetaEdit+ by a generator system which parses the Simulink models, extracts the relevant parts, and creates the architecture model. While reverse engineering like this may not lead to the ideal architecture design, companies often find it an appropriate solution to lower the effort needed to modernize development practices.
The second mechanism also parses existing models and legacy code, but now for the purposes of consistency checking: The architecture design is verified against an existing implementation to report any differences. This offers good support for comparing the planned architecture with the actual implementations provided by various suppliers. The comparison checks the architecture-level interfaces of individual modules, like ports, connections and interfaces. Figure 1 illustrates the automated checking with a typical architectural view: the functional components of a power supply and their connections via ports.
At the bottom of the screen the results of the consistency check are shown: the corresponding Simulink model includes a port ‘PowerConversionCtrl’ which is not found from the planned architecture. Engineers can next investigate whether the implementation should be changed or the architecture updated. The check may also cover other architectural elements in addition to those illustrated in Figure 1, such as interfaces, client/server based connections, power connections or I/O connections.
The third mechanism is to synthesize more specific design and implementation specifications, such as module designs or code, based directly on the architecture models. In our automotive systems example, we can generate Simulink models directly from the architecture models, ensuring that the modules allocated to different suppliers are compliant with the overall architecture.
On the tool level, the actual integration is achieved by using the interfaces and integration facilities of the tools. For these architecture models we used the generator system of MetaEdit+, and the API and file formats of Simulink. When selecting tools, the availability of open interfaces and mechanisms for data exchange is of key importance for efficient integration. The tools should be examined with an open mind, as their support for integration may not correspond to traditional views of ‘openness’: an open source tool may offer no existing interfaces for communication with other tools, while a commercial tool may offer multiple interface mechanisms and ready-made integrations.
In a broader sense, architectural models can be integrated with other existing data, such as requirements in a dedicated requirements management tools, Excel or other office tools. Figure 2 illustrates the support for requirements that are originally provided in spreadsheets but now been imported into the architecture designs. The ‘satisfy’ link in the matrix shows the well-defined traceability from imported requirements to individual parts of the architecture.
As an additional feature, any changes of the requirements are reflected automatically in these tool environments. With such tool support, requirements can be managed flexibly within the development process, either as a part of architecture model or in separate requirements management tools. Common formats can be used for integration, e.g., ReqIF for requirements interchange.
Architecture models and their use
The functionality of automotive software systems is typically specified with a functional view, with functional blocks and connectors capturing the application logic and system boundary. Figure 1 illustrated such a functional architecture model. Such a model plays a key role in system analysis and synthesis, associated with other models capturing the behavioral, extra-functional and technical constraints.
For embedded systems, a key design decision is the deployment of computation and communication resources. To facilitate this part of design, we need hardware architecture models describing the physical components and their connections.
Figure 3 shows an example of the hardware architecture of a braking system, including sensors, ECU nodes, actuators, electrical components and the various hardware connections between them.
This model is created using the hardware architecture view of EAST-ADL , a domain-specific language for automotive architectures. This language directly uses familiar automotive concepts (e.g., ECU, Bus speed and Wire) and understands the related automotive rules and constraints, making models easier to create, read and validate.
For example, every concept of EAST-ADL language has its own properties, so when a developer is creating an element, only the relevant properties are asked for. Similarly, every element has its own notation on the canvas, clearly distinguishable from others yet with common graphical conventions. The language also checks the completeness and correctness of the models as it is made, so it is formal and can be used for analysis and as an input for generators.
Allocating functions to hardware
Architecture design helps combine the functional and hardware views of the system. In Figure 4 the allocation matrix shows functions on the vertical axis on the left, and physical hardware on the horizontal axis. The allocation of a function to hardware is shown by a ‘FunctionAllocation’ symbol in the corresponding cell between those elements.
It is also possible to visualize the allocations directly in the hardware architecture: while making allocations the hardware architecture can be made to show the currently allocated functions inside each hardware element (Figure 5 ).
Targeting software platforms. While the architecture itself can be designed collaboratively – even editing the same diagram at the same time – models can be used for a wide variety of needs. For example, based on the allocations, as in Figure 4, the architecture can be transformed to the software component structure following a particular software platform. The allocation can also be used to map the functionality to different kinds of platforms at the same time: some parts can be running in internal frameworks and others in AUTOSAR, for example.
Automating safety design flows
The architecture models also lend themselves to various analysis needs. For example, safety design flows and standards like ISO26262 can be supported via architecture models. Instead of generating .arxml for AUTOSAR, the architecture models can be used to produce initial dependability and error models.
This is possible because the architecture modeling language produces formal models that are checked to be correct and complete input for generators. Figure 6 shows an error model that is produced automatically from an architecture model. Such a transformation helps safety engineers to consider all aspects of the actual planned architecture during safety design phase.
The error model then forms the basis for safety analysis and can already be analyzed for error propagation. Figure 6 shows the possible causes for a failure in the output port third from the top on the right, which has been marked with blue ‘error’ text. The functions or inputs that may be the cause of the failure in this output port are automatically highlighted with a blue outline.
While architecture design focuses on theconfigurations of a system, a useful byproduct is that it associatesbehavioral properties to the requirements, structural units, and otherarchitectural artifacts.
For example, in EAST-ADL, behaviormodels are used to support the refinement of textual requirements byformalizing their behavioral concerns such as the boundary conditionsand invariants of variables, states and state transitions. This enables aseamless integration of behavior models and requirements.
Another example in EAST-ADL is shown in Figure 7 ,where abstract behavior specifications, referred to as behaviorconstraints, are associated to some system blocks. All the instanceswill then follow the corresponding type constraints. In the design, suchconstraint annotations are necessary for many reasons, such ascompositionality assessment, composability checks, or cross-modelconformity control.
Alongwith the run-to-completion semantics of its execution, each functionalblock in the architecture can have a behavior constraint consisting oftimed properties. These timed properties can be expressed as arithmeticquantifications, state machines or computational control flows. Figure 8 shows the declaration of a state machine constraint for the batteryfunctions, for which the state invariants and guard conditions showrelated arithmetic quantification properties.
Inour example, within MetaEdit+, a model-checking gateway parses theconstraint description and produces some external models. The mappingrules are implemented as an algorithm in the generator languageavailable for developers using MetaEdit+. Developers may thus modify thegenerator depending on the analysis tools in use, or even create theirown new generators.
For example, there are already generators for analysis tools like SPIN, UPPAAL, HiP-HOPS , and Modelica , each performing their own different kinds of analysis tasks. Figure 9 shows the external models generated from the state machine constraintand its system composite for the UPPAAL tool in which the state machinesare then executed.
Tofacilitate safety engineering, MetaEdit+ can automatically create aninitial setup of such error models according to a nominal architecturemodel. Within each error model block, engineers then specify error logicrelating the declared component output failures to the received andlocal faults. The exact formalism can be based on a Boolean logicexpression or state machine (SM).
Figure 11: Error model defining the plausible error behavior of target system architecture
Architecturemodels offer several additional benefits compared to the traditionaluse of models focusing on implementing a single feature. Most visible isthat they allow the design of the larger system as an integrated whole.Supporting tools then enable team members to create and edit thearchitecture in a collaborative and concurrent manner. Architecturemodels also help in managing the development activities, which ofteninvolve dozens of suppliers: Individual parts can be split among variousteams and the resulting implementations can be integrated and checkedwith the whole architecture.
Reapingthe benefits of architecture models does not require creating thearchitecture separately or ahead of time. Tools are already availabletoday that can automate significant parts of the task, like creating theinitial architecture based on an existing implementation. The tools cancheck the resulting architecture models against existingimplementations, or generate the interfaces for the implementations tobe developed. The generators may also produce the configurations andmapping to the target platforms used, such as AUTOSAR, JasPar, orinternal platforms.
Dr. Juha-Pekka Tolvanen is CEO of MetaCase .He has been involved in domain-specific languages and tools since 1991and acted as a consultant world-wide on their use. Juha-Pekka hasco-authored a book (Domain-Specific Modeling , Wiley 2008) and over 80 articles in software development magazines and conferences. He can be reached at .
De-Jiu Chen received his PhD degree in Mechanical Engineering from Swedish RoyalInstitute of Technology (KTH) in 2004 for his research on embeddedcomputer control systems. His research interests include systems andsoftware architecture, model-based engineering, dependability, andself-adaptive embedded systems. He is currently an associate professor at KTH .
Janne Luoma (M.Sc.) works as senior consultant at MetaCase Consulting. His area ofexpertise is in the engineering of software development methods forcompany-specific needs. Janne has over 15 years of experience as aconsultant world-wide for method development and code generators. He canbe reached at .