Today’s state-of-the-art automobiles have become increasingly complex systems comprised of integrated hardware and software components. Many of these embedded systems incorporate engineering control unit (ECU) technology.
Before these cars can be brought to market, auto manufacturers and top-tier suppliers look to leverage AUTOSAR-compliant (Automotive Open System Architecture) technology to enhance the quality and efficiency of automotive design. A recent survey of 150 German AUTOSAR experts found that more than 55% of all electric/electronic (E/E) development projects will be based on AUTOSAR technology within the next five years.
Due to the growing complexity of these E/E systems, manufacturers and suppliers look to identify software-development tool vendors that can provide the capabilities to develop AUTOSAR-compliant solutions. The end result will be shortened product and design lifecycles and a simplified software-development process.
Such processes must incorporate well-established engineering best practices, such as model-driven systems engineering (MDSE) on top of the AUTOSAR artifacts. Integrating early lifecycle tools, which span from early system conceptualization to generation of the specific ECU extracts, will help satisfy the end-to-end traceability requirements between the E/E system and ECU-specific views.
AUTOSAR defines the complete in-vehicle E/E system. It significantly simplifies the overall integration of E/E artifacts from different functional domains, such as hardware, software and in-vehicle-communication.
For example, developers can realize the benefits afforded by IBM Rational Rhapsody AUTOSAR for E/E and ECU software development thanks to ECU basic software (BSW) tools and runtime environment (RTE) tresos Studio from Elektrobit. Such integration adds value to system engineering, model-driven development, requirements analysis, change management, and quality and workflow management.
These capabilities are provided through the Rational software platform for automotive systems, enabling developers to connect ECU RTE and BSW configurations to system requirements and application models. As a result, development teams can avoid costly manual linkages for demonstrating traceability.
It’s possible to leverage integrations to software change, software configuration, and asset and quality management. The result is repeatable, automated, and documented workflows, as well as improved collaboration among teams. The value for AUTOSAR developers is early error detection via AUTOSAR simulation, which avoids costly re-designs in downstream development phases.
More About AUTOSAR
To achieve the technical goals of modularity, scalability, transferability, and reusability of discrete functions, AUTOSAR provides a common software infrastructure for automotive systems of all vehicle domains, based on standardized interfaces for different layers (Fig. 1).
Layering design not only decouples the design of the various layers, but also the development software for those layers. Decoupling development enables parallel development, but it introduces risks in the integration phase. The AUTOSAR standard helps minimize those risks.
Model-Driven Systems Engineering
As previously stated, MDSE is a key component to a successful AUTOSAR project. MDSE presents a structured approach that supports requirements analysis, architecture definition, specifications of system functionality, interfaces, and behavior.
MDSE is based on Systems Modeling Language (SysML), which incorporates graphical diagrams to highlight important portions of the system under design. This allows developers to manage traceability between any given system artifact while avoiding costly and time-consuming manual traceability. By combining the MDSE artifacts with the AUTOSAR artifacts in the same environment, developers can establish full and dynamic traceability across the entire development process.
Case Study: Leveraging AUTOSAR to Manage Growing E/E Complexity
Elektrobit, a leading developer of AUTOSAR runtime and integration tools, has partnered with IBM Rational to offer engineers an integrated development environment (IDE) spanning across all building blocks of AUTOSAR-compliant ECU design and development. The combined solution gives developers a pre-tested, turnkey development environment for AUTOSAR-based E/E and ECU software.
IBM provides requirements management and design tools tailored to the AUTOSAR specification. Elektrobit tresos supplies the run-time environment on which Rhapsody-developed applications will be executed. The integrated solution allows for early verification and testing of applications even before integrating them onto the ECU. IBM has tested and verified this integration to guarantee interoperability that leverages the ARXML data interchange format.
Looking at IBM’s Rhapsody more closely, it enables teams to share information in real time. Users can link AUTOSAR-compliant and other models to requirements and quality-management test cases, extending potential collaboration capabilities. Further integration with automotive standards, such as ISO 26262 for functional safety, thus becomes possible. In addition, Rhapsody complies with the Capability Maturity Model Integration (CMMI) and Automotive SPICE standards. It includes data management of E/E artifacts with configuration and change management, work item and build management, integrated project planning, project management, and reporting.
The close integration also supports reuse across engineering teams. This is a key factor because AUTOSAR development incorporates a wide range of disciplines, requiring teams to be embedded in the broader E/E engineering lifecycle. On top of that, traceability can be achieved between an AUTOSAR receiverPort (RPort, with Sender/Receiver Interface) to an object in the system architecture such as “Brake Management Subsystem IBM.”
As mentioned earlier, tresos Studio generates AUTOSAR-compliant BSW and RTE that implement the ECU software stack. The tooling available with EB tresos Studio helps to configure the AUTOSAR BSW and provide the RTE required by the application software allocated to the specified ECU, as defined by the ECU extract (Fig. 2).
Early, Continuous Integrations
Referring back to Figure 1, layering decouples and standardizes proprietary interfaces, but it presents developers with a myriad of integration issues. More integration touch points translate to greater time-to-market risks, unless there’s proactive pre-testing of integrations and pre-verification of configuration layers.
A decoupled architecture of run time also enables systems engineering practices, such as model-based systems engineering specification and testing verification, to be enacted upstream. Therefore, the key to harnessing the architecture’s strengths depends on seamless best-of-breed tool chains that tightly align with best-in-industry run-time environments.
Early and continuous integrations are important software-engineering practices that should be implemented to reduce integration risks. With a combination of Rhapsody and EB tresos Studio, developers are able to start testing their integrated and pre-verified E/E and ECU software from day one, and incrementally add functionality while continuously testing the incremental code.
By using various flavors of run-time implementations like the Microsoft Windows-based EB tresos WinCore, developers can also avoid hardware dependencies. This will yield more accurate delivery schedules and time-to-market benefits while keeping a constant check on quality.