Towards asset administration shell-based continuous engineering in process industries

2.1 Automation engineering

Automation engineering usually follows a workflow as described in [1, 2], starting from a Front End Engineering and Design (FEED) phase that defines what should be constructed, through basic and detail engineering phases that define the automation system and automation software of the plant. Engineering usually ends with the commissioning phase, followed by the operation and maintenance phase and – at the end of the plant lifecycle – with its deconstruction.

For each of the phases, new methods are investigated, which decrease the engineering effort for every part, since engineering is quite expensive. For the FEED phase, for example, the Capital Facilities Information HandOver (CFIHOS) standard is developed by Oil and Gas (O&G) industry [3]. CFIHOS is meant as a data exchange format between the different engineering phases. During FEED, it is defined how the process should work, later the same document is enhanced by the technical implementation of the specific process function and/or its electrification. Further information can be added during later engineering phases.

In order to describe a P&ID of a process plant in a computer interpretable manner, the DEXPI standard, based on ISO 15926, is developed. The major driver for this standard is the German DECHEMA (ProcessNet), supported by several suppliers, plant owners and CAD tool vendors. Additionally, ProcessNet is cooperating with Interessengemeinschaft Automatisierungstechnik der Prozessindustrie e.V. (NAMUR), VDMA, VDI, and other large consortia on that standard. The idea is to generate the DEXPI-file for a P&ID during FEED and then reuse it in detail engineering for, e.g., generating operator displays (sometimes also referred to as Human Machine Interface (HMI)) [4, 5] or control code [6]. Besides the DEXPI standard, there is the NORSOK I-005 standard (also known as IEC PAS 63131) defining System Control Diagrams (SCDs), that roughly correspond to P&IDs incl. the control logic for several PCE-Requests. Machine-readable exchange of SCDs is possible using an Automation Markup Language (AutomationML) model [7].

A special case for the recent developments of the plant engineering is the modularization of process plants. Using this, the complete plant concept changes. Instead of constructing a single big plant, the plant is assembled from process modules, each defining a specific purpose. The general concept is described in [8]. The entire concept bases on the standardization of the process module interfaces, the MTP. Furthermore, the modelling techniques used for MTP are described in [9, 10]. The following paragraph gives an overview about the related standards and pilots/demonstrators.

2.2 Modular automation and pilot applications

The MTP standard is under development since 2013. The first parts of the national standard VDI/VDE/NAMUR 2658 are released, describing the general concepts for the automation interface of a PEA [11], as well as the description of an HMI [12] and the interfaces of PEA tags [13]. Draft parts for alarm management [14, 15] and service-based process control [16] are available, as well. Those guidelines are heavily used in pilot projects [17], driven by pharmaceutical industries and are now under international standardization within the IEC; the IEC 63280 new work item proposal has been accepted. In addition to that, VDI 2776 [18] is describing the concepts for the process design when constructing a modular production plant.

Discrete industry is working on a standard for the integration of machines into a production process. The underlying concept is called Packaging Machine Language (PackML) [19] originating from packaging industry, further formalized in The Organization for Machine Automation and Control (OMAC) [20] industry standard, the corresponding OPC UA companion specification [21], and the ISA 88 TR [19]. A compassion and alignment of MTP and PackML can be found in [22].

A concept called state-based control, as described in [23], based on ISA 88 [24] and ISA 106, is often used to provide advanced operation concepts for world-scale plants and a higher level of automation. Besides that, an abstraction layer is put on top of the automation system in order to ease integration and provide a larger degree of automation.

New concepts and new architectures, like discussed in Open Process Automation Forum (OPAF) at present and put into OPAS [25], also go into a modular direction. OPAF, as well, shows that there is a need for a more modular, type-based engineering, based on Distributed Control Nodes (DCNs), which can run on different target systems and be distributed throughout the plant.

