Designing For Advanced Functional Safety Requirements

1y ago
8 Views
2 Downloads
2.86 MB
64 Pages
Last View : 2m ago
Last Download : 2m ago
Upload by : Kaleb Stephen
Transcription

DESIGNING FOR ADVANCEDFUNCTIONAL SAFETYREQUIREMENTSMATHIEU BLAZY-WINNINGFUNCTIONAL SAFETY MANAGERAMF-AUT-T2805 AUGUST 2017NXP and the NXP logo are trademarks of NXP B.V. All other product or service names are the propertyof their respective owners. 2017 NXP B.V.PUBLIC

AGENDA Overview of ISO 26262 Standard NXP Approach to ISO 26262 ConclusionPUBLIC1

FROM AUTOMOTIVE TO SAFE & SECURE MOBILITYSEAMLESS CONNECTEDMOBILITY EXPERIENCEADVANCED DRIVERASSISTANCE SELF-DRIVINGENERGY EFFICIENCYEnjoying Life.One hour per dayin the carSaving Lives.1.3M Road FatalitiesEvery YearReducing CO2.EU mandates 20%reduction by 2020PUBLIC2

ROAD TRAFFIC ACCIDENTSTHE 9,000100%TotalData source: NMVCCSEvery year! 1.3 m fatalities 50 m people seriously injured 3 trillion cost of road accidents 90% caused by human mistakesDriver-RelatedCritical ReasonsNumber%Recognition Error845,00041%Decision Error684,00033%Performance Error210,00011%Non-performanceError (e.g. Sleep)145,0007%Other162,0008%2,046,000100%TotalWe need to get theHuman Factorout of the equation!PUBLIC3

Elements of a Safe ELIABILITYVEHICLE SAFETY:SECURITY:FUNCTIONAL SAFETY:DEVICE RELIABILITY:Zero accidents by human error (ADAS & SOTIF)Zero accidents by system hacksZero accidents by system failures (ISO 26262)Zero components failures (robust product)SOTIF: Safety of the intended functionalityPUBLIC4

Overview ofISO 26262 StandardPUBLIC55

Functional Safety Standards ISO 26262 is the adaptation of IEC 61508 tocomply with needs specific to electrical and/orelectronic (E/E) systems within road vehicles. ISO 26262 addresses possible hazards causedby malfunctioning behavior of E/E safetyrelated systems. Addresses risks from systematic failures andrandom hardware failures. System safety is achieved through a number ofsafety measures. ISO 26262 provides an automotive-specificrisk-based approach to determine integrity levels[Automotive Safety Integrity Levels (ASIL)]. ISO 26262 uses ASILs to specify applicablerequirements of ISO 26262 so as to avoidunreasonable residual risk.Reference ISO 26262-1:2011PUBLIC6

ISO 26262 Product Development ISO 26262 compliance isachieved between vehiclemanufacturers, Automotivesuppliers (Tier 1), semiconductorsuppliers and IP providersQ: But who does what?Reference ISO 26262-2:2011Focus of presentationPUBLIC7

Part 3 ConceptPUBLIC88

Determining ASILSeverityExposureControllabilityASILHow much harm is done?How often is it likely to happen?Can the hazard be controlled?ConceptPUBLIC9

Hazard Analysis and Risk Assessment (HARA)Concept Identify and categorize the hazards that can be triggered by malfunctions in the system The Risk Assessment is carried out using three criteria Severity– how much harm is done? Exposure– how often is it likely to happen? Controllability– can the hazard be controlled?Reference ISO 26262-3:2011PUBLIC10

Determination of ASIL and Safety Goals ConceptFor each Hazardous event, determine the ASIL based on Severity, Exposure &ControllabilityThen formulate safety goals to prevent or mitigate each event, to avoidunreasonable riskQ: So which ASILshould I target inmy IC or IP?Reference ISO 26262-3:2011PUBLIC11

Functional Safety Concept ConceptThe functional safety concept addresses: Fault Safedetection and failure mitigationState transitioning Faulttolerance mechanisms DriverwarningQ: This is a top down approach,typically components & IPdeveloped as Safety Elementout of Context (SEooC), how tomake assumptions?Note: An SEooC is a safety-related element which is not developed for a specific item. Thismeans it is not developed in the context of a particular vehicle.Reference ISO 26262-3:2011PUBLIC12

Part 4 SystemPUBLIC1313

