... | ... | @@ -27,3 +27,37 @@ It is the first BaSyx component to boot, as all others, including the AAS Server |
|
|
|
|
|
Light host 0-2 by default each create and upload four AAS to the AAS Server and host one lightSwitch submodule for each of them. In other words, it creates an AAS and a submodule for each of the four attached LEDs:
|
|
|
![Light Host #1 with LEDs](uploads/32c78bba4953f62dd2d9c395f606049b/lightHost.png)
|
|
|
|
|
|
Why doesn't a light host host exactly one light?
|
|
|
Frankly, to have a bit more to see and because it would be quite wasteful. It also demonstrates, how one additional device can send controls to multiple assets (here, LEDs), reducing costs of integration of existing Assets into an Industrie4.0-environment.
|
|
|
Changing the amount of lights present on a light host is quite simple, too and provides an easy entry point in understanding the Demo itself. More on that in the [documentation for the startup script](TODO).
|
|
|
|
|
|
## ESP32 Controller
|
|
|
|
|
|
The ESP32 Controller demonstrates how to integrate components utilizing a proprietary protocol into a BaSyx environment. ESP32 #0 through #2 are controlled via a simple proprietary protocol, [explained here](TODO), while the ESP32 Controller uploads their AAS and hosts the submodels doing the actual controlling.
|
|
|
|
|
|
## ProprietaryLight0-2
|
|
|
|
|
|
These are ESP32 microcontrollers, connected to single Red/green LEDs each and via WiFi to the rest of the network. They implement a proprietary protocol and are integrated into the BaSyx environment by the ESP32 Controller. The protocol is [explained here](TODO).
|
|
|
|
|
|
## Light Controller
|
|
|
|
|
|
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
|
|
|
|
|
|
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.
|
|
|
|
|
|
## 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, every time orchestrating the lights in turn.
|
|
|
|
|
|
## Demonstration Controller
|
|
|
|
|
|
The demonstration controller uses predefined calls to represent the condition of the demo kit and allows for user interaction with the Light Animator and Light Controller.
|
|
|
|
|
|
## AASX Server
|
|
|
|
|
|
The AASX Server hosts an [AASX Server](https://github.com/admin-shell-io/aasx-server), as provided by the [Industrial Digital Twin Association e.V.](https://idtwin.org/). More specifically the `blazor` variant. As of now the AASX Server and the BaSyx environment are incompatible. It is here, to have it as part of the Demo for future evaluation of compatibility and eventual integration.
|
|
|
Slightly more detail on compatibility [here](BaSyx-Adventures#compatibility-with-adminshellios-aasx-server). |