Make AUTOSAR work for you with IBM Rhapsody

A car today could not be moved without electronics. In fact, you wouldn't even be able to start the engine. Even if you think the steering wheel is directly moving the wheels: it’s not. Electronics do that. Automotive electronics are in charge of a large share of vehicle features and passenger services. With the increasing importance of electronically controlled functions, the need for a rigorous approach to managing modules, interfaces, and development processes became more pressing.

The response is AUTOSAR (AUTomotive Open System ARchitecture), a standardized architecture model for automotive electronics. AUTOSAR was introduced and maintained by a worldwide development partnership of vehicle manufacturers, suppliers, service providers, and companies from the automotive electronics, semiconductor, and software industry. Compliance with AUTOSAR is part of the MISRA guidelines for the development of embedded control systems used in road vehicles.

AUTOSAR is a powerful means to control the complexity of automotive electronics and foster quality, efficiency, and reuse of automotive systems. The challenge: design and implementation of AUTOSAR compatible components require in-depth expertise in the AUTOSAR concept. There is a shortage of experienced AUTOSAR engineers, and the creativity of talented developers should focus on smart solutions rather than being distracted by AUTOSAR syntax and semantics. So how can you make AUTOSAR work for you and your engineers and not the other way around?

A model-based approach supported by IBM Engineering Systems Design Rhapsody, enhanced with IBM AUTOSAR extension (enabled by SodiusWillert), provides an environment that gives your experts the legroom needed for designing high-quality AUTOSAR solutions. The solution briefly outlined in this blog article addresses several challenges the automotive industry is facing:

Traditional “horizontal” boundaries between OEMs and tier1, 2, n suppliers begin to blur. OEMs may consider not outsourcing modules that are of strategic importance.
Similarly, tier 1 suppliers start assuming “deeper” levels for a more unique market position.
Development processes are moving away from a waterfall approach towards agile and iterative concepts, across the OEM/supplier network.
Software enabled capabilities are continuously taking more room, resulting in the ever-increasing complexity of automotive systems and software

In a nutshell, the solution based on using IBM Rhapsody with the AUTOSAR extension allows engineers to do design architecture and modules in SysML and UML, just focusing on a smart solution and without being distracted by any AUTOSAR specific elements. The transformation to AUTOSAR compatible artifacts is accomplished by an automated process provided by the tool. Let’s briefly discuss two fundamental workflows enabled by the IBM Rhapsody and AUTOSAR extension solution:

Workflow for the OEM
Workflow for the supplier

AUTOSAR development – the OEM side

The project starts as usual with the elicitation of requirements, most often using a tool such as IBM Engineering Requirements Management DOORS. System engineers are creating the functional design model in IBM Rhapsody using their familiar SysML notation. Existing modules described in SysML can be integrated into the system under development. Thanks to the built-in model execution capabilities in combination with IBM Rhapsody TestConductor, engineers are already at this early stage able to verify and validate the SysML model “in the loop” with other components of the target system. Existing modules described in SysML can be integrated into the system under development.

Next, the SysML model is automatically transformed into an AUTOSAR compatible architecture model that is compliant with the AUTOSAR standard. The tool will take care of properly “translating” the SysML elements into AUTOSAR elements. Existing AUTOSAR components in ARXML format can be integrated into the system under development as needed. The AUTOSAR architecture design of the entire system is then exported in ARXML format for hand-over to the supplier. The graphic illustrates this workflow:

Make AUTOSAR work for you-2 (Source: IBM)

AUTOSAR development – the supplier side

For the supplier, the process starts with ARXML data received from the OEM. At this level, components can also be reused and imported into the system using the ARXML format. Next, the supplier engineers will elaborate the software design in IBM Rhapsody and AUTOSAR extension to implement the functional behavior of the system under development. They are using the AUTOSAR architecture design as their foundation. The architecture is automatically transformed into AR-UML, allowing the software engineers to describe the behavior in their familiar notation.

At this stage, existing components can be reused by importing and reverse engineering of legacy code and RTEs. Validation and verification on a model level are supported by adding IBM Rhapsody TestConductor to the environment, allowing to verify the AUTOSAR software modules using exactly the same test sequences that have already been used to verify the SysML model at the OEM. While the solution is being modeled, testing can be performed on the virtual or physical target, allowing engineers to perform comprehensive quality assurance in parallel with development. Once the system under development has successfully passed the tests, the finalized production code for the AUTOSAR software components is generated for shipment. The supplier side of the workflow is depicted here:

(Source: IBM)

Summary and conclusion

The engineering environment built with IBM Rhapsody, AUTOSAR extension, and IBM Rhapsody TestConductor enables automotive engineers to quickly model advanced capabilities using standard graphical notations and techniques. Compliance with AUTOSAR is ensured by the tool environment that takes care of the transformation between SysML, UML, AUTOSAR, and AR-UML. Engineers can deliver their AUTOSAR projects with IBM Rhapsody without having to be experts on the details of AUTOSAR, effectively letting the engineers focus on the application domain, the architecture, functionality, behavior, etc., while letting the tool handle all the distinct (and for some, peculiar) aspects of AUTOSAR.

For the AUTOSAR extension delivered by IBM, SodiusWillert has been selected to partner with IBM to add profound AUTOSAR expertise to the tool environment.

Looking ahead, this model-driven approach to AUTOSAR component development has yet another advantage for automotive companies: Compliance with process maturity standards such as ASPICE (Automotive Software Process Improvement and Capability dEtermination) becomes easier, and preparation for a successful ASPICE audit becomes less tedious and time-consuming.

Read IBM Software Announcement for more information.