Safety Mechanisms & FaultsSystem A safety mechanism is a technical solution implemented by E/E functions or elements, or by othertechnologies, to detect faults or control failures in order to achieve or maintain a safe state Safety mechanisms are implemented to prevent faults from leading to single-point failures or toreduce residual failures and to prevent faults from being latent multiple-point fault is a individual fault that, in combination with other independent faults, leads to a multiplepoint failure.Safety Mechanisms can take effect during Power up (pre-drive checks)During operationDuring power-down (post-drive checks)Part of maintenance.Q: How to decide where toimplement safety mechanisms? in HW or SW, in system orcomponent or IP Reference ISO 26262-1:2011PUBLIC14

Fault Detection & Reaction Times Diagnostic test interval time-span from the detection of afault to reaching the safe stateFault tolerant time interval amount of time between theexecutions of online diagnostic testsby a safety mechanismFault reaction time Systemtime-span in which a fault or faultscan be present in a system before ahazardous event occursMultiple-point fault detectioninterval time span to detect multiple-pointfault before it can contribute to amultiple-point failureReference ISO 26262-1:2011Q: How to know which times to use?1ms, 10ms, 100ms, 1sec, 1hr, several hours etcPUBLIC15

Part 5 HardwarePUBLIC1616

Target Metrics for ASIL HardwareAssociate the following target metrics to each safety goal Single-point Latent-faultfault metric (SPFM)Q: Which faults toconsider? How tojustify diagnosticcoverage? Some guidance inPart 5 Annex D metric (LFM) ProbabilisticMetric for random Hardware Failures (PMHF)Q: Which portionof PMHF can anIC or IP use?Reference ISO 26262-5:2011PUBLIC17

Hardware Integration & TestingHardwareQ: Fairlystandards tests,except for faultinjection?Reference ISO 26262-5:2011PUBLIC18

Part 6 SoftwarePUBLIC1919

SW Safety MechanismsSoftwareReference ISO 26262-6:2011PUBLIC20

Part 7 ProductionPUBLIC2121

Part 7 Production ProductionDevelop and maintain a production process for safety-related elements or items that areintended to be installed in road vehicles. Typicallyexisting production processes aligned with ISO TS 16949 are also well alignedwith ISO 26262 requirements In addition, the compliance with safety-related special characteristics may be required Examplesof such safety-related special characteristics are specific process parameters (e.g. temperature range or fastening torque) material characteristics production tolerance Configuration Also, safety impact analysis of changes or field returns is required during production - augmenting standard processes to comply.Reference ISO 26262-7:2011PUBLIC22

ISO 26262 2nd EditionPUBLIC2323

ISO 26262 2nd Edition The 2nd edition of ISO 26262 is planned for release in 2018. Most notable changes Scope now for series production road vehicles, except mopeds.Specific content added for Trucks, Buses, Trailers, Semitrailers and motorcycles (although very minimal)Part 11 guideline added for SemiconductorsPart 12 added for motorcycles (mapping of MSIL to ASIL)Interaction between safety and security organizations mentioned (no specifics)Method for dependent failure analysis provided in multiple examplesGuidance for fault tolerancePart 8.13 Hardware Qualification reworked to focus on non ISO 26262 developed hardwareOverall improvements to clarify understandingLimited new content towards fail operational / autonomous vehicles indicating not yet mature enoughin industry to standardizeDisclaimer: Above notes from DIS version, may change in final releasePUBLIC24

NXP Approach toISO 26262PUBLIC2525

Functional Safety Standards19801985DO 178DO 178AAeronautic19901995200020052010DO 178B2015DO 178CARP 4761DO 254ARP 4754ARP 4754AIEC 61508EN 50155EN 5012XRail TransportEN 50159GenericStandardIEC61508IEC 61508IEC 61508Ed. 2.0IEC 61508IndustrialAutomationAutomotiveMedicalIEC 61511ISO 13849IEC 61508Ed. 2.0IEC 62061(IEC 61508)ISO 26262IEC 60601Ed. 3.0Select products are being defined and designedfrom the ground up to comply withISO 26262Note: Some products enabled for IEC 61508 Ed.2.0 & ISO 13849PUBLIC26

NXP’s Safe Assure Program Launched SafeAssure initiative in September 2011focusing on NXP’s functional safety solutions NXP Development Processes are aligned with ISO26262 since 2013 across product lines BCaM7 deployment will align at BU Auto level100 Products being developed to target ISO 26262: Aug 2012 AMP HW – Leopard (MPC564xL) 32-bit MCU – Certifiedby Exida 2013 AMP SW – First release of Safety MCAL (sMCAL) 2014 AAA HW – Analog – PowerSBC Many more products are in the development pipeline and will cometo completion in the years to comePUBLIC2727

Example Interaction Between Car OEM, Tier 1 & Tier 2 (NXP)Overall ISO 26262 compliance isachieved together, we each own apiece of the puzzleISO26262OEM Relevantscope ofISO26262highItem definitionHazard analysis and risk assessmentSafety GoalsFunctional Safety ConceptSafetyRequirements &DIASafety Manual &Safety AnalysisTier 1 Safety Architecture Safety Concept ASIL Classification of FunctionsRelevantscope ofISO26262mediumSafetyRequirements &DIATier 2 Supplier - NXPSafety Manual &Safety AnalysisNXPFunctional Safety FocusSafety Element out of ContextFoundation HW / SW productsProduct Safety Mechanisms(implemented in offering, described inSafety Manual, quantified/qualified bySafety Analysis)Development Process & MethodsQuality & Quality DataPUBLIC28

HW & SW Components developed as SEooC(4-6) Safety Concept(RS)(4-7) Safety Concept(AS)Safety Manual includes all HW & SWrequirements on system level (Assumptions)as well as Safety Concept descriptionApplicable to HW Component developed as SEooCReference ISO 26262-10:2012PUBLIC29

Tailoring of ISO26262 to Component developed as SafetyElement out of Context (SEooC)HWComponentDeveloped asSEooCApplicable to Component developed as SEooCSWComponentDeveloped asSEooCReference ISO 26262-10:2012PUBLIC30

ISO 26262 Product Development - BCaM7 ISO 26262 compliance is achieved between vehicle manufacturers,Automotive suppliers (Tier 1), semiconductor suppliers and IP UTIONCLOSUREPCPROJECT LIFECYCLETOCESRQCQSNPI LIFECYCLEPI GateDefine product typeQM or ISO 26262Input RequirementsStandardCustomerMarketing (MRD)InternalER GateProduct Functional SafetyAssessment Report &Safety CaseCustomer DocumentsProductRequirements (PRD)(7-5) ProductionTestingData SheetReferenceManual(4-6) Safety Context(8-13) QualificationTestingSafety ManualFMEDA, FTA,DFA(4-7) Safety Concept(5-6) RequirementsSpecifications (RS)(5-10) ValidationTesting(5-8,9) Initial SafetyAnalysisArchitecturalSpecification(5-7) Chip LevelVerification Testing(5-7) Block LevelVerification Testing(5-7) Detailed DesignSpecifications (DDTS)Fault Injection TestingFault Injection TestingFault Injection TestingImplementDiagram Color SchemaFunctional DocumentationDevelopment FlowInput DocumentSafety DocumentationRequirement TraceabilitySimulation TestingSilicon TestingPUBLIC31

NXP Processes aligned with ISO 26262 NXP ISO 26262 process complies with all applicable ISO 26262 ASIL D requirements for HW or SW SEooC developmentISO 26262NXP ProcessASIL AASIL BASIL CPart 2ManagementSafety Plan, Safety Case, Confirmation MeasuresYesPart 3 ConceptOEM / Tier 1 responsibilityNAPart 4 SystemSystem assumptions & Safety Requirements –HW/SWPart 5 HardwareHW – Safety requirements traced toimplementation and testingYesPart 6 SoftwareSW – Safety requirements traced toimplementation and testingYesPart 7 ProductionStandard processes, aligned with ISO 26262YesPart 8 ProcessesStandard processes, aligned with ISO 26262YesPart 9 AnalysisFMEDA, FTA & DFAYesPart 10 GuidelineSEooC Development & application of ISO 26262to componentsASIL DYes, only partially applicableYes, SEooC development One process for all products, regardless of safety architecture ASIL target Only difference is for Confirmation Measures which are tailored to ASIL targetPUBLIC32

