SAREF4INMA: A SAREF extension for the industry and manufacturing domain

Abstract

The IoT landscape is characterized by a fragmentation of standards, platforms and technologies, often scattered among different vertical domains. To prevent the market to continue to be fragmented and power-less, a protocol-independent semantic layer can serve as enabler of interoperability among the various smart devices from different manufacturers that co-exist in a specific industry domain, but also across different domains. To that end, the SAREF ontology was created in 2015 with the intention to interconnect data, enabling the communication between IoT devices that use different protocols and standards. A number of industrial sectors consequently expressed their interest to extend SAREF into their domains in order to fill the gaps of the semantics not yet covered by their communication protocols. Therefore, the SAREF4INMA ontology was recently created to extend SAREF for describing the Smart Industry & Manufacturing domain. SAREF4INMA is based on several standards and IoT initiatives, as well as on real use cases, and includes classes, properties and instances specifically created to cover the industry and manufacturing domain. This work describes the approach followed to develop this ontology, specifies its requirements and also includes a practical example of how to use it.

1. Introduction

This paper presents the resulting model after extending the Smart Applications REFerence ontology (SAREF) for the Industry & Manufacturing domain1

¹

https://portal.etsi.org/STF/stfs/STFHomePages/STF534

together with the methodology followed and modelling decisions taken during the development. This paper builds on the success achieved in the past years with SAREF,2 ²

https://ec.europa.eu/digital-single-market/en/blog/new-standard-smart-appliances-smart-home

which is a reference ontology for IoT created in close interaction with the industry [4] during a study requested by the European Commission in 2015.3 ³

https://sites.google.com/site/smartappliancesproject

SAREF is published as an ETSI Technical Specification series that also includes dedicated extensions to specific domains (TS 103 410, parts 1–6). A proof-of-concept solution based on SAREF in the energy domain and implemented on existing commercial products4 ⁴

https://ec.europa.eu/digital-single-market/en/news/digitalising-energy-sector-common-language-consumer-centric-world

was demonstrated in 2017 [6].

The motivation behind SAREF is that the IoT landscape is characterized by a fragmentation of standards, platforms and technologies, often scattered among different vertical domains [12,13]. To prevent the market to continue to be fragmented and power-less, a protocol-independent semantic layer can serve as enabler of interoperability [1] among the various smart devices from different manufacturers that co-exist in a specific industry domain (e.g., from lamps and consumer electronics to white goods, such as washing machines and ovens, which co-exist in our homes), but also across different domains. To that end, SAREF was created with the intention to interconnect data from different protocols and platforms, for instance ZigBee,5 ⁵

https://www.zigbee.org/

UPnP (now OCF6 ⁶

https://openconnectivity.org/

) and Z-Wave,7 ⁷

https://z-wavealliance.org/

enabling the communication between in-home devices that use different protocols and standards. SAREF is not about the actual communication with devices and has not been set up to replace existing communication protocols, but it lays the base for enabling the translation of information coming from existing (and future) protocols to and from all other protocols that are referenced to SAREF. As confirmed in the EC’s ‘Rolling Plan for Information Communication and Technology standardization 2017’, SAREF is the first ontology standard in the Internet of Things (IoT) ecosystem, and sets a template and a base for the development of similar standards for the other verticals to unlock the full potential of IoT.

A number of industrial sectors consequently expressed their interest to extend SAREF into their domain in order to fill the gaps of the semantics not yet covered by their communication protocols nor by the existing SAREF extensions and the related ontologies in the state of the art. The main problems faced by the industrial sector are the absence of commercially independent solution to exchange Industrial Internet of Things (IIoT) data recorded during the production process of items. Nowadays, production equipment is equipped with an enormous multitude of sensors, which produce extensive amounts of valuable information. This data is only valuable if it can exchanged with the industrial partners such that it can be used for optimizing production processes, (predictive) maintenance, and audits. This is becoming more challenging because an increasingly number of organizations tend to rely on the outsourcing, or even offshoring, of sub-assemblies instead of producing a machine completely by themselves.

Moreover, in order to support smart product lifecycles, i.e. traceability of items, parts, and raw material in the supply chain, the exchange of production process data is essential. This is especially challenging in low-volume, high complexity, and high-mix production process scenarios such as high-tech equipment manufacturing and medtech sectors where there is an increasing need for zero-defect manufacturing. In order to achieve the goal of zero-defect manufacturing, it is essential to collect and analyse product process information of sub-assemblies and raw materials, which can be used to, for example, dynamically reconfigure production lines based on small raw material deviations.

This paper focuses on this extension of SAREF to the Smart Industry & Manufacturing domain, which resulted in a new ontology, named SAREF for Industry and Manufacturing (SAREF4INMA), which is published as part of the SAREF series in a new ETSI Technical Specification [11]. This paper describes the approach used for developing SAREF4INMA and, furthermore, presents the requirements, ontology design and a practical example of how to use and instantiate the SAREF4INMA extension.

The rest of the paper is structured as follows. Section 2 contains an overview of related work. Section 3 describes the methodology used while creating SAREF4INMA. Next, Section 4 describes the requirements of the ontology, the ontology design itself, and the validation of the ontology. Section 5 elaborates on the application of the designed ontology to an example. Section 6 discusses the choices made during the ontology development, the impact of SAREF4INMA, and its current limitations. Finally, Section 7 closes with the overall conclusions and future work.

2. Related work

In this section, the state of the art on ontologies and standards related to the industry and manufacturing domain is presented, including a brief description and their main features.

Among the relevant ontologies existing in the industry and manufacturing domain, ADACOR [3] is a manufacturing ontology which includes a taxonomy of manufacturing components and integrates concepts related to production orders and operations. Another ontology describing the manufacturing domain is MASON [31] upper ontology, which is built upon three head concepts: (1) entities, which aims to provide concepts to specify the product; (2) operations, which are related to process descriptions; and (3) resources, which stand for the whole set of manufacturing linked resource. Finally, OntoCAPE [32] is a large-scale ontology for chemical process engineering which has been used in three applications, namely, automatic selection of software components, computer-aided construction of mathematical models, and semantic annotation of document. It is divided into different modules, including material, chemical process system and simulation.

Regarding industrial initiatives, there are various member states initiatives aimed to support the digitisation of European industry and manufacturing, such as platform “Industry 4.0”8

⁸

https://www.plattform-i40.de

in Germany, “Industria 4.0”9 ⁹

https://www.mise.gov.it/index.php/en/202-news-english/2036690-national-industry-4-0-plan

in Italy, “Industrie du futur”10 ¹⁰

http://www.industrie-dufutur.org/

in France and the “Smart Industry initiative”11 ¹¹

https://www.smartindustry.nl/english/

in the Netherlands. These initiatives focus on several aspects such as: 1) cyberphysical systems; 2) digital manufacturing technologies; and 3) new business models and propositions.

These initiatives collect different standards related to industry and industry 4.0. Such standards include IEC 62794 [27], which is a reference model for automation assets and structural and operational relationships; IEC 62832 [29], which identifies the general principles of the Digital Factory framework (i.e., a set of model elements and rules for modelling production systems); IEC 62264 [28], which describes the manufacturing operations management domain and its activities; IEC 61512 Batch control [8], which is a reference model for batch control as used in the process industries; IEC 62541 OPC UA [23], which describes the OPC UA Architecture, machine to machine communication protocol for industrial Author Guidelines 5 automation; IEC 62890 [25], which describes the lifecycle management for systems and products used in industrial process measurement, control and automation; IEC 61360 ISO 13584 [22], which specifies a general purpose dictionary covering the field of electro technology, electronics and related domains; IEC 62424 Topology [21], which specifies procedures and specifications for the exchange of Process Control Engineering relevant data provided by the Piping and Instrumentation Diagram (P&ID) tool; and IEC 62714 AutomationML [24], which defines a data exchange solution based on an XML schema for the domain of automation engineering and integrates IEC 61131 [26], IEC 62424 and ISO/PAS 17506 [30].

After analyzing the existing ontologies in the state of the art, we concluded that none of them covers the industry standards mentioned above, which were of key importance for the creation of SAREF4INMA. Furthermore, these state of the art ontologies do not focus on inter-organizational material and item measurement tracing, which are especially relevant for interoperability purposes. Therefore, whilst we could not reuse directly these ontologies, the collected standards from the various Industry 4.0 initiatives were used as the main input to provide use cases and requirements to SAREF4INMA, as described in our earlier paper [7].

3. Methodological background

This section describes the methodology followed in this paper. The ontology presented in this work was built following the LOT (Linked Open Terms) methodology, which was first introduced in [33] and further developed in [17]. Additionally, this methodology was also proposed by ETSI in the Technical Report 103 411: SmartM2M Smart Appliances SAREF extension investigation [9] in order to develop the SAREF ontologies. The LOT methodology, which is built on top of the ontological engineering activities defined in the NeOn methodology [36], is based on agile techniques where the development of the ontology is organized in sprints or iterations.

This methodology defines iterations over the following activities: 1) Ontological requirements specification; 2) Ontology implementation; 3) Ontology publication; and 4) Ontology maintenance. Figure 1 summarizes these activities, together with their inputs, outputs and actors involved in them. More details related to LOT are available online in its website.12

¹²

http://lot.linkeddata.es/

Fig. 1.

LOT workflow with inputs, outputs and actors.

The following sections present the main definitions and guidelines provided by the methodology for each of the above-mentioned activities.

3.1. Ontology requirements specification

The goal of the ontological requirements specification process is to extract the set of requirements that guides the implementation and validation of the ontology. These ontological requirements aims to state why the ontology is being built, what its intended uses are, who the end-users are, and which requirements the ontology should fulfill. There are two types of requirements: functional requirements, which refer to the particular knowledge to be represented by the ontology, and non-functional requirements, which refer to the characteristics, qualities, or general aspects not related to the ontology content that the ontology should satisfy.

