Hi Chris,
Thanks for the warm welcome and your thoughts on the matter!
Like you said, both approaches can co-exist with one another,
therefore starting with the low-level approach is probably the
straightforward thing to do. My main initiator for the question was
whether the users (through the frontend) are technical enough to
individually manipulate the memory & IO slots or if the thing they're
actually interested in is the "business" use-case, e.g. "Fill the
water tank" or "Move the elevator to level 5".
Usually I'd try to encapsulate the low level technical details of the
domain but as in this case the domain itself is a technical thing, it
might actually make sense to open it up for any manipulation.
Let me take another look at your suggestions and the upcoming comments
for the new context model in the other email and then I'll adjust
accordingly.
Cheers,
Tim
On Tue, 15 Oct 2019 at 14:32, Christofer Dutz <christofer.d...@c-ware.de> wrote:
>
> 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 ;-) )
>
>
