Standardized Runtime platforms and component integration AutoSAR and ARINC653

Transcription

1 Standardized Runtime platforms and component integration AutoSAR and ARINC653 Ákos Horváth András Balogh Dept. of Measurement and Information Systems Budapest University of Technology and Economics Department of Measurement and Information Systems

2 Abstract The goals of standardization can be to help with independence of single suppliers (commoditization), compatibility, interoperability, safety, repeatability, or quality. 2

3 AutoSAR o Overview o High-level design flow o s o Runtime Environment Agenda ARINC 653 3

4 History AUTomotive Open System ARchitecture Started in 2002 BMW, Bosch, Daimler, Conti, VW, + Siemens Industrial standardization group o Current standard version: 4.0 (end 2009) o Currently we use 3.1 (end 2008) Members: OEMs, Tool vendors, Semiconductor manufacturers Europedominated Scope o Modeling and implementation of automotive systems o Distributed o Real-time operating system o String interaction with HW and environment Out of scope o GUI, Java, internet connectivity, File systems, Entertainement systems, USB conncetivity etc. 4

5 Key Concepts of AutoSAR A standard runtime architecture o component-oriented o layered o extensible New functionalities New components (component implementations) o all major interfaces standardized o Standardized Run Time Environment (RTE) A standard modeling and model interchange approach o follows the principles of model-driven design o supports the interchange of designs o supports the collaborative development Between different developers, Teams, And even companies Conformance test framework o assuring the conformance to the standard o Still evolving new in version 4.0 5

6 High-level design flow 6

7 High-level design process High-level SW modeling Model (VFB) High-level software modeling Definition of components component ports port interfaces data types logical Result VFB-level software model

8 High-level design process High-level SW modeling Detailed Design Internal Behavior Model (VFB) Detailed component design Specification of component internal behavior functional breakdown implementation/use of ports Non-AutoSAR specification of detailed behavior any tool can be used UML Simulink etc. Result AutoSAR component internal behavior model Non-AR: behavioral models/design

9 High-level SW modeling Detailed Design High-level design process Internal Behavior Model (VFB) ECU resource model High-level HW modeling High-level hardware modeling Specification of ECU resources CPU memories peripherals communication hw system topology ECU instances clusters connections Result ECU resource model for all ECUs System topology model

10 High-level SW modeling Detailed Design High-level design process Internal Behavior Model (VFB) HW/SW integration component allocation communication mapping configuration scheduling System model ECU resource model High-level HW modeling Hardware-software integration mapping software component allocation component implementation selection data-element to signal mapping inter-ecu communication communication configuration signal to PDU mapping PDU to frame mapping Signal, PDU, Frame triggering Cluster and controller configuration Frame scheduling (LIN, FlexRay) Result System model describing the integrated HW/SW system

11 High-level SW modeling Detailed Design High-level design process Internal Behavior Model (VFB) HW/SW integration component allocation communication mapping configuration scheduling ECU resource model High-level HW modeling implementation Impl. files Impl. Impl. files files System model implementation Implemeting all components automatically TargetLink Simulink Realtime workbench SCADE etc. manually Result implementation of the components C/C++/

12 High-level SW modeling Detailed Design High-level design process Model (VFB) HW/SW integration ECU configuration component allocation Internal Configuring all basic software modules communication based Behavior on the system model mapping for each ECU separately configuration Result scheduling ECU configuration model implementation System model ECU resource model ECU configuration High-level HW modeling Configuration model Impl. files Impl. Impl. files files

13 High-level SW modeling Detailed Design High-level design process Internal Behavior Model (VFB) HW/SW integration component allocation communication mapping configuration scheduling ECU resource model High-level HW modeling implementation Impl. files Impl. Impl. files files System model BSW configuration generation Configuration generation for basic software from the configuration model Result Configuration files (c,h) Generated modules/module fragments ECU configuration BSW config files Configuration model Code generation

14 High-level SW modeling Detailed Design High-level design process Model (VFB) HW/SW integration Compilation and linking component allocation Internal Building and linking all sources communication application Behavior component implementations mapping basic software modules configuration BSW configuration files scheduling Result Deployable binary file implementation System model ECU resource model ECU configuration High-level HW modeling Configuration model Impl. files Impl. Impl. files files Compiling Linking BSW config files Code generation Binary

15 Models in the design flow Software Template o s, ports, interfaces o Internal behavior o Implementation (files, resource consumption, run time, etc.) ECU Resource Template o Hardware components, interconnections System Template o System topology, HW/SW mapping o Comm. matrix

16 Models in the design flow 2 Basic Software Module Template o BSW modules Services Schedulable entities Resource consumption ECU Configuration Parameter Definition Template o Configurable paramters of BSW modules ECU Configuration Description Template o Actual configurations of BSW modules o Based on the ECU Parameter Definition

17 AutoSAR vs. UML/SysML/... modeling AutoSAR defines models with o Domain Specific Constructs o Precise syntax o Synthesizable constructs Direct model -> transformations Direct model -> detailed model mappings o Different abstraction levels From Virtual Function Bus to configuration Result o Models are primary design and implementation artifacts More precise, consistent modeling should be done

18 AutoSAR s 18

19 -oriented design What is a component? o A component is a self contained, reusable entity that encapsulates a specific functionality (and/or data), and communicates with other components via explicitly defined interfaces. AutoSAR uses the term component for application-level components o Elements related to the high-level functionality of the system under design Basic software (middleware) components are called modules. o Standard elements of the AutoSAR architecture

20 -based approach <<interface>> SenderReceiver1 dataelement1 dataelement2 Encapsulates a specific functionality Different kinds Composite component hierarchical refinement Application SW component generic, high level functionality Sensor/actuator SW-C handling sensor or actuator data ECU HW abstraction higher level device driver and abstraction ComplexDeviceDriver time-critical, low-level driver Calibration parameter SWC collects system calibration parameters Service SWC represents a basic software module from the service layer

21 -based approach Ports The only interaction points between the component and its environment Are implementing port interfaces sender receiver (message-based unidirectional communication) client-server (remote procedure call) <<interface>> SenderReceiver1 dataelement1 dataelement2

22 -based approach port notation Receiver port Sender port Server port Client port Service port To Basic Software (BSW) Module services Inverted image

23 interconnection the Virtual Functional Bus A B C X Virtual Functional Bus Virtual Functional Bus (VFB) Abstract interconnection layer Implementation of data/control transport between components No hardware/network dependency Hides the details of the implementation Allows high-level integration and simulation of components Before hardware architecture is chosen....

24 Software s On high-level, atomic components are black boxes Detailed design looks into these black boxes Main goals o Detail the behavior to get schedulable entities o Specify the semantics of port handling o Specify any service needs o Specify any RAM, nvram needs

25 Refinement of a component Black box definition of a component Definition of component internal behavior Schedulable entities, connections to the ports Comp.c Comp.h implementation. Specification of source and header files

26 internal behavior Specification of the internals of an atomic SWC Schedulable elements o Called: runnable entities Connection of ports o Port semantics o Port API options Inter-runnable communication Runnable activation and events

27 internal behavior runnable entities Smallest code-fragments considered by RTE Subject to scheduling by the OS Abstraction of a schedulable function Communicates o Using the SWC ports o Using inter-runnable communication facilities Is activated by o An RTE event Communication-related event Timing event

28 Run Time Environment 28

29 AutoSAR Runtime Architecture Software architecture of a single ECU Layered approach o Application software o Runtime Environment (RTE) Implementation of the VFB o Basic software modules Platform services Device drivers Operating system Standardized

30 AutoSAR Architecture layered view Application Layer AUTOSAR Runtime Environment (RTE) Services Layer ECU Abstraction Layer Complex Drivers Microcontroller Abstraction Layer Microcontroller

31 AutoSAR Architecture layered view Application Layer AUTOSAR Runtime Environment (RTE) Microcontroller Abstraction Layer Low-level peripheral drivers Services Layer Memory devices Communication controllers Internal uc peripheral units (ADC, GPIO, PWM) ECU Abstraction Layer Complex Drivers Microcontroller Abstraction Layer Microcontroller

32 AutoSAR Architecture layered view ECU Application Abstraction Layer Uniformization of device access Memory devices Communication controllers Onboard devices AUTOSAR (watchdog, Runtime etc.) Environment (RTE) ECU specific hardware abstraction I/O abstraction software components Services Layer ECU Abstraction Layer Complex Drivers Microcontroller Abstraction Layer Microcontroller

33 AutoSAR Architecture layered view Application Layer AUTOSAR Runtime Environment Complex drivers (RTE) Custom, low level hardware manipulation Time critical components Services Layer ECU Abstraction Layer Complex Drivers Microcontroller Abstraction Layer Microcontroller

34 AutoSAR Architecture layered view Application Layer AUTOSAR Runtime Environment (RTE) Services Layer ECU Abstraction Layer Complex Drivers Microcontroller Services layer Abstraction Layer System services RTOS Diagnostic event handling Microcontroller ECU and COM state management Non-volatile memory Communication controllers Onboard devices (watchdog, etc.) Communication services PDU router, transport protocols, network management, COM, DCM

35 AutoSAR Architecture layered view Application Layer AUTOSAR Runtime Environment (RTE) Services Layer RTE Provides interconnection between ECU components Abstraction and Layer BSW orchestrates component execution manages communication manages application modes Implements the VFB Microcontroller Abstraction Layer Complex Drivers Microcontroller

