*3.2.1. Requirements domain description*

The aim of this phase is to develop a first description of the application context and its functionalities. This activity aims to identify, classify and organize in hierarchy all functional and non functional requirements of different project actors. It must also provide a first estimated scope of the application as well as its size and complexity. In this work, the analysis approach adopted is based on the use case UML diagrams. To facilitate the analysis and reduce the complexity of the system studied, we decomposed the system studied into three modules: Mobile Maintenance Teams (MMT), Maintenance Policies (MP) and Maintenance Mediation (MM) which plays the role of mediator between the first two as shown in Figure 1. Let us now explain the role of each part of the system. The objective of "Mobile Maintenance

**Figure 2.** Use case diagram of Mobile Maintenance Teams

Planning and Tasks Execution as shown in Figure 4.

*3.2.4. Identification of roles and interactions*

*3.2.5. Description of interaction scenarios*

organizations Mediation Maintenance and Maintenance Policies.

in part to the behavior of a role at a higher level of abstraction.

This action must establish a decomposition of the organizational system and define the objectives of each organization. Every needs identified in the first activity, has an associated organization incarnating the global behavior in charge to satisfy or to realize. Identified organizations are added directly to the use case diagram, in the form of packages including stereotyped use cases diagram that are responsible to satisfy. The Mobile Maintenance Teams organization can be decomposed into three sub-organizations: MMT Forwarding, Tasks

31

Specifying and Verifying Holonic Multi-Agent Systems

Using Stochastic Petri Net and Object-Z: Application to Industrial Maintenance Organizations

The same process can be used to describe Mediation and Mobile Maintenance Teams organization. According to this decomposition, we can obtain organizational hierarchy of

In this hierarchy, MMT Forwarder serves as an intermediary between Mediation Maintenance and Mobile Maintenance Teams. Similarly, CMT Forwarding is directly linked to both

The context and objectives of each organization are now identified. The identification of roles and interactions aims to decompose the global behavior incarnated by an organization into a set of interacting roles. This activity must also describe the responsibilities of each role in satisfying the needs associated with their respective organizations. Each role is associated with a set of concepts in the ontology and generally a subset of those associated with his organization. Roles and interactions that constitute each organization are added to their class diagrams as described in Figure 6. A role is represented by a stereotyped class, and an interaction between two roles is represented by an association between classes of roles. Note also that in this figure, the link "Contributes to" means that an organization contributes

The objective of this activity is to specify the interactions between roles to induce higher level behavior. This activity describes the interactions between the roles defined within a given

*3.2.3. Identifying organizations*

the IMC (Figure 5).

#### **Figure 1.** Set parts associated to the IMC

Teams" (MMT) is: (a) Receive maintenance requests from "Mediation Maintenance", (b) Planning for maintenance actions, (c) Execute maintenance tasks, (d) Generate maintenance report. The role of "Mediation Maintenance" (MM) is: (a) Receive maintenance requests of different production sites, (b) Diagnosing problems, (c) Classify problems, (d) Responding to customers, (e) Send request maintenance to MMT or MP, (f) Receive execution plans of maintenance from MT or MP if necessary. The objective of "Maintenance Policies" (MP) is: (a) Receive maintenance requests from "Mediation Maintenance", (b) Scheduling maintenance tasks, (c) Execute maintenance tasks, (d) Generate maintenance report, (e) Send report to maintenance "Mediation service", (f) Develop new maintenance methods, (g) Provide training maintenance.

As an example, we'll just show the use case diagram of different scenarios associated to the MMT (Figure 2.). Similarly, we can use identical approach to describe other roles and establish their use case diagrams.

## *3.2.2. Problem ontology description*

First, problem ontology provides a definition of the application context and specific domain vocabulary. It aims to deeper understanding the problem, completing requirements analysis and use cases, with the description of the concepts that make up the problem domain and their relationships. Ontology plays a crucial role in ASPECS process development. Indeed, its structure will be a determining factor for identifying organizations. The ontology is described here in terms of concepts, actions and predicates. It is represented using a specific profile for UML class diagrams. The ontology of the IMC is described in Figure 3.

This ontology represents the knowledge related to the Mobile Maintenance Teams, Mediation Maintenance, Maintenance Policies, the different concepts that compose and the relationships between these components.

