Realization to Achieve Both Standardization and Customization with Open Standards (OPC UA, PackML)

In recent years, many efforts have been made to increase productivity by standardizing manufacturing data (information) and unifying the design and maintenance in the manufacturing industry. On the other hand, customization (unique specifications or vendor-specific specifications) to create value and strengthen competitive advantage is carried out in various aspects due to the importance of its purpose. However, this is contradictory to standardization and the way to achieve both (standardization and customization) has become an issue now. In order to solve the issue mentioned above, open standards OPC UA (OPC Unified Architecture)^1-3) and PackML (Packaging Machine Language)^4-6) have been used to develop a product that can easily standardize information on the Controller that serves as an important hub (center) of information at the manufacturing site as well as several methods that can customize. These have made it possible to both standardize and customize the information and to strengthen the separation of information. The details of the above approaches are explained in this paper, which can be applicable to cases such as the use of other open standards and individual customer support.

1. Introduction

Recent manufacturing sites have it as an aim to achieve, among other things, sustainable improvements in productivity or effective use of resources. Hence, standardization of information has been underway within and without the levels of suppliers, vendors, industries, countries, economic blocs, and the like^7-10). Fig. 1 shows an example of standardization for a manufacturing system.

On the other hand, such entities as suppliers, vendors, industries, countries, and economic blocs attempt to manage their core competence, including their tacit knowledge, as their proprietary specifications in the form of customized information to maintain value creation, competitive edge, and other advantages.

Fig. 2 shows examples of proprietary specifications in a manufacturing system, in other words, examples of not desiring to be standardized.

Efforts have been made to achieve these incompatible objectives. However, challenges exist in separating and optimizing standard specifications and customized portions during design, for example, at the vendor level.

To solve the above challenges, we newly developed a library product that easily enables information standardization and a method that enables information customization on a controller serving as a critical information hub (center) on the manufacturing site, using OPC UA (IEC 62541) and PackML (ANSI/ISA-TR88), open standards currently attracting attention.

In this paper, Section 2 explains the efforts pursued toward standardization and customization for OPC UA and PackML in conventional technologies. Section 3 outlines the challenges encountered in these efforts, while Section 4 details the solutions. Section 5 presents discussions, future challenges, and prospects.

2. Efforts in conventional technologies

2.1 Introduction

OPC UA is the standard specification for general-purpose communications, which is required mainly between information technology (IT) and operational technology (OT). It enables security-assured, highly reliable data exchange beyond the barriers between equipment types, operating systems (OS), or manufacturers. As such, OPC UA is recommended as the standard communication protocol for Industrie 4.0. With this recommendation as an impetus, OPC UA has attracted surging interest worldwide³⁾.

On the other hand, PackML is a standard specification specifically tailored to packaging machine applications. It has traditionally specified the action and operation of machines at the manufacturing site level and their interfaces with host systems. Following the agreement reached on its application to OPC UA by the Organization for Machine Automation and Control (OMAC) and the OPC Foundation, Version 1.00 Specification was established in 2018 as the standard specification for communications (OPC UA for PackML)⁴⁾.

This section explains specific situations of standardization and customization efforts in conventional technologies.

2.2 Efforts toward standardization

2.2.1 OPC UA

OPC UA specifications represent information in the form of information models. An information model is, so to speak, a profile of a device, machine, or line. Specific information models tailored to the characteristics of individual devices, machines, or lines are called companion specifications. These specifications are standardized through such methods as collaborations between individual trade groups and the OPC Foundation^3,4). A companion specification consists of a human-friendly specification (document) and a machine-friendly XML representing a data structure. XML files containing standardized companion specifications are available on the internet and elsewhere. Individual information items and the like in standardized information model specifications are not uniquely specified, which is because of such considerations as the need to ensure the flexibility of standard specifications, but are specified as substantially selective in such forms as mandatory (required) and optional (not required) for the items concerned¹⁾.

On the other hand, customization (proprietary specification), in our sense, refers to customer-specific information model definitions (extensions) and is made possible based on information model definitions in companion specifications and the like.

Fig. 3 shows the logical configuration of information models in OPC UA. Meanwhile, Fig. 4 shows examples of companion specifications as an embodied information model.

2.2.2 PackML: OPC UA for PackML

PackML specifications provide standard definitions for control program structures, machine operation modes or state transitions, machine external interfaces (Pack-Tags), and the like⁴⁾. Fig. 5 shows a typical PackML state transition diagram. Of such specifications, what serves as OPC UA specifications and provides standard definitions mainly for machine external interfaces has become companion specifications known as OPC UA for PackML, which enables access to information defined standard in PackML via the international standard OPC UA communication protocol⁴⁾. Fig. 6 shows a typical information model in OPC UA for PackML.

