Asset Administration Shell interoperability testing for brownfield machine retrofits in German Mittelstand factories: an OPC UA-based evaluation framework

1. The standards landscape, and the seam in it

Three components are often conflated; separating them is the first step toward a tractable research topic.

The structure standard. IEC 63278-1 defines the Asset Administration Shell for industrial applications — the standardised digital representation of an asset giving uniform access to information and services. Its German adoption is DIN EN IEC 63278-1:2024-09 [1]. Crucially, it describes the basic concept and structure and explicitly does not cover the information metamodel, security specifications, online interfaces or the communication language between shells [1].

The metamodel and interfaces. Those live with the Industrial Digital Twin Association, whose AAS specification is published in parts: Part 1 Metamodel, Part 2 Application Programming Interfaces, Parts 3a and 3b Data Specification, Part 4 Security and Part 5 Package File Format (AASX) [2].

The mapping onto a communication stack. OPC Unified Architecture is standardised as the IEC 62541 series — Part 14, for example, specifies PubSub [4]. The OPC Foundation’s companion specification OPC 30270 provides the mapping between the AAS metamodel and the OPC UA information model. Its specification record gives release version 1.00 with a publication date of 4 June 2021 [3].

Taken together, these three facts identify a potential research seam. The structure standard excludes the metamodel; the metamodel has moved to V3.x; the OPC UA mapping is a 2021 document. That seam provides one possible basis for a defensible thesis contribution.

2. From retrofitted machine to a defensible contribution

Figure 1. The brownfield path, the five levels at which it can be measured, and where the remaining research gap sits. Source: author synthesis based on the published standards, specifications and literature cited in this article [1,2,3,4,6,7,8,9].

3. The gap, stated so a committee can check it

A topic-selection claim has to survive someone looking it up — including someone who searches the exact phrase you used. So begin by conceding what is already done.

AAS conformance testing is now an established line of work, including formal metamodel and API testing. The evidence is specific and easy to find:

Otto and Kleinert published Test engines for the asset administration shell in at – Automatisierungstechnik in 2025 [8].
A multi-institution group including RWTH Aachen, TU Dresden and Fraunhofer presented Towards a Test Framework for Reactive (Type 2) Asset Administration Shell Implementations at IEEE ETFA 2024 [9].
Model-based test-case generation for compliance checking of reactive AAS implementations was published as early as 2022 [10].
And the work is institutionalised in tooling: an official AAS test engine validates AASX, JSON and XML files against the metamodel and Part 3a constraints, tests submodels against templates, and tests server implementations against the Part 2 interfaces [7].

A proposal that claims this field is empty will be rejected on the first search. The narrower opportunity is what remains:

Existing work	What it establishes	What it does not establish	Where a PhD can contribute
Official AAS test engines [7]	File, metamodel, template and API conformance for the supported profiles and versions	How a shell generated by a retrofit behaves, or where its semantics came from	A retrofit-specific conformance profile and test set
AAS conformance-testing research [8,9,10]	Formal and model-based test generation for passive and reactive shells	Legacy-controller-to-semantics mapping as an object of evaluation	Evaluation of the mapping procedure itself, not only its output
OPC 30270 [3]	A published mapping from the AAS metamodel to OPC UA	Empirical consistency of that mapping for a retrofitted asset, at the current metamodel version	Cross-representation consistency tests, reported per version
Brownfield integration studies [6]	That legacy integration is a recognised challenge	A formal conformance profile for the result	A combined evaluation framework spanning both

A 2025 review of ten years of AAS research in IEEE Access supports the framing on three specific points. It states that the OPC 30270 mapping is based on an earlier version of the AAS information metamodel, so “some adaptation may be required” [6]. It calls “integration with legacy/existing systems … another crucial challenge”, with automated-extraction work described as preliminary [6]. And it counts 39 published submodel templates, calling for more while warning that growth “can lead to the proliferation of submodels with overlapping purposes” [6].

