Home

Welcome to the simulation-bridge wiki!

Feature Roadmap

• The agents and simulation bridge are RabbitMQ / MQTT clients. The brokers of these protocols routinely save messages until they are delivered to at least one client. Thus we are left with old, useless simulation requests sent by inactive clients reaching the broker / agent. These requests are no longer valid. It is best to throw away all the old requests. How to do this reliably is a question. It could be based on timestamps but they are not completely reliable.
• Have a flow control mechanism at agents and the bridge. Otherwise, requests pile up. Perhaps having a FIFO queue of small size (say 2 to 5) should make the situation manageable
• Plan to develop an agent that integrates FMI standards, enabling interaction and control of FMU models through the simulation bridge. Use FMpy for this task.
• Improve Input Management
  Refactor the input handling mechanism to support both large-scale and streaming input data more efficiently.
  A possible solution includes:
  • Allowing clients to pass a stream source for real-time input streaming. (this is partially supported in Matlab Agent but not in other components)
  • Supporting references (e.g., URLs or object storage paths) to external static datasets for large batch inputs, instead of embedding all data in the request body.
• Add Granularity Point for Output Validation and Transformation (Validate and transform simulation outputs before they are sent to the DT. In production environments, raw or full simulation results should not be passed directly, only selected and properly configured outputs should be forwarded)
• Evaluate benefits of using asyncio in protocol adapters (MQTT, RabbitMQ, REST) [Event loop-Natural fit for sim-bridge]
• Validate sender for the signals (Blinker)

Security Checklist

• All clients use same queues for requests and responses. All clients can see others responses. This situation might be true for all protocols except REST.
• Is there DoS problem here?
• What are the ways of E2E authenticating and securing comm between client, bridge and agents?
• Since signals are global, can a rogue comm protocol plugin spy on all the messages?
• Is there a possibility of arbitrary code execution at agents (from different directory or by swapping contents of files)?
• The simulation agents and probably bridge are vulnerable to DoS attacks.
• What happens when an agent / bridge deliberately alters the contents of yaml messages (for example, alter request_id / output variables etc.)?
• It is good to have a list of approved clients and agents for simulation bridge. The problem here is to verify the verification of the claimed identity. The only way could be PKI. In any case, PKI is needed for E2E encryption between clients, simulation bridge and agents. So it is probably a good way to go.

Examples

• The examples of agents require simulation bridge for them to work. If the client scripts of examples can work without simulation bridge, the demonstrations become easier.
• The current --generate-project flag is not copying the functional simulation.yaml for the examples. This should be done.