BigLever Software’s Dr. Paul Clements, one of the pioneers of the PLE field, explains.

Product Line Engineering (PLE) is a way to engineer a portfolio of related products in an efficient manner, taking advantage of products’ similarities while managing their differences. Engineering includes all the activities involved in planning, producing, delivering, deploying, sustaining, and even retiring products.

PLE considers the product line portfolio as a single entity to be managed, as opposed to a multitude of similar but separate products. By exploiting product commonality while managing variation, organizations can achieve improvements in effort, time, and quality. This enables a unified, automated approach across the entire life cycle – including engineering and operations disciplines; software, electrical, and mechanical domains; and tool ecosystems.

Why PLE?

PLE can help aerospace manufacturers deal with the tremendous complexity of managing and delivering more product diversity. Aerospace products need to support varying missions, operating environments, customer needs, and regulatory frameworks – all while providing safety and reliability. PLE represents a cost-effective, cost-efficient way to handle variations while ensuring quality and responsiveness.

Traditional engineering risks

With the traditional, product-centric approach to handling variation, when a new system is needed that’s slightly different than systems that already exist, engineers will pick the most similar one available, copy it, make changes to it, and field it as a new system. Called clone-and-own, the practice does employ reuse but the savings occur once and only once. The new system spirals off on its own evolutionary trajectory, and ongoing savings available by exploiting commonality with the product it copied are lost.

Within the traditional approach, there are techniques that engineers use to manage variation. In software, for example, there are inheritance, compile-time constants, build scripts, component-based development, etc. In requirements management, engineers often use attributes to help identify which requirements apply to which products in a product line portfolio. However, these techniques are specific to a particular type of engineering and do not provide benefits across realms. Engineers often invent their own way to describe variations or simply describe the variations through the product name; not an approach that scales either across the life cycle or as a product line grows.

For instance, there are variations that an engineer is prepared to configure software for, but it’s not a central definition of what those variations are. It’s specific to that product. Likewise, with requirements, a person can set up attributes – but those attributes are product specific, so that person must look at every requirement every time a new product is added to see if it applies or not. These techniques duplicate effort and inefficiencies, create opportunities for errors, and significantly inhibit an organization’s ability to efficiently scale its product line, maintain quality, bring new products to market quickly, and meet other key goals.

PLE factory

Feature-based PLE takes the expression or description of the variation out of all those disparate places and centralizes it using a well-defined, common language of features. The features describe product variation; they are the distinguishing characteristics. Features become the common

A product line engineering (PLE) factory is much like a typical manufacturing factory except that it operates on digital assets (or digital twins) rather than physical parts.

language that engineering and operations domains use to capture, express, implement, and manage variation across the entire life cycle, and across the product line portfolio.

The underpinning of feature-based PLE is the creation of a PLE factory – much like a typical manufacturing factory that operates on digital assets (or digital twins) rather than physical parts. The technology infrastructure for the PLE factory (see graphic, pg. 68) starts with creating a feature catalog, which defines the feature options available for all the products in the product line.

The organization then creates a superset supply chain of digital assets (see graphic, pg. 70) that are shared across the product line. Assets could be requirements, source code, bills of materials, documentation, manufacturing processes, etc. Whatever it is, it’s a superset – assets designed to be shared among different products in the product line, and never cloned-and-owned for individual products. These digital assets are equipped with all possible feature options offered in the product line and then moved into the PLE factory, where they are used to automatically produce the products based on the feature selected.

The PLE factory becomes an automated production system, where new product capabilities and innovations can be incorporated into the asset supersets and shared across all the products in the product line. If a defect or problem occurs, it can be fixed once in the asset superset and quickly promulgated to all products.

Exports

A benefit of feature-based PLE is its ability to manage export products. When organizations have a defined set of product line features and a superset of shared assets that can be centrally managed, it becomes easier for them to manage forbidden or proscribed product content.

Lockheed Martin uses agile combined with feature-based product line engineering (PLE) for the Aegis product line.

Rather than having many different programs try to figure out what they can and cannot export, all of that is taken care of – inside the PLE factory – which provides an added level of control, since it will not allow a product or system that violates constraints. Lockheed Martin has developed a case study on this topic, termed “Auditing for prescribed content.” The U.S. Navy has also adopted this approach to help enforce export control restrictions.

However, this isn’t only about export control. It’s also about intellectual property (IP) protection. Contractors want to make sure that a piece of development for one defense customer doesn’t accidentally find its way into a product for another customer. The same kind of enforcement and auditing methods can accomplish this. Export control is just a special case of IP protection – it all works the same.

Transitioning to feature-based PLE

While PLE payoff is large, it does require a change in mindset; a shift from focusing on individual products to focusing on the product line as a whole – a mind shift that must be inculcated and institutionalized. Changing technology is easy. Changing people is hard. A successful transition to PLE starts at the top, with a clear PLE vision and business goals defined and sponsored by executive leadership. This entails creating a well-constructed business plan which captures the driving goals and funding requirements for adopting PLE. This, in turn, feeds into an adoption plan that ensures that the business goals are being addressed and refined. The adoption plan is essential for defining roles and responsibilities, setting factory-based processes, and getting management and staff trained to operate effectively within the PLE factory.

Proven organizational change methods work well here, combined with an incremental PLE adoption approach that’s tailored to an organization’s goals, situation, and needs. This approach needs to empower broad-based action and produce short-term wins, which builds momentum and further speeds an organization’s transition.

PLE must work in concert with existing tools across the lifecycle. That’s why BigLever created a PLE Lifecycle Framework that integrates with most engineering tools, and established a PLE Ecosystem to allow engineers to operate within the tooling environments in which they’ve become accustomed. With PLE, they can just continue to do their jobs – but in a slightly different way under the PLE factory paradigm.

Regarding other development techniques, agile is popular and works well with PLE. For example, Lockheed Martin uses agile combined with feature-based PLE for the Aegis product line. The company reports cost avoidance of $47 million per year. Model-based Engineering (MBE), another paradigm that’s making huge waves right now, also operates well with PLE.

A superset has assets that are specifically designed to be shared among the different products in the product line, and never cloned and owned for individual products.

PLE’s future

PLE is poised to grow rapidly in aerospace, including A&D, military, and avionics applications. It brings a level of discipline to the engineering of these very difficult, requirements-challenging systems that aligns well with the rigor these organizations need to produce successful systems.

PLE has matured in the last 15 years to become much more codified, formulaic, and repeatable. Part of this codification is standardization, which brings a new level of understanding and acceptance of PLE best practices. New ISO standards for feature-based PLE are taking shape, and BigLever is taking a role in this area, working closely with the International Council on Systems Engineering (INCOSE). We expect to see the number of PLE deployments in aerospace steadily increase, along with the critical benefits that organizations realize from this approach.

BigLever Software

www.biglever.com

About the author: Dr. Paul Clements is VP of customer success at BigLever Software and can be reached at pclements@biglever.com.