Active Knowledge Modeling

Computer support to Product Design and Life-Cycle Management is currently dominated by PLM systems, and industry is not very happy with the support provided. Industrial design methodologies and PLM systems create many disjoint, pre-typed product structures. This approach belongs to the era of communicating product knowledge as engineering drawings. In this post, we discuss the need for replacing these static structures by a single federated product model, from which any structure or aspect can be derived.  The federated product model is managed as a family of configurable system and component models, as part of an active knowledge architecture (AKA). With the advent of AKA we see completely new approaches, concepts, operational methodologies, visual modeling methods, enterprise architectures and design solutions emerging.

Concepts that enable operational methodologies and support configurable IT platforms, promise to revolutionize product design and industrial computing. However, it will require a change in attitude and thinking, organization and management from industry itself, and from IT departments and vendors. They must be prepared to share more of their core business knowledge with networked partners. Approaches such as Federated Product Models and Configurable Product Platforms have been prototyped, pointing towards active knowledge architectures. However, concepts and methods for developing product families for more automatic customer delivery, and artifact languages for conceptual design are still just models. Methods must be implemented before we can complete the wheel in the figure below, and claim that we have a quality knowledge architecture to replicate and adapt, providing front end loading of projects.

Simplified product lifecycle

With knowledge architectures we can start by front end loading new projects with the best quality results and practices from past projects. This can be achieved by replicating and adapting from existing knowledge architectures. The borders between stages, systems and disciplines can be relaxed, facilitating collaboration, concurrency, repetitions and replications.

An artifact language for conceptual design will be composed from a set of basic services. The services are modeled as extensible task patterns built from a library of basic tasks for conceptual and functional systems design. Concretizing the language could include 3D artifacts to ease user identification and navigation, and workspace customization. This will enable automatic context capture and reuse. It should also include services to model, prototype, adjust and extend the product language from concept to as-designed, as-built and finally to as-recycled product models.

Parameterization and Knowledge Based Engineering (KBE)

Any product design has a multitude of requirements, specifications and global properties, embodied and represented as performance parameters, functional parameters, material specifications, shape and geometry, centre of gravity, and other technical design parameters. Current IT systems face a series of challenges in creating and managing a flexible and role-oriented representation of this evolutionary pragmatic, mostly informal and life-cycle critical logic.

In the early 1970s CAD systems for oil tankers were developed to automatically compute all longitudinal and transverse steel structures. Their composition, dependencies, shape, material, construction details and geometric parameters were described by formal as well as pragmatic rules. This was feasible because of the more than 140 classification rules that govern tanker design. The product database had tanker structures implemented. Some modification of practices to facilitate deterministic computation of structural details were negotiated with the designers. Ten years later we repeated this extensive parameterization effort for families of water turbines.

It took 25 years before we realized that the tanker or turbine knowledge is the core of the IT system, and that software is merely a medium to enable communication and computation. Nowadays, the dominant industry solution is to apply KBE languages and tools to feed CAD systems. This yields solutions that we have characterized in the figure below. The industrial power lies in the scalable automatic customization of a frozen class of geometric designs. The shortcomings are many as indicated at the bottom of the figure.

KBE approach to product parameterization

Now, to meet present and future demands product parameterization should also embrace categories of requirements, performance and life-cycle properties and services. Customer solutions must, within a few hours (as was the case for tankers), be computed according to rules and customer expectations.

Managing Properties and Parameters

Most physical product properties are global properties that can be defined and calculated by formal methods, often available as standards. Examples are  time, costs, dimensions, materials, weight, center of gravity etc. Most functional properties and methods are well behaved, that is their dependencies are predictable. This is indicated on the left side of the figure below.

Human habits, preferences and pragmatic ways of working create informal methods and parameters, which are not predictable. Examples are design and usability features and details required by life-cycle services. These methods, properties, and parameters are not so well behaved. They seldom yield deterministic results, as indicated to the right in the figure below. This means that configuration and design rules cannot be fully automated, Engineering interactions will be required in order to choose a solution among alternatives.

