... | ... | @@ -53,7 +53,8 @@ See [here](implementation/Proprietary-Light-code-walkthrough) for the documentat |
|
|
|
|
|
The light controller looks up all available lights registered in the registry and upon invocation of exposed operations sends out it's own requests to the individual lights, illustrated below:
|
|
|
|
|
|
TODO
|
|
|

|
|
|
For simplicity, the Upload and registration of the AASs of the participants is not shown here. You can click on the Image to enlarge it.
|
|
|
|
|
|
The invokation happenes through the BaSyx API, directly to the exposed endpoint either on the AAS Server (which then forwards it) or to the Submodel hosted on the light controller directly.
|
|
|
|
... | ... | @@ -63,7 +64,10 @@ In the [AASX-Branch](https://gitlab.hrz.tu-chemnitz.de/vws-demo/vws-spielwiese/- |
|
|
## Light Animator
|
|
|
|
|
|
While one could argue the Light Controller already constitutes a Type 3 AAS, Adding another makes sure that we really have a Type 3 AAS in the Demo.
|
|
|
The light animator looks up all available light controllers (which is usually just one) and orchestrates it to cycle between different states, making it orchestrate the lights in turn.
|
|
|
The light animator looks up all available light controllers (which is usually just one) and orchestrates it to cycle between different states, making it orchestrate the lights in turn:
|
|
|
|
|
|

|
|
|
For simplicity, the Upload and registration of the AASs of the participants is not shown here. Also only one red and green light each is represented. You can click on the Image to enlarge it.
|
|
|
|
|
|
See [here](implementation/Light-Animator-walkthrough) for the implementation documentation of the Light Animator.
|
|
|
|
... | ... | |