The increasing complexity of software, as well as there is no standard software architecture for automotive systems and cost reasons resulted in the industry developing AUTOSAR.
AUTOSAR – or AUTomotive Open System ARchitecture – was founded in 2003 as a global development partnership of automotive manufacturers, suppliers, and tool developers.
The aim of AUTOSAR is to create and establish an open and standardized software architecture for automotive electrical-electronic (E/E).
Goals include the scalability to different vehicle and platform variants, transferability of software, the consideration of availability and safety requirements, a collaboration between various partners, sustainable use of natural resources, maintainability during the whole product lifecycle, and being able to slip applications over multiple ECU’s without redesigning the complete application.
The extra data in AUTOSAR applications are stored in XML files called ARXML. This can be parsed and imported and tools can in that way exchange information in a standard way.
What can IBM and Softacus do for you?
Autosar modeling
IBM Rational Rhapsody can be used to create diagrams in C to simplify the construction of an AUTOSAR system. Elements can now be group by their role, not only by their type. You can also define roles using profiles and specify a role per element.
Rational Rhapsody extends the benefits of model-driven development by allowing developers to work in either a functional or object-oriented environment. The developers can create models using familiar concepts such as blocks, flows, graphical files, functions. You can use the AUTOSAR functionality to design automotive systems and software applications. You can use the AUTOSAR-related profiles for the architectural description of an AUTOSAR model that uses the native AUTOSAR concepts.
Rhapsody provides the AUTOSAR profiles that you can use for modeling components in accordance with the AUTOSAR standards.
AUTOSAR modeling employs two standard UML diagrams: use case and sequence diagrams. It also supplies special automotive diagrams. As in UML, AUTOSAR elements are organized in packages. Each package can contain sub-packages and can be exported to ARXML. Where diagrams cannot be used, the browser is used to input elements.
You can define the element-specific role using profiles. You can specify the role in the Rhapsody browser.
Defining AUTOSAR Blueprints
You can define the infrastructure for Blueprints such as ports and interfaces blueprints, application data type blueprints. You can apply the blueprints to the existing model elements and check for compliance with standards.
How it works?
A blueprint is an element that, together with possibly other referenced elements, defines how user-model elements can be derived. The blueprint also defines certain characteristics to be applied to existing user-model elements.
Model elements can be derived from a blueprint, reference a blueprint, and derive various characteristics of the blueprint. If you derive model elements from a blueprint, you apply a blueprint to a model element. The relationship between a blueprint element and the blueprint that was applied is recorded in the model by using Blueprint Mappings. A Blueprint Mapping has two references: one to the blueprint and one to the element that has the blueprint applied. The blueprint mappings are contained within Blueprint Mapping Sets. The Blueprint Mapping Sets are contained within packages.
The Blueprint tab in the element's Features dialog shows a previously applied blueprint. It also allows the selection of a blueprint to apply to the current element. The Blueprint tab is shown only for the elements that have the blueprint applied, and are not contained in an ARPackage.
Creating AUTOSAR projects
You can create AUTOSAR projects. AUTOSAR contains software, electronic control units, a system description, and the mapping of the software to hardware. The AUTOSAR functionality can be used in C language projects.
Projects that are based on the AUTOSAR profiles can be exported from IBM Rational Rhapsody to the AUTOSAR XML format, and you can import the data that is stored in the AUTOSAR XML format.
The role and type values represent the AUTOSAR model's definition and the relations between them. The role-based type uses roles that, in most cases, define the Rhapsody profiles. The type-based profiles are using the type values, only.
- ECU diagram defines electronic control unit (ECU) types and ports.
- The implementation diagram describes the programming-language realization of internal behavior. Each internal behavior is associated with one atomic software component type.
- The internal Behavior diagram defines the internal workings of an atomic software component type.
- SW Component diagram defines the software (SW) components and connects them.
- The system diagram defines an AUTOSAR system at the required level of detail.
- The topology diagram defines the physical system as ECU instances and how they are connected.
Applying the AR3x_BMT profile
You can apply the AR3x_BMT profile, that supports the AUTOSAR concept-to-code in the Behavior Modeling Tool (BMT) environment, to IBM Rational Rhapsody projects designed in the C language.
In an AR3x_BMT project, you can organize the model into two specific packages:
- The AR Packages package contains the AUTOSAR system design, such as atomic software component types, internal behaviors, runnable, and other elements. These elements are used to export AUTOSAR XML (ARXML). You can also create these elements by importing an ARXML file.
- The ARBMTPackages package contains the Rational Rhapsody implementation blocks (RIMBs) and related elements that are used to implement atomic software component types. A RIMB is a class whose instances are used to implement AUTOSAR atomic software components. This type of implementation block is a special AUTOSAR class; it bridges the AUTOSAR domain and the Rational Rhapsody UML domain.
The picture to the left shows generated code with automatically generated active operations.
Generating code with the Transformation Manager
You can generate code using model-to-model transformations using the Transformation Manager utility.
The Transformer Manager utility performs model-to-model transformations. The complete model-to-model transformation is defined using a sequence of one or more model-to-model transformations. A Transformer is implemented using a Rhapsody plug-in. The Transformer can access the relevant part of the model via the scope of the active component.
AutomotiveC profile
The AutomotiveC profile automatically loads the MicroC profile, which contains code-generation capabilities designed for static systems. In a project with this profile, you can create an architecture diagram in which you specify the architecture for your automotive project.
You can use drawing tools that you typically see in a class or object model diagram, and also the architect diagram has drawing tools for flow ports and network ports. The AutomotiveC profile also includes a number of features intended specifically for the automotive projects, such as:
- Automotive-specific adapters, based on the user of configuration-level stereotypes
- Simulink and block integration capabilities
The integration of the AutomotiveC profile with Simulink S-functions can be either to have the:
- Rational Rhapsody model run inside a Simulink model, or
- Simulink model run inside a Rational Rhapsody model.
If you use a Simulink model embedded in a Rational Rhapsody model, then you can use the Simulink S-functions.
Managing large AUTOSAR projects - Importing / Exporting AUTOSAR XML files - Migrating to a different version
You can create port binding tables to improve workflows when working with large systems such as AUTOSAR projects.
The AUTOSAR SWC port binding table simplifies the understanding of the overall architecture of a system by showing the system binding, compositions, and the mappings in a single view of the model. This capability is available for projects created with the AUTOSAR profiles.
You can import AUTOSAR XML files into a new or existing Rational Rhapsody model, and you can export the data from your model to one or more AUTOSAR XML files. Import and export of AUTOSAR XML files can also be done from the command line.
You can migrate existing AUTOSAR projects to different versions of AUTOSAR. For model elements whose type does not exist in the target AUTOSAR version, if there is more than one possible replacement element type, you can choose what element type to use. This choice can be made separately for each such model element.