So the defensible claim is narrow and checkable: conformance and interoperability evaluation of AAS instances generated through brownfield machine retrofits — specifically the provenance of semantic mappings from legacy controller data, consistency across the OPC UA mapping, and retrofit-specific interoperability metrics — remains an open research opportunity, even though AAS conformance testing in general does not.

Stated that way, the existing literature strengthens the proposal instead of undermining it, because it supplies the methods the new work builds on.

A formulation an examiner finds hard to dismiss. Compare: “AAS interoperability testing” (too broad) → “AAS conformance testing” (already done) → “a version-aware test framework for evaluating semantic conformance, OPC UA mapping consistency and runtime interoperability of Asset Administration Shells generated from brownfield machine-tool retrofits”. Each qualifier in that last formulation is doing work, and each is defensible against a search.

4. Why brownfield, and why the Mittelstand

The scope restriction needs a reason beyond convenience, and there are three defensible ones.

Brownfield retrofit scenarios are less represented in the evidence reviewed for this article than greenfield implementations. A machine designed and implemented with an AAS can be provisioned against the relevant model from the outset; a legacy machine requires the shell to be constructed retrospectively, from whatever the retrofit adapter can observe. Conformance questions that are straightforward in the first case — does a required property exist, is its semantic identifier resolvable, is its unit the one the template demands — become real engineering questions when the source is a controller tap rather than a design document.

The 2025 review names SMEs as an open direction, on the grounds that the AAS can be adopted incrementally alongside existing systems, while noting that many face high costs and complex implementation requirements [6]. That is one review’s assessment rather than a field-wide consensus, but it is a published one, and a framework that lowers the cost of verifying a retrofit speaks directly to it.

And there is a test case with a standard behind it. Machine tools have their own OPC UA companion specification: OPC 40501-1, OPC UA for Machine Tools — Part 1: Machine Monitoring and Job Management, release version 1.02.0, publication date 1 November 2024 [5]. A retrofitted machine tool can therefore be evaluated against a published domain information model as well as against the AAS metamodel — two independent conformance targets on one asset.

Be honest about the trade-off. Restricting to retrofitted machine tools in Mittelstand factories buys interpretability and a credible access story, and costs external validity. Say so in the proposal rather than letting an examiner say it for you.

5. Five measurement levels, and why they must stay apart

The brief’s phrase “interoperability benchmarking” is not yet a measurement. A reviewer will ask what the dependent variable is, and “interoperability” is not an answer. Separate the levels and answer precisely.

Level	Construct	What is actually tested
1	Representation validity	Does the AASX, JSON or XML parse and satisfy the schema?
2	AAS conformance	Metamodel and Part 3a constraints; submodel-template conformance; Part 2 interface behaviour, including on invalid requests [2,7]
3	Semantic interoperability	Identifier resolution, unit and datatype agreement, semantic equivalence across submodels, and the provenance of each mapping
4	Cross-technology interoperability	Consistency between the AAS representation and the OPC UA representation of the same property [3]
5	Runtime performance	Latency, jitter and throughput under a stated load profile [4]

These fail independently. A file can be schema-valid and template-invalid; a server can serve conformant files and still mishandle a negative limit parameter; a shell can be fully conformant and still disagree with its own OPC UA projection. Reporting a single pass/fail rate across all five is the most common measurement error in this space.

Report a profile, not a verdict

Avoiding a single score does not mean avoiding numbers. Define a profile and report it per retrofit — for example S1 serialisation, S2 metamodel, S3 template, S4 interface, S5 semantic mapping, S6 OPC UA consistency, S7 timing — so a result reads as a vector across the levels, with the timing component reported as a percentile under a named load rather than as a mean. That is a doctoral result; a single percentage is a software demo.

Semantic interoperability, and the provenance question

Syntactic validity does not mean two systems agree on meaning. The measurable questions are concrete: can every semantic identifier be resolved to a definition? Do units and datatypes match what the template specifies? When the same physical quantity appears in two submodels, does it carry the same identifier? And — the retrofit-specific one — when a legacy controller exposes a register with no semantics at all, what is the provenance of the identifier the adapter assigns it?

