practical experiences from implementing iso 26262 vector ......example: model-based analysis and...

Practical Experiences from Implementing ISO 26262

Vector Congress 2012, Stuttgart, 29. Nov. 2012Christof Ebert, Vector Consulting Services

© 2012 . Vector Consulting Services GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V 1.1. 2012-11-29.

2/34

Content

Challenges with Implementing Functional Safety

Safety Management

Safety Development

Supporting Processes

Summary and Outlook


3/34

Functional Safety: Broad Exposure

Exposure of almost many E/E functions Risk of liability

Airbag

Delayed deployment after crash detection

ESP

Unintended, single-sided brake effect on straight lane

Electronic Park Brake

Unintended activation in motion

Collision Avoidance

Acceleration instead of deceleration in traffic


4/34

ProjectManagement

RequirementsManagement

SupplierManagement

QualityManagement

ConfigurationManagement

Idea

SystemReq. Analysis

ComponentTest

SystemTest

SystemDesign

ComponentReq. Analysis

ComponentImplementation

SystemIntegration

ComponentIntegration

ComponentDesign

Functional Safety: Wide Impact

Management Activity

Engineering Activity

Affected by ISO 26262

OEMSupplier

Wide impact on entire life-cycle Risk of gaps and inconsistencies


5/34

Fault

Failure

Error

Fault

Failure

Error

Fault

Failure

Error

…

System hierarchyMistake

Hazard

Effe

ct

Functional Safety: Many Techniques

Many methods and techniques Risk of uninformed usage

Fault prevention•Guidelines•Processes

Fault detection•Code analysis•Reviews, Test

Fault tolerance•Redundant design•Memory protection

Failure prevention•Redundant Shut-off•Fail-safe concepts


6/34

Functional Safety: Complex Standard

10 Parts

> 450 pages

in 43 chapters

~ 600 requirements

~ 100 work products

~ 180 (engineering-)methods

Abstract and detailed level of formulation

Rather complex standard Risk of overheads and bureaucracy

Source: ISO 26262-1:2011


8/34

Vector Experiences for Implementing Functional Safety

Setting up safety management

Integrating the Safety Life-Cycle

Including the customer

Managing safety requirements

Adjusting the Development Process

Using tools

Avoid inconsistencies

Avoid overheads

Avoid overheads

Avoid gaps

Avoid inconsistencies

No uninformed usage


9/34

Content


Safety Management Setting up Safety

Management Integrating the Safety Life-

Cycle

Safety Development


Summary and Outlook


10/34

Setting up Safety Management

Challenge

Effective and lean management of all safety aspects

Traps

Unclear responsibilities and interfaces along the life-cycle

Insufficient leadership competence of safety manager

Guidance

Define clear responsibilities and interfaces for safety activities

Install safety roles: Corporate/project safety manager, safety engineer

Anchor safety in the line and in projects (i.e., avoid shadow organization)

Build up a safety culture top-down from senior management

Clearly assign the safety responsibilities in the safety plan

Implement lean yet effective reporting, tracking – and escalation


11/34

Example: Define Clear Responsibilities

Responsibility for the system means responsibility for the system safety concept

Install safety roles: Corporate/project safety manager, safety engineer

Define clear responsibilities and interfaces for safety activities and work products

E/EProject manager

Componentdeveloper

Componentdeveloper

Componentdeveloper

Systemarchitect

Safetymanager


12/34

Integrating the Safety Life-Cycle

Challenge

Efficiently integrate safety with regular project activities

Traps

Insufficient effort budgeted for safety-relevant activities

Confusing documents that are not used and maintained

Missing understanding of activities to be done

Guidance

Integrate the safety activities directly with the regular project activities

Provide filtering on what matters for a work product or role at a time

Include all relevant information in one safety plan (e.g. inputs, outputs, explanations, mapping, status, responsibilities, milestones, dates)

Connect safety plan to DIA (Development Interface Agreement)


13/34

Example: Integrating Safety Activities to Project Plan

RequirementsAnalysis

ComponentTest