Product parameters in a federated knowledge architecture

Product properties, configuration and design parameters should therefore be modeled separate from objects and relationships, see Property Modeling – The Blind Spot of Object Orientation.

The figure above also illustrates the huge gaps in data definition and use. Current IT systems do not adequately support design and evolution. A root-cause is the static out-of-context data models. Current data-models are fine for persistent storage schemata, but do not provide any support to conceptual or functional system design. Most informal, local methods and parameters are lost. The same parameter sets are re-defined many times by different disciplines in each of the product structures..

Final configuration parameters and rules setting customer preferences are normally decided late in the design stage, or whenever the parties agree to freeze the design.  With a knowledge architecture, changes can be accepted until the deadline for manufacturing preparations.

One Federated Product Model

Product Lifecycle Management (PLM) systems have been applied for the last fifteen years and the verdict from leading industries is clear. PLM systems are too rigid, give poor support for conceptual design, functional systems engineering, and do not support recent advances in operational intelligence and model-configured methods.

There are no shared property and parameter-structures, and no role-specific parameters and value-sets to support concurrency, aggregation, range control, balancing of values. Operations on real-time data across teams, disciplines and projects are not possible. What is missing are capabilities that would involve rethinking data modeling, and methods that support lifecycle knowledge creation, sharing, operation and reuse.

Products are currently described by as many as 8 to 15 disjoint product structures created in prescribed data-models. This introduces many discontinuities and coordination problems, and thus prohibits life-cycle iterations, integration and information flow management.

The most familiar product structures are:

1. Arrangements or conceptual layouts to express functions and capture requirements
2. Topological structures for defining geometric element connectivity and features
3. Functional system structures to define properties and interpret requirements
4. Geometric structures for calculating dimensions and tolerances, and defining shape
5. Material lists or Bills of Materials (BoM), derived at stages, to define material demands
6. Technical product structures to support the many engineering calculation methods, such as centre of gravity, strength, vibrations etc.
7. Module and part structures to plan for manufacturing and assembly variants
8. Assembly structures and part-lists for assembly, maintenance and repair

A knowledge architecture has capabilities to capture all these structures in one integrated or federated product model, and to support component and product configuration rules and methods. Demand-driven customer delivery, reducing the need for interactive engineering can be openly implemented. Interaction with designers from relevant disciplines will however be needed in order to implement the family concept (see below).

Innovation projects, involving product designers and suppliers, are required to deliver rule-driven functional system composition, modularization, and life-cycle operation services. The key content of federated product modeling is illustrated below.

Typical content of a federated product knowledge architecture

The logical rules to design preferred system variants and modules must be modeled by teams involving the system suppliers and their supplier networks. This means sharing requirements and knowledge, and enabling visual proactive collaboration, top-down as well as bottom-up. So, we need to separate the knowledge domains defining the logic and methods, and those defining their key parameters, values and value ranges. Specific customer variants depend of varying values, while market variants are mostly based on logical and structural rules. These rules must themselves be configurable.

Configurable Product Platforms

Conceptual design and functional system engineering need role-oriented visual modeling, and adaptive computing based on emergent knowledge architectures. Visual Solutions Development methodologies must be applied to express rules for configuring across the three layers of concepts, functional systems and components. This demands a holistic design approach to market, customer-group and customer-specific solutions, as illustrated in the figure below. The core product model has to be developed, then we need to align it with market and business requirements. The rules and parameter dependencies (values) that connect these layers can not be specified a priori. They depend on design preferences, late customer decisions and key parameter values.

Knowledge layers in the product life-cycle