Specifying and Verifying Holonic Multi-Agent Systems

30 Petri Nets – Manufacturing and Computer Science Specifying and Verifying Holonic Multi-Agent Systems Using Stochastic Petri Net and Object-Z: Application to Industrial Maintenance Organizations <sup>5</sup> 31 Using Stochastic Petri Net and Object-Z: Application to Industrial Maintenance Organizations

**Figure 2.** Use case diagram of Mobile Maintenance Teams

#### *3.2.3. Identifying organizations*

4 Will-be-set-by-IN-TECH

since the description of the field requirements to capacities identification. It also shows how documents and UML diagrams must be constructed for each step. In the following, we present objective, description and diagrams for each step used in the requirements analysis phase.

The aim of this phase is to develop a first description of the application context and its functionalities. This activity aims to identify, classify and organize in hierarchy all functional and non functional requirements of different project actors. It must also provide a first estimated scope of the application as well as its size and complexity. In this work, the analysis approach adopted is based on the use case UML diagrams. To facilitate the analysis and reduce the complexity of the system studied, we decomposed the system studied into three modules: Mobile Maintenance Teams (MMT), Maintenance Policies (MP) and Maintenance Mediation (MM) which plays the role of mediator between the first two as shown in Figure 1. Let us now explain the role of each part of the system. The objective of "Mobile Maintenance

Teams" (MMT) is: (a) Receive maintenance requests from "Mediation Maintenance", (b) Planning for maintenance actions, (c) Execute maintenance tasks, (d) Generate maintenance report. The role of "Mediation Maintenance" (MM) is: (a) Receive maintenance requests of different production sites, (b) Diagnosing problems, (c) Classify problems, (d) Responding to customers, (e) Send request maintenance to MMT or MP, (f) Receive execution plans of maintenance from MT or MP if necessary. The objective of "Maintenance Policies" (MP) is: (a) Receive maintenance requests from "Mediation Maintenance", (b) Scheduling maintenance tasks, (c) Execute maintenance tasks, (d) Generate maintenance report, (e) Send report to maintenance "Mediation service", (f) Develop new maintenance methods, (g) Provide training

As an example, we'll just show the use case diagram of different scenarios associated to the MMT (Figure 2.). Similarly, we can use identical approach to describe other roles and establish

First, problem ontology provides a definition of the application context and specific domain vocabulary. It aims to deeper understanding the problem, completing requirements analysis and use cases, with the description of the concepts that make up the problem domain and their relationships. Ontology plays a crucial role in ASPECS process development. Indeed, its structure will be a determining factor for identifying organizations. The ontology is described here in terms of concepts, actions and predicates. It is represented using a specific profile for

This ontology represents the knowledge related to the Mobile Maintenance Teams, Mediation Maintenance, Maintenance Policies, the different concepts that compose and the relationships

UML class diagrams. The ontology of the IMC is described in Figure 3.

*3.2.1. Requirements domain description*

**Figure 1.** Set parts associated to the IMC

maintenance.

their use case diagrams.

*3.2.2. Problem ontology description*

between these components.

This action must establish a decomposition of the organizational system and define the objectives of each organization. Every needs identified in the first activity, has an associated organization incarnating the global behavior in charge to satisfy or to realize. Identified organizations are added directly to the use case diagram, in the form of packages including stereotyped use cases diagram that are responsible to satisfy. The Mobile Maintenance Teams organization can be decomposed into three sub-organizations: MMT Forwarding, Tasks Planning and Tasks Execution as shown in Figure 4.

The same process can be used to describe Mediation and Mobile Maintenance Teams organization. According to this decomposition, we can obtain organizational hierarchy of the IMC (Figure 5).

In this hierarchy, MMT Forwarder serves as an intermediary between Mediation Maintenance and Mobile Maintenance Teams. Similarly, CMT Forwarding is directly linked to both organizations Mediation Maintenance and Maintenance Policies.

#### *3.2.4. Identification of roles and interactions*

