Skip to main content

Functional Safety: “Well begun is half done”


There is a saying that “Well begun is half done” which means a clearly understood scope of work and a well-defined plan makes the work easier. There are some key activities in Functional Safety that must be “Well begun”. Let us understand the key aspects of functional safety (FuSa) management in this article. 

The foundation and pillars must be strong to build a safe house. To build a safe 'Item', the foundation and pillars that must be strong are:

  1. FuSa Process
  2. DIA (Development Interface Agreement)
  3. Safety Plan
  4. Safety Case

The above picture represents a high-level Functional Safety framework. 

This Framework

  1. Starts with DIA – to define the scope of work
  2. Progresses with Safety plan – to define the strategy how to perform the work 
  3. Ends with Safety case – to argue the achievement of Functional Safety compliance.

This framework represents FuSa Process as the "Foundation" of FuSa Development, DIA as the Input to the Complete FuSa cycle and Safety Case as its Output. Safety Plan is responsible for the execution of the FuSa cycle and is hence represented as connecting the Input to the Output. Supporting processes helps with guiding specific activities at all development stages. The top right corner where Safety plan and Safety case overlaps each other is to show that safety plan tracks the progress of safety case and safety case includes the safety plan to argues the achievement of Functional Safety compliance. 

Let’s understand the pillars and foundation of this framework in greater detail.

FuSa Process

Defining a FuSa Process is the first step that an organization must take before starting a FuSa program. FuSa process is also the go-to place for Employees to understand FuSa activities. At a high level, the process shall ensure the various objectives mentioned in the picture below.

Engineers have a key role in the continuous improvement of the FuSa process by providing feedback about gaps and possible improvements. 

Development Interface Agreement (DIA)

DIA is an interface document between Customer and suppliers. The Customer vs supplier could be OEM vs Tier 1 or Tier 1 vs Tier 2, and so on. In simpler terms, this is a statement of work (SOW) agreed between Customer and supplier for FuSa.

DIA contains

  • FuSa related Point of contacts on both sides of the organization 
  • Deliverables required/performed during the development of Item/System/Element for the required ASIL level
  • Level of contents expected for each activity (for ex. Content level could be full report or summary only or content only presented over the meeting and so on)
  • Methods and Tools applied for each activity. For example, FMEA method is applied for safety analysis for ASIL B and uses Exida’s SILCal or Ansys Medini Tool.
  • Values of Hardware target metrics (if applicable). Value might either be considered from the standard or sometimes OEM will allocate a target value other than the standard based on their analysis, which supplier need to assess and agree.
  • Milestone of the Safety development lifecycle to be achieved for each or group of deliverables. Some of the key milestones are
    • Planning – Plan the activities to be performed at all the stages
    • Concept development – Consolidate the customer requirements and prepare system level concept
    • Component Design – Design and Implement the Components (Hardware/Software)
    • DV/PV (Design Verification and Process Validation) – Verification of design and production process validation
    • Launch – Mass production starts here.
  • RASIC (Responsible, Accountable, Support, Informed, Consult) for each activity. For example, Safety plan will be supplier’s responsibility and informed to customer.
  • Activities with shared responsibility. For example, 
    • For Item/System development, Safety validation will be done at vehicle level against safety goals. Then Customer and supplier shall mutually agree on the scope of the activity.
    • For Component development, the integration and testing of the component shall have shared scope between customer and supplier.
  • Details about Audit and Assessment. For example, the required independence level as per ISO 26262:2018 – Part 2.6.4.9 Table 1 based on the ASIL level. Based on ASIL level, Customer might appoint a 3rd party assessor/auditor or customer himself might perform or customer can ask the supplier to perform.

It’s the Safety manager’s responsibility to ensure that the list of agreed activities in the DIA reaches all the key stakeholders of the project.

Safety Plan

Safety Plan is an instrument to understand the process, methods, tools, strategies identified for a specific item/system/component FuSa development. “If DIA is a telegram which provides the scope in shorter terms, the Safety plan is an epic that elaborates all the steps required for the program to achieve FuSa compliance at the required ASIL level”. It connects the dots between DIA and FuSa Process.

Safety Plan includes

  • Safety Manager: Safety Manager Contact who is responsible for the program’s planning and execution of FuSa.
  • Tailoring of Safety activities: Each activity and its method/steps to be performed shall be tailored as
    • Standard – Activity as provided in the Organization process 
    • Tailored – Method/steps might differ in performing the activity. But the result remains same 
    • Omitted – Activity is not performed. This will be decided based on organizational process or ASIL level or re-use from previous program or SEooC or element not developed as per ISO 26262.
  • Resources and Methods: Methods (ex. FMEA for safety analysis; Requirement based testing, etc.), Tools (like Exida’s SILCal for FMEA and Ansys Medini Tool for FMEDA).
  • Confirmation Measures: Confirmation reviews, Audit and Assessment for each activity as per ISO26262 and their timelines
  • Planning: Allocation of responsible person, timeline and duration for each Safety activity at Safety Management/Systems/Hardware/Software/Manufacturing level based on applicability.
  • Project Members and their competence: The project members, their roles and competence in their respective FuSa domain. The competence level required for the program shall be ensured through training. The criteria to evaluate competence shall be defined at an organizational level.
  • FuSa Process: Reference to the Organizational process.
  • Supporting Process: Organizational specific supporting processes like configuration management, change management, quality management, etc.
  • Escalations: Process, criteria and contacts to escalate the FuSa related problems at both customer and supplier side.
  • SEooC: List of elements that are developed based on Safety element out of context (SEooC). Its related activities will be tailored accordingly.
Additionally, details about
  • Software Tool qualifications – List of tools used for FuSa development and their compliance.
  • Software component qualification – List of QM SW elements planned to re-use without modification.
  • Hardware element evaluation – List of HW elements planned to use that are not safety compliant.
  • Proven in-use argument – List of elements planned to re-use based on confidence from field data.
  • Impact Analysis – Impact Analysis when there is change in the Item/System/element and the safety plan is refined for the impacted activities.
Key Notes:
Safety plan is a kind of internal SOW for FuSa. The Safety manager shall ensure the safety plan is reviewed and concurred by all the stakeholders.
Safety activities are not an independent or isolated activity. It shall be added into the overall project plan and the project management team who is responsible for overall project shall also ensure the execution of FuSa at project level.

Safety Case

If you are wondering why Safety Case is mentioned in the context of a good safety planning, hold on! While “Well begun is half done”, “Well done is better than well said” as another quote by Benjamin Franklin goes. The Safety case demonstrates the outcome of good Safety planning.

Safety case is a compilation of work products to provide arguments for the achievement of functional safety compliance for provided safety goals and safety requirement. The argument has two types, one is Product argument which argues safety through technical measures (for ex. Watchdog) and the next is process argument which argues through process compliance. 

The safety case contains,

  • The list of work products (i.e. evidence) that are agreed in the DIA with customer with the agreed level of content (for ex. Full report or summary only, etc.) and according to the safety plan.
  • Provides high level objective, strategy and argumentation of compliance w.r.t ISO26262 for each activity. (argument means how did we achieve safety compliance by each activity)
  • Document Names with location, version, date of execution and status for each activity

Summary

This article is an attempt to summarize the key activities of Safety Management and the Intent behind it. Lack of awareness of Functional Safety and its activities at the quote stage is one of the main reasons for failures/delays in executing Functional Safety programs. To overcome this, the activities related to FuSa management shall be understood and considered in the quote. 

We recommend Engineers who are interested in understanding the FuSa process and its Intent, to use this article to understand the FuSa Management activities of your organization and examples specific to your program.

Labels: