Connectivity changes the notion of the development process ending when a product is launched, or even when its production is ended. Whenever a new vulnerability is discovered in the field, there is a resulting change of requirement to address it – and in safety critical applications, a speedy response to requirements change has the potential to save lives. This shines a whole new light on automated requirements traceability.

Many embedded applications have traditionally been isolated, static, fixed-function, device-specific implementations, and practices and processes have relied on that status. There’s lots to learn for developers in our newly connected world. Domain separation, secure boot, defence-in-depth … all rocking the ordered worlds of many a development team.

But perhaps the biggest upheaval is actually nothing to do with any of these new technologies per se, and instead is more concerned with the simple notion of “coming to the end of a project”.

Beyond development, connectivity gives system maintenance a new significance with each newly discovered vulnerability, because requirements have the potential to change after development – and not just throughout a production lifetime, but as for long as a product is out in the field.

Safe & secure application code development

The traditional approach to secure software development in enterprise environments is mostly a reactive one – develop the software, and then use penetration, fuzz and functional test to expose any weaknesses. Useful though that approach is, in isolation it is not good enough to comply with a functional safety standard. Consider ISO 26262 from the automotive sector as a typical example. It implicitly demands that security factors with a safety implication are considered from the outset, because a safety-critical system cannot be safe if is not secure.

A V-model illustrates the scale of the problem, by representing the software-related phases defined within ISO 26262 (Figure 1). Requirements, designs, coding standards, static analysis reports, unit test, code coverage analysis… each phase of this process model implies a host of design, development and test artefacts, in addition to the code itself and the tests that go with it. The principle of bidirectional traceability runs throughout, with each development phase being shown to accurately reflect the one before it and after it.

All of that would represent more than enough stress for the project management team even if everything always ran in a neatly sequential manner, in accordance with the theory of the process model. In that halcyon world, the exact sequence of the standard would be adhered to, the requirements would never change, and tests would never throw up a problem. But life’s not like that.

Figure 1: ISO 26262 V-model, and tools used to support it

Managing change during development… and beyond

Changes to requirements can come from a multitude of sources. What if the client has a change of heart? Their client has a new requirement? Or legal obligations change?

Should such changes become necessary, an impact analysis is required on all existing requirements, designs, code, and static and dynamic tests. Impacted code needs to be reanalysed statically, and all impacted unit and integration tests need to be re-run (regression tested).

Automated bidirectional traceability helps by linking requirements from a host of different sources through to design, code and test, and the artefacts that go with them (Figure 2). The impact of any requirements changes – or, indeed, of failed test cases – can be automatically assessed by means of impact analysis, and addressed accordingly by means of automated testing and analysis. As part of that process, artefacts can be automatically re-generated to present evidence of continued compliance to the functional safety standard of choice.

During the development of a traditional, isolated system, that is clearly 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 quite some time. In such circumstances, being able to isolate what is needed and automatically test only the functions implemented becomes something much more significant.

Figure 2: Automated bidirectional traceability with the TBmanager component of the LDRA tool suite

Connectivity changes the notion of the development process ending when a product is launched, or even when its production is ended. Whenever a new vulnerability is discovered in the field, there is a resulting change of requirement to cater for it, coupled with the additional pressure of knowing that in such circumstances, a speedy response to requirements change has the potential to both save lives and enhance reputations. Such an obligation shines a whole new light on automated requirements traceability.