NXP ISO 26262 Confirmation Measures NXP performs ISO 26262 Confirmation Reviews (CR), Audit and Assessment as required by ISO 26262 for SEooCdevelopmentConfirmationMeasuresASIL AASIL BASIL CASIL DCR Safety AnalysisYesYesYesYesCR Safety PlanYesYesYesCR Safety CaseYesYesYesCR Software ToolsYesYesAuditYesYesAssessmentYesYesNote: The following confirmation reviews are not applicable: hazard analysis and risk assessment,item integration and testing, validation plan & proven in use argument Confirmation Measures (CM) performed depending on ASIL All checks executed with independence level I3 by NXP Quality organization NXP Assessors certified by SGS-TÜV Saar as Automotive Functional Safety Professional (AFSP) NXP CM process certified by SGS-TÜV Saar as ISO 26262 ASIL DPUBLIC33

TOMORROW: ENABLING THE SAFE & SECURE CONNECTEDCARSecure Connected, Self-Driving Cars willSave 1,3M Road fatalities globallySurround ViewCrossTrafficAlertTraffic SignRecognitionEmergency BrakingPedestrian DetectionCollision AvoidancePark AssistPark AssistAdaptiveCruise ControlBlind SpotDetectionRearCollisionWarningPark Assistance/Surround ViewLane DepartureWarningSurroundView including Big DataInfrastructureNXP Offers Complete Safe &Secure ADAS System .SENSERadarVisionSecure V2XSecureNetworkTHINKProcessingSensor FusionSecuritySecureNetworkACTBIG DATAPowertrainChassisBrakingDigital NetworkingInfrastructureSecurityPUBLIC34

Where the Failures Come From Typically, dangerous failures in a safety system come from a combination of the following Development Insufficient Transientsystem safety architecturefailures in semiconductors, primarily SRAM – very high rate of occurrence Permanent bugs – Software or hardwarefailures in hardwareFor a MCU the break down of Failures is typically:Failure TypeMCU SRAM Transient Failure rateMCU FF Transient Failure rateMCU Package Permanent Failure rateMCU Die Permanent Failure rateMCU Total Failure rateper 20080201000%70.00%20.00%8.00%2.00%100%Residual Failure rate1.00E-05MCU Raw1.00E-061.00E-071.00E-08 MCU ASIL B1.00E-09 MCU ASIL D1.00E-10Note: Assumption - MCU is allocated only 10% of System ASIL targetPUBLIC35

MCU Safety Context Applications have different safety requirements driven by different safety contexts,but the need for safe SW execution is common across all The objective is to make SW execution safe to achieve ASIL B or ASIL Ddepending on target marketASIL BFault Detection Time ostic Coverage(transient & permanent faults)Start-up /Shut-downperiodic testDiagnostic Coverage(permanent faults)Residual Failure rateMCU HW to support SW IndependenceASIL D10 ms90%99%1 x 10-8 / h 1 x 10-9 / h60%90%Residual Failure rate1.00E-05MCU Raw1.00E-061.00E-071.00E-08 MCU ASIL B1.00E-09 MCU ASIL D1.00E-10MPUNote: Assumption - MCU is allocated only 10% of System ASIL targetPUBLIC36

Defining the Safety Concept Objective Define how ASIL targets will be achieved between a mix of on-chip HW safety measures and system levelsafety measures (HW/SW)ISO 26262-5 Annex D – Elements related to HW Components Low application dependency: Power, Clock, Flash, SRAM & Processing Unit High application dependency: Digital IO & Analog IOReference ISO 26262-5:2011PUBLIC37

Module Classification - Safety Each module on the MCU is classified as Safety Related or Not Safety RelatedElements in ISO26262-5, TableD.1MPC5744PFMEDAMPC5744P ModulePower Management Controller (PMC)Power Control Unit (MC PCU)Phase Lock Loop (2 x PLL)Clock Monitor Unit (5 x CMU)ClockClockClock Generation Module (MC CGM)External Oscillator (XOSC)Internal RC Oscillator (IRCOSC)Embedded Flash Memory (c55fmc)Non-VolatileFlashFlash Memory Controller (PFLASH)MemoryEnd-to-end Error Correction Code (e2eECC)System SRAMVolatile MemorySRAMRAM Controller (PRAMC)End-to-end Error Correction Code (e2eECC)Main Core 0 (e200z4251n3)Checker Core 0s (e200z424) (Delayed Lockstep)Crossbar Switch (XBAR)JTAG Controller (JTAGC)Nexus debug modules (NXMC, NPC, NAL & NAP)Processing UnitCoreCyclic Redundancy Check (CRC)Fault Collection and Control Unit (FCCU)Memory Error Management Unit (MEMU)Self-Test Control Unit (STCU2) (includes MBIST & LBIST)Register Protection (REG PROT)CAN (3 x FlexCAN)CommunicationSerial Interprocessor Interface (SIPI)(External)10/100-Mbps Ethernet MAC (ENET)Peripheral Peripheral Bridge (2 x PBRIDGE)Analogue I/O andSystem Integration Unit Lite2 (SIUL2)Digital I/OAnalog to Digital Converter (4 x ADC)Wakeup Unit (WKPU)Power SupplyPowerPart ofSoftwareSafetyExecution YESYESYESYESYESCommentsNot Safety Related module - Debug logicNot Safety Related module - Debug logicYESYESYESYESYESPeripheral module - High application dependency (failure rates only)Peripheral module - High application dependency (failure rates only)Peripheral module - High application dependency (failure rates only)Peripheral module - High application dependency (failure rates only)Peripheral module - High application dependency (failure rates only)Peripheral module - High application dependency (failure rates only)Peripheral module - High application dependency (failure rates only)PUBLIC38

