In 2014 I was leading the design concepts for Product Line Engineering in the IoT Continuous Engineering solution.

What is Product Line Engineering

The industry is making amazing IoT innovations in the products, systems, and applications that impact most of our daily lives: from the smallest transistors in the latest microprocessor making the simplest THINGS smarter to the most advanced products like cars, airplanes, transportation systems, city infrastructures and globe-spanning electronic networks we now take for granted. Increasingly powerful yet inexpensive hardware, embedded and cloud-based software, and ubiquitous network connectivity are enabling new levels of intelligence, interconnections, and instrumentation.

The price we pay for this progress is increasing complexity in the designs, development processes, and supply chains needed to create these smarter products and systems. In many industries, development teams are finding their old development processes and tools to be insufficient to meet the challenges. For example, Engineering teams in auto companies have traditionally focused on mechanical engineering; now the majority of the requirements they must address are expressed in software running on the many processors networked together in a modern car.

Smartphone device manufacturers employ an army of programmers to manage the torrent of monthly changes in the Android operating system and evolve their proprietary value-adds. IT application development managers deal with extensive supply chains as they seek to optimize cost, quality, and time to market.

The IBM continuous engineering solution is a set of engineering and development tools that help systems engineers, application developers, and embedded developers work together to create product lines of smart and connected products.
A product line strategy helps to address the timeless need to work faster, cheaper and better. For example:

• Increase revenue by reaching more market segments/niches. Product variants provide targeted sets of capabilities, price points, and compliance with specific regulatory regimes.
• Improve time to market and lower development costs. Products are defined as sets of reusable components in a product line.
• Improve quality and lower field service costs. (A) Reusing validated and verified components already in the field results in lower defect densities and field service costs. (B) Engineering tools that can automate the reconstruction of complex product configurations used by clients will reduce field service costs through increased productivity of the engineers, for example, when preparing their environment to find and fix a defect.

A Product Line is a group of closely related products that are variants of each other. A product is formed from a specific configuration of component parts, often produced from a common base, or architecture, of components. Each component used in a product has associated requirements specifications, designs, software, test plans, and more. These artifacts are linked Requirements are linked to the design artifacts at the system and subsystem level that model the requirements. The design is linked to the implementing code. Tests are linked to the requirements and code they validate. The links declare dependencies and enable traceability and impact analysis..

However, the requirements specifications of each product in a product line are slightly varying. For example, a Compact car has different product requirements as compared to a Premium car. As the requirements specifications are different all downstream artifacts like designs, software, test plans are also impacted.

A common approach to manage the variability is to use a ‘Clone and Own’ practice. When stating developing a new product variant a copy is made of all requirements specifications, designs, software, test plans, and other associated artifacts. Requirements specifications for the new product variant are modified or added in the copy. Requirements specifications that do not apply to the new variant are removed. All downstream artifacts and traced and updated similarly. While this approach is simple and pragmatic it is ineffective. It is challenging to share components across products and leverage improvements made in one product variant with other variants. Defects have to be coordinated and fixed in every variant individually by each product team. The use of development resources is also ineffective. A system engineer, a system developer, or a tester can not easily switch tasks between project variants. Recreating a development environment with a complete and accurate set of requirements, designs, code, and tests is highly manual and can easily take several hours. Making sure that the environment is correct and consistent with the latest state of all versions is challenging and tedious.

A more effective way of working would be to offload the challenge of variants and configurations to the development tools. Imagine a tool that would manage all requirements, designs, code files, and tests and a structure representing each reusable component in a product, including the system, subsystem, SW, and HW levels. Then, imagine that each of the components has been branched into variants. The tool would manage the changes made to artifacts in each component variant. And then finally, imagine a way to select what variant of each component that would be used by each product variant in a product line. That would be so cool! And as a practitioner, I would be able to just ‘ask the tool’ to present me with the right artifacts for each component by choosing the product variant I wanted to work with. And, then, when ‘asking the tool’ to switch to another product variant the tool would transparently just present the right artifacts of the new variant. Just like that, switch configuration in seconds. That simplicity of operation and assurance of correct artifact version is the value proposition to enterprise-sized systems delivery organizations that are challenged by the market demands of delivering product variants and inefficiency of managing the development of the product lines.

