Graph-based Design Language (GBDL)

Texts taken from IILS white paper – “Total Engineering Automation”
 

The industrial success in the future will strongly depend on the usage of appropriate knowledge-based engineering tools in the design and manufacturing processes. With the ongoing spread of information technologies in the overall corporate structure companies face four major challenges that stem from historically grown structures:

  • Scattered Data Sources
  • Incoherent Processes
  • Manual Data Exchange via Documents
  • Manual Model Creation and Update

Graph-based design languages pose a new way to encode all aspects of engineering know-how in a universally applicable and executable central model to overcome the above mentioned problems. Design languages support teams of design engineers by automatic consistent model and simulation generation, thus relieving the design team from frequent tedious and error-prone routine tasks.

A design language consisting of a vocabulary, rules and a production system is processed by a compiler to generate a holistic central model of a system – the design graph. Translators, such as for CAD, then automatically generate specific domain models, e.g. 3D-geometry in OpenCASCADE or CATIA.

 

Information flow and automatic model creation with design languages

 

The picture above is explained by the following step-by-step videos using the DesignCompiler43 of IILS for the compilation step. The example used to describe how design languages work is a minimal routing of a wire around obstacles.
 

 
 
 
 

Step-By-Step Video Explanation

 
DesignCompiler43 Project. The DesignCompiler43 is not only a tool to compile design languages into a design graph, it also provides a user interface build on the basis of Eclipse to set up the vocabulary and the rules. With this user interface a new project will be created.

 
 

Class Diagram. Graph-based design languages are a new means for the holistic description of the task of engineering design which follows the composition scheme of natural languages where words form a vocabulary and rules form a grammar. Words in the context of graph-based design languages are the building blocks of the design on which rules operate. The set of all words (building blocks) in the language is called the vocabulary. It is encoded as a UML class diagram.

 
 

Activity Diagram. The flow describing how a design language should be processed is encoded in a UML activity diagram.

 
 

Rule Diagram. Rules encode model transformations. They instantiate and operate on individual building blocks from the vocabulary which in turn are encoded in an extended UML instance diagram. The set of all connected rules is called a production system, which is encoded in an UML activity diagram (shown above).

 
 

Import Wire Routing GBDL. Class Diagram, activity diagram and rule diagram form the graph-based design language and have to be created manually as an upfront investment to the engineering design process. To extend models with domain specific functionality several other prior designed GBDLs can be imported into an existing project.

 
 

Design Graph / Geometry. When the production system is executed by a so-called design compiler (here the DesignCompiler43) the complete design is created automatically and stored in a central model called the design graph, i.e. a holistic digital model of the system containing all parts, interconnections and parameters. From this central data model all other necessary domain models of a system, e.g. a CAD-model or a wire harness model, can also be generated automatically.

 
 

Wire Routing. The previous video showed the generation of 3D geometry which can be exported and then imported into professional CAD tools (e.g. CATIA, Siemens NX) for further editing and if wanted feed back into the design language for recompiling the model. Another use of design languages is the automatic cable routing of wire harnesses as used in use case 3 of the IDEaliSM project. The import and construction of the routing rules is omitted in the following since it is a similar routine as used for geometry.

 
 

Apply Design Change. The real strength of design languages once the complete model was built upfront relies in its fast and simple reuse to make changes until the model satisfies the desired level of detail. Changes then can be made directly in the rules, classes or even activities and will be directly reflected in the design graph and hence in the output domains after another compilation run. The recompilation ensures an always consistent product design across all modeled domains.

 
 
 
 

Advanced DesignCompiler43 Features

Routing Export

The generated wire harness can be exported to various formats e.g. into the VEC format as a holistic wire harness description and STEP format for 3D geometry.

 
 

Code Generation

The modeled classes of a class diagram can be translated into Java code.

 

This enables the ability to define design rules with so called JavaRules. These rules allow to modify the design graph via code without using graphical elements.

 
 

Edition Notice

Several text passages used in this article are excerpts from the white paper of IILS describing their market access with the tool DesignCompiler43 developed at IILS.

 

For further information about the scientific research of graph-based design languages the University of Stuttgart has published several papers in the past which can be accessed via the publication category of this home page.