Realizing the MCU Safety Concept - MPC5744PProcessing Unit - Dual Core LockstepFaultTolerantCom.ECConbusesECC onSRAM &FlashClock MonitoringPower MonitoringRedundant use of IO & Application checksPUBLIC39

Defining the Safety Concept – RADAR Example Objective Define how ASIL targets will be achievedbetween a mix of on-chip HW safetymeasures and system level safetymeasures (HW/SW)ISO 26262-5 Annex D – Elementsrelated to HW Components Low application dependency: Power,Clock, Flash, SRAM & Processing Unit High application dependency: RF, Digital &Analog IOPUBLIC40

CustomerDeliverablesPUBLIC4141

NXP SafeAssure ProductsTo support the customer to build his safety system, the following deliverables are provided as standard for all ISO 26262developed products. Public Information available via NXP Website Quality Certificates Safety Manual Reference Manual Data SheetConfidential Information available under NDA Safety Plan ISO 26262 Safety Case Permanent Failure Rate data (Die & Package) - IEC/TR 62380 or SN29500 Transient Failure Rate data (Die) - JEDEC Standard JESD89 Safety Analysis (FMEDA, FTA, DFA) & Report PPAP Confirmation Measures Report (summary of all applicable confirmation measures)PUBLIC42

Safety ManualPUBLIC4343

Safety ManualObjective Enables customers to build their safety systemusing the MCU safety mechanisms and definessystem level HW & SW assumptions Simplify integration of NXP’s safety products intoapplications A comprehensible description of all informationrelating to FS in a single entity to ensure integrityof informationSafety Manual for MCU SolutionSafety Manual for MPC574xPSafety Manual for Analog SolutionContent MCU Safety Context MCU Safety Concept System level hardware assumptions System level software assumptions FMEDA summary Dependent Failures Analysis summaryPUBLIC44

Safety Manual: Structure MCU Safety Context MCU Safety Concept Description of necessary or recommended sw mechanisms for each module (Initial checks, configuration & runtime checks)Failure Rates and FMEDA Describes the functions required by external hardware to complement the MCU safety concept (Error out monitor)System level software assumptions Describes the safety concept of the device (what is implemented and how does it work)System level hardware assumptions Safe states, Fault tolerant time intervalShort introduction to FMEDADependent Failure Analysis bic – IEC 61508 Ed. 2.0 part 2, Annex E: Analysis of dependent failures Countermeasures against common cause failures on chip levelPUBLIC45

Safety Support – System Level Application NotesDesign Guidelines for Integration of Microcontroller and Analog &Power Management device Explains main individual product Safetyfeatures Uses a typical Electrical Power steeringapplication to explain product alignment Covers the ASIL D safety requirements thatare satisfied by using both products: MPC5643Lrequires external measures tosupport a system level ASIL D safety level MC33907/08provides those external measures: External power supply and monitor External watchdog timer Error output monitorPUBLIC46

Dynamic FMEDAPUBLIC4747

Safety Support – Dynamic FMEDAObjective Tailor FMEDA to match application configuration Enables customers, by supporting their system levelarchitectural choicesContent FMEDA methods aligned with functional safetystandards SPFM & LFM, PMFH – ISO 26262 SFF & PFH- IEC 61508 Ed. 2.0 bic – IEC 61508 Ed. 2.0 part 2, Annex EDynamic FMEDA covers elements with lowapplication dependency: Clock, Power Supply,Flash, SRAM, Processing Unit Work flow and result Customer specifies the failure model (dependent onSafety Integrity Level) required by their application,and then confirms the Safety Measures that will beused or not be used A tailored FMEDA is then supplied to customer’s fortheir specific applicationPUBLIC48

