Taming Electric Drive Train Complexity at Festo with Knowledge Graphs and Reasoning

Tracking #: 3046-4260

Kathrin Gerber
Thorsten Liebig1
Andreas Maisenbacher
Christoph Petermann
Gunther Sudra
Daniel Wurst
Jens Wissmann

Responsible editor: 
Guest Editors SW for Industrial Engineering 2022

Submission type: 
Application Report
This article describes the successful outcome of applying Semantic Technologies at Festo, a global supplier of solutions for factory automation. As part of its Industry 4.0 initiative Festo uses OWL ontology models and SWRL reasoning to capture product complexity in order to power various knowledge intensive applications. We introduce the underlying product ontology model and present the data processing workflow originating from RDBMS tables through reasoning to a SPARQLdriven backend that computes a ranked selection of proper product solutions out of millions of electric drive trains from given parameters such as working range, moving mass, travel time, etc. in less than a second.
Full PDF Version: 

Major Revision

Solicited Reviews:
Click to Expand/Collapse
Review #1
By Dylan Van Assche submitted on 15/Jun/2022
Major Revision
Review Comment:


This paper discusses how Festo describes the components they use for Electric Drive Trains such as controllers, motors, mechanical parts, etc. with knowledge graphs through a declarative approach with the use of standards. They apply OWL/SWRL reasoning for verifying conditions when checking if components are compatible with each other and R2RML to generate knowledge graphs from their RDB. ShEx to validate the quality of their knowledge graphs. Using these knowledge graphs, they built a tool to query these knowledge graphs using SPARQL and make it easy for domain experts to find and select components matching consumers’ requests. This way, domain experts do not have to manually check and find components that are compatible to reduce the chance of selecting incompatible components and speed up the process.


This paper is properly written and provides a detailed overview of how Festo incorporated Semantic Web technologies to select the right Electric Drive Train components given a consumer’s request.


Their application covers millions of components with an in-depth selection process where quality standards must be adhered to at all times; therefore, traceability is provided. This paper shows how important it is for the industry to provide standards of Semantic Web technologies for adoption. The in-depth use of standards shows the sustainability and maintainability of their application for the next few years. This applied approach impacts the work of domain experts and users as they can quicker find the right components while adhering to high quality standards which are automatically verified through reasoning.


The authors explained well the domain-specific parts e.g. electric train drive components and systems before going into the details of modeling them in an ontology, generating a knowledge graph, etc. Therefore, it was easy to understand for non-experts how these components are modeled in the ontology and can be verified if components are compatible. The paper was clearly written overall, but it was not really clear which Semantic Web technologies were used in various steps of the ETL process they explain e.g.: (R2)RML is mentioned in Figure 5 and the text below the figure, but the paper only discusses the transformation of relational databases during the ETL process. It would be useful to discuss more in-depth how RML or R2RML is involved in the ETL process. Same for ShEx/SHACL, it is mentioned in Figure 5, but throughout the paper only ShEx is mentioned. While well-written overall, it still needs proof-reading to rephrase some sentences and correct various typos (see detailed comments).


The paper only links to a datasheet about spindles which are used as an example to explain how such components are modeled in the Festo knowledge graph. The datasheet is important for non-experts to understand the type codes used in the paper such as “ESBF-BS-32-%%-P”. It would be beneficial to provide this datasheet under a sustainable IRI or repository because components get replaced when they are End of Life and so might be the datasheet when the component is not available anymore.



I am missing the bigger problem in the abstract that this application solves for Festo, for example: higher customer satisfaction by faster selection of electric train drive components for a consumer’s request while adhering to high quality standards.


The motivation section clearly explains why Festo wanted to model these components and build a knowledge graph and discusses how the paper is structured. The motivation explains in-depth what I was missing in the abstract.

- “such as a pick-and-place application, furthermore has to comply”: drop “furthermore”
- “by means of the Festo Semantic Platform”: “the” is missing. “by the means of” could be replaced by “through” for conciseness.


The authors introduce the domain-specific terminology and how their model is used in reasoning to verify if components are compatible regarding features, technologies, etc. Later on, an example is given a spindle with its datasheet. The example clearly explains how the modeling happened, but I would like to see a more detailed explanation of Figure 3 to better understand how the different components relate to each other in the data model. The interfacing is explained shortly in the text, but does need to be better aligned with the figure. A possible solution would be adding an example of how components and their interfaces are modeled. Currently, only the interface name e.g. M-C and C-M is given but not how the interface looks e.g. voltage range, mounting holes, etc. Moreover, a more detailed figure explanation would be preferable to make the figure standalone while trying to avoid the blurred parts which makes me wonder why they are not removed from the figure if they are not relevant for the explanation.

- “range from motor with integrated controller”: add “a” or make “motor” plural.
- “non dismountable”: hyphen missing
- “interface structure in between the other”: “in” should be dropped
Rephrase: “With reference to the encoder example the following axiom rendered in Turtle syntax is”

Reference & links

