Formal requirement and architecture specifications of a multi-agent robotic system
JJOURNAL OF COMPUTING, VOLUME 4, ISSUE 4, APRIL 2012, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG 1
Formal requirement and architecture specifications of a multi-agent robotic system
Nadeem Akhtar, Yann Le Guyadec, and Flavio Oquendo
Abstract — One of the most challenging tasks in specification engineering for a multi-agent robotic system is to formally specify and architect the system, especially as a multi-agent robotic system is concurrent having concurrent processing, and often having dynamic environment. The formal requirement and architecture specifications along with step-wise refinement from abstract to concrete concepts play major role in formalizing the system. This paper proposes the formal requirement and architecture specifications aspects of an approach that supports analysis with respect to functional as well as non-functional properties by step-wise refinement from abstract to concrete specifications and formal architecture definition. These formal specifications have been exemplified by a case study. As formal specification techniques are getting more mature, our capability to build a correct complex multi-agent robotic system also grows quickly.
Index Terms — Formal architecture, Multi-agent robotic system, π -ADL (Architecture Description Language). —————————— (cid:1) ——————————
1 I
NTRODUCTION
NE of the most challenging tasks in specification engineering of a multi-agent robotic system is to formally specify and architect the system, especially as it is concurrent having concurrent processes, and often having dynamic environment. An approach has been proposed that supports formal analysis with respect to functional as well as non-functional properties; that sup-ports step-wise refinement from abstract to concrete spe-cifications and full code generation; and that formalizes the static as well as the dynamic architecture of these sys-tems. An agent is a computer system situated in some envi-ronment, capable of autonomous actions in this environ-ment in order to meet its design objectives [16]. Multiple agents are necessary to solve a problem, especially when the problem involves distributed data, knowledge, or control. A multi-agent system is a collection of several interacting agents in which each agent has incomplete infor-mation or capabilities for solving the problem [5]. These are complex systems and their specifications in-volve many levels of abstractions. We have proposed a formal approach having four phases of requirement specifications, verifica-tion specifi-cations, architecture specifications, and system implemen-tation as shown in fig. 1. This approach identifies and formally specifies each component and sub-component of the system, and identifies the formal requirement specifi- cations; verification specifications; architecture specifica-tions; implementation; satisfaction and refinement rela-tions between different phases. This ap-proach has been exemplified by a case study of a multi-agent robotic sys-tem. Complete approach with its functional and technical details can be found in [1].
Fig. 1. The proposed approach having two major phases of require-ment and architecture specification.
This paper focuses on the formal requirement and archi-tecture specifications. Our contributions are; (1) a combi-nation of regular expression, first-order predicate logic to define the formal requirement specifications; (2) 1-calculus based 1-ADL dot NET platform to define the dynamic architecture specifications; (3) a multi-agent ro-botic system case study to exemplify these formal specifi-cations. Objective: Our major objective is the formal specifica-tion, analysis with respect to functional as well as non-functional properties by step-wise refinement from ab-stract to concrete specifications and then formal architec-ture specifications. Along with the development of a ro-botic multi-agent system that’s static as well as dynamic formal architecture can be defined and is safe. By safe the focus is on the correctness properties of safety and live-ness. Section 2 presents the background studies, Section 3 O ———————————————— • Nadeem Akhtar is an assistant professor at the Department of Computer Science & IT, The Islamia University of Bahawalpur, PAKISTAN,E-mail:[email protected]. • Yann Le-Guyadec is an associate professor at the Laboratory VALORIA of Computer Science, University of South Brittany (UBS), Vannes, FRANCE,
E-mail: [email protected]. • Flavio Oquendo is a Professor at the Laboratory VALORIA of Computer Science, University of South Brittany (UBS), Vannes, FRANCE,
E-mail: [email protected]
OURNAL OF COMPUTING, VOLUME 4, ISSUE 4, APRIL 2012, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG 2 the case study, and Section 4 lessons learned and conclu-sion.
2 B
ACKGROUND STUDIES
Among the existing multi-agent methods we have consi-dered Gaia [17] as the most suitable one for specifying the requirements as it recognizes the organizational structure as a primary dimension for the development of an agent system. This organizational structure provides organiza-tional abstractions, which are needed to meet both func-tional and non-functional requirements. Gaia considers a multi-agent system as a computational organization con-sisting of interacting roles, and it deals with both the ma-cro-level (social) and the micro-level (agent internal) as-pects of a multi-agent system. The analysis phase in Gaia specifies the requirements in terms of functions, activities, and identi-fies the loosely coupled sub-organizations which compose the whole sys-tem. It involves considering real-world organization, the need to enforce organizational rules and then, for each of these sub-organizations it produces the following basic abstract models: (1) Environmental model captures the characteristics of the multi-agent system operational environment. (2) A preliminary role model captures the key task-oriented activities to be played in a multi-agent system. The result is a prototypical role model, a list of the key roles that occur in the system, each with a description that is not elaborated. (3) A preliminary interaction model captures basic inter-dependencies between roles. The result is an interac-tion model, which captures the recurring patterns of role interactions. (4) The preliminary interaction model is used as a base to elaborate the roles. The result is a fully elaborated roles model, which documents the key roles of the sys-tem, their permissions and responsibilities. Responsibili-ties attributes determine the expected behavior and key attributes of liveness and safety associated with a role. Liveness property is specified via liveness expression which defines the potential execution trajectories through activities and protocols associated with the role. An activ-ity corresponds to a unit of action that does not involve interaction with any other agent, and protocol requires interaction with other agents. (5) A set of organizational rules, expressing global constraints or directives that underlie the multi-agent system functioning. The role and interaction models are completed based on the adopted organizational structure. The analysis models are input to architectural design phase which defines the organizational structure of the system. After the architectural design phase, the detailed design involves identifying: An agent model consisting of a set of agent classes in a multi-agent system, implement-ing the identified roles; and a services model, expressing services and interaction protocols to be provided within these agent classes. π -ADL Formal requirements and architecture specifications achieve precision; the unambiguous specifications ensure that correctness, completeness, and complex system properties are preserved. 1-ADL [11] provides the core structure and behavior con-structs for describing static as well as dynamic software architectures. It is a formal specification language de-signed to be executable and to support automated analy-sis and refinement of dynamic architectures. It has as formal foundation the higher-order typed 1-calculus [6][7][8][13], and it takes its roots in work concerning the use of 1-calculus as a semantic foundation for architec-ture description languages [3][4]. The design of 1-ADL are based on [9][14][15] and follows the language design principles found in [10]. 1-ADL supports description of software architectures from a runtime perspective, an architecture is described in terms of components, connec-tors, and their composition. Fig.2 depicts its main consti-tuents.
Fig 2. Architectural concepts in π -ADL [11] Components are described in terms of external ports and an internal behavior. Their architectural role is to specify computational elements of a software system. The focus is on computation to deliver system functionalities. Ports are described in terms of connections between a compo-nent and its environment. Their architectural role is to put together connections providing an interface between the component and its environment. Protocols may be en-forced by ports and among ports. Connections are basic interaction points. Their architectural role is to provide communication channels between two architectural ele-ments. A component can send or receive values via con-nections. They can be declared as output connections (values can only be sent), input connections (values can only be received), or input-output connections (values can be sent or received). Connectors are special-purpose components. They are described as components in terms of external ports and an internal behavior. However, their architectural role is to connect together components. They specify interactions among components. Therefore, com-ponents provide the locus of computation, while connec-tors manage interaction among components. A compo-nent cannot be directly connected to another component. In order to have actual communication between two components, there must be a connector between them. Both components and connectors comprise ports and be-haviour. In order to attach a port of a component to a port of a connector, at least a connection of the former port must be attached with a connection of the later port. A connection provided by a port of a component is attached
OURNAL OF COMPUTING, VOLUME 4, ISSUE 4, APRIL 2012, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG 3 to a connection provided by a port of a connector by un-ification or value passing. Thereby, attached connections can transport values (that can be data, connections, or even architectural elements). 1-ADL dot NET [12] is the dot NET extension of 1-ADL based on Microsoft dot NET platform. It provides an ex-ecutable model of system specifications consisting of ab-stractions and behaviors, and leads to a formal architec-ture comprising of components and connectors that can change dynamically dusring execution. (a) It has as formal foundation the higher-order typed 1-calculus [6][7][8][13] which is a well-formed higher-order calculus for defining communicating and mobile architec-tural elements; (b) It focuses on formal description of software architecture from the run-time viewpoint: the run-time structure, the run-time behavior, and how it may evolve over time; (c) It is executable; (d) It supports multiple concrete syntaxes: textual and graphical nota-tions; and (e) It supports automated verification of prop-erties by model checking and theorem proving.
3 C
ASE STUDY : M ULTI - AGENT ROBOTIC TRANSPORT SYSTEM
Our multi-agent robotic system is composed of transport-ing agents. The mission is to transport stock from one storehouse to another. They move in their environment which is static i.e. the topology of the system does not evolve at run time [2][1].
Fig. 3. Case study - Environment alongwith the loader and unloader agents.
Our system consists of three types of agents; (1) Carrier agent transports stock from one store-house to another one, it can be loaded or un-loaded; can move both forward and backward directions; and can detect collision. Each road section is marked by a sign number readable by the carrier agent. (2) Loader / Un-loader agent receives/delivers stock from the storehouse; ensures that the carrier waiting to be loaded is loaded and the carrier waiting to be un-loaded is unloaded. (3) Store-manager agent manages the stock count in the storehouse and transports the stock between the storehouse and loader/un-loader.
Environment:
There is a path between storehouse-A and storehouse-B which is composed of a sequence of inter-connected road sections of fixed length as shown by fig.2. Each road section has a numbered sign, which is readable by carrier agents. Each road section has a unique num-bered sign. There are three types of road sections depend-ing upon the road topology. The road is single lane and there is a roundabout at storehouse-A and storehouse-B [2].
Scenario:
In the case study we have used a particular road topology consisting of nine road partitions as shown in fig.3. The main task of the carrier is to transport the stock from storehouse A to storehouse B until the storehouse A is empty. Loader at the storehouse A loads the carrier with stock and the Un-loader at the storehouse B unloads the carrier. The store-manager keeps a count of stock in each storehouse.
The role of an agent defines what it is expected to do in the organization, both in concert with other agents and in respect to the organization itself. Organizational role model precisely describes each role that constitutes the computational organization. Here we present the Move_full role of our system.
TABLE
OVE _ FULL ROLE OF G AIA R OLE MODEL
Role Schema:
Move_full
Description:
Role of a loaded carrier moving from storehouse A to storehouse B.
Protocols and Activities: readSign, movetoNext, collisionSensorTrue, carrierWait, readUnloadSign, waitforUnloading, unloadCarrier
Permissions: reads: sign_number (external) collision_sensor (internal) changes: position (internal) next_position (external) /// (TRUE or FALSE) Checks if next position is available
Responsibilities:
Liveness:
Move_full = Move .( readUnloadSign . waitforUnloading . unloadCarrier ) Move = ( readSign . movetoNext )+ | ( collisionSensorTrue . Wait ).( readSign . movetoNext )+ Wait = carrierWait + Safety: is_Full(c) ∧ can_movetoNext(sn) where c is for carrier and sn for the sign number In the above table activities (underlined) are readSign, movetoNext, collisionSensorTrue, carrierWait and rea-dUnloadSign. And there are two protocols waitforUn-loading and unloadCarrier. The activities are actions of an agent that do not involve interaction with any other agent, whereas protocols are actions that require interac-tion with other agents. When a loaded carrier reaches the road partition in front of the un-loader, it stops there and waits until it is unloaded. When we consider the liveness property, it shows all the activities and protocols that (a) N is the unique numbered sign. P is the parking Flag (TRUE or FALSE). This road section can be used for parking purposes (b) N is the unique numbered sign. (c) Road section present at the loader and un-loader which detect the presence of the carrier agents at the loader and un-loader.
OURNAL OF COMPUTING, VOLUME 4, ISSUE 4, APRIL 2012, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG 4 make up the role. The carrier has two choices; First choice it reads the sign and then moves to the next road parti-tion; Second choice in case of collision with another carri-er it sets its collision sensor to true and then waits. At the end, the carrier reads the unload sign, waits to be un-loaded, so now it’s no longer a loaded carrier, and is therefore not part of the Move_full role, instead it is part of the Move_empty role. There are dependencies and relationships between the various roles in a multi-agent organization which are pro-tocol definitions, one for each type of inter-role interac-tion. Table.2 shows the protocol definitions related to Move_full role.
TABLE
ROTOCOL DEFINITIONS RELATED TO M OVE _ FULL ROLE waitForUnloading
Move_full Unload
The full carrier agent waits for the un-loader agent unloadCarrier
Move_full Unload
The full carrier agent is unloaded by the un-loader agent π -ADL dot NET Fig. 4. Case study - Environment.
The 1-ADL architecture model of this system is shown in fig. 5. There is one behavior ROUTE and four abstractions MOVE_FULL, MOVE_EMPTY, STOREHOUSE_A and STOREHOUSE_B. There is a connection of type connec-tion (i.e. connection that lets another connection pass through it) between MOVE_FULL and STOREHOUSE_A, similarly another connection of type connection between MOVE_EMPTY and STOREHOUSE_B. These connections of type connection specify the dynamic aspects of the ar-chitecture.
Fig. 5. π -ADL dot NET model of our system. This 1-ADL architecture model as shown in fig. 5 is then defined by the 1-ADL dot NET code which can be compiled and run, some part of this code is given below. ROUTE is the main behavior having one connection named moveFull_Conn, through which it sends the road partition no. of full carrier agent to the MOVE_FULL ab-straction. The no. of stock present in storehouse-A (stockCount) is sent as an argument to MOVE_FULL through connection renaming.
ROUTE is the main bahaviour i.e. from where the execution /// starts
ROUTE names behaviour { moveFull_Conn:
Connection [ Integer ]; full_road_part:
Integer ; stockCount:
Integer ; /// Gets the initial location of the full carrier via in receive full_road_part; /// Gets the number of stock to transfer from STOREHOUSE_A to ///
STOREHOUSE_B via in receive stockCount; compose { via MOVE_FULL send stockCount where {moveFull_Conn renames full_Conn}; /// sends stockCount and /// sends full carrier initial position i.e. road partition via moveFull_Conn send full_road_part; } /// end compose } /// end ROUTE MOVE_FULL refers to the role of a loaded carrier agent. It has a connection named moveEmp-ty_Conn, and through this connection it sends the road partition no. of loaded carrier to MOVE_EMPTY. There is another con-nection con_A which allows another connection to pass through it. Through this connection a connection is sent with the current number of stock from MOVE_FULL to STOREHOUSE_A. So we have an architecture component sign_number position sign_number position
OURNAL OF COMPUTING, VOLUME 4, ISSUE 4, APRIL 2012, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG 5 (i.e. connection) that can pass other architecture compo-nents through it during execution, thus changing the ar-chitecture at runtime, as a result this con_A shows one of the dynamic aspects of our architecture.
20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ///
Here its the MOVE_FULL role as an abstractions (single /// carrier agent role) value
MOVE_FULL is abstraction (x: Integer ) { pos_full:
Integer ; empty_road_part:
Integer ; stock:
Integer ; a:
Integer ; moveEmpty_Conn:
Connection [ Integer ]; full_Conn:
Connection [ Integer ]; /// con_A is a dynamic connection between the MOVE_FULL carrier /// role and storehouse-A /// Connection passed through a connection (dynamicity of the /// system) con_A:
Connection [ Connection [ Integer ]]; p:
Connection [ Integer ]; stock = x; via full_Conn receive x; pos_full = x; ///
If full carrier is out of the range of full road partitions if (pos_full<1 || pos_full>7) do { via out send "Invalid position for Full carrier"; done ; } /// If stock is zero than the system stops as carrier has no stock to /// transfer if (stock==0) do { via out send "No stock to transfer"; done ; } while (pos_full>=1 && pos_full<=6) do { /// pseudo-code here (due to space constraints) /// if(pos_full==1) do /// road position=1 is the loader location, move to next /// position and print the new position /// if (pos_full>1 && pos_full<=6) do /// road position 1 to 6 are the central route positions as shown /// in fig. 3 /// move to the next position and print the new position } /// end while if (pos_full==7) do { /// road position=7 is the Unloader location as shown in fig. 3 empty_road_part=8; compose { via STOREHOUSE_A send p where {con_A renames con_B}; and /// connection A passes the connection p (i.e. fig. 4) via con_A send p; /// connection p sends the stock count as argument (i.e. fig. 4) via p send stock; compose { via MOVE_EMPTY send stock where {moveEmpty_Conn renames empty_Conn}; and via moveEmpty_Conn send empty_road_part; } /// end compose } /// end compose } /// end if } /// end MOVE_FULL STOREHOUSE_A abstraction counts the number of stock and gives the state of the storehouse-A.
76 77 787980818283 ///
STOREHOUSE_A which is full initially and empty at the end value
STOREHOUSE_A is abstraction (input: Connection [ Integer ]) { stockCountA:
Integer ; con_B:
Connection [ Connection [ Integer ]]; via out send "Empty carrier at the LOADER"; via con_B receive input; via input receive stockCountA; out send "No of stock at STOREHOUSE_A = "; via out send stockCountA; if (stockCountA > 0) do { via out send "decrementStock_at_STOREHOUSE_A"; /// stock at the Storehouse-A is decremented by 1 stockCountA = stockCountA-1; } /// stock at the Storehouse-A can not be decremented as it is /// already zero if (stockCountA == 0) do via out send "STOREHOUSE_A_Empty"; } /// end STOREHOUSE_A
4 L
ESSONS LEARNED AND CONCLUSION
The requirement and architecture aspects of a multi-agent robotic system are defined and formalized. The require-ment specifications define the behavior alongwith the correctness properties of liveness and safety, and the 1-ADL dot NET defines the formal static as well as the dy-namic aspects of the architecture. This requirement speci-fications method has a concrete syntax to express proper-ties, is suitable to model behaviors and is applicable to a wide range of multi-agent systems. These requirement specifications are refined into 1-ADL dot NET based ar-chitecture specifications. The proposed formal approach has key aspects of: requirement specifications constituting of organizational abstractions, organizational rules, role model specifications, protocol definitions followed by the architecture specifications constituting of constructs for specifying static as well as dynamic architecture. This approach is a step towards the development of a method, centered on organizational abstractions and formal dy-namic architecture for requirement analysis and architec-ture of a multi-agent robotic system. R EFERENCES [1]
Akhtar, N., (2010) Contribution to the formal specification and verifica-tion of multi-agent robotic systems, PhD thesis, Ecole Doctorale, Lab. VALORIA, University of South Brittany. [2]
Akhtar, N., Guyadec, Y. L., and Oquendo, F., (2009) FORMAL SPECIFICATION AND VERIFICATION OF MULTI-AGENT ROBOTICS SOFTWARE SYSTEMS: A Case Study, Proceedings of the International Conference on Agents and Artificial In-telligence (ICAART 09). Porto, Portugal, January 19-21, 2009. INSTICC Press. [3]
Chaudet, C., and Oquendo, F., (2000) A Formal Architecture Description Language Based on Process Algebra for Evolv-ing Software Systems. Proceedings of the 15th IEEE International Conference on Automated Software Engineering (ASE’00). IEEE Computer Society, Grenoble, France, September. [4]
Chaudet, C., Greenwood, M., Oquendo, F., Warboys, B., (2000) Architecture-Driven Software Engineering: Specifying, Gene-rating, and Evolving Component-Based Software Systems. IEEE Journal: Software Engineering, Vol. 147, No. 6, UK, December. [5]
Jennings, N., Sycara, K., and Wooldridge, M., (1998) A roadmap of agent research and development. Int. Journal of Autonomous Agents and Multi-Agent Systems, 1(1):7–38. [6]
Milner, R., (1999) Communicating and Mobile Systems: The 1-Calculus. Cambridge University Press. [7]
Milner, R., (1993) The Polyadic 1-Calculus: A Tutorial, Logic and Algebra of Specification, Springer-Verlag. [8]
Milner, R., Parrow, J., and Walker, D., (1992) A Calculus of Mobile Processes. Information and Computation, 100(1), pp. 1-77. [9]
Morrison, R. (1979) On the Development of S-algol. PhD Thesis, University of St Andrews.
OURNAL OF COMPUTING, VOLUME 4, ISSUE 4, APRIL 2012, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG 6 [10]
Oquendo, F., (2005) Tutorial on ArchWare ADL – Version 2 (1-ADL Tutorial). ArchWare European RTD Project IST-2001-32360, Jun 2005. [11]
Oquendo, F., (2004) 1-ADL: An Architecture Description Lan-guage based on the Higher Order Typed 1-Calculus for Speci-fying Dynamic and Mobile Software Architectures. ACM Soft-ware Engineering Notes, Vol. 29, No. 3, May 2004. [12]
Qayyum, Z., (2009) Concretizing software architectures using a formal language: towards development languages formally founded on 1-ADL, PhD thesis, Ecole Doctorale, Lab. VALO-RIA of Computer Science, Université de Bretagne-sud, France. [13]
Sangiorgi, D., (1992) Expressing Mobility in Process Algebras: First-Order and Higher-Order Paradigms. PhD Thesis, Univer-sity of Edinburgh. [14]
C. Strachey, (1967) Fundamental Concepts in Programming Lan-guages. Oxford University Press, Oxford. [15]
R.D. Tennent, (1977) Language Design Methods based on Se-mantic Principles. Acta Informatica 8. [16]
Wooldridge, M., and Jennings, J. R., (1995) Intelligent agents: Theory and practice. Knowledge Engineering Review, 10(2):115–152. [17]
Zambonelli, F., Jennings, N. R., and Wooldridge, M., (2003) Develop-ing multiagent systems: The gaia methodology. ACM Transactions on Software Engineering and Methodology, 12(3):317–370.
Nadeem Akhtar is an Assistant Professor at the Department of Computer Science & IT, The Islamia University of Bahawalpur (IUB), Pakistan. Before joining IUB in 2011, he was a Ph.D fellow at the research Lab. VALORIA of Computer Science, University of South Brittany (UBS), France. He has been awarded a highly honoured Ph.D in Computer Science from Lab. VALORIA, University of South Brittany (UBS) France in 2010. He has an MS with specialization in Information system architecture from IUP, University of South Brit-tany, Vannes, France awarded in 2005. In 2004 he was awarded the French govt. “Study in France 2004” scholarship for post-graduate studies in France. In 2007 he was awarded a French govt. and Pakis-tan govt. HEC scholarship for PhD studies at lab. VALORIA-UBS, France. His research areas are formal architecture, formal specifica-tion, and service-oriented architecture for robotics.
Yann Le-Guyadec is an Associate Professor of Computer Science and Software Engineering at the University of South Brittany, part of the European University of Brittany, France. His research interests are in parallel processes, formal verification, and robotics.