Automotive companies choose ARTiSAN for safety-critical embedded software development

Founded in 1997, ARTiSAN Software Tools provides products and services to dramatically accelerate the definition, design, and thereby the time-to-market of embedded systems and software. By substantially enhancing and automating “standard” modelling techniques in its ARTiSAN Studio integrated suite of UML/SysML collaborative modelling tools for requirements analysis, specification, design and development of complex, safety-critical systems and software engineering to specifically target embedded systems, ARTiSAN has gained a solid foothold in a variety of automotive accounts including Audi, Blaupunkt, Bosch, Daimler Chrysler, Delphi, Denso, International Truck, Renault, Siemens VDO, Volkswagen, Yazaki, and ZF

ARTiSAN takes a “whole product” approach to the development of complex embedded systems. Its modelling environment addresses the system, software, and even hardware portions of the project. The approach encourages the entire team to spend more time clarifying the overall system, architecture, features, and behaviour, before implementation begins. Many studies confirm that the most expensive problems are introduced in this vital early stage of the project. With ARTiSAN Studio customers can detect substantial problems far earlier in the development cycle, saving costs and improving predictability. This emphasis is a fundamental difference between ARTiSAN and its competitors.

ARTiSAN enjoys a fundamentally superior product architecture, based upon a robust multi-user repository. Automotive companies are drawn to the benefits of ARTiSAN Studio in supporting scalability, team collaboration and coordination through the instant propagation of changes.

ARTiSAN’s objective is to provide customers the “shortest path to the right product.” Using advanced modelling techniques and technology, ARTiSAN can help development teams clarify requirements, simulate systems and software models to validate functionality, and automatically generate as much as 100% of the production software used to implement the system. The result is that problems are identified far earlier in the development cycle, when they are least expensive to fix. At the same time, the approach instills responsible engineering practices, providing repeatability, discipline, and predictability to the development of cutting edge systems.

Adoption of modelling tools for systems and software was previously seen as an “all-or-nothing” proposition, requiring substantial changes to the development process in order to get started. ARTiSAN enables incremental adoption of modelling in three phases: capture of the system and software design in a shared, consistent format (model) instead of ad hoc drawing tools; automation of the models to leverage what has been captured; integration of the various “islands of automation” into a coherent development process.

Driven by constantly evolving safety and environmental regulations as well as customer demand for new features, modern cars now incorporate an exceptionally high level of functionality. This is largely underpinned by a complex electrical infrastructure comprising electronic components and embedded software that must be closely coupled in a network structure that ensures complete and accurate performance. Unfortunately, the solutions generally used for implementing automotive electrical and electronic development are proprietary which makes it difficult to exchange functions and applications between automotive OEMs and suppliers. If this situation continues, maintaining the future growth in functional complexity will require an excessive investment in resources without any guarantee of maintaining control of the development process.

In the light of this situation, the AUTOSAR (AUTomotive Open System Architecture) Consortium was formally launched in July 2003 by its core partners: BMW Group, Bosch, Continental, DaimlerChrysler, Siemens VDO and Volkswagen. They were later joined by the Ford Motor Company, General Motors, PSA Peugeot Citroën and Toyota Motor Company as core partners and many other OEMs and automotive suppliers have joined as premium or associate members. ARTiSAN joined as an Associate Member in 2005.

“This will give ARTiSAN early access to information regarding the results from working groups focusing on standardisation of automotive electronics including method definitions” said Thomas Scharnhorst, an AUTOSAR spokesperson. “In return AUTOSAR will benefit from ARTiSAN’s extensive experience and knowledge of systems and software modelling standards, processes and methodologies as applied to real-time and safety critical applications. We look forward to partnering with ARTiSAN in building the specifications for the next generation automotive Electric/Electronics (E/E) architectures.”

At the same time UML has gained in popularity as an extensible modelling language. Its objectives are essentially the same as those of AUTOSAR – mastering complexity and enabling reusability. The question is, can UML can be usefully employed for the purposes of implementing AUTOSAR requirements? The simple answer is yes and the key lies in its domain-specific extensibility will be the key to success.

