Organizing reuse for production systems engineering with capabilities and skills

2.1 Knowledge representation in PSE

PSE consists of several life-cycle phases, from basic and detailed planning to commissioning and operation. Additionally, PSE takes place in a multidisciplinary environment, where engineers from various domains, such as mechanical or electrical engineering, maintain different views on the production system [12]. The PPR approach [3] unifies three main aspects of PSE. The model represents input and output p roducts, production p rocesses required to transform input into output products, and production r esources that automate the production processes. The Formal Process Description (FPD), defined in the VDI 3682 [13], provides a visual and formal model to describe these aspects.

Pfrommer et al. [14] introduced skills as a complementary element to PPR. They defined skills as semantic, vendor-independent representations of process functionality required by a product and provided by a resource. Keddis et al. [15] distinguished required capabilities, defined in production step plans, from provided capabilities, implemented by resources. While a recent literature survey found early literature on C&S to use the concepts interchangeably [4], later works distinguished more clearly between C&S. Nevertheless, both concepts aim to abstract and decouple processes and resources for more flexible production.

Several works proposed models for C&S, including their relations to PPR, and formal machine-readable speci-fication, e.g., via ontologies [5, 16, 17]. Järvenpää et al. [7] investigated how formally described resource capabilities can be automatically matched to product requirements. Furthermore, recent research studied the automated derivation and execution of skills, e.g., via OPC UA [8, 18].

This paper builds on the PPR and C&S concepts, in particular, on the definitions and the model of C&S described in [19]. In their model, capabilities are implementation-independent specifications of functions in industrial production. While production resources can provide such capabilities, production processes can require them, encapsulating the product requirements. On the other hand, skills are executable implementations of capabilities on a resource (cf. Figure 1), where several skills might realize a capability.

Figure 1:

PPR model for a screwing process in VDI 3682 [13] notation without (dashed connection executes) and with C&Ss.

2.2 Knowledge reuse in PSE

Jazdi et al. [10] investigated how PSE efficiency can be increased by identifying reusable engineering artifacts and systematically using them extensively in upcoming engineering projects. Their work is based on the VDI 3695 procedure model for project activities [11] and the two-life-cycle model from Software Product Line Engineering (SPLE) [9].

The VDI 3695 [11] for optimizing engineering organizations describes a two-phase procedure model. The model consists of project-independent activities (PIAs) to identify and provide reusable artifacts and project-dependent activities (PDAs) that use these artifacts (cf. Figure 2). The PIAs for domain engineering consist of (i) an analysis of the domain and artifacts suited for reuse, (ii) the planning of a reference architecture and reusable artifacts, and (iii) the realization and testing of reusable artifacts. Jazdi et al. [10] translate these activities into detailed tasks for PSE. The VDI 3695 specifies five target states of reuse maturity in PSE that range from isolated reuse by single engineers to reuse with reference models and standards. The PDAs for application engineering consist of (i) the acquisition and requirements engineering of new PSE projects, (ii) the planning and realization of a production system or production services using the reference architecture and reusable artifacts, and (iii) commissioning of the realized system and services. Ideally, requirements, acquired knowledge, and artifacts from the individual projects are inputs to the PIAs (cf. Figure 2, dashed arrow).

Figure 2:

The Capability and Skill Reuse (CSR) framework for PPR models and artifacts, based on the VDI 3695 guideline [11].

Similarly, SPLE investigates the reuse, flexibility, and configuration of software portfolios and their engineering [20]. Therefore, van der Linden et al. [9] identified the four fundamental principles of variability management, business-centric and architecture-centric engineering, and the two-life-cycle approach. The two-life-cycle approach describes domain engineering and application engineering, similar to PIAs and PDAs of the VDI 3695 [11]. The reusable artifacts are stored in a common artifact repository (cf. Figure 2) for use in the PDAs. SPLE also investigated models and methods to represent and manage variability in artifacts and their configuration. Two SPLE approaches to model and configure variability, also mentioned by Jazdi et al. [10], are feature modeling and decision modeling [20].

A recent survey [4] elicited expected requirements towards C&S and benefits of C&S in PSE. The survey reported reusability both as a requirement to enable C&S-based PSE and as a benefit as C&Ss foster reuse of knowledge. However, to the best of our knowledge, very little work on the systematic reuse of C&S in PSE has been reported. Therefore, this paper investigates the reuse in and for C&S-based PSE, in particular, the elicitation and abstraction of C&Ss from engineering artifacts, such as PPR models.

