Traceability Of Functional Safety Requirements In Automotive IP And SoCs

By Shivakumar Chonnad, Vladimir Litovtchenko, and Rohit Bhardwaj

Developing functional safety systems, including all the components such as the system-on-chip (SoC) and IP, hinges on the ability to meet the stringent automotive functional safety requirements such as definition, implementation, verification, and validation. Depending on the Automotive Safety Integrity Level (ASIL), the functional safety requirements can vastly change.

While development methodologies for meeting the requirements for automotive functional safety applications, such as advanced driver assistance system (ADAS), infotainment, and autonomous driving, have been defined by standards like ISO 26262, IEC-61508, and DO-178C, the SoC and IP for such applications need an effective systematic approach to managing functional safety requirements. Having a requirements management flow in place that traces these functional safety requirements during the various steps ensures safe, timely, cost- effective, and efficient products. Without such traceability, the likelihood of missing some of the requirements is really high, which can lead to costly project iterations.

The functional safety requirements flow, as defined by the ISO 26262 standard, begins at the item level. The high-level requirements are then refined and funneled to the next level of system requirements, which are then allocated and distributed into a set of requirements for the hardware and software components. These hardware and software requirements also define the requirements for the SoC and IP blocks. Figure 1 shows a typical functional safety requirements flow for an automotive application, highlighting all levels of requirements from the OEM to the IP developer.

Figure 1: Functional safety requirements flow from supply chain to IP developer

Functional safety requirements flow with traceability
Automotive products require complex and automated requirement-based flows as well as requirement management. Traditional approaches have been using manual or tool-based checklists that have proved to be ineffective and error prone. Modern automotive products are developed by many distributed teams across the globe. Automotive designers use IP and service providers to make common requirements-based development flows. These automotive products need an unambiguous requirements management flow as a key part of the overall product development. The requirements management flow applies at all levels starting from the item definition (a system or a car) to the design structure at RTL and/or gate level which also include their verification, validation, and evidence collection for defining a final safety case of a product. However, the overall challenge for automotive functional safety systems is the traceability of the safety requirements. According to the ISO 26262 standard[1], “Safety Requirements shall be traceable with a reference being made to:

A. each source of a safety requirement at the next upper hierarchical level;
B. each derived safety requirement at the next lower hierarchical level, or to its realization in the design; and
C. the verification specification.”

Designers must implement a solution that includes a requirements management process which specifies the following key steps:

• Defining the requirements from the top level down
  • Passing these requirements through the various levels of abstraction
  • Including requirements traceability as part of the project requirements and reviews
• Allowing a bi-directional relationship established in the requirements and status
• Accessing a tool-based flow where the users can define requirements and update status

Having a requirements management process that follows the above key steps will help in meeting the overall functional safety requirements flow with traceability.

Defining the requirements from top level down
Requirements awareness and management need to begin early in the IP and SoC design phase including concept and planning. Requirements are collected early and used further for specification development and refinement. Each requirement defined at higher levels must be allocated to an element of a specification. The requirements address the ‘what is the product/solution trying to address’ i.e., at a functional level, and the specification addresses the ‘how to achieve’ the requirements i.e., at the level of interfaces, etc. At a minimum, a good requirements definition will need to consider the following factors:

• Level of abstraction: Depending on the hierarchy where the requirement is defined, it can be at the top-level or a sub-level along the way through the last level.
• Classification: Since the requirement can be of potentially different types i.e., functional, non-functional such as safety, timing, hardware, performance, etc., it is useful to classify the requirement into the right category based on the level of abstraction i.e., system, software, hardware, etc.
• Clarity of definition: The requirement should be concise, consistent, correct, realistic, verifiable, have measurable metrics specified with the right units, and be mappable to specific task and owner. Use of right terminology like ’shall’ instead of ‘could’ makes a difference in the interpretation.
• Traceability: The requirement should be traceable including its inputs and the outputs on who the consumer will be when the requirement is satisfied.
• Relationships: When there are multiple requirements that are interdependent, the relationships and gating of these requirements should be clearly specified. Requirements definition can be specified in many formats, such as documents, spreadsheets, and relationship diagrams. Today, there are good software tools that intake the requirements through a graphical user interface or other import mechanisms.

Bidirectional requirements management flow
The requirements flow from the definition to fulfillment undergoes different phases as shown in Figure 2.

Figure 2: Bidirectional requirements management flow phases

As shown in Figure 2, there are four phases of bidirectional requirements management: intake, analyze, implement, and validate. During the intake phase, the requirements are sought from the various sources, though there could be more sources such as meeting specific requirements of a standards specification like USB or PCI Express or a customer defining the response time. It is important at this stage to identify what requirements should be pursued and what shouldn’t, which is usually considered by a change management and is in consensus with stakeholders and the sources that define the requirements. The classification of the resources based on the various categories or the different levels of abstraction can be identified in this phase.

Tool-based flow
A good software tool should specify, interlink, analyze, manage, display, and report the requirements traceability, giving clear visibility throughout the development process. The tool can easily identify if a requirement is floating and unrelated, for example, if it is an orphan item due to a missing upstream requirement or is missing a coverage towards a downstream requirement. In a safety related project, fulfilling the requirements traceability can help decide whether the safety case for the product has been achieved.

An example of a safety requirement template which includes requirement property fields is shown in Figure 3. This example shows a functional safety requirement using Jama and a project-specific configuration for functional safety development flow.

Figure 3: Example of a Functional Safety Requirement in Jama using template with fields

Conclusion
Requirements flow and requirements management process are the essential elements that contribute to product quality while ensuring the target goals for functional safety products are achieved and covered by the required verification methods. Having a good requirements management system as a quality process can help organizations achieve higher goals like the ISO 9001 certification.

Synopsys has the requirements management process for design of our automotive-grade processor, interface, foundation, and analog IP solutions.

To read the full white paper, Best Practices for Traceability of Functional Safety Requirements In Automotive IP & SoCs, visit: https://www.synopsys.com/dw/doc.php/wp/Automotive_Functional_Safety_Requirements_WP.pdf.

References
1. ISO-26262, Second edition 2018-12, Part 8: Management of functional safety, section 6.4.3.2

Shivakumar Chonnad is a functional safety engineer at Synopsys.

Vladimir Litovtchenko is a functional safety engineer at Synopsys.

Rohit Bhardwaj is a functional safety engineer at Synopsys.