That question provides a potentially measurable research dimension, because the mapping from a controller register to a semantic identifier can be documented, reproduced and evaluated. Either it is a specified procedure that another engineer can rerun, or it is a technician’s judgement that nobody can.

Latency, stated so the number means something

Measuring “latency” is meaningless without stating the path, the clock and the load. Specify: which hop is measured (adapter to server, server to client, end-to-end); how clocks are synchronised across measurement points; whether the transport is client/server or PubSub [4]; what the load profile is; and whether you report a mean, a 95th percentile or a maximum. For time-sensitive control applications, jitter may be more informative than mean delay, because deadline compliance depends on the distribution of delay rather than on its average.

6. A worked retrofit example

Abstractions are easy to agree with and hard to test. Here is the same idea as a single data point travelling the full path.

A legacy CNC controller exposes a register — say a spindle-housing temperature in degrees Celsius — at an address that means nothing outside the machine’s own documentation.

Stage	What happens	What can go wrong
Controller register	Raw value read from a controller address	Scaling or sign convention misread
Adapter mapping	Address bound to a named quantity and a unit	Value correct, but the binding is undocumented
Semantic identifier	A semantic ID assigned to the property	Value correct, semantic ID wrong
AAS property	Property placed in a submodel against its template	Semantic ID correct, unit wrong
OPC UA node	Property exposed through the companion-specification mapping	AAS correct, OPC UA representation inconsistent
Consumer	Value read by an MES, client or dataspace	Consumed correctly but with the wrong meaning

The three bolded rows are three different failures, detected by three different instruments, at levels 3, 2 and 4 of the hierarchy in §5. A framework that distinguishes them is a contribution; one that reports “the retrofit worked” is not.

7. A test-bed design that survives contact with reality

Element	What to specify	Why a committee asks
Asset under test	Machine type, age, controller, available interfaces	Determines what the adapter can observe at all
Retrofit adapter	Sensing, gateway hardware, how the controller is read	The adapter is part of the system under test, not neutral apparatus
AAS implementation	Which SDK or server, which metamodel version	Results are version-bound and must be reported as such
Submodel set	Which templates, and why those	Scope control; ties the work to published semantics
Conformance instruments	Which checks, run with which tooling and which profiles [7]	Separates your contribution from the existing tool’s coverage
Timing instrumentation	Measurement points, clock synchronisation, load profile	Without this the latency numbers are not interpretable
Comparison condition	A second adapter, a second machine, or a greenfield reference	Without one, you have a demonstration rather than an evaluation
Reproducibility package	Configuration, test data, scripts, versions	Increasingly expected, and cheap to produce if planned early

The comparison condition is the row most often missing. A single working prototype is an existence proof, not an evaluation — and the difference is the difference between a project report and a thesis chapter.

On tooling coverage, be precise rather than dismissive. The published AAS test-engine coverage is specification- and version-dependent and spans file, metamodel, submodel-template and API conformance checks; the current tool documentation should be consulted for the supported profiles and templates now the study is fixed [7]. Report exactly which profiles, templates and specification versions your study used, and state what your framework adds beyond them. Do not characterise the tooling’s coverage as small without reporting the denominator you measured it against.

8. Candidate research questions

These are illustrative formulations, not findings, and each would need narrowing against the current specification releases.

RQ1 (descriptive). For AAS instances generated from retrofitted legacy machine tools, which classes of conformance failure occur, and at which of the five levels in §5?

RQ2 (design-science). Can an evaluation framework be specified that produces a per-level profile for a retrofit, rather than a single pass/fail verdict, and can it be applied by an engineer who is not an AAS specialist?

RQ3 (comparative). Where the same asset is exposed through the OPC UA companion-specification mapping and through the AAS Part 2 interfaces, do the two representations agree [3]? “Agreement” must be operationalised before this is testable — at minimum as four separate tests: value equality for the same property at the same instant; semantic-identifier equality or documented equivalence; datatype and unit equality; and documented provenance for every element of the mapping. Report each separately, because they fail separately.

