360 Requirements Traceability – A need for Industrial IoT Systems
Article by Chandana Kanth, Technical Consultant, LDRA India and Akshay Dixit, Sr. Account Manager, LDRA India
The IIoT market is expected to grow from USD 77.3 billion in 2020 to USD 110.6 billion by 2025, at a CAGR of 7.4% during the forecast period (2020-2025), as per the report by Markets & Markets1. The growth of the IIoT industry is driven by factors such as technological advancements in semiconductor and electronic devices, increased use of cloud computing platforms, standardization of IPv6, and support from governments of different countries for R&D activities related to IIoT.
The year 2020 was remarkable for all industries, including Industry 4.0. COVID-19 lockdown has led to new ways of Industrial Automation & Robotics as well as connectivity. Earlier in 2020, we never thought that we could carry out plant activities using remote access virtually. Now, we can directly access conveyor lines, production lines, stores, QA/QC lines and practically everything virtually.
The rapid growth of the IIoT industry and increased connectivity bring together the challenges for functional safety & cybersecurity, as traditionally, these systems were not designed keeping functional safety & cybersecurity requirements in mind. Therefore, it is crucial to identify and document functional safety & cybersecurity requirements early in the product development lifecycle and ensure that subsequent development artifacts are evaluated for compliance with those requirements.
Requirement traceability is an important aspect of requirement engineering. It focuses on ensuring that all the requirements have been met from planning, creation, maintenance, and use, with the ability to follow and check the life cycle of requirements in both forward and backward direction. In addition, traces and links should be maintained and used in the development process to keep track of different artifacts.
The software development model will help explain the phases of the project and how traceability will help in different levels of requirement like High Level Requirement (HLR), Low Level Requirement (LLR), Design, Source Code, Test cases and Test results. If any changes made to requirements, it would cause impacts to the associated test cases and other artifacts. Requirements for a software project is like the foundations of a building.
Requirement Traceability Matrix (RTM) is a document that links and maps user requirements with test cases to validate that all requirements are met via test cases, and no functionalities are unchecked during software testing and delivered at the conclusion of the software development life cycle. And it documents all requirements, tests, test results, and issues. The objective of the Requirements Traceability Matrix is to ensure that all requirements defined for a system are tested in the test protocols and recorded in a single document.
A requirement traceability matrix can:
- Capture the information of different requirements like System Level Requirement (SYS), High Level Requirement (HLR) and Low Level Requirement (LLR), Source Code and Test Cases along with the appropriate links.
- All requirements are mapped to the source code.
- The test cases derived from the requirements are run to generate a pass/fail report. This will ensure to maintain traceability between Requirements, Test cases and Test results.
- Using this, we can check whether all the functionalities have mapped and checked with specific requirements and no functionality are unchecked during software testing.
Importance of Requirement Traceability:
- It makes project management easy and helps in decision making.
- It helps to measure project progress and schedule.
- It helps in confidence-building and customer satisfaction.
- It assists in assessing the impact of change, risk and lowering them.
- It ensures that all requirements are met and simplifies project estimates.
- It creates an audit trail (traceability can be used to prove that requirements were implemented and tested).
- It helps to understand the relationship between requirements and the delivered system.
- It helps determine where a requirement came from, its importance, how it was implemented, and how it was tested.
Types of Requirement Traceability Matrix: In Software Engineering, the traceability matrix can be divided into four major components as mentioned below and showcased via. images:
- Forward Traceability: Forward traceability maps the requirements to the test cases; it ensures that every requirement is being tested from top to bottom.
- Backward Traceability: Backward traceability maps test cases with the requirements. It ensures that the scope is not changed, resulting in documented changes that might unnecessarily check back initial requirements.
- Bidirectional Traceability: Bidirectional traceability essentially combines forward and backward traceability into one document. This is useful because it establishes that each requirement has relating test cases.
- 360 Degree traceability: It combines forward, backward, and bidirectional traceability to avoid any requirement gaps. By doing so, we meet the stakeholder requirements, which helps a software project to be successful.
Challenges of Requirement Traceability
- The organization does not have a commitment to follow traceability practices. This leads to a weak practice of traceability, where traceability data is created and maintained without order or purpose.
- As a system grows, capturing the requirement, tracing becomes complex and expensive. To deal with the high cost of traceability is to practice value-based requirement tracing instead of full tracing.
- Need to maintain or update traceability data whenever a change occurs and follow the right discipline and effort.
- For development organizations, it is hard to know which traceability practices and tools are the most economical and in which situations they deliver the most.
- Need to apply and follow the right organization policy on traceability to apply uniformly to all projects.
- The process and tools need to establish traceability to be trusted and guarantee that the links are correct and complete.
Benefits of Requirement Traceability
- It provides a quick solution on impact analysis for risk, time and cost deviations.
- It makes it easy to identify the missing functionalities.
- If there is a change request for a requirement, we can easily find out which test cases need to be updated.
- It ensures that developers are not creating features that no one has requested.
- It reduces project risk, wastage of workforce, time, and effort.
- It saves time, costs, and effort during development.
- It helps to avoid quality and acceptance problems.
Standards demand Requirements Traceability: IEC 61508 and IEC 62443 are the widely accepted standards for functional safety and cybersecurity for industrial IoT systems, respectively. We are listing out some of the clauses related to requirements traceability below.
|Forward Traceability Technique/Measure defined in IEC 61508-3||SIL 1 & 2||SIL 3 & 4|
|Table A.1 – Forward traceability between the system safety requirements and the software safety requirements||
|Table A.2 – Forward traceability between the software safety requirements specification and software architecture|
|Table A.4 – Forward traceability between the software safety requirements specification and software design|
|Table A.5 – Forward traceability between the software design specification and the module and integration test specifications|
|Table A.6 – Forward traceability between the system and software design requirements for hardware/software integration and the hardware/software integration test specifications|
|Table A.7 – Forward traceability between the software safety requirements specification and the software safety validation plan|
|Table A.8 – Forward traceability between the Software safety requirements specification and the software modification plan (including reverification and revalidation)|
|Table A.9 – Forward traceability between the software design specification and the software verification (including data verification) plan|
|Table A.10 – Forward traceability between the requirements of Clause 8 and the plan for software functional safety assessment|
|Backward Traceability Technique/Measure defined in IEC 61508-3||SIL 1 & 2||SIL 3 & 4|
|Table A.1 – Backward traceability between the safety requirements and the perceived safety needs||
|Table A.2 – Backward traceability between the software safety requirements specification and software architecture|
|Table A.7 – Backward traceability between the software safety validation plan and the software safety requirements specification|
|Table A.8 – Backward traceability between the software modification plan (including reverification and revalidation)and the software safety requirements specification|
|Table A.9 – Backward traceability between the software verification (including data verification) plan and the software design specification|
Additionally, reference can be made to IEC 61508-6 Annex E, where two worked examples are given of SIL 2 & SIL 3 applications. It is illustrated how the above examples of forward & backward traceability can be selected/interpreted for these two SIL 2 & SIL 3 applications.
Clauses defined in IEC 62443-4-1:2018:
- Clause 3.1.14 demands traceability throughout the lifecycle.
- Clause 5.2.1b demands requirements definition with requirements traceability.
- Clause 8.3.1d demands review of security implementation and traceability to the security capabilities defined to support the security design.
Requirement Traceability is crucial to identify and document functional safety & cybersecurity requirements throughout the product development life cycle. To improve this process in the Industrial IoT system, we must focus on 360-degree requirement traceability. Standards such as IEC 61508 and IEC 62443 also demand requirement traceability. It is also essential to document functional safety and cybersecurity requirements throughout the life cycle and evaluate final artifacts for compliance.
Article by :
Chandana Kanth, Technical Consultant, LDRA India
With a Bachelor of Engineering in Information Science and Engineering from VTU, she started her career as a Software Engineer at Softtek India Pvt Ltd. As an FAE in LDRA, she is involved in integrating the development tools, debuggers and testing tools in the embedded domain. She has worked on the LDRA tool suite, point products, plugins and TLPs with the LDRA tool and is actively involved in technical support in assisting various customers.
Akshay Dixit, Sr. Account Manager, LDRA India
Akshay completed his MBA from Solapur University in 2012 and has more than 8 years of experience in industrial sales. He is currently handling India’s western region sales for LDRA. Before joining LDRA, he worked in the certification, testing and inspection industry for five years.