OPC UA specifications for PackML are also examples of companion specifications, and their specific form is XML files. The same applies to other companion specifications in the previous sub-subsection.

2.3 Efforts toward customization

Until the previous subsection, we explained that the specific form of information models standardized in OPC UA is XML files in many cases. In specific terms, customization often means supporting these XML files. From our knowledge, we assume that customization at this point falls mainly into the four types listed below. Caution must be exercised depending on the context or the requirement content.

1. Cases where customization refers to selecting optional in the standardized information model specification
2. Cases where customization changes the defined content of the standardized information model specification
3. Cases where customization inserts something not found in the standardized information model specification
4. Cases where standardization is completely absent (proprietary specifications)

Note, however, that although Type 4 cases logically exist, proprietary specifications can be sufficiently developed for conventional technologies and products. Moreover, these cases do not correspond to the sort of standardization or customization this paper mentions and, hence, will not be mentioned hereinafter.

To respond to customization requirements and the like for standardized information models, individual entities such as suppliers/vendors (including vendors that supply not only equipment but OPC UA software development kits (SDKs) and the like) and industries develop, supply, and use editor/generator tools for information models under such names as Modeler, Information Model Editor, and Node Set Generator. In this way, individual entities respond to requirements for new proprietary development or customization of information models. These editor/generator tools are so-called XML editors (hereinafter, these editor/generator tools are collectively called “information model editors”).

Editing/generation using such an information model editor is far beyond the abilities of an average developer. The reasons are as follows: expert knowledge relating to OPC UA specifications is required; and, to obtain appropriate customized specifications that also consider standard specifications in the industry concerned or for the equipment concerned, one must be as knowledgeable about the industry/equipment concerned as experts in them. Under these conditions, a vendor or the like of an information model editor sometimes performs customization while consulting with the editor’s customer. Alternatively, proprietary development may be pursued in-house, where vertically integrated system development is possible. Another alternative may be to use a specialist subcontractor.

3. Challenges

In the preceding sections, we have explained specific efforts pursued toward standardization and customization in conventional technologies, such as OPC UA and PackML. This section explains the challenges in these efforts.

3.1 Challenges in standardization efforts

3.1.1 Information contents and amounts variable despite compliance with standard specifications (Mandatory and Optional)

The previous section mentioned that OPC UA specifications are specified as substantially selective in such forms as mandatory and optional (more precisely, specification items called Modeling Rules).

A sticky situation occurs when such a way of specification is considered a standard specification effort. The reason is as follows: despite compliance with a standard specification, the variability of the selection of optional will result in various combinations of information structures, which may lead to such a problem as more difficult development or general-purpose utilization of the OPC UA client that accesses the information structures. Fig. 7 shows the typical content of an actual specification, which uses the standard Modeling Rules of mandatory and optional. Fig. 7 illustrates that Instances A1 to A14 can be defined according to the type definition of TYPE_A.

Based on the history so far or our knowledge about specifications, we can assume some degree of necessity for a standard specification containing optional for various reasons. In addition, OPC UA assumes the premise that the OPC UA client obtains and grasps the type information at the top of Fig. 7, including optional, and accesses the instance information that the OPC UA server has. Therefore, the specification items of optional pose no challenge to the specification. However, even if we limit ourselves to, for example, Fig. 7, all the information structures A1 to A14 must be supported for Type_A alone. Therefore, in practice, the OPC UA client would be more difficult to develop, posing a challenge.

3.1.2 Gap between the amount of information the customer needs and that contained in the standard specification

Another challenge is that a gap can occur between the amount of information a customer needs and the ample amount of information contained in a standard specification.

An actual voice of the customer (VOC) obtained from a small-scale equipment manufacturer regarding a companion specification read: “When the amount of information provided so far by our equipment is considered, the maximum amount of information contained in the companion specification need not be implemented.”

In other words, to support companion specifications, the customer may sometimes have to provide new information so far unavailable from their equipment. Hence, the customer may face the challenge of a higher development cost than before.

3.2 Challenges in customization efforts

3.2.1 Cases where customization refers to selecting Optional in the standardized information model specification

Until the previous section, we discussed mandatory and optional as challenges. Besides, from the perspective of separating standard and customized portions, mandatory and optional pose the following practical challenges.

It is impossible to assert whether selecting optional in a standard specification to make different requirements is a standardization or customization requirement. Moreover, it is far from clear what range of standard specifications an OPC UA client must support to be regarded as standard specification compliant.

