autosar

Semantic of executionin AUTOSARPascal GULA,C.E.O / pulse-AR

Explosion of Electronic Content in CarsInnovation through EE functionsMotivation (1/2)Electronic InjectionCheck ControlCruise ControlCentral Locking...Gearbox controlClimate controlASC Anti Slip ControlABS Anti Blocking Sys.Telephoneseat heating controlAutom. Mirror deflectionNavigation systemCD-ChangerACC Active CruiseControlAirbagsDSC DynamicStability ControlRoll stabilizationXenon LightDriver assistanceRDS/TMCVoice inputEmergency callACC Stop&GoBFDALCKSG42-VoltInternet PortalGPRS, UMTSTelematicsOnline ServicesBlue-ToothCar OfficeLocal Hazard WarningIntegrated Safety SystemBy-Wire-systemsI-DriveLane keepingPersonalizationSW Update...1970 Interconnection level2009

Motivation (2/2)Needs that lead to AUTOSAR definitionIncreasing complexity of E/E systems• Increasing number and complexity of functions / ECU• Complex interaction between functions (networking)Increasing safety and reliability needsThe design of a vehicle becomes the design• Critical functions (ABS/ESP, power steering, …)of • a Conformance complete issues system and does not consist• Real-time issuessolely with the assembly of functionsNeeds for rationalization of OEMs / Tier-1 exchanges• Complex specification• Low level of flexibility• Increasing complexity of integration

Objectives (1/2)‣ Implementation and standardizationof basic system functions as an OEMwide “Standard Core“ solution‣ Maintainability throughout thewhole “Product Life Cycle“‣ Scalability to different vehicleand platform variants‣ Transferability offunctions throughoutnetwork‣ Integration offunctional modulesfrommultiple suppliersApplicationInterfacesArchitectureMethodology‣ Increased use of “Commercial offthe shelf hardware“‣ Software updates andupgrades over vehiclelifetime‣ Consideration ofavailability and safetyrequirements‣ Redundancy activation

Objectives (2/2)Conventional, by nowSoftwareHardwareAUTOSARApplication SoftwareAUTOSARHardwarestandardizedHW-specific Hardware- and software will be widely independent of each other. Development processes will be simplified.This reduces development time and costs. Reuse of software increases at OEM as well as at suppliers.This enhances also quality and efficiency.Automotive Software will become a product.

Technical FeaturesMethodologyNewconceptsInputTemplatesExchangeFormatsMeta ModelVirtual FunctionBus (VFB)RunTimeEnvironmentConfigurationConceptErrorHandlingMemoryServicesModeManagementNetworkManagementComm.ServicesIndustry-wideconsolidation of‚existing‘ basicsoftware designsOS KernelμControllerAbstractionDiagnosticsECUAbstractionDriversGatewayComplexDriversBus systems

Organization9 Core Partners 6 DevelopmentMembers52 Premium Members67 Associate MembersGeneralOEMGenericTier 1StandardSoftwareTools andServicesSemiconductors

Software ArchitectureOverviewSW-Component1AUTOSARInterfaceSW-Component2AUTOSARInterface....................AUTOSAR RTESW-ComponentnAUTOSARInterfaceAutomotive Open SystemArchitecture (AUTOSAR):• Standardized, openly disclosedinterfaces• HW independent SW layer• Transferability of functions• Redundancy activationBasic Software• Transfer layers for different communication technologies (e.g. CAN, LIN, …)• Network management• System services (diagnostic protocols, …)• NVRAM management• …Microcontroller AbstractionAUTOSAR RTE:by specifying interfaces and theircommunication mechanisms, theapplications are decoupled from theunderlying HW and Basic SW,enabling the realization of Stan-dardLibrary Functions.ECU Hardware

Methodology OverviewVFB viewSW-CDescriptionAUTOSARSW-C1SW-CDescriptionAUTOSARSW-C2SW-CDescriptionAUTOSARSW-C3...SW-CDescriptionAUTOSARSW-CnStandardized description templates forapplication software components(interfaces and BSW requirements)ECUDescriptionsVirtual Functional BusSystem ConstraintDescriptionStandardized exchange formats andmethodology for component, ECU,and system levelTool supporting deploymentof SW componentsMappingAUTOSARSW-C1ECU IRTEBasicSoftwareAUTOSARSW-C3ECU IIAUTOSARSW-C2RTEBasicSoftware...ECU mAUTOSARSW-CnRTEBasicSoftwareTools for- support of component mapping- generation of RTE, i.e. inter- andintra ECU communicationStandardized Basic Software (BSW)architecture, detailed specificationsfor implementation and configurationof BSWGateway

