The movement defined as “Industry 4.0” has attracted more and more attention since it was first announced at the Hannover Fair in 2011 (Drath and Horch, 2014). The concept of “Industry 4.0” has first appeared in an article published by the German government in 2011 as a technological strategy for 2020. The term “Industry 4.0” appears again at Hannover Fair in Germany in 2013 and has become an important lead that global industries are pursuing (Zhou et al., 2018). Germany has developed a strategic plan to evolve from Industry 3.0 to 4.0. The main points according to Ma et al. (2019) can be summarized as building a network, researching two major themes, the realization of three integrations, and the achievement of eight planning objectives. Wang et al. (2019) have defined these three main ways to promote smart factories in Industry 4.0 as horizontal integration of value networks, vertical integration and networked systems, and peer-to-peer integration of the entire value-chain or end-to-end integration (Zhou et al., 2018).

Horizontal integration refers to integration between a resource and an information network in the value chain, to achieve seamless cooperation between enterprises and provide a real-time product and service. It also can be defined as the competition and cooperation between the enterprise and related enterprises. These relationships establish an ecosystem in which information, finance, and material can move continuously in cooperation (Stock and Seliger, 2016). Integration means, from the perspective of the systems, the interconnection of value elements such as equipment, people, organization, products, and processes (Tung, 2018). Vertical integration refers to networked manufacturing systems in the smart factories, as well as personalized custom manufacturing as alternatives to traditional fixed production processes. Vertical integration refers to the integration of relevant value elements such as people, equipment, and products within a manufacturing factory or line. This integration also includes integrating tasks like marketing, sales, services, and others (Marques et al., 2017; Tung, 2018). End-to-end integration means engineered numerical integrations across the entire value chain, implemented with the goal of every terminal having a digital value chain with integration between different companies, maximizing customization (Webster, 2008). The authors believe the vertical and horizontal integrations are the base and the way to get to the end-to-end integration, the reason why this work is focused mostly on these first two integrations.

A smart manufacturing system should be possible to link activities in the manufacturing value chain with CPS (Stock and Seliger, 2016). The horizontal and vertical integration allows better visualization of the manufacturing process, enabling it to react to customers’ necessities (Beier et al., 2020). Industry 4.0 aims to enable sensors, embedded terminal systems, intelligent control systems, facilities, and more to integrate an intelligent network within the CPS (Lu et al., 2020). This may happen by man-to-man, machine-to-machine, man-to-machine, or service-to-service, to achieve complete horizontal, vertical, and end-to-end integration (Kumar and Lee, 2022).

The practical benefits of Industry 4.0 include the flexibilization of manufacturing tasks, lead times reduction, and enabling small batch production (Tung, 2018). In addition, data analysis can help companies to provide high-quality services and productivity increase (Wang and Wang, 2016), and reduce manufacturing costs (Rüßmann et al., 2015, 0; Yoo et al., 2016). Industry 4.0 can be defined as a movement toward flexibility and automation in the manufacturing industry. It is also an intelligent plan for the next generation of operations in smart factories (Peters et al., 2016). However, from the standardization perspective, there is still a lack of commonly accepted standards, software, and hardware. To effectively implement Industry 4.0, it is necessary to choose formal standards (Liao et al., 2017). This might be considered a semantic interoperability issue.

The concept of interoperability has been initially defined by IEEE as “the ability of two or more systems or components to exchange information and to use the information that has been exchanged” (IEEE, 1990). However, the technical definitions that are addressed in the IEEE-90 do not include the idea of preservation of meaning (semantics), but just the content. The U.S. branch of IEEE redefined the concept of interoperability in 2005, presenting a more complete version of the IEEE-90 (IEEE-USA Medical Technology Policy Committee, 2006), and defined interoperability as the ability “to use the information that has been exchanged,” which means that not only systems must be able to communicate with each other but also they must employ shared terminology and definitions. This secondary emphasis places a much greater burden on system designers and engineers to make the information truly usable in the distributed settings of the most varied environments.

