A reference model for common understanding of capabilities and skills in manufacturing

3.1 Requirements and model overview

An overview of requirements from various publications was condensed by [2]. The most relevant requirements for this work are discussed here, while more specific requirements, e.g., regarding solution technologies, are out of the scope of this work. Models of capabilities, skills, and services need to foster more efficient approaches to production planning and production system reconfiguration. This need can be considered a paramount requirement from which all others can be derived. Both matchability and executability are often mentioned as a requirement highlighting the need for a description of functions on different levels [2]. While matchability may best be achieved with formal models, executability necessitates bindings to implementation technologies. Thus, a clear distinction between these concepts is needed. Skills must have a communication interface, and individual skill states need to be expressed [2].

Figure 1 represents a Unified Modeling Language (UML) class diagram to illustrate the developed CSS reference model considering the previously discussed requirements. The model distinguishes the three areas capability, skill, and service. In each of the areas, the main concepts and their relations to other model elements are defined. In addition, the main concepts of each aspect are related to PPR concepts.

3.2 Services

One of the promising and future-oriented developments of the manufacturing industry is the upcoming transformation of industrial production into shared production. According to this scenario, production sites will form cross-company networks. In such networks, service providers can offer their manufacturing capabilities and integrate the capabilities of external partners into their own production processes based on specific orders. Such scenarios imply automated order processing in supply chains spanning various companies. The challenge in realizing such shared production networks is interoperability. In this context, important parameters beyond a pure technical description of provided capabilities need to be considered for order processing [11, 13]. These are, for example, information on economic criteria such as delivery dates, cost, and agreements regarding documentation or maintenance, certification, and rating. For modeling such issues and distinguishing them from the concept of capability, this work introduces the term service in an economic sense representing a set of capabilities supplemented by an organizational and economic description. It should be noted that the service concept presented here is different from the same term used in information technology (see Section 5.1 for a distinction).

In the context of the CSS model, a service requester, which provides a specification of a requested service with its properties, demands suitable services. service providers can provide services suitable to fulfill a demanded service. They then can propose a service offer as the basis of a binding contract to execute one or more services. The service requester can accept the proposal under the proposed conditions in a specified time period. If service requesters are searching for services through a marketplace, multiple service offers may be created by different service providers. These service offers could be mutually exclusive or could also be combined to fulfill a requested service.

3.3 Capabilities

We define a capability as “an implementation-independent specification of a function in industrial production to achieve an effect in the physical or virtual world”. Thus, a capability specifies a function in a production process. Usually, capabilities specify production functions that have an effect in the physical world. Nevertheless, software functions that only apply to the virtual world may also be modeled as a capability. capabilities that specify a production function should refer to terms of an actual manufacturing method, such as “drilling”, along with properties and capability constraints to precisely describe their application. An example of a capability could read “drilling a hole with a particular depth and a diameter into certain types of material”.

capabilities are either provided by production resources that claim the ability to apply the expressed function or are required by a process as part of a product’s functional requirements. Required and provided capabilities typically differ, e.g., because provided capabilities are described in more detail to enable reuse for a range of operating conditions or even different processes. A matching between required and provided capabilities is thus necessary to find candidates for a suitable sequence of production steps for given requirements. This matching can initially be done on a descriptive level – e.g., by comparing capability types and their properties – regardless of which actual resources execute these process steps later.

In the CSS model, capabilities are related to the concepts skill and service. The implementation of capabilities is possible through skills, which contain details at the level of implementation and invocation of automation functions. In a broader supply chain network outside a company-internal production setup, capabilities are offered through services.

3.4 Skills

We define a skill as “an executable implementation of an encapsulated (automation) function specified by a capability”. A skill is provided by a resource in the production environment and enables the realization of a capability. Every capability may reference multiple skills in a production environment that act as implementations for this capability. skills must have a skill Interface allowing external systems, e.g., a Manufacturing Execution System (MES), to interact with the provided function. Every skills behavior needs to follow a harmonized state machine describing possible states and transitions. The state machine needs to be exposed via the skill interface so that the current state can be monitored and transitions can be triggered. The execution of one or more skills allows to control production steps. skills can have input or output skill parameters enabling the execution or monitoring of a skill. These skill parameters must also be exposed by the skill interface in order to set or get parameter values. Specifying input parameters makes it possible to execute defined production steps with an individual configuration. Every skill parameter references a property. On the one hand, this property may be a capability property, i.e., a property that is also used in a capability constraint. On the other hand, this property may also be a process or resource property which may only be relevant for execution but not for planning on capability level.

The distinction between capabilities and skills decouples the description of a function from its implementation and enables developers to freely select a technology and programming language to implement skills. In addition, multiple skill interfaces may be provided for one skill. This further decouples the skill implementation from its users that consume a skill only through its interface without being bound to the actual implementation. Integrators may select a skill interface matching their technology stack. With a suitable software architecture, skill interfaces can be installed or configured at the time of integration [14]. Admittedly, this requires more flexible and modular control approaches than the ones defined in IEC 61131.