2.3 Illustrative use case

To illustrate the CSR framework, this section reports on a use case abstracted from real-world applications. These applications stem from engineering organizations of high-performance automation for car part manufacturing in Germany and Austria [21]. In particular, we consider joining processes of large car parts, such as doors, to car bodies.

In the use case, we consider a system integrator which, for particular customers, plans and engineers work line production systems that manufacture a portfolio of car parts automated in typical car production plants. The plant operators should be able to offer their production services in a marketplace in the future, aiming at PaaS. Therefore, the system integrator wants to reuse existing well-described engineering artifacts, such as robot cell models, for various company-wide projects. To this end, the solution candidates should be decoupled from specific product and production process requirements of previous projects.

Figure 1 shows a section of a PPR model in VDI 3682 notation [13] with the products (represented as circles in a blue frame), e.g., the door, one process step (depicted as a rectangle in a red frame), i.e., the door screwing process, and a resource (shown as a rounded rectangle in a yellow frame), i.e., the screw-driving robot. A corresponding engineering artifact can be, e.g., the model in the Product-Process-Resource Domain-Specific Language (PPR–DSL) [22].

In the use case, the door is mounted to a car body with screws. The screws have different types depending on the doors, which have different dimensions. The processes have technical and economic requirements, such as the required torque or the production rate. Furthermore, the processes need to consider the characteristics of the products, i.e., the torque and dimension. The screw-driving robot has several characteristics, such as torque or rate range, required for correct process execution. While some of these characteristics are similar in the assembly line, others are variants of originating processes and resources.

Traditional PSE and reuse [10, 23] often maintain a quite resource-centered perspective, where processes are modeled only as part of the resource and its behavior (cf. dashed red arrow in Figure 1).

In C&S-based PSE, the process requirements are modeled as required capabilities, e.g., a screwing capability (cf. Figure 1) or even more abstract a joining capability. However, some characteristics, such as electric or pneumatic screwing, might be irrelevant to the production processes. Resources, such as screw-driving robots, on the other hand, provide the means to execute a functionality, in this case, to join two parts, respectively, screw them together. In C&S-based PSE, the functionalities of resources are modeled as provided capabilities and implemented as, e.g., skills [19]. This way, the required and provided capabilities can be matched, e.g., in the engineering phase or on a marketplace.

3.1 Requirements towards capability- and skill-based engineering and reuse

Froschauer et al. [4] elicited requirements towards C&Ss in a literature survey. We categorize these requirements to identify which of them are particularly relevant in what reuse activity of the CSR framework. In Table 1, we introduce four categories and assign each requirement to one of them.^[1] In the next section, we use this categorization to highlight the relevance of the particular requirements in the activities of the CSR framework.

The first category concerns the description of capabilities to support their interpretation by machines and humans, exchange, and ideally openness [24]. Therefore, capability descriptions shall be formal and vendor-neutral.

To facilitate the selection of C&Ss, i.e., the appropriate selection of C&Ss for a purpose, during the PSE life-cycle, they shall be (i) identifiable ^[2] for reliable distinction (ii) classifiable to categorize C&Ss according to well-known PSE semantics, e.g., the DIN 8580 [25], (iii) matchable to automatically find suitable production resources for production requirements, and (iv) discoverable to find production services in a distributed environment, e.g., on a marketplace.

Skills encapsulate the functionality of a production resource implementing a particular capability. Therefore, they need to fulfill requirements at implementation and at run time. During the implementation time of a skill, engineers need to consider the following requirements with the aim of flexibility and usage variability. A skill should be (i) configurable respectively adaptable, to choose from their internal variations [9], (ii) modular to combine them to higher-level functionality, and (iii) extensible to adapt them for future purposes.

At production system run time, skills shall be (i) executable to run directly on a resource, (ii) stateful respectively deterministic for reproducibility and to know their current state, (iii) scalable to deploy them to many similar resources and handle growing production requests, and (iv) provide a communication interface to control their behavior.

3.2 Activities for capability- and skill-based reuse of PPR artifacts

This section introduces the Capability and Skill Reuse (CSR) framework for reuse in PSE with C&Ss. Figure 2 shows the PIAs and PDAs of the VDI 3695 procedure model [11]. This paper focuses on the activities depicted in blue, i.e., the core activities of domain and application engineering [9] without considering acquisition. Between the PIAs and PDAs, Figure 2 further shows the common artifact repository to store reusable artifacts. Furthermore, the figure shows the iterative character of the framework as backflow from the PDAs to the PIAs. As a novelty, Figure 2 highlights the activities for engineering with C&Ss based on reusable PPR artifacts (areas in grey).

