Software Configuration Management

May 6, 2009

Many high tech products these days cannot work without software that controls specific (user) functions of the product. Take your car; engine functions that were traditionally mechanically controlled have now been replaced by devices and capabilities that are managed by software. Also when you travel to your vacation destination by air the very plane you are flying in is loaded with software to control for example the avionics or the (glass) cockpit instrument panel. Recently I was asked to consult for a client that had configuration management issues regarding software installed in their product. They had challenges to manage the appropriate version of the software in relation to the hardware configuration and also assuring that certification results were correctly captured. A further challenge was the collaboration with partners that actually does the software development and the maintenance. Our recommendation consisted of the following set of improvement initiatives and functions.

First of all, we recommended a digital collaboration platform with a key software vendor to stop software from being either distributed on CD or send by email in cases of urgency. When we met the client the cycle of submission of the request to the resolution was far too long; days rather than hours, specifically in the early days of the product when there were many iterations it was ‘chaos’. The collaboration platform also serves as the vehicle to register the vendor ‘Work Request’…. no, not email. The platform sends notifications if such requests have been submitted. The vendor then starts the process to verify the supporting material of the work request. With supporting material we for example mean the work schedule, the (amended) requirement specification(s) and also test procedures to be followed.

The second recommendation was to expand the core PLM functions such that it could manage software as a ‘part’ and because the client already managed the hardware configuration in the product structure we had the foundation to manage the software as an extension to the available functions. You have to appreciate that the hardware may not only have installed software but also embedded software i.e. binary firmware flashed to integrated circuits.. Managing software as a part also brought capabilities to register the relevant software file set. This ‘set’ is a copy of the files as managed by the vendor software configuration management solution.

Third, we worked with the client to understand the configuration management operational challenges and from there we recommended a solution regarding the hardware-to-software and software-to-software relations that were critical to managing the product configuration. We further identified a series of reports in line with CMII configuration management principles. Key to this recommended approach is the integrated discrepancy capture and the linked change management process. With the latter we recommended concepts that would allow the establishment of a (released/certified) Product Baseline to track hardware-software compatibility management aspects.

Fourth, we had to overcome data management challenges in the verification process, i.e. the V-model I referred to this several times in other blog posts. The verification process is critical to verifying that the new software release (still) works under the conditions as specified. In the client case the hardware is tested on a test installation or rig. Here is some added complexity as our client had to record on which installation/rig it was tested i.e. the serial number to assure that there is a water tight proof. Another critical aspect is the test scenarios or (parameter files) files that are used as input to simulations to be completed. Also these files will be registered as they are specific to the new release of the software.

You appreciate that software configuration management is a complex process as the software itself may control critical product functions. The most regulated industry today is the Aerospace. Specifically the US DO-178b (as adopted also in Europe) is the key recommendation how software should be developed and managed as per criticality of the impact of failure, the so called Design Assurance Level. Also the Food and Drug Administration has published a guidance as laid out in for example 21 CFR 820.
Oh, by the way… both of these regulations are just a guidance, how companies implement the ultimate configuration management plan and processes that makes technical sense is their responsibility and challenge. There are many PLM capabilities to help companies comply better with less effort, how you apply these is the challenge.

One Response to “Software Configuration Management”

  1. Mintjens Says:

    I would like to stress that software should be regarded as a product and therefore be an integral part of a product tree or the traditional bill of material. As a thumb rule, any item that is essential for proper operating or manufacturing of a particular product should be subject to configuration management and part of a product tree of that particular product. It does not matter if one is dealing with tangible physical objects like screws or bolts or less tangible items like software.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: