Use model-driven development for extensible automotive system design - Embedded.com

Use model-driven development for extensible automotive system design

Developingsafer, more comfortable andenvironmentally friendly vehicles thatinclude the latest features consumersdemand is a daunting challenge that’sbecome even trickier for automotiveengineers.

Forinstance, maintaining competitiveadvantages in today’s marketplace meanscreating increasingly complex embeddedelectric and electronic (E/E) systems inless time and with fewer resources. Thattask is made even more difficult by risingvehicle integration and the dynamicrequirements of external interfaces.

Nonetheless,there are ways engineers can ensure theinteroperability of future electronicdevices with current vehicle E/E systems,as well as integrate software-enabledfeatures and capabilities more efficientlyinto existing E/E systems across avehicle’s life cycle.

Leveragingstandardization is one line of attack. TheAutomotive Open System Architecture(Autosar) is a good example of howexchangeability and transferability ofsoftware modules is achievable acrossdifferent electronic control units (ECUs).

Another possible tactic is to go the open-source and open-communities route through organizations such as the GENIVI Alliance.

Both approaches—standardization and open source—are useful for providing extensibility, but they are not enough. To ensure extensibility, a structured approach to system development is required.

A structured approach is partially enabled by standardization, as the Autosar example shows. Autosar standardized not only middleware, but also how E/E systems and components are described and how those descriptions are stored and exchanged.

Autosar thus is a good start, but more is required. We propose a model-driven systems development (MDSD) approach.

MDSD raises the abstraction level to gain a better understanding of the system, and allows detailed design while maintaining interface consistency.

MDSD is a structured approach for automotive E/E systems and ECU engineering that follows a development paradigm focused on models as central artifacts to analyze requirements, capture architecture, and specify functional behavior and interfaces.

In other words, different perspectives need to be expressed, as depicted in Figure 1 . Modeling improves communication and enables early and continuous verification and validation. 


Figure.1. Modern Modeling Quadrathlon provides different perspectives needed for improving communication and enabling early and continuous verification and validation.
Click on image to enlarge.

MDSD uses a language for constructing and expressing models. Graphical modeling languages preponderate compared with purely textual notations, because they better support the above-mentioned objectives of collaboration and documentation.

Extensibility is a key advantage of industry-standard languages such as the Unified Modeling Language (UML) and Systems Modeling Language (SysML). In fact, SysML can be seen as an extension to UML. Profiles allow redefining or extending the base language for specialized purposes or domains.

For example, a safety analysis profile could be created that would account for such elements as hazards, faults and safety measures. The standard UML diagrams might even be extended to include a fault-tree analysis diagram.

MDSD raises the level of abstraction to gain a better understanding of the overall system and allows detailed design to occur while maintaining consistency of interfaces across subsystems. It provides a mechanism to analyze the consistency and feasibility of textual requirements: by creating a more complete specification of requirements, by organizing them from a feature perspective and by validating that feature in the context of its environment through simulation and execution.

Requirements are traced directly to model elements that satisfy the requirements. Through an iterative development process, the models are elaborated further, enabling the capture of end-to-end traceability between high-level requirements and the final implementation. Figure 2 depicts those processes. The system is decomposed into subsystems, with the vehicle partitioned into its E/E domains, each E/E domain realized by a set of ECUs, and so forth.

During decomposition, functional, logical and physical architectures are derived, with each realizing a set of allocated requirements and use cases. MDSD ensures the traceability from one level to another. So MDSD is not only about models, but also about the processes of when and what kind of models are built.

Models are built to create good E/E architectures. In the context of extensibility, “good” means suitable to integrate future software applications with the lowest possible effort. Abstraction layers, such as the Autosar Runtime Environment, allow for the plugging in of software components without modification.

Modern infotainment and human-machine interface (HMI) platforms provide similar services. They are enabling automotive OEMs to add even higher levels of abstractions into their ECUs, representing architectures that enable vehicle-function-oriented design and development, all of which is facilitated by modeling.

“Good architectures” could also mean those with the lowest possible overhead, which can conflict with the decision to introduce additional abstraction layers. Thus, during development, it is important to weigh the relative benefits and disadvantages of each architectural and design option in the context of the full project. Each decision might affect such factors as cost, weight, power or scalability.


Figure.2. System decomposition in MDSD separates subsystems of the vehicle into its E/E domains, each E/E domain being realized by a set of ECUs.

Designers leverage trade-off studies to assist in deciding upon a solution that best meets a project’s overall needs. MDSD provides a suitable approach for efficiently conducting such studies. Unlike tests of fully developed prototypes, the execution of a model helps to make validated design decisions early in the engineering process. MDSD can therefore aid in determining the best architecture for satisfying the different, often conflicting, requirements of a system design based on the weighted importance of each criterion.

MDSD can also help meet timing and performance goals, important aspects of any E/E system design and ECU implementation. Through an MDSD approach, you can address the following questions when it is still cost-effective to do so: Does the ECU still have available resources? Can the processor execute another runnable entity within an operating system task? Will it be possible to add one more signal to the bus?

Typically, these questions are answered once hardware and software are integrated. At that time, it may be too costly or too late in the development life cycle to implement changes, however. Using MDSD, you can combine models describing the expected hardware and operating system behavior with models of the application software and their resource consumption, so performance and timing analysis can be run prior to hardware availability.

Ideally, these models are closely related to the models already used for architecture, design and trade-off studies.

Another factor in improving and effectively managing extensibility is addressing variation across vehicle product lines over time. By incorporating product line engineering methods into an MDSD approach, you greatly improve the ability to manage these variants. The process outlined in Figure 2 i s not limited to describing the development of one specific vehicle or ECU model; it is capable of describing variants for multiple versions of that vehicle.

Today, many tool providers claim to support MDSD. But when adopting the strategy, it is important to check the suitability of the proposed solutions. Is the offering based on standardized languages?  Are automotive-specific languages such as Autosar supported? Are the above-mentioned techniques—trade-off studies, timing and performance analyses, and product line engineering—supported?

Does the solution provide commonly accepted or standardized exchange formats? Can you jointly manage requirements with models? To what extent can you integrate existing modeling tools and languages? Are workflow management and team collaboration supported?

Overall, the solution must be extensible—just like the E/E systems built with it.

You can use models not only for collaboration but for simulation, analysis and code generation as well. Extensions to models that allow OEM or supplier-specific notations, such as functional networks, are also possible.

The IBM Rational software solution for automotive systems, for example, provides an open and extensible platform capable of managing SysML, UML and Autosar models. Further, it allows for the integration of models from The MathWorks Inc. Additional modeling extensions support fault-tree analysis for the ISO 26262  functional-safety standard and product line engineering.

Hans Windpassinger is go-to-market manager for automotive at IBM’s Rational software division. Ron Felice works closely with engineers as senior modeling specialist at IBM Rational.

This article was previously published on EETimes  

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.