Problem

The increasing importance of software in digital manufacturing and the concept of digital twins highlights a significant gap in existing literature. While Asset Administration Shells (AAS) are becoming a standard for implementing digital twins, there is a lack of systematic analysis of software architectures that directly integrate software services into AAS. Current specifications and individual solutions do not offer a unified classification to guide which forms of software integration are possible and appropriate for different use cases.

Method

The authors propose a comprehensive classification for "software-heaviness" in AAS, structured into two independent categories. First, they classify AAS runtime environments into three stages: passive (file-based storage), server-based (utilizing a generic server runtime), and standalone (a self-contained executable application). Second, they introduce six levels of functional software integration (Lvl. 0 to Lvl. 5) within the AAS, starting from a static data model and progressing to fully embedded executable services. These architectural classifications are then systematically evaluated against functional software quality criteria (reliability, usability, performance, security, supportability, and transferability) and linked to typical digital manufacturing use cases.

Results

The study reveals that the architectural choices regarding AAS runtime environments and software integration levels have a profound impact on various software quality attributes. For instance, higher levels of software integration (Lvl. 3-5), where logic resides within the AAS, generally lead to increased complexity, demanding greater consideration for reliability, usability, and performance optimization, as well as heightened security awareness. In contrast, Lvl. 0 (static model) and Lvl. 5 (executable file) often demonstrate better transferability due to fewer external dependencies or self-contained logic. The analysis also underscores that the optimal architecture is highly dependent on the specific use case and business model. For example, Lvl. 1 and Lvl. 2 are suitable for external data retrieval with basic to parameterized requests, while Lvl. 3, Lvl. 4, and Lvl. 5 are more appropriate for scenarios requiring internal logic execution, such as agent systems or peer-to-peer AAS interaction. Lvl. 5 is recommended for customer deployment due to its ease of integration, whereas Lvl. 3 or Lvl. 4 might be preferable for internal development due to accessible source code.

Implications

This paper provides valuable guidelines for both academic researchers and industry practitioners involved in developing digital twins and AAS. The proposed classifications offer a systematic framework for understanding and designing software-heavy AAS, enabling more informed architectural decisions aligned with specific project requirements, quality criteria, and use cases. The findings highlight that the level of software heaviness should be adaptive, evolving with changing use cases. Future research should concentrate on developing methodologies to manage this lifecycle adaptability, thereby enhancing the role of AAS as a flexible and dynamic component within digital manufacturing ecosystems.