2.3 Overview
3.1.1 Agent Description
Here we outline how the agents are specified and interact with a given GSM-based artifact system, thereby defining a GSM-MAS instance. The artifact system and agents communicate using events, where the available events for an agent depend on the current state of the artifact system, as well as of the agent. The system progresses by non-deterministically selecting an agent, which sends an event and triggers the execution of the artifact system. The selection of the event and execution of the artifact system are seen as a one-step transition from one stable state to another. A stable state has no pending events.
1
0
⌫
!
1
Figure 3.1: Static and dynamic visibility in GSM-MAS.
An important aspect of artifact systems is that agents should not be able to access all the data, nor should they be able to send arbitrary events to artifact instances. The behaviour of an agent is determined by two key components. Firstly, an authorisation view specifies the permitted access to the artifact system based on the role of the agent. This concept is inspired by the abstract i-Hub model [LBH+12, LBH13]. Secondly, private data and the protocol
function, defined for each agent individually, drive local decisions regarding which events the agent sends to the artifact system.
Definition 10 (Role). A role in a GSM-MAS is a tuple r =hν, ω, i, where • ν is the view for the visible attributes of the artifact system;
• ω is the window for the selection the visible artifact instances; • is the set of events that are accepted by the artifact system.
The concepts of ν, ω and are powerful tools to define the aspects that the agents can see and the ways they can interact with the artifact system. While ν and are simple lists, ωi(ι)
is a formula that is evaluated for a specific artifact instance ι and an agent i. The instance is exposed to the agent only if ωi(ι) evaluates to true.
In Figure 3.1 the lines correspond to artifact instances that were created at run-time and the columns correspond to data and status attributes. The view ν describes the relationship between each role and a specific artifact type. It defines a static view of the system, as it puts fixed restrictions on the data attributes and the portion of the lifecycle phases agents of a particular role can observe. In contrast, the window ω describes a connection between a role and a specific instance of an artifact type. It gives a dynamic selection of the parts of the artifact system an agent can access in terms of the state of artifact instances as it hides complete instances depending on the current state.
3.1 gsm-based multi-agent systems| 35
Table 3.1: Data attributes in view ν of agent roles in Order-to-Cash.
Buyer Seller Carrier
Order ID Order ID Order ID Product Code Product Code
Quantity Quantity
Buyer ID Buyer ID Buyer ID Seller ID Seller ID Seller ID
Carrier ID Carrier ID Parts
Table 3.2: Stages in view ν of agent roles in Order-to-Cash.
Buyer Seller Carrier
Initialization
Order Processing Order Processing Order Processing Submitting Submitting
Preparing Preparing Collecting
Researching & Ordering Receiving
Assembling Assembling
Shipping Shipping Shipping
Definition 11 (Agent). An agent in a GSM-MAS is a tuple i =hri, vi, ℘ii, where
• ri is the role of the agent;
• vi is the set of local variables with their names, types and initial values;
• ℘i : (ι, vi)→ 2i is the local protocol function.
The protocol determines behaviour of the agent i depending on the observable state of the artifact system and vi. It gives the set of events e with their respective payloads that can be
sent in the current state to the instance ι. The protocol also gives an update function µi(e, v),
which computes new assignments for the local variables depending on the selected event and the local state of the agent.
To handle automated tasks, we define an AutoAgent, which handles service calls and compu- tations in the GSM model Γ and returns the result to the artifact system in form of an event. The AutoAgent holds pending tasks in a buffer t, has full access to Γ, and can send the return messages at any time, but is otherwise handled like any other agent. Note that the AutoAgent is a simplification of the model in the sense that the agents do not carry out tasks completion themselves. This would require more sophisticated protocols of agents and we wanted to focus on more fundamental aspects of the system at this stage.
Table 3.3: Milestones in view ν of agent roles in Order-to-Cash.
Buyer Seller Carrier
Initialized
Received Received Received Cancelled Cancelled Cancelled Submitted Submitted
Ready Ready
Collected Parts Ordered Part Received All Parts Received Assembled
Shipped Shipped Shipped
Table 3.4: Events in of agent roles in Order-to-Cash.
Buyer Seller Carrier
Create Prepare Ship
Submit Research Receive Receive Part Cancel Assemble
Assembled Carry
We illustrate these concepts on the Order-to-Cash example introduced in Section 2.1.3. We introduce three roles of agents: Buyer, Seller, and Carrier. The Buyer creates an instance of the order, the Seller manages most of the CustomerOrderProcessing stage, and the delivery of the ordered product is performed by the Carrier.
Table 3.1 lists data attributes that are added to the view ν of the three roles. Table 3.2 gives restrictions on observable stages and Table 3.3 on observable milestones. The latter two Tables hide parts of the GSM model Γ. For example, the Buyer can only see that the state of an order moved from Preparing to Shipping, while the Seller sees more detail. Finally, Table 3.4 lists events from the set of events that each role can send to the artifact system. For example, the Buyer is the only one, who can create an instance of the order.
The window ω is defined for each agent of the role Buyer, such that the value of the Buyer ID attribute is equal to the unique ID of the agent. This effectively restricts access of a Buyer to its own orders only. Similarly for Sellers and Carriers.