The Edinburgh Designer System (EDS) provides a coherent set of inference engines which operate upon a common formalism appropriate to the representation of engineering designs in general. This formalism stems from the work of Barrow, but has been extended in various ways, including to provide for the representation of the evolution of a design. The exploration of the space of possible designs follows early work work of Latombe.
In the EDS, a design is specified in terms of modules, which are engineering functional units (eg a motor or a keyway or a shaft). Thus modules are not necessarily rigid bodies, but may be features of bodies (eg an oilway) or assemblies of bodies (eg a gear-box). The extension of the EDS to deal with plan formation requires that modules be regarded as existing in time, for example the activity of drilling of an oilway or the support of a shaft while a gear is fitted to it.
Barrow specified interactions between modules in terms of connections between ports of modules. This formalism is appropriate for his domain (the logical analysis of VLSI designs) because interaction between modules always occurs in a standard way through conductors. However in general engineering, interaction between modules can take place in a rich variety of ways, so that knowledge about such interaction cannot be regarded as a static part of the EDS. Considerable conceptual economy can be achieved by treating the interaction between modules as a module in its own right, called an interface module. Such interface modules can be regarded as establishing a relational network or graph upon the concrete modules.
Modules have parameters, which are symbols denoting quantities which are determined at design time, and variables which are symbols denoting quantities which may vary while the module is operating. For example a gear has as one of its parameters the pitch radius, and as one of its variables its angular velocity. Interface modules will define constraints upon parameters of the modules connected by the interface. For example the interface module meshing_gears equates the pitch line velocities of the two component gears. The parameters and variables of particular modules are ground level terms. For example r$g1 may denote the pitch radius of the gear g1.
Modules are classified in a taxonomy, which is part of the formal support of the exploration of possible designs. For example, having decided that g1 belongs to the module-class gear,a further step of detailing it is to decide that g1belongs to the module-class spur_gear. Other important steps in detailing involve deciding on values for parameters, and using one of the engines to determine new relationships.
In the EDS, the representation of shape is supported by a Constructive Solid Geometry (CSG) modeller. makes use of the Cameron's ROBMOD modelle, but an interface to the
We use the term inference engine for any program which applies some body of knowledge relevant to the EDS. Such an engine will typically follow paths in the relational structure placed upon concrete modules by interface modules, and infer new relationships between entities which are at some distance from each other in the original structure, or it may derive new relationships by examining cycles in the structure. The inference engines typically perform forward chaining upon facts about the design: it is necessary to place strict limits on this chaining to avoid an undesirable proliferation of deduced facts.