The LOT methodology proposes the exchange of different documents, such as manuals, API specifications, datasets, standards or formats used in the community, between domain experts, ontology users and the ontology development team. From all the documentation, the ontology development team proposes a set of ontological requirements which can be written as Competency Questions [19] or in the form of natural language sentences. Such list of ontological requirements should be validated and completed together with domain experts.

3.2. Ontology implementation

During the ontology implementation activity, the ontology is built using a formal implementation language based on the ontological requirements identified in the previous activity. The ontology implementation is usually divided into the following sub-activities:

Conceptualization: It refers to the activity of organizing and structuring the information obtained during the acquisition process into meaningful models at the knowledge level according to the ontology specification document [36]. This conceptualization is usually carried out by means of diagrams or description logics statements.

Encoding: It refers to the activity of generating computable models according to the syntax of a formal representation language, such as OWL [36]. To create such ontology encoding tools such as Protégé 13

¹³

https://protege.stanford.edu

or TopBraid 14 ¹⁴

http://www.topquadrant.com/products/TB_Composer.html

can be used.

Evaluation: It refers to the activity of checking the technical quality of an ontology against a frame of reference [36]. Such evaluation can be related to different evaluation criteria, e.g., logical consistency checking, modelling issues or completeness. Some example of tools that can be used to validate ontologies are OOPS! (OntOlogy Pitfall Scanner!15 ¹⁵

http://oops.linkeddata.es/

) [35] for bad design practices detection, Themis 16 ¹⁶

http://themis.linkeddata.es/

for checking that the ontology fulfill all the proposed requirements, and the Hermit17 ¹⁷

http://www.hermit-reasoner.com/

or Pellet18 ¹⁸

https://www.w3.org/2001/sw/wiki/Pellet

reasoners to check that the ontology is consistent.

Reuse: During this activity the ontology reuse activity can also be carried out. In this ontology reuse activity, the ontology development team should search for existing ontologies in order to reuse them. Experienced developers may carry out the ontology reuse also during the conceptualisation activity as they may be are aware which ontologies or set of ontologies to reuse before the encoding.

3.3. Ontology publication

The aim of this activity is to make the ontology available online both as a human-readable documentation and in a machine-readable format. The machine-readable format has to be obtained during the previous implementation activity, while the human-readable documentation should be carried out during this activity by describing, in HTML pages, the content of the ontology with diagrams and examples to improve ontology readability and reusability.

It is worth noting that these two versions of the ontology, both the code and the documentation in HTML, should be reached from the same URI using content negotiation mechanisms. There are tools that ease this documentation activity, such as Widoco [18] or LODE,19

¹⁹

https://github.com/essepuntato/LODE

which generate HTML documentation from the ontology encoding.

3.4. Ontology maintenance

During this activity the ontology is updated with new information, which may be needed after new requirements identification or bugs detection. This activity can be triggered during or after the ontology development process, if new requirements or bugs are detected, or if a new version of the ontology needs to be generated.

4. SAREF4INMA ontology development

This section describes how each of the activities presented in Section 3 is carried out during the development of the SAREF4INMA ontology.

4.1. SAREF4INMA ontological requirements

The ontology requirement specification activity was carried out using two different inputs: (1) Standards and (2) Use Cases. First, an analysis of the standards in Industry and Industry 4.0 was carried out, identifying the more relevant terms and relations between them, as well as extracting definitions needed to model this domain. From all the analysed standards, which were presented in Section 2, only IEC 62890, which describes the lifecycle management for systems and products, IEC 62264, which describes the manufacturing operations management, and IEC 61512, which describes the batch control in the industry processes, were considered as relevant for the SAREF4INMA ontology domain.

Second, we extracted several concepts from the Zero defect manufacturing use case. Zero defect manufacturing focuses on reducing the yield loss of production to zero, often combined with an increase in flexibility. To that end, a combination of precision manufacturing technology, data collection and process control is needed. Two cycles are especially needed in the zero defect manufacturing use case, i.e., a real-time loop, that focuses on the immediate collection of data from sensors in or around a production equipment, and a data collection and analysis loop, that focuses on achieving a continuous process analysis and improvement. Therefore, the ontology should model the values of the measurements of the production equipment together with their exact time, in order to support the collection and analysis of the needed data during the production process. This use case is further detailed in the Technical Specification document of the SAREF extension for Industry and Manufacturing [10].

Table 1

Excerpt of requirements for SAREF4INMA

Id	Competency question/Statement	Possible answer	Category	Provenance
INMA-1	What sort of production equipment is used in the factory?	Milling machine, stamping machine, moulding machine.	Machine/Production Equipment	Zero defect manufacturing use case
INMA-33	What kind of incoming material is used in the machine?	An individual item, a sub-assembly composed of different items or a volume of raw material	Material	Zero defect manufacturing use case
INMA-41	Products can be distinguished in categories		Product	IEC 62890
INMA-52	A site is located in a factory		Factory	IEC 62264

