research:axiomatic_information_model_for_design

All formalisms that treat processes, from action logics to model theories, assume the existence of a language able to describe the *domain of interest*. To formalize design engineering, which is inherently process-based, we need to have such a language. AIMD is a representation language that covers the domain of designed products; that is, it is a theory that describes product modelling languages.

**NOTE:** Design mereotopology supercedes AIMD.

The current version of AIMD is based on axiomatic set theory (ST). There are some problems with the interpretation of ST in this domain that suggest it may not be the right formalism. (See design mereotopology for a new approach.)

In its current incarnation, AIMD covers quantities, features, parts, assemblies, and systems, and types of all these. AIMD provides the means to reason about products in a logically rigorous manner. For example, AIMD demonstrates the superiority of fixturing and self-fixturing assemblies, strictly from a logical (rather than an engineering or technological) point of view.

The current version of AIMD is described in [Sal96a].

AIMD's main goal is to represent formally the basic characteristics of design products in a manner consistent with typical product modeling practices. In order to address the shortcomings in the current version, mereotopology is being investigated as an alternative formal approach. This includes three major components:

- part-whole relationships (e.g. the piston is part of the engine),
- topology (e.g. the piston is connected to the crank), and
- abstraction hierarchies (e.g. “a car is a vehicle”).

With respect to product centred modelling, AIMD is a *language theory*. It describes the logic that must be supported by any product modelling language.

AIMD is based on set theory. There are some problems with this approach.

In Equation 6 in [Sal96a], Separation prevents a predicate used to specify a part relation from refering to the part over which the relation is being defined. So a predicate like

`part-of(p, W, R)`

is not allowable if `R`

refers to `p`

.

For parts/assemblies, one way is to get around this is to define the predicate as identifying the instances of topological relations between parts, and assuming that any valid collection of instances of topological relations between parts, must define a valid assembly.

But this is a topology-based approach; that is, it defines parthood with respect to topology. This is only one way to handle mereologic relations, and not necessarily the best.

This is typical in bottom-up (configuration or component-based) design processes. Parts are chosen and connected together (say, in a CAD model). The whole comes into existence once all the parts are connected together correctly.

How can top-down processes be represented?

- Should not formalization of geometry also be a component of the goal of AIM-D?
- How are abstraction hierarchies affected by an adoption of mereotopology rather than set theory?

**Taking account of domain granularity:** To what level of detail are we interested in representing “reality” with a logical system? Whereas a materials engineer will probably be interested in microscopic or atomic properties of materials, a structural engineer will probably not. In seeking a universal representation, should not every possible degree of granularity be represented? I think not, if we have contexts available with which to partition knowledge and share it as appropriate or required.

**Extending current theory on features:** The notion of a feature is particularly important in the interface between design and manufacturing, but it can also be the *glue* that connects product modeling to geometric modeling. What exactly is a feature? How are they best described? What axioms are needed to represent these notions consistently within AIMD as a whole?

**Modeling product function:** AIMD currently defines the structural side (shape, size, composition, etc.) of products. But what about the functions provided by those structures? A functional definition of a product ought to precede its structural definition. How can this be done using the axiomatic approach of AIMD and preserve consistency of the theory as a whole? Current thinking generally accepts that the 3 basic functions of engineered products are transfers of (a) mass, (b) energy, and © information. How can this be incorporated into AIMD? What classification structures are needed to get from these abstract functions to more pragmatic definitions of, say, freely-pinned connections?

**Temporal aspects of design processes:** Functions of designed products occur over time. AIMD does not capture the notion of time (in the current version, time is considered constant). What temporal representation can be incorporated into the theory while maintaining the overall consistency of the theory? What would be the implications of such an advance for design processes that are currently in use or proposed in the research literature?

**The part/whole relation:** (see design mereotopology) The study of the relationship between a whole and its parts is called mereology. For some reason I can't understand, it has been largely overlooked in the development of ontologies for design in favor of taxologic considerations. What work does exist in mereology seems to be solely in the general area of knowledge representation and AI. What does this work imply for design? What alterations are needed to be able to incorporate mereologic concepts directly into AIMD?

**Partonomies:** A partonomy may be a good formalism for the three-way division in AIMD of assemblies, parts, and features. How good a fit is there here?

**Topological considerations:** Mereology is a depth-wise relation, relating items at different levels of complexity. Topology, on the other hand, determines the interrelationships between items at the samelevel of complexity. For example, mereology determines that pistons and cylinders are parts of automobile engines, but topology describes how the pistons are related to the cylinders. How can topology be treated in AIMD?

research/axiomatic_information_model_for_design.txt · Last modified: 2020.03.12 13:30 (external edit)

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International