Automotive Functional Safety ISO 26262 Training Bootcamp

Automotive Functional Safety ISO 26262 Training Bootcamp by Tonex

Automotive Functional Safety ISO 26262 exists because automotive technology has surged over the past 25 years.

This has predictably led to compliances. In 2011, the Automotive Functional Safety ISO 26262 standard was published, designed for the specific risk picture of the automotive industry and road vehicles. Its intent is to ensure the design and construction of functionally safe vehicles and efficient safety management through the supply chain.

ISO 26262 has become increasingly important because electronic Systems support the human driver or can even take over critical tasks to control the vehicle. This leads to increased risks from systematic failures and random hardware failures of these systems. ISO 26262 provides guidance for the automotive industry to mitigate these risks.

The ISO 26262 standard is a weighty series of documents that many believe has all the force of law or regulation; however, it is not a dictate. It is an agreement on best practices for participants in the vehicle value chain to follow to ensure safety as far as the industry understands it today.

ISO 26262 requires that hardware and software safety concerns be addressed and documented throughout the product lifecycle. Though safety design was considered part of general requirements activity in the past, hardware and software teams working in isolation in automotive development does not guarantee the kind of functional safety coverage required by ISO 26262.

Using ISO 26262 to evaluate the safety of your vehicle’s electrical and electronic components provides multiple benefits to automotive original equipment manufacturers (OEMs) and suppliers, such as:

• Demonstrate due diligence and ensure overall safety of the respective vehicle and/or the corresponding systems in compliance with ISO 26262
• Maintain your competitive advantage in interpreting and implementing the ISO 26262 requirements correctly
• Minimize the risk of harm to people and non-acceptance of your products by the market
• Avoid costly product recalls and reputational damage due to safety hazards because insufficient safety assurance
• Simplified access to global markets by ensuring compliance with relevant international regulations

The entire area of functional safety is important because the systems covered under functional safety are designed to automatically prevent dangerous failures or to control them when they occur. It helps us to design a system that can execute specific functions correctly, even under non-intended use (or sometimes even misuse).

Automotive Functional Safety ISO 26262 Training Bootcamp Course by Tonex

Automotive functional safety ISO 26262 training covers the background of ISO 26262 standard, its scope, the main differences from IEC 61508 (the general safety standard), and how the scope varies with adding new systems.

Automotive functional safety ISO 26262 training provides an overview of all sections of ISO 26262 and its impact. Automotive functional safety ISO 26262 training helps you prepare for ISO 26262 by presenting the details of ISO 26262 in a practical way. This hands-on seminar will give you the all the information you need to implement ISO 26262.

What is ISO 26262?

ISO 26262 is a Functional Safety standard that is a modification of the general safety standard IEC 61508 for the specifics of Automotive Electric/Electronic Systems.

ISO 26262 is applied to safety related systems that contain one or more EE systems installed in passenger cars with a maximum gross vehicle mass up to 3,500 kg.

Learn About:

• ISO 26262 requirements
• The challenges of implementing ISO 26262
• The formal safety management processes and the recommended supporting processes
• Risk assessment and the functional safety concept
• Technical safety concept and system design
• Safety-oriented hardware and software development
• A methodical approach to safety analysis
• Skills required for effective auditing of the ISO 26262 requirements
• Skills to review the Safety Case
• Functional Safety Audit and Functional Safety Assessment
• Confirmation Measures including Confirmation Reviews, Functional Safety Audit and Functional Safety Assessment
• Hazard analysis and risk assessment (H&R / HARA)
• Parts 2,3,4,5,6,7,8, and 9
• FMEA
• FTA
• ISO 26262 hardware architectural metrics
• Dependent failure analysis (DFA)
• DRBFM

Why Do You Need ISO 26262 Training?

ISO 26262 is an automotive application standard for functional safety IEC 61508 that impacts the whole product life cycle. However, applying and implementing ISO 26262 in an effective, efficient way can be challenging. That is why you need to educate your personnel with the right, suitable, and comprehensive training. Our ISO 26262 automotive functional safety training allows you to inform your personnel about their legal responsibilities, the safety protocols, and how they can meet the ISO 26262 requirements.

TONEX ISO 26262 Training Framework

Automotive functional safety ISO 26262 training is combined of interactive presentations and hands-on activities.

Audience

Automotive functional safety ISO 26262 training is a 4-day course designed for:

• System engineers
• Software and hardware engineers
• Managers responsible for the development and implementation of systems, software and hardware in a motor vehicle
• Product development engineers
• Suppliers whose products contain electronics or software
• Quality engineers
• SPICE, CMMI, and internal process assessment personnel
• Attorneys involved in Product Liability
• Supplier quality engineers
• Functional safety managers
• Functional safety implementation leaders and senior management

Learning Objectives

Upon the completion of automotive functional safety ISO 26262 training, the attendees are able to:

• Understand the details of ISO 26262
• Identify how the scope of ISO 26262 applies to their system
• Develop a Safety Case plan complying ISO 26262
• Respond to Development Interface Agreement compliant to ISO 26262
• Define the safety goals and Automotive Safety Integrity Level (ASIL)
• Determine the HW requirements based on ASIL
• Determine the SW requirements based on ASIL

Course Outline

Overview of the ISO 26262

• Origin of ISO 26262
• France and Germany pre-standard activities
• National Academy of Science expectations
• Differences of ISO 26262 with IEC 61508
• How ISO 26262 affect automotive development
• Planning
• System
• Hardware
• Software
• Operations
• Supporting processes
• ASIL-oriented and safety-oriented analyses
• Management of functional safety (part 2)
• Documentation management system (part 8)
• Production and operation (part 7)
• Supporting processes (part 8)
• Integration of ISO 26262 with ISO 9001 or ISO/TS 16949

 Functional Safety Management (Part 2)

• Planning, coordinating, and documenting activities associated with functional safety
• Executing management plan for all stages of the safety life cycle, including:
  • Project-independent functional safety management activities
  • Safety management during development
  • Safety management after Start of Production (SOP)

 Project-Independent Functional Safety Management Activities

• Safety culture
• Quality management
• Continuous improvement
• Training and qualification
• Application of the life cycle

Requirements of Safety Management

• Organizational measures to achieve functional safety
• Management of functional safety after SOP
• Field monitoring and collection of data
• Malfunction survey
• Malfunction analysis
• Malfunction solution

Work Products, Part 2

• Company internal standard for functional safety
• Training and qualification programs
• Quality management system
• Safety plan
• Overall project plan
• Safety case
• Results of the confirmation measures
• Confirmation plan
• Functional safety assessment plan
• Evidence of a field monitoring process

Concept Phase (Part 3)

• Hazard analysis and risk assessment
  • Vehicle usage
  • Environmental conditions
  • Foreseeable driver use and misuse
  • Interaction between vehicle systems
• Safety requirements
  • A safety goal is to be identified for each hazardous event evaluated in the hazard analysis
  • ASIL identified for the hazardous event is to be allocated to the associated safety goal
  • Potential hazard may have more than one safety goal
  • If similar safety goals are identified, they can be mixed with one safety goal that will be assigned the highest ASIL of the similar goals

Work Products, Part 3

• Item definition
• Effect evaluation
• Hazard analysis and risk assessment
• Safety goals
• Review of hazard analysis, risk assessment and the safety goals
• Functional safety concept
• Review of the functional safety requirements

Product Development, System Level (Part 4)

• Determine and plan the functional safety activities for each sub-phase of system development
• Uses to both systems and subsystems
• Requirement of the technical safety requirements
  • Define system properties
  • Identify other functional and non-functional requirements
• System design and technical safety concept
  • Requirements for inhibiting systematic failures
  • Requirements for the control of random hardware failures during operation
  • Assign each technical safety requirement to hardware, software, or both
  • The hardware – software interface (HSI)
  • Requirements for production, operation, service, and decommissioning
  • Development at the hardware and software levels
• Item integration and testing
• Safety validation
• Functional safety analysis
• Preparing for production

Work Products, Part 4

• Project plan
• Safety plan
• Validation plan
• Functional safety evaluation plan
• Technical safety requirements specification
• System level verification report
• Technical safety concept
• System design specification
• Item integration and testing plan
• Requirements for manufacturing, operation, service, and decommissioning
• HW/SW interface specification (HSI)
• Integration testing specification
• Integration testing report
• Validation report
• Functional safety assessment report
• Production report

Product Development: Hardware Level (Part 5)

• Determining relevant safety life cycle phases for item hardware engineering
• Determining Hardware safety requirements
• Designing hardware, protecting for safety concerns
• Analyzing architectural constraints
• Assessing possibility of violation of a safety goal
• Hardware safety integration and test