Fig. 2.

SAREF4INMA conceptualization overview.

From these two inputs, a first proposal of ontological requirements written both as competency questions and natural language sentences was generated. Such requirements, which were all of them functional requirements, were divided into four categories: (1) Requirements for Machine/Production Equipment, (2) Requirements for Material, (3) Requirements for Product and (4) Requirements for Factory. Each ontological requirement included:

• Identifier, unique for each requirements.

• Competency question or natural language sentences, which define the requirement the ontology should fulfill.

• Possible answer. In case the requirement is written as a competency question it should include an answer from which ontology needs are also leverage.

• Category, which indicates the domain of each requirement.

• Provenance, which represents the source from which they each requirement is extracted.

Once this first ontological requirements proposal was completed, domain experts validated it in order to determine if some of the requirements were incorrect and to add new ones. Table 1 shows an excerpt of the gathered requirements along with the source from which they were extracted, i.e., standard or use case. The complete list of ontological requirements for SAREF4INMA is presented in [10].

Fig. 3.

SAREF4INMA Item, Batch and related classes.

4.2. SAREF4INMA implementation

Taking as input the requirements defined in the previous activity, a conceptualization of the ontology was proposed. This conceptualization includes the most relevant concepts to model the industry domain, such as production equipment, item, batch and measurement. Figure 2 shows an overview of such conceptualization, where arrows with white triangles on top represent the rdfs:subClassOf relation between two classes. The origin of the arrow is the class to be declared as subclass of the class at the destination of the arrow. In addition, directed arrows are used to represent properties between classes. The ontologies in which each concept or relation is defined is indicated by the use of prefixes, for example the concept s4inma:Item is defined in the https://saref.etsi.org/saref4inma/ namespace. As it is shown in this figure, SAREF4INMA also reuses terms from the SAREF ontology,20

²⁰

https://saref.etsi.org/core/

such as saref:FeatureOfInterest, and the SAREF4BLDG ontology,21 ²¹

https://saref.etsi.org/saref4bldg/

such as s4bldg:Building. This format also applies to the other figures in the rest of the paper.

Figure 3 shows in detail the terms defined in SAREF4INMA related to items and batches. A s4inma:Item is a tangible object that represents either the goods produced by an organization’s production process or individually traced supplies. Additionally, such s4inma:Item can be individually traced using a s4inma:ID, which can be defined in the form of GTIN,22 ²²

https://www.gs1.org/standards/id-keys/gtin

International Registration Data Identifier (IRDI)23 ²³

https://stats.oecd.org/glossary/detail.asp?ID=1404

or Universally Unique Identifier (UUID),24 ²⁴

https://www.itu.int/en/ITU-T/asn1/Pages/UUID/uuids.aspx

and can consist of other s4inma:Item. Each s4inma:Item is created in a s4inma:ItemBatch, which describes a special type of s4inma:Batch. A s4inma:Batch is a uniform collection of goods produced at a certain time using a certain s4inma:ProductionEquipment and thus have highly similar properties. There might be slight variations between different items within a batch, but generally speaking the variations between items in a batch is significantly smaller than the variation between items in different batches. A s4imna:ItemBatch is a specialization of the more general s4inma:Batch, similarly to s4inma:MaterialBatch. The difference between s4inma:ItemBatch and s4inma:MaterialBatch is that individual items can be traced in an s4inma:ItemBatch (e.g., it is possible to trace an individual metal sheet in an ItemBatch), whereas it is not possible to exactly trace material in a s4inma:MaterialBatch, (e.g., it is not possible to trace the exact piece of raw plastic material from a s4inma:MaterialBatch, as the raw plastic is a volume, not identifiable in a specific sheet like in the case of metal sheets). This traceability of Items and Material through the production process is an integral part of the appliances of SAREF4INMA and are fundamentally different from an ontology engineering perspective as they both represent different types of information (e.g. a volume raw material versus individually traceable items) and imply different levels of traceability.

Fig. 4.

SAREF4INMA Production Equipment, Factory and related classes.

SAREF4INMA also defines concepts related to production equipment and factory, in order to describe how a production equipment is organized and how it is able to exchange information within the factory. Figure 4 shows the terms related to production equipment and factory. A s4inma:ProductionEquipmentCategory describes the type of production equipment required for producing a certain s4inma:Item, i.e., describes the category of a machine. An organization might have multiple instances of the same category of machines. Each particular machine is represented by a s4inma:ProductionEquipment, which is a subclass of saref:Device, which is in turn a subclass of s4bldg:PhysicalObject.

Moreover, an s4imna:Item can recursively consist of other items (e.g., a shaver consists of a specific motor) and can consists of s4imna:Batch (e.g., a shaver consists of some raw plastic material).

