Product Design Ontology (PDO)

Ontology Overview

The PDO focuses on two important phases of the product development process: styling and simulation. Free-form styling is an early step in the product development dedicated to the conceptual definition of the functional and aesthetical characteristics of a new product; the engineering simulation stage evaluates the physical behaviour of any engineering component constituting the whole product, which is subject to various kinds of loads and conditions. The typical workflow of engineering simulation consists in tessellating and simplifying the original CAD model, then applying boundary conditions and performing FEA on this mesh, and finally post-processing to interpret the simulation outcome.

Within the AIM@SHAPE network we have developed a PDO to be applied in e-science scenarios especially useful for researchers working in the development of tools and methods supporting industrial product design and engineering analysis. The main purpose of the PDO is to formalize process, tool and shape know-how relevant to the phases of the product development process, i.e. the free-form styling and the engineering simulation. The PDO tackles the following aspects:

• Processes and workflows relevant to the two phases of the Product Development Process considered;
• Role of shapes along the Product Development Process to interpret the additional related information, which intervenes in a specific task of the design workflow;
• Condition type hierarchies: Any kind of condition a shape role must or should satisfy has been modelled. In particular, all the conditions involving geometry for B-Rep and mesh representations are grouped in the geometric condition type hierarchy, while the conditions related to the task to perform have been grouped in task condition type, with particular attention to the boundary condition type hierarchy which corresponds to the taxonomy of boundary condition types associated to a mesh during the analysis stage;
• Functionality and usage of shape processing methods and algorithms adopted in the free-form modelling and engineering analysis phases in order to model and analyse a shape according to the specific needs of the design task
• Grouping mechanisms useful for researchers and experts involved in the product development process to gather together models which are related one another, such as:
• Grouping shapes representing the same object in different representations and different formats
• Grouping shapes representing different variants of the same product
• Grouping shapes belonging to the same product category
• Grouping shapes belonging to specific chains of shape processing operations

The following figure shows the different facets of the PDO:

The Ontology for Product Design has undergone for test cycles and it is able to answer to several CQs related to such application scenarios. To answer the CQs we have used the Semantic Search Engine (SSE) developed within the AIM@SHAPE network. In addition, the ontology structure has been validated by all cluster members and by researchers working in the area of shapes and semantics in Product Design.

You can browse through all cluster ontologies and test them with queries using the SSE here: http://dsw.aimatshape.net/sse/Search.jsp?ontology=shapes

Core Concepts

The Ontology for Product Design (PDO) has the following objectives:

• Guiding researchers and developers in e-science scenarios in the development of tools and methods supporting industrial product design and engineering analysis;
• Formalising process, tool and shape know-how relevant to the free-form modelling and the engineering simulation phases for training purposes.

The key concepts of the PDO are the tasks of the product development process, and the shapes and tools adopted in the different tasks. The concept of Task is central to describe the workflow where the different shape representations are used and the different shape processing tools are applied. The concept of ShapeRole of shapes along the product development process has been formalised to interpret the additional information related to the shape which intervenes in a specific task of the design workflow. The different Condition Types required to the shapes, which are necessary or preferable to perform a certain task have been also classified.

Since shape types and representations, shape processing tools and algorithms are common to all the expertise domains of AIM@SHAPE, they have been modelled in the AIM@SHAPE Comon Ontologies. The PDO specialises these conceptualisations for meeting the Product Design requirements. For instance, the metadata of the shape representations most relevant for the Product Design domain, i.e., Boundary Representation (B-Rep), which multi-patch parametric surfaces belong to, and Mesh, which is employed in the simulation scenarios, have been fixed also consistently with the Product Design requirements.

The Task Concept

The product development process modelled in the PDO is aligned with the Application Activity Model (AAM) of AP214 of the ISO Standard 10303 (STEP - Standard for the Exchange of Product Information). The conceptualisation of the workflow relies on the concept of Task together with the relation of Successor, Predecessor, SubTask and SuperTask, which permit to model the complexity of the process. The task is related to the suitable shape representations used and the specific shape processing tools applied according to the goal of that development phase.