The AUTOSAR initiative and technical concept

The AUTOSAR initiative aims to define standards on which the implementation of future automotive applications will be based and ensure that, as the electronic content of vehicles is increased, build quality and reliability remains high.. These standards are aimed at managing the growing electrical/electronic complexity involved in the development of automotive functionality. They are also intended to generate greater flexibility in terms of product maintenance, enhancements and updates. The solutions based on the AUTOSAR approach are intended to be scalable in and across product lines. In addition, it will be possible to exchange functions between OEMs and suppliers. All the domain areas involved in automotive design such as powertrain, chassis, safety, multimedia/telematics and body/comfort and the man/machine interface will be addressed.

So far AUTOSAR has addressed three main topics:

• A basic software core.
• Standardised functional interfaces.
• Methods for software integration.

As such, AUTOSAR defines a common software infrastructure based on standardised interfaces. This includes different API’s that separate the various software layers. The encapsulation of software components and their associated data types is pre-defined. In order to enable these software components to function, the software infrastructure, including basic software modules, is identified and specified. These basic software modules also have their own standardised interfaces enabling partitioning and the better use of resources while still allowing local optimisation to meet specific non-functional constraints.

The AUTOSAR software architecture consists of a layered design.

In this example, the basic software, which provides functions and services to the AUTOSAR software components, lies over the ECU-specific hardware layer. It is sub-divided into various different elements. The “services” element includes RTOS services although it should be noted that this refers to any commercially available RTOS as AUTOSAR has no intention of defining one. The “services” element also includes communications functions for all relevant vehicle buses such as FlexRay, CANbus, MOST and LIN. There is also a “microcontroller abstraction” element which interfaces to an “ECU abstraction” element. ECU-specific drivers (complex device drivers) enable the software components to directly access microcontroller-specific hardware, allowing the implementation of complex sensors or actuators with specific functional and non-functional requirements.

The overall design concept in AUTOSAR is characterised by the separation of applications from the infrastructure. An application is described through the networking and interaction of the AUTOSAR software components involved.

AUTOSAR software component (SW-C) is the most important structural element. As with UML 2.0, the AUTOSAR software components have ports to interact with the outside world. In both UML and AUTOSAR, required and provided interfaces can be modelled. However, with regard to port types, AUTOSAR goes further than UML. Data is transmitted through ports with the <> stereotype. Data is received through ports with the <> stereotype. Services are made available through <> ports which can then be used by ports with <> stereotyping.
Data exchange is always asynchronous and non-blocking in nature. To distinguish this from client-server communication, different symbols are used for the ports, enabling modellers to clearly visualise the chosen type of communication using graphical stereotyping. Unlike earlier types of representation, the ports are directly connected rather than through the interface symbols, which explains why the graphical stereotyping of ports is more important than using different interface symbols.

The size of AUTOSAR software components is not defined. <> SW-Cs containing additional SW-Cs are distinguished from components with the <> stereotype which cannot be further subdivided. As such it cannot run on several ECU’s. However, in a UML model, this can be achieved by defining a 1:1 relationship between the software component and the appropriate ECU.

AUTOSAR software components are developed independently from the available hardware or the actual infrastructure used in a vehicle. However, a full description of an SW-C must still contain its interfaces (provided or required) and any functional and non-functional framework conditions. The format and structure of the AUTOSAR Software Component Description is established in the so-called “Software Component Template”. This ensures that the final descriptions contain all the necessary information such as operations or attributes which a component will exchange with other components. This is complemented by the demands of the component infrastructure, required hardware resources and specific implementation details that need to be taken into account.

Each implementation of an AUTOSAR software component is independent of the specific ECU (or microcontroller architecture within the ECU) on which it will run. Also, the software components providing the required data or services for it, do not need to run on the same ECU. This means that it is possible to run multiple instances of the same software component in a vehicle.

