Next: Conclusion and Future Works Up: Application of STL Previous: The Framework

A Preliminary STL-based Implementation

For this preliminary implementation, the Environment is made up of a torus grid with a four connectivity (each cell has four neighbors). Agents comply rigorously with the model previously introduced (Figure 1). They sense the environment through their sensors and act upon their perception at once.

To put to good use distributed systems, the Environment is split into sub-environments, each of which being handled by a blop, thus providing an independent functioning between sub-environments. Note that blops have to be arranged in accordance with the topology of the environment they implement.

   figure193
Figure 3: init process and blop se: solid and dotted lines are introduced just for a purpose of visualization

Global Structure. The meta-blop world is composed of an init process, responsible for the global initialization of the system, and a set of predefined blops (called se), each one handling a sub-environment.

The init process has two static ports (of type P2P_o) for every blop to be initialized (Figure 3). The rôle of the init process is twofold: first, to create through its cre_Agts port the initial agents within every blop; secondly, to set up through its cre_SubEnv port the sub-environment (size, number of objects, etc.) of every blop.

Blop se. Figure 3 shows the basic organization of processes within a blop se and their coordination through ports. Figure 4 displays the implementation of se in STL. Two types of processes may be distinguished: processes that are part of the coordination platform (implementation purpose), namely initAgent and taxi, and processes that are intrinsic to the multi-agent model, namely subEnv and agent processes.

   figure220
Figure 4: Implementation of the blop se in STL.

Ports of a Blop. Each blop has ten static ports: four P2P_o out-flowing direction ports (north_o, south_o, west_o, east_o) and four P2P_i in-flowing direction ports (north_i, south_i, west_i, east_i), which are used for agent migration, and two P2P_i ports, namely i_Agents and i_SubEnv used respectively for the creation of the initial agents and for the initialization of the subEnv process.

For the time being, the topology between blops is set in a static manner, by creating the ports with appropriate names. The four in-flowing direction ports of a blop match with ports of its inner process initAgent. The four out-flowing direction ports of a blop match with ports of its inner process taxi.

initAgent Process, newAgentEvt Event. The initAgent process is responsible for the creation of agents. It has two static ports: newArrival and init. The newArrival P2P_iN port is connected to all in-flowing direction ports of the blop within which it resides. As soon as a value comes to this port, the initAgent process copies it onto its init P2P_oN port. In the meantime, the newAgentEvt event (see Figure 4) is triggered and it will create a new agent process, which through its creation port will read the value that was previously written on the init port of the initAgent process. Transmitted values are for instance the state of the agent to create.

agent Process. This process (C++ code in Figure 5) has two static ports (req_ans of type BB and creation of type P2P_i) plus to_taxi a dynamic P2P_o port. As already stated, this process reads on its creation port some values (its state). All req_ans ports of the agents are connected to a Blackboard, through which agents will sense their environment (perception) and act into it (action), by performing put/get operations (Linda-like out/in) with appropriate messages. The type of action depends on the type of control Algorithm implemented within the agent (see Figure 1). The to_taxi port is used to communicate dynamically with the taxi process in case of migration: the state of the agent is indeed copied to the taxi process. The decision of migrating is always taken by the subEnv process.

   figure286
Figure 5: Implementation of agent in C++.

subEnv Process. The subEnv process handles the access to the sub-environment and is in charge of keeping data consistency. It is also responsible for migrating agents, which will cross the border of a sub-environment. It has a static in_out port (of type BB) connected to the Blackboard and a static P2P_o port to_taxi connected to the taxi process. Once initialized through its init P2P_i port, the subEnv process builds the sub-environment. By performing put/get operations with appropriate tuples, the subEnv process will process the requests of the agents (e.g. number of objects on a given cell, move to next cell) and reply to their requests (e.g. x objects on a given cell, move registered). When the move of an agent will lead to cross the border (cell located in another blop), the subEnv process will first inform the agent it has to migrate and then inform the taxi process an agent has to be migrated (the direction the agent has to take will be transmitted).

The taxi Process. The taxi process is responsible for migrating agents across blops' boundaries. It has four static direction ports (of type P2P_o), which are connected to the four out-flowing direction ports of the blop within which it stands. When this process receives on its static P2P_i port requ the direction towards where the agent has to migrate, it will create a dynamic P2P_i port con_Agt in order to establish with the appropriate agent process a communication, by means of which it will collect all the useful information of the agent (state). These values will then be written on the port corresponding to the direction to take and will be transferred to the newArrival port of the initAgent process of the concerned blop inducing the dynamic creation of a new agent process in the blop, thus materializing the migration.


Next: Conclusion and Future Works Up: Application of STL Previous: The Framework

Chantemargue Fabrice
Thu Mar 12 11:42:01 MET 1998