36 AutoSAR Runtime Architecture AUTOSAR Software Application Software AUTOSAR Interface Actuator Software AUTOSAR Interface Sensor Software AUTOSAR Interface AUTOSAR Software... Application Software AUTOSAR Interface Interface AUTOSAR Runtime Environment (RTE) Standard Software API 2 VFB & RTE relevant API 1 RTE relevant API 0 API 3 Private Interfaces inside Basic Software possible Standardized Interface Operating System Standardized Interface Standardized AUTOSAR Interface Services Standardized Interface Standardized Interface Communication Standardized Interface Basic Software AUTOSAR Interface ECU Abstraction Standardized Interface Standardized Interface Microcontroller Abstraction AUTOSAR Interface Complex Device Drivers ECU-Hardware

37 The overall mapping process 1. step Overall System specification o Selection of implementations for the components Implicitly includes the selection of internal behavior o Selection of ECUs for the components Allocation o Mapping of data elements/operation parameters to signals For inter-ecu communication o Communication configuration Signal Isignal PDU Frame mapping Cluster and comm. Controller configuration o Result: configured system ECU Extract: a slice of the model representing elements required for a single ECU

38 The overall mapping process 2. step Single ECU configuration o Input ECU extract internal behavior Communication matrix (of the ECU) o OS Configuration Runnables needs to be mapped to tasks Basic tasks» Finite execution time Extended tasks» Can run forever (blocking calls required) o Events to notification mapping 38

39 Summary AutoSAR defines o A component-oriented system design approach Domain specific modeling language A high level design process Standard middleware (basic software) stack Standard interfaces Standard configuration descriptors AutoSAR compliant ECU software o Includes several BSW and application components o RTE provides the integration (glue) between these o Configuration and glue code is mostly auto-generated

40 AutoSAR o Overview o High-level design flow o s o Runtime Environment Agenda ARINC

41 ARINC 653 Overview ARINC Avionics Application Standard Software Interface) is a software specification for space and time partitioning in Safety-critical avionics Real-time operating systems. ARINC 653 is a specification for an application executive used for integrating avionics systems on modern aircraft It is an API of 51 routines (ARINC 653 APEX APplication Executive): time and space (memory) partitioning, health monitoring (error detection and reporting), communications via ports ARINC 653 OS and applications are typically certified per DO-178B; o different partitions can be certified to different DO-178B levels running on the same CPU 41

42 ARINC 653 Structure Part 1: Definition of Required Services o Health management o Time and space partitioning o Suplement 3: corrected XML schema definition based on Boeing 787 issues (2010 Oct 6) Part 2: Extended Services o File system, logbook, service access points Part 3: Conformity Test Specification Part 4: Embedded profiles for small embedded systems under definition 42

43 Architecture Complete time and space partitioning o Integration of SW of Multiple Criticalities Portability o Abstract away underlying HW and RTOS Reusability o Resuse components Modularity o Removes HW and SW dependencies 43

44 ARINC 653 Key s Partitoning and scheduling Communications Health Monitoring 44

45 Partitions Completely deterministic time scheduling Fix cyclic scheduling Scheduling is a negotation process between o System integrator and App developers Health Monitor check for any temporal violations (jitter, deadlines) 45

46 Processes Runs inside a partition time jumps when partition is activated do not know about anything else Types o Periodic o Aperiodic Hard deadline o Remedial action if deadline are missed Soft deadline o Records failure and continues Health Monitor defines all actions if a deadline is missed 46

47 Communications Inter Partition Communication o Port channel- port o One-to-one, or one-to-n o Queuing ports Stored messages variable length FIFO or priority o Sampling ports Overwrites previous messages Fixed length Time stamped (validity time) Streaming like data is not supported 47

48 Communications Intra Partition Communication o Buffers FIFO o Blackboards Message is overwritten by teh next message (or clear if required) Processes can queue for a message reads lates version data on blackboard o Semaphore counting o Events For notification of condition occurance 48

49 Health Monitoring Defines the actions when an error occurs o Deadline missed, numeric error, illegal request, power fail, memory violation, etc. Precisely defines roles 1. Process HM error handler process Optional 2. Partition HM Memory and context belongs to Module OS but scheduled in Partition window 3. Module HM Not part of any partition higher priority than any partition Severe error if it is activated Multi role definition o o System integrator Application provider 49

50 Summary IMA systems are very complex o 10+ applications o 2M lines of code, 50k configuration element ARINC 653 o became the De facto avionics RTOS standard o Fits into the DO-297 concept Strong partitioning Incremental certification o Decreases the cost of change Field proven technology o Airbus 380 o Boeing 787 o Airbus 400m 50