IEC 63278-1:2023 defines a 3-part Asset Administration Shell series for industrial applications, with Part 1 covering shell structure, Part 2 covering metamodel concepts, and Part 3 covering security provisions [S2][S5][S8].
The Asset Administration Shell represents a product, device, or machine through submodels, identifiers, and submodel elements so different software systems can exchange asset information without vendor-specific mappings [S1][S3][S4].
What IEC 63278 Defines at System Level
IEC 63278-1:2023 defines the structure of a standardized digital representation of an asset, and EN IEC 63278-1:2024 reproduces that international edition as a European Standard [S2][S9]. The metamodel specification is organized as IDTA document 01001-3-0, version 1.0RC03, published in April 2023 across 215 pages [S1].
The Asset Administration Shell is a container for asset information rather than one indivisible data block. Its principal building blocks are the shell, its submodels, and the submodel elements inside them; these can be represented through AASX package files, JSON, XML, and REST interfaces [S4]. The underlying AAS metamodel is technology-independent, which separates the information structure from the protocol used to transport it [S6].
The model supports both asset types and asset instances. Type assets represent a defined product or machine class, while instance assets represent particular physical or logical assets in operation; the specification addresses identifiers for assets, administration shells, and their contained elements [S1].
How the Shell and Submodels Relate
The shell provides the asset-level container and identity, while each submodel represents a focused information domain. Published explanations identify energy, maintenance, and documentation as typical submodel subjects, with reusable templates intended to reduce repeated definition work [S3].
A useful engineering model is a three-level hierarchy: the Asset Administration Shell identifies the industrial subject, one or more submodels partition its technical and business information, and submodel elements carry the actual semantic data. This structure lets separate applications work with one domain without loading every attribute of the complete asset representation [S4][S7].
Identifiers provide the links needed to locate and associate distributed information. IRDI and URI are identified as global identifier forms, while semantic metadata can reference dictionaries such as ECLASS so that data elements can be interpreted consistently across systems [S3]. The specification separately defines element identification and distinguishes identifiers by the object they identify [S1].
Selecting a Submodel Architecture
Submodels are not interchangeable payloads, so selection should follow domain ownership, reuse requirements, and interoperability constraints. An energy-management application may need energy properties, a maintenance system needs condition and service information, and documentation applications need manuals and technical documents [S3].
The comparison favors domain-specific submodels when several applications consume different aspects of the same asset. A single broad container reduces initial modeling effort but weakens change isolation, while multiple AAS instances can separate ownership or scale, at the cost of more identifier and relationship management [S1][S3].
Where the Model Fits in Plant Work
A machine builder can use an AAS to receive supplier data during engineering, an operator can use the same representation for commissioning and maintenance, and downstream processes can retain relevant asset data for repair, recycling, or disposal [S4]. This makes the AAS useful across the asset life cycle rather than only during a commissioning project.
Condition monitoring, overall equipment effectiveness analysis, predictive maintenance, and digital type-plate applications are identified as manufacturing use cases [S3]. The structure also supports traceability and compliance workflows in logistics, energy and emissions data exchange, product-service systems, and production-as-a-service models [S3][S4].
The Part 1 model is therefore not a control-loop specification. It defines how information about a physical or non-physical asset is represented, while actual measurements, commands, control logic, and functional-safety behavior remain responsibilities of the relevant engineering systems and equipment standards [S1][S6].
Security and Data Exchange Constraints
IEC 63278 Part 3 addresses secure and interoperable information exchange between stakeholders in value chains. Its security information model covers integrity, authenticity, and confidentiality, complements the Part 2 metamodel, and refines security requirements affecting the Part 1 information structure [S5].
Three security properties provide the decision framework. Integrity requires detecting unauthorized modification, authenticity requires establishing the origin of information, and confidentiality requires limiting exposure of protected content [S5]. These controls operate with the AAS structure rather than replacing identifiers, submodels, or semantic dictionaries.
The OPC UA Companion Specification I4AAS transfers the AAS data model into an OPC UA context, while AASX, JSON, XML, and REST remain relevant exchange formats [S3][S4]. Transport format alone does not establish end-to-end trust: identity, authorization, integrity verification, and protection of exchanged information still require an appropriate security architecture [S5].
Implementation Pitfalls and Sourcing Controls
The most common structural failure is treating a submodel as an unstructured attachment. A submodel without stable identifiers, defined semantic elements, and clear ownership can pass file validation while remaining unusable across applications [S1][S3]. Another failure is duplicating the same asset data in incompatible proprietary fields, which shifts the mapping burden back to every consumer [S4].
Data quality should be verified before release by checking identifier uniqueness, required elements, semantic references, and the relationship between type and instance records. For multi-vendor equipment, this prevents a drive, sensor, robot, or software tool from forcing a separate point-to-point interface [S1][S4].
Specification control should distinguish document provenance from implementation choice. Part 1 defines shell structure, Part 2 defines metamodel concepts, and Part 3 defines security provisions [S2][S5][S8]. EN IEC 63278-1:2024, dated January 2024, is the European adoption of IEC 63278-1:2023.
A trackable procurement signal is whether a supplier delivers a structured shell with identifiable submodels and reusable semantic definitions, not merely a PDF datasheet or an AASX file. A second signal is whether an integration platform can exchange those submodels through its declared formats while preserving identifiers and applying the Part 3 security properties [S3][S4][S5].