Hi Tim,
welcome to this coolest mailing-list the Apache Software Foundation has :-)
Just let me sum up how I understood your question:
- You wanted to know opinions on how a frontend should communicate with the
matching backend?
I have to admit that I would sort of expect the backend and frontend for a
simulation module to be very tightly coupled.
Why not let the implementor(s) decide how to do it?
Probably it would be good to have a standard rest API for manipulating the
context of a simulation module, but ho that module's UI interacts with the
backend, I wouldn't want to enforce anything here.
Using a universal simulation context (memory & IO slots) would provide a
universal rest API, but I doubt that it is necessary to force anyone to do it
in a certain way as the universal context API could nicely Co-Exist with any
other API.
UI developers could either just use that universal API or provide a custom one,
if this is more convenient for them.
So from my side, I'd suggest you do what you think is better.
Thank you for contributing :-)
Chris
Am 15.10.19, 13:21 schrieb "Tim Kläsener" <tim.klaese...@codecentric.de>:
Hi everyone,
I'm currently working on creating a frontend and REST interface for
the PLC Simulator to control the different simulation modules for
testing and presentation purposes.
One question came up this morning with Chris about whether the backend
should be more low level or high level.
To clarify, the simulated PLC modules are basically just some objects
with metadata (name etc.), some properties (basically a map with
key/value pairs) and optionally some business logic and the question
asked is how to best interact with them.
Let me explain the question by the example of a simplified water tank
with the following three properties:
- VALVE_IN (boolean: true = open)
- VALVE_OUT (boolean: true = open)
- FILL_LEVEL (int: 0-100 percent)
High-level API
-------------------
The high-level API would allow the simulation modules to expose the
actions or states to be performed with them, e.g. you would call a
REST endpoint like "PUT /simulator/water_tank_1/state/fill" and then
the internal logic of the simulation module would change the
properties of the water tank accordingly over time.
Advantages:
- Communication with the simulation modules via a defined set of
actions, therefore the frontend wouldn't have to understand the
meaning of individual properties.
- Business logic in the simulation modules is based on defined set of
actions, i.e. they don't have to look at all the different properties
to derive how to properly simulate the real PLC's behaviour.
Disadvantages:
- Level of abstraction over the raw values, harder to simulate
specific or even 'dangerous' states.
Low-level API
------------------
The low-level API would modify the properties of the water tank
directly, e.g. you would call a REST endpoint like "PUT
/simulator/water_tank_1" with a payload of
"{
VALVE_IN: false,
VALVE_OUT: true,
FILL_LEVEL: 50
}"
(or only some of the values).
Advantages:
- All properties are exposed: You could interact with everything and
also construct potential invalid combinations to cover more cases.
- Probably closest to how interfaces interact with real PLCs.
Disadvantages:
- To create complex business logic, any user of the API/the frontend
would have to know how a business flow (e.g. "Fill water tank until
it's full") translates into changes of the individual properties over
time.
- Alternatively, the simulation backend would have to react to any
combination of the property values to figure out what to do.
Personally, I would go for a combination of the two approaches, i.e.
allow the mutation of the raw values from the low-level approach to be
able to create the full set of valid and invalid states in the
simulator - BUT this does not trigger any business logic (like setting
VALVE_IN to true slowly raising the FILL_LEVEL). The complex business
logic should only be triggered via a higher-level API to keep the
complexity in the front-end low.
Any opinions on the matter?
Cheers and nice to digitally meet you all
Tim
(sorry, another one ;-) )
