The digital twin is a virtual representation of an asset over its entire life cycle. This also includes non-physical assets such as software. There are a number of specific use cases for the digital twins of software. These include storing, managing, versioning and distributing software via a digital twin. Various use cases show how well the AAS and OPC UA technologies complement each other here.

The software update model OPC-UA-DI in the address space of a PLCnext Control from Phoenix Contact

The digital twin has been one of the trending topics in automation technology for years. According to the definition from the publication “The role of the Industry 4.0 “administration shell” and the “digital twin” in the life cycle of a plant: navigation aid”, it refers to the administration shell of an asset (asset administration shell, AAS). An asset can be an individual component, a field device, an entire system or software. The use cases of the AAS that are currently being discussed the most include:

• the digital rating plate (digital nameplate)
• paperless documentation by storing corresponding digital documents in the AAS
• the provision of technical product features in the AAS and
• making the CO₂ footprint available in the AAS.

In addition, digital twins have the potential to advance end-to-end, integrated plant engineering in industrial manufacturing and thus increase the efficiency of production plant engineering in general. This was discussed in detail in the article “Digital Twin: More efficiency in
plant engineering”. The following use cases were described and examined in more detail in the item:

• Management of (automation) software modules based on asset administration shells
• Obtaining and reusing engineering data that is located in the plant AAS
• Use of engineering-relevant data from the AAS of the components
• Storage of engineering data generated during PLC engineering in Asset Administration Shells so that it can be reused in other engineering tools.

This article builds on this and focuses specifically on the aspects of software management, i.e. saving and managing with AAS and distributing software using OPC UA DI. To this end, the item briefly introduces the AAS technology – in particular the “Software Nameplate” submodel – and the “Software Update Model” in the OPC UA DI standard. It then shows how software can be stored, versioned and referenced in AAS software repositories. The authors then explain how software can be retrieved from the repositories and loaded onto devices via the OPC UA DI standard.

Finally, a conclusion is drawn and an assessment is made of the extent to which vendor-neutral, holistic software management is feasible today with the AAS and OPC UA.

AAS information is available in partial models

AAS technology is supported and promoted by the Industrial Digital Twin Association e.V. (IDTA) as a cross-company technology consortium. The general AAS metamodel has now been transferred to IEC standard 63278-1:2023. The Asset Administration Shells differentiate between type and instance AAS based on a class-object relationship. A type AAS represents the type of an asset. The instance AAS represents a concrete existing asset. It is generated when the asset is created and may be derived from a type AAS.

The information actually contained in the asset administration shells is available in the submodels. As of July 2025, the IDTA lists 98 predefined, i.e. published submodels and those currently being developed. These cover the basic use cases mentioned above, for example. Based on the predefined submodel “Hierarchical Structures”, the hierarchical structures of the AAS are also implemented as a list of references to subordinate AAS. The Asset Administration Shells are hosted in AAS repositories on AAS servers. Access to the AAS of an AAS server is via its REST API. Security mechanisms – such as fine-grained rights management – are already integrated into the AAS technology. On the production side, individual devices and components have a QR code that links to the AAS.

Software packages can be stored in the submodel

The aim of the Software Nameplate submodel is to provide software-related information in a standardized and interoperable way. The submodel consists of two aspects:

• the SoftwareNameplateType, which describes type-related properties such as product designation, version, manufacturer information or installation source.
• the SoftwareNameplateInstance, which includes instance-specific details such as serial number, installation path, architecture used and contact information.

Software packages can be stored directly in the type aspect of the submodel. Alternatively, the submodel allows the referencing of external sources of supply, for example a downstream software repository. Information on the download URL is recorded here.

Software update model determines standardized download interface

The OPC UA DI standard (Device Integration) is an extension of the OPC UA standard that was developed specifically for the uniform modeling and integration of devices in automation systems. It defines standardized information models and interfaces to represent and control devices from different manufacturers in an interoperable manner. The DI standard forms the basis for other standards aimed at modeling devices, such as “OPC UA for Profinet”, “OPC UA for IO-Link” or “OPC UA for PLCopen”. The DI specification explains three models that build on each other: the “(base) Device Model”, “Device Communication Model” and “Device Integration Host Model”. Two add-ins are also defined: the “Locking Model” and the “Software Update Model”.

The Software Update Model defines a standardized interface for loading software – for example firmware – onto a device via OPC UA. The download and installation of the software can be completely decoupled. For example, firmware updates can first be rolled out to several devices and then installed on all devices at the same time. To ensure the function of a device if an update fails, a fallback version can be defined via the model. Figure 2 shows the software update model in the address space of the OPC UA server of a Phoenix Contact controller.

Structure of AAS software repositories

Software repository the detection of changes to software dependencies

Figure 3 illustrates how software repositories can be realized with AAS using the Hierarchical Structures and Software Nameplate submodels mentioned in the previous sections. The repository can be an AAS server or a list of the AAS of software modules. In the first step, each software module is represented by an AAS that contains the Hierarchical Structures submodel. Each release of a software module has its own AAS, which is referenced in the AAS of the software module. The type aspect of the Software Nameplate submodel is defined in the AAS of the releases. Among other things, the software package of the release itself or its source of supply is stored in this submodel. Each release AAS also contains a Hierarchical Structures submodel with references to the AAS of all software releases on which this release is dependent.

Interaction with the AAS software repository over the life cycle of software.

Figure 4 shows the life cycle of software that – as described – is linked to the software repository of an AAS. The figure illustrates that there is even more information that should be stored in the AAS of the software module. This includes, for example, requirements and interface descriptions, documentation and test reports. The figure also explains that changes to software dependencies can also be determined from the software repository. Such a mechanism is useful in order to be able to react to any safety-critical updates in software dependencies.

Device and Update Management System obtains new installation packages from the AAS

Figure 5 shows how a software package is retrieved from the software repository of an AAS and loaded onto a device via the software update model of OPC-UA-DI. The central element here is software, which is referred to below as the “Device and Update Management System (DaUM)”. This software accesses the OPC UA servers of subordinate devices – such as controllers – and reads the version status of their firmware or other software on the devices. The DaUM uses the AAS software repository via the standard REST interface of the AAS server and checks at regular intervals whether a new software version is available there. If this is the case, the DaUM obtains the installation package from the AAS, loads it onto the device via the OPC-UA-DI software update model and runs the installation here.

Obtaining software from the AAS software repository and loading the software onto devices via the OPC UA DI standard.

Implementation of an AAS software repository is possible with current technologies

This article explains how complex software repositories can be set up using AAS technology and how they interact with AAS technology over the lifecycle of a software. The submodels used for this are already published today. It is therefore possible to implement such AAS software repositories with the current state of the art. The article also illustrates how a so-called device and update management system uses the OPC UA DI standard to update device firmware via OPC UA. Such device and update management systems are already available on the market, for example the software of the same name from Phoenix Contact. The next logical step towards completely vendor-neutral software management would be to link AAS software repositories with the installation mechanisms of the OPC UA DI standard. The last currently unresolved hurdle for complete vendor neutrality would then only be the format of the installation packages for software. There is therefore a need for further specifications to define a general, manufacturer-neutral format for software packages.

Prof. Dr. Andreas Würger, Professor of Industrial Control Engineering, HAW Hamburg and Arno Martin Fast, Senior Specialist, PLCnext Technology, Phoenix Contact GmbH & Co.