The authors mention negation as failure (NAF) as a non-standard extension of SWRL, but no reference or link is provided.


The authors mention here the use of RML or R2RML but only transform data from relational databases. They do not explain which standard they now actually use; this part needs to be revised. From the example under 3.2 Data Mapping and Enrichment, I think it is R2RML only as I don’t see any RML extensions of R2RML in the mappings.

Figure 5 mentions ShEx/SHACL for quality validation, but the paper only mentions ShEx. The paper would benefit from a ShEx example matching the R2RML mapping to see the complete pipeline.

Later on, the authors mentioned how stable IRIs are generated using stable IDs or hashing to differentiate between revisions of components. I was wondering how revisions are handled by the system. If a new revision makes the previous ones obsolete, how is that being taken care of? This is important when providing a setup to consumers at a certain point in time, which may require different revisions of the components when placing an order.

In the enrichment explanation, the authors mention “compare with the protection level IP65 classification above”. However, I couldn’t find anything related to IP65 in the section. I think an example is missing in the previous parts of the paragraph which they are referring to.

In 3.6 Deployment and Use, the authors mention versioned knowledge graphs, how did the authors handle versions? This is related to the revision comment above.

- Rephrase: “Small errors can multiply an have an impact on large number of inferred drive trains”
“apporach”: typo
- “does not conform this standard”: “to” missing
- Rephrase: “this as next evolution step”
- Rephrase: “as it offers means for declarative description”
- “The highlighting show all directly or indirectly”: shows


This section explains how this knowledge graph and reasoning impacts the consumers and domain experts of Festo. They developed a tool to find the right components given the consumer’s request, available components, etc. Through Semantic Web technologies, candidate components are provided and verified if they match physically with each other. This saves time and improves quality as validation is applied automatically during the process.

Behind the application, SPARQL is used in which mathematical operators and equations are applied to adhere to the laws of physics when proposing candidate components. Parts of the equations here require consumer’s input so they have to be computed at runtime. It would be interesting to see how this scales when the electric drive train setup is huge and contains a lot of these equations.

- “Filter Query Service is built up from a query”: drop “up”
- “Oftentimes”: typo
- “don’t”: do not
- “In principle, the well known formula F = m*a applies”: I would rephrase it, e.g. “In principle, Newton’s Second Law of Motion formula applies: F = m * a”


The authors explained well how they established this data model, knowledge graph and tool and what they learned during the process. They also explain the next steps for their approach such as extending to other domains such as pneumatic linear motion. This will be important to establish an ontology which can cope with the different kinds of linear motion technologies.



Shape Expressions’ abbreviation is written as “ShEx” instead of “SHEX”.
“as well as” is used a lot and can be dropped in various places through the paper

References & links

References to standard e.g. OWL, SWRL, R2RML, ShEx, etc. are missing


Major revision

The paper is well explained, shows how important Semantic Web standards are for the industry, and how knowledge graphs and reasoning can be used to speed up the selection of electric drive train components while still adhering to high quality standards. However, the paper needs to be revised first to include a good running example across the whole pipeline as mentioned in the detailed comments.

Review #2
Anonymous submitted on 11/Jul/2022
Major Revision
Review Comment:

Review Comment:

The paper presents a vital example of the role of some semantic web technologies can play in integrating, enriching, and checking the integrity of data in industrial applications of automation solutions (i.e., at Festo corporate). The paper shows an overview of the Knowledge Graph ETL pipeline used in Festo alongside focusing on the ontology model used as the backend for supporting the best selection of the compatible components of drive trains.

Significance of the results:

Positive Points:

- The paper discusses in-action industrial challenges that customers that seek factory automation solutions may face, like finding the best suitable configurations (according to defined criteria) out of a very wide range of variants while ensuring compatibility of the selected workpieces.
- The employment of a semantic graph (RDF+ OWL) model suits the in-hand complex problem and well represents the high interconnectedness and relationship flexibility among data individuals (components in this case), rather than depending on the typical traditional relational data management systems.
- Quality of writing: The article is well written in general (With some minor typos, will list some below).
- The query process flow in the SEM application is presented in a good shape.

Negative Points:
- Positioning of the work within the space of the related work of incorporating semantic web technologies in factory automation solutions is missing. Examples:
"Software Support for Building Automation Requirements Engineering—An Application of Semantic Web Technologies in Automation, Stefan Runde et.al".
"Software Support for Building Automation Requirements Engineering—An Application of Semantic Web Technologies in Automation Stefan Runde et.al."

- Regarding the motivation, a running example that shows how time-consuming and cumbersome it is when relying on the traditional DB systems for achieving the task would be beneficial to elaborate on the need for KG and reasoning solutions.
- I can understand that the paper is application-oriented and industrial-wise, however, I still believe the solutions presented in the paper could interest those working in this field of factory automation solutions.
For example, there was mentioned some terminology that can be understood only by practitioners, or domain experts (“IP65”).
Experimental evaluation of the performance of the pipeline is very crucial, however, I didn’t see one showing the difference between using it rather than without using the semantic model or quality checks, etc.
- The paper falls quite shallow on some technical parts that require more elaborative details:
I expected more details on the requirement that specifies how data is integrated from the different sources that have different update cycles and maturity levels?
I also expected more illustrative examples (at least one) on the detected errors (Inputs) captured by the validation step, and How SHEX is used for achieving this goal.
What happens when adding new components, and how does this affect, and reflect in the model and the knowledge graph, are there some measurements or experiments for that?

