AAS Editor Overview

[aaronzi]

As a BaSyx user,
I want to create, edit and delete Asset Administration Shells in BaSyx without having to use 3rd party tools.

Rules

• Use Vue [1], Vuetify [2] in the AAS Web UI [4].
• The editor should be disableable via an env variable [5,6,7].
• The editor should be available under the AAS Editor menu [3] in the AAS Web UI
• BasicEvent and Capability SubmodelElements are out of scope
• Authorization is out of scope
• No BaSyx V1 support

Acceptance Criteria

• Environment variable to disable the editor mode (should work at container runtime -> docker run)

All Subtickets have been implemented:

• Create/Edit/Delete AAS #10
• Create/Edit Asset Information
• Create/Edit/Delete Submodel
• Create/Edit/Delete SubmodelElementCollection
• Create/Edit/Delete SubmodelElementList
• Create/Edit/Delete Property
• Create/Edit/Delete MultilanguageProperty
• Create/Edit/Delete File
• Create/Edit/Delete Blob
• Create/Edit/Delete Range
• Create/Edit/Delete Entity
• Create/Edit/Delete Operation
• Create/Edit/Delete ReferenceElement
• Create/Edit/Delete RelationshipElement
• Create/Edit/Delete AnnotatedRelationshipElement
• Create/Edit/Delete ConceptDescription
• Create/Edit/Delete Qualifier

Entry Points

[4] https://github.com/eclipse-basyx/basyx-applications/blob/main/aas-gui
[5] https://github.com/eclipse-basyx/basyx-applications/blob/main/aas-gui/Frontend/aas-web-gui/entrypoint.sh
[6] https://github.com/eclipse-basyx/basyx-applications/blob/main/aas-gui/Frontend/aas-web-gui/src/store/EnvironmentStore.ts
[7] https://github.com/eclipse-basyx/basyx-applications/blob/main/aas-gui/Frontend/aas-web-gui/public/config.json

Risks and Assumptions

The ticket is divided into multiple sub-tickets for each type of meta-model element (e.g.) SubmodelElements

References and Notes

[1] https://vuejs.org/
[2] https://vuetifyjs.com/en/
[3]

ℹ All API endpoints (implemented in the basyx-java-server-sdk) needed for this feature should already be implemented. Only front-end changes are necessary!

ℹ Some aspects of the editor mode are already implemented:

• The menu entry already exists
• Editing just the value of almost all SubmodelElements is already possible
• Deleting entire shells already works

Dependencies and Blockers

Every ticket for each SubmodelElement can be implemented independently.
There are no dependencies.
The AAS (+ Asset Information) and Submodel tickets should be implemented first.

[mrentsch65]

Hi Aaron,
the above text Is not quite clear about it, but I understand that a dedicated "AAS-Editor"-Plugin is desired?
To make the desired apperance clearer, could you provide some UI-Screenshots (i.e. modified with paint)?
How would be the architectural recommendation regarding distribution of functionalities?
What should be in the frontend, what in the backend? Are new API-Endpoints required?
Can you provide links to "The AAS and Submodel Tickets" mentioned above?
Best Regards, Markus

[aaronzi]

Hi Markus,

yes, this will follow. I just copied the overview ticket from our internal sprint planner here.
There are 10 more tickets to come including actual details about what this feature will look like and what the entry points are. I'm planning to add those next week.

By the way, I also created a GitHub project for the AAS UI and a view for the editor feature. You can find that here: https://github.com/orgs/eclipse-basyx/projects/1

Best regards,
Aaron

[mrentsch65]

All API endpoints (implemented in the basyx-java-server-sdk) needed for this feature should already be implemented. Only front-end changes are necessary!

Hi Aaron,
two points:

1. For new functionalites like "generate a AAS or a submodel out of something that is passed from the frontend to the backend", suitable API endpoints are required.
2. And when for example file attachements or -references and links are added in the AAS, I believe they should be checked for validity. This would be rather a functionality in the backend, right?

Do we already have something in that direction?

Best Regards,
Markus

[mrentsch65]

One more thing: Could you please add links to the subtickets in the "Acceptance criteria" list above? Otherwise navigation is quite elaborate.

[aaronzi]

Hi Markus,
Regarding your two points:

1. I will add the appropriate API endpoints to the tickets for each sub-feature.
2. Can you please clarify what you mean by this? What kind of validity are we talking about? The backend generally checks if a request is valid. When it comes to validating e.g. valueTypes, this should be handled in the frontend. For example, a text field with a valueType of dateTime should validate that the user has entered a dateTime string, and throw an error if they haven't.

Sorry that I did not have time to complete this and only added the first two tickets. Creating them is a lot of work. The tickets I've done internally before didn't need to be this detailed.

I hope to be able to add a few more in the next two weeks and gradually add the rest. I will also improve the links between them.

Best regards,
Aaron

[mrentsch65]

Hi Aaron,
I specifically think of the use case "Attaching a file to the AAS" with a certain Mimetype. To prevent adding wrong file formats (i.e. by renaming the file ending), it would be good to have some basic validation function whether the file content really matches the MimeType. I agree, that this rather simple case could even be handled in the frontend. But what happens for more complex cases, i.e. creating an AAS or a SM based on the contents of another file? I believe something like that must be implemented in the backend.