RQ4 (performance). Under a stated load profile, how do end-to-end latency and jitter differ between client/server and PubSub transports [4] for the same retrofitted asset? If the study claims a requirement is met or missed, the consuming application must be named, and its timing requirement stated — for example, a condition-monitoring dashboard with a defined refresh deadline, or a job-management client under OPC 40501-1 [5]. Otherwise report the distributions and explicitly decline to adjudicate fitness for purpose.

Hypothesis, labelled as such. Conformance failures in brownfield AAS instances concentrate at the semantic layer — identifier resolution and unit agreement — rather than at serialisation, because serialisation is produced by tooling while semantics are supplied by a human during retrofit. That is a plausible and testable proposition. It is not an established finding, and nothing in this article should be cited as evidence for it.

9. Traps that sink Industry 4.0 proposals

Trap	What it looks like	What to do instead
The buzzword subject	“Industry 4.0 in SMEs” as the topic	Name the standard, the level and the failure mode
The empty-field claim	“No one has studied AAS conformance testing”	Concede the established work, then narrow [7,8,9,10]
Version amnesia	A design written against an unnamed AAS version	Pin the metamodel, API and companion-spec versions, and say they are pinned [2,3]
Tool substitution	Running the existing test engine and reporting the output	State which profiles and templates it covers, then state what your framework adds [7]
One prototype, no comparison	A single retrofit that works	Add a comparison condition and report where it fails
Undefined latency	“Low latency was achieved”	Path, clock, load, percentile — or no number
Conformance as one number	A single percentage across all checks	Report a per-level profile
Semantics by assertion	Identifiers assigned without provenance	Document and evaluate the assignment procedure itself
Access assumed	A factory partner implied but not secured	Letter of access, or a laboratory fallback designed in advance

10. Study design checklist

Dimension	Evidence to hold before submission	Risk if unresolved
Standard identified	The exact standards and versions in scope [1,2,3]	A moving target no examiner can assess
Gap located	The gap checked against current testing research [6,7,8,9,10]	A novelty claim that collapses under one search
Level named	Which of the five levels the contribution addresses	A claim about “interoperability” in general
Instrument coverage	Which profiles, templates and versions existing tooling covers [7]	Reinvention presented as contribution
Test case secured	Machine access, or a documented fallback	A design that cannot be executed
Measurement defined	Path, clock, load and statistic for every metric	Numbers that cannot be interpreted or replicated
Agreement operationalised	How cross-representation equality is tested	A comparison nobody can referee
Comparison condition	A second adapter, machine or reference implementation	A demonstration, not an evaluation
Reproducibility	Versions, configuration and data archived	Results that cannot be rerun after a release changes
Scope justified	Why brownfield, why this machine class, why Germany	Convenience mistaken for research design

11. What a German committee will ask

Expect: which standard, which part, which version; what exactly is new relative to the published test engines and the existing conformance-testing literature; what counts as a conformance failure and who adjudicates it; how many machines, and whether one is enough; what the measurement path and load profile are; whether the result survives the next specification release; and how the work generalises beyond the single factory that let you in.

Common weaknesses that require revision: a topic stated at the level of a technology programme rather than a standard; a novelty claim that current testing research disproves; conformance reported as a single number; latency without a path or a load; cross-representation “agreement” left undefined; a prototype with no comparison condition; and a design pinned to no specification version at all.

Before you commit to an Industry 4.0 topic: validate the design

The problem is specific to this field. The standards move faster than a doctorate, the vocabulary is shared with marketing material, and a topic that sounds current in month one can be either superseded or already published by the time anyone tests it.

What the research-design review covers

Standards and version scope
Research-gap validation against current literature and tooling
Research questions and construct definitions
Test-bed feasibility and equipment access
The measurement framework across all five levels
Comparison-condition design
Specification-version risk

The deliverable is a written design assessment — a scoping memo and an evaluation-framework plan stating what can be claimed, what must be narrowed and what must be re-checked against the current releases.

Request a Research Design Review with PhD Assistance’s engineering research team. The consultation advises on methodology; you carry out the research.

Frequently asked questions

Is AAS conformance testing already a research topic?

