Which Tools Should I Use for ASIL D Requirement Management ISO 26262/IEC 61508?

There is 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 Automotive Safety Integrity Level (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 Hazard Analysis and Risk Assessment (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 existing 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 NI (previously known as 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
• NI Tools: Automated test and test scripting

By combining engineering best practices with the tools’ strengths and considering an organization’s main drivers, a workflow can be defined as one that optimizes tool usage and reduces the load on engineers. Ultimately, to be successful in 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 spending that can otherwise be avoided.

Get Started Today

Takeaways

• 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 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, and 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 user interface (UI) will have to be developed to allow for 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 of 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
  • JAMA Software reports
  • JIRA reports
  • Requirements gap analysis
  • Test coverage gap analysis
  • Requirements Traceability Matrix
  • Bug reports
  • Customized reports
• Since the REST APIs produce a consumable output, any reporting tool that can consume XML/JSON can be used to produce reports.