In the end design is a question of communicating and sharing requirements, concepts, specifications and operational experiences among customers, suppliers and other actors involved. It means agreeing on the meaning of data, and balancing parameter values among engineering disciplines. The final set of validated requirements, performance, configuration and design parameters becomes available in the as-delivered product models for lifecycle support.
Knowledge architectures connect business architectures and IT architectures, introducing modeling methodologies and principles that define work-centric knowledge spaces and executable workspaces. This is the basis for making the best of human creativity as well as digital computing.

Product Families

A product family is a set of variants that share the same external properties, such as design principles, common laws of physics, functional behavior, performance and usability properties. Requirements and constraints are also part of product family definitions.

A family tree should be created when there are very different requirements and constraints, and different design principles apply. As an example, consider the huge family of vacuum cleaners. There are sub-families depending on brands, usability, capacity, durability, ease of operation and so on, but the main function is cleaning. Most industrial products have distinct sub-families based on many major differences in design constraints and principles.

A family is best characterized by categories of external properties such as requirements, constraints, usability, functions, features, services offered, and values created for product users. The latter are often expressed as performance parameters. In contrast, industrial classes are defined by internal parameters and design rules.

Product family development is best performed in innovation projects, applying operational methodologies to build active knowledge architectures that support holistic design. Holistic design implies simultaneously modeling of multiple enterprise knowledge spaces and dimensions, in order to meet growing business, customer and technology demands. From a federated product perspective, customized products can be semi-automatically configured, manufactured, and supported for life-cycle operations. To achieve this agility, components of a Collaborative Product and Process Design methodology, and are adapted using the Visual Solutions Development methodology (posts describind these are in the pipeline, see this post for an introduction).

Need for a New Design Methodology

There are many design methodologies out there, mostly created by design theorists. Utilizing a knowledge architecture, networked conceptual design teams will create new operational structure views, that if visual modeling principles are applied will act as descriptive or meta-views for the functional system designers.

Operational and descriptive views on product models

This role-specific reflective behavior is illustrated in the figure above. By exploring the layers of design knowledge and defining clear roles and responsibilities, we minimize the need for meta-modeling, allowing designers to build a single integrated and federated product model. Any structure, aspect or view created by any design role, discipline, engineering team or person will become specifications or descriptive knowledge, along with methodology views, for other designer roles at the layer below, or in another system.  Role-oriented reflection is a key principle in knowledge architectures.

By applying these methodologies, customers create federated product family descriptions, representing knowledge families and classes, in what is called an active knowledge architecture. The architecture also contains rule-driven structures and knowledge elements that help users configure concepts, functional systems, and customer product delivery models, working environments and workplaces. This approach gives designers and engineers proactive visual languages to express and share their data in collaboration with suppliers and customers. Using visual languages they can continuously capture work logic, build product knowledge architectures, and close the gap between design and operation.

Federated Product Design Methodologies

Integrated operations, concurrent design and engineering cannot be supported by pre-configured IT application services and tools alone. Ideation and conceptual design include formulating the visual artifact language to express design intent, and build the initial knowledge architectures. This is needed to support collaborative team-building, knowledge reuse, and to prepare for future business challenges.

Visual workspaces, scenes of action, will give clarity to what theorists call the fuzzy front end, creating traceability and predictability throughout the entire product life-cycle.  Design and life-cycle management requirements can be summarized as:

1. Design is about defining, creating and sharing data, knowledge views, dependencies and flows
2. Designers must be able to express their data and develop, share and cultivate knowledge
3. Designers create many kinds of rules that must be defined and managed in context
4. Design is creative work, where aspects of work must be captured as emergent task-patterns
5. Designer knowledge exists as both perspective and work-centric views in mental models
6. Mental models must be stimulated and supported by knowledge architectures
7. Visual artifact modeling languages are needed to capture and support designer collaboration

Future design platforms must support holistic approaches, and provide operational intelligence to both project execution and product life-cycle management. Business teams must be actively supported by adaptable integrated methodologies, and involving the roles and methods of process, organization and system disciplines.