To respond to changing market demand and technological evolution, enterprise systems need to be constantly and smoothly re-engineered in the actual industrial and economic context (Panetto and Molina, 2008). This is not only an information technology problem but also a strategic and organizational challenge. Manufacturing support tools provide valuable information support to decision-makers. However, they are not well integrated, and the traditional methods of integration, via interfacing, are expensive and subject to errors (Ray and Jones, 2006). The integration based on industrial standards can be helpful, but these tend to be focused on narrow domains and are not very well suited to managing and sharing the information across manufacture (Chungoora et al., 2013).

Even though ISA-95 (IEC/ISO 62264, 2013) is the most used reference standard for the interoperation of manufacturing tools, it is also limited by the lack of semantic consistency in interpretation (Palmer et al., 2018). Sanfilippo et al. (2019) have demonstrated the problem of misinterpretations among users of ISA-95, identifying 83 errors in a real-world example and explaining how these could have been avoided by semantical approaches. The necessity of improved standards has been recognized by Panetto et al. (2016). However, finding a robust and consistent way of representing the information, so that it can be shared with trust, is a substantial problem. The lack of a generally adopted standard in the domain of enterprises is a bottleneck for this development.

The literature points out that the use of ontologies should offer radical improvements to share information and knowledge, or at least to understand what can and cannot be shared (Palmer et al., 2018). The issues of misinterpretation among the multiple domains of the PDP are demonstrated by Canciglieri and Young (2010), Szejka et al. (2017a). The use of ontologies to formalize information and knowledge in product or manufacturing models, as well as ensuring interoperability across them, has been suggested by Panetto et al. (2012), Chungoora et al. (2013), Imran and Young (2016), Palmer et al. (2018). To ensure semantic interoperability, that is, promote the ability to model and share product design and manufacturing information knowledge reliably, it is necessary to establish standardized product and manufacturing models. In addition, relationships between these models must be established. Gunendran and Young (2006) explored an information and knowledge framework for capturing multi-perspective product design and manufacturing. They stated that the integration between the product and manufacturing models may contain several rules, equations, and variables to support the integration of information from multiple views. Canciglieri and Young (2010) have developed information mapping across plastic injection molding designs and manufacturing domains. However, a semantic interoperability analysis has not been performed to evaluate the impact of changing information in the steps of product or manufacturing modeling.

Even though shreds of evidence about structuring information from product and manufacturing models have been presented, a reliable way to integrate these two models in an interoperable manner has not yet been addressed in the context of manufacturing systems.

Ontologies have been applied in different areas and one of the many definitions describes them as an explicit specification of a conceptualization (Gruber, 1993). Despite the differences in the different ways to define ontology, they highlight that these are a representation or model that provides a basis for sharing meaning or knowledge (Young et al., 2007). The literature points out that the use of ontologies should offer improvements to share information and knowledge, or at least to understand what can and cannot be shared (Palmer et al., 2016).

Song et al. (2013) have summarized the most relevant ontological formalism. These are commonly separated into traditional ontology languages, such as FOL, DL, and KIF; and ontology markup languages, based on the XML language, such as RDF and OWL. The main difference between these groups is that the first one is based on the first-order logic (FOL) and later. Description logic (DL), and the second group have their syntax based on the eXtensible Markup Language (XML), which addresses the flexible information structuring according to Nurmilaakso et al. (2002).

The Web Ontology Language (OWL) is part of the W3C’s semantic web technology stack, as well as RDF, RDFS, SPARQL, and others (W3C, 2014). It can be defined as a Semantic Web language that is designed to represent rich and complex knowledge referring to things, groups of things, and relations between things. The knowledge expressed in OWL can be used by computer programs, for example, to verify the consistency of that knowledge or even make implicit knowledge explicit (W3C, 2012). OWL documents can be published on the World Wide Web and can refer to or be referred from other OWL ontologies. The current version of OWL, referred to as “OWL 2,” was developed and published in 2009, with a second edition published in 2012 as an extension to the 2004 version of OWL.

The Semantic Rule Web Language (SWRL) was created based on the combination of two OWL variations (OWL DL and OWL LITE). This language extends the set of OWL axioms to include Horn-like rules that can be combined with an OWL knowledge base. A simple example of a rule would be “hasParent” and “hasBrother” implies the “hasUncle” property, that is, if John has Mary as a parent, and Mary has Bill as a brother, then John has Bill as an uncle.

