twinfix 2.0 highlight - Generic Submodel Template Conformity Validation for the AAS

We’re excited to lift the curtain on twinfix 2.0 today. twinfix is our free validation and fixing service for AAS 3.1 data, and this release is more than a face lift: the headline feature is generic submodel conformity validation.

Screenshot of twinfix 2.0: the website shows a log of the errors
found in an .aasx package, and detailed information on the specifics of one
of the errors. — twinfix 2.0 in action: the website provides a comprehensive overview of all identified defects. Additionally, it provides detailed information and suggestions for the individual defects.

Try it now: twinfix 2.0 is live at twinfix.twinsphere.io. Upload an .aasx package and see conformity results.

twinfix is the public-facing web service for the same validation technology that has already been available in the twinsphere.TypedAasMetamodels NuGet library. In the past we already offered specialized validation for a handful of submodel templates (SMTs), but hand-writing a validator for every SMT doesn’t scale against the number and pace of new templates being released. twinfix 2.0 solves this generically, for any SMT. The following gives a tour on twinfix and shows what’s new.

Motivation

The AAS has a real chance to become a key enabler for industrial automation, and with the adoption of the Digital Product Passport (DPP), it’s on track to become one of Industry 4.0’s cornerstone technologies. At the same time, one of the biggest hurdles to adoption is the standard’s own stated goal: interoperability, or rather, the current lack of it.

Since its inception, the AAS standard has evolved significantly. At the same time SMTs are authored by domain experts from many different fields. Add software vendors with differing interpretations of the standard, and you get a Tower-of-Babel situation. While the quality of tooling has improved and AAS data quality has gone up overall, true interoperability isn’t there yet.

The validation approach behind twinfix addresses this at every level of the AAS specification. twinfix 2.0 makes that technology freely accessible to the community.

What’s new in twinfix 2.0

twinfix checks AAS data correctness across several layers of the specification:

Part 1 for meta model data
Part 5 for .aasx packages
Specialized validation for submodel templates and instances
New: generic validation of submodel instances against arbitrary SMTs. Checking whether an instance’s structure and values conform to the qualifiers defined by its template

twinfix also auto-fixes common structural issues that can be resolved without changing the semantic meaning of the underlying data.

For generic SMT conformity validation specifically, we support the full set of template qualifiers as defined in IDTA’s “How to Create a Submodel Template Specification” guideline, including resolution of drop-ins and arbitrary properties.

What’s a drop-in? SMTs can reference reusable fragments. These are common building blocks like contact-information structures that can be reused, instead of requiring modellers to redefine them inline. A drop-in reference has to be resolved against the referenced fragment before an instance can be validated against the full, “expanded” template.

How generic SMT conformity validation works

To check whether a submodel instance conforms to its template, we borrowed a strategy from compiler design: parse the template into an intermediate representation, then derive executable validation logic from it, rather than hand-coding checks per template.

Pipeline diagram: Submodel Instance and Submodel Template flow through
Identification, Drop-in resolution, Canonicalization, and Translation stages
(with Template Repository access) into a Validator, producing either a valid
result or an Error Log
entry — The generic SMT conformity validation pipeline: a submodel instance and its SMT are identified, resolved, canonicalized, and translated into validator logic that checks the instance and reports either a valid result or an error log.

When a submodel instance is loaded, we identify its corresponding SMT via the template ID or semantic ID.
All drop-in references in the SMT are resolved, recursively, until none remain.
The fully resolved SMT is brought into a canonical representation.
The canonicalized SMT is checked for internal correctness (e.g., is it well-formed and consistent?).
The SMT is compiled into an abstract syntax tree (AST), and from the AST into materialized validator logic. In this step qualifiers become concrete constraint checks.
That validator logic runs against the submodel instance, checking both structural integrity (are all required elements present, in the right form?) and value constraints (are property values within their specified bounds?).

Outlook

twinfix 2.0 brings a substantial set of new validations across parts 1 and 5 of the AAS spec. But the most significant addition is the ability to check any submodel instance against its guiding SMT. We believe that this capability is a key requirement for real interoperability, not just a nice-to-have.

That said, this approach also shows that a number of official SMTs still contain errors: discrepancies between the PDF specification and the machine-readable template, violations of Part 1 of the standard, or plain modeling mistakes. Given the current efforts from IDTA to tighten SMT quality, we believe this is a matter of time, not a flaw in the approach itself.