Most software developers are familiar with the need for and benefits of change control. Usually change control means one thing to a software developer and that is 'commits' to a source code revision control system. Not only do small and regular commits provide significant advantages to large teams of developers potentially working on the same or related parts of a project, it also means we can examine who made and who approved modifications to our code base. It also allows recent changes to be reversed and the code to be reverted to an earlier less-developed condition. This is useful for narrowing the list of changes that may be resulting in unwanted behavior to enable problem resolution.

The change control systems typically used for software change control are themselves software projects which also likely have versions and use a software change control system for the source code. In principal, every piece of software involved in a project pipeline could (and might already) exist in one or more version control repositories. Some of these might be proprietary and therefore privately held by third parties, while others might be available in the public domain also held managed by 3rd parties. Some of the code, including the primary product or application software, may be held locally.

Each change control system in use is likely built with yet more software tools and the executable code is created for a specific device or family of devices that we use to host the change control system. The computers used for creating software and the potentially different computers and equipment used for testing the finished software interim work products themselves have software loaded on them and the hardware consists of specific devices and equipment all with version numbers and compatibility and incompatibility complications.

In some industries the complexity of all these systems of software maintained at several different locations around the globe poses some significant concerns for engineers managing potential risks that may arise as a result of failure of individual parts of this supply chain or needing to urgently revert changes for some reason including external pressures. The commits to the project in the source code repository are only one piece of the configuration and generally it is expected that not only can we revert to an earlier known working (potentially previously deployed) version of a project but also be able to reproduce the object code and related and supporting artifacts including test results. In some cases, it might be the case that the 'latest' version of a build environment, automated testing script, or test fixture no longer supports an earlier version of the software under test.

Configuration management requires change control to be in place and is concerned with the state of the wider equipment used for software development and can potentially involve significant complexity determined by the extent of the build, test, deploy and decommissioning activities of a project.

ISO 26262 Part 8 has a very succinct objective for configuration management as follows:

• Ensure that the work products, and the principles and general conditions of their creation, can be uniquely identified and reproduced in a controlled manner at any time.
• Ensure that the relations and differences between earlier and current versions can be traced.

The automotive industry has a very mature process for managing configurations at scale. ISO 26262 (the automotive standard for functional safety) is quite happy to assume and build on that solid foundation. For industries who maybe aren't at that scale or maturity, IEC 61508 Part 3 provides some helpful guidance in addition to requiring change control.

Software configuration management shall maintain accurately and with unique identification all configuration items which are necessary including:

• safety analysis and requirements
• software specifications and design documents
• software source code modules
• test plans and results
• verification documents
• pre-existing software elements
• all tools and development environments which are used to create or test, or carry out any action on, the software

It is not unusual for Configuration Management to go beyond just software and hardware used for testing, simulating or stimulating a product and consider in scope the state of the known requirements, prior test results, field data and even legislation so that in the event of a catastrophic loss a complete picture of the state of development including what was known and not known can be recreated.

Are your software builds reproducible? Can you get the same test results on your products when you repeat the same tests? Will you be able to do that one year from now?

As I’ve been often reminded by a great customer ‘being able to do things in a reproducible way is all that matters.”

Thanks for reading this short blog. If you have questions or comments please leave them below or get in touch.