The first four activities of the CSR framework concern the PIAs of the VDI 3695 procedure model for domain engineering.

PIA.1 – Model and artifact analysis. This activity maps to the analysis PIA of the VDI 3695.

In this activity, engineers responsible for company-wide reuse analyze the domain and its requirements. The result is a reference model for the domain, such as the system architecture for a work line in car manufacturing. This reference model can specify common requirements but also technical solution elements for the PDAs. Furthermore, the engineers analyze existing artifacts, like PPR models in PPR–DSL [22], from previous projects to assess their reuse potential. The analysis aims to find and document artifacts that have been used in several projects and that engineers can adapt for more generic use. In the context of the use case (cf. Section 2.3), such artifacts could be PPR models of screwing processes with parameters in a similar range, like the torque or workpiece dimensions.

In the traditional approach, the engineers often do not differentiate between the products, processes, and resources in the analysis. For instance, engineers analyzed and collected resources for reuse in future projects at one company from the use case but mixed them with concrete products rather than, e.g., more generic dimensions. While such an analysis is efficient for local engineering, it makes reuse beyond local environments riskier and less efficient.

In the CSR framework, the reuse engineers pursue two goals to find and document reuse candidates. First, they identify processes in the artifacts independent of the products and resources they use, e.g., the screwing process. Based on that, more generic process characteristics can be derived in the next activity. The overall goal is to identify process candidates that seem relevant for required capability descriptions (cf. Figure 1). Second, the engineers identify resources in the artifacts that seem promising for reuse, e.g., the screw-driving robot. For instance, one company in our use case maintains a database of regularly used resources with particular characteristics, such as power consumption. In another company, a domain analysis showed that the types of screw-driving robots could be reduced by grouping them by their functionality [21]. The overall goal is to identify functionality candidates that seem relevant as input to describe the functionalities of these resources as provided capabilities and implement them as skills.

The result of the analysis (cf. Figure 2 yellow diamond 1) is a reference model for the domain, e.g., for joining work lines, and a documentation of (partial) PPR artifacts identified as processes or resources. This reference model and the documentation are the inputs for activity PIA.2.

PIA.2 – Process and resource planning. This activity maps to the planning PIA of the VDI 3695.

In this activity, the engineers define the utilization of the assets from the analyzed PPR artifacts, e.g., usage as reference assets or parameterized assets in future projects. Therefore, the engineers need to generalize and categorize the assets and plan their parameterization, i.e., assess their variability and configuration options.

In the use case, we consider the PPR model of the door screwing process. First, the PPR artifacts might need to be split to single out the section with the screwing process. Then, the engineers need to generalize the products as the products are most likely different in other projects. For instance, the type of screw used, e.g., with a specific inventory number, needs to be generalized to its relevant properties, e.g., slotted or Phillips head. Similarly, the door might be generalized to a workpiece with particular dimensions. Figure 1 illustrates this generalization of products as dashed outlines in activity PIA.2.

In the traditional approach, process and resource assets are often mixed or merged in the artifacts. For instance, the screw-driving robot might be modeled to directly manipulate the products, only implicitly representing a screwing process. Thus, artifacts resulting from this planning activity are less modular and decoupled and, hence, represent the requiring and provisioning side of production insufficiently.

In the CSR approach, the engineers decide which (parts of the) artifacts concern process capabilities, i.e., required, or resource capabilities, i.e., provided. If an artifact mixes process requirements and resource functionality, the engineers plan how to separate the process from the resource descriptions. In the use case, the PPR artifact requires splitting or remodeling to separate the process and the resource, e.g., into different artifacts that can then be imported as libraries. The engineers must then categorize and group the processes and resources by similar requirements and functionality. This task can follow domain-specific guidelines, such as the DIN 8580^[3] for manufacturing methods. For instance, screwing and welding processes can be part of a higher-level group of joining processes. Similarly, catalogs, such as company-specific taxonomies or databases or the EClass standard,^[4] can help to categorize resources.

The result of the planning activity (cf. Figure 2 yellow diamond 2) are separated and categorized processes (with generalized products) and resources. These resulting artifacts are the input for activity PIA.3.

PIA.3 – Capability and skill elicitation and modelling. This activity maps to the PIAs planning and realization of the VDI 3695.

