Presented at IEEE Spring COMPCON, March 1988, pages 228-229.


Gio Wiederhold

Stanford University

The spectrum of services that an EIS must provide ranges far. We can recognize two orthogonal dimensions:

  1. Design: The reduction of informal specifications to precise mechanical dimensions of the objects being designed, with complete material specification.
  2. Flow: A product has to move through the phases of design for functio- nality, design tests, design for manufacturability, prototype building and test, production planning, manufacture, product test, maintenance, and engineering changes.
Activities pertaining to a design object should proceed in parallel along both dimensions. As the functional specification of a design become firm, tests can be defined, and manufacturability begins to be considered. As the product design nears completion, the flow has reached questions of maintenance, and once it is firmed up, further alterations become engineering changes.

We can, using these dimensions, view the design process as a wavefront, starting small at the origin of our plan, and widening while proceeding in parallel over all phases. The greatest effort takes place where the wavefront is widest, at the time that the design is nearly complete, but other phases of the product flow are still lagging.

Given this model, we notice that there are continuously active parallel tasks to be served by an EIS. Strict task serialization would not only extend the product development time excessively, but also inhibit the necessary feedback. Information from later phases in the product must be able to affect the design tasks before the design is completed, otherwise we are forced to use longer iterative cycles. The feedback effectively creates conflicts between the contibuing design task and the product development flow. Methods must be developed which signal possible conflicts without inhibiting cooperative parallel work.

At the stages where multiple phases are active, the data within the EIS will be viewed from very different aspects. An optimal data structure for the design phase is likely to be unwieldy for a testing phase. Distinct activities within a phase will themselves have differing requirements.

Most task specific design tools have today employ data structures that are specifically well-suited to the task at hand, but because of that view, the data structures chosen are rarely well suited to other tasks. Questions to be posed in regard to the data organization are:

  1. Adequacy of information content.
  2. Adequacy of recognized relationships.
One specific design task is likely to ignore interesting descriptive data about the design object that are not relevant to the task. The data will be organized according to the hierarchical decomposition inherent in the design or evaluation paradigm of that task.

Problems induced by these two aspects are information loss and locality loss. If the information is needed in phase i-1 and phase i+1, and phase i ignores that information, it must be reobtained, merged, and possibly transformed to be available in phase i+1. Similarly, structures have to be rebuilt from phase to phase.

The use of a central database with an EIS seems to have the potential of dealing with the first problem in information loss. The database provides a central resource, the tasks are limited to views. Mapping functions will have to be programmed until we have query languages that permit object construction and view update.

Locality management remains a problem, since locality and access issues are based on accessing requirements, beyond the knowledge of the database system and schema. They must be solved to provide adequate performance for engineering users.

If a database for an EIS can provide dynamic rebinding capabilities, which permit adjustment to current usage patterns, a third of the problems is solved. The remaining issues are: how does one application advise the database system of its access needs and how does the database integrate the diversity of requirements? As databases for EIS become a reality these questions will have to be addressed.

This note is based on experience gained within the US Air Force VHSIC datamanagement task force, supported through a contract with Universal Energy Systems. Research support for this area is supported by DARPA contract N39-84-C211, and NSF grant DTMP 8619595. It was written while the author was a guest investigator with IBM Deutschland, at the LILOG project in Stuttgart.