PAGE 6 PSA To optimize cooperation with the electronic control unit suppliers, PSA decided to make the development process for drivetrain ECUs AUTOSARcompliant. To do this efficiently, PSA set up a tool chain that seamlessly supports elementary process steps from creating the architecture to actual implementation. Several AUTOSAR-compliant production projects have since been successfully completed. PAGE 7 AUTOSAR Implemented AUTOSAR-compliant production software development with TargetLink and SystemDesk PAGE 8 PSA The software in PSA engine ECUs supports functions for combustion engines, hybrid controllers and transmission applications. Established Model-Based Tool Chain Based on TargetLink/ Simulink TargetLink®, dSPACE’s production code generator, has been used at PSA for production software development in the drivetrain area since 2007 – for combustion engines, hybrid controllers, and transmission applications. process and higher software quality. The advent of the AUTOSAR standard gave PSA the opportunity to simplify cooperation with suppliers by putting it on a new, AUTOSAR-compliant basis. This was the main motivation for extending the tool chain to support AUTOSAR-compliant development and for using standardized 1. Simulink/TargetLink Models Requirements are described in the form of models that PSA develops internally and then passes to another team for software implementation. In this case the model serves as an executable specification of the algorithmic behavior, which is then converted into software by adding software properties with TargetLink. 2. Textual Requirements Requirements can also be specified in classic text form, for example, in IBM® Rational® DOORS®. In this case the implementation specialists perform the actual function/ algorithm development with TargetLink and also the software implementation from the models that they create. AUTOSAR-Compliant Development Process The architecture of the ECUs’ application software is described with SystemDesk in compliance with AUTOSAR. Currently at PSA, the software architecture for engine ECUs consists of 70 AUTOSAR application “We have been using TargetLink since 2007 to develop software for engine management systems with a model-based design approach. This tool provides efficiency in our development process and offers features that we need to produce AUTOSAR-compliant code.” Nabile Khoury, PSA The reasons for using automatic production code generation were classic factors such as time to market, the need to handle the increasing complexity of automotive software, and the fact that other departments deliver models as executable specifications within PSA, where an implementation team turns them into production software. Inhouse benchmark tests with the first version of TargetLink to be used, 2.2.1, confirmed the expected benefits: an accelerated development AUTOSAR-XML (ARXML) exchange formats instead of proprietary formats. Other tools were used for this in addition to the TargetLink AUTOSAR Module, particularly the system architecture tool dSPACE SystemDesk®. From Requirement to Implementation Software requirements are the starting point and the basis for development. They can be included in the workflow in one of two defined ways, depending on the project. components with approx. 3000 interfaces and 300 runnables. All the AUTOSAR specifications, including the parts needed to generate a run-time environment (RTE), are completely available in SystemDesk. Either this data is created manually in SystemDesk, or existing interfaces or runnable specifications are imported from the Visu-IT! Automotive Data Dictionary (ADD) or from existing models. To develop the functions of a software component, first its AUTOSAR PAGE 9 properties are exported from SystemDesk (AUTOSAR ARXML files) and transferred to the TargetLink Data Dictionary. The TargetLink user generates an AUTOSAR frame model from them and inserts the algorithmic functionality under development into the frame model (this is the top-down approach). Currently, AUTOSAR standard version 3.1.2 is being used, and all PSA components are implemented with TargetLink. Model Design and Automatic Code Generation TargetLink models for implementing individual AUTOSAR software components are designed according to the following rules: The models must be compatible with the software architecture in SystemDesk. Compliance with this rule is practically automatic with the AUTOSAR-compliant workflow and AUTOSAR frame model generation. The models must implement the software requirements. For functional requirements, this rule is generally satisfied if the specifications are supplied as models. Such models just have to be converted from Simulink® to TargetLink if necessary. If the requirements are in text form, the model is validated against them by offline simulations and other methods. The individual TargetLink models for implementing the functionality of individual components can vary greatly in size, with the largest SWC models containing up to 6000 computation blocks. For the actual control design, a proprietary PSA library is used in addition to TargetLink blocks. The library contains functionalities such as counters and filters, and TargetLink’s scaling invariance features are also partly used. To ensure high model quality, modeling guidelines from the following bodies are applied: MathWorks®, dSPACE, and PSA. Either floating-point or fixed-point code is generated depending on the project, and also on the complexity and required precision. The software for PSA engine ECUs is developed with TargetLink and SystemDesk. Test Activities for Components and Integrations Because PSA bears complete responsibility for its own software, the individual software components are tested in TargetLink software-in-theloop (SIL) and processor-in-the-loop (PIL) simulations, supported by BTC EmbeddedTester®: PAGE 10 PSA “SystemDesk helps us to efficiently design the software architecture of our engine management systems with AUTOSAR constraints. Its integrated environment also enables us to verify that our applications can be integrated in AUTOSAR platforms.” Zhao Zuo, PSA Automatic test vector generation and back-to-back testing with BTC EmbeddedTester MIL/SIL/PIL simulation results are compared automatically with the help of automatic test vector generation by the Embedded Tester and so-called back-to-back tests. This is particularly helpful in the case of supplied controller models, in order to validate automatically that the controller model and the software implementation with TargetLink have sufficiently similar behaviors. Modified condition/decision coverage (MC/DC) measurements are also performed to verify that a satisfactory code coverage is achieved. PIL tests for profiling the required ECU resources With the help of TargetLink PIL simulation, a resource profile is created in order to estimate the memory (RAM/ROM/stack) that will be consumed at run time. Functional tests with other data Other test cases are developed manually on the basis of functional requirements or taken from recorded vehicle data. These tests are executed with Embedded Tester and an in-house test tool. PSA not only tests components but also performs software integrations for test purposes. An RTE for the ECU’s entire software architecture is generated from within SystemDesk and temporarily integrated with the TargetLink components (this is called pre-integration). This step ensures that no problems occur when the actual integration is performed later by the supplier. The Roles of OEM and Suppliers The division of tasks and exchange of artifacts between PSA and suppliers looks like this: PSA is responsible for the ECU’s software architecture and passes AUTOSAR workflow with SystemDesk and TargetLink. Architecture definition with SystemDesk SWC architecture model (Simulink) Composition of ECU application SW Internal behavior RTE Application interfaces ECU ARXML Application internal data ASWC sources ADD database ASWC A2L file Simulink model Code generation with TargetLink ADD: Automotive Data Dictionary ARXML: AUTOSAR architecture definition file ASWC: AUTOSAR software component A2L: ECU software description file RTE: Run-time environment SWC: Software component PAGE 11 it to the supplier as AUTOSAR ARXML specifications. PSA provides the major part of the application software for the ECUs and also thoroughly tests the individual software components as described above. Some of the software components are outsourced to external developers (“software as a product”) and made directly available to PSA. For IP protection, the generated source code is intentionally made unreadable by a code obfuscator. It is therefore not necessary to exchange object code, and the ECU suppliers are free to choose their own compilers and compiler options. The ECU supplier also contributes small parts of the application software and uses RTE generation to integrate them and the components supplied by PSA on the ECU together with the basic software, after which the ECU is delivered to PSA. PSA block library for recurring functionalities such as filters and counters. Experience with Using the dSPACE AUTOSAR Tool Chain Since starting to use the TargetLink/ SystemDesk combination, PSA has successfully developed software for 10 engine ECUs, 1 transmission ECU, and 2 hybrid ECUs, and brought it up to production level. The proportion of the application software produced by PSA varies between 60% and 95%. The entire software is developed with TargetLink and SystemDesk, in other words, modelbased design and autocoding are the established methods. For example, for an engine ECU, PSA produces approx. 1 megabyte of code, created by approx. 50 developers. A special focus of current projects is to implement the requirements resulting from the Euro 6.2 standard. This is being done with TargetLink 3.2 and SystemDesk 3.1, based on AUTOSAR Version 3.1.2. Conclusion and Outlook The AUTOSAR-compliant tool chain with SystemDesk and TargetLink has proved successful in several production projects. SystemDesk supports the convenient, efficient design of extensive software architectures. Two of TargetLink’s indispensable strengths are its strong focus on software implementation tasks and its good integration with MATLAB®/Simulink® and EmbeddedTester. With the tool’s high usability, the efficient and well-documented automation APIs, and the PSA-specific extensions, even new users can very quickly start working productively. In the future, PSA plans to migrate to AUTOSAR 4 with TargetLink 3.5 and SystemDesk 4.1. Nabile Khoury, Zhao Zuo, PSA Peugeot Citroën Summary French carmaker PSA Peugeot Citroën develops the software for drivetrain ECUs of all their model series in compliance with AUTOSAR. The company creates most of the application software itself, using a tool chain that consists of the architecture software SystemDesk, the model-based development environment MATLAB/ Simulink, and the production code generator TargetLink. The functions that are developed are first implemented on an ECU and thoroughly tested by PSA. Then the ECU supplier integrates the tested PSA software components, parts of the application software that they have developed themselves, and the basic software on the production ECU. The efficiency of the development process is ensured by standardized exchange formats, clearly structured components, and the seamless tool chain. Nabile Khoury Nabile Khoury is Model-BasedDesign Specialist at PSA Peugeot Citroën in La GarenneColombes, France. Zhao Zuo Zhao Zuo is AUTOSAR Software Architect at PSA Peugeot Citroën in La Garenne-Colombes, France.
© Copyright 2018 ExploreDoc