You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MQTT has no inherent concept of client/server, or what we call site/supervisor in RSMP.
Currently the idea is to specify that a site and a supervisor must implement different things on top of MQTT.
But what if we remove the basic distinction between site/supervisor, and instead say it's all just clients? We could then instead rely on modules to specify the functionality that different clients support.
This might make it easier to support site-to-site and center-to-center communication.
Consider a setup where you have to supervisor systems, and two TLC's.
Here the TLC would implement the TLC module, and perhaps also the Traffic Data module if they can collect data.
Now suppose you want the two supervisors systems to communicate, and also the two TLCs. Since all comunication goes through the broker, the network topology is still the same. But conceptualle there is now site-to-site and center-to-center communication:
For center-to-center communication, we would define a Center module, or perhaps something more specific ilke Scenario and Analysis. One or both of the centers would implement this module, so the other center can do things like e.g. request a priority or a traffic management scenario, or fetch traffic data analysis data.
Essentially the idea is to make functionality and API's modular, and allow any client to implement any module.
I think it could simplifies things to not think of sites vs. supervisor, but instead just clients which can implement any suitable set of modules.
Note that you can (and should) setup access control on the broker to manage which clients can publish to which topics, and thus which functionality they can access in other clients.
I'm wondering if we should define modules as pairs, e.g. a TLC Site module and a TLC Supervisor module. Is it relevant to know that a traffic management systems can control TLCs? For example, when you send a command to change signal plan, you get a response (possible an error) and you should now how to receive and deal with that. On the other hand, if such reponse handling can be made generic enough, we might not need such "supervisor" modules.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
MQTT has no inherent concept of client/server, or what we call site/supervisor in RSMP.
Currently the idea is to specify that a site and a supervisor must implement different things on top of MQTT.
But what if we remove the basic distinction between site/supervisor, and instead say it's all just clients? We could then instead rely on modules to specify the functionality that different clients support.
This might make it easier to support site-to-site and center-to-center communication.
Consider a setup where you have to supervisor systems, and two TLC's.
We would define a list of modules, e.g:
Here the TLC would implement the TLC module, and perhaps also the Traffic Data module if they can collect data.
Now suppose you want the two supervisors systems to communicate, and also the two TLCs. Since all comunication goes through the broker, the network topology is still the same. But conceptualle there is now site-to-site and center-to-center communication:
For center-to-center communication, we would define a Center module, or perhaps something more specific ilke Scenario and Analysis. One or both of the centers would implement this module, so the other center can do things like e.g. request a priority or a traffic management scenario, or fetch traffic data analysis data.
Essentially the idea is to make functionality and API's modular, and allow any client to implement any module.
I think it could simplifies things to not think of sites vs. supervisor, but instead just clients which can implement any suitable set of modules.
Note that you can (and should) setup access control on the broker to manage which clients can publish to which topics, and thus which functionality they can access in other clients.
I'm wondering if we should define modules as pairs, e.g. a TLC Site module and a TLC Supervisor module. Is it relevant to know that a traffic management systems can control TLCs? For example, when you send a command to change signal plan, you get a response (possible an error) and you should now how to receive and deal with that. On the other hand, if such reponse handling can be made generic enough, we might not need such "supervisor" modules.
Beta Was this translation helpful? Give feedback.
All reactions