In this activity, domain engineers realize the reusable assets as PPR artifacts. For instance, they create templates from particular assets that can be parameterized and reused in different PSE projects.

In the traditional approach, such PPR template designs often consist of resources only that realize the functionality for the production of a product. Therefore, the resulting artifacts concern product and process requirements as well as the functionality of particular resources like robots. While this might make the configuration of such templates easier, it makes, e.g., the exchange of resources solely based on the required functionality harder [7].

In the CSR framework, the domain engineers elicit and model processes and their requirements as process capabilities. In several cases, the engineers might want to aggregate the found process requirements for an abstraction to higher-level groups, e.g., serving a range of parameter values [26]. Similarly, the engineers model the resource functionality as capabilities and potentially implement them as skills. Modeling the C&Ss requires using appropriate models or languages, such as ontologies [5, 17] or domain-specific languages [22]. For the skill implementations, engineers can utilize technologies, such as OPC UA [8, 18] or PackML.^[5]

In the use case, we would model the screwing process as required capability, e.g., in a process ontology [5], with the required rate, torque, and screw type as configurable parameters. The screw-driving robot would be modeled as provided capability with its rate and torque range, i.e., the minimal and maximal values, e.g., 100 Nm to 200 Nm. Furthermore, the concrete functionality of the screw-driving robot would be implemented as a skill, e.g., with specific control software, that implements the provided capability.

The capabilities shall fulfill the capability description and C&S selection requirements (cf. Table 1) that are then relevant in the PDAs. Similarly, the skill implementations shall fulfill the implementation time requirements. While this is an extra effort in this step, fulfilling these requirements pays off in the project-dependent realization.

The result of the realization is modeled as C&Ss that are deployed into the common artifact repository using an agreed-on structure. Figure 2 illustrates these artifacts as processes with generalized products with their corresponding capabilities in blue and as resources with their corresponding capabilities (and skills) in magenta.

PIA.4 – Capability and skill validation. This activity maps to the testing PIA of the VDI 3695.

After modeling the capabilities and implementing the skills, the provided C&Ss must be tested and validated to qualify them for the production systems. This task should already be executed on physical resources, such as a testbed, indicated by the cog wheel in the resources.

Therefore, skills must fulfill the run time requirements. This means, they need to be executable, stateful and deterministic, and scalable [4]. Furthermore, they need to have a communication interface to control their behavior.

The artifacts resulting from the PIAs are stored in the common artifact repository for use in the PDAs.

The activities in the lower part of Figure 2 concern the project-dependent activity (PDA) of the VDI 3695 procedure model.

PDA.1 – Product portfolio analysis. This activity maps to the planning PDA of the VDI 3695 and is similar in the traditional approach and the CSR framework.

In this activity, application engineers analyze the product portfolio that the production system should manufacture. Therefore, they investigate its production requirements, such as quality concerns or the planned order quantity, based on input from the acquisition activity. Figure 2 shows a product portfolio as small product icons. For instance, in the use case, a range of different doors types shall be mounted to similar types of car bodies.

In the use case, the engineers analyze the doors and car bodies with their commonalities and variability. From this analysis, they can derive which products are similar enough to manufacture them on one production system, e.g., door type A and B with similar dimensions in a robot cell.

The result of this analysis shall be a bill of materials for the products with corresponding variability and configuration models [9]. In Figure 2 the red label 1 at the lower part represents the results that are input to PDA.2.

PDA.2 – Capability planning. This activity maps to the planning and realization PDAs of the VDI 3695.

In this activity, application engineers receive the production system requirements and the product portfolio analysis from PDA.1. From this data and the reference architecture from PIA.1, they derive a suitable production system architecture. Second, the application engineers define the requirements and the functionality for the products' single production steps. Therefore, they take up the analyzed product portfolio, investigate ways to assemble these products, and derive properties for the production steps. In the use case, the engineers decide, e.g., to mount the doors to the car body with screws of a certain type using a screwing process with a specific torque and rate.

In the traditional approach, the engineers often define a bill of processes and tie them to reusable resource templates from the common artifact repository. However, without adequate abstraction, this limits the exchange and reconfiguration of resources and impedes the search for adequate production services, e.g., in a production network.