In addition, there are SW-Cs with the <> stereotype which are intended for the direct use of sensors and actuators. Normally not transferable to other ECUs, these software components encapsulate the physical properties of a sensor output or actuator input, allowing vehicle functions to use specific hardware properties of ECUs. Interaction with these software components takes place without having to access the hardware directly. In the same way as the technical details of the ECU and its microcontroller(s) are hidden from the SW-C (being available as services only), these functions are available on a software component level.

Virtual Functional Bus and technical artifacts

In order to make AUTOSAR software components re-locatable, the concept of the Virtual Functional Bus (VFB) has been developed. Using software component descriptions as input, the VFB validates the interaction of all components and interfaces before software implementation. This enables the software integration to be tested much earlier in the design process than it can today.

Within the VFB, all necessary connection data between AUTOSAR software components is abstracted independently from its future location in the vehicle. So, for example, two or more AUTOSAR SW-Cs that need to communicate, can be specified even without the knowledge of the specific hardware on which they will run. This is because VFB communication services required by a software component are defined as abstractions. Their implementation will take place on the layers below the AUTOSAR run-time environment (RTE) such as operating system functions or hardware drivers.

Well-formed design patterns for communication over the VFB provide the abstract communication services. They are implemented within the various ECUs by the AUTOSAR RTE after they have been mapped to the actual hardware. Within the RTE, communication functions are implemented by basic software and its communication mechanisms.

In order to build up systems using the concepts of AUTOSAR, several artifacts have to be
described. A complete architecture requires the following:

1. A description for each AUTOSAR software component.
2. A description for each ECU available.
3. A description of system topology.

With AUTOSAR relying on existing standards, XML is used. AUTOSAR defines a pattern for the SW Cs using the Software Component Template. ECU Descriptions are used to specify the ECUs, while the System Constraint Description contains the general framework of the network architecture in the vehicle. This information in XML also allows automated and tool-supported mapping of the software components to the hardware.

Mapping of AUTOSAR to UML

To facilitate the description of all of the various AUTOSAR elements, a domain-specific AUTOSAR meta- model has been developed by the AUTOSAR Consortium. The meta-model determines the vocabulary for describing a model and is described using UML. A standardised approach for describing models and defining the modelling languages themselves exists within the Object Management Group (OMG), the industry consortium responsible for specifying UML. This is the Meta Object Facility (MOF) which serves as the meta-meta model.

UML itself is increasingly being used as the standard graphical modelling language for software-heavy systems. The key to its success lies in its generic extensible. For instance, domain-specific additions can easily be incorporated into an UML model and used along with standard elements of the UML meta-model. The OMG has defined standard extensions to UML such as those for real-time modelling through the Profile for Schedulability, Performance and Time and, for test modelling, through the UML Profile for Testing. In addition to UML, the OMG has recently standardised its systems modelling language – SysML – which is based on UML. SysML, for example, provides the ability to model requirements which is ideal for automotive projects as they tend to be heavily requirements-driven.

In keeping with the extensibility of UML through Profiles, AUTOSAR Consortium has developed and published a UML profile which includes the mapping of the AUTOSAR meta-model to UML 2.0. The profile not only defines stereotypes and property values but also rules arising from the meta-model. For instance, classes carrying the <> stereotype may not contain operations because they are only meant to be used for the transport of data. However, using UML development tools suite like ARTiSAN Studio, these rules can be linked directly to the use of stereotypes through a capability called Ergonomic Profiling. Ergonomic profiling not only makes it possible to control the appearance of model elements but also to define new diagrams based on existing UML diagrams, including all rules. These are directly linked to tool properties in the VBS ensuring that the domain-specific modeller is assisted by the profile rules while working with the tool. It will directly be notified about .

Another advantage in using UML as the basis for AUTOSAR modelling lies in the fact that plenty of practice-proven tools are already in existence. Moreover, if a modelling tool is as extensible as outlined in the UML specification, automotive electronics modellers will gain from additional synergy benefits. For example, AUTOSAR and UML can be used alongside each other to describe and simulate object behaviour in state diagrams. Modellers can define profiles, depositing and using project management information in the model. In automotive applications, the potential for using SysML is of particular interest as it can bridge the gaps that AUTOSAR has left open.