SAREF4INMA also describes a factory layout, which allows to locate each s4inma:ProductionEquipment. A factory (s4inma:Factory) in SAREF4INMA can be divided into smaller spaces, namely: s4inma:Site and s4inma:Area. Additionally, a s4inma:Area contains one or multiple s4inma:WorkCenter, which is a set of equipment elements located in an area that performs production, storage or material movement.

Fig. 5.

SAREF4INMA Measurements and related classes.

Finally, SAREF4INMA allows to trace back production process measurements to individual s4inma:Item or s4inma:Batch. The modelling of measurements in SAREF4INMA relies on the measurement model proposed in SAREF. According to the measurement model in SAREF, the saref:FeatureOfInterest25 ²⁵

The saref:FeatureOfInterest class is not included in the current SAREF ontology v2.0 yet, but is planned to be added in the upcoming version v3.0.

class represents the thing whose property is being measured. In addition, measurements (represented as saref:Measurement) are related to the property they observe (e.g., welding temperature), its unit of measure (e.g., degrees Celsius) and the device carrying out such measurement.

In SAREF4INMA, the s4inma:Measurement class is created as a specialization of saref:Measurement. Such s4inma:Measurement further presents two specializations, namely s4inma:ActualMeasurement and s4inma:ExpectedMeasurement, which are defined to describe the measurements that are planned or expected, and the measurements that are actually measured during the production process.

Additionally, the s4inma:Measurement can be related to a specific s4inma:Batch or s4inma:Item, which are both subclasses of saref:FeatureOfInterest. The saref:FeatureOfInterest class provides the means to refer to the real world phenomena that is being observed in the given measurement (e.g., a shaver is an item resulting from a certain production process and it can be defined as the feature of interest of a temperature measurement made by a welding machine used to join different parts in the production of the shaver). Figure 5 summarizes this measurement conceptualization.

Once the SAREF4INMA conceptualization was defined, it was encoded in OWL using Protégé26 ²⁶

https://protege.stanford.edu

and stored in the repository.27 ²⁷

https://forge.etsi.org/rep/SAREF/saref4inma/

Finally, we evaluated the ontology to check that it does not contain pitfalls and that it covers all the identified requirements.

Fig. 6.

Results of the SAREF4INMA ontology evaluation perfomed by OOPS!

Table 2

Excerpt of tests for SAREF4IMA

ID	Competency question/Statement	Test	Result	Problem found
T-52	What sort of production equipment is used in the factory?	MillingMachine subClassOf ProductionEquipment, StampingMachine subClassOf ProductionEquipment, MouldingMachine subClassOf ProductionEquipment	Not passed	MillingMachine, StampingMachine and MouldingMachine are not defined in the ontology
T-21	What kind of incoming materialis used in the machine?	ItemMaterial subClassOf Material, RawMaterial subClassOf Material	Not passed	ItemMaterial and RawMaterial are not defined in the ontology
T-6	Products can be distinguished in categories	ItemBatch subclassOf belongsTo only ItemCategory	Passed	–
T-62	A site is located in a factory	Factory subclassOf hasSpace only Site	Passed	–

First of all, in order to detect common mistakes done by developers when implementing ontologies we have used the tool OOPS!. As shown in Fig. 6, several important and minor pitfalls have been found. However, these important pitfalls do not affect the consistency, reasoning or applicability of the ontology. Some of the pitfalls refer to “missing domain or range”, but it was a modelling decision to not add domain or range to certain properties in order not to be restrictive with them. In the case of the “recursive definitions” pitfall, it was needed to define several recursive relations, such as states the requirement “A production equipment can contain another production equipment”. Therefore, they are not considered mistakes in the ontology. Finally, regarding the minor pitfalls, they are mostly related to missing annotations and they will be corrected in future releases of the ontology, together with the identified unconnected elements. The other errors found by the tool were corrected accordingly.

In addition to the validation of the ontology with OOPS!, the ontology was also verified to check that all the functional requirements defined during the ontology requirements specification activity were satisfied. In order to do so, a set of 58 tests were defined and executed on the ontology using the tool Themis,28 ²⁸

http://themis.linkeddata.es

which supports the testing methodology introduced by Fernández-Izquierdo and García-Castro [16]. The set of tests was also defined following this methodology. Therefore, the purpose of each requirement, such as the definition of a new hierarchy between classes or a universal restriction of a class in the ontology, was translated into at least one or even multiple tests.29 ²⁹

The complete list of tests supported by Themis is available in: http://themis.linkeddata.es/tests-info.html.

These tests are available online30 ³⁰

The tests for SAREF4INMA are available in: https://forge.etsi.org/rep/SAREF/saref4inma/blob/develop-v1.1.2/tests/tests.csv.

in a CSV file including metadata that can be associated to a test, such as the associated requirement or the related category.

As examples of tests, Table 2 summarises the tests provided for the requirements presented in Table 1, together with their results and the problem found, if any.

