Diagram for the overview of the production line authored by Antoine ZIMMERMANN's avatar Antoine ZIMMERMANN
The Knowledge Graph (or KG for short) is a data structure that describes the industrial system, the machines, the sensors and actuators, the interfaces, the configuration and the environment of this system. In its largest extent, our KG is distributed, with parts of it hosted in France, in Germany and in Switzerland. The Knowledge Graph (or KG for short) is a data structure that describes the industrial system, the machines, the sensors and actuators, the interfaces, the configuration and the environment of this system. In its largest extent, our KG is distributed, with parts of it hosted in France, in Germany and in Switzerland.
## Preliminaries
Our KG is stored using the [Resource Description Framework](https://www.w3.org/TR/rdf11-primer/) (RDF), a Web standard for data exchange and interlinking on the Web. The largest part of the KG is hosted by Mines Saint-Étienne and accessible in two ways: Our KG is stored using the [Resource Description Framework](https://www.w3.org/TR/rdf11-primer/) (RDF), a Web standard for data exchange and interlinking on the Web. The largest part of the KG is hosted by Mines Saint-Étienne and accessible in two ways:
- via a graph database (called a triplestore) by way of [SPARQL queries](https://www.w3.org/TR/sparql11-query/). - via a graph database (called a triplestore) by way of [SPARQL queries](https://www.w3.org/TR/sparql11-query/).
- in multiple small files that each describe a particular element of the system, with links to related resources (see for instance the description of the [IT'm Factory](https://ci.mines-stetienne.fr/kg8/itmfactory/itm)) - in multiple small files that each describe a particular element of the system, with links to related resources (see for instance the description of the [IT'm Factory](https://ci.mines-stetienne.fr/kg8/itmfactory/itm))
...@@ -17,6 +19,8 @@ To simplify the presentation, from now on, we will use a prefixed notation for a ...@@ -17,6 +19,8 @@ To simplify the presentation, from now on, we will use a prefixed notation for a
The most important parts of the KG are the description of the machines, especially the ones identified as [itm:bosch-apas](https://ci.mines-stetienne.fr/kg/itmfactory/bosch-apas), [itm:dx10](https://ci.mines-stetienne.fr/kg/itmfactory/dx10), [itm:vl10](https://ci.mines-stetienne.fr/kg/itmfactory/vl10), and [itm:xy10](https://ci.mines-stetienne.fr/kg/itmfactory/xy10). The most important parts of the KG are the description of the machines, especially the ones identified as [itm:bosch-apas](https://ci.mines-stetienne.fr/kg/itmfactory/bosch-apas), [itm:dx10](https://ci.mines-stetienne.fr/kg/itmfactory/dx10), [itm:vl10](https://ci.mines-stetienne.fr/kg/itmfactory/vl10), and [itm:xy10](https://ci.mines-stetienne.fr/kg/itmfactory/xy10).
## Finding affordances
These machines are identified as td:Thing and their description contains the interfaces for their property affordances and action affordances (what they can "tell" and what they can "do"). For each affordance, we provide a td:name that helps identifying what the affordance serves for. An affordance has a form (td:hasForm) which is itself composed of several characteristics: a target (hctl:hasTarget) that identifies what resource must be queried, and what is the content type of the payload for the request (hctl:forContentTYpe). Each affordance have a type, usually defined in our custom ontology. These types of affordance can be used to find mutiple affordances that serves a similar purpose. For instance, onto:ActivityStatus correspond to a type of affordance that provides a status about a certain action. This way, it is not always necessary to know the name (td:name) of an affordance to find it and use it. Some affordances require a certain JSON schema, which is documented using the js: vocabulary. These machines are identified as td:Thing and their description contains the interfaces for their property affordances and action affordances (what they can "tell" and what they can "do"). For each affordance, we provide a td:name that helps identifying what the affordance serves for. An affordance has a form (td:hasForm) which is itself composed of several characteristics: a target (hctl:hasTarget) that identifies what resource must be queried, and what is the content type of the payload for the request (hctl:forContentTYpe). Each affordance have a type, usually defined in our custom ontology. These types of affordance can be used to find mutiple affordances that serves a similar purpose. For instance, onto:ActivityStatus correspond to a type of affordance that provides a status about a certain action. This way, it is not always necessary to know the name (td:name) of an affordance to find it and use it. Some affordances require a certain JSON schema, which is documented using the js: vocabulary.
Some machines have multiple affordances of the same type (because they achieve the same thing but at different places). For instance, there are multiple optical sensors in the filling machine, at each end of the conveyor belt. To select the right one, it may be necessary to rely on their td:name. Some machines have multiple affordances of the same type (because they achieve the same thing but at different places). For instance, there are multiple optical sensors in the filling machine, at each end of the conveyor belt. To select the right one, it may be necessary to rely on their td:name.
...@@ -25,3 +29,9 @@ In addition, each machine may have a location where material that must be used s ...@@ -25,3 +29,9 @@ In addition, each machine may have a location where material that must be used s
Moreover, the location of input material or the location of product are features of interest that may be observed by sensors, for instance, to detect the presence of a cup and start the filling process, or detect multiple a cup at the location of product so as to stop the filling machine and avoid accumulation of products at the end of the conveyor belt, etc. Moreover, the location of input material or the location of product are features of interest that may be observed by sensors, for instance, to detect the presence of a cup and start the filling process, or detect multiple a cup at the location of product so as to stop the filling machine and avoid accumulation of products at the end of the conveyor belt, etc.
## Structure of the production line description
The production line is described according to the pattern of the figure below:
![production-line-overview.svg](uploads/1ba22c893448c4654d159413bad3977b/production-line-overview.svg)