Automotive Functional Safety ISO 26262 Training Course Description
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.
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
ISO 26262 is the new automotive application standard for functional safety IEC 61508 that impacts the whole product lifecycle. 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 26262requirements.
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
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
Overview of the ISO 26262
- Origin of ISO 26262
- France and Germany pre-standard activities
- S. impact on the standard
- 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
- Planning, coordinating, and documenting activities associated with functional safety
- Executing management plan for all stages of the safety lifecycle, including:
- Project-independent functional safety management activities
- Safety management during development
- Safety management after Start of Production (SOP)
- Safety culture
- Quality management
- Continuous improvement
- Training and qualification
- Application of the lifecycle
- Organizational measures to achieve functional safety
- Management of functional safety after SOP
- Field monitoring and collection of data
- Malfunction survey
- Malfunction analysis
- Malfunction solution
- 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
- 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
- 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
- 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
- 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
- Determining relevant safety lifecycle 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
- Probabilistic method for random hardware failure
- Residual risk analysis method
- 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
- Planning
- Lists requirements to be satisfied for each phase of the software development lifecycle
- 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
- 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
- Determines requirements on production, operation, service, and decommissioning
- Production objectives
- Planning
- Requirements for production
- 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
- 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
- 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
- Requirements decomposition with respect to ASIL tailoring
- Criteria for coexistence of elements
- Analysis of dependent failures
- Safety analyses
- Updated architectural information
- Update of ASIL as attribute of safety requirements and elements
- FMEA
- DFMEA
- FTA
- Difference between qualitative and quantitative FTAs in the context of ISO 26262
- DFA
- DRBFM
- 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
- 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
Learn More:
Comments
Post a Comment