How to Choose the Right Tool for ASIL D Requirement Management ISO 26262 / IEC 61508

Editor’s Note: This posts on tool selection around ASIL D requirement management for ISO 26262 / IEC 61508 was originally published here by LHP Engineering Solutions and written by Steve Neemeh. When the options for choosing a requirements management tool are endless, what factors should you be looking at to help make your decision? This article provides some concrete considerations you may use to guide your selection.

Which tools should I use for ASIL D requirement management ISO 26262 / IEC 61508?

There are a multitude of requirements management tools in the marketplace (e.g., IBM DNG, Siemens Polarion, Jama Software, Helix). How does an organization make the important decision of which is best for its needs when the options are endless or when using Microsoft Word/Excel or Google Docs for requirements management can be considered? Is there even one tool that can meet all of the organization’s needs? This blog will describe why selecting a tool based on one specific departmental need, such as requirements management, might be impractical.

To begin the search, here are five items that might be considered:

1. Cost of Tools

• The range of costs can vary significantly. For a small organization, some of the larger toolchains may not be affordable. On the other hand, some of the smaller tools may not address parts of requirements management that are critical for ASIL D development.

2. Size and Distribution of the Organization

• How many engineers need the tools and in how many locations? Some license agreements are floating so utilization could be optimized if the tools are used across multiple time zones (e.g. India and USA).

3. Number of Requirements and Requirements Hierarchy

• Are there 100 safety-critical requirements or 5,000? Out of these requirements, how many of them are related to software, hardware, or test cases? How large is the HARA and how many safety goals are there? This will define the size of the requirements hierarchy.

4. Existing tools

• The selection and integration of a new tool will inevitably impact the use of the exiting toolchains.

5. Full ISO 26262 workflow

• Refer to V diagram.

LHP’s requirements management V diagram for the Application Lifecycle Management toolchain

When researching tools for an organization, it is a common discovery that there is not one tool that meets all of the needs. The tools industry has not caught up with the complexity of the safety lifecycle. What is found in the marketplace are versions of Application Lifecycle Management (ALM) tools, but what is really needed is an LHP ecosystem-based Safety Lifecycle Management (SLM) toolchain. This SLM is based on guidelines for safety-critical development as defined in the 700+ pages of requirements, work products, and methods in standards such as ISO 26262 or the Safety of The Intended Functionality (SOTIF).

What is the Workflow for Functional Safety, ASPICE, and Other Safety-Critical Applications?

The V diagram covers the foundational items that need to be considered in addressing a standard like ISO 26262: project management, task management, and change management. In this particular case, four tools have been considered: ANSYS Medini, Jama Software, Atlassian JIRA, and National Instruments. All four tools provide partial solutions to meeting the needs of functional safety.

• ANSYS Medini: HARA and systems-level modeling, as well as hardware metrics calculations (Parts 3 & 5 of ISO 26262)
• Jama Software: Requirements management (required by ISO 26262, emphasized in Part 8)
• Atlassian JIRA: Project management and change management
• National Instruments Tools: Automated test and test scripting

By combining the engineering best practices with the tools’ strengths and considering an organization’s main drivers, a workflow can be defined; one that optimizes tool usage and reduces the load on engineers. Ultimately, to be successful within safety-critical development, an organization needs to develop against a standard while also reducing the labor associated with engineering and testing.

Without the latter, the cost and time for development escalate exponentially. Are engineers going to copy and paste data across tools? Are they going to have multiple versions of the same information across different toolchains? As the complexity of systems increases, a non-optimized toolchain can paralyze an organization and its development process.

In the absence of a commercial off-the-shelf fully-compliant SLM tool, the solution of integration tools can provide the same functionality. For this purpose, the tools provide methods of connectivity with REST (Representational State Transfer) API. An example of a REST API between Jama Software and JIRA is shown in the appendix.

Conclusion

When selecting a requirements management tool, it is crucial to consider the needs of the organization as a whole, the safety workflow, and the customization and connectivity for optimization of the tools. In a typical implementation of a safety-critical system, most organizations just consider one, or parts of one, of these critical items, causing large rework and tool spend that can otherwise be avoided.

Take-a-Ways

• There is no one tool that meets the needs of requirements management in compliance with functional safety.
• The tool capability varies greatly based on cost, and there is feature overlap between tools.
• The holistic organization, not just a single department, needs to be involved in making the tool selection. The needs of each department: management, engineering, IT, manufacturing, regulators, and even certification agencies all must be considered.
• The tool must be appropriate for the size and scale of the organization.
• There are methods of automating data transfer that significantly reduce labor and cost on development programs (as shown in the appendix).
• Successful organizations are going to get ahead by creating efficient workflows that allow them to release products faster and more economically in the new electric vehicle/autonomous vehicle (EV/AV) world of transportation.

Appendix: More Details About REST API

Both Jama Software and JIRA provide access to their cloud resources via Representational State Transfer (REST API). REST is a web-based application programming interface that exposes a set of Uniform Resource Locators (URLs) with which to carry out Create, Read, Update, Delete (CRUD) operations in the tool. LHP Engineering Solutions has implemented a Domain Object Model (DOM) connection for both Jama Software and JIRA with a third integration piece to connect the two. The integration piece is a configurable application that implements the customer use cases.

Benefits of Using REST API

• Ease of implementation
  • REST is a standard specification of how to access web resources
  • All web and cloud-based tools expose REST APIs
  • Returns data, as well as metadata, which allows for conditional and iterative processing
  • Implemented in a JAVA wrapper making it configurable and portable to any system
• Customizable authentication feature
  • Simple user and password authentication if desired
  • Simple user and access token authentication if more security is desired
  • OAuth authentication is also available but not required
• Portability of output to Web and other tool frameworks
  • XML/JSON that any tool can consume
  • XML/JSON are standard serialized data formats for web resources
  • Web applications typically take XML/JSON as input files for data exchange, data migration, report building, etc.

REST API Complexities

• Requires a non-standard mapping of attributes from Jama Software to JIRA and vice-versa. Each customer mapping will need to be customized.
  • The REST specification defines what the API should do but not how it should do it. No standardization of data schema. Therefore, tools will have disparate data models.
  • Attribute A in Tool A must be mapped via a mapping file to Attribute B in Tool B etc. This goes for attributes, links, attachments, and all data elements in each data model.
  • A UI will have to be developed to allow for the mapping creation and management.

Standard Feature Set of REST API

• Mapping and transfer of attributes and attachments from one tool to the other
  • Data models are mapped as closely to 1:1 as possible
  • UI to build and manage mappings
• Scheduled and on-demand synchronization
  • Synchronization data between toolsets via UI
  • Synchronize data between toolsets by scheduling a task
• Intermediate transformations (e.g., risk calculations)
  • Calculating or transforming the data from the source tool before reaching the target tool
• Linking from one tool to the other via hypertext links
  • URLs from source resources to target resources and vice versa for traceability
• Reports
  • Since the REST APIs produce a consumable output, any reporting tool that can consume XML/JSON can be used to produce reports.
    • Jama Software reports
    • JIRA reports
    • Requirements gap analysis
    • Test coverage gap analysis
    • Requirements Traceability Matrix
    • Bug reports
    • Customized reports