AUTOSAR design flow. Yoon-Jin Kim Application Engineer. July mentor.com/automotive

Transcription

1 AUTOSAR design flow Yoon-Jin Kim Application Engineer July 2016 mentor.com/automotive Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Qt is a registered trade mark of Digia Plc and/or its subsidiaries. All other trademarks mentioned in this document are trademarks of their respective owners.

2 AUTOSAR AUTOSAR(AUTomotive Open System ARchitecture) Standard for automotive E/E architecture organization established in June 2003 BMW, Bosch, Continental, DaimlerChrysler, Volkswagen, etc. Total 191 worldwide AUTOSAR members are cooperate Initial stage in the domestic Lack of AUTOSAR SW Developers Building phase of Market < Core Partners of AUTOSAR > < Transition of AUTOSAR Partners > 2

3 Adaption of AUTOSAR Growing E/E complexity of software(e.g. ADAS, Infotainment, Autonomous car, Safety) Analog to Digital System Rising of mounted ECU in-vehicle and SW code lines Decreasing of hardware spaces Increasing of in-vehicle interface for communication < Growing E/E complexity due to demand for functionalities on vehicle > < Rising of mounted ECU and interface per each car > 3

4 Adaption of AUTOSAR Advantage Increase of reusing SW Improvement of safety Cost reduction for testing and certifying Reduce architecture design analysis Decrease of design errors Enable good communication between OEMs and Suppliers Weakness Massive specification Long time of design process

5 AUTOSAR Principle Goals Independence of SW and HW Modularity Modularization of SW application Transferability of functions Providing standardized interfaces Re-usability Assigned functions to ECU Maintainability Application RTE BSW SW Application Microcontroller Past & Now MCAL Microcontroller Now & In progress HW 5

6 6 AUTOSAR Development Methodology

7 AUTOSAR Development Process OEM Architects, System Network Design OEM ECU Supplier SW architecture definition Configuration of Memory, RTE, RTOS, DIAG, CAN, LIN HW architecture definition IOHW & Services generation SW to HW arch. mapping UTM - Upstream Template Mapper Network design CAN LIN FR, Eth RTE Contract Phase ECU Extract Additional SWCs, Internal behaviour Configuration generators BSW Integration Compiler - Linker ECU Application SW Design SW Validation 7

8 AUTOSAR Workflow (simplified) Software Architecture Design Software components design Communication of components (VFB) Datatypes, Interfaces, etc.. System Design System topology - ECUs and Buses Communication matrix - Signals, PDUs, Frames, Routing, Timings, Nm., etc.. Software and System Mapping SWC and ECU mapping Implementation based on RTE level Dataelement and signal mapping Application Software Development SW-C behavior design BSW service needs definition Implement applications based on runnable ECU Configuration BSW modules design Service, ECU Abstraction configuration Configure MCAL modules Generate source code 8

9 Software Architecture Design - Dashboards Main Dashboard SWC design Dashboard 9

10 Software Architecture Design - Datatypes With AR4.0 the datatypes concept has been totally reworked Three level of datatypes have been defined Application Datatypes Implementation Datatypes Base Datatypes These can be created in a tabular datatype editor Application Datatypes VFB Level DataType Mapping Implementation Datatypes RTE Level Base Datatypes 10

11 Software Architecture Design - Interfaces Sender-Receiver Interface Transfer of Data element of a certain Data type(e.g. Uint8) 1..m Multiplicity n..1 Multiplicity Data Elements are Variables Client-Server Interface Transfer of Arguments to/from an Operation n..1 Multiplicity Arguments are Variables inout Sender/Receiver Interfaces Client/Server Interfaces 11

12 Software Architecture Design - SWC Design A SWC is the smallest software-unit, which can be mapped to an ECU SWC 1 ECU 1 SWC 1 SWCs can be connected via assembly connections Ports defines the need for communication interfaces and datatypes define the content of the communication Ports can be connected via assembly connectors SWC 1 Assembly Connection SWC2 ECU 1 SWC 1 ECU 2 SWC 2 12

13 Software Architecture Design - Internal Behavior The SWC Behavior describes the SWC-internal Runnable Entity RTE Events SWC Behaviors are assigned to SWCs (each SWC at least one) RTOS SWC 1 Task A Priority 1 Task B Priority 2 <Runnable 2> <interface 3> <data_element 3> <interface 1> <data_element 1> <variable> <data type> <interface 2> <data_element 2> <Runnable 1> <interface 4> <data_element 4> 13

14 Software Architecture Design - Runnable Runnable The smallest code-fragment that are provided by components An SWC consists of at least a Runnable Runnables are activated by RTE Events Mapped to OS Task i.e. subject for scheduling by the underlying OS 14

15 Software Architecture Design - RTE Events RTE Events trigger (activate) Runnables Events differ in their triggering conditions (e.g.) TimingEvent DataReceivedEvent OperationInvokedEvent 15

16 Software Architecture Design - Composition SWC CSWCs can be instanciated within a CSWC SWCs can be grouped through CSWCs CSWCs communicate via Client/Serveror Sender/Receiver-Ports Delegation Connector Assembly Connector SWC 1 SWC 2 CSWC 1 SWC 3 SWC 4 Pass-Through Connector CSWC 2 SWC 5 Ports of related interfaces can be autoconnected using the AutoConnect Wizzard 16

17 System Design - Dashboards System Dashboard 17

18 System Design - System Topology VSA Graphical Topology Editor 18

19 System Design - Frame packing Communication Matrix design Network database Signal to PDU PDU to Frame Frame Packing Manual Automatic Semi-Automatic Signal to Frame packer Graphical PDU layout Communication Matrix 19

20 System Design - SWC to ECU Mapping SWC-to-ECU mapping effects Intra-/Inter ECU communication ECU memory usage CPU load Communication matrix design Additional ECU SW configuration 20

21 System Design - ECU Extract of System Description 1 Extracts information for one (selected) ECU SWCs, compositions, ports, interfaces Communication-Matrix related information The ECU extract is needed as input for the BSW configuration tool (e.g. VSB)

22 System Design - ECU Extract Tier 1 Data OEM A OEM B OEM C Extract A OEM C Extract B Content ECU ARXML ECU ARXML COM/SYS ARXML SW ARXML Data types Platform Platform Platform Per ECU Interfaces Per ECU Per ECU Platform Per ECU SWCs Per ECU Per ECU - Per ECU Behavior - Per ECU - Per ECU System - - Platform - Signals / Frames Per ECU Per ECU Platform - OEM A/B Data flow Signals System COM Arxml Interfaces SWC Behavior Signals System Frames ECU Frames Interfaces SWC SWC Arxml ECU Behavior OEM A/B TIER1 OEM C TIER1 22

23 Application Design - RTE Contract Phase Is used as interface specification for SW developers Is used by the SW Developer to implement his specific applications and algorithms As input when a complete description of one or multiple SW components are needed SWC incl. Ports, Interfaces SWC Behavior Implementation SW Component Description SWC API Generator Component API (app.h, app.c) Results One header file (*.h) with the RTE-API macros (the interface specification) Depending on the tool vendor a C-Skeleton framework (*.c files) 23

24 Application Design - Model Base Step 1 Skeleton Simulink Model arxml *.h *.c import SW-C Simulink Data Objects VSA Step 2 design internal behavior Step 3 validate model c, h arxml merge SW-C back Step 5 Completed Simulink Model Step 4 generate code 24

25 ECU Configuration - Dashboards ECU Configuration Dashboard 25

26 ECU Configuration - Build When the ECU configuration is complete, configuration generators can be executed Configuration generators convert ECU configuration into C- code (configuration data) Compiler and linker used to bring generated c-code and VSTAR BSW libraries together with application SW ECUCFG.arxml Configuration generators C, C, H H files (config data for BSW modules) Application SW VSTAR Libraries c, h Compiler/Linker Binary image 26

27 Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Qt is a registered trade mark of Digia Plc and/or its subsidiaries. All other trademarks mentioned in this document are trademarks of their respective owners. mentor.com/automotive