These challenges increase the difficulty of developing a standard specification-compliant client. In addition, the ambiguous boundary between these challenges impedes, for example, the customer focusing on their proprietary customized portions to put their energies into further productivity improvements and other efforts.

We heard from a customer who said that if the standard specification has no problem, they want to consider nothing and focus exclusively on any proprietary information that must absolutely be inserted. This situation is challenging for the customer.

The next and subsequent sections take up this case as a clue to the solution to the challenge of ensuring the identity of the standard specification to be complied with in the standardization efforts.

3.2.2 Cases where customization changes the defined content of the standardized information model specification

According to the information and data obtained so far from the OPC Foundation or our customers, the background situations described below have led to forms of customization changing the defined contents of standardized information model specifications. We analyze that such cases of customization can pose a challenge detrimental to further productivity improvements and the like through standardization. Therefore, the next and subsequent sections take up this case as a clue to the solution to the challenge of ensuring the identity of the standard specification to be complied with in standardization efforts.

1. Existing conditions unable/unlikely to motivate suppliers and vendors to apply standards

   Currently, in many cases, standardization is promoted as part of improvement primarily by suppliers and vendors for their own good^9-11). Based on the information and data obtained so far from the OPC Foundation or our customers, we surmise that many suppliers and vendors consider that if standardization is possible within the in-house range, that will do. However, such standardization within single suppliers/vendors alone cannot seem to provide perspectives such as further sustainable improvements in productivity, competitiveness, and the like in the future^9-11).

2. Existing conditions conducive to discretionary information tailoring

• (a) In many cases, an information model editor allows the user to write and edit anything. Based on the information and data obtained so far from the OPC Foundation or our customers, we analyze that it is currently a natural course of action for enterprises to bring in and modify the OPC UA standard specifications into information structures that best suit their desired use.
• (b) As explained above, customizing information models requires considerable skills. Accordingly, many cases require the use of consultants or outsourcing.
• (c) Some existing vendors provide consulting services, functions, or subcontracting services such as those described above. They are left free to perform customization at their discretion.

3.2.3 Cases where customization inserts something not found in the standardized information model specification

Though it may depend on the nature of something not found in the standardized information model specification, this type of customization is a challenge for rather forward-looking evolution, as we analyze below.

In many cases, attempts/requirements made to insert something not found in the standardized information model specification are classified into the following cases based on the information and data obtained so far from the OPC Foundation or our customers:

1. Information that should be already established as standard specifications but is not yet

   Though required as customized specifications, some information is of content that is necessary for any enterprise, equipment, industry, country, or economic bloc regardless of rivalry between competitors. In some cases, multiple standard specifications coexist or are merged, resulting in the need for customized specifications. In our understanding of the nature of standard specifications, these cases can be regarded as manifestations of the simple insufficiency of standard specifications and their applicability. Standard specifications are also required to evolve continuously.

   This case is a matter of continuous evolution of standard specifications and will not be discussed hereinafter.

2. Information that should avoid standardization (or open disclosure)

   Information of this kind is utilized by different entities, such as suppliers, vendors, industries, countries, and economic blocs. Based on such information, they identify their core competence, including their tacit knowledge, and turn it into explicit/informatized knowledge in the form of customized information. This process helps them to maintain their existential value, competitiveness, and other advantages. Future potential and scalability may also be considerations. This type of information has high confidentiality and, as such, requires robust protection. We analyze that this case poses a challenge in customization efforts when an attempt is made to further improve the current customization practices for their proper promotion.

   The next and subsequent sections take up this case only as a clue to the solution to challenges in customization efforts.

4. Solutions

When an attempt is made to further improve the current standardization and customization practices for their proper promotion, challenges remain with the following as observed above: information contents and amounts variable despite compliance with standard specifications, gaps relative to customer requirements, and how to separate standard and customized portions. We achieved the following as the solutions to these challenges:

4.1 Solutions in standardization efforts

We newly developed a library that enables easy standardization of information as a solution to the challenges in efforts toward standardization^11-15). More specifically, this library is the function block (FB) library (Type SYSMAC-XR101) intended for the FA-integrated development environment Sysmac Studio to develop OPC UA companion specifications for PackML. The following sub-subsections describe its technical features.

4.1.1 Ensuring the identity of the standard specification to be complied with

Sub-subsection 3.1.1 mentioned the possibility of information contents and amounts variable despite compliance with standard specifications and the challenge with mandatory and optional. To accommodate differences that may occur in specification and implementation as viewed from outside due to the variability of the selection of optional, we chose to support all optional selections as components of this library.

As a result, standards and information are guaranteed for identity to any user of this library. Fig. 8 shows the conceptual image of this aspect.