A significant amount of work has been realized in the field of engineering applying ontologies to solve specific problems (Szejka and Junior, 2017). A combination of Ontology Web Language (OWL) with Semantic Web Rule Language (SWRL) has been employed to solve many problems in representing constraints in formal models. Since OWL and SWRL consequently are based on the XML standard, there are several implementations in many different programming languages, such as Java, LISP, Python, Prolog, C, Ruby, Perl, C++, PHP, Javascript, ActionScript, Tcl, Objective-C, and others. In the industrial context, these powerful tools can be used to extract and model knowledge from the manufacturing process using the aid of semantic reconciliation tools. These can be dedicated applications or even standard integrators, such as OPC, that can help to adapt, contextualize, translate, and give meaning to information and knowledge coming from the many sources in the manufacturing context.

The reference ontologies are the starting point of the MANUMATE framework. It gathers and structures concepts to formally represent the product design to be manufactured, manufacturing process, materials, etc. These concepts are modeled in an Ontology Web Language (OWL) using the concept of lightweight ontology (Giunchiglia and Zaihrayeu, 2009). This research uses three main reference ontologies to support the manufacturing process. They are product reference ontology, manufacturing process reference ontology, and materials reference ontology.

The product reference ontology (Detail “ii” of Figure 2) is the model of a generic product. It has the design of functional characteristics that are related to the application of the final product and non-functional characteristics. In the example of the carton package, functional characteristics can be the number of layers of plastic film, grammage of paper, plastic film, presence or not, and the grammage of aluminum foil, etc. Non-functional characteristics are the type of ink used, dimensions of the box, art used for printing, and others. It is important to reinforce that in this step only the schema of the product is modeled. In the example, the model represents a generic carton package that can be used further to represent a wide variety of carton packages.

Manufacturing process reference ontologies (Detail “iii” of Figure 2) are the models of the manufacturing processes that are or will need to be available in the industry being modeled, and the interactions between them. For this work only the manufacturing resources and planning models will be considered for the manufacturing model, a cost approach is suggested for future works. In the context of the example, the manufacturing resources can be the paper coating, printing, and crease-cutting processes, and the production control plan (PCP) can be considered as the process planning model.

Materials reference ontologies (Detail “ii” of Figure 2) are common models that are used for a wide variety of applications. These can be acquired and reused from the literature and/or common source web servers of the semantic web. In the context of this work, these can be carton paper, aluminum foil, polyurethane, and ink models. The next item describes the requirements that will be combined with these generic reference ontologies, to define specific ontologies that will be used to exchange information across the different domains of the manufacturing system.

The requirements are a set of different information and knowledge that are necessary for the product’s lifecycle, that is, research and development, manufacturing, sales, and usage. It has specific information about the product to be manufactured, such as geometric dimensions, tolerances, customers application, laws and standards. All data information will be subclasses or instances of the reference ontologies. These arise from different sources and domains, such as manufacturing, business, customers, product development, logistics, and standardization institutes. The main types of requirements (Detail “2” of Figure 2) considered for this work are as follows:

• Production process: these can be the productive process constraints and limitations. They also represent the processes that are required to make a determined product, defined mostly by the product research and development process. For example, coating machine’s speed and crease/cutting position to make the package in the correct size.

The requirements combined with the reference ontologies pass through the ontology specialization process.

The ontology specialization process is responsible to relate reference ontologies with data information from the requirements. The ontology specialization process is shown in Figure 3, begins with two independent sources. According to (Chungoora et al., 2013; Szejka et al., 2017a), two subsumptions relations that enable taxonomies of classes and relations to existing are 1) subclass relation and 2) sub-relation. The third ontological relationship, which is not a subsumption relation, is 3) the instance-of, that makes the population of facts possible through the class instantiation.

The reference ontologies (Detail “1” of Figure 3) that represent the knowledge about manufacturing processes, products, and materials are concentrated in single ontology, through the ontology intersection process, to represent the knowledge and information about the product that it will be produced. In parallel, the requirement (Detail “2” of Figure 3) information is inserted in the ontology through a semantic reconciliation process using the semantic rules.