Especially the MTP standard is of importance when it comes to modular automation systems. The maturity level is high enough to use it for first pilot applications. The community has developed several pilot application together with end customers, as e.g., described in [17]. Besides this, the concept is enhanced to be usable for conventional plants, as well. The concept of the Function Modules enables the usage of MTP for world-scale plants. Function Modules enable the usage of a single controller for several modules, as well as for the parameterization of modules on instance level as described in [26].

2.3 Asset administration shell

AAS is one of the key concepts originally developed by the “Plattform Industrie 4.0”, a German consortium including industrial associations, academic research facilities and industry. AAS is currently the subject of international standardisation as IEC 63278.

The core vision of AAS is to implement a digital representation (sometimes referred to as Industrial Digital Twin) of physical or non-physical assets to enable interoperability (1) across the life cycle phases of an asset and (2) across organizational boundaries.

Towards the first aim, AAS is defined as a technology neutral Unified Modelling Language (UML) model which has defined mappings to multiple file-based serializations (so-called type 1 AAS), e.g., eXtensible Markup Language (XML), JavaScript Object Notation (JSON), AutomationML or Resource Description Framework (RDF). Moving along the lifecycle of an asset, e.g., into its operational phase, an interactive Application Programming Interface (API) might be preferable for interaction with asset information. This is realized by so-called reactive (type 2) AAS, e.g., by means of a RESTful API providing JSON representation of the information model and its parts. A mapping to OPC Unified Architecture (OPC UA) is also available via a companion specification I4AAS.^[1] A proactive (type 3) AASs which are conceptually similar to agent-based systems are currently subject to research, e.g. [27], or [28], and currently have less relevance in industrial pilots and demonstrators. A seamless transition between AAS types is possible based on the demands of a particular digitalization use-case. For example, it is natural to use file-based type 1 AAS during the engineering phases of asset’s life cycle and switch to type 2 or even type 3 AAS during start up and operation phases.

Towards the second aim, AAS can be seamlessly integrated with other Industry 4.0 technologies and standards like Identification Link [29] and semantic dictionaries based on IEC 61360 like IEC Common Data Dictionary (CDD)^[2] and ECLASS.^[3] Identification link can be used to identify the asset of interest along product’s life cycle from production to disposal. Semantic dictionaries allow re-using the existing standardized attributes to describe asset’s properties, e.g., the weight of a sensor.

Both types 1 and 2 require certain infrastructure to discover, consume and exchange AAS. While no specific means for type 1 AAS are defined, type 2 services are being specified including so-called AAS registries to discover AAS and contained information based on the asset ID, e.g., its identification link. There are a number of open source Software Development Kits (SDKs) implementing AAS and related infrastructural elements, most notably Eclipse BaSyx.^[4] An overview of the available SDKs can be found in [30].

In a nutshell, the metamodel of a AAS defines AAS to include an asset description including a possibility to list multiple asset identifiers. An arbitrary number of AAS for an asset may exist, e.g., owned by multiple organizations along the asset’s life cycle. AAS aggregates submodels which are information containers describing different aspects of the asset, e.g., its technical specification or its documentation. Similarly to AAS, submodels have globally unique IDs and are the minimal deployment unit for type 2 AASs, i.e., an AAS may have multiple submodels each of which can be hosted on different physical hosts or even across organization boundaries. Submodels group actual properties of the asset offering a rather limited set of modeling possibilities including, but not limited to, ordered an unordered collections, properties to supply values of primitive data types, reference to other AASs and their parts as well as executable operations.

It is obvious, that relying on well-defined semantics of parts of the AAS, e.g., semantics of single properties within a submodel, is not sufficient to ensure interoperability in every Industry 4.0 use-case. Therefore, in recent years the work of Industry 4.0 community is focusing on a definition of standardized submodel templates for well-defined use-cases. With the gradual maturity and adoption of AAS within research projects and industrial pilots, the governance of the development of AAS specification and submodel templates is being transferred to the Industrial Digital Twin Association (IDTA),^[5] a non-profit organization founded in 2021. Currently, there are more than 80, mostly industrial, members covering a variety of industrial verticals as well as geographic markets. There are about 30 standardized submodel templates which are either published, in review or under active development. We will focus on submodels which are related to engineering in Section 5.

