The product line engineering capability adds a Configuration Management menu to the practitioner tools in the IBM IoT Continuous Engineering solution. The menu provides commands to select a configuration context and perform actions on the current configuration context. is a baseline or stream that contains a set of versioned artifacts. A global configuration represents a physical or logical piece of a product offering. It gathers configurations for itself and other contributing applications in IoT Continuous Engineering solutions.
The Configuration Management menu allows users to choose a Project Area configuration of the project area currently opened in the application. The menu also allows users to choose a Global Configuration context. Once a configuration has been chosen, the user may use the Configuration Management menu to create new streams or baselines. Users may also deliver changes from or into the currently selected baseline.
PLE Hills
The hill for PLE states that “Hill 1: Teams enjoy configuration management in and across their ALM tools” and that “With minimal impact to current usage, team members can select a configuration related to their plan and be confident that they are using the right artifacts and links.”
The hill for PLE states that “Hill 1: Teams enjoy configuration management in and across their ALM tools” and that “With minimal impact to current usage, team members can select a configuration related to their plan and be confident that they are using the right artifacts and links.”
User research identifies the need to scope the capabilities on the Configuration Management menu to the right level of user maturity
System Engineers and Testers may be assigned work in a configuration. Such a user just wants to browse from the work item into the configuration selected for the work. The user experience for switching into a configuration should now require any action by the user.
Users with no permissions for Configuration Management should not see such actions on the Configuration Management menu
System Engineers with Configuration Management permissions should be presented with menu commands to choose a configuration context.
System Engineers with Configuration Management permissions should be presented links to browse into the definition of a global configuration in the Configuration Management Application
User Experience Low Fidelity Design – Configuration Management menu
Early playback of Configuration Management menu
User Experience High Fidelity Prototypes
Running code prototypes of Configuration Management Application
User Experience – IBM IoT Continuous Engineering 6.0 GA
Released version of Configuration Management Application
Global Configuration Management (GCM) is an application that assembles configurations for itself and other contributing applications so teams can gain an overall view of the physical and logical parts of their product offering.
A configuration is a baseline or stream that contains a set of versioned artifacts. A global configuration represents a physical or logical piece of a product offering. It gathers configurations for itself and other contributing applications in IoT Continuous Engineering solutions.
Global Configuration Management integrates with the following CLM applications.
The Requirements Management application (RM) delivers requirements definition and requirements management capabilities.
The Quality Management (QM) application delivers testing and test management capabilities.
The Design Management (DM) application delivers design management capabilities.
The software configuration management part of the Rational Team Concert™ application delivers work item capabilities.
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.
“Product lines are a development paradigm allowing companies to realize order-of-magnitude improvements in time to market, cost, productivity, quality, and other business drivers. Software product line engineering can also enable rapid market entry and flexible response, and provide a capability for mass customization” – Software Product Line handbook by SEI
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
“We have 30 products in our product line with 5 variants of each product. We release every product variant 2 times every 18 months with about 30-45 new features in each release. A product contains 300 modules with 500 reusable objects per module. The release roadmap and mapping it to the requirements is a pain point.”
“Our current pain points are; Traceability analysis and baselining Feature change management, and Product change management. We need to view requirement states across all releases.”
“Your PLE 2014 Design Hills and direction resonate well with our needs. We have been waiting for this solution for years”
“Very glad you are being intentional about minimizing impact to existing users and enabling users to adapt better reuse patterns for reuse incrementally — that’s critical. We can’t expect to start from scratch. This has to be accessible to our teams without heroic changes to how they are working now.”
After seeing the playback and our discussions at the Sponsor User call today, here are some quotes from my team: “big leap forward”, “great progress”, “these demos can impress some of our executive people”
Read more about Strategic reuse and product line engineering in an article by Eran Gary, Distinguished Engineer, Rational Continuous Engineering.
The Automated Meter Reader scenario, used in Product Line Engineering design, uses a fictitious company JK Meters Corp, aspiring leaders of Smarter Flow Products for Utilities.
About JK Meters Corp
The Metering Division at JK Meters Corp has a range of Automated Meter Reader products in its product line. The innovative flow detection solutions combine flow sensors, digital monitors integrated with network communication features that are installed both above and below ground, units for gas and water pipe and pump attached flow control, along with meter reader equipment to commission and extract metering information, increasingly using wireless technologies. The Metering division also develops applications that provide industry partners and consumers with analytics on consumption, diagnostic, and status and solutions for customer billing and service management.
The most successful product is the Automated Meter Reader for Water Flow (see figure below). The product consists of meter interface units mounted on water pipes. The meter interface unit measures flow and delivers data to handheld or car-mounted meter readers. The registered meter readings are uploaded from the handheld devices to the AMR server data management system manually. Uploading of data is performed continuously by the mobile meter readers using a mobile network connection, or manually when returning to the office at the end of the day when using the manual meter reader product.
The Automated Meter Reader products are delivered to utility customers worldwide and the products are developed with variants for each regional market. The variants are configured for regional requirements on power voltage, dimensions on pipe mounting, regional units of flow and volume, language configuration for the handheld meter readers, and regional city maps for GPS routing.
The Metering Division is currently investing in improved features in the product lines and new AMR products. An innovative new AMR Grid product reduces the operational cost of utility services by providing fixed grid meter readers that continuously read a wireless grid of residential or industrial meter interface units and uploads data over a fixed network connection.
About the Organization in the Metering Division
Under the direction of Product Management and Sales, the Metering Division organizes Development, Product quality, Operations with production and maintenance in North America, Europe, India, and China. Development is organized around Enterprise systems for IT, business, and analytics applications and products, and on Sensor systems with integration of sensor technologies and devices. 3rd party suppliers are used for some sub-system development and delivery (not emphasized within the current scenario). The Metering Division teams are distributed and rely on a common product and systems development lifecycle infrastructure for development collaboration and product delivery.
The Metering Division organizes its Development in a matrix of projects and disciplines. The disciplines, managed by discipline managers, are responsible for the definition and continuous improvements of practices and contributor skills. Team members from the discipline are assigned to the project organization and work in the product development team under the leadership of a project manager.
The success factors for the Metering Division Development is to achieve better use of development resources by improving the reuse of parts through product configurations, improvement in product quality, and productivity improvements through collaborative design of hardware and software sub-systems. JK Meters Corp has the initiative to improve the performance of its development and delivery activities for the Metering division. The AMR product development team has deployed IBM Rational’s Systems and Software Engineering solution are currently using change management (CM), requirements management (RM), model-driven systems engineering (MDSE), and quality management (QM) capabilities.
About the AMR Product Line
The Automated Meter Reader products are configured from reusable components. These component subsystems are developed and delivered by the Meter Reader, Meter Interface, and AMR Server platform teams. The AMR Manual product is configured from a Wired Meter Interface unit, a Manual Handheld Reader, and a generic AMR Server that is reused across the product line. The AMR Mobile and AMR Grid reuses the Wireless Meter Interface unit but differs in using a Mobile reader vs Grid Reader.
The Automated Meter Reader products have been delivered to utility customers in the US. JK Meters Corp is growing its market share by developing variants for other regional markets. The variants are configured with regional requirements on power voltage, dimensions on pipe mounting, regional units of flow and volume, language configuration for the handheld meter readers, and regional city maps for GPS routing. Meter Interfaces, Mobile Readers, and AMR Servers are adapted and regional variants are created for each market in the US, EU, and the UK.
The AMR Meter Interface is an electro-mechanical unit that connects to water pipes, gas pipes, or electrical cords and measures flow consumption and triggers alarms based on events and analytics. The unit is based on a standard microcontroller that connects to a sensor and runs the AMR Meter Interface embedded software and additional drivers for the sensor type. Backup power and communication components are attached to the controller.
The Handheld AMR Meter Reader is a rugged handheld Microsoft® Windows Mobile® tablet that connects over wire or RF to Meter Interface units for reading and uploading water, gas, or electrical flow consumption data and alarms. The unit provides GPS routing and Cellular GSM (EU) or CDMA (US) connectivity to AMR servers.
The unit is based on a standard tablet and runs the AMR Meter Interface Windows Mobile software. It integrates with Windows Mobile applications for messaging, map management, and routing. The unit may be ordered with a car mount kit that charges the unit and connects to the car audio system over Bluetooth.
Handheld AMR Meter Reader Parts
Windows Mobile tablet
Windows® Embedded Handheld 6.5 operating system
AMR RF expansion unit + AMR RF unit drivers
GPS expansion unit + GPS unit drivers
Cellular GSM and CDMA expansion units + Cellular unit drivers
The AMR Grid Reader is a fixed meter reader that connects over RF to Meter Interface units for uploading water, gas, or electrical and reads flow consumption data and alarms. The unit provides fixed internet or Cellular GSM (EU) or CDMA (US) connectivity to AMR servers. The unit is based on a standard ARM processor board and runs the AMR Grid Meter Reader Linux embedded software. The unit is equipped with an RF antenna, solar panel power, and a backup battery unit. GSM/CDMA or Ethernet cards are attached directly to the board.
The AMR Server is provided with our IBM partner using the PureData Systems solutions and runs the ARM Server data storage and services applications. JK Meters and IBM offers on-premise, hosted, or cloud configurations.
The AMR Server delivers the AMR data store, the AMR analytics engine, and system administration applications for a customer, infrastructure, operations, and system management. The system also delivers AMR services like billing, reporting, reading, alarms, forecasts and flow analysis, and infrastructure planning.
AMR Server Software Parts
AMR Administration
Server administration
Services administration
Customer administrations
Device administration
GRID administration
Handheld administration
Meter administration
Reusable Platform Components and Variant Product Line Configurations
The Automated Meter Reader products are configured from reusable components. These component subsystems are developed and delivered by the Meter Reader, Meter Interface, and AMR Server platform teams. The platform teams deliver the component subsystems with feature variability for the product line. For example, the Meter Interface team delivers wired and wireless variants of the component for the Manual and Mobile products. The Meter Reader team delivers variant components for Manual, Mobile, and Grid products.
The Product Line Engineering capabilities in the IBM IoT Continuous Engineering solution is providing support to manage variants of components.
What is a Component?
A component is a unit of organization consisting of a reusable set of artifacts such as requirements, tests, designs, and source code. The Automated Meter Reader (AMR) teams are using components to organize the lifecycle artifacts under development. The teams have defined components both at the system/product level and at each subsystem level. Separate components are used to manage requirements, tests, designs, and source code at each level.
A configuration is a set of specific artifacts versions of a component. A configuration evolves as changes are made to the artifacts in the configuration. At different times it might contain different sets of artifact versions. Such a configuration is also called a stream. A stream can contain changes and is mutable. Snapshots of configurations (streams) at a certain time are called a baseline. Their role is to record a configuration state for either a comparison or simply later reuse. Baselines, can’t be changed, they are immutable.
As a configuration is a set of specific artifacts versions of a component, the use of two configurations for AMR system requirements will greatly help in managing the variability of artifacts across the US and UK markets. In two such configurations, common requirements will have the same artifact version but a specific requirement for the UK configuration will have a different version as compared to the US configuration.
The AMR teams are using several streams to manage variability across the product line. Streams are branched for the Manual, Mobile, and Grid products. Streams are also used to manage variability across regional market US and UK products. The stream diagram below shows a conceptual view of the configuration dependencies.
The AMR teams create baselines consistently across all artifact types for each milestone and release. The baselines are used to branch new streams for changes going into the next product release.
The AMR teams are using global configurations to organize the components for the system level. This enables the system requirements, design models, tests and source code to be managed as a single global configuration. You will use the IBM Rational Configuration Management application to create an AMR Mobile UK global configuration that assembles the requirements and test streams for Mobile UK you created in the previous part. The Automated Meter Reader (AMR) platform teams are using individual global configurations to develop and deliver the Meter Reader, Meter Interface, and AMR Server subsystems.
“We have 30 products in our product line with 5 variants of each product. We release every product variant 2 times every 18 months with about 30-45 new features in each release. A product contains 300 modules with 500 reusable objects per module. The release roadmap and mapping it to the requirements is a pain point.”
Read more about Strategic reuse and product line engineering in an article by Eran Gary, Distinguished Engineer, Rational Continuous Engineering.
