Preserve AAS-/SM-Id of original AAS/SM after cross enterprise AAS-/SM-transfer with modification of Ids

[HeinrichChristian]

Is your feature request related to a problem? Please describe.
At the SPS 2024, we have implemented the use case “Transfer Of Owner Ship”\“Cross Enterprise AAS Transfer”.
An AAS shell including the submodels is transferred from the manufacturer's AAS environment to the customer's AAS environment.
The customer has the option of enriching this AAS with new information and making it available to its customers. However, this means that the customer is obliged to change the AAS ID and submodel ID.
If the AAS ID and submodel ID are changed, the reference to the manufacturer's AAS is lost. This means that it is no longer possible to access the manufacturer's AAS or to access the delivery status.

Describe the solution you'd like
A property such as “CopyFrom”, “OriginalID” or similar would be required at shell and submodel level to enter the manufacturer's AAS ID and submodel ID here.

Describe alternatives you've considered
The attribute "derivedFrom" in the metamodel is used to explicitly state a relationship between assets that are being derived from one another.
Other relationships are not explicitly supported by the metamodel of the Asset Administration Shell, but they can be modelled via the "RelationshipElement" submodel element type.

[seicke]

Dear Christian,

what about using the templateId from the AdministrativeInformation, which is available for the AAS as well as its Submodels?
https://aas-core-works.github.io/aas-core-meta/v3/AdministrativeInformation.html

BR Sebastian

[chborntraeger]

Hello Sebastian,
I think using the administrative information as a parent element is a good idea. However, an additional field for “CopiedFrom” should actually be added here. The previous fields all already have a precisely specified meaning. TemplateId as you mentioned has the special meaning that it indicates which template led the creation of the submodel/AAS.
If a new field is introduced, the meaning could be specified precisely. Using the TemplateId would cause the information that is actually in this field to be lost.

Regards,
Christina

[Hendrik-Mueller-Overzone]

Hello everyone,

I too would encourage the addition of a field like "CopiedFrom". In one of our projects we have the case, that we "move" an AAS from a repository to an edge device. But since the device wont be able to remove the AAS from the original repo, we have to generate new IDs to avoid collisions.
In that moment, the reference to the original AAS is lost.

A field like "CopiedFrom" could allow e.g. for pulling updates from the original AAS.

Regards,
Hendrik

[alexgordtop]

Hello together,
We've had a very interesting discussion at the: https://arena2036.de/de/vws4ls/veranstaltungen/aas-netzwerktreffen-feb-25

The discussion was about the GlobalAssetId and that there will most probably be multiple concrete AAS.IDs - for the different stakeholders in the coarse of the lifecycle phases.

A member of JTC24 explicitly raced the question about traceability for auditing / reviewing the information flow along the lifecycle phases.

As of now, there is now semantically clear answer to this question - since the templateId has another semantic - and RelationshipElements are only available for Submodels, not Shells.

Because of that I would support the idea of having an optional, explicit "copiedFrom" attribute in AdministrativeInformation, so that the source of information can be clearly documented - and machine readable be evaluated.

[BirgitBoss]

2025-02-25 TF Metamodel of Workstream AAS Spec

Decison Proposal: do not incoporate to V3.1, needs more discussion

• in IEC 63278 "copyFrom" it is called "take over" (e.g. from one company to another company)
• "derivedFrom" was introduced for "Take over" use case and not (only) for type-instance relationships. However, "derivedFrom" is only available for complete AAS not for single Submodels
• So far no best practices for using "derivedFrom" are existing covering
  • which kind of information can be changed, which kind of information needs to stay as it is
  • is is a "CopyOf" or a "CopyFrom" with changes?
• what about usage policies, licenses when copying data from another company etc.?
• should it be part of AAS or is it a separate system containing such information?