Minor Comments and Recommendations:

- I think extending the excerpt of the ontology with a small example of a component interface graph conceptualization would complete the picture and link the dots.
- I couldn’t really get how the interface conceptualization in the FSP model reflects tot the database normalization, a little bit of elaboration on this part is required (or at least cite a reference).
If it’s done on purpose, Why you are blurring the interface graph (in Figure 3).
Several tools and terminology are used without keeping references or footnotes.
Examples: NAF Skolems, Maven, JetBrains TeamCity, JSON-LD, Google ApiGee…etc.
- An example of the object property hierarchy is recommended (in a form of a listing, or a figure).
- As an organizational comment on the paper’s structure, I recommend starting with the Data Pipeline alongside the requirements (Data quality, ….etc.) section before mentioning the specifications of the semantic model in Festo to further reduce redundancy.
- Figure (6) quality is low.

- Typos and phrases hard to follow:
Keep consistency in using the term “drivetrain” or “drive train”.
Page(5)-Line (30): An simple…
Page(6)-Line(28), the sentence starts with “Ideally, they have shown…” is hard to follow, and needs rephrasing.
Page(6)-Line(30), the “SQL to RDF” is not quite accurate, I think you meant relational data to RDF.
Page(6)-Line(31), the sentence ends with “SHEX” should be “quality checks, we use SHEX”.
Page(6)-Line(42),”...multiply an have ….”.
Page(9)-Line(7),”...an increases of….”.
The reference [10] should be mentioned when SemSpect first mentioned (Page(9)-Line(10)).
Page(12)-Line(40), “pays of..”.

Review #3
Anonymous submitted on 21/Aug/2022
Major Revision
Review Comment:

This paper presents a semantic web solution deployed at Festo that supports product configuration and selection processes, in particular in the area of electric drive trains. The paper describes the data modelling aspects (using OWL RL and SWRL), the data processing pipeline in this industrial level application and enabled applications such as the SemSpect based exploration and the electric motor sizing application.

As an application paper, the following two review criteria apply to this paper:

(1)Quality, importance, and impact of the described application – High
The described application has an important impact on the internal processes as Festo for representing knowledge about drive trains and supporting the configuration/selection process of the various possible combination of such complex tools. The paper reports how the authors have adapted the capabilities of the semantic web technology stack to the particular requirements of the company and have converged to an interesting, high quality data model as well as a complex application life-cycle.

(2) Clarity and readability of the describing paper – Good
The paper is well-structured and mostly easy to read, with the exception of a few typos that should be removed in the next review step. When printing the paper, most images were printed incorrectly (although the pdf version of the paper was always displaying these correctly). Section 5 should be revised to be more factual and rely on less colloquial expressions.

As a commercial application is described, authors were unable to provide the underlying knowledge graph due to obvious commercial sensitivity reasons.

This paper is a valuable contribution to the special issue as it gives insights from industry settings and evidence that semantic web technologies can successfully be used to support industry-strength applications.

Besides some minor comments listed next, a major concern is that the paper does not mention related work at all. Product configuration/selection is an important problem in industry in general, and has also been addressed, among others, using semantic web technologies (e.g., [1]). It is therefore important, that the authors extend the paper with some insights on related work on this problem, describing solution approaches to it both based on semantic web technologies or other technology stacks.

Smaller comments:
•Page 5, Line 42 states that 13 property chains are used. This seams to be in contradiction with footnote 2 on the same page stating that property chains were not used at all. Please clarify.
•For interface modelling, as a related work, the authors might be interested in the modelling approaches proposed earlier in the literature, e.g., in [2].
•End of page 9: “The highlighting show all the directly or indirectly compatible products of a controller in the upper branch” – it would be advisable to add 1-2 sentences to explain to the reader why is this analysis relevant from a business perspective.
•Section 5 contains a high number of colloquial terms that should be revised and removed from a scientific publication. E.g., “serious effort ” => considerable, significant – also consider quantifying this effort in some way. “come up with a reasonable ontology” => design a suitable ontology; “decent” tool – in what ways?; “existentially different” – what exactly do you mean?

[1] Bischof, Stefan, Gottfried Schenner, Simon Steyskal and Richard Comploi-Taupe. “Integrating Semantic Web Technologies and ASP for Product Configuration.” ConfWS (2018).
[2] Tudorache, T., Alani, L. (2016). Semantic Web Solutions in the Automotive Industry. In: Biffl, S., Sabou, M. (eds) Semantic Web Technologies for Intelligent Engineering Applications. Springer, Cham. https://doi.org/10.1007/978-3-319-41490-4_12