2.4 Asset administration shell applications in engineering

Aiming to cover the whole life cycle of any asset, applications in the engineering process and using it as a bridge towards operations guide the use-cases around AAS. The focus of this work is on engineering-related use-cases, therefore we exclude a vast number of work around AAS like re-configurable production, e.g. [31], or [32], use-cases related to edge computing [33], or usage of AAS for hand-over and orchestration of Functional Mockup Unit (FMU)-based simulations [34, 35].

A vision of the whole life cycle applicability of the AAS for process plants has been already sketched in [36] in 2017. In this work, a number of use-cases have been identified along with the plant life cycle like device selection, procurement, plan commissioning, as built documentation and operations. Some of those use-cases are covered by the standardized submodels which we are reviewing later in this paper.

Multiple efforts around capability-based (or skill-based) engineering for lot-size-one production found place in the Industry 4.0 community, e.g., around BaSys^[6] research projects [37], [38], [39]. This work leads to a consolidated understanding of equipment capability description [40] and more recent implementation approaches, e.g., [41, 42]. The rough idea behind capability-based engineering is the ability to automatically assess, whether a product can be produced by the existing production equipment and generate a production plan if possible. Methodological backbone for capability-based planning and reconfiguration can be ontologies as outlined in [43].

To create an AAS from existing information sources, there are works on using AutomationML [44] as integration format to integrate information during the engineering phases to export it as an AAS. Alternatively, model transformation can be used to create mappings from proprietary information sources [45], [46], [47].

Recent applications of AAS in different engineering phases are manifold and cannot be reviewed here completely. Some relevant examples are the usage of AAS in Product Lifecycle Management (PLM) [48], representing PLC within AAS according to IEC 61131-3 [49] or IEC 61499 [50], to its use for planning and scheduling purposes using Artificial Intelligence (AI) [51]. Furthermore, there are works adapting value-statement-based semantics, e.g., matching requirements and assurances on different ECLASS or CDD properties, for multiple use-cases including service and asset discovery [52], [53], [54].

Recently, the working group 1.4 “Asset Administration Shell” of NAMUR published two position papers on the role of AAS in the process industry with a great focus on the engineering process. Unfortunately, both papers are currently available in German only, therefore we provide a short summary below. The first position paper [55] describes four different kinds of the AAS involved in the plant engineering:

1. Plant Structure AAS: describes the logical and physical structure of the plant. It connects planned functionality, so-called roles, which can be fulfilled by different automation devices.

2. Role AAS: This AAS is a container for the requirements towards a device. Those requirements can come from multiple disciplines including process (e.g., measured medium) and mechanical (e.g., pipe diameter). Requirements towards the role restrict the possible device types which can fulfill the role.

3. Device Type AAS: Device type is an abstract catalog item provided by device supplier. Typically, it contains a set of assurances towards predefined properties, e.g., assured measurement precision. Ideally, these properties can be matched with the requirements within the Role AAS to deduce a set of compatible devices for each role.

4. Device Instance AAS: This AAS represents an individual device (e.g., a temperature transmitter with a dedicated serial number). Instance AAS typically contains either a link or a copy of the content of the Device Type AAS, e.g., its assurances and documentations. Additionally, it can contain some instance-specific information like calibration certificates, maintenance reports, etc. During its lifecycle Device Instance AAS is temporally referencing the Role AAS it is fulfilling. This reference can be changed during the lifecycle, e.g., when the device instance is removed from the plant for the maintenance.

The second position paper [56] reflects on two use-cases around the usage of the AAS. The first use-case called “Engineering” describes a vision of integrated engineering which uses AAS as an interoperable technical backbone compared to file-based or vendor-specific exchange platforms which are used now. The second use-case called “Operations” describes an automated sensor device exchange (the new device is assumed to have a different type AAS as the original one) based on automatic matching of Role AAS requirements. We describe opportunities related to both use-cases in more detail in Section 4.

