Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
The Asset Administration Shell (AAS) is the standardized digital representation of the asset, corner stone of the interoperability between the applications managing the manufacturing systems. AAS identifies the Administration Shell and the assets represented by it, holds digital models of various aspects (submodels) and describes technical functionality exposed by the Administration Shell or respective assets. Core elements of AAS are the metamodels and serializations, APIs, and security.
Eclipse FA³ST aims to provide an implementation of the re-active (or type 2) Asset Administration Shell according to the AAS specification.
This includes the following aspects:
- AAS APIs, especially AAS & Submodel API, Repository API, and Registry API
- AAS metamodel as defined in Part 2
- JSON De-/Serialization including all content modifiers such as $value, $metadata, or $reference
- Asset Synchronization
Implementation of the metamodel as defined in AAS specification Part 1 as well as basic de-/serialization (i.e. content modifier $normal) are out-of-scope of this project. This functionality will be provided by re-using Eclipse AAS4J.
Eclipse FA³ST aims to provide an implementation of the re-active (or type 2) Asset Administration Shell according to the Asset Administration Shell (AAS) specification by Plattform Industrie 4.0. In contrast to other implementations such as Eclipse BaSyx, Eclipse FA³ST will focus on the deployment at edge-level rather than cloud-level, meaning that its primary focus will be on asset connectivity rather than scalability. Other expected key features are
- Easy to set-up & use
- Open architecture which enables easy customization and extension
- Implementation of API for HTTP and OPC UA
- Protocol-agnostic synchronization with assets
- Usage via command-line interface, docker container, and as embedded library
The Eclipse Foundation provides a professional environment (governance, licensing, intellectual property management) for the future development of Eclipse FA³ST. These advantages facilitate the usage of an open source, extensible ecosystem and helps the software to gain more visibility in the AAS community and beyond.
Furthermore, Eclipse FA³ST nicely integrates with existing Eclipse projects in the AAS domain such as Eclipse BaSyx and Eclipse AAS4J that are already part of the Eclipse Digital Twin Top-Level Project.
Currently the project exists in two separate repositories under the FraunhoferIOSB organization on Github which are considered as initial contribution to this project
We intend to create a new project-related Github organization (as the current one is affiliated with Fraunhofer) and transfer the repositories there.
For this project we propose to use Eclipse FA³ST instead of “FA³ST - Fraunhofer Advanced Asset Administration Shell Tools for Digital Twins” which is currently used. As there are already other software projects using the term "fast" (or some variation of it) as name we suspect that this might potentially cause problems. If this should be the case we suggest the following alternative titles for the project
- Eclipse FAAST
- Eclipse FAST4AAS
Another potential legal issue might be the logo which we would like to either keep or replace with something similar (e.g. adding "Eclipse" in there). The current logo has been designed by Fraunhofer IOSB (the developers of the current FA³ST project).
Eclipse FA³ST and its involved parties intend to move to Eclipse as soon as possible. The plan is to release v1.0 of the software under the existing FA³ST project and then transfer the repositories to the new Eclipse FA³ST project and continue development there.
Eclipse FA³ST wants to build an open source community in Eclipse to coordinate the building of an extensible ecosystem in which manufacturers and suppliers, including the providers of applications, platforms and infrastructure, can all participate equally.
Concrete next steps will include features like generic handling of SubmodelTemplates, i.e. to manage time series data within an AAS according the the SubmodelTemplate TimeSeriesData specification.