In the sequence, both sources (Reference Ontologies and Requirements) are combined through the context alignment, and the reference ontology is adjusted to the context of the requirements. For example, adjusting the process to use the machine available when different machines produce the same item, selecting the desired product from a portfolio, and applying specific process requirements.

The next step is ontology mapping, where all the necessary information about the artifact is stored in an instance of the reference ontology. For the ontology mapping, the Semantic Web Rule Language (SRWL) is used. The final process is the consistency check, that is, the system validation of the ontology’s consistency through a reasoning process using the first set of semantic rules. For the reasoning process, the Pellet engine reasoner is used in this research. The result of the ontology specialization process is the application ontology (Detail “3” of Figure 3), where all the information and knowledge necessary for the manufacturing process are concentrated and available for further use.

The application ontology is a specialized ontology that is a virtual representation of the desired final product. It gathers the specialized ontologies according to the data information from the requirements into a specific ontology of the product, respecting semantic rules. This process requires specialization approaches to well define the representation of the product, allowing their relationships without losing their meaning.

It contains all the information and knowledge regarding the product that will be used for the different steps of the manufacturing process. This includes information about the raw materials that will be used, product characteristics, and processes that the product will have to go through. As an instance of the final product, this application ontology is singular and should be created as soon as the necessity to make a product arises. The ontology will go through every part of the productive process and as soon as the product’s manufacturing is done, it should be destroyed. The application ontology is specific to each product that will be produced and should not be reused.

Whenever the appropriate knowledge and information are gathered into the application ontology, this can be used to exchange information across the various systems that are applied to the manufacturing context. This happens through the process of information application, described in the next sub-section.

The information application process (presented in Figure 4) begins with a new reasoning process, using a different set of semantic rules. These are used to split the information, previously concentrated in the form of the application ontology, into new sets of information, directed to every piece of the manufacturing system.

The information application is responsible after the reasoning process to distribute all specific information to different levels of the horizontal and vertical systems. For this, information application has semantic rules, which with the support of a set of plugins to ease the technical reconciliation (such as OPC, APIs, and libraries/packages), are responsible to decode the information to the manufacturing systems (enterprise resource planning—ERP, manufacturing execution system—MES, supervisory control and data acquisition—SCADA, and programmable automation controller—PAC). This process separates will take care of translating the information, that was previously in the form of ontologies, into a format that the system in concern can understand and apply to the manufacturing process.

In the case studies developed for this work, a specific type of carton package was investigated. This company’s product is used to store and ship beverages of the most varied types, such as milk drinks (chocolate, strawberry, and pure milk), juices (citric and corrosive such as orange and lemon, and non-citric such as apple and grape), and other related products, such as milk cream and condensed milk.

To demonstrate the application of the MANUMATE framework in a real case, a small example of long-life milk manufacturing chain is proposed to promote interoperable information and knowledge management across its manufacturing systems. The long-life milk manufacturing chain presents multiple requirements and restrictions to guarantee the correct manufacturability of the product. However, each stakeholder involved in this process use a different taxonomy, the manufacturing process has different machines with different supervisory systems, controllers, sensor and motors and there is a portfolio with different designs, as presented in the example illustrated in Figure 5 and Table 1. All these systems and subsystems must operate under the best condition to guarantee the delivery and quality of the final product.

As shown in Figure 5, heterogeneous information from multiple processes must be shared in the same company or across the company boundaries. Additionally, the information must be shared by multiple systems across different phases of the manufacturing process in nearly real-time. Company A in Figure 5 is long-life food packaging manufacturing, company B is the supplier of fresh milk, and company C is long-life milk manufacturing and distribution. Also, there are suppliers of raw materials (paper, aluminum, polyethylene, and ink) for the manufacturing process.

In this context, all information must be shared correctly, but misinterpretation and mistakes across the whole process were identified, implying losses throughout the process. In process 1 (P1—extrusion line) of Figure 5, for example, there is a problem with bending polyethylene, and this manufacturing problem impacts directly in the process 3 (P3—cutting line) of Figure 5, which is why it is necessary to remove the final product. Another problem is the paper thickness, which impacts process 1 (traction speed, traction force of the reel rollers, etc.), process 2 (printing speed, traction force of the reel rollers, etc.), and process 3 (cutting speed, shear stress, etc.). All this information must be manually inputted by the manufacturing operator and misinterpretation, or mistakes can occur across the process.