Meta-model OverviewAUTOSAR XML DescriptionExchangeable and interoperableBetween AUTOSAR compliant tools and partiesXSDPhysical Elements DescriptionApplication SoftwareComponentInternal BehaviorRunnable EntityExclusiveAreaStructuration levelUsage levelXMLSW-C3Physical ElementsSW-C4SW-C 2SW-C1

Agenda• Introduction to AUTOSAR• AUTOSAR Software Architecture• Semantic of execution of a SW-C• Configuration of the OS and RTE• Outlook on the future Timing Extension

SwitchEventcheck_switch ()switch_event(event)AUTOSAR Int.LightRequestswitch_event(event)request_light(type, mode)AUTOSAR InterfaceFront-Light Managerrequest_light(type, mode)get_keyposition()set_light(type, mode)AUTOSAR InterfaceIntroductionary Use-Case– ECU Level (1/4)Headlightset_light(type, mode)set_current (…)AUTOSAR InterfaceAUTOSAR RTEStandardizedInterfaceStd. AUTOSARInterfaceServicesStandardizedInterfaceCommunicationAUTOSARInterfaceECUAbstractionAUTOSARInterfaceOperatingSystemStandardizedInterfaceStd. InterfaceStd. InterfaceStandardized InterfaceStd. InterfaceComplexDeviceDriversDIOPWMCAN DriverMicrocontroller AbstractionECU-Hardware

Introductionary Use-Case– Changing Implementation (2/4)SwitchEventcheck_switch ()switch_event(event)LightRequestswitch_event(event)request_light(type, mode)Front-Light Managerrequest_light(type, mode)get_keyposition()set_light(type, mode)Xenonlight Headlightset_light(type, mode)set_current (…)AUTOSAR Int.AUTOSAR InterfaceAUTOSAR InterfaceAUTOSAR InterfaceAUTOSAR RTEStandardizedInterfaceStd. AUTOSARInterfaceServicesStandardizedInterfaceCommunicationAUTOSARInterfaceECUAbstractionAUTOSARInterfaceOperatingSystemStandardizedInterfaceStd. InterfaceStd. InterfaceStandardized InterfaceStd. InterfaceComplexDeviceDriversDIOPWM DIOCAN DriverMicrocontroller AbstractionECU-Hardware

Introductionary Use-Case– Network Level (3/4)SwitchEventcheck_switch ()switch_event(event)LightRequestswitch_event(event)request_light(type, mode)Front-Light Managerrequest_light(type, mode)get_keyposition()set_light(type, mode)Xenonlightset_light(type, mode)set_current (…)AUTOSAR Int.AUTOSAR InterfaceAUTOSAR InterfaceAUTOSAR InterfaceAUTOSAR RTEStandardizedInterfaceStd. AUTOSARInterfaceServicesStandardizedInterfaceCommunicationAUTOSARInterfaceECUAbstractionAUTOSARInterfaceOperatingSystemStandardizedInterfaceStd. InterfaceStd. InterfaceStandardized InterfaceStd. InterfaceComplexDeviceDriversDIOPWM DIOCAN DriverMicrocontroller AbstractionECU-Hardware

SwitchEventcheck_switch ()switch_event(event)AUTOSAR Int.LightRequestswitch_event(event)request_light(type, mode)AUTOSAR InterfaceIntroductionary Use-Case – Network Level(4/4)Front-Light Managerrequest_light(type, mode)get_keyposition()set_light(type, mode)AUTOSAR InterfaceXenonlightset_light(type, mode)set_current (…)AUTOSAR InterfaceAUTOSAR RTEAUTOSAR RTEAUTOSAR RTEStd. AUTOSARInterfaceServicesAUTOSARInterfaceECUAbstractionStandardizedInterfaceStandardizedInterfaceCommunicationCommunicationCommunicationStandardizedInterfaceAUTOSARInterfaceECUAbstractionStd. InterfaceStd. InterfaceStd. InterfaceStd. InterfaceStd. InterfaceStd. InterfaceStandardized InterfaceStandardized InterfaceStandardized InterfaceDIOCAN DriverCAN DriverCAN DriverPWMMicrocontroller AbstractionECU-HardwareMicrocontroller AbstractionECU-HardwareMicrocontroller AbstractionECU-HardwareCAN Bus

