Active Knowledge Modeling

Properties define the data values that are important in a domain. In product design, properties and parameters are used for quantifying requirements, for setting agreed upon targets, and for assessing the qualities of different solutions. Product data management (PDM) therefore places properties at the centre of attention, and properties are perhaps the most important kind of elements in PDM standards, cf. independent property definition in STEP, and e.g. the DIN product property dictionary. Design methodology processes are defined according to what kind of properties are defined, related, mapped, balanced, estimated, calculated etc. in each step. Generally, required and target properties are defined long before the objects that will eventually possess them are properly identified or classified.

Yet in IT, properties and attributes are normally treated as second class citizens compared to objects. In database schema, they define the columns of entities, while in object oriented design, they are just subordinate features of object classes. OWL (Web Ontology Language) is a notable exception. It supports property modeling independent of object classes. In the reflective variant OWL Full users may remove the differences between objects and properties, to model features of and relationships between properties. This variant is however seldom applied, because it cannot guarantee sound formal reasoning for automatic execution. In information systems research, Jeffrey Parsons has shown how properties determine classification structures, rather than vice versa. These examples, however, are exceptions to the common practice. This is why our modeling principles include the representation of properties as first class citizens.

A knowledge architecture should express the core knowledge in business terms. Because of the lack of attention they pay to properties, most common modeling frameworks are unsuitable for product design and engineering. This article explores which property modeling techniques are needed.

Global Property Classes

In general, an overview of product design can be given in terms of a few global classes of product properties:

• Form
• Function
• Physical
• Material
• Environment
• Economy
• Production and manufacturing
• Lifecycle, e.g. operation and maintenance
• etc.

These property classes, or aspects, are more general than object classes, which tend to differ across industries and kinds of products. They are also more stable throughout the product lifecycle. In product development, object classes initially deal with concepts and functions, later you need a new set of classes for systems and subsystems, then probably yet another for different geometric areas, and finally for production and assembly modules. To facilitate traceability and knowledge sharing across all stages of the development process, property classes are thus more useful. Finally, properties are often defined prior to the objects. Requirements lead to target values and functions, which designers parameterize before they decide which object classes should be applied in a given conceptual design. Indeed, selection of alternative object structures is typically determined by the required product properties.

Property Specialization and Composition

In a given industry, the global properties above need to be specialized and detailed to fit the particular features of a specific kind of products. The example below is still rather general. Here the core property aspects (in red) are specialized into more specific aspects (in green). In the centre, we find four kinds of parameters that have different roles in the product development process (see below).

General classes of product properties

Properties are further specialized and decomposed, e.g. to increase precision as the design unfolds. For instance, the geometry of a product part may be given initially as a 3D envelope (height, width, breadth), but later, a detailed geometry shape will be defined as a CAD model. These concerns are common for a wide range of object classes. Separate modeling of properties and their interdependencies facilitates traceability between different product structures. When defined in a single place as part of a rich property definition, rather than distributed across all the object classes where these properties apply. Separate property modeling thus helps us to avoid the tyranny of the dominant decomposition problem, well-known to advocates of aspect-oriented programming.

The figure below shows some of the many different product models that are defined during product development. Different models capture customer, business, technology and government perspectives on the product to be developed. All of these models define properties, parameters, and values for the product, so the properties are critical to integrating and balancing the different perspectives.

Different product structures, defined by customer, business, technology, and government perspectives.

Property Aspects and Role-Specific Views

Defining all properties in property specialization hierarchies also simplifies the definition of customized views for different roles. For instance, a product designer may be working also on the economic properties of the product she designs, but she is not interested in seeing all the details of e.g, different cost analysis approaches, which the cost engineer needs in his view. This simplifies the configuration of views in model-driven applications, because property definitions are more general and reusable than object classes.

From Properties to Parameters

