Four new software product lines were inducted into the Hall of Fame at SPLC 2004: General Motors' Powertrain product line, Salion, Inc.'s product line of revenue acquisition management systems, Ericsson's AXE family of telecommunication switches, and Phillips' product line of software for high-end television sets.

General Motors Powertrain (GMPT)

General Motors Powertrain (GMPT) is a division of General Motors Corporation (GM), the world's largest producer of passenger cars and trucks. GMPT provides powertrains to GM, its subsidiaries, and its partners. Today's automotive powertrains consist of an engine, transmissions and the associated control system. In the control system, there are electrical components, an electronic control module, and the software that runs this system. The software that runs this system is called the General Motors Powertrain Software Product Line.

GMPT began its transition to a product line approach for its embedded powertrain control software in the late 1990's. Since the inception of the product line, GMPT has taken four iterations of its software product line to production. During its short product line history, GMPT has used the software product line to support multiple electronic architectures - 5 engine control modules, 4 transmission control modules and 3 powertrain control module supporting both an engine and transmission controls. The software product line is also capable of supporting multiple powertrain physical architectures (diesel engines vs. gas engines, clutch-to-clutch transmissions vs. freewheel transmissions). Finally, controller products built using the GMPT software product line cleanly interface with over 100 vehicle platforms.

The GMPT software product line is now the basis for nearly all new control modules being developed within GMPT. In the next three years, GMPT expects to take the number of software sets supporting gasoline engine programs from 17 down to 3. In this manner, the use of the GMPT software product line has enabled GMPT to support the demand for new control modules and new powertrain features with minimal additional resources.

More information about the GMPT software product line is available at www.eecs.umich.edu/courses/eecs486/win03/notes/GMVisit.pdf

Ericsson AXE Family of Telecommunications Switches

The Ericsson AXE family of telecommunications switches was created in the 1970's as a conscious effort to create a system structure that would be resilient to a wide variety of changes:

• functionality requirements: telephony is constantly evolving as a services
• local adaptations: Ericsson is active in 140 countries, and many regional and national regulations must be accommodated
• scalability: the architecture must deliver cost-effective solutions from small installations to major international hubs
• personnel: several generations of engineers have kept building on their predecessors' achievements, in dozens of development centers all over the world
• technology evolution, but more of that below!

In terms of technology growth, AXE has survived a remarkable set of changes. This goes from the first switch deployment in 1976, which actually controlled relay devices, through the introduction of digital switching, ATM, and now moving on to a softswitch architecture. In the latter case, AXE takes on the server role, controlling gateway devices based on various technologies including IP transport, carrying the AXE architecture into the Voice-over-IP world.

The software design of the AXE family was built from the ground up based on what we now describe as an object oriented approach. Objects (blocks) interact using message passing; simple and clear rules regarding design time and runtime semantics minimize the risk of design deterioration. The prime example of the resilience of the architecture is Ericsson's implementation of mobile switching on top of the AXE platform and basic switching application structure. This includes a number of analog cellular systems, as well as every major digital cellular standard: GSM/GPRS/EDGE, WCDMA, D-AMPS, PDC, cdma2000, with others to follow.

During its 30+ year history, AXE has also evolved in terms of the computing platform, going through a number of performance enhancing technology changes. In the latest step, this has included successfully transferring the architecture onto a commercial hardware platform, while retaining software and interface compatibility with the wide range of line interfaces and switching devices available within the family.

Finally, AXE has been a considerable commercial success: several thousand switches are in operation all over the world, and 40% of all cellular phone calls are placed through Ericsson equipment.

Salion's Product Line of Revenue Acquisition Management Systems

In 2001, Salion was a startup preparing for its initial product launch. Even before completing its first product or getting its first customer, Salion knew it would have to solve the software product line problem – how to efficiently engineer a collection of nearly identical variations of their core product. The core product in this case was an enterprise software system to help optimize front-end processes for companies whose revenue stream starts by receiving and bidding on requests for quotes (RFQs).

Most of the product line methodologies being discussed at the time were proactive, requiring experience in a stable and well defined application domain. However, Salion expected some turbulence in their domain since they were inventing a new product in a new market and would be integrating the product into a wide variety of unknown customer settings.

