The principle of bi-directional traceability runs throughout the V-models referenced in DO-178C, IEC 62304 and ISO 26262, with each development phase required to accurately reflect the one before it. In theory, if the exact sequence of the standard is adhered to, then the requirements will never change and tests will never throw up a problem. But life’s not like that.

For example, it is easy to imagine these processes as they relate to a green-field project. But what if there is a need to integrate many different subsystems? What if some of those are pre-existing, with requirements defined in widely different formats? What if some of those systems were written with no security in mind, assuming an isolated system? And what if different subsystems are in different development phases?

Then there is the issue of requirements changes. What if the client has a change of heart? A bright idea? Advice from a lawyer that existing approaches could be problematic?

Should changes become necessary, revised code would need to be reanalysed statically, and all impacted unit and integration tests would need to be re-run (regression tested). Although that can result in a project management nightmare at the time, in an isolated application it lasts little longer than the time the product is under development.

Connectivity, with its inherent need for security, changes all that. Whenever a new vulnerability is discovered, there is the potential for a resulting change of requirement to cater for it, coupled with the additional pressure of knowing that a speedy response could be critically important if products are not to be compromised in the field. Indeed, many IoT systems are difficult to patch once in service.

Automated bi-directional traceability links requirements from different sources through to design, code and test. The impact of any requirements changes – or failed test cases – can be assessed by impact analysis and addressed accordingly. Artefacts can be automatically re-generated to present evidence of continued compliance to the appropriate standard.

During the development of a traditional, isolated system, that is useful enough. But connectivity demands the ability to respond to vulnerabilities because each newly discovered vulnerability implies a changed or new requirement, and one to which an immediate response is needed – even though the system itself may not have been touched by development engineers for some time. Being able to isolate what is needed and automatically test only the functions implemented becomes much more significant.