So far we have discussed the relationship between properties and object classes, highlighting limitations of object-oriented design. Now it is time to explore the relationships between properties and processes or tasks. In general, a task or method takes a set of property values as input parameters, and produces results as output parameters. Parameters thus reflect the binding of properties and values to tasks and processes.

The application scope of a method is generally defined by the types of parameters it processes. Parameter types can refer to property classes at different levels of the specialization hierarchy. For instance, one cost engineering method may be useful when the cost estimates are very uncertain, while a more precise method should be applied at a later stage, when the estimates are more trustworthy. Different parameter value ranges may also lead to different methods being invoked. For SYSML, an example of a hybrid car has been used to illustrate this. Depending on the speed of the vehicle, different methods are used to control acceleration (using the electric motor or the combustion engine). Not only do  properties control object classification and composition in configurable product structures, they also determine which methods to apply in method engineering.

For traceability and change management, tasks and methods should be represented as relationships between input and output parameters. This implies that if the value of an input parameter is changed, it is easy to navigate the relationship structures of the product knowledge architecture to see which other parameters may be affected. Dealing with all such dependencies at the object level will be too coarse-grained. When the dependencies are represented at the property level, we know exactly which parameters can be affected, and we need not explore side-effects from other parameters of the same objects. If we only represented dependencies between objects, we would need to check all dependent objects all the time, even the dependencies that have nothing to do with the parameter that was changed. This simplification becomes critical when we take into account second, third, fourth order effects etc.

Typically, some dependencies will only be represented as relationships, without formalising the underlying tasks or methods. This makes sense for methods that rely on human reasoning and decision making. Rather than trying to capture the decision making process and rationale, it sometimes makes sense just to state that this parameter influenced this other parameter, and identify the person(s) who made the decision. In general, though, one should always keep in mind the tasks behind, when one sees a relationship in an object model. Combining these reflective views is important for a thorough and simple approach to change management.

Value Sets

Not just properties, but even their values, should sometimes be represented as first class model elements, structured and related to each other. Values for a range of parameters can be grouped into value sets, e.g. to distinguish between

• to-be
• as-is
• as-required
• as-designed
• as-built

… and other situations or alternatives.

Parameter Mapping and Balancing

Different disciplines may also need to have their own local value sets, which contain different values from those of other disciplines. For instance, an engineer performing coarse 3D modeling of a complex product will use a 3D envelope to represent a certain part, at the same time as another designer is working on the detailed 3D model of that part. The ideal situation, that a common consistent view should be shared among all participant, neglects the complex processes involved in parameter mapping and balancing. Sometimes, inconsistencies between views must be tolerated temporarily, to be resolved later. The engineer who models the part in the example above, may for instance have to go slightly outside of the envelope he was assigned, in order to decrease manufacturing costs or improve some other parameter.

Design methodologies such as House of Quality and Modular Management use matrices to capture mapping relationships between different kinds of product parameters. Matrices are used for allocating requirements and functions to modules, for connecting assemblies to parts, for comparing target values to achieved performances etc. SYSML similarly adds a concept of allocation to UML, in order to represent requirements allocation, functional allocation, various logical allocations (assembly-part, input-output), software-hardware allocation etc.

A typical pattern in these examples is the balancing of a target value derived from requirements, budgets, or surrounding specifications, and an actual value that the designers are able to provide, given all other constraints put on the design. Sometimes targets must be relaxed or renegotiated because of conflics with other parameter targets. The relationships between targets and actual values, and between different parameters, go both ways. As one of our modeling principles state, in design all relationships are bidirectional. Design dependencies are complex and non-linear, so neither the design process nor the product knowledge architecture can be linear and formal.

Lessons for IT

If you found the portrayal of product design above naive, I apologise. It is primarily written by an IT professional for other IT people. The objective is to illustrate that IT that have a lot to learn from industrial data management practices. After all, software engineering is one of the least mature engineering disciplines. Complex physical products needs more sophisticated data models than the virtual information products that tend to dominate our industry, but hopefully this article has shown that software development practices can be improved by insights from more established engineering domains.