After the execution of the defined tests, it was found that 35 of them were passed while 23 were not, indicating that there are some requirements that are not satisfied by the ontology, e.g., the test T-52 and T-21 in Table 2. However, these 23 tests did not pass as they refer to very specific examples related to instantiated data (e.g. shavers, injection units and moulding machines) while the ontology scope is kept at a more general level. Taking T-52 as example we can observe that in principle, the terms MillingMachine, StampingMachine and MouldingMachine could be modelled as subclasses of ProductionEquipment. However, as the ontology is defined at a more general level, only the class ProductionEquipment is defined in SAREF4INMA, leaving for the specific use cases the generation of the corresponding classes or instances for MillingMachine, StampingMachine and MouldingMachine. The generation of such classes or instances will depend on the use cases needs.

Fig. 7.

SAREF4INMA Item example.

4.3. SAREF4INMA publication and maintenance

Once the ontology is encoded, it has to be published online. For this purpose it was used OnToology [2], a web-based system that builds on top of Git-based environments and integrates a set of existing tools for documentation, evaluation and publication activities. These integrated tools are Widoco [18] for generating the HTML documentation, AR2DTool31

³¹

https://github.com/idafensp/ar2dtool

for generating diagrams, and OOPS! [35] for evaluating the ontology. Additionally, OnToology provides two alternatives for ontology publication with content negotiation mechanisms, namely: (1) publishing the ontology with a permanent id using the https://w3id.org services or (2) downloading a bundle with all the archives needed to publish the ontology in a server. For the SAREF4INMA ontology the second option was selected, publishing the ontology under the URI https://saref.etsi.org/saref4inma/. Therefore, the SAREF4INMA ontology is available in https://saref.etsi.org/saref4inma/ as machine-readable format and as a human-readable document by using content negotiation.

In order to support the maintenance activity in SAREF4INMA, an issue tracker32 ³²

https://forge.etsi.org/rep/SAREF/saref4inma/issues

is used. Therefore, if users, domain experts, or ontology developers want to propose new requirements, detect bugs or have any suggestion, they have to create an issue in the repository. This issue tracker allows to keep track of all the issues proposed by users, domain experts and developers ontology developers. Once an issue is open, it has to be discussed by the ontology development team in order to decide if the proposal presented in such issue should be implemented in the ontology or rejected.

5. SAREF4INMA example

This section provides an example of how users can instantiate SAREF4INMA. This instantiation uses the ex prefix to indicate the instances created for such example, and the prefix s4inma, which indicates the SAREF4INMA ontology on which the ex example instantiation is built upon.

The example is shown in Fig. 7 and represents an instance of a shaver, namely the ex:Shaver10023, of the s4inma:Item class. This shaver is an item created in a batch, and belongs to a category of items called PhilBrau S40 Premium Gold Shaver ItemCategory, represented by the ex:PhilBraue_S40_Premium_Gold_Shaver_ItemCategory instance of the s4inma:ItemCategory class.

As shown in Fig. 8, the ex:Shaver10023 item recursively consists of other three items, namely the ex:ShaverHead3002, ex:StepMotor083 and ex:ShaverBody9440 items. The ex:ShaverBody9440 item is created in the ex:PhilBrau_S40-S50_Generic_Body_ItemBatch3290, which consists of material from other batches such as the Torx screws Batch 323 and ABS Plastic Batch 742, represented in the ontology example as ex:Torx_screws_D2mm_L8mm_MaterialBatch323 and ex:ABS_Plastic_Role_8mm_MaterialBatch742, respectively. These two material batches belong to two material categories classes created specifically for this example, respectively the ex:Screw class and the ex:Plastic class.

Fig. 8.

SAREF4INMA Material example.

Fig. 9.

SAREF4INMA Production equipment example.

The production equipment example in Fig. 9 defines two types of production equipment categories, namely the ex:Lazor_Series_8030_ProdEquipCategory and the ex:WandI_Welding_Series_1000_ProdEquipCategory. These categories represent models of production equipment and not the individual machines, since an organization might have multiple machines of the same model. For example, there is one laser cutting machine of type ex:Lazor_Series_8030_ProdEquipCategory, namely the ex:Laser_Cutting_Machine_1, and two individual welding machines, namely ex:Welding_Machine_1 and ex:Welding_Machine_2.

Table 3

Number of classes, properties and individuals defined in the SAREF4INMA ontology and reused from SAREF and SAREF4BLDG

Source	Number of classes	Number of object properties	Number of datatype properties	Number of individuals	Topics
SAREF4INMA	26	20	11	0	Production equipment, Material, Product, Factory
SAREF	8	5	0	0	Device, Function, Feature of interest, Measurement
SAREF4BLDG	3	3	0	0	Physical object, Building