The context and objectives of each organization are now identified. The identification of roles and interactions aims to decompose the global behavior incarnated by an organization into a set of interacting roles. This activity must also describe the responsibilities of each role in satisfying the needs associated with their respective organizations. Each role is associated with a set of concepts in the ontology and generally a subset of those associated with his organization. Roles and interactions that constitute each organization are added to their class diagrams as described in Figure 6. A role is represented by a stereotyped class, and an interaction between two roles is represented by an association between classes of roles. Note also that in this figure, the link "Contributes to" means that an organization contributes in part to the behavior of a role at a higher level of abstraction.

#### *3.2.5. Description of interaction scenarios*

The objective of this activity is to specify the interactions between roles to induce higher level behavior. This activity describes the interactions between the roles defined within a given

**Figure 4.** Mobile Maintenance Teams Organization

are not represented here.

IMC organizations.

*3.2.7. Identification of capacities*

*3.2.6. Behavioral roles plans of organizations*

organization and specifies the means of coordination between them to meet the objectives of their organization. Consequently, each organization is associated with at least one scenario and it may involve defined roles in different organizations. Indeed, an organization usually requires information from other organizations at different level of abstraction. The scenarios detail the sequence of arrival or transfer of such information. Describing interaction scenarios is supported by a set of UML sequence diagrams. An example of interaction scenario associated with the organization IMC system is shown in Figure 7. This diagram above describes possible scenarios within the organization "Mobile Maintenance Teams". For each received request, "Planning Tasks" will schedule maintenance tasks and "Tasks Execution" executes maintenance tasks and finally generates a maintenance report. Scenarios of "Mediation Maintenance" and "Maintenance Policies" organization are not complicated and

33

Specifying and Verifying Holonic Multi-Agent Systems

Using Stochastic Petri Net and Object-Z: Application to Industrial Maintenance Organizations

The description of the behavior plans of roles specify the behavior of each role adapted with the objectives assigned to it and interactions in which it is implicated. Each plan describes the combination of behavior and sequencing of interactions, external events and tasks that make up the behavior of each role. Figure 8 shows the behavior plans of the roles that constitute the

This activity aims to increase the generic behavior of roles by separate clearly the definition of these behaviors of their external dependencies organizations. It is particularly to refine the behavior of roles, to abstract the architecture of the entities that will play them, and ensuring

**Figure 3.** Ontology of the IMC system

#### 6 Will-be-set-by-IN-TECH 32 Petri Nets – Manufacturing and Computer Science Specifying and Verifying Holonic Multi-Agent Systems Using Stochastic Petri Net and Object-Z: Application to Industrial Maintenance Organizations <sup>7</sup>

Specifying and Verifying Holonic Multi-Agent Systems

32 Petri Nets – Manufacturing and Computer Science Specifying and Verifying Holonic Multi-Agent Systems Using Stochastic Petri Net and Object-Z: Application to Industrial Maintenance Organizations <sup>7</sup> 33 Using Stochastic Petri Net and Object-Z: Application to Industrial Maintenance Organizations

**Figure 4.** Mobile Maintenance Teams Organization

6 Will-be-set-by-IN-TECH

**Figure 3.** Ontology of the IMC system

organization and specifies the means of coordination between them to meet the objectives of their organization. Consequently, each organization is associated with at least one scenario and it may involve defined roles in different organizations. Indeed, an organization usually requires information from other organizations at different level of abstraction. The scenarios detail the sequence of arrival or transfer of such information. Describing interaction scenarios is supported by a set of UML sequence diagrams. An example of interaction scenario associated with the organization IMC system is shown in Figure 7. This diagram above describes possible scenarios within the organization "Mobile Maintenance Teams". For each received request, "Planning Tasks" will schedule maintenance tasks and "Tasks Execution" executes maintenance tasks and finally generates a maintenance report. Scenarios of "Mediation Maintenance" and "Maintenance Policies" organization are not complicated and are not represented here.

#### *3.2.6. Behavioral roles plans of organizations*

The description of the behavior plans of roles specify the behavior of each role adapted with the objectives assigned to it and interactions in which it is implicated. Each plan describes the combination of behavior and sequencing of interactions, external events and tasks that make up the behavior of each role. Figure 8 shows the behavior plans of the roles that constitute the IMC organizations.

#### *3.2.7. Identification of capacities*

