Details - example around dynamic restructuring of models

[Bajger]

To provide thoughts and insights about dynamic organization of DEVS models within another coupled model: the idea is to use "manager" atomic DEVS model that deals with organization and delegates coupling of ports to parent coupled DEVS. Manager DEVS model knows about its children models and sends coupling instruction to parent coupled DEVS.

In my thesis, there is an example of two atomic DEVS models, each one is running own instance of robot. There is also one manager atomic DEVS that drives re-structuring of model. Parent model is coupled DEVS that defines wiring between robot models and manager DEVS.

2 essential methods on manager DEVS are here:
#organizeTeam - which does 2 robot model organization in the way they directly communicate between each other using readyIn, readyOut ports.
#disorganizeTeam - robot models aren't directly coupled. Models have #report #position output ports that are connected to manager DEVS. Report ports are serving for announcement that other robot is lost (it doesn't make sense in self-organized state however). Position ports are serving for announcing position of robots, based on that manager DEVS organizes the team (if robots are close to each other).

"manager DEVS logic - sending coupling instructions to parent coupled DEVS"
RobotManagerDEVS>>organizeTeam
self parent removeCouplings:{
#(robot1 position) -> #(manager position1).
#(robot2 position) -> #(manager position2).
#(manager check1) -> #(robot1 check).
#(manager check2) -> #(robot2 check).
}.

self parent addCouplings: {
#(robot1 readyOut) -> #(robot2 readyIn).
#(robot2 readyOut) -> #(robot1 readyIn).
}

RobotManagerDEVS>>disorganizeTeam
self parent removeCouplings: {
#(robot1 readyOut) -> #(robot2 readyIn).
#(robot2 readyOut) -> #(robot1 readyIn).
}.
self parent addCouplings: {
#(robot1 position) -> #(manager position1).
#(robot2 position) -> #(manager position2).
#(robot1 report) -> #(manager report1).
#(robot2 report) -> #(manager report2).
#(manager check1) -> #(robot1 check).
#(manager check2) -> #(robot2 check).
}.

Note: The observation here is that method for organization is triggered by manager DEVS in its external function (most probably - don't have original code here). Manager DEVS should know about its robot models which drives them. Point is that port coupling should be responsibility of parent coupled DEVS model (and not manager atomic DEVS). So organizing and disorganizing should be delegated to parent with necessary information.