Yes. AAS conformance testing is an established research direction, including formal metamodel and API testing, model-based test generation for reactive shells, and published test engines [7,8,9,10]. A stronger PhD contribution therefore has to narrow the problem further — for example to brownfield retrofit-generated AAS instances, semantic mapping provenance, OPC UA mapping consistency, or performance under defined workloads.

Is the Asset Administration Shell still a novel PhD topic?

Not in its broad form — a 2025 review describes a decade of development and a technology that has reached adoption maturity [6]. It remains open in specific places, and the evaluation of shells produced by brownfield retrofits is one of them, for the reasons set out in §3.

Which standard do I actually cite — IEC or IDTA?

Both, for different things. IEC 63278-1 defines the AAS structure and is the formal standard, but it does not cover the information metamodel [1]; the metamodel, APIs, data specification, security and package format are the IDTA specification parts [2]. A proposal that cites only one of them will be asked about the other.

Does OPC UA replace the AAS, or the other way round?

Neither. OPC UA, standardised as IEC 62541, is the communication architecture and information-model framework [4]; the AAS is the asset’s standardised digital representation. The companion specification OPC 30270 maps the AAS metamodel into OPC UA, with a publication date of 4 June 2021 for release version 1.00 [3] — which is why version alignment is itself a research question [6].

Can I do this without factory access

Partly. A laboratory test bed with a representative controller can support the conformance and semantic work. The retrofit-specific questions — what a technician must supply when a register carries no semantics — need real equipment and a real retrofit. Design the fallback before you need it, and state in the proposal which research questions survive if access is lost.

How do I keep the work from being obsoleted by a new release?

Pin and report every version, build the framework so the specification profile is an input rather than hard-coded, and treat “does the framework survive a version change” as a finding worth reporting rather than a threat to hide.

Reference

Asset Administration Shell for industrial applications — Part 1: Asset Administration Shell structure. DIN EN IEC 63278-1:2024-09 (IEC 63278-1:2023); VDE 0810-781:2024-09. https://dinmedia.de/en/standard/din-en-iec-63278-1/380477303
Industrial Digital Twin Association (IDTA). Specification of the Asset Administration Shell, Parts 1–5 (Metamodel; Application Programming Interfaces; Data Specification; Security; Package File Format AASX). https://industrialdigitaltwin.org/en/content-hub/aasspecifications
OPC Foundation. OPC 30270: OPC UA for Asset Administration Shell. Release version 1.00; publication date 4 June 2021. https://reference.opcfoundation.org/specs/OPC-30270
International Electrotechnical Commission. OPC Unified Architecture — Part 14: PubSub. IEC 62541-14:2020. https://webstore.iec.ch/publication/61108
OPC Foundation. OPC 40501-1: OPC UA for Machine Tools — Part 1: Machine Monitoring and Job Management. Release version 1.02.0; publication date 1 November 2024. https://reference.opcfoundation.org/specs/OPC-40501-1
Sakurada L, de la Prieta F, Leitão P. Ten years of Asset Administration Shell: developments, research opportunities, and adoption challenges. IEEE Access. 2025;13:127721–127741. doi:10.1109/ACCESS.2025.3586716
aas-test-engines — official test tooling for the Asset Administration Shell (file, API and submodel-template conformance), version 1.0.3, 5 August 2025. https://pypi.org/project/aas-test-engines
Otto B, Kleinert T. Test engines for the asset administration shell. at – Automatisierungstechnik. 2025;73(2):145–158. doi:10.1515/auto-2024-0150
Miny TH, Heppner S, Garmaev I, Ristin M, Otto B, et al. Towards a test framework for reactive (Type 2) Asset Administration Shell implementations. In: 2024 IEEE 29th International Conference on Emerging Technologies and Factory Automation (ETFA); Padova, Italy. IEEE; 2024. doi:10.1109/ETFA61755.2024.10710957
Otto B, Meinecke K, Kleinert TT. Model-based test case generation for compliance checking of reactive Asset Administration Shells. In: Kommunikation in der Automation — KommA 2022. Lemgo: inIT, TH Ostwestfalen-Lippe; 2022:180–191. doi:10.18154/RWTH-2022-10160