ISO 26262-5 (Elements and Failure Models)FMEDA SupplyFMEDA ClockFMEDA FlashFMEDA SRAMFailure RateTableReference ISO 26262-5:2011PUBLIC49

ISO 26262-5 (Elements and Failure Models)FMEDAProcessingUnitReference ISO 26262-5:2011PUBLIC50

Dynamic FMEDA MetricsMCU partitioning for analysis individual olatilememoryvolatilememoryCommunicationDigital I/OAnalog I/OFMEDAFMEDAFailurerates onlyFMEDAs must individually fulfill thetarget relative metrics (SPFM, LFM)Sum of individual PMHF must fulfillthe absolute SPFMLFMPMHFFailurerates onlyPUBLIC51

Dynamic FMEDA Failure Mode, Effect and Diagnostic Analysis A systematic way to identify and evaluate failure modes, effects and diagnostic techniques, and todocument the system. FMEDA can be tailored to application use-case: FMEDA allows adaptation of temperature profile and ASIL level FMEDA allows selection of package used FMEDA allows selection / de-selection of modules FMEDA allows selection / de-selection of diagnostic measures FMEDA allows to change particular DCsCalled “Dynamic FMEDA” FMEDA can generate a specific (static) “customer FMEDA”PUBLIC52

Dynamic FMEDA Additionally - FMEDA Report Summarizing the assumptions and the method of the inductive functional safety analysis activities based on the FMEDAcarried out for the MCUPUBLIC53

Safety Plan, SafetyCase & ConfirmationMeasuresPUBLIC5454

Safety Plan Describes the overall approach to functional safety management during the development of thehardware or software components in accordance with ISO 26262 requirements. The Safety Plan is based on ISO 26262:2011 The Safety Plan follows the standard NXP BCaM7 Process, which defines the overall productlifecycle. The MCU safety activities are planned and tracked in the as part of standard project plans: Thesafety deliverables are identified by “fs:” Key safety activities addressed, including safety requirements definition and reviewsafety analysis and reviewdesign implementation and associated testing in verification simulation, silicon validation and qualificationkey safety management activities of confirmation reviews, audit activities and assessment.PUBLIC55

Key Roles and Responsibilities for ISO 26262 Functional Safety Architect Specification of Functional Safety requirements and performing Functional Safety analysisProject Functional Safety Manager Projectspecific set up and maintenance of Functional Safety activities according to organizationalFunctional Safety standards and product requirements Functional Safety Assessor Planningand execution of functional safety assessments according to ISO26262 standard and theNXP Functional Safety process Organisation Functional Safety Manager Implementationof ISO 26262 standard including training into the organizationPUBLIC56

ISO 26262 Safety Case Lists the ISO 26262 Work Products applicable to the development, as well asprogressively compiles the deliverables generated during the safety lifecycle which formthe safety case along with the safety argument. The complete list of information exchanged between NXP (MCU Supplier) and thecustomer (System developer) is detailed in the ISO 26262 Safety Case, including how theinformation is exchanged: PublicInformation available via the NXP Website Confidential Information available under NDA Internal Information available during onsite Audit In case NXP enters into a Customer Development Interface Agreement (Customer DIA) fora system, then the Customer DIA takes precedence over the ISO 26262 Safety Case.PUBLIC57

ISO26262-10 Table A.8 Checklist ISO 26262-10 Annex A.3.7 deals with techniques or measures to detect or avoid systematic failures during MCU design It proposes a checklist according to table A.8 to provide evidence that sufficient measures for avoidance of systematicfailures are taken during MCU designChecklist summary Checklist complied with for each NXP design. When integrating 3rd party IP, for example from ARM, then major design steps to integrate the 3rd party IP like synthesis, testinsertion, backend etc. is in NXP’s responsibility and NXP provides the data for the checklist. 3rd party IP providers give the data for the IP-design part to enable NXP to fill in the checklistPUBLIC58