3.1 Step 0: requirements exchange

In this step the plant owner/operator defines requirements of a plant, i.e., a subsystem specification, and communicates them to the integrator. Typically, this specification includes a rough plant structure (e.g., functional and location structure) of the to-be plant or plant segment. Requirements exchange step is the main difference between the Z-value-chain (Figure 2) originating from Plattform Industrie 4.0 and the Σ-value-chain (Figure 3) originating from this work. We suppose that the absence of requirement exchange in the original leading picture origins in discrete manufacturing roots of Industry 4.0 where integrators may create composite systems based on market research and not on the requirements of an individual customer/plant operator as it is the case for process automation and especially in process and the oil and gas industry. This theory is supported by recent publications, e.g., [56], filling this gap.

Having formalized and machine-readable requirements opens a way towards semi-automated verification of the system and allows a clear traceability of inter-dependencies between system parts. Requirements can be partially formalized using existing O&G standards, e.g., the rough plant structure can be expressed using an ISA-95/ISA-88 hierarchy (cf. Table 1). The information exchanged between the parties is split into multiple logical steps which are discussed below. Note that some steps are focusing on pure information flow and mechanisms to enable it, e.g., exchanging requirements (Step 0) or device data (Step 1). Other steps like engineering (Step 2) are focused on value creation within Industry 4.0 domain and hence are creating information to be exchanged in further steps, e.g., lifetime services (Step 6).

3.2 Step 1: asset type information exchange

To use asset type information during its value creation process, the integrator needs to aggregate (or even maintain an own copy, cf. [55]) catalog information of different components available from several suppliers. The product information includes technical specifications (e.g., height, weight, available certifications) and documentation (e.g., operating instructions) for specific equipment. Standards related to this information exchange steps include VDI 2770 documentation exchange as well as technical information expressed as a set or ECLASS or IEC CDD properties (e.g., weight, height, IP environmental protection class). Furthermore, specification of a field device might include its OPC UA runtime information model represented as an engineering artifact, e.g., supplied as OPC UA Nodeset XML file.

Please note that the order of Step 1 and Step 2 is taken based on original drawings of the Z-value-chain and is subject to discussion.

3.3 Step 2: engineering design with digital twins

In this step the integrator designs a composite system, e.g., a machine, module or skid, based on market or customer requirements. This step includes combination of product information obtained from supplier catalogs and matching them to the requirements. Included activities are detailed modeling of the plant/plant subsystem, sizing of components (e.g., selecting a motor providing sufficient torque for a pumping application), and optionally the simulation of the composite system. Furthermore, automation application design is performed in this step including PLC programming in IEC 61131, design of HMIs, alarm limits etc. Relevant standards to this step include IEC 61131-3 and -10, IEC 61499, Module Type Package, SCD (IEC 63131), DEXPI and AutomationML/Computer Aided Engineering Exchange (CAEX) based representation of P&ID.

3.4 Step 3: commit on design of module/subsystem

In this step the system design is agreed between integrator and operator and operator’s asset lifecycle, and the composite system reaches a new phase in its lifecycle both on operator’s and integrator’s Information Technology (IT) systems, e.g., AAS registries. No standards are known that could support this step. Furthermore, this is mostly a business process based on deliverables produced in (multiple iterations of) Step 1 and Step 2.

3.5 Step 4: ordering and delivery

Based on committed composite system design, the integrator and/or the operator start an interaction with defined product vendors to procure the selected components. From the lifecycle perspective of the designed composite system, it is essential to connect the planning artifacts (e.g., tag names or placeholders) with the identifiers of actual products (e.g., order and serial numbers of sensors and actuators). This connection happens in this step via an automated or (human-) assisted procurement process.

