Digital Twins Gain Integrated Software for Smarter Factories

Researchers are increasingly focused on the Asset Administration Shell (AAS) as a key technology for realising digital twins within manufacturing environments. Carsten Ellwein, David Dietrich, and Jessica Roth, all from the Institute for Control Engineering of Machine Tools (ISW) at the University of Stuttgart, alongside Rozana Cvitkovic from Blue Yonder GmbH and Andreas Wortmann from ISW, University of Stuttgart, present a systematic analysis of software architectures designed to integrate software services directly into the AAS. This collaborative work addresses a significant gap in current literature, moving beyond individual solutions to classify and evaluate these architectures according to software quality and their applicability to typical manufacturing use cases. The resulting framework offers valuable guidance for both academic researchers and industry practitioners seeking to implement robust and effective software-heavy AAS solutions.

Over 60% of modern manufacturing relies on complex software systems, demanding a new approach to digital twins. Current approaches to software-heavy AAS implementations are fragmented, lacking a systematic evaluation of software architectures.

This research addresses this gap by classifying architectures based on software quality and suitability for typical manufacturing applications, offering a valuable interpretation guideline for both academic researchers and industry practitioners. Defining the appropriate level of software integration within an AAS is not straightforward. Digital twins exist on a spectrum, ranging from simple digital models to fully integrated systems capable of real-time synchronization with their physical counterparts.

A digital shadow automatically mirrors changes in a physical object, while a true digital twin achieves complete integration and automated data flow. Successfully implementing advanced digital manufacturing use cases demands a software component within the twin that can access and interpret a thorough information model of the production environment.

However, current AAS specifications primarily focus on data representation and application programming interfaces, with limited guidance on managing complex software or services within the shell itself. Several proof-of-concept implementations have begun to embed software directly into the AAS, but a lack of established concepts hinders wider adoption.

By introducing a classification of ‘software-heaviness’, considering both the runtime environment and functional components, this work proposes a pathway toward more structured development of AASs. The research derives potential architectures, evaluating their impact on key software quality criteria and identifying appropriate use cases. For example, a preprocessing stage for incoming asset data or the execution of actions originating from within the AAS become viable possibilities.

This structured approach enables the creation of AASs tailored to specific needs, aligning with standard specifications and unlocking new potential in digital manufacturing. Six distinct levels were defined to categorise AAS implementations, ranging from purely descriptive models to systems incorporating complete executable services. Level 0.0, the baseline, consists solely of the AAS model and associated data, lacking any functional services or automated connection to a physical entity.

Progressing to Level 1, services were integrated to establish a connection between the AAS and its corresponding physical object, requiring a runtime environment for operation and enabling simple API requests. Subsequent levels introduced increasing complexity. Level 2 allowed for parameterised requests and complex queries via interfaces like REST or OPC-UA, demanding the model possess knowledge of these interfaces for correct processing.

At Level 3, functionality moved directly inside the AAS, with service logic implemented through scripts, containers, or regular expressions interpreted and executed by the system. Level 4 extended this by utilising source code for service description, enabling greater complexity and opportunities for performance optimisation. Reaching Level 5, the AAS fully owned the complete service as an executable file, permitting direct execution without prior interpretation or compilation.

For structuring these components, the research employed the 5D model, a framework for representing the various dimensions of an AAS. Beyond defining these levels, the study assessed their impact on key quality criteria, including reliability, usability, performance, security, supportability, and transferability, all viewed from the perspective of a software provider delivering AAS instances to customers.

Higher levels demanded greater consideration of potential failure points and data exchange issues, unlike simpler implementations. Once the levels of software integration were established, a systematic evaluation of these architectures was undertaken using functional quality criteria aligned with ISO/IEC 25000 standards. By focusing on the AAS itself, the initial levels, 0.0 and 0.1, were deemed inherently reliable due to their lack of processing logic.

As software complexity increased from Level 2 onwards, the potential for issues affecting data exchange and system functionality necessitated a more thorough assessment of reliability. At each level, the research considered the tolerance to failure and recovery capabilities of the system. For example, AASs at Levels 0.3 to 0.5, containing complex software components, bore greater responsibility for processing logic.

The methodology specifically evaluated these criteria from the viewpoint of a software provider, such as a component manufacturer offering AAS instances alongside physical assets. This perspective informed the analysis of each level’s implications for maintenance, security, and overall system performance. The research team carefully considered how the increasing software ‘heaviness’ of the AAS impacted the workload and responsibilities of the provider.

Comparative assessment of system architecture levels against ISO/IEC 25000 standards

Analyses of six system architectures, categorised as Lvl0.0 through Lvl0.5, reveal distinct performance characteristics when assessed against ISO/IEC 25000 quality criteria. Reliability assessments show Lvl0.0 receives partial consideration, while Lvl0.1 is deemed unsuitable, and levels Lvl0.2 to Lvl0.5 are strongly considered for implementation. Security considerations highlight potential risks associated with Lvl0.4, specifically runtime code injections, recommending its use primarily for research or testing purposes.

Conversely, Lvl0.5, employing a black-box approach, is favoured for customer-side deployment due to its simplified integration and bundled dependencies. Supportability assessments show that accessible source code in Lvl0.3 and Lvl0.4 simplifies maintenance and customisation for internal provider use. Transferability is limited at Lvl0.1 due to system-specific parameters requiring adjustment for deployment in different environments.

The usefulness of each architecture is heavily dependent on the specific manufacturing use case. Retrieving data from a customer’s system presents challenges at Lvl0.1, requiring substantial effort to establish parameterised API endpoints for each AAS. Lvl0.2’s single interface markedly reduces this effort, improving maintainability and scalability.

Integrating logic within the AAS, as seen in Lvl0.3 to Lvl0.5, proves beneficial when data consolidation from multiple sources is unnecessary. At these levels, standard algorithms can be extended with custom logic, although Lvl0.3 and Lvl0.4 offer transparency through accessible source code, while Lvl0.5 operates as a closed system.

Evaluating software architectures for secure digital manufacturing twins

Once a futuristic vision, the idea of fully digitised manufacturing is rapidly becoming a practical necessity. For years, modelling the physical components was achievable, yet representing the behaviour of the controlling software, and ensuring its security, presented a considerable hurdle.

This research doesn’t offer a single solution, but instead a systematic way to evaluate different software architectures within the AAS framework, judged against established quality standards and realistic factory scenarios. The implications extend beyond simply improving software integration. By providing a structured approach to building ‘software-heavy’ AAS, manufacturers can move closer to genuinely adaptive production systems.

Instead of rigid automation, these systems could reconfigure themselves based on real-time data and changing demands, offering a degree of flexibility previously unattainable. A reliance on software introduces new vulnerabilities, and the analysis of security implications, like protection against malicious interference, remains a critical area for development.

The study categorises architectures, but doesn’t prescribe a ‘best’ solution, recognising that the optimal design will depend on the specific application. Wider adoption requires standardised interfaces and data formats, something the industry continues to refine. Future work could explore the integration of artificial intelligence and machine learning within the AAS, allowing for predictive maintenance and self-optimisation. The next step may be designing entirely new manufacturing processes around the capabilities of these intelligent digital twins.