At about the same time, BigLever Software was promoting the agile notion of reactive software product line engineering as well as lightweight and incremental adoption strategies using commercial off-the-shelf product line engineering and variation management technology. Salion decided to adopt this approach and in hindsight, this decision was a central part of their success in bringing their product line to market.

The unmodified architecture, design, and source modules from Salion's initial baseline product served as the core assets for the product line. By utilizing the existing baseline product for core assets and off-the-shelf technology for software product line engineering and variation management, Salion made the transition to a reactive software product line approach in only 2 person-months of effort, which is two orders-of-magnitude less than previously reported efforts with proactive software product line transition efforts. They have subsequently deployed 16 commercial products in their product line, each with an average 95% software reuse and 90% reduction in engineering effort compared to the initial baseline product.

By taking a reactive software product line approach and using off-the-shelf product line engineering technology, Salion has been able to reap the benefits of software product lines while remaining agile in the face of turbulence in their application domain.

• Clements, P. and Northrop, L., Salion, Inc.: A Software Product Line Case Study, Software Engineering Institute (SEI) Technical Report CMU/SEI-2002-TR-038, Carnegie Mellon University, Pittsburgh, PA, November 2002.

• Buhrdorf, R. and Churchett, D. Product Line Agility in the Face of Turbulence - The Salion Success Story, on www.SoftwareProductLines.com.

• Krueger, C. and Churchett, D., Eliciting Abstractions from a Software Product Line, in Proceedings of the OOPSLA 2002 PLEES International Workshop on Product Line Engineering. Seattle, Washington. November 2002, pages 43-48.

• Buhrdorf, R., Churchett, D. and Krueger, C. Salion's Experience with a Reactive Software Product Line Approach, in Proceedings of the 5th International Workshop on Product Family Engineering. Siena, Italy. November 2003.

Philips Product Line of Software for Television Sets

Philips is one of the world's largest consumer electronics companies, and a global leader in televisions and other consumer products. While initially solely consisting of hardware, TVs now contain fully equipped embedded computers to control the hardware and to implement extra features. These computers started small, with 1 kilobyte of code around 1980, but software size has grown according to Moore's Law, resulting in many million lines of code today. While this by itself makes complexity an important issue, the other important issue is diversity, since televisions are produced in many different variants. To efficiently manage complexity and diversity, we decided to set-up a software product line.

The first step was the definition of a software component model, Koala, designed to allow the creation of different products by making new combinations of selections of reusable components. For this, all context dependencies of components are made explicit in the form of provides and requires interfaces, while diversity interfaces allow for internal variation of components. An explicit architectural description language, one of the first to be used extensively in industry, helps to manage complexity and to automatically generate product specific binding code. While Koala was modeled after Darwin and Microsoft COM, it is specifically tuned to build software product lines of resource-constrained products.

The second step was the creation of a product line architecture, profiting as much as possible from (re-engineered) existing software. This architecture is not a generic architecture shared by all products, but rather a set of rules and principles that should be obeyed by individual products, allowing each product to have its own specific and optimized architecture. The architecture was split in three main layers to anticipate on the use of 2nd and 3rd party software in the future.

To effectively deploy the architecture, changes had to be made to the existing development processes, which were optimized for the creation of single products. Typical changes were the introduction of component and interface data sheets to replace the traditional requirement specifications, and the definition of 'infinitely' progressing asset development projects, as opposed to finite product development projects.

The fourth step was the adaptation of the development organization to accommodate product line development. While we do separate asset from product development, all asset teams are aware of all products and vice versa, to ensure that the right level of generality is achieved. Another important issue was the alignment of the organization with the architecture, making sure that each subsystem is being developed on a single site.

The component model was created in 1996. The architecture was defined in 1998. The first product came on the market in 2000. Since 2002, all Philips' mid-range and high-end televisions have software derived from this product line. Today, there are 20 different software releases per year, where each release serving 1-5 different product types. The product line supports three different hardware platforms. When we started, diversity was one of the top three issues on the agenda of architects. Now, diversity has disappeared as issue entirely.

Our product line approach is extensively documented in http://irs.ub.rug.nl/ppn/275169561.