The “competence” entity is related to the
technical aspects via an n:m relationship. This
means that a “competence” consists of n technical
aspects. Vice versa, a technical aspect may occur in
n “competences”. However, this n:m relationship is
subject to a semantic constraint that cannot be
expressed by the ER model: Since the technical
aspects on level 1 of the tree form independent
taxonomies, a competence may only be related to
such technical aspects that do not have a node as a
common parent (i.e., that originate from different
taxonomies). Thus, it is ensured Together with the
“is-parent” relation, the entity “technical aspects”
forms the generalization hierarchies for the technical
aspects (procedure, material, …). Consequently,
each entity that does not refer to a corresponding
parent node is considered to be the root of a
taxonomy. Hence, the requirement of flexible
taxonomies is fulfilled.
The technical parameters that are related to the
technical aspects via the relation “has” allow for an
allocation of the production- and product-specific
parameters to the technical aspects. According to the
semantics of the application, the technical
parameters of the technical aspects are inherited to
all specializations (child nodes in the taxonomy
tree).
Separation between the technical parameter and
parameter value allows for the variation of the given
default value (or interval) for a technical parameter
in the individual taxonomies.
The “competence” entity is related to the
technical aspects via an n:m relationship. This
means that a “competence” consists of n technical
aspects. Vice versa, a technical aspect may occur in
n “competences”. However, this n:m relationship is
subject to a semantic constraint that cannot be
expressed by the ER model: Since the technical
aspects on level 1 of the tree form independent
taxonomies, a competence may only be related to
such technical aspects that do not have a node as a
common parent (i.e., that originate from different
taxonomies). Thus, it is ensured that each
competence from each taxonomy tree contains a
single value of a technical aspect only.
2.3 Knowledge about Relations among
and Constraints of Process Steps
State-of-the-art process documentation typically is
performed in line with the requirements of a quality
management system which usually describes product
specific processes on an organizational level. The
ProWiDa methodology aims at showing the relations
among the process steps in a more transparent and
with that transferable manner, which also allows for
an improved reusability of the product specific
production information. These meta parameters are
additional or different properties resulting from the
combination of single process steps in a process
sequence or process chain.
2.3.1 Modeling of Technological Parameters
along the MST Process Chains
The modeling component allows for a simplified
modeling of MST processes (sequential and
parallel). Three major elements serve to describe a
complete production process:
The process chain element represents an
order/product-specific set of process sequences. It is
equivalent to the model of a product or customer-
related production process.
The process sequence represents a characteristic
of a basic technology.
A technology is represented by a set of process
steps. The process step itself is the smallest
modeling element (represented by a competence)
which represents a subtask that has to be executed
when processing a technology.
The complexity of such a process chain directly
depends on the complexity of the MST system to be
produced. MST parts may consist of a small amount
of process sequences, while complex MST
subsystems, e.g. a sensor, comprise larger numbers
of process sequences, completed by additional
sequences for assembly and manufacturing.
2.3.2 Corresponding Data Model
To model the workflow functionality, a simple, but
flexible model is selected (figure 3), as described in
the section above. The key component is the
“activity” that is given by the above specializations
of “process chain”, “process sequence”, and
“process step”. Any complex hierarchical workflow
can be modeled by the two types of relations of
“hierarchy_relation” and “flow_relation”. The basic
element to generate the workflow, however, must be
an activity entity of the type “process step” that is
related to a “competence”. Consequently, the
“competences” defined above are the basic elements
of the workflow. In analogy to the “technological
aspects”, adding of additional “technological
parameters” is possible.
AN ONTOLOGY-BASED APPROACH TO SUPPORTING DEVELOPMENT AND PRODUCTION OF
MICROSYSTEMS - Process-Related Documentation for Process and Application Knowledge Management in
Microsystems Technology
515