Tue, 26. May 2009
Variant Management for everyone
Have you tried explaining variant management to your boss? And he or she is not really the engineering or technical type? Well, we often get asked this question and so, instead of trying to answer ourselves with our engineering hat on, we have asked a journalist friend to come up with a simpler explanation. Let us know what you think: firstname.lastname@example.org
It is a quiet afternoon so you go onto the web and look at your favourite automotive company’s site. The new sports model looks good – how much does it cost? Before you can discover that, you start configuring your dream version. Petrol or diesel? Engine capacity? Power output? Wheel style? Tyre size? Oops, can’t have that low profile tyre with the wheel style you have chosen. Each choice is creating a different variant and that is before you get into the real toys, like the infotainment systems. Satellite navigation, tuner, multi CD store, speaker configuration: all these can provide a significant number of choices, some compatible with each other, others not. The number of possible options that manufacturers now provide is so great that Mercedes Benz reckons that it is statistically possible that each year every car in the mid-range C series can be different.
And many of the variants are software defined. For example, an engine control unit (ECU) can provide different power output variants of a single engine capacity, primarily through programming. The same unit can also be used for the other capacities and outputs. This presents some challenges for the manufacturer. If a bug shows up in service, how they determine whether it is specific to one implementation, say the 150 b.h.p. 2.0l diesel version, a group of implementations, say all 2.0l diesels, or larger group, all diesels, or even all implementations of that particular ECU. Full scale recalls to rectify problems cost money and reputation, so knowing which versions may have to be recalled is a significant issue.
Variants are nothing new: the automotive industry has used variants to produce product families since soon after the Model T went into service and tools and techniques are in place to handle mechanical variants. What is new is the use of software to produce the variants. Minor software changes allow considerable number of variants of a particular product to be produced. A single chipset for television can be modified by software to match the transmission standards of specific national markets, and then further software variants can be used to provide differentiating features, from entry level to top-end models.
However throughout the development and life cycles of the software, from initial architectural design, through test, to maintenance and update, the developers need to be aware of the issues of different variants and build them into the process, even though there are, as yet, no standards for variant management in popular development processes and tools.
pure::variants, from pure-systems GmbH., can resolve these issues throughout the product life cycle, from requirements’ specification through to maintenance and field support, from configuring the different variants to keeping track of which variant is in service and where.
At one end of the spectrum, consider a large passenger aircraft. It is built of many systems, sub-systems and sub-sub-systems. Defining and managing the interfaces between these is complex (as was revealed by the delays in the Airbus A380) even in a single build. But, just as with cars, different customers require different features, from engines to passenger entertainment systems. More than with cars, over time aircraft are upgraded and modified in different ways. All through the operational life of the aircraft, regulatory authorities require detailed record keeping and compliance with high level standards. Some form of variant management is nothing less than essential.
But to understand the way in which pure::variants work, it is probably best to look at something smaller. Consider a home weather station created from a series of elements: these include a series of sensor modules, for pressure, temperature and wind speed, and further elements include the protocols and links (USB or serial) used to transmit the output, the display choices and options, such as debug.
Within pure::variants these are described at the highest level of abstraction as a feature model capturing the product variabilities. Each element is a feature possessing different properties. A significant property is its type: whether the feature is mandatory, a choice, an alternative or an option when building a particular variant.
The next stage is the family model, capturing solution architectures. The resulting implementation files can be managed with other tools, such as UML, or within pure::variants. These models include the rules that control the selection of elements. From the family model it is possible to create product lines, each line containing one or more models or variants. For the weather station these product variants might be just a thermometer, a multifunction indoor station with inbuilt LED or multifunction indoor station with data transmission.
A variant matrix showing the differences and commonalities between different variants is created after the developer has selected features. pure::variants, after following the different dependency relationships, adds further features needed for completion and highlights issues, such as incomplete definition or incompatible features. Since this matrix can quickly become very large, there are filters available to show, for example, just the differences between two models.
Once a variant model is defined, it can be exported in formats like HTML, CSV/Excel or XML. Alternatively users can use the pure::variants transformation engine to generate concrete solutions and generate product documentation in Microsoft Word. Users can easily extend the transformation engine to provide further facilities.
This approach takes time to set up but once created provides powerful resources. It is possible to add further features, for example adding a humidity sensor or wireless connectivity to the weather station, and create more variant models. When development progresses, it is possible to modify features in the light of knowledge gained, and this process can continue even after field deployment.
pure::variants can also be used for purely software products, with each feature being a code module, making it easier to reuse code. This is particularly valuable for products requiring certification for safety critical applications, where reusing pre-certified code can reduce development time dramatically, but it has applications across the software spectrum.
For example, every PC user is painfully aware of the issues of compatibility between OS, platforms and applications, which Vista has brought very much to the fore. pure::variants will help developers of application software, particularly complex software that runs on different platforms, cope with the issues of providing software that works in such a complex world.
By configuring the variant models within a rigorous structure pure::variants provides the traceability required by military and aerospace applications. In an increasingly litigious society, traceability is more and more desirable for consumer products. Recent government rulings, such as those stemming from Sarbanes-Oxley in the US, mean that traceability is necessary to demonstrate compliance.
pure::variants is language and tool chain independent and, since it can be used within the Eclipse framework, it can integrate easily with most tool chains. It also has extensions to interface to well known and popular tools such as Bugzilla, CaliberRM, ClearQuest, DOORS, Enterprise Architect, Jira, MATLAB/Simulink, MKS, and openArchitectureWare., as well as a range of configuration management tools.