Software Component- Interface Definition (1/2)• Components have two typesof ports– Provided ports• What the component giveR-PortsClientApplicationSoftwareComponentP-PortsSender• This is done through P-Ports– Required portsReceiverServer• What the component needsParameter• This is done through R-Ports• Components can export asmany P-Ports and R-Ports asneededservice interfaces

Software Component- Interface Definition (2/2)• Communication between SW-Cs isperformed via SW-C ports• Ports can be– Provided– Required• Each port specify what it willcommunicate (using port interface)– Sender – Receiver Interface• Specify the data that will be sent / received– Client – Server Interface• Specify the functions that will be called /executed– Calibration Interfaces• Specify the values of calibrationparametersPortPortInterfaceData ElementsCalibrationStatusBrakeIOOperationsBrakeSensorBrakeSensor

Software Component- Composition Definition (1/2)CompositionTrailerSensorTrailerSensorStatusIOTrailerStatusBrakeSensorStatusBrakeIOBrakeSensorStopLightsManagerPowerIOPowerCommandStopTrailerCommandStopLightsCarTrailerStatusBrakeStatusStopLightsTrailerActuatorPowerStopLightTrailerActivationTrailerLightStopLightsCarActuatorPowerCarLightTrailerActivationCarLight

Software Component- Composition Definition (2/2)– Compositions are built from• SW-C Instances– Called Prototype• Assembly Connector instance• Other Composition– A composition is hierarchicalComposition– All SW-C instantiated in aComposition must refer to a SW-C Type

Software Component- Mode Definition– The purpose of mode is• To trigger runnables on thetransition between modes• To make runnables reactdifferentlyModeManagerMode ManagementSTARTUPRUNSHUTDOWNWAKE_UPSLEEPSW-C 1Port IO Port 2Port 3Mode ManagementPort 1– A particular SW-CSTARTUPRUNWAKE_UPSW-C 2Port IO Port 4• Manage modes and modestransitionsSHUTDOWNSLEEPMode Management• Informs the others SW-C ofmodes transitions

Run-Time EnvironmentGenerationRTE ContractPhase”• Generation of the RTE APIs• Based on the SWC Component andBehavior• Allows the SW-C developmentVFB viewXMLAUTOSAR SW-C1XML XML XMLAUTOSAR SW-C...AUTOSAR SW-CAUTOSAR SW-C23nRTE GenerationRTE“GenerationPhase”• Generation of the whole RTE• Based on• All the previous SWCs present on a ECU• The configuration of the correspondingRTEVirtual Functional BusECUDescriptionTool supporting deployment of SWcomponentsMappingECU IECU IIAUTOSAR SW-C AUTOSAR SW-CAUTOSAR SW-C...123RTERTEBSWBSWGatewaySystemConstraintDescriptionECU mAUTOSAR SW-CnRTEBSWCANFlexrayOriginalImage

RTE Generation- Contract Phase (1/2)– RTE Contract phase can occurs as soon as SW-C are fully defined– RTE Contract phase consist in• Generation of the specific APIs to access– The Ports to send and receive data, explicitly or implicitly– The Ports to call and execute operations– The Callibration Port– The Inter Runnable Variables– The Exclusives Areas– The Per Instance Memories– …• These APIs are gathered in the’Component API’ (application header file)Service Call PortReceiver PortClient PortSW-CInternalBehaviorEventRunnable– RTE Contract phase allows• The SW-C development to be parallelised• The SW-C developer to provide the SW-C’s source code without beingconcerned about the communication aspectsEAIRVService ProvidePortSender PortServer Port

RTE Generation- Contract Phase (2/2)– RTE contract phase result is static• If the SW-C description change, the application header file must beregenerated– RTE Contract phase result can be used as a “contract” between aOEM and a subcontractor– SW-C description can be enhanced with the information from thespecific implementation• This includes information about the memory needs for ROM and RAM

