Digitalization with Value Chain Integration

Author photo: Valentijn de Leeuw
By Valentijn de Leeuw

Keywords: NAMUR, Asset Administration Shell (AAS), NAMUR Open Architecture (NOA), PA-DIM, O-PAS, European Data Spaces, Manufacturing-X, AR Advisory Group.


At the NAMUR General Assembly, 23 and 24 November 2023, in Neuss, Germany, Michael Pelz, Andreas Schüller and Igor Stolz presented a common vision of NAMUR and ZVEI of recent developments in digitalization in the process automation domain, building on several existing standards and concepts. The vision aims to improve Value Chain Integrationcompetitiveness through efficiency increases, that will secure viability of the process industry’s manufacturing sites in high-wage countries.  The presenters showcased a few potential use cases. 

The key technical component in the vision is the use of the Industrie 4.0 Asset Administration Shell (AAS).  The AAS was originally proposed by the Platform Industrie 4.0, which focused on the discrete industries. The NAMUR organization, with a process and hybrid focus, understood the AAS’ potential for their vertical. 

One use case is the update of an asset management or engineering tool with the information carried by the AAS of a replaced or maintained device.  The vision builds upon the NAMUR Open Architecture (NOA), which NAMUR extended with a context layer that hosts and serves AASs.  A second use case uses the AAS of a brownfield device built in the context layer using OPC-UA, PA-DIM and other standards. This AAS is efficiently and securely shared and collaboratively worked on by actors such as owner-operators and contractors across the value chain involved with the asset, using data spaces. 

To support the vision, NAMUR aims to build a Gaia-X -compatible data space “Manufacturing-X” with similar scope as “Catena-X” for the automotive industry.  The next paragraph updates and adds to information published earlier in “Concepts and Applications of the I4.0 Asset Administration Shell.”  Next we discuss the extended NOA concept, followed by the description of use cases described by the aforementioned authors.

Asset Administration Shells Are Real

The ASS was not only viewed as a concept for the discrete industry, but it was also seen as a theoretical construct. Today it has sufficiently been described and tested to be real and usable. An AAS is a standardized digital representation of an asset (for the full definition by ZVEI, see call-out). It can be located in a cloud application, an edge device or inside smart equipment. 

To illustrate what the AAS really is, this section briefly guides the reader through its structure. Besides identifiers of the AAS and its associated asset, the AAS is a collection of populated information models, referred to as “submodels.” Submodels contain a category of information related to the asset such as technical data, operational data, documentation and in the near future “facility-related environmental data.” Technical data could include 1D and 3D design data, and other asset properties. Operational data can be operating and control modes (as in the case of MTP), and dynamic, real-time data, which are traditionally located in control systems, SCADA, or historians. 

Ideally, submodels are standardized. If so, they are built according to a submodel template. This approach improves interoperability and applies to many categories of information. Templates contain standard submodel element collections (SMCs), each of which contain submodel elements. Optionally, collections can contain other collections. For example, in the SMC “Technical Properties” there can be an SMC “Electrical” with elements “Max.Current”=4A, and “Freq.Range”=50.60 Hz. The variables “Max.Current” and “Freq.Range” are equipment properties that can be defined by standards, such as product classification systems as ECLASS or IEC CDD, by consortium specifications or manufacturer specifications. 

A property is interoperable when the product class of the asset has a semantic identifier which is part of a standard classification. The semantic identifier serves as reference to the standardized properties of the asset class. When the property of a product class is not available in a standard, the property can be described by non-standard submodel elements.

The AAS can describe a generic asset type used in the design, development lifecycle stages of the asset, or it can describe an asset instance, once it has been built, integrated and is used. The relationship between type and instance will continue to exist throughout the life of the assets and the type. Usage and maintenance data of asset instances can flow back to the asset type information. This information could lead to updates for the asset fleet, for example with over-the-air firmware or software updates.

NAMUR’s current thinking is to introduce a third AAS that would contain the engineering specification of the asset, a version of the instance AAS, and differentiate it from the as-built and as-maintained instance AAS. In their view, the specification values may be adapted over the lifecycle and will differ from the as-built and as-maintained values. The latter must perform at least as well as the specification. The reason to keep the two distinct is to avoid specification inflation over the asset lifecycle by providing a well-motivated reference point for the design specification. How to manage those two AASs efficiently is a question. An alternative could be to add submodels for specifications in the instance AAS. The debate is ongoing.

Information exchange can also happen between AASs of different asset classes, for example in the case of assemblies. In operations, an asset can communicate its operation mode or status to the assets downstream in the process.

Extended NAMUR Open Architecture

The NAMUR Open Architecture (NOA) is based on a concept that separates critical measurement and control functions from non-critical operations management such as “monitoring and optimization.” In its implementation it focuses on exporting critical control and instrument information efficiently using existing standards such as OPC-UA, and the standard classification standards mentioned above. This work led amongst others to the PA-DIM companion specification. (See NAMUR’s page or our article for details.). In this year’s General Assembly, the NOA automation pyramid has been extended with another layer, dubbed “context,” which could be interpreted as the additional meaning of data added by, for example PA-DIM, or AAS. When this context is shared across the value chain, another layer can be added representing the data spaces through which this contextual information flows.


ARC Advisory Group clients can view the complete report at the ARC Client Portal. 

Please Contact Us if you would like to speak with the author.

Obtain more ARC In-depth Research at Market Analysis


Engage with ARC Advisory Group

Representative End User Clients
Representative Automation Clients
Representative Software Clients