This activity aims to increase the generic behavior of roles by separate clearly the definition of these behaviors of their external dependencies organizations. It is particularly to refine the behavior of roles, to abstract the architecture of the entities that will play them, and ensuring

**Figure 6.** Description of a few roles and interactions of the IMC organization

35

Specifying and Verifying Holonic Multi-Agent Systems

Using Stochastic Petri Net and Object-Z: Application to Industrial Maintenance Organizations

**Figure 5.** Organizational hierarchy of the IMC

**Figure 6.** Description of a few roles and interactions of the IMC organization

8 Will-be-set-by-IN-TECH

**Figure 5.** Organizational hierarchy of the IMC

**Figure 7.** Description of interaction scenarios for MMT

**Figure 9.** Identification of capacities required by the roles of the IMC organization

At this stage of the process, all system organizations, their roles and associated communications are now fully described and specified. Holarchies design is the last activity of the design phase. It performs a global synthesis in which the results of all previous work are summarized and combined in one product. It is devoted to the agentification of the organizational hierarchy and the definition of the entities in charge of running it. Its objective is to define holons system and deduce the holarchy structure. To build the holarchy of the system, the organizations that compose the system are instantiated as groups. A set of holons is then created at each level, each playing one or more roles in one or more groups in the same level. Composition relations between super-holons and sub-holons are then specified in accordance with the contributions from the organizations defined in the organizational hierarchy. The organizational hierarchy is directly associated with the hierarchy of holons (or holarchy). The dynamics governing rules of holons, and the types of governance of each composed holon, are also described. All these elements are then synthesized to describe the structure of the initial holarchy system. To represent static structure of holarchy, the notation used is inspired from the "cheese board" diagrams proposed by [7]. However, it was adapted to better represent the holonic approach. The holonic structure of the IMC is presented in

37

Specifying and Verifying Holonic Multi-Agent Systems

Using Stochastic Petri Net and Object-Z: Application to Industrial Maintenance Organizations