Here are some sample Competency Questions (CQs) related to the Task concept:

• Which software tools support the Task Meshing?
• Find the tools which execution platform is Windows 2k that save suppressed details (e.g., through holes) and have as input a tessellated model with format stl and have as output a model with format stl.
• Find the tools which execution platform is Windows 2k that perform defeaturing (or simplification), and have as input a polygonal triangulated model with format stl (or iges, STEP).
• Find a tool which determines the influence of each suppressed detail on the simulation results.

Shape Roles

The Shape Role concept enriches a Shape Type with:

• Shape Conditions: necessary (or preferable) geometric conditions that have to be satisfied by a shape type in a certain design phase. For instance, to perform a simulation task, a conformal mesh is required.
• Task Conditions: necessary (or preferable) conditions required to perform a certain task. For example, the boundary conditions are necessary for simulation. They can be mechanical but also geometric.

The PD Model concept has been introduced to model the shape role of a specific shape (that is an instance of ShapeRepresentation of the Shape Ontology). In this way, it is possible to capture, for example, that a shape is a simplification of a given CAD model according to certain conditions (associated to the corresponding Shape Role).

In the following we show some sample CQs related to the ShapeRole and PDModel concept:

• Find a simulation model, which ShapeRole is post simulation mesh and which has boundary conditions of the specified type.
• Find a simulation model, which related mesh fulfils the demanded properties (given format, mechanical part, real object) and which ShapeRole is a finite element meshwith boundary conditions of the specified type.
• Find post-processing algorithms or post-processing software tools that work with a given type of simulation results.

Shape Condition Types

Any kind of condition a shape role must or should satisfy has been modelled with the concept of Condition Type, both related to the shape and to the task.

In particular, all the conditions involving geometry for B-Rep and mesh representations are grouped in the Geometric Condition Type class, while the Boundary Condition Type class corresponds to the taxonomy of boundary condition types associated to a mesh during the analysis stage. Not only geometrical conditions and boundary conditions have been considered, but also some more complex ones directly related to mechanical criteria, even if acting on the geometry.

Here are some sample CQs related with Shape Condition Types:

• Find shapes that are SimulationResults of a FEA of given BoundaryConditionType, that are possibly real-world objects, and that are in a given format.
• Find the FE analysis tools which perform a ThermalAnalysis, which execution platform is Windows 2k and which have as output a model with format abaqus (or ansys, unv).

Grouping Mechanism

Several shape grouping mechanisms are useful for researchers involved in the product development process to gather together models which are related one another for some reason for further reuse:

• Grouping shapes representing the same object in different representations and different formats
• Grouping shapes representing different variants of the same product
• Grouping shapes belonging to the same product category
• Grouping shapes belonging to specific chains of shape processing operations
• Grouping shapes belonging to the same assembly

In the following we show the part of the ontology which covers the formalisation of groups.

The Group class has the subclasses AssemblyGroup, VariantGroup, SimplificationGroup, and AnalysisGroup, which correspond to the categories of the groups we treated. The relation hasElement has values in PDModel. In this way we are able to answer CQs like "Find the Simulation model whose role is PreSimulationMesh and that belongs to an analysis group also containing the post-simulation model given."

The AssemblyGroup has only the restriction that any subgroup contained is an assembly, and gives the possibility to specify the graph structuring the components through the relation hasStructuralGraph. The AnalysisGroup aims at structuring the different PDModels related to the simulation phase, requiring that at least a SimulationModel belongs to such Group

Here are some sample CQs related to grouping mechanism:

• Are there PDModels that belong to an analysis group?
• Find all the elements (either PDModel or groups) of a given group.
• Find all the groups (the kind of group could be specialised too) that contain simulation models whose role is Post Simulation Mesh.
• Is there an analysis group that contains a simplification group?