Service and Support | Neoception® Digital Twin Infrastructure

Downloads & Documents

Name Relase Date Version Download Language
Deployment Guide
25.09.2024
01.00.00
EN
README-Connector
25.09.2024
01.00.00
EN

Frequently asked Questions

What is the Neoception® Digital Twin Infrastructure?

The Neoception® Digital Twin Infrastructure is an advanced solution that automates the creation of digital twins through standardized Asset Administration Shells (AAS). This technology allows organizations to efficiently manage and integrate data across various platforms.

How does the infrastructure ensure data security and integrity?

The infrastructure employs robust security measures, including multi-level authentication, data encryption, and compliance with international standards. These protocols ensure that sensitive information remains secure while maintaining the integrity of data throughout its lifecycle.

What are the implementation requirements for the Digital Twin Infrastructure?

Implementation typically requires an assessment of existing systems and infrastructure. Our team collaborates with clients to ensure a seamless integration process that aligns with their operational goals and technological capabilities.

AAS = Digital Twin?

The digital twin can be seen as the aggregation of all AAS with the same global asset ID, incorporating features like Web3 for data requiring clearance or proof of truth. For instance, consider two AAS for a single asset—one managed by the manufacturer and the other by the operator. Both may have a “current location” submodel, but the manufacturer’s submodel becomes outdated after the goods issue, while the operator’s “current location” submodel holds the accurate information. Web3 technology, in conjunction with AAS, can potentially resolve such discrepancies. AAS offers a comprehensive perspective on various aspects of a digital twin throughout the entire asset lifecycle.

IS AAS a clone of data?

Well, not necessarily. If a customer prefers and implements submodels with their own persistence, that’s a valid approach.

However, for many scenarios, it’s often more advantageous if the AAS retrieves data “ad-hoc”/”on-demand” from a system of records (e.g., SAP S/4, MES, maintenance- or asset management applications, …). In this context, the client makes use of the AAS “APIs”. The AAS, respectively its APIs, enable/act as a proxy for accessing the system of records.

Alternatively, there is the possibility of persisting certain submodels and/or properties, while others are retrieved on demand. The mechanisms can be employed to keep them in sync with the corresponding system of records.

Is AAS just a static format?

Yes and no. You can use an XML file with a semantic definition of structured elements to reflect an asset, which is called “AAS Type 1”, but there is also “AAS Type 2”, which uses a normalized API over a service-oriented approach (REST/JSON).

Additionally, there is “AAS Type 3”, representing machine-based communication using a standardized API. As a conclusion, a combination of different AAS types is valid. If you’re just using XML files or archiving them, this is just the beginning—think of it as an external output format.

Once your AAS systems are in place, you can choose an output format of your choice; the content remains the same, but the output format may vary based on your needs. We recommend using “AAS Type 2” whenever possible.

AAS only works with the submodels, standardized by the IDTA?

The more submodels the IDTA (Industrial Digital Twin Association e.V.) standardizes, the better; however, the standardized submodels are only one pillar of the whole concept, as the AAS metamodel and the AAS APIs are independent of standardized or IDTA-approved submodels.

By the way, there is a parallel between an OPC UA companion specification and an AAS IDTA submodel: similar to OPC UA companion specifications, AAS IDTA submodels do not encompass all the data that a machine can provide, leaving room for a machine builder to add additional information, especially to highlight individual capabilities or characteristics.

It’s likely that specific submodels will be developed for interacting with or integrating into specific business systems, also known as systems of records; for instance, there might be submodels designed for seamless interaction with a system like ERP, PLM, or MES, plant, client, process, and customizing-specific codes to align with the APIs of the legacy system.

AAS is just about master data?

The exchange of master data from the manufacturer to the operator or engineering partner serves as a foundational use case, crucial for enabling more intricate scenarios for digital twins; in certain industries, addressing this aspect is pivotal to filling a gap, reducing systematic errors, minimizing manual data management, and enhancing the overall quality of master data. Interacting with AAS, such as retrieving the phone number of the last service technician who worked on the machine, is just as essential as obtaining or maintaining the planned schedule (for maintenance or production) for the machine in the coming week.

AAS, along with its corresponding submodels, establishes connections to asset information through protocols like Modbus, MQTT, and OPC UA, enabling the representation of the most recently updated values that reflect the current state of a machine.

There is only one AAS for an asset?

Multiple AAS can exist for the same asset, both within a company and across different companies, with the unifying factor being the presence of a unique “global asset ID” that all AAS reference; however, the content, composition, and ownership of each AAS can vary.

Throughout an asset’s lifecycle, ownership may change, affecting the digital twin, which typically involves copying or sharing the digital twin, yet a trace of the digital twin may persist with the manufacturer. This imprint, for instance, can support tasks like updating master data from the manufacturer to the customer or facilitating data exchange between the customer and the manufacturer, as seen in cross-enterprise data exchange based on data spaces.

AAS only works on a centralized infrastructure

The AAS registry concept is established to pinpoint the endpoint for accessing an AAS or its submodels; therefore, by nature, AAS can be considered a “distributed document.” Furthermore, the AAS serves as a standardized exchange format for asset data, offering well-defined semantics, which promotes its utilization in decentralized environments, among various other functions.

How Can We
assist You?

Get in Touch with us for more information about our products.

We are ready to assist you with any questions.

Tel.

+49 621 776 4000

E-Mail

support@neoception.com