Artifacts, like the products they describe, have versions. A version of an artifact is identified by a specific set of characteristics and can exist at the same time as other versions of the artifact in other configurations. Artifacts are contained by components to make them easily tracked and reused. Product line engineering adds configuration management to enable System Engineering teams to effectively work on changes for a given product variant.

PLE design strategy

Our objectives are to design PLE by adding capabilities to our existing Application Lifecycle Management tools and articulating best practices, rather than creating a new PLE tool

PLE aspects concern the entire development process. This strategy focuses on the supporting infrastructure for artifact management and reuses needed to support PLE practices.

• Specifying a multi-domain product structure – What is exactly the product?
• Consistently manage asset versions and product configurations across all lifecycle disciplines – Create cross-product baselines
• Effectively handling change propagation to the multitude of variants – Where does this change need to go
• Effectively creating new product configuration based on functional parameters – What features define my new product variant

This strategy enables

• Product development teams to
  • Achieve high levels of reuse and parallel development
  • Define and work in the context of the products and components they are developing
  • Engineer product lines
• Work across engineering domains
• Employ version and configuration management across these domains
• Federated data that is created and managed by multiple tools from multiple vendors
• Use open standards and specifications
• Enterprise-scale with worldwide teams

Hills

My research and analysis led our design to two key System Engineering personas and two PLE hills

Hill 1. Teams enjoy configuration management in and across their ALM tools

• With minimal impact on current usage, team members can select a configuration related to their plan and be confident that they are using the right artifacts and links.
• Configuration Leads can define configurations of a product under development consisting of requirements, tests, designs, and implementation.
• Teams work in a scalable environment with 1000s of configurations consisting of artifacts managed in multiple tools and links within and across those tools.

Subhill 1.1 Fine-grained components in RDNG and RQM

Subhill 1.2 Impact analysis using validity assertions

Subhill 1.3 Report from the lifecycle index with versioned data from GCM, RQM, RDM, RTC, including using data currently missing and data related to plans and project areas

Hill 2 – Technical foundation

Provide and adopt service additions for multi-stream configuration management in Foundation, DNG, RQM, RTC, and DM

• Provide and adopt a Global Configurations SDK
• Provide and adopt Link service
• Enable configuration-aware aware dashboards and product artifact views, including document generation and TRS data feeds in RQM
• Enable configuration-aware TRS data feeds in RDNG, RTC, DM and fill the data gaps in RTC, Foundation
• Provide and adopt validity service

Use-Cases

Product Line Engineering capabilities should enable development organizations to

• Decompose products into (independent) reusable components, like requirements modules, test plans, and design packages or blocks
• Develop new products by reusing and modifying components
• Develop and release a platform of reusable components that can be combined into new variants of products
• Develop and release components of related requirements, tests, designs, and implementation into a reusable global configuration component
• Re-factor artifacts across components within the same project area, split and merge components within the same project area.
• Work in parallel when developing, releasing, and using variants of reusable components
• Compose products under development from both released immutable component baselines and mutable component streams
• Overview of the product, its parts, and the component configurations
• Select a product configuration context, and then work, either collaboratively or in isolation, on changes in and across multiple components
• Deliver or merge changes made in one component configuration to other component configurations
• Report on components and their metadata, configurations and their metadata, and the artifacts in a configuration

The Product Line Engineering hills call out two major use-cases

• The Configuration Lead creates a new product configuration
• The System Engineer switches into and starts working in the context of the new configuration

Use-Case – Create a new product configuration

Use-Case – Switch and work in a context