4.1 Modeling capabilities using ontologies

Semantic Web technologies provide mechanisms for knowledge representation in information systems. They are based on a stack of downward-compatible languages for information models and knowledge representation standardized by the W3C. Ontologies constitute reusable information models that capture the knowledge of a domain in a general form, independent of specific applications and are used as semantically rich schemas for knowledge graphs. The W3C technology stack for ontologies consists of the Resource Description Framework (RDF)^[3] and its schema extension (RDFS)^[4] that form the representational basis for the Web Ontology Language (OWL).^[5] OWL allows to express domain knowledge in terms of logical statements that support automated reasoning for infering implicit knowledge. Additional powerful technologies such as SPARQL^[6] and SHACL^[7] may be used to query for and validate the information in RDF-based data models.

Semantic Web technologies provide an ideal candidate solution for the semantically rich representation of capabilities concerning their surrounding PPR model elements and for the matching of semantic capability descriptions. A direct way of utilizing OWL is to model the notion of capability as an OWL class. One can then use OWL restrictions on OWL properties for representing properties and their constraints from the CSS Model. Applications can then introduce specific capabilities like drilling by means of sub-classing together with their relevant properties restricted in complex OWL class expressions. An example of such an expression in OWL Manchester syntax is “Drilling and (depth some integer[<=15])” to represent a capability for drilling with a depth of max. 15 mm. The specialization hierarchies for capability classes can be taken from standards such as DIN 8580 or VDI 2860, as proposed in [8]. This representational approach is similar to the one presented in [9] and extends it by equipping otherwise opaque capability classes with constraints on properties to account for their rich semantics.

Moreover, OWL reasoning can be utilized for capability matching, at least on a coarse level of detail. The conjunction formed from two capability class expressions—one offered by a resource and the other one requested for a process—can be checked for satisfiability by any standard OWL reasoner to test whether the two capabilities are compatible, meaning that their constraint sets can be jointly fulfilled. This technique goes back to the intersection matching proposed in [15]. As discussed in [16], issues with OWL’s open-world assumption can be overcome by strictly controlling the ontological vocabulary used. This requires systematically including so-called closure axioms, which is presumably easy to achieve in a factory environment, e.g., disjointness between sibling capability classes from standard hierarchies. Still, this approach needs further research on potential issues with scalability and expressivity in comparison to alternative constraint solving methods when applied in real setups with complex capability descriptions on large property sets.

4.2 Executing skills using OPC UA

In recent years, the possibilities of implementing skills have been investigated and implemented in various publications and research projects, such as DEVEKOS, BaSys4.0/4.2, AKOMI or SmartMA-X [10, 17], [18], [19], [20], [21], [22]. The vendor-independent communication standard Open Platform Communications Unified Architecture (OPC UA) has emerged as a promising approach for implementing skill interfaces. OPC UA has a high degree of diffusion in control technology due to its ability to provide a resource-neutral information model in its servers. The description of skills with all skill parameters can be mapped directly within this information model to enable unified control of resources. So far, standardized OPC UA information models (so-called “Companion Specifications”), focused primarily on data acquisition, e.g., for asset management or condition monitoring. These use cases require primarily read-only access which does not enable complete interoperability of machines in the sense of the Industrie 4.0 vision. Furthermore, a classic real-time capable communication standard for controlling the resources is still required. This currently means there can either be separate networks for data acquisition and control or a shared network that strongly limits the available traffic. Therefore, it is essential to enable write and, thus, control access to these machines and systems over OPC UA. Companion Specifications, such as the PackML state machine (OPC 30050) [23] or OPC UA programs (OPC 10000-10) [24], show first approaches for such access. However, there is a lack of a uniform and cross-domain concept for the realization of skills that OPC UA can provide.

As shown in Figure 1, a distinction between the skill interface and the actual skill is necessary. The skill interface can be defined as an OPC UA information model. Figure 2 shows a proposal for this model. A separate OPC UA ObjectType with the name SkillType is created, which provides the essential elements for the skill interface: The name of the skill is optional and serves as plain text for the user to quickly identify the skill. The ontologyURL must be specified and forms the reference to the capability in the ontology model (cf. Section 3.3). This reference can be used to identify the capability realized. The skillStateMachine represents a finite state machine similar to the aforementioned OPC UA for PackML or OPC UA programs. The ParameterSet contains necessary parameters to set or check during or after skill execution:

1. The LocalRuntimeID serves a client as a unique identifier to identify the skill for execution.

2. The placeholder <InputParameter> is used to define any input parameters necessary for the execution or configuration of a skill. These can be, for example, position or speed parameters.

3. The placeholder <OutputParameter> is used to define any output parameters that are returned by a skill. These can be, for example, current actual values (speed, velocity) during the skill execution, which are necessary for synchronization with other skills. Furthermore, it is also conceivable to create sensory skills, for example, for quality assurance, whose result is also represented by output parameters [19].

Figure 2:

OPC UA skill metamodel.

The optional FeasibilityCheck may be used to confirm the execution of complex skills in advance [20]. A feasibility check can also be implemented as a state machine in the OPC UA information model. To check the executability of a skill, the required input parameters are written into the parameter set of the feasibility check. The optional PreconditionCheck checks shortly before executing a skill whether the required resource fulfills all necessary conditions. This is especially needed if the execution depends on many other factors. In the assembly domain, this could be checking whether a required component is in stock, or, in the field of machine tools, checking if needed tools are available. Furthermore, the concept of skills can be integrated into OPC UA PubSub over Time-Sensitive Networking (TSN) to realize real-time capable communication for skills.

4.3 Describing services using the Asset Administration Shell

Only few publications, such as [11], distinguish the concept of service from capabilities and skills. Furthermore, in existing publications, there are no implementation examples for services. The exchange of information between companies must be based on mutually agreed semantics, which is standardized in the best case. Therefore, one solution to describe services is the Asset Administration Shell (AAS). The AAS is an Industrie 4.0 specification of a digital twin to enhance interoperability between systems of different vendors. Recently published specifications define a standardized AAS meta model and AAS interface [25]. The meta model specifies a set of elements used to create information models that are compliant with the concepts of Industrie 4.0, so-called Submodels (SMs), needed to represent several aspects and functionalities of a modeled asset. Using standardized SMs to ensure cross-company interoperability includes the standardization of information models for describing various aspects of modeled assets. The service is either demanded by the service requester or offered by the service Provider. Therefore, there must be two different SM templates.

The request contains the specification of required product or process requirements as well as the description of the required provision and may be part of the product AAS. The description of the provision, relevant for potential manufacturers, may include necessary certifications and a non-disclosure agreement if required. The different categories can be organized in Submodel Collections (SMCs) and can be described by properties. For instance, an SMC TenderCritera may represent all the information needed to find a suitable manufacturer based on, e.g., the required quantities, price specifications, CO₂ specifications, and delivery conditions. All SMCs and their properties are extended by a preset qualifier, indicating that the information is a requirement. Each property can also be described by a semantic ID. In case of a service, which is used between companies, standardized data elements are required. Therefore, repositories such as IEC Common Data Dictionary^[8] or ECLASS^[9] are recommended to ensure common semantics.

A service provider offers services that can be matched to required services. In this case, the SM service could be part of the factory or company AAS, based on a similar description as the requested service. The description is further extended by the capabilities which can provide the assured service to link the service and the corresponding capabilities.

5.1 Web Services and service-oriented architectures

Web Services are software systems that allow humans or machines to consume functionalities via a network. Interface descriptions in machine-readable formats are required for machine-to-machine interoperation [26].

A Service-Oriented Architecture (SOA) is an architectural paradigm that encourages using multiple services to structure software functionality which may be distributed and maintained by different owners [27]. Services are typically considered self-contained functions that may be composed of other services. They logically represent a recurring activity with a clearly defined input and output so that consumers of the service may interact with it in the sense of a “black box”—i.e., without knowing a service’s internal details [28].

The understanding of the term service as used in information technology differs significantly from the understanding expressed in this publication. While services in IT are encapsulated functionalities and may thus be compared to skills, services in the context of the CSS model act as containers bundling capabilities with commercial aspects in order to be offered and requested on a marketplace (see Section 3.2).

Transferring the SOA service concept from information technology to automation was one of the earliest approaches to obtaining encapsulated functions with clearly defined interfaces in automation [29]. Thus, services can be seen as an early precursor of skills according to the CSS reference model.

5.2 Module Type Package

A description of modular process units is provided with the Module Type Package (MTP). The MTP defines and describes data of the structure, information interfaces, process sequences, and functions (MTP services) of modules from automation technology. The combination and aggregation of components enables modular process units, known as Process Equipment Assembly (PEA). A PEA is developed once and contains the physical design of a process step to be implemented as well as the information technology interface to higher-level systems [30].

An MTP is a module description to allow module integration into a modular process plant. Modules provide MTP services with a predefined behavior (procedure) and a standardized interface that are offered externally with their description as MTP.

MTP concepts can be related to the aforementioned capabilities and skills, see Section 3.3. A description of an MTP service provides a specification of a function without invocation information and can thus be considered as a capability. A skill being an executable implementation may be compared to the implemented MTP service including procedures. Additional skill information, e.g., about the invocation interface and parameters are also included in an MTP—however, the State Machine is not explicitly modeled in an MTP.

Thereby, a PEA is the described resource of the aligned PPR approach at the CSS model, which provides skills. In contrast to the service of the CSS model, the complete MTP description is at capability and skill level and does not consider business, compliance, or commercial aspects.

Another relation to the concept of capability and module descriptions with its functions is given by the term “super-service” in [31]. A super-service is described as a conceptual planning artifact that contains the union of all process engineering services and procedures. The objective is to break down module boundaries and describe them in a manner comparable to capabilities, i.e., independent of modules or resources.