Assessing Possibility of Violation of A Safety Goal

• Probabilistic method for random hardware failure
• Residual risk analysis method

Work Products, Part 5

• Project plan
• Safety plan
• Hardware safety requirements specification
• Hardware architectural measurement requirements
• Random hardware failure requirements
• Hardware-software interface specification
• Hardware safety requirements verification report
• Hardware design specification
• Hardware safety analysis report
• Hardware design verification report
• Requirements for production and operation
• Evaluation of the effectiveness of the system architecture to face with the hardware random failures
• Review report of assessment of the effectiveness of the system architecture to face with the hardware random failures
• Evaluation of random hardware failures
• Specification of dedicated measures
• Review report of evaluation of violation of the safety goal due to random HW failures
• Hardware integration and verification report

Product Development: Software Level (Part 6)

• Planning
• Lists requirements to be satisfied for each phase of the software development life cycle
• ASIL of software safety requirements flows down
• Requires qualification of software tools used for software development (Part 8 Clause 11)
• Determines standards to be addressed in design and coding guidelines
• Software architectural design
  • Gives requirements for notations for SW architectural design
  • Design principles to use to accomplish modularity, encapsulation, minimum complexity
  • Allocates SW safety requirements to the SW components
  • Safety analysis (Part 9-8) applied to the software architecture
  • Requirements for addressing error detection
  • Requirements for addressing error handling
  • Specifies verification requirements
• Software unit design and implementation
• Notation requirements based on ASIL
• Software unit testing
• Verification of software safety requirements

Work Products, Part 7

• Safety plan
• Software verification plan
• Design and coding guidelines for modeling and programming languages
• Software tool application guidelines
• Software safety requirements specification
• Hardware-software interface specification
• Software verification plan
• Software verification report
• Software architectural design specification
• Safety analysis report
• Dependent failures analysis report
• Software unit design specification
• Software unit implementation
• Software verification specification
• Embedded software

Production and Operation (Part 7)

• Determines requirements on production, operation, service, and decommissioning
• Production objectives
• Planning
• Requirements for production

 Work Products, Part 7

• Production plan
• Production control plan
• Documentation of performed control measures
• Requirements of hardware or software development level
• Evaluation report for capability of the production process
• Maintenance plan
• Repair instructions
• User manual
• Instructions regarding field observations
• Instructions for decommissioning
• Requirements associated with operation, maintenance and decommissioning at system, hardware or software development level

Supporting Processes (part 8)

• Distributed development
• Specification and management of safety requirements
• Configuration management
• Change management
• Verification
• Documentation
• Qualification of software tools
• Qualification of software components
• Qualification of hardware components
• Proven in use argument
• Existing engineering processes

Work Products, Part 8

• Supplier selection report
• Development interface agreement
• Supplier’s project plan
• Supplier’s safety plan
• Safety assessment report
• Supply agreement
• Change management plan
• Change request
• Impact analysis
• Change request plan
• Change report
• Proven in use credit
• Definition of candidate for proven in use argument
• Proven in use analysis reports
• Qualification plan
• Hardware component testing plan
• Qualification report

ASIL-Oriented and Safety-Oriented Analyses (Part 9)

• Requirements decomposition with respect to ASIL tailoring
• Criteria for coexistence of elements
• Analysis of dependent failures
• Safety analyses

Work Products, Part 9

• Updated architectural information
• Update of ASIL as attribute of safety requirements and elements

ISO 26262 Tools

• FMEA
• DFMEA
• FTA
• Difference between qualitative and quantitative FTAs in the context of ISO 26262
• DFA
• DRBFM

ISO 26262 Auditing

• Managing audits
• How to scope a ISO 26262 audit
• Audit planning – different scenarios
• Opening meeting
• Conducting an audit to ISO 26262
• Writing non-conformances
• Closing meeting
• Corrective action and close outs
• Scope and audit planning for an ISO 26262 analysis
• Conducting FSMS evaluation
• Evaluation vs confirmation measure

Tonex Sample Hands-On Workshop

• Bringing in a project from your organization, or work on the real-world scenario provided by the instructor
• Practicing parts 2-9
• Documenting each step
• Going through all the work products for each part
• Presenting the result to the class

Automotive Functional Safety ISO 26262 Bootcamp Training