Current industrial information systems maintain and process immense amounts of knowledge to be used for the development, con guration, and production of artifacts. From a logical point of view these elements process knowledge abozt the same concepts albeit existing in di erent information systems. From a practical point of view, however, the systems are only loosely coupled and only have little linkage. These semantic gaps prevent a seamless analysis and evaluation of the entire knowledge, which in practice, is of signi cant importance for productional success. In this paper, we propose a general high-level ontology that integrates with the knowledge of the information systems and enables the analysis and evaluation tasks. We describe the basic concepts and properties of industrial knowledge and motivate a number of general evaluation tasks.
The manufacturing industry is currently moving fast from traditional manufacturing processes to digitalized processes. This transition also includes the full representation of so-called digital twins of the manufactured artifacts. Digital twins are the enablers for mass-customized products that deliver premium quality of single-slot products at the range and costs of mass production.
The representation and handling of these twins, however, typically ranges over a wide range of industrial process systems within the IT landscape. The di erent interfaces of these systems act as a barrier for the data sharing and linkage and thus prevent a full digital handling of the process. These systems also hold knowledge about con guration and manufacturing processes that need to be shared between the systems. Today, often a manual transition between the system borders is developed which is complex, error-prone, and time-consuming. Also a full knowledge process is not possible due to the system borders. This prevents...
{ a consistent development semantics of the manufacturing knowledge; no semantic gaps between system transitions, { a simple and lossless connection to existing information infrastructures within or outside the company, and { a comprehensive and complete quality assessment of the knowledge (validation and veri cation).
Semantic technologies are a key enabler for archiving these goals [
This paper will focus on the last issue described above, i.e., the quality
assessment of distributed knowledge. We present an ontology for describing the
typical artifacts of a producing company:
{ products and their structure
{ features and feature items of products
{ relational knowledge for customization and con guration
Despite general approaches in knowledge-based con guration [
The remainder of the paper is organized as follows: We rst introduce a general ontology for con guration items, i.e., artifacts that are produced in industrial manufacturing. In Section 3 we brie y sketch, how di erent knowledge bases from distributed knowledge bases can be integrated into the presented ontology. We show uses cases of analysis and evaluation in Section 4. The paper concludes with a discussion of related and future work in Section 5. 2
A reusable ontology for industrial manufacturing needs to represent di erent products, that are de ned by feature values. Di erent types of knowledge constrain the combinatorics of features but also of products, see Figure 1. In more detailed, the following key concepts need to be explicitly de ned: Product portfolio: A product portfolio includes all artifacts produced by a manufacturer. These artifacts are named products and are typically organized in a hierarchy. Products itself run through a life cycle yielding di erent product versions.
Features: A single product is characterized by distinct features. The collection of features for a produced product is often called a con guration. These features are sub-classi ed into di erent types, i.e., features with a numerical has constrains
constrains
Knowledge feature value (e.g. length) versus features with discrete values (color). A larger number of features is organized in a hierarchy, for instance, in order to mark the origin or use of the feature. Typical origins of features within a company are the sales department, engineering group, and the production department.
Relational knowledge: The values of some features are dependent on the
assignment of other feature values and/or product types. One example is the
calculation of a total product weight that is dependent on the single weights
of the included features. Another example is the prohibition of a distinct
feature value combination, e.g., a roof antenna for convertible cars.
In the following, we will describe these elements in a more formal manner. For
the de nition of the manufacturing product ontology we used a derivation of the
SKOS ontology [
The product portfolio organizes all produced artifacts of a manufacturer in a loose hierarchical structure, see Figure 2. The class ProductPortfolio wraps all products and is derived from skos:ConceptScheme. A distinct product acts as a root of the portfolio using the property topConceptOf. The hierarchy of the portfolio follows the composite pattern. It is created by instances of Product, that itself can have successors of Product by using the property superProduct (a derivation of skos:broader). There exists special types of Products to represent the group of concrete products in model families and model lines (also known as series).
The life cycle of products is modeled by di erent product versions. That way, a ProductVersion instance is assigned to a concrete product to represent the life cycle version of this product. Each product version has a start date and an end date, that de nes the validity of this version. Often, di erent model years skos:Concept LinkedConcept
ProductPortfolio
Product topConceptOf hasProductVersion
ProductVersion follows validStart / validEnd superProduct xs:date ProductLine
ProductFamily are represented by di erent product versions. Here, the particular calendar years are the valid dates for the product versions. 2.2
A product is characterized by its possible features. More precisely, a concrete product version de nes a collection of features, that are available in this version. It is worth noticing, that all available features are described for a product and that the combination of some features may be not possible in a concrete instance (e.g., feature electric engine vs. gasoline engine in a automotive setting). Figure 3 shows that Feature instances are organized hierarchically by the superFeature property, a derivation of skos:broader. Di erent types of features are characterized by the value type it can be assigned to. We de ne NumericalFeature storing numerical oat values (e.g., length of a car)and ChoiceFeature having a prede ned list of possible choice values (e.g., color of a car). Consequently, we introduce properties for assigned choice values to Features (possibleValue) and initial values (initValue, sometimes used as defaults). For choice values it is possible to state an order between the di erent values by the property valueOrder, e.g., for a feature doors the ordered choices two, four, and ve.
An assignment between a value and a feature is captured by the corresponding class assignment, that provides the property hf (has feature) to reference the feature instance and the property hfv (has feature value) to reference the value. Please note, that the value class need to correspond to the assigned feature class.
A concrete instantiation of a product is manifested by an instance of Configuration. Basically, a con guration stores a collection of features with concrete values, i.e., Assignment instances. Please note, that the assignments need to reference to features of the same product version. Also, a Configuration instance initValue
hasVersionFeature
possibleValue
valueUnit xs:string hfv usually refers to an ID that distinguishes it from other con gurations. Often, this identi er is called serial number or machine number. 2.3
The features of products are constrained by relational knowledge. As shown in Figure 4, relational knowledge refers to a Condition instance, that de nes the requirements for the execution of this particular knowledge element. These requirements vary between the specializations of RelationalKnowledge: For instance, the condition can state invalid combinations between features and their values (InvalidValues). Furthermore, relational knowledge is used to derive speci c values of features based on the given condition; the derivation is possible for choice features (SymbolicDeduction) and for numerical features (Calculation). A SATConstraint de nes a (often complex) condition, that need to be either positively or negatively satis ed. For a simpli ed analysis and exchange of relational knowledge, all involved features are linked explicitly by the relation involved. We also de ne sub-properties conditionedFeature and derivedFeature for, involved RelationalKnowledge condition depending of the speci c type of the relational knowledge, the features used in the condition but also in the conclusion are linked by these properties.
For the ontological representation of conditions of relational knowledge and
the representation of deductive knowledge in particular, we refer to the rule
language SWRL [
Based on the general ontology de ned in the previous section, we give an example of a meaningful syncing strategy for an industrial use case. As we motivated in the introduction, the knowledge of a producing company is typically dispersed over a number of information systems. For the analysis of the summed knowledge base, the knowledge elements of the particular systems need to be synced and linked.
In an exemplary situation, a company runs a product data management system (PDM) in the engineering department, a customer relations and pricing system in the sales department (CRM/CPQ), and a service information system (SIS) in the after sales department. Also an enterprise resource planing system (ERP) is connected for managing the master data of the company. The knowledge included in these systems considers the same products, features, and interrelations.
Figure 5 shows the proposed approach, where the local knowledge bases are linked with an integration ontology to be used for all analysis and evaluation concept unfpreflebels conceptswleg.peLabds concepts notusedinknaledge concepts walnidderlabels
unlinked
ERP PDM
Yoo Wo 6 sync syXnc 1
Integration Ontology
HE 4 noteovend t sync sync
CRM / CPQ
T
SIS synoAcbobo
Hof
tasks. In a canonical mapping scheme we represent all elements in the
integration ontology, but introduce distinct instances for the elements with local
namespaces in each system. For example, a speci c product p referenced in all
information systems, we also introduce three corresponding instances erp:p,
pdm:p, cpq:p, and sis:p of Product. The identity semantics between all p
instances is represented by the sub-properties of skos:mappingRelation, such as
skos:exactMatch [
This procedure may produce redundant instances at rst sight, but allows for a independent development and use of the di erent information systems and the simple combination of di erent knowledge versions of each information system.
It is worth noticing, that the integration ontology does not include and map the entire depth of the knowledge bases it is linked to, but integrates only that levels of knowledge that are used in the evaluation task. In consequence, knowledge included in the integration ontology can be used for analysis but may be not executable as in the original system. 4
Use Case: Analysis and Automated Veri cation In most cases, the installed information systems provide mechanisms to maintain, analyze, and evaluate the knowledge included in their systems (local evaluation). In a distributed scenario, however, the analysis and veri cation of the combined knowledge represented by all systems is not possible (global evaluation). This combined consideration of knowledge is made di cult because of the di erent semantics and missing general interfaces of the particular information systems. With the proposed ontology, a shallow analysis and veri cation of the knowledge becomes feasible for a wide range of participating information systems. We show some examples that motivate that even the shallow investigation of the combined knowledge is valuable for maintaining a steady health state of the knowledge.
In the context of analysis and evaluation of knowledge cases we
distinguish veri cation and validation tasks [
We observe two matching features f1 and f2 in di erent models. Both features have de ned values f1 2 M1 ^ dom(f1) = fv1;1; v1;2; : : : ; v1;ng and
f2 2 M2 ^ dom(f2) = fv2;1; v2;2; : : : ; v2;mg : The features are de ned to be exact matches of each other, i.e., exactMatch(f1; f2).
We report an design anomaly (bad smell), when there exists a feature value v 2 dom(f1) that has no value v0 2 dom(f2) with an exact match. That way, both features are to be de ned to be exact matches (twins) but de ne values that are not known in the counter feature. A common reason for such a anomaly is a missing match relation, that was not de ned by the knowledge engineers. Sometimes, however, the change of the semantics of values without the broadcasting to the other information systems are a further reason.
The following SPARQL statement shows a possible query for identifying uneven twins f1 and f2.
SELECT ?f1 ?f1_value ?model WHERE { ?f1 a co:Feature ; co:possibleValue ?f1_value ; co:inModel ?model .
MINUS { ?f2 a co:Feature ;
co:possibleValue ?f2_value . ?f1 skos:exactMatch ?f2 . ?f1_value skos:exactMatch ?f2_value .
FILTER (?f1 != ?f2) } 4.2
We de ne relational knowledge in di erent models that derive feature values for the same features with same or intersecting feature sets in the condition, i.e., k1 : fa1; : : : ; ang ! fb1; : : : ; bmg ^ k2 : fc1; : : : ; cpg ! fd1; : : : ; dqg ; where ai; bi; ci, di are assignments f = v of values v to features f . Two sets of assignments A1; A2 are intersecting, when there exists at least one assignment in each set, that have matching features and feature values, i.e., for (f1 = v1) 2 A1; (f2 = v2) 2 A2 : exactMatch(f1; f2) ^ exactMatch(v1; v2) Please notice, that the property exactMatch is re exive and thus a feature also has an exact match to itself.
We observe a knowledge twin, when there exists an intersection between the sets of assignments in the condition and an intersection between the sets of the knowledge action, i.e.,
fa1; : : : ; ang \ fc1; : : : ; cpg 6= fg ^ fb1; : : : ; bmg \ fd1; : : : ; dqg 6= fg The following SPARQL statement shows a simpli ed query for detecting knowledge twins k1 and k2 in di erent knowledge models, here the sales model and the engineering model.
SELECT ?k1 ?k2 WHERE { ?k1 a co:RelationalKnowledge ; co:conditionedFeature ?f1con ; co:derivingFeature ?f1der ; co:inModel sam:salesModel . ?k2 a co:RelationalKnowledge ; co:conditionedFeature ?f2con ; co:derivingFeature ?f2der ; co:inModel enm:engineeringModel .
FILTER (?k1 != ?k2) FILTER EXISTS { ?f1con skos:exactMatch ?f2con .
?f1der skos:exactMatch ?f2der . } }
A (semantically) identical feature exists in two di erent information systems and is matched, i.e., f1 2 M1 ^ f2 2 M2 : exactMatch(f1; f2). Due to a design decision the type of the feature in M1 is modi ed but this is not broadcasted to the other information system.
For example, the feature fuel tank is a choice feature in the sales system with only two possible values 40 liters and 80 liters. Since the engineering department needs to compute with the actual capacity of the tank, they change the feature class from symbolic to numerical. The exact match relation still exists. In consequence, we arrive at an incompatible concept matching.
The following SPARQL queries for a feature f1 that has an exact match to a feature f2 with class f2Type that is di erent from all classes of f1Type. SELECT ?f1 WHERE { ?f1 a co:Feature ;
skos:exactMatch/rdf:type ?f2Type ;
MINUS { ?f1 a ?f2Type . } } 4.4
There exist two features f1; f2 that have similar names, but there exists no matching relation between them. This simply smell is a indicator for incomplete knowledge, typically occurring for new elements in the (distributed) knowledge base.
The following SPARQL statement implements a simpli ed version of this smell, where we query for features f1 and f2 that have an identical label. A more re ned query would look for similar strings.
SELECT ?f1 ?f2 WHERE { ?f1 a co:Feature ;
rdfs:label ?f1Label . ?f2 a co:Feature ;
rdfs:label ?f1Label .
FILTER (?f1 != ?f2)
FILTER NOT EXISTS { ?f1 skos:exactMatch ?f2 } } 5
For the production of industrial artifacts typically a number of interacting information systems are used. These information systems show a large overlap of concepts they are storing and working with. Nevertheless, these concepts are in principle not linked or matched to each other. This especially makes is di cult when evaluation of the distributed knowledge comes into place.
We introduced a simple ontology for the description of industrial production artifacts. The ontology covers the product world, features, and versions of artifacts as well as a shallow interpretation of con guration knowledge. In consequence, we introduced some evaluation methods to motivate the general use of the ontology.
In the literature, we see a couple of approaches for describing industrial
production knowledge in a semantic manner. For example, Badra et al. [
In the future, we are planing to extend the ontology description with respect to possible relational knowledge. Most importantly, the ontology needs to be mapped to existing information systems already in use in a typical industrial setting, i.e., ERP and CRM systems such as SAP and Salesforce. Also, we plan to de ne and implement an extended catalog of evaluation methods tailored to investigation of distributed knowledge bases.