Furthermore, as equipment is instantiated in this step, additional instance-specific information may be provided by the vendor including calibration information for filed devices. In similarity to Step 3 this is mostly a business process, also no standards (except semantic catalogs like ECLASS or commercial systems like CADENAS) are known to support this step.

3.6 Step 5: commissioning

Delivered components are assembled by the integrator to the composite system instance (e.g., a physical skid). This step includes commissioning the components of the system, e.g., wiring and network bootstrapping, device identification (e.g., based on serial number) and downloading engineered parameters (e.g., measurement ranges and alarm limits for a sensor) from Step 2. This step may be spread between supplier and integrator as well as integrator and operator as indicated by two arrows in both value chain diagrams. This involves the construction of the composite system by the integrator (e.g., test and commissioning of the composite module) followed by the integration of the pre-tested module into the lager system of the operator.

We are aware that the actual assembly/commissioning process might happen physically at operator’s site/location, still the separation into module-tests and integration-test seems to be reasonable based on typical system design process.

Related standards originate from OPC UA family (IEC 62541) including discovery mechanisms (OPC UA Global Discovery Server (GDS)) and various companion specifications (e.g., PA-DIM OPC UA) defining actual content of the information model within the devices (e.g., name of parameters). Possibilities to apply those standards can be found in works around Plug-and-Produce, e.g., [58, 59].

3.7 Step 6: lifetime services

Lifetime services span between all three actors. The basic example is condition monitoring of both the skid and components in it during the operational lifecycle phase of the plant. The multi-vendor hierarchical structure of the “complex system” implies tangling wrt. data processing by multiple device vendors. For example, information collected from a skid may include information from sensors of two vendors. Efficient predictive maintenance of the sensors may require splitting and forwarding the sensor-specific information to the respective vendor.

Beyond condition monitoring, lifetime services may include:

1. Updates of components and the composite system, e.g., device replacement (cf. [56]).

2. Adding or changing functionality of deployed assets, e.g., firmware update of field devices.

3. Performance enhancements of existing components, e.g., by proposing an optimal parameter configuration for existing devices.

Related standards include OPC UA to enable connectivity the field devices. Additionally secure information extraction from OT infrastructure may be needed (e.g., NAMUR NOA) as well as further means to ingest and process data in a (hybrid) cloud.

The summary of relevant standards listed for every step within the value chain can be found in Table 1. Next to the examples of the relevant standards the IDs of standardized submodel templates is listed (we will present the standardized submodel definitions in more detail in Section 4).

4.1 Opportunities – horizontal integration along the engineering workflow and the trades

The engineering of a plant can be split up into different phases according to [1]. During these phases different tasks have to be executed that require experts from different trades, using specialized software tools [2]. Already in 2010 Hollender stated that “integration of all tools and data in three dimensions [was] a strong trend” [2, p. 178]. But while the vertical integration (as one of the three dimensions) has made huge progress since then with, e.g., the usage of OPC UA down to the field level, especially in combination with the upcoming Time-Sensitive Networking (TSN) [60] as demonstrated in [61] as well as the upcoming standardization with NAMUR Open Architecture (NOA) [62], the horizontal integration along the engineering workflow still has a lot of improvement potential. The integration between the trades, seen as the third dimension [2], partly overlaps with the horizontal integration, as typically different trades are dominant in different engineering phases.

Using CAEX [63] as part of AutomationML [10], the syntax of engineering data can be standardized, forming a basis for a file-based data exchange between different engineering tools and thus engineering phases. Approaches to standardize on the semantics as well, are made with ECLASS. Further standard data formats like COLLAborative Design Activity (COLLADA) for 3D-data, MTP for modules or DEXPI for P&ID diagrams ease the data exchange of at least some of the engineering artifacts. Using an AAS-framework, these artifacts can now be structured, versioned and exchanged in a more automatic way than sending files via emails.