4.1.2 Ensuring the selectivity of the amount of implementation

Sub-subsection 3.1.2 mentioned the gap that may occur between the amount of information a customer needs and that contained in a standard specification when a standard specification effort is attempted. With the effort made, including all optional selections as in the previous subsection, such a gap is all the more likely to occur. With this point in mind, we designed this library so that whether to handle the data of the node concerned can be determined as part of the design of the controller program.

As a result, the user of this library can decide the selection of Optional at the design phase of the controller program. More specifically, we made it possible for the user to make that decision based on whether or not to set the data as FB parameters. Fig. 9 shows the conceptual image of this implementation.

4.1.3 Complete separation of standard and customized portions

Throughout Section 3, we observed that standard and customized portions currently exist as intermixed and that multiple types of customizations exist. As observed until the previous subsection, we designed this library to be a standard identical for anyone, including the optional data area, to ensure the reliability of the standard portion. Besides, the library was designed to preclude unrestricted modifications by its users, whereby no room was left for customization. Thus, we achieved a complete separation of standard and customized portions.

4.2 Solutions in customization efforts

To contribute to solving the challenge in Item 2 of Sub-subsection 3.2.3, we developed three methods that enable customization^11-15). The following sub-subsections describe the technical features of these methods.

4.2.1 Functional expansion of information models as PLC information (Solution 1)

As mentioned at the beginning of this paper, this solution needs to be implemented on a controller that serves as a critical information hub (center) at a manufacturing site. Information tailoring, supported for conventional technologies and products, should be expanded into appropriate forms for customization efforts.

Based on the above, we expanded the support range of the OPC UA Information Model for IEC 61131-3 (OPC 30000), which is the companion specification for programmable logic controllers (PLCs) supported by the NJ/NX Series CPU units in our product lineup¹⁶⁾. More specifically, this companion specification formerly supported global variable exposure only; it was expanded to support exposing (FB) local variables in addition to global variables. As a result, what used to be a simple ability to expose variables in the PLC through the global variable was enhanced to represent information flexibly in more structurally divided or structured ways, using even the namespace function, FB function, and the like. Besides, these areas became newly available to be granted roles (operation authorities) from the OPC UA network. As a result, information storage has become possible with more security guaranteed. Note that this role (operation authority) function can be applied to cases of other companion specifications.

These functional expansion efforts enabled information to be represented more flexibly and with more security guaranteed. An OPC 30000-compliant information storage location was selected as a more suitable location for storing customized information.

Fig. 10 shows the OPC 30000-compliant change point and its post-expansion conceptual image. Besides, Fig. 11 shows the conceptual image of information concealment using the role function.

4.2.2 Provision of an OPC UA node configuration customization method (Solution 2)

The method presented in the previous sub-subsection has expanded from a conventional specification and, as such, follows the existing specification of the appearance of controller information. In other words, the method stops short of allowing customization of the appearance of the node configuration in OPC UA for PackML.

Therefore, we newly developed a simplified information model editor as a sales promotion tool that can be used by in-house system engineers (SEs)/developers as an OPC UA node configuration customization method.

As a result, we can now provide a method for modifying the node configuration in OPC UA for PackML. Note that this method can be applied to OPC UA node configurations in other information models not limited to OPC UA for PackML. As regards the restrictive constraint on the current simplified information model editor (being able to customize variable node configurations only), we will pursue further considerations and make efforts to expand its applicability.

4.2.3 Sufficient technical maturity for dedicated library development (Solution 3)

As mentioned in the previous sub-subsection, the method presented there is limited in applicability and can only customize the configuration of some OPC UA nodes (variable nodes).

Therefore, through our efforts this time, we have newly achieved the following and attained sufficient technical maturity to develop customer-dedicated custom model libraries.

1. Establishment of a general-purpose specification for OPC UA information space (address space)-to-controller function association specifications

   Our latest efforts have led to a newly established internal specification for mapping OPC UA information space-to-controller function association specifications for general use.

2. Establishment of an internal general-purpose interface (I/F) for calling the function block (FB) from the OPC UA network

   Similarly to Item 1 above, we have newly established an internal general-purpose interface (I/F) for calling the function block (FB) from the OPC UA network. These achievements have led to sufficient technical maturity for even non-product developers to develop specially tailored dedicated libraries.

5. Conclusions