At level 0 of the holarchy, we find three super-colons H1, H2 and H3, which play respectively Mobile Maintenance, Mediation Maintenance and Maintenance Policies in the group g0: Industrial Maintenance Company. It is reminded that this name means that the group g0 is an instance of the organization Industrial Maintenance Company. The super-holon H1 contains an instance of the Mobile Maintenance organization (g2 group), the super-holon H2 contains an instance of the Maintenance Mediation organization (g4 group) and the super-holon H3 contains an instance of the Maintenance policies (g8 group). The holon H7 of Mediation organization is also a super-holon strategy Choice who plays in the group g4 (Mediation Maintenance). This super-holon contains an instance of the organization strategy Choice (g6

**3.3. Holarchies design**

Figure 10.

**Figure 8.** Behavioral roles plans description of the IMC organization

their independence from any external element not associated to them. The identification of capacity needs to determine the competences set required for each role. Capacities are added as stereotyped classes in UML class diagrams of the organizations concerned. In our case, we will identify the capacities required by the roles of the IMC organization (Figure 9).

Specifying and Verifying Holonic Multi-Agent Systems

36 Petri Nets – Manufacturing and Computer Science Specifying and Verifying Holonic Multi-Agent Systems Using Stochastic Petri Net and Object-Z: Application to Industrial Maintenance Organizations <sup>11</sup> 37 Using Stochastic Petri Net and Object-Z: Application to Industrial Maintenance Organizations

**Figure 9.** Identification of capacities required by the roles of the IMC organization

#### **3.3. Holarchies design**

10 Will-be-set-by-IN-TECH

**Figure 7.** Description of interaction scenarios for MMT

**Figure 8.** Behavioral roles plans description of the IMC organization

their independence from any external element not associated to them. The identification of capacity needs to determine the competences set required for each role. Capacities are added as stereotyped classes in UML class diagrams of the organizations concerned. In our case, we

will identify the capacities required by the roles of the IMC organization (Figure 9).

At this stage of the process, all system organizations, their roles and associated communications are now fully described and specified. Holarchies design is the last activity of the design phase. It performs a global synthesis in which the results of all previous work are summarized and combined in one product. It is devoted to the agentification of the organizational hierarchy and the definition of the entities in charge of running it. Its objective is to define holons system and deduce the holarchy structure. To build the holarchy of the system, the organizations that compose the system are instantiated as groups. A set of holons is then created at each level, each playing one or more roles in one or more groups in the same level. Composition relations between super-holons and sub-holons are then specified in accordance with the contributions from the organizations defined in the organizational hierarchy. The organizational hierarchy is directly associated with the hierarchy of holons (or holarchy). The dynamics governing rules of holons, and the types of governance of each composed holon, are also described. All these elements are then synthesized to describe the structure of the initial holarchy system. To represent static structure of holarchy, the notation used is inspired from the "cheese board" diagrams proposed by [7]. However, it was adapted to better represent the holonic approach. The holonic structure of the IMC is presented in Figure 10.

At level 0 of the holarchy, we find three super-colons H1, H2 and H3, which play respectively Mobile Maintenance, Mediation Maintenance and Maintenance Policies in the group g0: Industrial Maintenance Company. It is reminded that this name means that the group g0 is an instance of the organization Industrial Maintenance Company. The super-holon H1 contains an instance of the Mobile Maintenance organization (g2 group), the super-holon H2 contains an instance of the Maintenance Mediation organization (g4 group) and the super-holon H3 contains an instance of the Maintenance policies (g8 group). The holon H7 of Mediation organization is also a super-holon strategy Choice who plays in the group g4 (Mediation Maintenance). This super-holon contains an instance of the organization strategy Choice (g6 group). Holon H11, of the Maintenance Policies organization, is also a super-holon which acts in the Research & Development group g8.

This super-holon contains an instance of the Research & Development organization (g10 group). Holon H8 Playing Mediation role is named Multi-part role since sharing between Maintenance Policies and Maintenance Mediation organizations. In different organizations,

Using Stochastic Petri Net and Object-Z: Application to Industrial Maintenance Organizations

39

Specifying and Verifying Holonic Multi-Agent Systems

In this section, we present an integration method of Stochastic Petri Nest (SPN) and Object-Z (OZ) by define coherent formalism called SPNOZ. This formalism is an extension of our formalism which was first defined and based on Z language [14] and GSPN called ZGSPN [19]. Petri nets (PN) are an excellent graphic formal model for describing the control structures and dynamic behaviour of concurrent and distributed systems, but Petri nets lack modelling

OZ [6] is a formal notation for specifying the functionality of sequential systems. It is based on typed set theory and first order logic and thus offers rich type definition facility and supports formal reasoning. However, OZ does not support the effective definition of concurrent and distributed systems and OZ specifications often do not have an explicit operational semantics. The benefits of integrating SPN with OZ include: (a) a unified formal model for specifying different aspects of a system (structure, control flow, data types and functionality), (b) a unified formal model for specifying different types of systems (sequential, concurrent and distributed systems), (c) a rich set of complementary specification development and analysis techniques. Our approach consists in giving a syntactic and semantic integration of both languages. Syntactic integration is done by introducing a behaviour schema into OZ schema. The semantic integration is made by translating both languages towards the same semantic domain as shown in (Figure 11). An operational semantics is aimed to the description of how

The semantic entity associated to a given specification can be seen as an abstract machine capable of producing a set of computations. Because of this, we believe that an operational semantics is a suitable representation for verification and simulation purposes. The approach consists in using a pre-existent model checker rather than developing a specific one. Both transition system models of a SPNOZ class can be used for verification purposes by model checking. In this work, the resulting specification is model-checked by using the Symbolic Analysis Laboratory (SAL) [23]. One of the reasons for choosing SAL is that it also includes verification tools and procedures that support from deductive techniques and theorem

**4. Heterogeneous formal specification and verification of holonic**

interactions between holons are represented by arrows.

the system evolves along the time.

**Figure 11.** Composition formalisms Approach

proving.

**organisation based on SPN and object-Z language**

power and mechanisms for data abstraction and refinement [22, 28].

**Figure 10.** Holonic Structure of the IMC

This super-holon contains an instance of the Research & Development organization (g10 group). Holon H8 Playing Mediation role is named Multi-part role since sharing between Maintenance Policies and Maintenance Mediation organizations. In different organizations, interactions between holons are represented by arrows.