To enable this automatic exchange, the different engineering tools must be able to import and export already existing standardized file formats, e.g., like Autocad or Engineering Base Tool (Ebase) are supporting DEXPI.^[7] In addition of supporting these standards, an integration of the AAS-framework into the engineering tools would be beneficial. For this, a standard interface, e.g., using Representational State Transfer (REST) as a technology, would be required to be defined between the AAS-framework and the different tools. Following use-cases show possible benefits of such a multi-standard and multi-lifecycle-phase integration:

1. Uniform engineering information retrieval: Beyond the retrieval of the technical specifications from the catalog data, the related device type AAS can be easily extended to contain a device definition in form of a PA-DIM information model from a library (AAS of a device type). In case the device is used within a Process Equipment Assembly (PEA) according to the MTP-standard, a mapping between the variables of the PA-DIM model and the MTP-library [13] is required so that the correct OPC UA nodes can be addressed within the PEA. Thus, together with the Process Automation – Device Integration Model (PA-DIM) information model, this mapping could be stored, uploaded to the AAS and re-used within other projects.

2. Linking between existing standards: An example of this use-case are links between elements of a composite system, like Computer Aided Design (CAD) or P&ID, and the supporting type- and instance-specific documentation of the diagram’s elements. This use-case is picked up within the definition of the MTP submodel for AAS and shows the integration between MTP and VDI 2770 standard for documentation metadata (cf. Section 5). An additional example is the import of a DEXPI-file from an engineering tool be used as an HMI for the operator graphic [6]. Anyhow, this feature of converting one format to another does not come out of the box and must be implemented in addition. Nevertheless, an AAS can be used to create and maintain those links between artifacts, e.g., between the P&ID and the generated HMI elements.

3. Comparison of as-planned, as-built, and as-operated models: For this use-case, labelling the information within the AAS as it is the default way for code repositories might be a solution in order to quickly fetch the relevant versions after years have passed. An essential requirement for this use-case is of course to keep the AAS up to date or to be able to update the AAS on request with the current as-operated data. In order to visualize the results, the engineering tools might be required to implement an API for graphical comparison, as the AAS otherwise can only compare the data in a text-based way (e.g., JSON). This is especially important for tools that work graphically, like CAD tools or control logic editors using Function Block Diagrams (FBD). Here, a text-based comparison would be too confusing. But for a first start, an automatic approach to retrieve the relevant artifacts, e.g., as files, and indicate what files are different or the same might already be beneficial to point out differences.

4. Lifetime services: As listed in the previous section (cf. Step 6 of Figure 3), lifetime services which span over multiple lifecycle phases and include condition monitoring, firmware updates and enhancements of equipment during the operation phase benefit from the AAS. An example is the replacement of a device like a pump: The parameters are backed up in the AAS and can be loaded into the new device. In case the AAS does not only contain ‘as-is’ data but also requirements data, a new pump could be selected according to these requirements (cf. [56]) without overdimensioning devices over the time. Furthermore, circular economy use-cases including safe device and plant re- and up-cycling after the operational phase (cf. [64]) are included in this category.

The different use-cases show that not only within one project, but also between projects, saving potentials could be lifted with the help of the AAS. Thus, not only the operation phase, but also the engineering phase could benefit from an AAS. Similar to the support of standardized import and export formats, the different engineering tools would have to support a standard interface towards the AAS-infrastructure to ease the data exchange. Otherwise the versioning and keeping track of all the different files, uploading and downloading them manually to the AAS-framework, will become a challenge.

A yet to be explored aspect is the interplay between engineering tools for specific standards, e.g., DEXPI and generic AAS tooling when it comes to tasks of detecting deltas and impact analysis of changes within those. This is obvious that, on one hand, generic AAS tools cannot interpret differences beyond the AAS metamodel better than text comparisons – here domain specific tools are continued to be used. On the other hand, changes in the metamodel of the AAS and also co-located changes in other, possibly linked, artifacts are beyond the scope of specific domain engineering tools and should be solved by AAS tooling. It turns out that AAS tooling has potential to become an “orchestrator” to invoke domain-specific engineering tools and interpret their findings.