Through the efforts presented in this paper, we assembled adaptive efforts to the current challenges, such as variations in standard information content and amount in the standardization efforts described in Section 3 and gaps relative to customer requirements, into a single integrated solution package, including simplification. We also successfully provided methods of applying standard specifications to suit the scale of the user environment. These achievements enabled complete separation between standard and customized portions, which we consider may become a factor that can significantly affect the current methods of efforts toward standardization and customization, including what will be necessary for the future for further advancement, for example, what would occur or should be done if standards were to be placed in the cloud.

For customization, we addressed challenges relating to its further separation from standardization in the customization efforts described in Section 3 by newly developing and presenting three functions/methods for integration into standardization efforts and another three functions/methods for customization. However, considering the weight we gave to the feasibility/robustness of standardization, we probably should make further considerations and improvements to customization. There may be arguments regarding whether the current PLC information model is most suitable for storing customized information.

Moving forward, we will promote activities to spread this standardization to more manufacturing sites, industries, and the like while picking up the VOC. The technology developed this time has extensive applicability to opportunities for other standardization and functional additions, for example. We intend to contribute to technological deployment and problem-solving to further advance standardization and functions in the future.

Last but not least, we would like to take this opportunity to express our most sincere gratitude to those who significantly helped us achieve the technology, functions, and products presented in this paper and to everyone who will cooperate with us in deploying the functions and products in the future.

References

1）

OPC Unified Architecture Core, OPC10000, 2016-2024.

2）

OMRON Corporation. “Original Explanatory Notes: What Is OPC UA?” (in Japanese), Dedicated Site. https://www.fa.omron.co.jp/product/special/sysmac/nx1/opcua.html (Accessed: Jan. 19, 2024).

3）

Y. Ogawa. “Solution Examples in OPC UA Application to FA.” (in Japanese), OPC Foundation Japan Introductory Seminar to OPC UA Solutions. https://jp.opcfoundation.org/wp-content/uploads/sites/2/2022/09/OPC-UA-Seminar_Session4_Omron.pdf (Accessed: Aug. 26, 2022).

4）

T. Ueki. “Standardization Supporting Data Utilization in Manufacturing with Increasing Complexity.” (in Japanese), OPC Foundation Japan OPC Day 2023. https://jp.opcfoundation.org/wp-content/uploads/sites/2/2023/12/1-3_Standardization%E3%83%BCOPC-UA_for_PackML%E3%83%BC.pdf (Accessed: Dec. 7, 2023).

5）

OPC UA for PackML, OPC30050, 2020.

6）

OMRON Corporation. Sysmac Library User’s Manual: OPC UA PackML Library Section for Type SYSMAC-XR101, (in Japanese), SBCA-505B. (2023). Accessed: Jan. 19, 2024. [Online]. Available: https://www.fa.omron.co.jp/data_pdf/mnu/sbca-505b_sysmacxr101.pdf?id=3459

7）

T. Kawano, “Standardization Strategy of the German Manufacturing Policy: Industrie 4.0,” (in Japanese), J. Robot. Soc. Jpn, vol. 33, no. 5, pp. 318-324, 2015.

8）

K. Ogawa, “Open and Close Strategy and Its Deployment in Business.” (in Japanese), Engineering Advancement Association of Japan, Year 2023 Sixth Lecture Meeting, Season 3 of Latest DX Seminar for Engineering. https://www.enaa.or.jp/?fname=DX2023-6.pdf (Accessed: Dec. 22, 2023).

9）

M. Eto, “Standardization Strategies of European Enterprises,” (in Japanese), in Proc. Annu. Conf. Jpn Soc. Sci. Policy and Res. Manage., 2013, vol. 28, pp. 954-959.

10）

A. Tokuda et al., Open Innovation System, (in Japanese), 1st ed. Koyo Shobo, 2011.

11）

J. Shintaku, “Competition Strategies of Japanese Enterprises Based on Architecture Analysis,” (in Japanese), MMRC Discuss. Paper, no. 54, 2005.

12）

K. Katano and C. Nishio, “Effectiveness of Customer Interfaces and Decoupling Points in Mass Customization Strategies,” (in Japanese), Int. J. Marketing & Distributions, vol. 7, no. 2, pp. 19-37, 2004.

13）

A. Ono, “Customization and Personalization,” (in Japanese), Quart. J. Marketing, vol. 40, no. 1, pp. 3-5, 2020.

14）

A. Ono, “Buying Intention Toward Mass-Customized Products,” (in Japanese), Mita Bus. Rev., vol. 50, no. 2, pp. 1-18, 2007.

15）

K. Katano, “From Mass Customization Strategy to Personalizing Co-creation Experiences,” (in Japanese), Meisei Univ., Bull. Manage. Sci., no. 7, pp. 45-58, 2012.

16）

OPC UA Information Model for IEC 61131-3, OPC30000, 2010-2020.