Software ComponentMappingSW-C 1Run AECUSW-C 2Run B• Two SW-Cs that exchangeinformation on one ECU– The information can be handled ECUinternallyWe have created Intra-ECUcommunicationSW-C 1Run AECU 1SW-C 2Run BECU 2• Two SW-Cs that exchange informationbetween different ECUs– The information must be handled ECUexternally by the busWe have created Inter-ECU communicationThe AUTOSAR Code-Generator cangenerate this information automatically

SWComponentsBasic SoftwareECU Basic Software- Services viewApplicationSoftwareComponentAUTOSARInterfaceActuatorSoftwareComponentAUTOSARInterfaceSensorSoftwareComponentAUTOSARInterfaceAUTOSARSoftware..............ApplicationSoftwareComponentAUTOSARInterfaceAUTOSAR Runtime Environment (RTE)StandardizedInterfaceAUTOSAR OS, RTE &Bsw SchedulerOperatingSystemStandardizedIntefaceStandardizedAUTOSARInterfaceServicesAUTOSAR Standardized MemoryServices InterfaceStandardizedInterfaceCommunicationAUTOSARCommunicationStandardizedServices InterfaceBasic SoftwareECU-HardwareAUTOSARInterfaceECUAbstractionAUTOSAR Standardized NetworkManagement Interface ServicesStandardizedInterfaceMicrocontrollerAbstractionAUTOSARInterfaceAUTOSAR ComplexDevice Drivers ServicesComplexDeviceDrivers

Agenda• Introduction to AUTOSAR• AUTOSAR Software Architecture• Semantic of execution of a SW-C• Configuration of the OS and RTE• Outlook on the future Timing Extension

Software Component- Behavior Definition– Describe the real time execution elementsand characteristics of an atomic SW-C– Contains RunnableEntities to representexecutable portion of code– Contains RTE Event to trigger Runnables– Provides communication scheme/concurrency scheme between runnables– Provide Per Instance Memory dedicated tothe instances of the associated SW-CPowerIOTrailerStatusBrakeStatusStopLightsManagerBehStopLightsManagerRunPowerManagerRunStopLightsManagerPowerCommandStopTrailerCommandStopLightsCar– Describes Service Needs with regards tounderlying AUTOSAR Services

Software Component- Runnable Definition Timing Event Data Send Completed Event Data Received Event / Data Receive Error Event Operation Invoked Event Asynchronous Server Call Returns Event Mode Switch Event / Mode Switched Ack EventSW-CInternalBehavior– A Runnablebelongs to acertain categoryService CallPortReceiverPortClientPortEA EAEventRunnableIRV IRV IRVServiceProvide PortSenderPortServerPort

Runnable –Example Access– DataWriteAccess• Specifies that a runnableimplicitly sends a certaindata element– Sending of data elementvalues is only done onceafter runnable returns– Several usages of the APIcall inside the runnablecause only one dataelement transmission• Multiple DataWriteAccesscan be declared for arunnableSoftware Component- Runnable DefinitionAtomic SoftwareComponentRunnableEntity• DataWriteAccess– A reference to the interfaceelement that is sent• Used to build the API call

Implicit communicationSoftware Component- Runnable DefinitionASW-C 1ASW-C 2RunnableARunnableBRunnable ARunnable BStart runnableexecutionRunnable jobThis action isperformed by theRTE at the startof runnableThis action isperformed by theRTE at the end ofrunnableStart runnableexecutionGet Data onportSet data onportRunnable jobStop runnableexecutionStop runnableexecution

Explicit communicationSoftware Component- Runnable DefinitionASW-C 1ASW-C 2RunnableARunnableBRunnable AStart runnableexecutionRunnable BStart runnableexecutionRunnable job…..Write data…..Runnable job…..Read data…..Stop runnableexecutionStop runnableexecution

Software ComponentInvoking anoperation– ServerCallPoint• Specifies that a runnableinvoked an operation• Cannot be used concurrently• Can be a– AsynchronousServerCallPoint(Associated withAsynchronousServerCallReturnsEvent)– SynchronousServerCallPoint• Multiple ServerCallPoint canbe declared for a runnable- Runnable DefinitionAtomic SoftwareComponentRunnableEntity• ServerCallPoint– A reference to theoperation that is received• Used to build the API call

