In the first article in this three-part series, Why Do Software Bugs Continue to Plague Products?, I described how the proliferation of complex control software in most modern industrial, commercial and personal products are challenging product companies, and the expectation that engineering issues and quality snags will not only persist, but, in fact, are likely to increase.
A follow up article, Agile vs. Corporate Culture, discusses Agile software development methodologies and explains the organizational processes and cultural barriers that impede the adoption and reduce the efficacy of Agile practices.
A typical product development environment in organizations designing embedded control software is an eclectic mix: Agile methodologies are utilized, side by side, with traditional, more rigid product development disciplines; formal tools are mixed with a plethora of one-off but nonetheless very capable tools, many of which are open-source, Unix-flavored tools; and processes are broken and scattered along the functional boundaries of these tools and data repositories.
After studying embedded software development practices at a number of automotive, aerospace and medical equipment manufacturing companies, I am convinced that this eclectic development environment and its fragmented decision-making processes are not likely to change anytime soon.
Application lifecycle management (ALM) software environment offer the convenience of a single platform and some data integration capabilities. But in and of themselves, ALM tools are not designed to manage the entire product lifecycle and must be well-integrated with the product lifecycle management (PLM) environment.
PLM-ALM Integration
Product organizations must re-architect their product development methods and consider a model that separates the overall product development governance and the associated product data management from the multitude of individual tools used to design, integrate, test and build product components and subsystems.
At the core of this process model is a centralized product data management (PDM) for the product’s bill-of-materials (BOM) that is able to manage the broad range of design objects and attributes necessary to define all products structures and configurations completely and precisely.
Specifically, a product’s BOM must be able to delineate any type of mechanical, hardware and software design artifacts. ALM software objects include software components (source files and binary images) and the software switch configurations (“calibration parameters” in automotive parlance) set by the supplier or during the final assembly process. Other non-BOM items include manufacturing work instructions, compliance certificates and user documentation—all must be configured and maintained in the context of each product variant.
This product BOM is used to define and manage all the dependencies, relationships, and configuration data, across all engineering disciplines, in a single logical view. In particular, this BOM represents hardware and software version incompatibilities and dependencies, and all possible and allowable configurations (and calibration settings) for integration testing, validation and manufacturing (and without the help of Excel “cheat sheets”).
To be clear, the notion of a single centralized PDM does not mean a single physical database and is not proposed here to start a turf war between PLM, PDM and ALM advocates.
It quite conceivable that the product BOM is managed in a PLM repository, and design components such as source code and test cases are stored in the ALM tool suite and are only linked to from the PLM system so that products structure dependencies and compatibility definitions are maintained centrally to allow the manufacturing and maintenance of various product configurations and variants throughout the product lifecycle.
This BOM is used by manufacturing to ensure that the correct software configuration is embedded into the hardware. Next, the “as-built” configuration of hardware and software is continually modified to reflect the “as-maintained” status, including recent software updates, to be used by the service and quality management organizations.
PLM Redefined
This unified PLM-ALM model extends the role of PLM system as used in many product organizations, where it has been relegated to a PDM. The PLM software is tasked not only with managing data repositories, but it now serves as the “digital backbone” that facilitates and maintains the integrity of cross-linked multidisciplinary product lifecycle information.
This PLM backbone supports tool and process federation that allows different design teams to work in their native environments, and, at the same time, grants access to cross-domain data objects. Decision makers involved in a broad spectrum of product related decisions, including marketing, engineering, supply chain management and service operations, can have access to rich information that facilitates better decisions and reduces mistakes and coordination friction downstream.
If you stop and think about it for a minute, the forgoing isn’t redefining PLM at all; it is letting PLM regain its original role—a centralized platform to manage (but not necessarily own) all product related decisions throughout the product lifecycle.
Image: London City Farmhouse by Catrina Stewart