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.
Introduction
This paper presents the resulting model after extending the Smart Applications REFerence ontology (SAREF) for the Industry & Manufacturing domain1
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
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.
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
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].
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
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.
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.
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:
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
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.
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.
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].
Excerpt of requirements for SAREF4INMA
Excerpt of requirements for SAREF4INMA
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:
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].
SAREF4INMA Item, Batch and related classes.
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
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
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.
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.
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
Results of the SAREF4INMA ontology evaluation perfomed by OOPS!
Excerpt of tests for SAREF4IMA
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
The complete list of tests supported by Themis is available in:
The tests for SAREF4INMA are available in:
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.
SAREF4INMA Item example.
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
In order to support the maintenance activity in SAREF4INMA, an issue tracker32
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.
SAREF4INMA Material example.
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.
Number of classes, properties and individuals defined in the SAREF4INMA ontology and reused from SAREF and SAREF4BLDG
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.
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
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
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.
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.
Footnotes
Acknowledgements
This work is supported by the ETSI STF 534 and a Predoctoral grant from the I+D+i program of the Universidad Politécnica de Madrid.