Beyond that, the omnipresence of runtime and engineering information is an enabler for advanced use-cases like intent-based engineering. The model and submodel meta data from the AAS (i.e., the semantic meanings and representations) can be mapped to the respective semantic representations of Semantic Function Modules (SFMs) [65]. Having this, one can bring the respectively AAS-contained data, as contained in the meta model, into the SFM Pipeline Generator engine, so that it processes AAS contents, and so that it allows to accordingly build or complete, e.g., a process topology based on the MTPs listed, and based on what is specified for the overall process plant I/O. Moreover, building on top of the AAS submodels and the therein defined entities, parameters, variables, and relations, one can implement query mechanisms. These queries can, e.g., simply filter the AAS-contained data according to specific features or features that occur in conjunction with each other, etc. In more advanced scenarios and applications, these queries can even be used to implement sophisticated feature engineering, data analytics, and machine learning algorithms, or be used for semantic reasoning and inference, e.g., based on an underlying knowledge graph [66].

4.2 Challenges – standard re-modeling and infrastructure efforts

Adapting an emerging standard like AAS for the purpose of integrated engineering have a number of challenges which we review in this section.

First and foremost, there are a number of general challenges related to emerging standards like the frequency of change of the specification, gaps in the specification (e.g., related to the security concepts within the AAS or event exchange between AAS which is especially important for lifetime services), and a lack of feature support and feature comparability among different available AAS SDKs. Furthermore, since AAS metamodel is an “envelope format” for the contained information, the suitability of AAS for a concrete use-case is determined by the quality of available standardized submodel templates (we will discuss these in Section 5) and their lifecycle governance (processes of creation, review, updates, and deprecation of submodel templates) [67].

When looking into applications of AAS particularly for the engineering process, there are a number of challenges already indicated in the previous section (cf. Section 4) and some publications around AAS and engineering (e.g. [55, 64]):

1. AAS version control: To match the state of the art of existing file-based and database-based engineering tools, AAS infrastructure support for versioning, compression, merging and exchange of engineering information is needed. The versioning is related not only to the content of the AAS, e.g., included parameter values, but also to the versioning of submodel definition and the relation between the submodel definition and the submodel content. Methods for (combined) calculation of deltas within the AAS metamodel and embedded artifacts are yet to be developed as mentioned above.

2. Distributed AAS infrastructure: In order to fulfill the requirement of distributed type-AAS catalogs, a support of replication and synchronization of multiple AAS repositories and related update events is needed. Even though distributed deployment of AAS and its submodels is deeply rooted into the AAS specifications, so far, no standardization or implementation efforts are known to us to enable support of those.

3. Double-modeling risks when lifting existing standards into AAS: Process plant engineering has a large amount of existing standards covering various aspects of the engineering process (cf. Table 1). An approach to embed an existing standard ranges between embedding an existing standard artifact (e.g., an MTP file) into the AAS as a Binary Large Object (BLOB) (the black-box approach) to a complete re-modeling of the underlying standard-specific information model within the AAS metamodel involving double-modeling and data provision. We will discuss a possible compromise between these two model types in Section 6.

4. Missing cross-AAS reference practices and infrastructure: References between submodels and related lifecycle phases, e.g., engineering and operations, are of particular importance for described integrated lifecycle engineering use-cases. Currently, references between AAS submodels are rarely seen in known demonstrators and model specifications. Therefore, guidelines for cross-submodel referencing and an infrastructure to store and resolve those references is required. Furthermore, even though event propagation concepts are defined within the AAS specification, there is a lack of interoperable implementation agreed by the community.

5. Missing best practices regarding AAS-based workflows and processes: Since AAS metamodel and infrastructure do not specify explicit workflows, currently there is a lack of well-defined workflows when exchanging engineering information based on AAS framework. For a suitable workflow definition questions of data ownership, data access, the quality and the frequency of data exchange via AAS have to be specified by the community.