SystemTest

SystemDesign

Component Design

Component Implementation

SystemIntegration

Requirements Analysis

ComponentTest

SystemTest

SystemDesign

ComponentDesign

ComponentImplementation

SystemIntegration

1

Item Definition

2

Hazard and RiskAnalysis

3

System safetyconcept

4

System andcomponent design

5

QualitativeSafety Analyses

6

QuantitativeSafety Analyses

7

Verification andValidation

8

Safety Case

Integrate the safety activities directly to the regular project activities

Include all relevant information in one safety plan


14/34

Content


Safety Management

Safety Development

Including the Customer



Summary and Outlook


15/34

Including the Customer

Challenge Achieve upfront commitment to necessary activities

Traps Inconsistent understanding of DIA (Development Interface

Agreement) and responsibilities to match the standard Different expectations of the extend of work products to be shared or

delivered (e.g. FMEA: cover sheet vs. complete document)

Guidance

Ensure the DIA with clear responsibilities (RACI) is agreed and signed upfront

Provide a description how functional safety will be part of the product, how it will be handled and what are the key ideas to achieve it (i.e., safety plan and derived DIA, safety handbook, safety manual, item definition)

Define extend of work products to be exchanged (original, extract, onsite inspection)

Use ISO 26262 oriented list of activities and work products in project planning


16/34

Example: Development Interface Agreement (DIA)

Base the DIA on the safety plan

Use tailoring mechanism for DIA

Agree and document clear responsibilities (i.e., RACI)

Agree extend to be shared (e.g. Original, Extract, Inspection, etc.)

Define what is the concrete document to be exchanged (interpretation)


17/34


Challenge

Do what is necessary and avoid overheads

Traps

Development process is inconsistent with ISO 26262

Overengineering and gaps due to lack of clarity how activities and work products with their respective quality level map to ISO 26262

Guidance

Base safety activities and work products on a defined CMMI/SPICE driven life-cycle

Use table format and elaborate each single safety requirement

Provide and maintain an ASIL depended mapping

Directly refer from operation scenarios, operating modes and safety goals to existing artifacts in the model (drop-down lists)


18/34

Example: Consistently Documenting Safety Goals

Directly reference to existing artifacts in the model

Mapping of ASIL-dependent measures

Table based approach to perform hazard and risk assessments


19/34

Content


Safety Management

Safety Development


Managing Safety Requirements

Using Tools

Summary and Outlook


20/34

Managing Safety Requirements

Challenge Create maintainable and traceable requirements

Traps Unstructured, unreadable text formats Incomplete and inconsistent entries Relying on tools alone without adequate coaching and learning

Guidance

Use systematic and structured techniques for eliciting, specifying, validating and tracing functional and safety requirements

Set up and maintain bidirectional traceability throughout the project

Evaluate requirements status and progress against planning

Define test criteria at the same time when specifying requirements

Use appropriate tools (i.e., do not manage requirements with Office tools)


21/34

Example: Functional Safety Requirements

Refinement of safety goals and safety functions into functional safety requirements (FSRs)

Tabular and diagrammatic representation of traceability

Automatic consistency checks and metrics


22/34

Using Tools

Challenge Appropriate tools to support project activities

Traps Inadequate tools, such as Office, cause inefficiencies and rework Engineers and managers insufficiently trained Tools not embedded in a systematic workflow along the safety life-cycle

Guidance

Introduce a professional tool chain with workflow support

Ensure a single source for all project and engineering data

Agree tools requirements (e.g. security, performance, collaboration) with all stakeholders before introducing a tool

Train and coach periodically on tools (e.g., lunch talks with evangelists)

Check periodically usage and usefulness of tool chain


23/34

Example: Tool-driven Hazard Analysis and Risk Assessment

Common data base for hazard analysis, risk assessment and FMEA to safety requirements and documents

Consistent reporting at any stage of the development process based on given tempates


24/34

Example: Model-Based Analysis and Documentation

Safety goals

