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.

Read the rest of this entry »

Advertisements

Hardware-oriented MRO systems need to cope with the accelerating complexity and velocity of change found within hardware embedded (and loaded) software on today’s aircraft, cars, ships, industrial products etc.. One of the most critical aspects that PLM can address is the coupling of hardware and its certified software. PLM Configuration Managed software can nicely sit next to an EAM/MRO application. Integration of applications concerned with management of requirements, configurations and maintenance statuses captures all of the critical information needed to assure that the software status of an asset is known at any point in time. From the MRO perspective all relevant information regarding the ‘master record’ configurations are available (See also Enterprise Asset Management category) across specific aircraft categories for example, but also the  individualized real-time status information of the current configuration for every managed tail number. We all remember the stories of software problems in cars, here the same link can be established between the Vehicle Identification Number and its software status. When integrated with problem reports, a complete closed loop failure record and action system can be operated and this would provide a full accountability from discrepancy till resolution.

Read the rest of this entry »

In the previous post I talked about Software Configuration Management. This post is about management of software requirements and the link to software configuration management.
Although I did not specifically discuss management of software requirements in the previous post, it is evident that managing the configuration includes the specification sources i.e. the requirements. In the first recommendation of the previous post I touched on the object Work Request and example supporting materials e.g. specifications that may be attached. Ideally requirements are decomposed to individual requirement line items, i.e. similar to a tree. Each such line item would then specify the desired function but also instructions essential to developers but also test scenarios and the required end results that must be met.
In the requirements set you also find the actual failure mode and effect analysis i.e. if this function fails; what would be the effect and what would would need to be implemented that this failure would not occur. Obviously this is not just the software itself but the complete integration with the hardware it may need to control. As pointed out earlier, this level of detail is critical to also manage the prototype test process and also the actual life test i.e. the software as it is installed onto the product. The myriad of interconnections considering this level of detail and also combined with Change management records makes data management a daunting task without the right PLM capabilities.

Read the rest of this entry »