In the following sections we address three of the presented challenges. Section 5 reviews current submodel template specification activities of IDTA with focus on engineering. Section 6 tackles the risks of double modeling and missing reference practices by defining gray-box modeling practice and fragment reference mechanisms between AAS submodels which are applied on the example of MTP submodel. Addressing the remaining challenges is scope of future work.

5.1 Handover documentation

The submodel template “handover documentation” defines an interoperable documentation provisioning interface for documentation artifacts (e.g., manuals or specification sheets) from equipment suppliers to operators and engineering companies. The kinds of supplied information range from administrative documentation, project control documents over data sheets, instruction, certificates and manuals to on-site location documents for the commissioning and operation phases (still, current demonstrators mostly focus on the engineering-related type-specific documentation).

The submodel embraces an existing German standard called VDI 2770 [69] defining a (partial) model mapping between the information model of VDI 2770 entities to the metamodel of the AAS like nested submodel element collections and specific properties. Since there is no public final version available currently, a mock of the submodel indicating the intended structure can be found in the left-lower part of Figure 4 below a submodel element element called “Documentation”. In the figure, a type 1 AAS is viewed using an open source AAS Package Explorer tool^[10] and a number of nested properties for each documentation item like its title, release status and date are visible.

Figure 4:

Example of a fragment reference between the MTP (black-box) and the documentation handover (white-box) submodels viewed using AASX package explorer tool.

The current proposal state of the submodel specification does not embed the XML-based artifacts defined by VDI 2770, only the actual documentation items (e.g. as Portable Documentation Format (PDF) files) are embedded in the AAS. Therefore, this submodel specification can be considered as a white-box submodel wrt. VDI 2770 specification.

5.2 DEXPI handover

The currently ongoing specification of the submodel for the handover of P&ID diagrams according to the DEXPI specification between different organizational entities defines an information model to uniquely describe the (segment of) the production plant which is described by the P&ID, such that, a diagram can be uniquely attributed to the plant along during its lifecycle.

This use-case requires a remodeling of a subset of meta-data from the DEXPI specification for both the plant (segment) and the embedded diagram within the submodel template definition. Examples for meta-data of the plant are hierarchy information like company name, location name, site name etc. Examples for diagram meta data are the names of creators, drawing name and number etc.

The submodel definition furthermore defines two additional features: (1) the possibility to bundle multiple DEXPI diagrams describing the same plant into one AAS submodel for handover and (2) the possibility to provide globally unique IDs for tagged elements within the P&ID diagram (in this case, the tags within the P&ID are also re-modelled within the submodel). For this reasons, we classify this submodel as a gray-box submodel with added features.

5.3 Inclusion of MTP data

The submodel template “Inclusion of Module Type Package Data into Asset Administration Shell” defines an information model for handover of MTP files both for module types and module instances called PEAs.

When it comes to the wrapping of the MTP file describing the module type, the submodel proposes a black-box approach of embedding the file into the submodel without almost any additionally added information on the AAS level. This simple approach is visible in the left-upper part of Figure 4 below the submodel element called “Module Type Package”. It is planned to extend the submodel with additional information along with further use-cases around the submodel usage. On such use-case could be searching for the services offered by the MTP with means of AAS infrastructure (e.g., within a registry referencing information of multiple module types). This would require re-modeling of services described within the MTP file by means of AAS metamodel in the next revision of submodel template.

On the other hand, the submodel specification provides an additional feature compared to plain MTP when describing PEAs. Examples are identification properties of the PEA (like its serial number), the network location of its OPC UA endpoint (for runtime communication) and a number of operator-specific description fields are proposed. Furthermore, the AAS of the PEA is referencing the relevant AAS of module type containing the MTP artifact.

Based on the sparse re-modeling efforts within the published submodel, we classify it as black-box submodel with added features. Furthermore, an important pattern for cross-artifact references called fragment referencing is described in the next section.