Mountain Runner

Implementing Functional Safety

The Difference to "Conventional" Development as a List

Time to Read 2 min

The customer thinks your product is fantastic, she would just like to get it with a functional safety level: DAL, SIL, ASIL, PL ...just a few letters more in the requirements. What does the realization of functional safety mean for your R&D team? What do you have to do now if you want to fulfill the customers wish? If you read the according standards and still nothing is clear, you are not the only one...

Functional safety is not just another feature for the datasheet, like another sneaker color. Functional safety is more like a mountain marathon which makes demands on the whole development.

In this contribution I will provide a coarse list of the most important differences between such a functionally safe and a mere functional development. In a second, more elaborate contribution you can find the according details: Functional Safety Details . There you will also find explanations of the concepts and terms used below.

Basic Concepts of Functional Safety

  • Standards
  • „Use quality to manage risk”
  • Planning
  • Evidence
  • Traceability

What does the Engineer Do?

  • Safety Analyses
    • Hazard-/ Risk Analysis
    • Fault Tree Analysis (FTA)
    • Failure Modes and Effects Analysis (FMEA)/ Failure Modes , Effects and Diagnosis Analysis (FMEDA)
    • for:
      • System
      • Subsystem
      • Component
      • Function
  • Safety Measures
    • against random hardware failures
    • against systematic software failures
    • against systematic hardware failures
    • detection of latent faults
  • Requirements
    • V-Model
    • Requirements-Traceability
      • Traceability-Coverage Analysis
  • Verification
    • Reviews
    • Checklists
    • Tests
    • Code-Coverage Analysis
  • Standards
    • Requirement Standards
    • Design Standards
    • Coding Standards
  • Components
    • Quantitative Analysis (failure rates)
    • High-Reliability Components?
  • Tools
    • Tool Classification
    • Tool Qualification
  • Give and Accept Feedback

What does the Project Team Do?

  • Plans
    • Development Interface Agreement:
    • Safety Plan or Plan on Software/ Hardware Aspects of Certification
    • Verification Plan
    • Integration Plan
    • Configuration Management Plan
    • Quality Assurance Plan
    • Lead-Free Development Plan
    • etc.
  • Configuration Management
    • Releases
    • Storage
  • Change Management
    • Change Control Board
    • Traceability
  • Audits
  • Statements
    • Safety Case or Software/ Hardware Accomplishment Summary
  • Communication

What does the Company Do?

  • Processes
    • Work Instructions
    • Tools
    • Templates
    • Checklists
    • etc.
  • Level 3
    • Processes for the Entire Organisation
    • Processes Continously Improved
  • Safety Culture
    • Safety Before Commercial Aspects
    • Proactive Attitude towards Errors
    • Clear Plans
    • Traceable Responsibility
  • Keep It Simple

As you can see, there are quite a few things to to, if you have to guarantee functional safety. If you like to know more , please read the detailed contribution or contact me. We are also glad to support you with your safety project:

Andreas Stucki

Do you have additional questions? Do you have a different opinion? If so, email me  or comment your thoughts below!

Author

Comments

Good afternoon

My name is Flavio Di Francesco and I work in the QA group in my division within a semiconductor company.

I am interested in the SW Safety development processes/template/work product in according ISO 26262.

Regards

Dear Mr Di Francesco

See the separate Email I sent you.

What is Your Opinion?

* These fields are required

Projects? Ideas? Questions? Let's do a free initial workshop!