Reaping the benefits of architectural modeling in embedded design

Juha-Pekka Tolvanen and Janne Luoma, Metacase and De-Jiu Chen, KTH

November 09, 2014

Juha-Pekka Tolvanen and Janne Luoma, Metacase and De-Jiu Chen, KTHNovember 09, 2014

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.



Click on image to enlarge.

Figure 1: Checking the consistency of designs and reporting them with architecture model

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.



Click on image to enlarge.

Figure 2: Importing requirements and aligning them with architecture designs

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.



Click on image to enlarge.

Figure 3: Part of a hardware architecture model

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.



Click on image to enlarge.

Figure 4: Allocating functions to hardware

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).



Click on image to enlarge.

Figure 5: Hardware architecture visualizing allocations made

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.



Click on image to enlarge.

Figure 6: Initial error model generated from nominal architecture

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.

< Previous
Page 1 of 2
Next >

Loading comments...