WaitingSoftware Component- Runnable Definition– Wait Point• Indicate that theRunnable is to wait foran RTEEvent to occurs– Contains a reference toall RTEEvents that canunlocked it– To stop infinite waiting,the call must specify atimeout• A single Runnable canactually wait only at asingle WaitingPointRte_Read_();Rte_Read_();TimeOut = 3TimeOut = 3DataReceivedEventRTE_E_TIMEOUT

Client - ServersynchronouscommunicationSoftware Component- Runnable DefinitionASW-C 1ASW-C 2RunnableARunnableBRunnable ARunnable BExecutionService requestStart runnableexecutionWait serviceexecutionRunnable jobServiceexcecutedStop runnableexecutionContinue runnableexecution

Exclusive AreaSoftware Component- Runnable Definition• Allow to protect critical sectionsbetween runnables– If two or more Runnables refer to thesame ExclusiveArea, only one isallowed to access it• Two ways to use the ExclusiveArea– Entire Runnable runs in the ExclusiveArea– Runnable dynamically enter and leavethe Exclusive Area• Explicitly make API-calls to the RTE withinthe implementation of the RunnableEntityto enter and leave a specific ExclusiveAreamySwCInternal BehaviorRe1Re2EA1

Inter RunnableVariableSoftware Component- Runnable Definition– Support communication amongrunnables of the same component• Must have a data type• Can have a Initial ValuemySwCInternal BehaviorRe1– Two different communicationapproaches• Explicit communication– Corresponds toDataReceivePoint/DataSendPoint• Implicit communication– Corresponds toDataReadAccess/DataWriteAccessIRVRe2

Agenda• Introduction to AUTOSAR• AUTOSAR Software Architecture• Semantic of execution of a SW-C• Configuration of the OS and RTE• Outlook on the future Timing Extension

AUTOSAR OS,RTE & BSW SchedulerThe applicationpart use the OSservices throughthe usage of RTEAccess to OSservicesSoftwareComponent ASoftwareComponent BSoftwareComponent ZAUTOSAR Runtime Environment (RTE)No direct access toOS servicesBSW module 1OperatingSystemBSWSchedulerBSW module 2The BSW modulesuse the OS servicesthrough the BswSchedulerBSW module NBased on OSEK Time / OSEK OS

AUTOSAR OS, RTE & SchM:– Two differents domains : SWCs & BSWsConfiguration principes– Each domain will define its own tasks and executioncontextsRTE ConfigurationSchM ConfigurationmySwCOS ConfigurationBSW ModuleOS ConfigurationTimingEventInternal BehaviorRe1• Task• Priority• Alarms• Task StackBSW BehaviorEntity• Task• Priority• Alarms• Task StackData Received EventIRVRe2• Task• Priority• Alarms• Task StackBSW ModuleBSW BehaviorEntity• Task• Priority• Alarms• Task Stack02/03.04.2008 Geensys, Copyright ©

AUTOSAR OS, RTE & BswScheduler: RTE– Unique per ECU– Is an interface layer between applicative parts (SW-C) &OS & BSW– All configurations made in RTE are static configurations– The XML models for SWC description allow an automaticgeneration of sources codes• Headers and source for RTE• Source template for application

SW-C 1Run ASW-C 2Run BAUTOSAR OS, RTE & BswScheduler: RTECommunication Usage• Implements communicationbetween 2 SWC of a same ECUmySwCECUInternal Behavior• Implements communicationbetween 2 runnables of a sameSW-CRe1IRVSW-C 1SW-C 2Re2Run ARun BECU 1ECU 2• Implements communicationbetween 2 SWC between ECUs

OS Tasks ReminderExtended tasksonlyRunningBasic andextended tasksWait(4)Terminate(1)WaitingPreempt(5)Start(6)SuspendedRelease(3)Activate(2)Ready

Runnable - Categories– Category 1A• Runnable MUSTterminate• Contains at least anImplicit access andany Explicit Access• Mapped toBasic/ExtendedTasksRTE Glue CodeRunnableRTE Glue CodeRunnableRTE Glue CodeRTE GlueCodeRunnableRTE GlueCodeEvent ?RTE GlueCodeRunnableRTE GlueCodeBasicTaskExtended Task

