Functional Safety (FuSa) of Electronics and Software According to IEC 61508 and ISO 26262

• Functional Safety: Basics and Introduction
  • Terms and definitions
  • Purpose of norms and international standards
  • Safety related functions and their integrity
  • Example systems
  • Definition and components of risk
  • Types of fault and failures
  • Relationship to legislation
• Base Norm IEC 61508
  • Objectives and applicability
  • Integrity levels (SIL)
  • Documentation in focus
• Safety Lifecycle According to IEC 61508
  • Phases and meaning
  • Requirements
  • Verification
  • Assessment
  • Management of functional safety
• Overall Aspects of ISO 26262
  • Risk assessment based on factors
  • Normative references
  • Safety plan and safety case
  • Development Interface Agreement (DIA)
  • Configuration management
  • Change management
  • Verification
  • Documentation
• Hazard Analysis and Risk Assessment (HARA) According to IEC 61508
  • Required input
  • Required risk reduction
  • SIL and failure rates per operational mode
  • Common cause failures
  • ALARP method
  • Risk classification
  • Quantitative SIL determination
  • Risk graph (incl. exercise)
  • Hazardous event severity matrix (qualitative)
  • Layer of protection analysis (example)
• Aspects of HARA According to ISO 26262
  • Classification by severity, exposure and controllability
  • Automotive SIL (ASIL)
  • Risk matrix
• System Design According to IEC 61508
  • Allocation of safety requirements
  • Effects of dependencies
  • Functional requirements
  • Integrity requirements
  • Architectural constraints
  • Hardware fault tolerance (HFT)
  • Safe failure fraction (SFF)
  • Quantification of effects of random hardware faults
  • Proven in use argumentation
  • Synthesis of elements
  • Requirements on data communication
  • Dangerous faults and required actions
  • Failure analysis
• Safety Related Hardware as per ISO 26262
  • Required quantitative assessments
  • Probabilistic metric for random hardware failures (PMHF)
  • Single point fault metric (SPFM)
  • Latent fault metric (LFM)
  • Qualification of components
  • ASIL decomposition
• Software Safety Lifecycle as per IEC 61508
  • Hardware/software interface (HSI)
  • Additional requirements for managing software
  • Software architecture
  • Support tools and programming languages
  • Test and integration
  • Modification process
  • Verification of inputs and outputs according to the development process
• Select Software-Related Aspects of ISO 26262
  • Modifications
  • Structural metrics
  • Tool classification and qualification
• Example of a Microcontroller with Integrated Safety Measures
• TOP 5 Dos and Don'ts
• Note:
  • An interactive and individual assessment of the learning progress is performed for each chapter; results are available at real-time and as pfd file.

Lernziele

• Learn about pre-requirements from management at company level and project management to achieve functional safety of electronics and its related software according to the state of the art.
• The training course Functional Safety teaches basics of functional safe systems in the area of embedded systems. It covers items from terms and definitions to objectives of safety in relationship to the basic norm IEC 61508
• Specifics of the related norm for automotive vehicles ISO 26262 are discussed in alternating fashion. The training also allows to apply the learned methods generically and according to other norms or standards.
• YOUR ADVANTAGES:
• Intensive jump start into the topic of Functional Safety
• Refresh and intensify your knowledge
• Training certificate for participants as to comply with the related standards
• Effective preparation for potential exams
• You can use the training documentation as a compendium

Zielgruppe

• Die Funktionale Sicherheit Schulung richtet sich vorrangig an Personen mit übergeordneter Verantwortung bzw. Tätigkeit im Bereich Safety. Dazu gehören Personen im Management im Allgemeinen und SafetyManager oder Projektmanager im Besonderen. Wichtige Adressaten sind Prozess-Ingenieure und Methoden-Ingenieure sowie Systemingenieure, Systemarchitekten und Systemdesigner. Reine Entwickler auf Umsetzungs- und Implementierungsebene sind praktisch nicht betroffen, profitieren aber allgemein durch besseres Verständnis safetyrelevanter Themengebiete, was auch Teil eines Anforderungsprofils ist.

Voraussetzungen

• Experience with control electronics (embedded systems)