The use of product architectures for managing product complexity is a practice that is growing across more and more industries. With the emergence of global markets and competition, twenty-first century engineering enterprises face new challenges as they strive to meet demand for varied products in increasingly short timeframes and often minimal potential for product differentiation. For many industries, each new generation of products is inevitably more sophisticated and complex, as new product versions require the participation of more engineering disciplines than ever before. My colleagues have explored several BOM management and BOM configuration topics that help to overcome these challenges. We’ve discussed different approaches to BOM configuration and some best practices for configuration management, as well as product variant management and guided product configuration. In our overview of BOM management, we introduced the use of architectures as part of an effective BOM management approach. I’d like to take a closer look at the role of architectures.
Modern vehicles have been growing to highly complex systems with considerable electronics and software content. Already today this complexity is difficult to master, but with the expected further growth of vehicle functionality and complexity new measures are needed to reduce this complexity and to streamline the related development and support processes. A proven way to reduce complexity is to leverage a stable product architecture to define the product decomposition and to plan and account for work.
As per ISO 42010 – ‘Architecture’ is defined as “the fundamental conception of a system in its environment embodied in its elements, their relationships to each other and to its environment, and the principles guiding its design and evolution”
Automotive enterprises typically already leverage engineering development of product generations around a common architecture framework which is optimized for efficiency and reuse. This approach is relevant and valuable for a variety of engineering products. Let’s look at some of the key concepts around product architecture management.
Strategic reuse of Product Architecture Views for executing Product Engineering of Product Families
As part of the
Corporate knowledge repository, engineering creates and manages product specific architecture templates. Each template may be a collection of planning, system, physical or functional, spatial and manufacturing architecture views
Knowledge captured in these templates can be intelligently reused in future products family development.
Each of these views has a standard architecture breakdown that describes the functions, systems, logical elements or other breakdowns for that view that are common across the evolving product family or product generations.
The process of creating architecture involves decomposition, in which a top-level concept of the system’s required functions is broken down into sub-functions; the most abstract version of its physical form is broken down into subsystems capable of performing the sub-functions, and so on for other types of breakdowns.
OEMs can realize platform architectures from the PLM repository based on which a variety of related products can be built from a common design, engineering, and production efforts to satisfy a range of market segments.
This establishes a framework for reuse, product planning, and accountability. Product completeness to the expected content and variability can be validated. Product architectures formalize a corporate standard for how products are organized, planned, and delivered thus maximizing the reuse potential.
Managing complexity and tracking against high level goals – Product Integration Architecture
Effective strategies enable you to manage program assumptions and targets using a consistent product planning architecture to guide and account for work throughout the program lifecycle, as well as cascade and track program targets for downstream execution.
Vehicle programs are evaluated in terms of their ability to achieve goals that, ideally, are formulated as measurable targets – such as fuel economy, vehicle mass or safety. In systems-driven product development, these vehicle-level targets are decomposed into targets for subsystems or specific vehicle properties – such as engine parameters, transmission parameters, mass and aero drag. This translation is refined from high level parameters for subsystems to increasingly detailed parameters of the subsystem components based on heuristic or quantitative models that are continuously refined to describe these dependencies as accurately as possible.
This refinement of high level targets to lower level targets creates a structure that ultimately enables individual engineers to understand how changes that they make to a component or subsystem impact the goals of the vehicle program. This structure also allows the program manager to track if the program is “on target” for its high level goals. If it is not, the structure enables the program manager to determine what causes the deviation and how it can be compensated.
We call this structure the “product integration architecture.” Even if a vehicle has thousands of requirements and functions, only a small number of these are associated to each of its elements. Through the product integration architecture, Teamcenter allows a mapping of dependent systems and functions. The product integration architecture enables engineers to manage this level of complexity while understanding how it contributes to the performance of the whole system.
Systems Architecture Breakdown to author & manage Functional & Logical System Design
To understand the integration and information flow within and across systems, you need to author and simulate system and sub-system functional architectures and behavioral models that describe the logical representation of the mechanical hardware, electrical hardware and electronic control systems. This enables you to support robust delivery of product features and attributes. System logical models provide a starting point of design & BOM execution for the product family and will be implemented by modules and components in the physical world.
Architecture Breakdown for BOM and Design Documentation
Physical or functional architecture breakdowns facilitate controlled product definition content authoring of part and design Solutions per product architecture node.
Engineers can document and optimize on the number of potential solutions based on the build conditions per architecture node which is a key to complexity reduction. Build conditions are generated based on the scoped variability per Architecture node.
Part and design content under a specific architecture node can be used to validate product definition content from completeness and build-ability perspective during various stages of the product lifecycle. Configured full or partial variant solves can be executed on an architecture node to validate the completeness of BOM and design. Authored parts and designs should ideally conform to the program targets in terms of the cascaded cost, weight, and performance attributes at specific product architecture nodes.
It is possible to organize and view the same authored part and design content in the context of multiple views of a product. For example parts used in a brake system are documented across distinct functional areas of a product. However it is possible to organize the same set of parts and designs in a brake system view which provides a complete picture of how the brake system of a vehicle looks like.
Architecture Breakdown to manage Manufacturing and Service Views of the Product
Manufacturing process breakdowns are key to executing centralized manufacturing planning of the engineered product. A manufacturing architecture view of the product is a breakdown of manufacturing process blocks under which manufacturing process operations are authored. Authored manufacturing process operations consume documented engineering part usages and designs.
Executing manufacturing solves with aligned visualization can be executed on the process architecture breakdown for specific product configurations to look at the way the product would be assembled. On similar lines service views of the engineered product can be created and managed.
With product architecture management as part of your PLM BOM strategy, you can enable reuse and support a commonality strategy to manage product complexity. You can execute systematic development and management of products to support ever increasing product differentiation and diversification in global markets.