Figure 9 shows the ex:Welding_Machine_1 and the ex:Welding_Machine_2, which are instances of the ex:WeldingMachine and the ex:LaserCuttingMachine classes created for this example. Both these classes are subclasses of s4inma:ProductionEquipment, which is, in turn a subclass of saref:Device. The subclass relation of s4inma:ProductionEquipment and saref:Device ensures that a s4inma:ProductionEquipment can reuse SAREF functionalities, such as the possibility to perform functions with the object property saref:hasFunction or to control properties with the object property saref:controlsProperty. This is shown in the ex:Welding_Machine_2 production equipment, which performs an ex:JoiningFunction, controls the ex:WeldingTemperature property, and consists of other devices such as the ex:WeldingMachineTemperatureSensor1.

6. Discussion

SAREF4INMA is developed as an extension of the SAREF ontology, which is a reference model for smart applications originally created for smart homes, to support the definition of production equipment providers that manufacture items in a factory. SAREF4INMA introduces new functionality that also enables organizations to track back the manufacturer items to the corresponding production equipment, batches and material, and retrieve their time of production in the supply chain. To that extent, 26 new classes have been defined in this ontology, as well as 20 new properties. As it is an extension of the SAREF ontology, SAREF4INMA also reuses some terms of SAREF, such as Device and Function, and some terms from its SAREF4BLDG extension for the building domain, such as Building and BuildingSpace. Table 3 summarizes the number of terms defined in SAREF4INMA, as well as the number of terms reused from SAREF and from SAREF4BLDG.

As mentioned in the previous sections, several standards were analysed for creating the SAREF4INMA ontology. Such standards include information about equipment, factories, material, storage and measurements, among other topics. However, after a thorough analysis of the zero defect manufacturing use case [7] and interviews with domain experts, it was decided to leave some of these topics out of scope, such as those related to storage. Since SAREF4INMA was developed to solve the lack of interoperability between various types of production equipment that produces items in a factory, it was decided to focus on the production process, rather than on the storage handling. Furthermore, it was decided not to model all categories of material and production equipment, but instead provide a structured method, which is similar to the mechanism in IEC 62890, to add new types of material and production equipment to the ontology in order to ensure that the user can easily relate their categories to the model. In this way, the ontology provides generic building blocks that can be adopted, and eventually extended, by any manufacturing use case.

Similarly to SAREF, it was further decided not to model the organizational actors (e.g. organizations, employees, skills, ownership of machines), but instead fully focus on the industry and manufacturing domain. The organizational actors are not domain specific for SAREF4INMA and, therefore, are left out in this first version of the ontology. There are other existing ontologies, such as FOAF33

³³

http://xmlns.com/foaf/spec/

or The Organization Ontology,34 ³⁴

https://www.w3.org/TR/vocab-org/

which model the organizational actors and can easily be integrated into future versions of SAREF4INMA.

Additionally, the best practice of maximizing reuse was adopted. An obvious example is the reuse of SAREF, which was extended for specific SAREF4INMA needs. For example, the saref:Device class has been reused and extended with the s4inma:ProductionEquipment class; the saref:Function with the s4inma:ProductionEquipmentFunction class; and the saref:Property with the s4inma:Size class to describe the s4inma:Batch size. SAREF4BLDG was also reused and extended to model the layout of the factory. For example, saref:BuildingSpace has been reused and extended with s4inma:Site and s4inma:Area; whilst s4bldg:PhysicalObject has been reused and extended with the s4inma:ProductionEquipment and s4inma:WorkCenter classes, which are elements that need to be included in a factory. As a best practice of reuse, we created mappings not only to SAREF extensions, but also to other standards, such as, for example, the Smart Connected Supplier Network (SCSN) standard [37], which is a communication standard used by the high-tech equipment manufacturing sector for inter-organizational data exchange. This communication standard previously focused primarily on the procurement of goods. However, traceability of goods in the supply chain is an increasingly important topic in the industry, which requires new information to be shared across the supply chain. SAREF4INMA can therefore serve as basis for further SCSN extensions, such as the possibility to exchange material certificates, production process sensor information, and measurement reports between organizations.

During the development of the ontology, a number of issues were encountered that could be tackled in different ways. This led to some fruitful discussions within the SAREF4INMA team that resulted in the specific design choices that are outlined in this paper. For example, in the early stages it was discussed how to model identifiers. Identifiers can be modelled using a datatype property (e.g. hasID) with xsd:string as a range, or as an hasID object property with an ID class as a range, which in turn contains an hadIDValue datatype property with xsd:string as a range. The first case results in a simpler ontology (less classes and less properties) which allows reasoning on the identifiers via label comparison, as they are modelled as strings, but the reasoning that can be done is limited, as the identifiers are not entities by themselves. In contrast, the second case allows a complete and exhaustive modelling of identifiers as classes with subsequent reasoning, but this makes the ontology more complex (more classes and more properties) and it is not always needed. In SAREF4INMA the latter option is chosen since there are various types of IDs used in the manufacturing sector which are fundamentally different (e.g. product ID specified in GTIN35 ³⁵

https://www.gs1.org/standards/id-keys/gtin

and material quality specified in ETIM36 ³⁶

https://www.etim-international.com/

/eCl@ss37 ³⁷

https://www.eclass.eu/en/index.html

) that in our opinion require a dedicated modelling and reasoning as classes. Therefore, SAREF4INMA defines a s4inma:ID class with a number of subclasses for different ID types (e.g., GTIN-8, GTIN-12, GTIN-13, GTIN-14 subclasses to express the various GTIN formats, an IRDI subclass to associate items to the International Registration Data Identifier, and a UUID subclass for the Universally Unique Identifiers). New ID subclasses can be further defined ad-hoc by the ontology users if needed. These ID classes are modelled as the range of corresponding object properties, i.e., s4inma:hasID and its subproperties. These ID classes, finally, contain a s4inma:hasIDValue datatype property to define the actual value of the identifiers.