In the CSR framework, the engineers take up the product portfolio description to plan the capabilities required to produce the products. In the use case, the engineers define that a door is screwed to the car body, e.g., with a Phillips and 150 Nm torque. Based on these requirements, the engineers search in the common artifact repository for process capabilities that fit their requirements, i.e., a screwing capability with configuration parameters for the screw head and the torque. Therefore, the capabilities have to fulfill the requirement categories capability description and C&S selection (cf. Table 1) to find suitable reusable capabilities in the common artifact repository.

In the second step, the engineers configure the retrieved capabilities with the known values of the products from the product portfolio. In the use case, this means configuring a screwing capability with, e.g., the required torque of 150 Nm ±5 Nm, and the required Phillips screw head. Modeling classes of parameter ranges can be helpful to support better matching to provided C&Ss in the next step.

Figure 2 illustrates the resulting configured capability as a PPR model with concrete products and a configured process capability in blue. These configured capabilities (cf. red diamond 2 in Figure 2) are then inputs to PDA.3.

PDA.3 – Capability and skill matching. This activity maps to the planning and realization PDAs of the VDI 3695.

In this activity, the product requirements, expressed through process descriptions, must be matched and bound to concrete production resources. The resources must then be configured to execute the processes correctly.

In the traditional approach, the engineers manually match the process requirements to resources from the common artifact repository. This step is mainly based on implicit knowledge by a single key engineer. A major limitation of this approach is the need for experts with high domain knowledge suitable to conduct this task. Thus, this task is challenging, error-prone, hard to teach, and limited by the availability of these key experts.

In the CSR framework application engineers use computational support to match the partially configured process capabilities with resource capabilities. Therefore, the tooling environment shall enable to match C&S descriptions. The selection requires C&Ss to be (cf. Table 1) identifiable to find unique ones, classifiable to search for them systematically, discoverable to retrieve them from the common artifact repository, and matchable to assign them to the required process capabilities. Ontology reasoning is a promising approach to match C&Ss [7]. In the use case, we would set up, e.g., an ontology query that searches for provided capabilities with a torque range that includes the configured torque of 150 Nm. The result would be the previously described provided capability with a torque range from 100 Nm to 200 Nm. Similarly, other provide capabilities with torque ranges around 150 Nm could be returned. Furthermore, the engineers can now select from different skills that implement these capabilities, e.g., based on robots that they regularly use in their projects.

The results of this step are matched required and provided capabilities (cf. red label 3 Figure 2) that are input to PDA.4. Figure 2 depicts the icon of the processes with concrete products and their required capabilities that are matched to one or more capabilities.

PDA.4 – Capability and skill configuration. This activity maps to the planning and realization PDAs of the VDI 3695.

In the traditional approach, one of two cases applies. If the artifacts are tightly coupled, they require adaption to the particular project. If the artifacts are loosely coupled, they require adaption to each other and the project. This specific adaptation makes it hard to exchange production resources in case they do not fit as expected.

In the CSR framework, the engineers receive C&Ss from activity PDA.3 that match each other but are only partially configured. For instance, the torque in the screwing capability has been set to a particular value, in the use case 150 Nm. However, the engineer might need to set further C&S parameters to concrete values for the production. Furthermore, the engineers need to bind the particular capability to the finally selected and configured skill.

In Figure 2 the bound and configured capability and skill for a process are shown in a PPR model with connected C&Ss. The results of this step (cf. red label 4 Figure 2) are input to PDA.5.

PDA.5 – Skill execution. This activity maps to the commissioning PDA of the VDI 3695.

During commissioning, the designed production system runs for the first time with different resource configurations for various products from the product portfolio.

In the traditional approach, the engineers configured the resources based on product and process knowledge which is often diluted over the engineering process. While they might have used reusable artifacts for the configuration, we argue that it is harder to reconfigure resources in case they do not prove as efficient or suitable as expected.

In the CSR approach, the finally configured skills are executed for the first time on the production system with the particular configuration. This activity shall ensure, beyond other things, that the C&Ss are configured correctly. To run on the production system, skills must fulfill the same requirements as in PIA.3, where the skills are tested and validated. Concretely, they have to fulfill the run time requirements of Table 1. Issues during the execution of the skills shall be fed back directly to the PIAs, e.g., validation and testing.

Experiences and assets from the PDAs are fed back to the PIAs to improve the reuse lifecycle.

As a summary, the CSR framework defines activities that motivate which tasks should be taken to (i) elicit C&Ss from previous projects, (ii) model and validate them as reusable artifacts in a common artifact repository, and (iii) use and configure them in particular engineering projects. In the next section, we discuss the CSR framework in context to the related work and research question.