Runnable - Categories– Category 1B• Runnable MUSTterminate• Contains ONLY ExplicitAccess• Mapped toBasic/Extended TasksRunnableRunnableRunnableEvent ?RunnableBasicTaskExtended Task

Runnable - Categories– Category 2• May Contains Wait Point• Contains ONLY ExplicitAccess• Mapped mostly toExtended Tasks• Recommended only tomap a Runnable to a Task(avoid some possibledelays)RTE Glue CodeWait ?RunnableExtended Task

ECU Parameter Definition– An ECU Parameter Definition contains a group of references to Module Definitions fora standard AUTOSAR ECU– Each Module represents a BSW– Each Module Definition defines the standard configuration parameters for a BSWECU Parameter DefinitionModule Def 1Module Def 2Module Def 3Module Def 4Module Def 5Module Def 6Module Def 7Module Def 8Module Def 9

ECU Parameter Definition- OS ExempleOS ModuleOS AlarmAutoStart- AlarmTime- CycleTime- AppModeRef? Action ?- ActivateTask- Callback- …OS Task- Priority- Activation- Schedule- ExecutionBudget- …- EventRef- ResourceRef- …OS Resource- Property- LinkedResource

ECU Parameter ConfigurationModuleDef1ContainerDef1- ParamDef11- ParamDef12- RefDef11ContainerDef2- ParamDef21- ParamDef22SubContainerDef11- SubParamDef11- SubRefDef11ContainerDef3- ParamDef31- ParamDef32- RefDef31Module1Container1- Param11- Param12- Ref11Container2- Param21- Param22BSW ModuleSubContainer11- SubParam11- SubRef11Container3- Param31- Param32- Ref31BSW ImplementationvendorSpecificModuleDefpreconfiguredConfigurationrecommendedConfiguration

ECU Parameter Configuration- OS & RTE ExampleOS Module ConfigurationRTE Module ConfigurationWakeUpTaskCommandTaskRunPowerManagerRunStopLightsManager- Priority: 10- Activation: 1-Schedule: NON- Priority: 2- Activation: 1- Schedule: NON- PositionInTask: 1- PositionInTask: 1StopLightsManagerPowerIPoweBehStopLightsManagerOrLightManagerWakeUpCommandRunPowerManager StopTrailerCommandEventCommandStopLightsStopLightsCarTrailerStatusBrakeStatusRunStopLightsManager

Agenda• Introduction to AUTOSAR• AUTOSAR Software Architecture• Semantic of execution of a SW-C• Configuration of the OS and RTE• Outlook on the future Timing Extension

Timing SpecificationIntroduction• Introducing timing aspect on all steps of theAUTOSAR methodology:– VFB Timing: this view deals with timing information related tothe interaction of SwComponentTypes at VFB level– SWC Timing: this view deals with timing information related tothe SwcInternalBehavior of AtomicSwComponentTypes.– System Timing: this view deals with timing information relatedto a System,utilizing information about topology, softwaredeployment, and signal mapping– BSW Timing: this view deals with timing information related tothe BswInternalBehavior of a single BswModuleDescription– ECU Timing:this view deals with timing information related tothe EcucValueCollection

VFB Timing• Timing Notations are only considered atinterface level (Atomic SW-C andComposition)– Time to execute some computation– Time to deliver a dataReceiverApplicationSoftwareComponentSenderMax Execution Latency

SWC Timing• Timing Notations are now considered atbehavior level– Time to execute a runnable behavior (activation,start, termination)ApplicationSoftwareComponentBehaviorRunnable1Runnable2

Other Timing• Timing Notations are then enriched for– System Timing: introdution of communicationlatencies (intra and inter-ECU)– BSW Timing: counterpart of SWC (runnables hereare called entities)• And aggregated for– ECU Timing: aggregate only ECU-relevantinformation from previous timing notation

• Basically, timing informations are:Timing description– Composed in a set of meta-model elements(TDEvents, TDEventChains, EventTriggering,LatencyTiming, Synchronization,…)– Referencing meta-model elements depending onthe timing level previously described

•QUESTIONS ?