Another modelling issue concerned the modelling of categories, i.e., as traditionally done by using subclasses (for example, for the ProductionEquipment class, by creating categories as subclasses/types of this ProductionEquipment class) or by using specific, separate classes (i.e., by creating a separate, dedicated ProductionEquipmentCategory class). It was decided to model categories as separate classes. This modelling decision was based on the approach followed by the IEC 62890 standard, which distinguishes between a product, its category and its instantiation. As an example, the product Toshiba Computer Model UX0293 has category Toshiba Computer and it can be instantiated by Toshiba Computer Model UX0293 with serial number 109487. The same approach was followed when defining the ItemCategory and MaterialCategory classes.

When modelling the Batch concept, we encountered the need to distinguish between ItemBatch and MaterialBatch. An ItemBatch describes a batch of individually traceable items such as a batch of shaving machine motors. In many industrial use-cases it is essential to completely be able to trace components to its origin for e.g. predictive maintenance and sustainability use cases. However, not all groups of components can be individually traceable, especially raw materials. These raw materials are still produced in batches and therefore have similar characteristics, but cannot be traced on the individual level. Some examples are: nails, steel plates, a barrel of protective coating. It is therefore chosen to make an explicit distinction between ItemBatch and MaterialBatch as they describe different forms of Batches.

When modelling measurements, we noticed in SAREF4INMA the extra need, compared to SAREF and other extensions, to distinguish between expected and actual measurements. This distinction enables the calculation of deviations between planned and actual production process measurements. Therefore, after careful consideration, it was decided to model it as two specialized subclasses saref:ActualMeasurement and saref:ExpectedMeasurement because the saref:ExpectedMeasurement may consist of complex prediction models, while the saref:ActualMeasurement consists of a set of descrete data points.

Finally, a major need when developing SAREF4INMA was to introduce the FeatureOfInterest concept that was originally absent in SAREF. This concept provides the means to refer to the real world phenomena that is being observed in a certain measurement. In other words, it provides the context of the measurement. For example, a shaver is an item resulting from a certain production process and it can be defined as the feature of interest of a temperature measurement made by a welding machine, which is used to join different parts in the production of the shaver. Without the FeatureOfInterest concept, we would only be able to express the temperature measurement made by the welding machine, but not the context in which it is done, which is essential in SAREF4INMA, as it links the measurement to its precise context (i.e., the specific item being produced). The FeatureOfInterest concept was therefore added to SAREF4INMA, reusing the pattern originally defined by the SSN ontology. It is important to notice that the need for the FeatureOfInterest concept was also encountered in the SAREF4CITY and SAREF4AGRI extensions for the Smart Cities and Agriculture domains, respectively, which were developed at the same time of SAREF4INMA. This resulted in the decision to promote the FeatureOfInterest concept from the specific extensions to the SAREF core model. This improvement contributed to an updated SAREF 3.0 core ontology released by ETSI in February 2020.

7. Conclusions

In this work, the process followed to develop the SAREF extension for the industry and manufacturing domain, called SAREF4INMA, has been described. In addition, the ontology itself has been presented, together with an example of how such ontology can be instantiated. Finally, important design decisions have been discussed and explained.

SAREF4INMA represents a step forward with regard to the state of the art ontologies for the industry and manufacturing domain, as it describe production equipment in factories and allows to trace back and monitor production process measurements. Moreover, it describes a factory layout in order to be able to locate each production equipment in a factory. It is worth mentioning that this ontology is based on real-world use cases provided by domain experts and on several standards and industry 4.0 initiatives, such as Platform Industrie 4.0 from Germany. Based on these inputs, it is decided to keep out of scope the organizational actors, the material and the storage, while fully focusing on the industry and manufacturing domain. Moreover, SAREF4INMA fulfills all the defined generic requirements as described in [11] and can, therefore, successfully support to the zero defects and smart product lifecycle use cases. This is further confirmed by applying the ontology to a real-world example.

Finally, an important aspect regarding the SAREF4INMA ontology is the fact that it was proposed in close collaboration with industry experts, who expect to adopt this extension in specific applications such as the Smart Connected Supplier Network communication standard.