NXP ISO 26262 Confirmation Measures NXP performs ISO 26262 Confirmation Reviews (CR), Audit and Assessment as required by ISO 26262 for SEooCdevelopmentConfirmationMeasuresASIL AASIL BASIL CASIL DCR Safety AnalysisYesYesYesYesCR Safety PlanYesYesYesCR Safety CaseYesYesYesCR Software ToolsYesYesAuditYesYesAssessmentYesYesNote: The following confirmation reviews are not applicable: hazard analysis and risk assessment,item integration and testing, validation plan & proven in use argument Confirmation Measures (CM) performed depending on ASIL All checks executed with independence level I3 by NXP Quality organization NXP Assessors certified by SGS-TÜV Saar as Automotive Functional Safety Professional (AFSP) NXP CM process certified by SGS-TÜV Saar as ISO 26262 ASIL DPUBLIC59

SENSETHINKACTAutonomousdriving leading toFail-operationalsystemsPUBLIC60

Functional SafetyAutonomous Driving – SAE LevelsSYSTEM CONTROLHUMANMACHINESYSTEM AVAILABILITYFAIL-SAFEDEGRADED MODEFAIL-OPERATIONALPUBLIC61

ConclusionISO 26262 addresses functional safety inautomotiveNXP applies ISO 26262 across AutomotivedevelopmentsFaults & Safety Mechanisms are determined for HW& SW components, NXP safety concepts enablecustomers to design their safety systemsISO 26262 evolving to address the requirements forsafe autonomous vehiclePUBLIC6262

NXP and the NXP logo are trademarks of NXP B.V. All other product or service names are the property of their respective owners. 2017 NXP B.V.

PUBLIC 14 Safety Mechanisms & Faults A safety mechanism is a technical solution implemented by E/E functions or elements, or by other technologies, to detect faults or control failures in order to achieve or maintain a safe state Safety mechanisms are implemented to prevent faults from leading to single-point failures or to reduce residual failures and to prevent faults from being latent

Related Documents:

Bruksanvisning för bilstereo . Bruksanvisning for bilstereo . Instrukcja obsługi samochodowego odtwarzacza stereo . Operating Instructions for Car Stereo . 610-104 . SV . Bruksanvisning i original

10 tips och tricks för att lyckas med ert sap-projekt 20 SAPSANYTT 2/2015 De flesta projektledare känner säkert till Cobb’s paradox. Martin Cobb verkade som CIO för sekretariatet för Treasury Board of Canada 1995 då han ställde frågan

service i Norge och Finland drivs inom ramen för ett enskilt företag (NRK. 1 och Yleisradio), fin ns det i Sverige tre: Ett för tv (Sveriges Television , SVT ), ett för radio (Sveriges Radio , SR ) och ett för utbildnings program (Sveriges Utbildningsradio, UR, vilket till följd av sin begränsade storlek inte återfinns bland de 25 största

Hotell För hotell anges de tre klasserna A/B, C och D. Det betyder att den "normala" standarden C är acceptabel men att motiven för en högre standard är starka. Ljudklass C motsvarar de tidigare normkraven för hotell, ljudklass A/B motsvarar kraven för moderna hotell med hög standard och ljudklass D kan användas vid

LÄS NOGGRANT FÖLJANDE VILLKOR FÖR APPLE DEVELOPER PROGRAM LICENCE . Apple Developer Program License Agreement Syfte Du vill använda Apple-mjukvara (enligt definitionen nedan) för att utveckla en eller flera Applikationer (enligt definitionen nedan) för Apple-märkta produkter. . Applikationer som utvecklas för iOS-produkter, Apple .

Numeric Functional Programming Functional Data Structures Outline 1 Stuff We Covered Last Time Data Types Multi-precision Verification Array Operations Automatic Differentiation Functional Metaprogramming with Templates 2 Numeric Functional Programming Advanced Functional Programming with Templates Functional Data Structures Sparse Data Structures

och krav. Maskinerna skriver ut upp till fyra tum breda etiketter med direkt termoteknik och termotransferteknik och är lämpliga för en lång rad användningsområden på vertikala marknader. TD-seriens professionella etikettskrivare för . skrivbordet. Brothers nya avancerade 4-tums etikettskrivare för skrivbordet är effektiva och enkla att

Den kanadensiska språkvetaren Jim Cummins har visat i sin forskning från år 1979 att det kan ta 1 till 3 år för att lära sig ett vardagsspråk och mellan 5 till 7 år för att behärska ett akademiskt språk.4 Han införde två begrepp för att beskriva elevernas språkliga kompetens: BI