Graphically Speaking Editor : André Stork Graph-Based Design Languages : A Lingua Franca for Product Design Including Abstract Geometry

An important task in engineering is de ning the geometry of a future product, because it is a prerequisite for both simulation and manufacturing. Modern products are typically complex and may comprise many components and functions from a multitude of different domains such as electrical, mechanical, hydraulic, and thermal. Each domain usually requires a dedicated simulation model to be instantiated in a speci c software tool. Yet, in any dedicated engineering analysis, we are simply viewing the same product from a different domain perspective. That is, a model change induced by ful lling requirements in one domain must be propagated to all other domains to ensure model consistency. If this is done via bidirectional interfaces, it leads to a quadratic increase of interfaces between programs, because each program needs converters to all other programs. Standard formats are the usual answer to avoiding these many interfaces and replacing them with just one for each program domain (such as geometry) to convert to a common standard format, such as the Standard for the Exchange of Product Model Data (STEP). However this only works as long as we stay in the same or related domains. As soon as there are interdomain relationships (which is commonly the case) the standard format of one domain overlaps with the standard format of the other. A solution would be to de ne a new standard format that incorporates both other standard formats. Eventually another domain is added and another and so on. Ultimately this would lead to programs that have to understand model data totally unrelated to their intended task—for example, a thermal analysis program would have to interpret model data for control theory or train station layout—because a truly standardized format includes every possible aspect of product engineering. Therefore, we propose ipping the solution around: create one central model that holds all the information, parts, and their interconnections and parameters for the product design and then feed the destination programs only with the necessary information. We can use a central abstract representation with subsequent mapping to the target domains, thus reducing the number of interfaces to the number of domains and tools. This central abstract model, called the design graph, is generated with the use of a design compiler (www.iils.de/43. html) that processes a design language. A design language consists of a vocabulary, rules, and a production system. The building blocks are de ned in the vocabulary (such as satellite, solar panel, or propulsion system). These building blocks are then used in rules—for example, “Rule A: If there is nothing yet instantiated, create a satellite,” “Rule B: If there is a satellite, create a propulsion system,” and “Rule C: If there is a satellite, cover it with solar panels. ” A production system de nes the sequence of those rules—that is, rst rule A, then rule B, and then C. The design graph is the complete digital (holistic) abstract model of the product. It contains all its entities’ interrelations and parameters including the geometry de nition. From this central model, translators can create speci c domain models in a target program to perform a dedicated engineering analysis. The results are either fed back directly to the central model (such as into the geometry) or are