AUTOSAR And Functional Safety - WordPress
AUTOSAR and Functional SafetySimon Fürst, BMW GroupSafetronic 20118 Nov. 2011, Sheraton Arabellapark Hotel, Munich
AUTOSAR and Functional SafetyOverviewBasic aspects of AUTOSAR architecture and methodologySafety mechanisms supported by AUTOSARTechnical safety concepts supported by AUTOSARRelationship to ISO 26262 and Conclusion28 Nov. 2011Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
AUTOSAR and Functional SafetyAUTOSAR VisionAUTOSAR aims to standardize the software architecture of ECUs.AUTOSAR paves the way for innovative electronic systems that further improveperformance, safety and environmental friendliness.YesterdaySoftwareCustomer needsAUTOSARApplication SoftwareAdaptive Cruise ControlLane DepartureWarningAdvanced FrontLighting System.standardizedUsing standardsHardwareHW-specificHardwareCommunication StackOSEKDiagnosticsCAN, FlexRayHardware and software will be widely independent of each other.Development can be de-coupled by horizontal layers. This reduces development timeand costs.The reuse of software increases at OEM as well as at suppliers. This enhances qualityand efficiency.38 Nov. 2011Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
AUTOSAR and Functional SafetyIntra- and Inter-ECU CommunicationPorts implement the interface accordingto the communication paradigm (hereclient-server based).ECU IECU IIApplicationSW-CAPorts are the interactionpoints of CApplicationPortsThe communication ischanneled via the RTE.RTEThe communication layerin the basic software isencapsulated and notvisible at the SensorHardwareCommunication BusCommunication Path48 Nov. 2011Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
AUTOSAR and Functional SafetySoftware Architecture – AUTOSAR Defined InterfacesAutomotive Open SystemArchitecture (AUTOSAR):Standardized, openly disclosedinterfacesHW independent SW layerTransferability of functionsRedundancy AUTOSARInterfaceAUTOSAR Runtime Environment zedInterfaceAUTOSAR RTE:by specifying interfaces and theircommunication mechanisms, theapplications are decoupled fromthe underlying HW and Basic SWby the RTE. This enables therealization of re-usableapplication dInterfaceStandardizedInterfaceBasic SoftwareComponent58 Nov. 2011InterfaceStandardSoftwareSafetronic 2011 - Simon Fürst - Functional Safety and AUTOSARVFB &RTE relevantRTErelevantBSWrelevant
AUTOSAR and Functional SafetySoftware Architecture: Software Abstraction inside the Infrastructure ArchitectureSWComponentsThe Basic Software Layers are further divided into functional groups.Each functional group consist of multiple basic software eComponentAUTOSARSoftwareAUTOSARInterface.Memory ServicesAUTOSAR Runtime Environment (RTE)Basic SoftwareSystem ServicesMemory ServicesI/O y Hardware AbstractionOnboard DeviceAbstractionMemory HardwareAbstractionMicrocontrollerDriversMemory DriversCommunicationHardwareEEPROM AbstractionAbstractionCommunicationExternalEEPROM DriverDriversECU-Hardware8 Nov. 2011Flash EEPROMEmulationExternal FlashDriverMemory DriversSPIHandlerDriverSafetronic 2011 - Simon Fürst - Functional Safety and AUTOSARMemory Abstraction InterfaceI/O DriversCOM DriversSPI6NVRAM lFlash DriverEEPROMFlash
AUTOSAR and Functional SafetyMethodology and Templates: The AUTOSAR Meta ModelThe AUTOSAR Meta Modelis the backbone of the AUTOSAR architecture definitioncontains complete specification, how to model AUTOSAR systemsMetamodel Package OverviewM3: Model of the Meta Model(Meta-Meta Model)(Defines UML ModelingElements)M2: Model of the model(Meta Model)(Defines AUTOSAR ModelingElements)M1: Model of the system(Defines a real system)M0: Realized System in the car(Implements a real system)78 Nov. 2011All other top-levelpackagesaggregate metaclasses from“GenericStructure”Generic StructureCommonStructureECU ResourceTemplateSW ComponentTemplateSystem TemplateECU DescriptionTemplateBSW ModuleTemplateECU ParameterDef TemplateSafetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
AUTOSAR and Functional SafetyAUTOSAR Methodology – Alternative iptionECUResourceDescription(HW only)System –ConstraintDescriptionComponentAPI(e.g. app.h)ECU .g. mapping)ECU extractof SystemConfigurationECU extractof SystemConfigurationInformation / Database (no files)Generation step:complex algorithm or engineering work8SW-CImplementation8 Nov. 2011AUTOSARECUConfigurationGeneratorDecisions(e.g. scheduling)System per ECUSafetronic 2011 - Simon Fürst - Functional Safety and AUTOSARRTE extract ofECU configurationAUTOSARRTEGeneratorOS extract ofECU configurationOS, COM, Generatore.g. OILBasic SWBasic SWModuleBasicA extractSWModule A extractofECUModuleAof ECU extractconfigurationof ECUconfigurationconfigurationList ofimplementationsof SWcomponentsOther BasicSW GeneratorMCAL –Generator
AUTOSAR and Functional SafetyOverviewBasic aspects of AUTOSAR architecture and methodologySafety mechanisms supported by AUTOSARTechnical safety concepts supported by AUTOSARRelationship to ISO 26262 and Conclusion98 Nov. 2011Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
SourcesAUTOSAR and Functional SafetyApproach of AUTOSAR with regard to Functional Safety.ISO WD 26262Requirements fromWPs & WGsRequirements fromApplicationsRequirements fromSafety ConceptsConsolidated Safety RequirementsStructure and AllocationProcess SafetyRequirementsAUTOSARSafetyGuidelinesTechnical SafetyRequirementsInterface Class 1Interface Class 3List of requirements ondevelopment processesAssignmentDevelopment ProcessMethodology ionList of safety requirementsallocated to BSW & RTETools andGeneration ProcessBSW & RTERequirementsBSW & RTESRSToolsSWSUpdate of existingdocuments of WPsRequirements on toolsand generation processRequirements on how todevelop AUTOSAR SWand Tools108 Nov. 2011List of safety requirementsallocated to methodologySafetronic 2011 - Simon Fürst - Functional Safety and AUTOSARToolsGeneration
AUTOSAR and Functional SafetyOverview on Safety Mechanisms Supported by AUTOSARBuilt-in self test mechanisms for detecting hardware faults (testing and monitoring)Run-time mechanisms for detecting software faults during the execution of softwareProgram flow monitoringRun-time mechanisms for preventing fault interferenceMemory partitioning for SW-CsTime partitioning for applicationsRun-time mechanisms for protecting the communicationEnd-to-end (E2E) communication protection for SW-CsRun-time mechanisms for error handling118 Nov. 2011Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
AUTOSAR and Functional SafetySafety mechanisms for detecting errors.Memory:RAM TestFlash TestSupport for ECC memoryCore:Core Test128 Nov. 2011Watch DogLogical and temporal program flowmonitoringSafetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
AUTOSAR and Functional SafetyRun-time mechanisms for error handlingDetected errors in the basic software:Are reported through DEM to SW-Cs. SW-Cs then executes application-specificactionsAre reported to FIM, which permits to disable some functions ofSW-CDetected hardware errors:Arithmetic exceptions (e.g. division by 0): handled by OS callouts (small errorhandling routines in the context of basic software). Typical reaction – ECU resetHW errors detected by HW testing: handled by callouts. Typical reaction – ECU resetErrors detected my MMU/MPU (memory and time partitioning). It will shut down orrestart the faulty SW-C partition138 Nov. 2011Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
AUTOSAR and Functional SafetyMemory partitioning for Software-ComponentsEnables create protection boundaries around groups of SW-CsThis is realized by user-mode/non-trusted memory partitions (for groups of SW-Cs)This protects from interference:(1) basic software and(2) SW-Cs in otherpartitionsBasic software is notAUTOSARpartitioned. It runsSoftwarewith in CPU super.visor mode withAUTOSAR Runtime Environment (RTE)full access tomemory, CPU andall other hardware c SoftwareECU-Hardware148 Nov. 2011Safetronic 2011 - Simon Fürst - Functional Safety and tionAUTOSARInterfaceComplexDeviceDrivers
AUTOSAR and Functional SafetyEnd-to-End communication protection (1/4)E2E protection detects faults in data caused by both hardware and in softwareTypical sources ofLibrariesOS-Application 2interferences, causing errorsdetected by E2E protection:OS-Application 1Receiver 1SenderSW-related sources:S1. Error in mostly generatedRTE,S2. Error in partially generatedand partially hand-coded COMS3. Error in network stackS4. Error in generated IOC orOSS1H3AUTOSAR Runtime Environment (RTE)System ServicesMemory ServicesCommunication ServicesI/O Hardw are AbstractionCDDS2S3IOCOnboard DeviceAbstractionMemory HardwareAbstractionDirect functioncallCommunication Hardw areAbstractionHW-related sources:H1. Microcontroller error duringcore/partition switchH2. Failure of HW networkH2. Network EMIH3. Microcontroller failureduring context switch (partition)or on the communicationbetween coresS3Receiver 2Microcontroller DriversMemory DriversCommunication DriversI/O DriversH3Microcontroller 1 / ECU 1158 Nov. 2011Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSARH4Microcontroller 2/ ECU 2
AUTOSAR and Functional SafetyEnd-to-End communication protection (2/4)Application is almost un-impacted by the introduction of end-to-end protection wrapperEnd-to-End protection wrapper protects/checks the communication on behalf ofapplication, i.e. SW-CsEnd-to-End Protectionwrapper encapsulatesthe data protection andalso invokes RTEOS-Application 2OS-Application 1Sender 1Receiver 1Application logicApplication logic9 Consume safe data elements1 Produce safe data elements2 Invoke safe transmission request E2EPW Write()6 Invoke safe read do get the data element- E2EPW Read()E2E protection wrapperE2E protection wrapper3 Call E2E protect on array – E2E P0x Protect()8 Call E2E check on array - E2E P0xCheck()4 Invoke RTE - RTE Write() to transmit the data element7 Invoke RTE read - RTE Read() to get the data elementAUTOSAR Runtime Environment (RTE)AUTOSAR Runtime Environment (RTE)LibrariesLibraries5: RTE communication (intra or inter ECU), either through COM, IOC, or local in RTEE2ELib168 Nov. 2011Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSARE2ELib
AUTOSAR and Functional SafetyEnd-to-End communication protection (3/4)Protection of data exchanged over communication channels like FlexRay and CANFailure modes addressed as defined by ISO DIS 26262 for communication (repetition,deletion, insertion, incorrect sequence, corruption, timing faults, addressing faults,inconsistency, masquerading)Three different protection mechanisms for data are usedCRC, counter, Data ID, timeout detectionData ID included in to calculated CRC, but not sentData IdCRC0xF Count Signal1er0xFFSignal 2CRC : CRC8 over(1) Data Id,(2) all serialized signal (including empty areas, excluding CRC byte itself)178 Nov. 2011Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
AUTOSAR and Functional SafetyEnd-to-End communication protection: future considerations (4/4)Fully AUTOSAR compliant design with major impact on ASIL inheritanceExample: overall flow atsenderOS-Application 1SW-C 11. Produce safe data elements2. Invoke RTE - RTE * p o () to transmit the data element3. Map Data Elements to signalsAUTOSAR Runtime Environment (RTE)LibrariesCommunication Services4. COM Signals8. Execute E2E Library, wrte control fields(e.g. CRC, Counter) in IPduDataE2E Lib7. E2E PXXProtect(&Config, &State,(unit8*) IPduData)COM E2ECalloutsCOM5. Serialize signals on I-PDU9. Updated parameters State and IPduData6. IPDU E2EProtect IPDU ID ( PduId, IPduData)11. If (ret TRUE) deliver IPduData;else no action10. ret: TRUE if no error else FALSE; updated IPduDataPDU Router188 Nov. 2011Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
AUTOSAR and Functional SafetyOverviewBasic aspects of AUTOSAR architecture and methodologySafety mechanisms supported by AUTOSARTechnical safety concepts supported by AUTOSARRelationship to ISO 26262 and Conclusion198 Nov. 2011Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
AUTOSAR and Functional SafetyTechnical safety concepts supported by AUTOSARImplementation of typical safety concepts in the automotive domainIntelligent HW watchdog (ASIC) / 3-level safety conceptMonitored channel (2 µCs, the second is a simple µC monitoring the first µC)Dual channel (2 AUTOSAR µCs)Application redundancy (on the same or different µCs)Basic Software redundancy inside one ECU208 Nov. 2011Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
AUTOSAR and Functional SafetyApplication redundancyAssuming integrity of HW/ECU and AUTOSAR basic software implementation, softwareredundancy with ASIL decomposition can be used within the same ECU.Distribution of SW channels across ECUs is also possible.SW-C Channel 1SW-C Channel 2AUTOSARµC core 121µC core 28 Nov. 2011SW-C Channel 1SW-C Channel 2AUTOSARAUTOSARECU 1ECU 2Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
AUTOSAR and Functional SafetyBasic Software redundancy inside one ECURedundancy inside AUTOSAR e.g. double input/output data paths throughRedundant IO hardware abstraction and IO driversRedundant and diverse (e.g. ADC DIO, internal ADC external ADC)RedundancythroughSW-C Channel 1SW-C Channel 2SW-C Channel 1SW-C Channel 2integrationof complexRuntime EnvironmentRuntime Environmentdrivers runnComplex DriversI/O Hardware AbstractionI/O Hardware Abstractioning on theI/O Signal Interface 1I/O Signal Interface 2I/O Signal Interface 1same µCDriver for ext.offering aADC ASICredundantComplexdata pathDriverCOM DriversCOM DriversI/O DriversADCSafetronic 2011 - Simon Fürst - Functional Safety and AUTOSARµCHWcomponentADC Driver 1ADC 2ADC 1ADC Driver 2ADC Driver 1DIOSPI8 Nov. 2011DIO DriverSPIHandlerDriver22µC
AUTOSAR and Functional SafetyOverviewBasic aspects of AUTOSAR architecture and methodologySafety mechanisms supported by AUTOSARTechnical safety concepts supported by AUTOSARRelationship to ISO 26262 and Conclusion238 Nov. 2011Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
AUTOSAR and Functional SafetyRelationship to ISO 26262Essential concepts of ISO 26262 have been developed in sync with AUTOSARSoftware configurationPart 6, Chapter 7 and Annex CFreedom of interference by partitioningPart 6, Chapter 7 and Annex DSafety Element out of Context (SEooC)Part 10, Chapter 9Qualification of software toolsPart 8, Chapter 10”Item” Development3-7 Hazard analysis and riskassessmentHazard analysis and risk assessmentOverall management of safety requirements8-6 Overall management of safety requirementsrequireASIL Capability3-7 Hazard analysis and riskassessmentAssumptions on safety goals (ASILSafety Element out of ContextCapability per system failure )Specification of safety goalsAssumptions on functional safetyconcept3-8 Functional safety conceptAssumptions on functional safetyrequirementsSpecification of functional safetyrequirements4-6 Specification of technical safetyconceptSpecification of technical safetyrequirements4-7 System designSystem design specification5-6 Specification of HW safetyrequirements6-6 Specification of SW safetyrequirementsHardware safety requirementsSoftware safety requirementsAfter SOPProduct developmentConcept phaseSEooC Development248 Nov. 2011Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
AUTOSAR and Functional SafetyRelationship to ISO 26262Due to rules on ASIL inheritance defined in ISO 26262 the AUTOSAR basic softwareand RTE inherits safety relevance.Either implement complete AUTOSAR basic software according to max. ASIL ofapplication software ordemonstrate freedom of inference in basic software by appropriate mechanisms1. Vocabulary2. Management of functional safety2-5 Overall safety managementChapters tobe consideredbyImplementers3-5 Item definition3-6 Initiation of the safety lifecycle258 Nov. 20113-8 Functional safetyconcept2-7 Safety management after release forproduction4. Product development: system level3. Concept phase3-7 Hazard analysis and riskassessmentFor all implemented safetymechanisms a safety manual isneeded containingThe fault model according towhich the safety mechanismwas developedThe constraints that must befulfilled when applying a safetymechanism2-6 Safety management during item development4-5 Initiation of productdevelopment at the system level4-11 Release for production4-10 Functional safety assessment4-6 Specification of the technicalsafety requirements4-7 System design4-9 Safety validation7. Production and operation7-5 Production7-5 Operation, service(maintenance and repair), anddecommissioning4-8 Item integration and testing5. Product development:hardware level6. Product development:software level5-5 Initiation of productdevelopment at the hardware level5-6 Specification of hardwaresafety requirements5-7 Hardware design6-5 Initiation of productdevelopment at the software level6-6 Specification of software safetyrequirements5-8 Hardware architectural metrics6-8 Software unit design andimplementation5-9 Evaluation of violation of thesafety goal due to random HWfailures5-10 Hardware integration andtesting6-7 Software architectural design6-9 Software unit testing6-10 Software integration andtesting6-11 Verification of software safetyrequirements8. Supporting processes8-5 Interfaces within distributed developments8-6 Specification and management of safety requirements8-7 Configuration management8-8 Change management8-9 Verification8-10 Documentation8-11 Qualification of software tools8-12 Qualification of software components8-13 Qualification of hardware components8-14 Proven in use argument9. ASIL-oriented and safety-oriented analyses9-5 Requirements decomposition with respect to ASIL tailoring9-6 Criteria for coexistence of elements9-7 Analysis of dependent failures9-8 Safety analyses10. Guideline on ISO 26262 (informative)Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSARCore processesImplementers have to tailorISO 26262 according to theiractivities in the safety-lifecycle
AUTOSAR and Functional SafetyConclusionAUTOSAR systematically derived safety mechanisms supported in release 4.0AUTOSAR provides support for dedicated safety mechanisms with generic fault modelsAUTOSAR supports typical technical safety conceptsDuring system and software design the safety manual is considered to appropr
Simon Fürst, BMW Group Safetronic 2011 8 Nov. 2011, Sheraton Arabellapark Hotel, Munich. 2 8 Nov. 2011 AUTOSAR and Functional Safety . Basic aspects of AUTOSAR architecture and methodology Safety mechanisms supported by AUTOSAR Technical safety concepts supported by AUTOSAR Relationship to ISO 26262 and Conclusion
AUTOSAR 3.x AUTOSAR 4.x AUTOSAR 3.x is used in serial production projects by: Audi / Volkswagen / Porsche Daimler Fiat / Chrysler Volvo Trucks (incl. Construction Machines) AUTOSAR 4.x is used in serial production projects by: BMW GM Toyota Volvo Cars AUTOSAR 4.x is generally announced by Ford PSA
AUTOSAR User Group, i.e. the Artop User Group . –It is a group of AUTOSAR members and partners, i.e. users of AUTOSAR, with a special interest in AUTOSAR tools. –Was launched in October 2008 and the members currently are: –Continental –Geensys –Peugeot Citroën (PSA)–BMW Car IT –New members are welcome to join the User Group.
Both, Releases 2.0 and 2.1, are in use by several AUTOSAR members for series produc-tions. 2.2. Overview on AUTOSAR Phase II Three releases had been planned for AUTOSAR Phase II, providing a continuous improve-ment of the specifications and introducing new concepts. Release 3.0 was published early 2008 on the AUTOSAR web site [1]. It included a .
Adaptive Environment - The AUTOSAR Adaptive environment for adaptive design AUTOSAR Builder is based on Eclipse and uses Artop. Artop is an open AUTOSAR tool environment that is available for free. It enables you to build your own tools and integrate from other tool vendors. For more details, see the AUTOSAR Builder Overview document. 1.
2 Introduction to AUTOSAR Simulink approach to AUTOSAR Overview of Modeling SWCs & Modeling Styles AUTOSAR Design Workflows Bottom Up, Top Down & Round Trip Advanced Topics –Top 5 Startup, Reset, and Shutdown Modeling Basic Software (BSW) Access J-MAAB Type B Architectu
Specification of NVRAM Manager AUTOSAR CP Release 4.3.1 9 of 190 Document ID 033: AUTOSAR_SWS_NVRAMManager - AUTOSAR confidential - 1 Introduction and functional overview This specification describes the functionality, API and the configuration of the AUTOSAR Ba
AUTOSAR 3.x: First specification: 2007 Mature solution used for series production 2010ff Adaptations necessary OEM-specific extensions AUTOSAR 4.x: First specification: 2009 First mature specification: 2012 (4.0.3) 4.0.3 is the right version for development start in 2012 New functions: safety, Ethernet/IP, multicore, AUTOSAR Status
The American Board of Radiology . i The Diagnostic Radiology Milestone Project The Milestones are designed only for use in evaluation of resident physicians in the context of their participation in ACGME accredited residency or fellowship programs. The Milestones provide a framework for the assessment of the development of the resident physician in key dimensions of the elements of physician .