Model-based design of functional and technical safety concept (incl. ASIL decomposition

Single source for item definition, based on features, requirements, operating scenarios, dependencies

Generation of ISO 26262 compatible reports

Documentation of tool based analysis (FMEA, FTA, FMEDA)

Documentation of requirement based tests and their results

Documentation of safety requirements

Support of hazard analysis and risk assessment and documentation of safety goals


25/34

Example: Tool-based Validation of Safety Concept with FMEA

Traceability to design artifacts using drag and drop (e.g. allocating prevention measures to functional requirements)

Consistency checks and metrics to ensure that the necessary coverage has been achieved


26/34

Example: Consistent Tool-Chain for Quality and Efficiency

Identification and management of safety goals and requirements

Model-based design and analysis (FMEA etc.) of safety architecture

Test support (configuration, regression etc.) by test data management and test tools


27/34

Content


Safety Management

Safety Development


Summary and Outlook


28/34

AirbagsElectronic stability control Active body control Adaptive gearbox controlAdaptive cruise controlEmergency callGearbox controlTraction control Anti lock brakesElectronic fuel injectionCruise control

Complexity Grows Faster than Available Competences

1975 1985 1995 2005

Electronic fuel injectionCruise control

Gearbox controlTraction control Anti lock brakesElectronic fuel injectionCruise control

Adaptive HeadlightsSteer-by-wireLane AssistantStop and GoParking Distance ControlEmergency Break AssistCurve-WarningHybrid DriveRoad TrainsElectronic Brake Control TelediagnosticsCar-2-car CommunicationOnline Software UpdatesAirbagsElectronic stability control Active body control Adaptive gearbox controlAdaptive cruise controlEmergency callGearbox controlTraction control Anti lock brakesElectronic fuel injectionCruise control

Increasing number and complexity of functions

More and more distributed development

Rising certification requirements

2015

Many systems to be handled

Inefficient processes and tools

Lack of experts


29/34

Key Success Factor: Change Towards Safety Culture

Safety CultureNecessary measures are planned according to safety analysis – and reliably implemented

Safety expertise is embedded into the regular line and project organization

Risk analysis and FMEA are developed at the beginning of system development and are continuously updated

System architecture explicitly covers the safety goals and requirements

Changes are analyzed with respect to their effects on functional safety by a strict change management

Safety assessments are established as a normal and standardized behavior

…

Implementing ISO 26262 implies a profound culture change

Classic Development CultureInsufficient budget and time for relevant safety measures

Shadow organization of safety experts and staff teams

Risk analysis is done superficially for documentation purposes and not maintained

System architecture is not considered in safety goals and requirements

Changes are accepted at any time for practically all system parts

Safety assessments are conducted only sporadically

…


31/34

Outlook

Automotive OEMs in many cases still need to improve their process capabilities to fulfill the requirements of the safety standards and to better collaborate with suppliers

Suppliers of established safety critical components need to further improve field observation and abilities for complete safety case.Examples: Engine management systems, driving dynamics

Suppliers of new and innovative components need to build up good basic process capabilities as a reliable foundation for safety.Examples: Innovative driver assistance functions and powertrain

ISO 26262 will evolve based on experiences and to cover new challenges and development techniques

Safety capabilities will become part of standard supplier evaluations

Functional safety can be achieved on the basis of mature development processes together with a competent partner.


32/34

Vector – Complete Safety Solution Portfolio

Providing software components and platforms, such as MICROSAR Safe Facilitating safety analyses (e.g., Hazard, FMEA, FTA) Development and review of safety concepts

Safety Engineering (Examples)

Provisioning (interim) safety managers for development projects Executing safety assessments at suppliers

Safety Management (Examples)

Vector Safety-Check and introduction of ISO 26262 in R&D department (analysis of current state, incl. technical and procedural methods and

Training und coaching for functional safety, sustainable safety culture Implementation of tool support, such as PREEvision

Introduction of Safety Processes (Examples)

Thank you for your attention!

www.vector.com/safety www.vector.com/consulting

practical experiences from implementing iso 26262 vector ......example: model-based analysis and...

Documents