Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "BaSyx / Documentation / API / Submodel"
Line 2: | Line 2: | ||
Amongst the official attributes of Submodels, BaSyx defines aggregates called data elements, operations and events. These aggregates are used to structure official SubmodelElements (Property, ReferenceElement, Event, Operation, etc.) into groups of same functionality, i.e. | Amongst the official attributes of Submodels, BaSyx defines aggregates called data elements, operations and events. These aggregates are used to structure official SubmodelElements (Property, ReferenceElement, Event, Operation, etc.) into groups of same functionality, i.e. | ||
− | + | * DataElements as value-based properties | |
− | + | * Operations as callable methods | |
− | + | * Events as collection for events' information model. | |
Additionally, BaSyx follows a distributed approach, i.e. Submodels may be deployed in distributed infrastructure. Asset Administration Shells only refer to their Submodels by terms of a reference. They do not know about their Submodels' content but they know the way to it. On the other side, Submodels may reference their Asset Administration Shells as well via a parent attribute. | Additionally, BaSyx follows a distributed approach, i.e. Submodels may be deployed in distributed infrastructure. Asset Administration Shells only refer to their Submodels by terms of a reference. They do not know about their Submodels' content but they know the way to it. On the other side, Submodels may reference their Asset Administration Shells as well via a parent attribute. | ||
− | In order to access the Submodel's content, BaSyx defines Submodel Service Providers. These Service Providers are used to make, e.g. data elements or operations, accessible by defining | + | In order to access the Submodel's content, BaSyx defines Submodel Service Providers. These Service Providers are used to make, e.g. data elements or operations, accessible by defining GET- and SET- resp. MethodCalled-Handler. Initially, on an abstract level, there is no technology binding necessary to build or use a service provider. Later of course, when starting the runtime, BaSyx provides highly generic technology bindings which can be used to grant access to the Submodel's content via chosen technology (HTTP/REST, OPC UA, BaSyx native). |
− | In a nutshell, BaSyx Submodel Service Providers enable access to Submodels' content. A Submodel Service Provider needs to implement the generic Submodel Service Provider interface that is exemplary described on this page in HTTP/REST technology. The Submodel Service Provider enables access to data elements, operations and events. The BaSyx Submodel Service Provider may provide a façade hiding numerous (proprietary) data sources, e.g. SQL databases, XML configuration files, AutomationML, Hashmaps, Lambda, XQuery and many more. Furthermore, the BaSyx SDK enables creation of custom Submodel Service Providers. This is done by deriving from abstract BaSyx Service Provider | + | In a nutshell, BaSyx Submodel Service Providers enable access to Submodels' content. A Submodel Service Provider needs to implement the generic Submodel Service Provider interface that is exemplary described on this page in HTTP/REST technology. The Submodel Service Provider enables access to data elements, operations and events. The BaSyx Submodel Service Provider may provide a façade hiding numerous (proprietary) data sources, e.g. SQL databases, XML configuration files, AutomationML, Hashmaps, Lambda, XQuery and many more. Furthermore, the BaSyx SDK enables creation of custom Submodel Service Providers. This is done by deriving from abstract BaSyx Service Provider interfaces. |
The BaSyx Submodel Service Provider in HTTP/REST technology is defined as follows: | The BaSyx Submodel Service Provider in HTTP/REST technology is defined as follows: |
Revision as of 12:57, 11 June 2019
"A Submodel defines a specific aspect of the asset represented by the Asset Administration Shell. A Submodel is used to structure the virtual representation and technical functionality of an Administration Shell into distinguishable parts. Each Submodel refers to a well-defined domain or subject matter. Submodels can become standardized and thus become submodels types. Submodels can have different life-cycles." (Details of the Asset Administration Shell, 2018, p. 46, [1])
Amongst the official attributes of Submodels, BaSyx defines aggregates called data elements, operations and events. These aggregates are used to structure official SubmodelElements (Property, ReferenceElement, Event, Operation, etc.) into groups of same functionality, i.e.
- DataElements as value-based properties
- Operations as callable methods
- Events as collection for events' information model.
Additionally, BaSyx follows a distributed approach, i.e. Submodels may be deployed in distributed infrastructure. Asset Administration Shells only refer to their Submodels by terms of a reference. They do not know about their Submodels' content but they know the way to it. On the other side, Submodels may reference their Asset Administration Shells as well via a parent attribute.
In order to access the Submodel's content, BaSyx defines Submodel Service Providers. These Service Providers are used to make, e.g. data elements or operations, accessible by defining GET- and SET- resp. MethodCalled-Handler. Initially, on an abstract level, there is no technology binding necessary to build or use a service provider. Later of course, when starting the runtime, BaSyx provides highly generic technology bindings which can be used to grant access to the Submodel's content via chosen technology (HTTP/REST, OPC UA, BaSyx native).
In a nutshell, BaSyx Submodel Service Providers enable access to Submodels' content. A Submodel Service Provider needs to implement the generic Submodel Service Provider interface that is exemplary described on this page in HTTP/REST technology. The Submodel Service Provider enables access to data elements, operations and events. The BaSyx Submodel Service Provider may provide a façade hiding numerous (proprietary) data sources, e.g. SQL databases, XML configuration files, AutomationML, Hashmaps, Lambda, XQuery and many more. Furthermore, the BaSyx SDK enables creation of custom Submodel Service Providers. This is done by deriving from abstract BaSyx Service Provider interfaces.
The BaSyx Submodel Service Provider in HTTP/REST technology is defined as follows:
GET | /aas | Description
|
GET | /aas/submodels | Description
|
POST | /aas/submodels | Description
|
GET | /aas/submodels/{subModelId} | Description
|
DELETE | /aas/submodels/{subModelId} | Description
|
GET | /aas/submodels/{subModelId}/properties | Description
|
POST | /aas/submodels/{subModelId}/properties | Description
Response codes
|
GET | /aas/submodels/{subModelId}/operations | Description
|
POST | /aas/submodels/{subModelId}/properties | Description
|
GET | /aas/submodels/{subModelId}/properties/{propertyId} | Description
|
PUT | /aas/submodels/{subModelId}/properties/{propertyId} | Description
|
DELETE | /aas/submodels/{subModelId}/properties/{propertyId} | Description
Parameter
|
GET | /aas/submodels/{subModelId}/properties/{operationId} | Description
|
POST | /aas/submodels/{subModelId}/properties/{operationId} | Description
|
DELETE | /aas/submodels/{subModelId}/properties/{propertyId} | Description
|
BaSyx project links: Project BaSyx main wiki page | What is BaSyx? | BaSyx Developer Documentation |