Before discussing processes and intermediary products, it is important to understand how this specific carton package is composed in general terms, that is, the composition of the final product that this company produces. The carton package is composed of the base carton paper, which is coated with an aluminum foil layer and a polyethylene film layer to protect the product from oxidation and light damage. A polyethylene outside the layer is added to protect the base carton paper from liquids, and improve the printed ink’s adherence, which enables the package to receive the product’s manufacturer-designed art.

Some variants could be applied to the package depending on the product that it will carry. These could be the types of polyethylene used (to protect the package from corrosion), the width of the polyethylene layer and aluminum foil, etc. But despite the different applications, all the different packages produced by the company share this same structure of layers and materials and passes through the same sequence of manufacturing processes. The carton packages manufacturing process in the company where the experimental case studies were developed has three main manufacturing processes.

In this manufacturing context, two case studies were picked and are described in the next sections. The objective is to demonstrate how the MANUMATE framework can be applied to real-world situations. A proof of concept has been developed for each case study with the owlready2 ³ framework in Python ⁴ programming language to demonstrate a simplified version of how the conceptual solution could be put into practice.

The customer is an acid juice manufacturer and requires anti-corrosive packages to store and ship his juice to his company’s customers. The customer requests an anti-corrosive package from the seller, which inputs the order into the ERP system for anti-corrosive packages. The production planner reads the customer order and needs to know how anti-corrosive packages are made. He knows that anti-corrosive packages are a sub-product of anti-corrosive coated reels and plans to produce a coated reel with the coat type anti-corrosive, inserting that information in the MES system. The coating machine operator gets the information in the MES system and verifies that he needs to produce a coated reel with type anti-corrosive. To make this coated reel, the operator must have the knowledge that for the coated reel to have the type of anti-corrosive a paper reel needs to be coated with a special type of polyethylene, also defined as anti-corrosive.

The first step of the MANUMATE framework is to select the reference ontologies. It represents the conceptual model and includes the three main classes as defined in the framework (material, process, and product) defined independently, with no relations between those ontologies. The Material class is inherited by the PaperReel class, which in this example case and to ease the understanding needs no properties; and Polyethylene class with a has_pe_type functional data property with range string. The manufacturing process in this case study is the Coat process, which is represented as a subclass of the Process class. There are no intrinsic properties that are necessary to represent in this example case for Process or Coat classes.

The Product class has an object property defined as has_sub_product, which domain and range are Product class, as well as its inverse property is_sub_product_of. The Product class is inherited by CoatedReel class, which has a has_coat_type functional property with range string; and the CartonPackage class that has a has_package_type functional property as well, with a string range. Figure 6 illustrates the structure of the reference ontology.

The next step in the MANUMATE framework is the ontology specialization process. The reference ontologies are enriched with information from the requirements. In the case study’s context, the Material class is enhanced with the inverse object property is_raw_material_of with a range of Process classes. The Process class (and by heritage Coat class is added with two object properties: has_final_product that has the range of Product class and represents the output of the manufacturing processes in this context, which is a product; and has_raw_material with the range Material, that represents the materials used as input to the manufacturing processes. The inverse object property is_final_product_of with range Process is added to the Product class, as a link of the origin of that product regarding manufacturing processes. Figure 6 presents the reference ontology architecture to support the experimental case “A.”

The application ontology is then constructed by defining individuals for the enriched ontology. The Material individuals are pe1 that is a member of polyethylene class and has_pe_type property is defined as anti-corrosive; and paper_reel1, that is a member of PaperReel class. The process individual is coat_proc1 that is a member of the Coat class. Product individuals are coated_reel1 member of CoatedReel class with has_coat_type defined as anti-corrosive, and carton_pack1 that is member of CartonPackage class with the property has_package_type with the value of anti-corrosive as well. To establish a link between these individuals, cross-properties are added. The individual coat_proc1 has a list containing pe1 and paper_reel1 individuals that they are assigned to the property has_raw_material. The coated_reel1 individual is defined as the value for the coat_proc1 individuals, has_final_product object property and it has property has_sub_product defined as the element carton_pack1. Figure 7 summarizes the specialized ontology based on these characteristics.

In Figure 7, it is possible to verify the final step of the MANUMATE framework happening, where the information and knowledge modeled in the form of the application ontology is then applied to each pertinent part of the manufacturing process, without the need of human intervention. It is also relevant to notice the vertical integration happening in the manufacturing system.

In this case study, the final customer gets in contact with the seller to send the image that he wants to be printed in his carton packages, as described in Figure 8. The customer defines that his packages must have a specific image printed. The seller adds the packages’ request and image information into the ERP system. The production planner must know that to have packages printed with a specific image, it is necessary to have a printed reel with the image out of the print process, to then send to the cut process to make the packages. He adds that information to the MES system.

The printer machine operator knows that to have a printed reel with a specific image, he must print a coated reel with the image in concern. But the operator also needs to know that the next manufacturing process uses a cutting tool that has a tool thickness that might cut a part of the printed image out of the final product. The printer operator then adds an offset spacing between the images printed and must agree with the cutter machine operator to use a cutting tool with the same value of tool thickness as the offset value.

The application for this case study of the MANUMATE framework starts with the reference ontology model. The reference ontologies of product, material, and process could be reused from the last case study, but the authors chose to use a new reference ontology.

The material subclasses are defined based on the raw materials that will be necessary as inputs of the manufacturing processes. Two classes are defined as subclasses of the material class: CoatedReel with no properties and PrintedReel with a has_image functional property with a range string. This represents the image that has been/will be printed on a PrintedReel individual. The PrintedReel class has been defined as a subclass of the material class because it is used as a raw material for the cut process but is also a subclass of the product class because printed reels are the final product of the print process. In case B, the Process class has also two subclasses. The print class represents the print manufacturing process and has two functional data properties: has_print_image with range str that represents the name of the image to be printed on the reel in the print manufacturing process; and has_offset with range int, which represents the offset to be applied between the images to be printed, so that they do not get cut on the cut manufacturing process. The Cut class is a model of the cut manufacturing process and contains the has_tool_thickness functional data property with a range of type int. This property is used to store the thickness of the tool to be used on the cut process. The Product class is the parent class of the already defined PrintedReel class, and the final product of this manufacturing process is the CartonPackage class. The latter has a single functional Data Property with range str defined as has_image, which represents the image that a CartonPackage has printed on it. Figure 9 presents the reference ontology architecture to support the experimental case “B.”

The next step in the MANUMATE framework is to specialize the reference ontologies. For this manufacturing process, the modeling is the same as the case study A for the ontologies material, process, and product. Two object properties were added to the process ontology: has_final_product with range Product represents the final product that the manufacturing process produces and has_raw_material with range Material that corresponds to the raw materials used as a base by the manufacturing processes to produce the final product. The corresponding inverse object properties were added as well to material class the is_raw_material_of and product class the is_final_product_of properties, both with the range Process.

The next step in the MANUMATE framework implementation for case study B is defining the individuals in the application ontology. For the material individuals and using the CoatedReel class, the coated_reel1 is defined. The individual printed_reel1 is an instance of the PrintedReel class, and the value of “milk.jpg,” corresponding to the image of the case study, is assigned to the has_image property.

For the process individuals, the print_proc1 is declared from the class Print and the example image “milk.jpg” is assigned to the has_print_image property. The element cut_proc1 is an instance of the Cut class, with the has_tool_thickness property value of “5.” The product class has a single individual. Created from the subclass CartonPackage, the individual carton_pack1 also has the example image “milk.jpg” attributed as value to the has_image property. These individuals are then related to each other by assigning coated_reel1 as has_raw_material for print_proc1, which also has printed_reel1 assigned to the has_final_product property. The cut_proc1 property has_raw_material is defined as printed_reel1 and the has_final_product property receives the carton_pack1 as value. The print_proc1 property has_offset then receives the value of the cut_proc1 has_tool_thickness property.

The final application ontology and information application for case study B are demonstrated conceptually in Figure 10. The MANUMATE is represented as a support system, by receiving the input from the seller and sharing the necessary information to each of the systems in the manufacturing system. It is also possible to verify the vertical integration happening between the manufacturing systems, and the horizontal integration happening between the different correlated manufacturing processes.