Formal Modelling of Real-Time Self-Adaptive Multi-Agent ...prr.hec.gov.pk/jspui/bitstream/123456789/9055/1... · Awais Qasim (2013-PhD-CS-18) March 2017. iv Research Completion CertiÞcate

Formal Modelling of Real-TimeSelf-Adaptive Multi-Agent Systems

Awais Qasim(2013-PhD-CS-18)

Supervisor: Dr. Syed Asad Raza Kazmi

Department of Computer ScienceGovernment College University, Lahore

This dissertation is submitted for the degree ofPh.D in Computer Science

March 2017

I would like to dedicate this thesis to my loving parents . . .

Declaration

I hereby declare that except where specific reference is made to the work of others, thecontents of this dissertation are original and have not been submitted in whole or in partfor consideration for any other degree or qualification in this, or any other university. Thisdissertation is my own work and contains nothing which is the outcome of work done incollaboration with others, except as specified in the text and Acknowledgements. Thisdissertation contains fewer than 65,000 words including appendices, bibliography, footnotes,tables and equations and has fewer than 150 figures.

Date: Signature:

Awais Qasim(2013-PhD-CS-18)

March 2017

iv

Research Completion Certificate

It is certified that the research work contained in this thesis titled Formal Modelling

of Real-Time Self-Adaptive Multi-Agent Systems has been carried out by Awais

Qasim Roll. No 903-PhD-13 under my supervision.

Dr. Syed Asad Raza Kazmi

Assistant Professor

Department of Computer Science

GC University Lahore

Date: Supervisor:

Submitted Through

Dr. Syed Asad Raza Kazmi

Incharge

Department of Computer Science Controller of Examination

GC University Lahore GC University Lahore

i

Acknowledgements

Writing my Ph.D thesis was one of the biggest challenge of my life. I am extremely thankfulto Gold Almighty who gave me the courage to accomplish this difficult task. Althoughthis journey was very difficult but it has made me more humble and taught me how to payattention to the detail.

I would like to thank my Ph.D Adviser Dr. Syed Asad Raza Kazmi for his continuoussupport and guidance throughout my Ph.D. He was always there when I needed him forany kind of research guidance and even personal advice. He enabled me to do independentresearch. Not to mention that he motivated me to start my Ph.D as early as possible. I wouldhave never been able to complete my Ph.D without his enthusiastic supervision.

I am extremely thankful to my parents especially my father who convinced me to leavethe software industry and pursue my Ph.D. I am also thankful to my mother and sisters whowere always praying for my Ph.D. I am thankful to my best friend Rafay Ali who was alwaysthere for emotional support. He comforted me whenever the pressure of studies was immense.

I am thankful to Dr. Farooq Ahmed who gave me advice for improving my thesis. I amalso thankful to Dr. Danny Weyns, Linnaeus University Sweden, whose work inspired me toconduct research in the area of self-adaptive systems. I would also like to thank to Dr. JiriSrba of Aalborg University for his help in designing models in TAPAAL model checker.Iacknowledge the moral support of all my colleagues of the GC University Lahore.

Last but not the least I offer my gratitude to the worthy Vice Chancellor of GC University,Lahore who allowed me to pursue my Ph.D with full-time job. I was provided necessaryfunding for the purchase of research equipment required for the simulation results.

Abstract

Software systems are becoming complex and dynamic with the passage of time and toprovide better fault tolerance and resource management they need to have the ability ofself-adaptation. Software agents are expected to work autonomously and deal with unfamiliarsituations astutely. Achieving cent percent test case coverage for these agents has always beena problem due to the limited resources. Also a high degree of dependability is expected fromautonomous software agents. Multi-agent systems deployed in dynamic and unpredictableenvironment needs to have the ability of self-adaptation, making them adaptable to thefailures. These systems have emerged as a useful technique to model real-time systemsand these real-time multi-agent systems by their nature have temporal constraints. Thoughreal-time multi-agent systems have been formally modelled in the past but self-adaptivereal-time multi-agent systems are yet to be addressed. State of the art encourage the useof MAPE-K feedback loop for the provision of self-adaptation in any system. Hence thereis a dire need of formal vocabulary that can be used for the conceptual design of anyreal-time multi-agent system with self-adaptation. In this work we proposed a frameworkSMARTS (Self-adaptive Multi-Agent Real-Time Systems) for the formal modelling of self-adaptive real-time multi-agent systems. Our framework integrates reflection perspectiveand unification with distribution perspective into the SIMBA (SIstema Multiagente Basadoen ARTIS) agent architecture. For a precise semantic description of the constructs ofour framework, we used Timed Communicating Object-Z (TCOZ) language. The corefunctionality of the system is depicted using managed system and self-adaptive unit. Theself-adaptive functionality is provided by using a predefined interfaces based on Monitor,Analyze, Plan and Execute phases of the MAPE-K feedback loop. The managed systemcomprises the ARTIS agents, which are designed to work in hard real-time environment. InSMARTS the non-terminating behavior of the ARTIS agent is represented using active classconcept of TCOZ. For communication between active processes, channel communicationmechanism of TCOZ is utilized. We elaborate the application of the SMARTS frameworkusing a trivial case-study of Traffic Management System for real-time congestion control.We ensure the correctness of the system by formally specifying and verifying the actionsof the communicating real-time agents in Timed-Arc Petri-Nets as they are visually more

vii

expressive than Linear Temporal Logic (LTL) and Computational Tree Logic (CTL). Thetraffic models are verified using Timed Computational Tree Logic (TCTL) via translationsinto timed automata. The TAPAAL model checker is used for the formal verification. Thesimulation results show the computation trees of the traffic models, trace of the satisfiedproperties, count of the transitions triggered and places visited during the verification process.This formal verification of real-time self-adaptive multi-agent systems will enhance theconfidence and expressibility to address the correctness of such systems.

Table of contents

List of figures x

List of tables xi

List of Abbreviations xii

1 Introduction 11.1 Motivation and Thesis Statement . . . . . . . . . . . . . . . . . . . . . . . 21.2 Our Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Layout of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Preliminaries 102.1 MAPE-K Feedback Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 ARTIS Agent Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 SIMBA Agent Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 TCOZ Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5 Timed-Arc Petri-Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Proposed SMARTS Framework 143.1 Overview of the Self-adaptive Multi-Agent Real-Time Systems (SMARTS)

Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 TCOZ Specification of the SMARTS Framework . . . . . . . . . . . . . . 17

3.2.1 Environment Representation . . . . . . . . . . . . . . . . . . . . . 173.2.2 Model and Domain Model Representation . . . . . . . . . . . . . . 173.2.3 Entities for Domain Functionality . . . . . . . . . . . . . . . . . . 183.2.4 Entities for Inter and Intra Platform Agent Communication . . . . . 203.2.5 Entities for the Provision of Domain Functionality . . . . . . . . . 243.2.6 Entities for Self-Adaptive Functionality . . . . . . . . . . . . . . . 28

Table of contents ix

3.2.7 Entities for Distributed Self-Adaptive Multi-Agent System . . . . . 35

4 Application of the SMARTS Framework 364.1 Modelling of Traffic Management System using SMARTS . . . . . . . . . 364.2 Existing Methodology for Smart Traffic Management System . . . . . . . . 37

4.2.1 Inductive Loop Detection Technology . . . . . . . . . . . . . . . . 384.2.2 Video Analysis Technology . . . . . . . . . . . . . . . . . . . . . 384.2.3 Infrared Sensors Technology . . . . . . . . . . . . . . . . . . . . . 38

4.3 Proposed Solution for Traffic Management System . . . . . . . . . . . . . 394.3.1 Overview of Single Traffic Monitoring Station . . . . . . . . . . . 404.3.2 Provision of the Domain Functionality . . . . . . . . . . . . . . . . 414.3.3 Self-Adaptive Functionality . . . . . . . . . . . . . . . . . . . . . 474.3.4 Coordination Mechanism . . . . . . . . . . . . . . . . . . . . . . . 514.3.5 Complete Traffic Monitoring System (TMS) . . . . . . . . . . . . 52

4.4 Formal Verification of the Traffic Monitoring System . . . . . . . . . . . . 554.4.1 Timed Arc Petri-Net Models of the MTM and TNB Signals . . . . 554.4.2 Communication Model of the MTM and TNB Signals . . . . . . . 734.4.3 Computational Statistics of the Discovered Markings, Trace and

Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.4.4 Fault Handling using Self-Adaptive Functionality . . . . . . . . . . 824.4.5 Run-time Adaptation of the System Based on Congestion Situation 87

4.5 Application Areas and Socioeconomic Benefits . . . . . . . . . . . . . . . 92

5 Conclusion and Discussions 95

References 99

Appendix A Run-time Adaptation of the System Based on Congestion Situation 110A.1 Formal Specification of Monitoring Stations at MTM Signal to Handle

Congestion at the MTM2 Station . . . . . . . . . . . . . . . . . . . . . . . 110A.2 Formal Specification of Monitoring Stations at TNB Signal to Handle Con-

gestion at the MTM2 Station . . . . . . . . . . . . . . . . . . . . . . . . . 112A.3 Formal Specification of Monitoring Stations at MTM Signal to Disseminate

Signal Duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113A.4 Formal Specification of Monitoring Stations at TNB Signal to Disseminate

Signal Duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

List of figures

3.1 Proposed SMARTS framework. . . . . . . . . . . . . . . . . . . . . . . . 163.2 MAPE-K interfaces for self-adaptive functionality in the SMARTS framework. 29

4.1 Traffic types based on congestion. . . . . . . . . . . . . . . . . . . . . . . 394.2 Overview of the traffic monitoring stations at the Thokar Niaz Baig signal. . 404.3 Overview of the traffic monitoring stations at the Muslim Town Mor signal. 414.4 Overview of single traffic monitoring station. . . . . . . . . . . . . . . . . 424.5 Timed Petri-Net model of the Muslim Town Mor signal. . . . . . . . . . . 574.6 Initial computation tree of the Muslim Town Mor signal. . . . . . . . . . . 574.7 Computation tree of the MTM1 signal. . . . . . . . . . . . . . . . . . . . . 604.8 Computation tree of the MTM2 signal. . . . . . . . . . . . . . . . . . . . . 614.9 Computation tree of the MTM3 signal. . . . . . . . . . . . . . . . . . . . . 624.10 Computation tree of the MTM4 signal. . . . . . . . . . . . . . . . . . . . . 634.11 Computation tree of the MTM5 signal. . . . . . . . . . . . . . . . . . . . . 644.12 Timed Petri-Net model of the Thokar Niaz Baig signal. . . . . . . . . . . . 664.13 Initial computation tree of the Thokar Niaz Baig signal. . . . . . . . . . . . 684.14 Computation tree of the TNB1 signal. . . . . . . . . . . . . . . . . . . . . 694.15 Computation tree of the TNB2 signal. . . . . . . . . . . . . . . . . . . . . 704.16 Computation tree of the TNB3 signal. . . . . . . . . . . . . . . . . . . . . 714.17 Computation tree of the TNB4 signal. . . . . . . . . . . . . . . . . . . . . 724.18 Communication model of the Muslim Town Mor signal. . . . . . . . . . . 744.19 Communication model of the Thokar Niaz Baig signal. . . . . . . . . . . . 754.20 Failure of single traffic monitoring station at Muslim Town Mor signal. . . . 834.21 Re-organization of the system after failure of single traffic monitoring station. 844.22 Failure of two traffic monitoring stations at two locations of the Muslim

Town Mor signal and Thokar Niaz baig signal. . . . . . . . . . . . . . . . . 854.23 Re-organization of the system after failure of two traffic monitoring stations. 86

List of tables

4.1 Properties for correct functioning of the Muslim Town Mor Signal and theircorresponding TCTL formulas in TAPAAL. . . . . . . . . . . . . . . . . . 58

4.2 Properties for correct functioning of the Thokar Niaz Baig Signal and theircorresponding TCTL formulas in TAPAAL . . . . . . . . . . . . . . . . . 67

4.3 Properties for correct functioning of the communication model of ThokarNiaz Baig and Muslim Town Mor Signal. Their corresponding TCTL formu-las in TAPAAL is also shown. . . . . . . . . . . . . . . . . . . . . . . . . 76

4.4 Statistics for markings, verification time and memory usage. . . . . . . . . 804.5 Table showing statistics for transitions fired. . . . . . . . . . . . . . . . . . 804.6 Table showing trace for the verified property. . . . . . . . . . . . . . . . . 81

List of Abbreviations

TCOZ . . . . . . . . . Timed Communicating Object-Z

SMARTS . . . . . . Self-adaptive Multi-Agent Real-Time Systems

LTL . . . . . . . . . . . Linear Temporal Logic

CTL . . . . . . . . . . Computational Tree Logic

TCTL . . . . . . . . . Timed Computational Tree Logic

RTA . . . . . . . . . . . Real-Time Agent

MAS . . . . . . . . . . Multi-Agent System

RTMAS . . . . . . . Real-Time Multi-Agent System

FIPA . . . . . . . . . . Foundation for Intelligent Physical Agents

FORMS . . . . . . . FOrmal Reference Model for Self-adaptation

CSP . . . . . . . . . . . Communicating Sequential Processes

CCP . . . . . . . . . . Concurrent Constraint Programming

In-agent . . . . . . . Internal Agent

RS . . . . . . . . . . . . Reflex Server

DS . . . . . . . . . . . . Deliberative Server

AMS . . . . . . . . . . Agent Management System

DF . . . . . . . . . . . . Directory Facilitator

AMS . . . . . . . . . . Agent Management System

xiii

MTS . . . . . . . . . . Message Transport Service

ACL . . . . . . . . . . Agent Communication Language

TNB . . . . . . . . . . Thokar Niaz Baig

MTM . . . . . . . . . Muslim Town Mor

QoS . . . . . . . . . . . Quality of Service

SIMBA . . . . . . . . SIstema Multiagente Basado en ARTIS

TAPN . . . . . . . . . Timed-Arc Petri-Net

Chapter 1

Introduction

Formal modelling is the process of constructing mathematical model of software and hard-ware systems at some level of abstraction. Its basic purpose is to utilize the unambiguousnotation of formal methods and precisely specify and analyze the systems leading to their pre-cise understanding. This work has focused on the formal modelling of real-time self-adaptivemulti-agent systems, where the system’s domain functionality is provided by the autonomousworking agents. These real-time multi-agent systems by their working nature have highdegree of unpredictability in their execution context and require extensive analysis at the de-sign time before their implementation to ensure their correct functioning. This dynamism ofreal-time multi-agent systems has led to a new category of software systems called real-timeself-adaptive multi-agent systems. These systems possess the necessary knowledge to adapttheir behavior in real-time in response to the environmental context. A computer software sys-tem that works autonomously in an environment to achieve its objectives can be categorizedas an agent according to [1]. It is reserved by other processes and agents, but it can also learnfrom its experience during functioning in an environment over a longer period of time. Theseagents are expected to face unfamiliar situations with their confined knowledge. In real-timeenvironments these agents need to work collaboratively to achieve the common objectivewith minimum communication between them for timely response. An agent with restrictivetiming constraints is called a Real-Time Agent (RTA). The correct functioning of these RTAsdoes not solely depend on whether they complete the task, rather it depends on whether theycomplete the task within the deadline or not. Usually an off-line schedulability analysis isdone before these RTAs are deployed to make sure that these agents will meet their deadlines.Previously these RTAs have been classified as hard real-time agents and soft real-time agentsin [2]. In soft real-time agents there is a slight marginal period for the fulfillment of theirtemporal restrictions. A multi-agent system with at least one real-time agent is called aReal-Time Multi-Agent system (RTMAS). Self-adaptability endows a system with the ability

1.1 Motivation and Thesis Statement 2

of self-organization according to the changes in the user requirements and execution context,which ultimately leads to better fault tolerance in case of any failure. In [3–5] it has beenargued that the development of autonomous physical systems with real-time constraints isa challenging task. With self-adaptive real-time multi-agent systems the problem is morechallenging as the system have tight temporal constraints. Self-Adaptation should ensurethat the overall system’s functionality is not effected. Ideally to an external observer/user ofthe system the restructuring of the system as part of its self-adaptation should be as abstractas possible.

1.1 Motivation and Thesis Statement

For complex systems, their formal specification is devised at the conceptual design phasebefore the system is implemented. Such specifications describe the semantics of the systembeing implemented without the concern for the implementation details and can be used asa basis for the verification and validation of the system’s functionality. The precise andun-ambiguous notation of the formal specification enables the developer to express theirsystem rigorously and analyze it ensuring its consistency and completeness. Multi-agentsystems paradigm has emerged as a useful technique to model real-time systems like mobilerobots, online auction systems, intrusion detection systems, control processes, etc. Onereason for the popularity of multi-agent systems relates to the advances in computationalsystems, which are increasingly more distributed, open, large, and heterogeneous. Majorexamples are the paradigm of fog computing and cloud computing versus centralized serverbased control of some decades ago.

The main motivations for the formal modelling of real-time multi-agent system are :

• Currently we do not have a precise vocabulary for the specification of key architecturalcharacteristics of self-adaptive real-time multi-agent systems. Encompassing differentperspectives of self-adaptation into the real-time multi agent systems would help in theconstruction of such systems. Our proposed SMARTS framework will overcome thisrequirement.

• A clear distinction between the entities responsible for providing the system’s domainfunctionality and entities responsible for the self-adaptation would help in validatingthe system against user requirements. The SMARTS provides a clear distinctionbetween a managed system and a self-adaptive unit.

• Self-adaptation endows a real-time multi-agent system with the ability of self-organizationaccording to the changes in user requirements and the execution context. This ulti-

1.2 Our Contribution 3

mately leads to better fault tolerance in case of any failure without affecting the system’soverall functionality. Robust services can be provided due to their self-organizationcapability. The SMARTS make use of the state of the art MAPE-K feedback loop forthe provision of self-adaptation.

• Techniques like off-line schedulability ensures that the overall system’s entities willmeet its deadlines before its actual implementation and deployment.

• The system can take advantage of the decentralized nature of multi-agent systems andavoid having any single point of failure. Decisions are made using local point of viewand if necessary keeping using the global point of view.

• The autonomous working nature of agents makes them appropriate for modellingheterogeneous systems. A single agent has its own state and behavior deployed tosolve a particular problem. An arbitrary level of detail can be included into a simulationmodel or a problem-solving framework can be applied on the agent level.

• The standardization of inter-agent communication by international standards organiza-tion like Foundation for Intelligent Physical Agents (FIPA) makes interaction betweendiverse agent platforms using high-level abstractions. Thus, they provide an intuitivelevel of interaction between human users or modellers and the agent-based system.

The formal modelling of these multi agent systems with temporal deadlines and adaptationcapability will help to better analyze and understand them as safety is a major concern forthem [6–10].

1.2 Our Contribution

This work has focused on the formal modelling of real-time self-adaptive multi-agent systems,where the system’s domain functionality is provided by the autonomous working agents.We have proposed a framework for the formal modelling of real-time multi-agent systemsnamed SMARTS (Self-adaptive Multi-Agent Real-Time Systems). The framework makesuse of the SIMBA agent architecture as proposed in [11] and FORMS reference model foradaptation as proposed in [12]. Basic agents of SMARTS are ARTIS agents, which willprovide the system’s domain functionality. ARTIS agents have been designed to work indynamic environments with temporal constraints. The self-adaptive functionality is providedwith the help of MAPE-K interfaces. The interfaces are based on Monitor, Analyze, Planand Execute phases of the MAPE-K feedback loop. In programming the term interface

1.3 Related Work 4

refers to an abstract type that defines behaviors as methods. In contrast to the inheritance,a class can implement as many interfaces as required to provide the desired functionality.Interfaces are especially useful at the design time to make classes inter-operable becauserather than specifying a particular class, the type of the object to be exchanged can bespecified in terms of its interface. The proposed framework can be used for the architecturalspecification of any self-adaptive real-time multi-agent system. Though our framework isFoundation for Intelligent Physical Agents (FIPA) compliant and supports communicationwith agents of other platform but such communication with other agent platforms may preventthis real-time behavior. A system’s designer should thus decide which features the ARTISagents are going to have. For readability we elaborate SMARTS framework using UMLnotations in this work. For a precise semantic description of the constructs we use TimedCommunicating Object-Z (TCOZ) language. In SMARTS the non-terminating behavior ofthe ARTIS agent is represented using active class concept of TCOZ. For communicationbetween active processes, channel communication mechanism of TCOZ is utilized. Weelaborate the application of SMARTS framework using a trivial case-study of Lahore TrafficManagement System for real-time congestion control. We ensure the correctness of thesystem by formally specifying and verifying the actions of the communicating real-timeagents in Timed-Arc Petri-Net’s. Timed-Arc Petri-Net’s being visually more expressivethan Linear Tree Logic (LTL) and Computational Tree Logic (CTL) provides a richerframework for such formalism [13]. The traffic models are verified used AF, AG, EG, and EFfragments of Timed Computational Tree Logic (TCTL) via translations to timed automata.We used TAPAAL model checker for the formal verification. The simulation results show thecomputation tree of the traffic model, trace of the satisfied properties, count of the transitionstriggered and places visited during the verification process. Formal verification of thesesystems will increase the confidence in the correctness of such systems.

1.3 Related Work

A comprehensive review of the related work reveals that multi-agent systems have beenformally specified and verified by many in the past but not self-adaptive real-time multi-agentsystems. A Unified Modeling Language and Architecture Description Language basedframework for formal modelling of multi-agent systems has been proposed in [14]. Foragent communication they used a service agent that accepts Knowledge Query ManipulationLanguage (KQML). In [15] Stanford Research Institute (SRI) have proposed an agentframework called Open Agent Architecture (OAA) that used a language called Inter-agentCommunication Language (ICL) using a facilitator agent. Formal verification of e-agent’s

1.3 Related Work 5

communication has been examined in detail previously. In [16] verifiable semantics based oncomputational models was proposed. Giordano has used Dynamic LTL Logic for specifyingand verifying agent communication properties in [17, 18]. In DLTL we express the programsas regular expressions and specify the communicative actions as precondition laws, causallaws and constraints. The use of model checking for verification of e-agents has beendiscussed in [19] using Belief-Desire-Intention (BDI) attitudes. They used a new logic whichwas the composition of formal temporal evolution and formal BDI attitudes. A processalgebra based approach for agent’s communication was discussed in [20]. They established alink between mathematical models and biological systems. In [21] petri-nets have been usedfor the modelling of railway networks to ensure the safety and deadlock free requirements.In [22] two techniques of formal methods namely Z-notation and X-machine for the formalspecification of multi-agent systems have been used with a dynamic behavior and structure.In [23] a new XML based language called MASDL has been proposed for the specification ofmulti-agent systems in coloured petri nets. Mutli-agent systems have been modelled in [24–26] using petri-nets but not RTMAS. [8] provides QoS services for RTAgent’s communication.In [16] verifiable semantics based on computational models have been proposed for e-agent’scommunication. In [27] a framework for communication among e-agents was presented.In particular they used different languages for the specification of communication amonge-agents. The use of model checking for verification of e-agents has been discussed in[19] using Belief-Desire-Intention (BDI) attitudes. They used a new logic which was thecomposition of formal temporal evolution and formal BDI attitudes. A process algebra basedapproach for e-agent’s communication was discussed in [28]. They proposed new semanticscalled ACPL which models the basics of agent communication. They used the informationprocessing aspects of Concurrent Constraint Programming (CCP) with a generalization ofthe synchronous handshaking communication mechanism of Communicating SequentialProcesses (CSP).

[29] have formally modelled real-time systems using an extension of the Rebeca language.They used Structural Operational Semantics for modeling distributed systems with temporalconstraints. In [30] a new language named STeC (an extension of process algebra) hasbeen proposed for the formal specification of location-trigger real-time systems. In [31] amulti-agent system approach has been presented for the real-time operation of schedulingand demand management in microgrids. [32] has presented a new model-checker namedMCMAS for the formal verification of multi-agent systems. Their model checker can be usedto verify the epistemic, strategic and temporal properties of interest for these multi-agentsystems. [33] have presented a new combined model checking approach for eliminating theproblem of introducing new logics for the verification of different aspects of multi-agent

1.3 Related Work 6

systems like knowledge and time, knowledge and probability, real-time and knowledge, etc.This will help to reduce the problem of having different model checking tools targetingdifferent aspects of multi-agent systems. In [34] hierarchical real-time systems have beenformally modelled and verified using an extension of Timed CSP called Stateful Timed CSP.Majorly they solved the problem of verification with non-Zeroness assumption. In [12] aframework for formal modelling of distributed self-adaptive systems has been proposed calledFORMS, which provides different modelling elements and a set of relationships guidingthe design of self-adaptive software systems. [35] have proposed a real-time multi-agentarchitecture for Intrusion Detection System called RT-MOVICAB-IDS. Their architectureensures that the agent’s response (reflex or deliberative) conforms to temporal constraints ofthe system in case of an intrusion. In [36] a cooperative motion and task planning schemefor multi-agent systems has been proposed. According to their scheme the agent’s tasks,categorized with hard or soft deadlines are specified as Linear Temporal Logic formulas. Thetasks with hard temporal constraints are always executed within the deadline and the agenttries to improve the result for soft deadline. [37] presented an extension of Computation TreeLogic called RTCTLcc for the specification of real-time properties of multi-agent systems.They argued that RTCTLcc can be used to formally model the interaction among agents withtemporal constraints.

In [38] a technique for controlling decentralized multi-agent systems using LTL specifica-tions have been proposed. An eclipse based CASE tool for the development and verificationof multi-agent systems comprising heterogeneous agents has been discussed in [39]. Theyused model checking approach for the verification of such systems. Multi-agent systemshas been formally specified in [40] using Object-Z with trace semantics. They focused onsafety and liveness properties of these systems. [41] presented a prototyping approach forformal modelling of multi-agent systems. Their framework described the key entities likeorganization, role and interaction using a language called OZS, which is a formal languagecombining Object-Z and state-charts. [42] have specified distributed multi-agent systemsusing TCOZ which is a combination of Object-Z and Timed CSP. The work of [43] has fo-cused on handling fault-tolerance in multi-agent system’s interaction using Event-B Patterns.Event-B is formal technique used for modelling distributed systems to analyze the system. In[44] Object-Z has been used to formally model the incremental development of multi-agentsystems. Basically they introduced a notion of action refinement for agent decision-makingand inter-agent negotiations in Object-Z. [45] has proposed timed automata based behaviorspecification and property specification templates based on MAPE-K feedback loop for theformal modeling of self-adaptive systems. However their templates are not directly applicableto the multi-agent system’s domain. [46] have comprehensively analyzed the self-adaptive

1.3 Related Work 7

software systems to tackle the problem of assuring that the system provides its domainfunctionality under uncertain conditions. [47] proposed an analytical framework for thearchitectural reasoning of self-adaptive systems. Their framework extended the ArchitecturalReasoning Framework (eARF) to ensure that the design complies to the requirements forsingle product instance. Time-extended models like timed automata have been proposed forthe formal verification of real-time systems in [48, 49], but not for multi-agent systems.

Additionally many researchers have proposed several frameworks for constructing sys-tems with self-adaptation capability. In [50] different stages of self-adaptation has beenidentified as MAPE-K conceptual framework. According to [51] any self-adaptive sys-tem feedback-control loop is an essential activity. In [52] an architectural model has beenpresented for adaptivity which divides change management, component control and goalmanagement into three different levels. A software architecture-based approach has beenrecommended in [53–55] for change management and assessing the adaptation decisions. ATimed CSP based approach for the specification and verification of embedded distributed real-time systems has been proposed in [56] but not for RTMAS. They extended their approachfor formal modelling of self-adaptive distributed real-time systems in [57]. Multi-agentsystems have been formally specified and verified using modal mu-calculus and Timed-ArcPetri-nets in [13, 58]. It has been argued in [59–67] that formal methods should be used forthe verification of safety critical and real-time systems to ensure their correct functioning.

[68] have proposed a Tele Assistance System (TAS) to compare the effectiveness ofdifferent solutions for self-adaptive systems. Its another purpose is to enhance understand-ing among researchers in the domain of self-adaptive systems. In [69] a framework forcomponent-based multi-agent systems has been proposed for their formal verification. Majorentity of their approach the is Agent Verification Engine (AVE). AVE handles the Belief-Desire-Intention (BDI) agents to verify the complete system after a component has beenadded/removed from the system. [70] proposed a extended MAPE-K feedback loop todeal with uncertainty in self-adaptive systems with predefined set of rules. Their approachrequires a structured knowledge base comprising a global goal model, environment model,abstract system and current adaptation rules. With their approach new rules are generated atrun-time and the adaptation logic itself becomes dynamic. [71] have integrated Model-drivenengineering and agent-oriented software development for the development of multi-agentsystems. [72] have formally modelled autonomous multi-agent systems for the targeted drugdelivery. They simulated the nanorobots using agent technology to demonstrate the futurepossibilities of drug delivery system using multi-agent systems. [73] presented a Event-Bbased formal modeling technique for multi-agent systems with self-organizing ability. Theirtechnique uses a step-wise refinement for individual agent’s behavior, which in turn enable

1.4 Layout of the Thesis 8

the verification of properties for the complete system. In [74] a model checking techniquefor formally verifying the scheduling activities of robotic assistants for humans has beenproposed by translating the requirements to the model checker’s language i.e PROMELA. Amulti-agent system’s approach with self-adaptive ability for collaborative mobile learninghas been proposed in [75]. They discussed the issues of node failure and resource availabilitydue to system dynamism and environment and how to tackle it with self-adaptation. [76]presented a two-layer approach for the development of self-adaptive multi-agent system inopen environment. The two layers corresponds to self-adaptation at the agent’s behaviorlevel and agent’ organization level. [77] proposed a self-adaptive multi-agent systems forsolving the satellite mission planning. They focused collective planning among agents foreffective load balancing. [78] have used self-adaptive multi-agent systems for solving the carpooling problem. Their approach is based on dynamic heuristics for the systems learning pro-cess. Self-adaptive multi-agent system’s and their interaction has been discussed in [79, 80].[81–88] has presented an in depth analysis of the challenges, application and approaches ofself-adaptive systems. Formal verification of self-adaptive systems has been carried out in[89].

Lastly the paradigm of self-adaptive multi-agent systems has been used in maritimesurveillance [90–92], Smart Office [93], intelligent strategic marketing [94], large scale su-pervisory control and data acquisition (SCADA) systems [95], re-configurable manufacturingsystems [96–98], managing workflows in business processes [99], supply chain management[100–103], autonomous vehicle navigation [104–107], software quality [108], Internet ofThings [109, 110], reinforcement learning [111–115], wireless sensor networks [116, 117],flood forecast [118], intrusion detection systems [119], decision support systems [119] andcloud computing [120–123]. It has been argued in [124–128] that self-adaptive multi-agentsystems are very expressive for modelling complex systems with high dynamism.

1.4 Layout of the Thesis

The rest of the thesis is structured as follows. Chapter-2 gives a summarized overview ofthe MAPE-K feedback loop, ARTIS agent architecture, SIMBA agent architecture, TCOZlanguage and Timed-Arc Petri-nets. These preliminaries will be required for thorough under-standing of the research work presented. Chapter-3 presents the comprehensive overview ofthe proposed SMARTS framework and its formal specification in TCOZ. The specificationcontains the major entities related to the managed system and self-adaptive system. Chapter-4shows the application of SMARTS framework to a real-world problem of traffic monitoringsystem. SMARTS has been applied to two traffic signals of Lahore region including Muslim

1.4 Layout of the Thesis 9

Town Mor and Thokar Niaz Baig. Their formal model has been presented in TAPPAL modelchecker and the properties of interest are verified using fragments of CTL. Finally chapter-5presents the concluding remarks and discussions.

Chapter 2

Preliminaries

A few terminologies have been described in this section that will be used in the rest of thediscussion for the specification of the problem under analysis.

2.1 MAPE-K Feedback Loop

A self-adaptive system typically consists of a managed system which provides the domainfunctionality and a feedback loop that deals with the architectural adaptations of the system.Architecture-based adaptation requires a system to interact with the environment, reasonabout its models based on the stimulus received and then adapt itself. The feedback loop isknown as MAPE-K and it was proposed in [50]. The MAPE represents Monitor, Analyze,Plan, and Execute phase, whereas the K represents the models of the system, its environmentand adaptation goals. We refer the reader to [50] for details concerning the MAPE-K feedbackloop.

2.2 ARTIS Agent Architecture

ARTIS agent architecture was proposed in [129] and it is an extension of the blackboardmodel that has been modified to work in environments with hard temporal constraints.This agent guarantees that it will meet its temporal constraints by the use of an off-lineschedulability analysis. Agent’s perception occurs through a set of sensors and the system’sresponse is exhibited using a set of effectors. These perception and action processes arereal-time in nature. The agent has two different categorization of processes namely reflexprocess and a deliberative process. Every ARTIS agent has a number of internal agents(In-agent) that provides the domain functionality. Every In-agent is designed to solve a

2.3 SIMBA Agent Architecture 11

particular problem and it is characterized as critical or acritical. A critical In-agent hasa period and a deadline and the agent must perform its operations within those deadlines.In other words it provides the minimum system functionality. On the contrary acriticalIn-agent can utilize artificial intelligence techniques to better achieve the system goal. EveryIn-agent has two layers namely reflex layer and real-time deliberative layer. When a taskarrives for execution the In-agent checks the deadline if it can provide a response via areal-time deliberative layer. The real-time deliberative layer provides an improved responseas compared to reflex layer, hence it needs more time. The reflex layer only provides aminimal quality response. The mandatory phase of an ARTIS agent consists of reflex layersof all the In-agents it has. Similarly the real-time deliberative layers of all In-agents makesup the optional phase of an ARTIS agent. A reflex layer is absent in a acritical In-agents andonly the real-time deliberative layer is present. For real-time environments all the In-agentsare critical in nature. Each In-agent has a set of beliefs comprising the domain knowledgerelevant to it. Each ARTIS agent has a Control Module which controls the execution of allthe In-agents that belongs to it. It is divided into two sub modules namely the Reflex server(RS) and the Deliberative server (DS). Reflex server controls the execution of tasks withcritical temporal restrictions. Deliberative server controls the execution of deliberative tasks.

2.3 SIMBA Agent Architecture

The SIMBA (SIstemaMultiagente Basado en ARTIS) agent architecture was proposed in[11] for RTMAS. It is an extension of the ARTIS agent architecture proposed in [129].Basically this architecture is formed by the collaboration of multiple ARTIS agents deployedin environment with strict temporal restrictions. Major advantage of SIMBA architectureis that it is FIPA-compliant and allows communication between diverse agent platforms.Foundation for Intelligent Physical Agents (FIPA) is a standards organization for agents andmulti-agent systems. Its specifications contain standards to promote the inter-operation ofheterogeneous agents between diverse agents and agent-platforms. FIPA-compliance requiresan agent architecture to at least implement the Agent Communication Language specificationand Agent Management specification. The Agent Management specification requires anagent architecture to implement a Directory Facilitator (DF) and an Agent ManagementSystem (AMS). DF will provide yellow-pages service to the agents involved. AMS willmaintain the addresses of all the agents registered in the platform (white-pages service).The agent communication language specification enforces a standard message format to beused in agents communication. Within every SIMBA architecture there is a single SIMBA

2.4 TCOZ Language 12

Communicator Agent which serves as a mediator agent for inter and intra-platform agentcommunication.

2.4 TCOZ Language

TCOZ is a formal specification language and was first proposed in [130]. It is a assimilationof Object-Z and Timed Communicating Sequential Processes (CSP). Object-Z incorporatesobject-oriented paradigm into the standard Z formal specification language. It provides pre-vailing features for recitation of complex data structures and their operations. Incorporationof object-oriented paradigm improves the clarity of formal specifications documents throughenhanced structuring. However Object-Z lacks the operators for determining the duration ofthe operations and assumes that all the operations are atomic. Because of these limitationsit is intricate to use Object-Z for real-time concurrent systems modelling. Timed CSP isa real-time extension of CSP notation and does not have significant modelling elementsto encapsulate the state of a system. Hence both Timed CSP and Object-Z supplementeach other in their perspicuity. The approach taken in TCOZ is to identify the operationschemas with CSP processes that perform only state update events. Non-terminating CSPprocesses are represented by active classes in TCOZ. It also provides special channel-basedcommunications for inter-process communication.

We have used the following data types and symbols of TCOZ language for the formalspecification of our SMARTS framework. P represents the power set of defined any type.T represents the time. N represents the set of natural numbers. BOOL represents theboolean attribute. The data type chan represents a channel for inter-process and intra-processcommunication. The constant SKIP will be used to show the termination of any process. The2 symbol represents a choice between a number of processes. The symbol ∆ represents achange in an attribute. The inputs are modelled by components of the schema decorated with?, and the outputs by components decorated with !. The ′ symbols denotes the state of anattribute after an operation has been executed. The appearance of MAIN symbol in a schemadenotes that a class is an active object. The =̂ denotes a process definition.

2.5 Timed-Arc Petri-Nets

A Timed Arc Petri-Net (TAPN) is a 7-tuple (P,T, IA,OA,c, i,Type) where P is a finite set ofplaces. T is a finite set of transitions such that P∩T =∅. IA⊆P×T is a finite set of input arcs.OA⊆ T×P is a finite set of output arcs. c : IA→I assigns intervals to input arcs. i : P→Iinv

2.5 Timed-Arc Petri-Nets 13

assigns age invariants to places. Type : IA∪OA →{Normal, Inhib}∪{Transporti | i ε N} isa function assigning a type to all arcs such that

• Type(a) = Inhib ⇒ a ε IA∧ c(a) = [0,∞)

• Type(p, t) = Transportl ⇒∃!(t,p′) ε OA.Type(t,p′) = Transportl and

• Type(t,p′) = Transportl ⇒∃!(p, t) ε IA.Type(p, t) = Transportl,

In a TAPN that is k-bounded we represent a Token as an element from 1,2, . . . , k.A marking M is a pair (pl,v) where pl : {1,2, ...,k} → P⊥ is the placement function andv : {1,2, ...,k}→ R ≥ 0 is the age function. A transition t ε T is enabled by a set of tokensIN ⊆ {1,2, ...,k} in a marking (pl,v) if

(i) t = {pl(i) | i ε IN}

(ii) v(i) ε c(pl(i), t)for all i ε IN

(iii) Type(pl(i), t) = Transport ⇒ v(i) ε i(move(pl, IN, t)(i))for all i ε IN

(iv) (pl(i), t) ε IA ⇒ Type(pl(i), t) ̸= Inhib for all i ε {1,2, ...,k} IN.

A transition t enabled in a marking (pl,v) by the set of tokens IN can fire, producing amarking (move(pl, IN, t),vR=0) where R = {i ε IN | Type(pl(i), t) ̸= Transport}. Theseformulation will be used in order to specify the actions of the communicating agents.

Chapter 3

Proposed SMARTS Framework

3.1 Overview of the Self-adaptive Multi-Agent Real-TimeSystems (SMARTS) Framework

An overview of the SMARTS’s primitives are provided in Figure 3.1, while the TCOZspecifications of the framework is provided in the next section. The shaded entities infigure are part of the SMARTS framework and the un-shaded entities are taken from theFORMS reference model [12]. As shown in the figure, a distributed self-adaptive system is aself-adaptive system comprises one or more local self-adaptive multi-agent systems. A localself-adaptive multi-agent system comprises multiple local managed systems, self-adaptiveunits and a single SIMBA communicator agent. A local managed system provides domainfunctionality of the system in the form of ARTIS agents. An ARTIS agent corresponds to asingle local managed system. A local managed system is a subsystem comprising multipleIn-agents, a set of domain models, a single dynamic agent organization and a single controlmodule.

A model is a representation describing entities of interest in the physical or conceptualworld. A domain model contains representations of entities necessary for the provision ofrequired features. An environment comprises of attributes and processes and correspondsto both conceptual and physical entities. An attribute is any observable characteristic ofthe environment. A process represents any activity that can modify the attributes of theenvironment. As described previously an In-agent is an agent configured to solve a particularproblem. It periodically performs a specific task. An ARTIS agent will autonomously workin an environment and execute the required tasks with the help of In-agents by readingfrom and writing to the domain model. A self adaptive unit is a subsystem responsible forimplementing the adaptation process in a computing system. It can manage multiple local

3.1 Overview of the Self-adaptive Multi-Agent Real-Time Systems (SMARTS) Framework15

managed systems and some other self-adaptive units. It will manage another self-adaptiveunit in case of more than one reflective levels in the system. It comprises of multiple reflectionmodels and reflective computations. A reflection model is similar to meta-data and providesconcrete instances of entities needed for adaptation. It corresponds to architectural modelsof the system. A reflective computation is analogous to an In-agent but it acts and reasonsabout the reflection models. It is responsible for environment monitoring to determine therequired adaptations. A reflective computation is not capable of changing the environmentdirectly and needs support from other agents for doing so. A local reflective computation isbasically a reflective computation with coordination mechanism. The coordination mech-anism provides an ability so that the agents providing domain functionality and the localreflective computations can coordinate with other in the same layer.

SMARTS’s coordination mechanism consists of a coordination protocol and a coordina-tion model, while coordination model contains information like coordination partners, theirroles, ongoing interaction’s information, entity representations needed by the local reflectivecomputation to communicate with other self-adaptive unit’s reflective computations. Thecoordination protocol is basically a set of rules for governing the communication amongthe entities. For communication within the system, TCOZ channel communication will beutilized. The channel will be an abstraction for communication (message exchange or sharedtuple spaces) between entities. The dynamic agent organization manages grouping of theagents in the form of master/slave relationships. Agent in the role of master will manage thedynamics of its organization by communicating with all the slaves/master agents of neighbor-ing organizations. By default an ARTIS agent is a member of a single organization. MultipleARTIS agents can however merge in one organization depending upon the circumstances.

3.1 Overview of the Self-adaptive Multi-Agent Real-Time Systems (SMARTS) Framework16

Fig.

3.1

Prop

osed

SMA

RT

Sfr

amew

ork.

3.2 TCOZ Specification of the SMARTS Framework 17

3.2 TCOZ Specification of the SMARTS Framework

In the following sections we give formal specification of all the entities of the SMARTSFramework.

3.2.1 Environment Representation

An environment comprises of attributes and processes and corresponds to both conceptual andphysical entities. An attribute is any observable characteristic of the environment. A processrepresents any activity that can modify the attributes of the environment. An environmentwill keep on updating itself after certain time units. With each update event the new attributesare available at the output channel.

Environment

attributes : PAttributeprocesses : PProcessc : chan

INIT

attributes ̸=∅processes ̸=∅

Update∆attributes∆processes

c! = attributes

MAIN =̂ µ T • (Update • WaitUntil 1s); T

3.2.2 Model and Domain Model Representation

A model is a representation describing entities of interest in the physical or conceptualdomain. Concrete models can have different types of representations. Models are specifiedas generic constant.

[Model[Representation]]rep : PRepresentation

rep ̸=∅


A domain model contains representations of entities necessary for the provision ofrequired features. Here EnvironmentRepresentation specifies the attributes of the environment.Domain model is specified as a passive class. The channel c is used for communication withany active class.

DomainModelModel[EnvironmentRepresentation]map : PAttribute ↔ EnvironmentRepresentationenvr : chan

dommap ⊆ {attrs : PAttribute | attrs ⊆ envr?.attributes}ranmap = {r : EnvironmentRepresentation | r ∈ rep}

3.2.3 Entities for Domain Functionality

A passive class named Task is specified to represent any task in the system. Each task requiresa single resource for certain duration without which it cannot execute. For brevity we haveonly handled the case of one resource per task but the approach can be extended for multipleresources per task. The ReflexExecute operation models the execution of a task when theagent executing it does not have the extra time to improve the result. The DeliberativeExecutemodels the execution of a task when it has soft deadline. The variable length represents theexpected amount of time which the task will take to execute. In SMARTS length is consideredas the deadline before which the task should have executed. margin represents additional timefor the soft deadline. In case a margin is available for a task then the DeliberativeExecuteprocess will be executed.

TaskType ::= REFLEX | DELIBERATIVEAgentType ::= INAGENT | ARTISAGENT

Task

resource : Resourcelength : Tmargin : T

INIT

length > 0


ReflexExecute∆length

δ = lengthlength′ = 0

DeliberativeExecute∆length

δ = length+marginlength′ = 0

Each agent can be uniquely identified by an id. We specify the type id as

ID == N

Every In-agent is configured to solve a particular type of task. No In-agent can occupymore than one resource at any given time. An execution of a task necessitates that theIn-agent executing it has the required resource for the needed duration. This condition isspecified as a predicate in task execution. An In-agent might get multiple requests to solvethe same type of tasks. To ensure the autonomous working of In-agents they are specifiedas an active object. The set tasks represent those tasks for which the In-agent has beenconfigured. The set agents represent those In-agents that are part of the same ARTIS agent.alloc maps resources to the In-agents. Since an active class can only communicate with otheractive class via channels so an In-agent has channel c to communicate with ARTIS agent.The id represents unique identifier of the agent.

InAgent

id : Ntasks : PTaskalloc : (Resource×T)→ InAgentc : chanmargin : Nstate : PStatetype : AgentType

∀r1,r2 : Resource; t : T r1 ̸= r2 • alloc(self ,r1, t) ̸= alloc(self ,r2, t)


INIT

type = INAGENTrequests =∅

CanExecuteDeliberatelytask? : Task

task? ∈ tasks ∧∃currentTime == clock.time; l == task?.length; r == task?.resource •currentTime..currentTime+ l+margin ⊆ {t : T | alloc(r, t) = self}

ExecuteTask =̂ [task? : Task] • ((CanExecuteDeliberately∧ task?.DeliberativeExecute)2(!CanExecuteDeliberately∧ task?.ReflexExecute))MAIN =̂ µ T • [tasks ̸=∅] • ExecuteTask; T

3.2.4 Entities for Inter and Intra Platform Agent Communication

The DF provides yellow-page services to the platform agents. Agents of the platform registerwith the DF. This allows one agent to trace other agents that are providing the services itrequires. The method RegisterARTISAgent will register an ARTIS agent with the directoryfacilitator. There is only one DF in each platform. We specify an entity ServiceDescriptionto represent the different services in the platform. A service has a name and type only andcorresponds to a summarized overview of the different services the agents are providing inthe platform.

ServiceDescription

type : Nname : N

INIT

type ̸=∅name ̸=∅


DirectoryFacilitator

inagents : P InAgentartisagents : PARTISAgentservices : PServiceDescriptionc : chan

INIT

requests =∅

RegisterInAgent′

agent? : InAgentservices? : PServiceDescription

inagents′ = inagents∪{agent}services′ = services∪{agent.services}

RegisterARTISAgent′

agent? : ARTISAgentservices? : PServiceDescription

artisagents′ = artisagents∪{agent}services′ = services∪{agent.services}

PublishServices =̂ c!services → SKIPSearchService =̂ [name : N; type : N] •(∃s : services | s.name = name ∧ s.type = type) • c!s → SKIPRegisterInAgent =̂ [agent? : InAgent; services? : PServiceDescription] •RegisterInAgent′ → SKIPRegisterARTISAgent =̂ [agent? : ARTISAgent; services? : PServiceDescription] •RegisterARTISAgent′ → SKIPMAIN =̂ µ T • (PublishServices2SearchService2RegisterInAgent2RegisterARTISAgent); T

AMS is responsible for providing white-pages service and maintains the identifiers of allthe agents in the platform. It ensures that each agent in the platform has a unique identifier. Itperforms several management tasks as well, such as creating and destroying agents. There isonly one AMS in each platform and all agents must be registered in the AMS. The operationAddARTISAgent and AddInAgent will create an instance of ARTIS Agent and In-agentrespectively with unique identifiers. The lsamas represents a channel with which the AMSwill communicate with LocalSelfAdaptiveMultiAgentSystem. We use two parameterizedmethods CreateNewAgent and RemoveAgentByIdentifier for creating and destroying agents


in the platform respectively. The method CreateNewAgent takes as input the agent type andcreates an instance with unique identifier. The method RemoveAgentByIdentifier removes anagent from the platform by taking the agent identifier and type.

AgentManagementSystem

inagents : InAgentartisagents : ARTISAgentlsamas : chan

AddARTISAgent′

agent : ARTISAgent

agent : CreateNewAgent[type = ARTIS]artisagents′ = artisagents∪{agent}#artisagents′ = (#artisagents+1)

AddInAgent′

agent : InAgent

agent : CreateNewAgent[type = INAGENT]inagents′ = inagents∪{agent}#inagents′ = (#inagents+1)

RemoveARTISAgent′

id? : N

RemoveAgentByIdentifier[type = ARTIS, id]#artisagents′ = (#artisagents−1)

RemoveInAgent′

id? : N

RemoveAgentByIdentifier[type = INAGENT, id]#inagents′ = (#inagents−1)


RemoveARTISAgent =̂ [id? : N,result : BOOL] • RemoveARTISAgent′

→ lsamas!(result)→ SKIPRemoveInAgent =̂ [id? : N,result : BOOL] • RemoveInAgent′

→ lsamas!(result)→ SKIPAddARTISAgent =̂ [agent! : ARTISAgent] • AddARTISAgent′

→ lsamas!(agent)→ SKIPAddInAgent =̂ [agent! : AddInAgent] • AddInAgent′

→ lsamas!(agent)→ SKIPMAIN =̂ µ T • (RemoveARTISAgent2RemoveInAgent2AddARTISAgent2AddInAgent); T

SIMBA communicator agent is a mediator agent and makes the communication possiblewith agents of other platforms. It is equivalent to Message Transport Service (MTS), support-ing the communication of FIPA Agent Communication Language (ACL) messages betweenagents of inter-platform and intra-platforms. The channels df , ams are used to communicatewith DF and AMS of the agent platform respectively. mts represents mediator agents ofother agent platforms with which SIMBA communicator agent is interacting. The SIMBAcommunicator agent can send message to any agent within the platform by using the methodSendMessageWithinAgentPlatform. It can also communicate with any of the agent of someother platform by using the method SendMessageAcrossAgentPlatform.

SIMBACommunicatorAgent

df ,ams : chanmts : PMessageTransportServiceinagents : P InAgentartisagents : PARTISAgent

INIT

inagents ̸=∅ ∧ artisagents ̸=∅

SendMessageWithinAgentPlatform′

message? : Messagesender? : AgentTypereceiver? : AgentType

(sender ∈ inagents ∨ sender ∈ artisagents)∧ (receiver ∈ inagents ∨ receiver ∈ artisagents)SendMessage(sender,receiver,message);


SendMessageAcrossAgentPlatform′

message? : Messagesender? : AgentTypereceiver? : AgentTypemts? : MessageTransportService

{∃agent ∈ inagents | agent = (sender ∨ receiver)}∨ {∃agent ∈ artisagents | agent = (sender ∨ receiver)}SendMessage(sender,receiver,mts,message);

SendMessageWithinAgentPlatform =̂ [message? : Message; sender? : Agent;receiver? : Agent] • SendMessageWithinAgentPlatform′ → SKIPSendMessageAcrossAgentPlatform =̂ [message? : Message; sender? : Agent;receiver? : Agent; mts? : MessageTransportService] •SendMessageAcrossAgentPlatform′ → SKIPMAIN =̂ µ T • (SendMessageWithinAgentPlatform2

SendMessageAcrossAgentPlatform); T

A coordination mechanism contains coordination protocol and a coordination model.

[CoordinationMechanism[Protocol,Model]]protocol : Protocolmodel : Model

3.2.5 Entities for the Provision of Domain Functionality

Each ARTIS agent manages multiple In-agents to provide the domain functionality. Itincludes a set of domain models. There should be at least one In-agent for any ARTIS agent.We use a function SUM which will return the sum of all the tasks of In-agents controlled byan ARTIS agent. The action AddTask′ represents the scenario when a task is assigned to thisARTIS agent. It searches the most suitable In-agent that can execute the task and assign him.Similarly the action RemoveTask′ specifies the scenario when a task is either completed or itis no longer needed. The task is removed from the ARTIS agent and In-agent’s knowledgebase.


ARTISAgent

id : Nagents : P InAgentmodels : PDomainModeltasks : PTaskc : chantype : AgentTypestate : PStatecm : ControlModulereadAction : PDomainModel×PState → PStatewriteAction : PState×PDomainModel → PDomainModelperceiveAction : PState×Context → PStateeffectAction : PState×Context → Context

dom tasks ⊆ SUM(∀agent : agents • agent.tasks)

INIT

agents ̸=∅models ̸=∅tasks ̸=∅type = ARTISAGENT

AddTask′

∆models∆taskst? : Taskdm? : PDomainModeldm! : PDomainModelagent? : InAgent

dm? ⊆ models ∧tasks′ = tasks∪{t} ∧dm! = writeAction(state,dm?) ∧models′ = models\dm?∪dm! ∧agent.tasks′ = agent.tasks′∪{t}


RemoveTask′

∆models∆taskst? : Taskdm? : PDomainModeldm! : PDomainModelagent? : InAgent

tasks ̸=∅dm? ⊆ models ∧tasks′ = tasks\{t} ∧dm! = writeAction(state,dm?) ∧models′ = models\dm?∪dm! ∧agent.tasks′ = agent.tasks′\{t}

AddTask =̂ [t? : Task; agent? : InAgent; dm? : PDomainModel] • c?(t,agent,dm)→ cm.AnalyzeTask → AddTask′ → c!(dm)→ SKIPRemoveTask =̂ [t? : Task; agent? : InAgent; dm? : PDomainModel]• c?(t,agent,dm)→ RemoveTask′ → c!(dm)→ SKIPMAIN =̂ µ T • (AddTask 2 RemoveTask); T

Each ARTIS agent has a single control module that controls the execution of tasks by theIn-agents belonging to this ARTIS agent. It is divided into two sub-modules namely Reflexserver (RS) and the Deliberative Server (DS). The RS controls the execution of componentswith critical temporal restrictions. The DS controls the execution of deliberative components.Control Module ensures that only tasks that can be executed (within the temporal restrictions)are added to the system.

ControlModule

result : BOOLartis : chanrs : ReflexServerds : DeliberativeServer

AnalyzeTask =̂ [task? : Task] • artis?task → (ds.CanDeliberativeExecute ∧task.type = DELIBERATIVE ∧ artis!.result)2(rs.CanReflexExecute ∧task.type = REFLEX ∧ artis!.result)

A ReflexServer is part of the control module that handles all the critical tasks i.e tasks forwhich no time period is available for their execution.


ReflexServer

c : chan

CanReflexExecutetask? : Task

∃currentTime == clock.time; l == task?.length; r == task?.resource •currentTime..currentTime+ l ⊆ {t : T | alloc(r, t) = self}

A DeliberativeServer is part of the control module that handles all the acritical tasks i.etasks for which an improved systems response can be generated.

DeliberativeServer

c : chanmargin : N

CanDeliberativeExecutetask? : Task

∃currentTime == clock.time; l == task?.length; r == task?.resource •currentTime..currentTime+ l+margin ⊆ {t : T | alloc(r, t) = self}

A computation is an activity that manages its own state. Its current status is representedby attribute state.

Computation

state : PStatecompute : PState ↔ PState

domcompute = {s : PState | s ⊆ state}

INIT

state ̸=∅


ComputationOp∆state∆computes?,s! : PState

s! = compute(s?) ∧state′ = state\s?∪ s!

A local managed system contains multiple domain models and an ARTIS Agent. Eachlocal managed system corresponds to a single ARTIS Agent.

[LocalManagedSystem[Protocol,Model]]agent : ARTISAgentmodels : PDomainModel

3.2.6 Entities for Self-Adaptive Functionality

A reflection model is similar to meta-data and provides concrete instances of entities neededfor the adaptation. It corresponds to architectural models of the system.

ReflectionModelModel[ReflectionModelRepresentation]

A reflective computation is analogous to an In-agent but it acts and reasons about thereflection models. It is responsible for environment monitoring to determine the requiredadaptations. A reflective computation is not capable of changing the environment directlyand needs support from agents for doing so.

[ReflectiveComputation[LocalManagedSystem]]Computationread : PReflectionModel×PState → PStatewriteAction : PState×PReflectionModel → PReflectionModelperceiveAction : Context×PState → PStatesenseAction : PLocalManagedSystem×PState → PStateadaptAction : PLocalManagedSystem×PState → PLocalManagedSystemtriggerAction : PState×PReflectiveComputation[LocalManagedSystem]→PReflectiveComputation[LocalManagedSystem]


A local reflective computation is basically a reflective computation with coordinationmechanisms.

[LocalReflectiveComputation[LocalManagedSystem,Protocol,Model]ComputationcoordinationMechanism : CoordinationMechanism[Protocol,Model]readAction : PReflectionModel×PState → PStatewriteAction : PState×PReflectionModel → PReflectionModeltriggerAction : PState×PLocalReflectiveComputation[LocalManagedSystem,Protocol,Model]→ PLocalReflectiveComputation[LocalManagedSystem,Protocol,Model]senseAction : PLocalManagedSystem×PState → PStateadaptAction : PLocalManagedSystem×PState → PLocalManagedSystemperceiveAction : Context×PState → PState

An overview of the MAPE-K Interfaces is provided in the Figure 3.2. In [131] we havediscussed application of these MAPE-K interfaces in detail. A TCOZ specification of theinterfaces is provided along with.

Sense()GetData()UpdateKnowledge()Trigger()

<<interface>>Monitor

GetData()AnalyzeResources()UpdateKnowledge()Trigger()

<<interface>>Analyze

DevisePlanForUnsatisfied()DevisePlanForSatisfied()Trigger()

<<interface>>Plan

AddResources()ReleaseResources()ExecutePlans()

<<interface>>Execute

Fig. 3.2 MAPE-K interfaces for self-adaptive functionality in the SMARTS framework.

The MonitorAgent will continuously perceive the environment and after any pre-processingof data it will update the models and trigger the next i.e AnalyzeAgent. The aAgent representsthe AnalyzeAgent to whom this agent will notify in case an event of interest occurs requiringadaptation.


MonitorAgent

aAgent : AnalyzeAgent

Sense′

senseAction : PSubsystem×PState → PStatesubsystem? : Subsystem

state′ = senseAction(subsystem?,state)

GetData′

readAction : PReflectionModel×PState → PState

state′ = readAction(rModel,state)

UpdateKnowledge′

writeAction : PState×PReflectionModel → PReflectionModel

rModel′ = writeAction(state,rModel)

Trigger′

triggerAction : PState×AnalyzeAgent → AnalyzeAgent

aAgent′ = triggerAction(state,aAgent)

Sense =̂ [subsystem? : Subsystem] • Sense′ → SKIPGetData =̂ GetData′ → SKIPUpdateKnowledge =̂ UpdateKnowledge′ → SKIPTrigger =̂ Trigger′ → SKIPMAIN =̂ µ T • Sense; GetData; UpdateKnowledge; Trigger; T

The AnalyzeAgent will make decisions regarding whether the adaptations are needed ornot. In case an adaptation is needed it will trigger the PlanAgent. The pAgent representsthe PlanAgent to whom this agent will notify to plan for the necessary adaptations. TherequiredResources represent the resources that this agent needs to complete its assignedtasks. The availableResources are the resources that have been assigned to this agent. Atanytime the attribute rRequirement represents the situation of the resources for this agent.Resource requirement can be divided into four classes, one in which the system does notrequire additional resources, second in which the system has more resources than it needs,third in which the system needs more resources and fourth in which it is not possible to get apredictable total of the system resources.


ResourcesRequirement ::= SATISFIED | OVERSATISFIED | UNSATISFIED |UNDETERMINED

AnalyzeAgent

pAgent : PlanAgentrequiredResources : PResourceavailableResources : PResourcerRequirement : ResourcesRequirement

INIT

rRequirement = UNDETERMINED

GetData′



AnalyzeResources′

∆requiredResources∆availableResources

UpdateKnowledge′



Trigger′

triggerAction : PState×PlanAgent → PlanAgent

aAgent′ = triggerAction(state,pAgent)

GetData =̂ GetData′ → SKIPAnalyzeResources =̂ [requiredResources?,availableResources : Resource] •((AnalyzeResources′ ∧ rRequirement = SATISFIED)2(AnalyzeResources′ ∧ rRequirement = UNDERSATISFIED))2(AnalyzeResources′ ∧ rRequirement = OVERSATISFIED))→ SKIPUpdateKnowledge =̂ UpdateKnowledge′ → SKIPTrigger =̂ Trigger′ → SKIPMAIN =̂ µ T • GetData; AnalyzeResources; UpdateKnowledge; Trigger; T


The PlanAgent will prepare a set of tasks that are required for the adaptation and thenit will trigger the ExecuteAgent. It basically plans two types of actions. In case the systemresources are unsatisfied it creates plans to add the resources to the system. On the contraryif the system resources are over satisfied it creates plans to release the extra resources. TheeAgent represents the ExecuteAgent to whom this agent will notify to execute the actionsrequired for the necessary adaptations. In case the resources are under-satisfied, a set of planactions are devised in order to add the resources to the managed system. Similarly in case ofover-satisfied, a set of plan actions are devised in order to release the extra resources of themanaged system. We specify a new type Plan which is a collection of tasks.

Plan ::= PTask

PlanAgent

eAgent : ExecuteAgentrRequirement : ResourcesRequirement

INIT


DevisePlanForUnsatisfied′

rRequirement? = UNSATISFIEDplans? : Plan

c!plans

DevisePlanForOversatisfied′

rRequirement? = OVERSATISFIEDplans? : Plan

c!plans

Trigger′

triggerAction : PState×ExecuteAgent → ExecuteAgent

eAgent′ = triggerAction(state,eAgent)


DevisePlanForUnsatisfied =̂ [rRequirement : ResourcesRequirement; plans? : Plan] •(DevisePlanForUnsatisfied′ ∧ rRequirement = UNSATISFIED) • c?(plans)→ SKIPDevisePlanForOversatisfied =̂ [rRequirement : ResourcesRequirement; plans? : Plan] •(DevisePlanForOversatisfied′ ∧ rRequirement = OVERSATISFIED) • c?(plans)→ SKIPTrigger =̂ Trigger′ → SKIPMAIN =̂ µ T • (DevisePlanForUnsatisfied2DevisePlanForOversatisfied); Trigger; T

The ExecuteAgent is responsible for executing the adaptation actions of the generatedplans. There are three phases in an execute behavior namely PreProcess, ExecutePlanand PostProcess. In PreProcess the agent acquires all the resources that are required forthe adaptation goals. Once all the pre-processing has been completed, the agent performsExecutePlan to perform the necessary adaptations. After all the plans have been executed theagent performs PostProcess to release all the acquired resources.

ExecuteAgent

InAgentrequiredResources : PResourceavailableResources : PResourcerRequirement : ResourcesRequirement

INIT


AddResources′

newResources?PResource∆requiredResources∆availableResources∆alloc

availableResources′ = availableResources∪{newResources}requiredResources′ = requiredResources\{newResources}

ExecutePlans′

plans? : Planexecute : Plan×PState×PReflectionModel → PReflectionModel

plans ̸=∅∀(plan ∈ plans ∧ execute(plan,state,rModel))


ReleaseResources′

extraResources?PResource∆availableResources∆alloc

availableResources′ = availableResources\{extraResources}

PreProcess =̂ [newResources? : Resource] • (AddResources′

∧ rRequirement = UNSATISFIED)→ SKIPExecutePlans =̂ [plans? : Plan] • ExecutePlans′ → SKIPPostProcess =̂ [extraResources? : Resource] • (ReleaseResources′

∧ rRequirement = OVERSATISFIED)→ SKIPMAIN =̂ µ T • PreProcess; ExecutePlans; PostProcess; T

A self-adaptive unit is a reflective subsystem comprising reflection models and localreflective computations. It is specified as a active class continuously monitoring the system.

SelfAdaptiveUnitstate : PStatemodels : PReflectionModelcomputations : PLocalReflectiveComputation[LocalManagedSystem,Protocol,Model]c : chanreadAction : PReflectionModel×PState → PStatewriteAction : PState×PReflectionModel → PReflectionModeltriggerAction : PState×PLocalReflectiveComputation[LocalManagedSystem,Protocol,Model]→PLocalReflectiveComputation[LocalManagedSystem,Protocol,Model]

∀c : computations •domc.readAction = {m : PReflectionModel | m ⊆ models • (m,c.state)} ∧domc.writeAction = {m : PReflectionModel | m ⊆ models • (c.state,m)} ∧domc.triggerAction = {ct : PLocalReflectiveComputation[LocalManagedSystem,Protocol,Model]| ct ⊆ computations\{c} • (c.state,ct)}Read =̂ [m? : PReflectionModel; state? : PState] • c?(m,state)→ readAction →c!(state)→ SKIPWrite =̂ [state? : PState; m? : PReflectionModel] • c?(state,m)→ writeAction →c!(m)→ SKIPTrigger =̂ [state? : PState; ct : PLocalReflectiveComputation[LocalManagedSystem,Protocol,Model]] • c?(state,ct)→ triggerAction → c!(ct)→ SKIPMAIN =̂ µ T • (Read 2 Write 2 Trigger); T


3.2.7 Entities for Distributed Self-Adaptive Multi-Agent System

A local self-adaptive multi-agent system contains multiple local managed systems and self-adaptive units. The local managed systems can be sensed and adapted by the self-adaptiveunits. It will contain a list of all the ARTIS agents and In-agents. It also contains SIMBAcommunicator agent for communication with any agent within the platform or with any agentacross the platform. An agent is added to the multi-agent system via AMS which assigns aunique identifier to every agent. Similarly an agent is removed from the multi-agent systemvia AMS.

LocalSelfAdaptiveMultiAgentSystemlocalManagedSystems : PLocalManagedSystem[Protocol,Model]selfAdaptiveUnits : PSelfAdaptiveUnit[LocalManagedSystem,Protocol,Model]sca : SIMBACommunicatorAgent

∀sau : selfAdaptiveUnits; lrcSense; lrcAdapt : LocalReflectiveComputation •lrcSense ∈ sau : computations ∧ lrca ∈ sau : computations ∧dom lrcSense.sense = {lms : PLocalManagedSystem | lms ⊆ localManagedSystems •(lms, lrcSense.state)} ∧dom lrcAdapt.adapt = {lms : PLocalManagedSystem | lms ⊆ localManagedSystems •(lms, lrcAdapt.state)}

Finally a distributed self-adaptive system contains multiple local self-adaptive multi-agentsystems. We use external choice operator between all the active classes to allow a choice ofbehavior according to the environmental events.

DistributedSelfAdaptiveSystemlocalSelfAdaptiveSystems : PLocalSelfAdaptiveMultiAgentSystem[Protocol,Model]MAIN =̂ µ T • (Environment 2 InAgent 2 DirectoryFacilitator 2AgentManagementSystem 2SIMBACommunicatorAgent 2ARTISAgent 2SelfAdaptiveUnit); T

Chapter 4

Application of the SMARTS Framework

4.1 Modelling of Traffic Management System using SMARTS

Lahore is the capital city of the Pakistani province of Punjab. It is the second largest andmost populous city in Pakistan with a population of about 10,355,000, after Karachi, and the32nd most populous urban city in the world [132]. Traffic problem in Lahore like any otherbig city of Pakistan has become a major issue at the moment. The situation is getting worstwith every passing day. Numerous reasons are there which are accelerating the intensity ofthis problem. Among the many reasons of traffic problems in Lahore a few are listed below.

1. Lack of proper signaling system (this includes roads without signals and malfunctionedsignals).

2. Negligence of traffic wardens (this includes negligence from their duties).

3. Poor quality of roads (this means physical conditions of the roads).

4. Lack of proper transportation system (this includes lesser number of vehicles thanrequired for passengers, need for new roads, roads carrying more traffic than theircapacity).

5. Violation of traffic rules by the passengers (this includes intentional and unintentional.Intentional violation like use of mobile phones while driving. Unintentional meansthat people lacks the awareness about the traffic rules).

6. Obstruction of roads due to parking on the main roads and busy roads.

7. Increasing number of vehicles with each passing day while the infrastructure eitherremains the same or if the infrastructure is being developed then at a very slow rate.

4.2 Existing Methodology for Smart Traffic Management System 37

8. Mega Projects like Metro Bus and Metro Train being developed without providing anyalternative road facilities.

Due to these conditions the problem of traffic jam is increasing day by day. This createsa lot of mental stress for the people. Although the Government of Punjab has taken steps likeMetro Bus and Metro Train to reduce the amount of traffic on the main roads but the resultshave yet to be seen. Our focus of this research is to propose a solution for effective trafficmanagement in Lahore using real-time self-adaptive traffic management system. It has beenargued in this [133–137] that for efficient traffic management the ability of self-adaptationfor dynamic traffic environments is a key characteristic. Currently in Lahore the traffic signalare either timer based or controlled by the traffic wardens deployed at those signals. Thetimer based signals turns themselves RED/YELLOW/GREEN after certain amount of timeranging from 10s to 90s. During peak hours we can clearly see these timer based and trafficwarden controlled signals failing. The timer based signals fail because it does not possess therequired adaptivity to change its working based on the traffic flow. On occasion we can seethat at intersections drivers often have to wait for 10s to 90s while the signal remains openand there is no passenger. The traffic warden controlled signaling system although resolvesthis issue as they are able to view the traffic situation by making sure that the traffic signalremains open only when there is some passenger waiting. The traffic warden controlledsignaling system fails in situation of severe traffic because a traffic warden deployed at onesignal usually has no idea about the traffic situation of its neighboring signals. He mightaccidentally route the traffic to a signal at which there is already a traffic jam while someother neighboring signal is completely free. Besides this, the traffic system of Lahore requirescertain changes like coordination mechanism between different traffic signals to resolve theissue in a efficient way.

4.2 Existing Methodology for Smart Traffic ManagementSystem

At present, there are three major techniques for smart traffic managemnt system. None of thetechnology contains the ability of self-adaptation though. The following section conatins anoverview of these technologies.

4.2.1 Inductive Loop Detection Technology

Inductive loop detection works on the principle that one or more turns of insulated wireare placed in a shallow cutout in the roadway A wire runs from roadside pull box to the

4.2 Existing Methodology for Smart Traffic Management System 38

controller and to the electronic unit located in the controller cabinet. When a vehicle passesover the loop or stops, the induction of the wire is changed. Due to change in induction,there is change in the frequency. This change in the frequency causes the electronic unitto send a signal to the controller, indicating presence of the vehicle [6]. Inductive loopdetection is useful in knowing the vehicle presence, passage, occupancy and even the numberof vehicles passing through a particular area [6,7]. But there are few problems with thissystem. These include poor reliability due to improper connections made in the pull boxesand due to application of sealant over the cutout of the road. If this system is implemented inpoor pavement or where digging of the roads is frequent then the problem of reliability isaggravated [4,5,8].

4.2.2 Video Analysis Technology

Video analysis consists of a smart camera placed which consists of sensors, a processing unitand a communication unit [9]. The traffic is continuously monitored using smart cameras.The video captured is then compressed so as to reduce the transmission bandwidth. Thevideo analysis abstracts scene description from the raw video data. This description is thenused to compute traffic statistics. This statistic includes frequency of the vehicles, averagespeed of the vehicles as well as the lane occupancy [9,10]. The problems associated withvideo analysis are – (a) the overall cost of the system is quite high (b) the system gets affectedin case of heavy fog or rains (c) night time surveillance requires proper street lighting.At present this video analysis technology lacks the element of self-adaptation to make itfault-tolerant in a distributed environment.

4.2.3 Infrared Sensors Technology

Infrared sensors are used to detect energy emitted from vehicles, road surfaces and otherobjects. The energy captured by these infrared sensors is focused onto an infrared sensitivematerial using an optical system which then converts the energy into the electric signals.These signals are mounted overhead to view the traffic. These infrared sensors are used forsignal control, detection of pedestrians in crosswalks and transmission of traffic information[11]. The basic disadvantages of infrared sensors are that the operation of the system may beaffected due to fog; also installation and maintenance of the system is tedious [5,8].

4.3 Proposed Solution for Traffic Management System 39

Fig. 4.1 Traffic types based on congestion.

4.3 Proposed Solution for Traffic Management System

We believe that the traffic problem of Lahore can be effectively managed using the paradigmof real-time self-adaptive multi-agent system. We identified mainly four types of trafficflows namely Normal Traffic, Full Congestion, Near Congestion and Far Congestion. Theinterpretations of these four traffic types is shown in Figure 4.1. We have chosen two majorsignals of Lahore to show the application of our proposed SMARTS framework. Thesestations are Thokar Niaz Baig signal and Muslim Town Mor signal. We needed at least twostations to show the coordination between the stations. Thokar Niaz Baig signal is among thebiggest intersection of Lahore and is located at the South-West side of the Lahore division. Itconnects Raiwind Road, Chuburji, Canal Road, and Multan Road, as shown in Figure 4.2.Major traffic jams can be routinely observed at this signal. It is expected that the completionof mega project like Orange Train Project will help to reduce the traffic load on this signal.Muslim Town Mor signal is connected to the Thokar Niaz Baig signal via the Canal BankRoad. It connects Wahdat Road, Ferozepor Road and Canal Road as shown in Figure 4.3.

An agent based sensor will be deployed on each lane. In case the road is two way thesensor will monitor both the incoming and outgoing traffic with the help of a video camera.In case of Thokar Niaz Baig since there are 4 connecting roads so there will be 4 monitoringstations. We name these four monitoring stations as TNB1, TNB2, TNB3 and TNB4. TheseTNB1, TNB2, TNB3 and TNB4 monitoring stations will monitor the incoming and outgoingtraffic from Chuburji Road, Canal Road, Raiwind Road and Multan Road respectively. For


Fig. 4.2 Overview of the traffic monitoring stations at the Thokar Niaz Baig signal.

Muslim Town Mor signal since there are 5 connecting roads so there will be 5 monitoringstations. We name these five monitoring stations as MTM1, MTM2, MTM3, MTM5 andMTM 5. These MTM1, MTM2, MTM3, MTM4 and MTM5 monitoring stations will monitorthe incoming and outgoing traffic of Canal Bank Road, Ferozepor Road, Thokar Niaz Baig,Wahdat Road and Icchra Bazar respectively.

4.3.1 Overview of Single Traffic Monitoring Station

An overview of the single monitoring station is shown in Figure 4.4. Monitor ARTIS agentwill be the main agent responsible for monitoring and controlling the traffic. It is assumedthat each monitoring station will work independently without any human intervention. Thisincludes not only turning the signals but also managing the duration of each signal. Thisagent will analyze the real-time traffic using the Image Sensor In-agent and Video SensorIn-agent. Image Sensor In-agent will analyze the traffic based on imagery data, thereforeit can process its data faster. Video Sensor In-agent will analyze the traffic based on videodata. Each monitoring station will communicate with the rest of the stations using SIMBAcommunicator agent. This agent will also provide the yellow-pages and white-pages servicesto the other agents using DF In-agent and AMS In-agent respectively. These monitoringstations needs to have decentralized control so that we do not have a single point of failure.Each monitoring station will operate the signals they are controlling in two ways. First undernormal traffic the signals will operate based on fixed timing. This will give equal opportunity


Fig. 4.3 Overview of the traffic monitoring stations at the Muslim Town Mor signal.

to each signal and the adaptation decisions will not be required. Second in case congestion isdetected then the adaptive decision taking module will be active and real-time timings for thesignals will be derived.

4.3.2 Provision of the Domain Functionality

Each monitoring station will have four types of traffic these are NormalTraffic, FullCongestion,NearCongestion, FarCongestion. We introduce the type TrafficType that will represent thecurrent status of the traffic.

TrafficType ::= NORMAL TRAFFIC | FULL CONGESTION | NEAR CONGESTION |FAR CONGESTION

To specify computations, we introduce the type State. State represents the current statusof a computation and is specified as:

[State]

We specify a type new type SignalStatus to represent the current status of a signal.


Fig. 4.4 Overview of single traffic monitoring station.

SignalStatus ::= RED | YELLOW | GREEN

We specify neighbor as a collection of traffic signals.

Neighbor ::= PTrafficSignal

We specify Location as a combination of longitude and latitude.

Location ::= Longitude×Latitude

Since a traffic signal would be operating under two modes, we specify a type mode as

Mode ::= TIMER | ADAPTIVE


The specifications below introduces the features and operations of a traffic signal. Everytraffic signal has an id to uniquely identify it. Its location specifies its longitude and latitude.The type specifies whether there is a congestion or normal traffic. The status specifies thecurrent status. The neighbors is a combination of all the traffic signals with whom this signalis connected to. The mode specifies whether the signal is working to control normal trafficor congestion. Since a traffic signal can change its type, status and neighbors so we havemethods ChangeTrafficStatus, ChangeTrafficType, UpdateNeighbors for these respectively.A traffic signal cannot change its position so there is no method for it.

TrafficSignal

id : Ntype : TrafficTypeposition : Locationstatus : SignalStatusneighbors : Neighbor

INIT

id ̸=∅type = NORMAL

ChangeTrafficStatus∆(status)newStatus? : SignalStatus

status′ = newStatus?

ChangeTrafficType∆(type)newType? : TrafficType

type′ = newType?

UpdateNeighbors∆(neighbors)neighborsToAdd? : NeighborneighborsToRemove? : Neighbor

neighbors′ = neighbors∪{neighborsToAdd}neighbors′ = neighbors\{neighborsToRemove}


The TrafficSensorInAgent will analyze the the image/video data to determine the trafficconditions. Its reflex action is to process the image to determine the congestion status.However in poor visibility conditions like fog etc, there might be need to process the videodata to analyze the traffic conditions. We specify a type TrafficSensorStatus to represent thecurrent status of sensor to depict whether it is processing data (image/video) or it is idle.

TrafficSensorStatus ::= PROCESS DATA | IDLE

TrafficSensorInAgent

InAgentid : Idstatus : TrafficSensorStatusc : chan

INIT

status = IDLE

AnalyzeImageData′

∆(status)data? : P IMAGEresult! : TrafficType

status′ = PROCESS DATA

AnalyzeVideoData′

∆(status)data? : VIDEOresult! : TrafficType

status′ = PROCESS DATA

AnalyzeImageData =̂ [data? : P IMAGE; result! : TrafficType] •AnalyzeImageData′ → c!(result)→ SKIPAnalyzeVideoData =̂ [data? : VIDEO; result! : TrafficType] •AnalyzeVideoData′ → c!(result)→ SKIPMAIN =̂ µ T • (AnalyzeImageData 2 AnalyzeVideoData); T

The MonitorARTISAgent will be the main agent providing the domain functionality. Itwill control only one In-agent namely MonitorARTISAgent for this purpose.


MonitorARTISAgent

ARTISAgentid : Idsignal : TrafficSignalagent : TrafficSensorInAgent

The id represents the unique identifier of the traffic monitoring station. The agentrepresents the MonitorARTISAgent providing the domain functionality. The attribute cbCo-ordnationMechanism represents the other other monitoring station who are in coordinationwith this station. The mAgent, aAgent, pAgent and eAgent represents the four agents re-sponsible for providing the self-adaptive functionality. The scAgent is the agent responsiblefor communication between different stations. The cbCoordnationMechanism is a set ofcollaborating stations to monitor the traffic.

TrafficMonitoringStation

id : Idagent : MonitorARTISAgentmAgent : Monitor AgentaAgent : Analyze AgentpAgent : Plan AgenteAgent : Execute AgentscAgent : SIMBACommunicatorAgentcbCoordnationMechanism : DynamicAgentOrganizations

As there are five monitoring stations at the Muslim Town Mor so we specify it as below.

MTM1 TrafficMonitoringStation











For Thokar Niaz Baig we have four monitoring stations so we specify it as below.

TNB1 TrafficMonitoringStation









4.3.3 Self-Adaptive Functionality

The Monitor Agent will continuously monitor the real-time traffic data. Since the sensors formonitoring the traffic are controlled by the Monitor−ARTIS−Agent, the Monitor Agent willcommunicate with it to get the traffic data. This is depicted by the GetTrafficData′ process.It will then pre-process the data to keep only the data needed for the adaptation/decisionsregarding the traffic environment. This is depicted by the UpdateKnowledge′ process. TheaAgent represents the Analyze Agent to whom this agent will notify in case an event ofinterest occurs requiring adaptation. This is depicted by the Trigger′ process.

Monitor Agent

aAgent : Analyze AgentrModel? : PReflectionModel

GetTrafficData′



UpdateKnowledge′



Trigger′

triggerAction : PState×Analyze Agent → Analyze Agent

aAgent′ = triggerAction(state,aAgent)

GetTrafficData =̂ GetTrafficData′ → SKIPUpdateKnowledge =̂ UpdateKnowledge′ → SKIPTrigger =̂ Trigger′ → SKIPMAIN =̂ µ T • SenseTraffic; GetTrafficData; UpdateKnowledge; Trigger; T

The Analyze Agent will make decisions regarding whether the adaptations are neededor not. It will get the pre-processed data saved by the Monitor Agent for analyses. Thisis depicted by the GetTrafficData′ process. It will analyze the data and reach one of thefour possible outcomes i.e NORMAL, FULL, NEAR, and FAR. This is depicted by theAnalyzeTrafficData process. In case of normal traffic, the signals will work based on timerand no adaptations will be required. In case of congestion the agent will update the reflection


models. This is depicted by the UpdateKnowledge process. It will then notify the next agentto devise the necessary plans for the adaptation as shown by the Trigger′ process.

Analyze Agent

pAgent : Plan AgentrModel? : PReflectionModel

GetTrafficData′



AnalyzeTrafficData′

result? : TrafficType

result! = (NORMAL ∨ FULL ∨ NEAR ∨ FAR)

UpdateKnowledge′

trafficType? : TrafficTypewriteAction : PState×PReflectionModel → PReflectionModel

rModel′ = writeAction(state,rModel) ∧ (trafficType = FULL∨ trafficType = NEAR ∨ trafficType = FAR)

Trigger′

triggerAction : PState×Plan Agent → Plan Agent

aAgent′ = triggerAction(state,pAgent)

GetTrafficData =̂ GetTrafficData′ → SKIPAnalyzeTrafficData =̂ [result? : TrafficType] •((AnalyzeTrafficData′ ∧ result = FULL)2(AnalyzeTrafficData′ ∧ result = FAR))2(AnalyzeTrafficData′ ∧ result = NEAR))→ SKIPUpdateKnowledge =̂ UpdateKnowledge′ → SKIPTrigger =̂ Trigger′ → SKIPMAIN =̂ µ T • GetTrafficData; AnalyzeTrafficData; UpdateKnowledge; Trigger; T

The Plan Agent will prepare a set of tasks/actions that are required for the smooth man-agement of traffic flow. Since there can be three types of traffic, it basically plans three typesof actions. These are depicted by the three processes named DevisePlanForFullCongestion,DevisePlanForNearCongestion and DevisePlanForFarCongestion. The eAgent representsthe Execute Agent to whom this agent will notify to execute the actions required for the


necessary adaptations.

Plan Agent

eAgent : Execute AgentrModel? : PReflectionModel

DevisePlanForFullCongestion′

writePlans : PState×PReflectionModel×TrafficType×PPlan → PReflectionModelplans? : Plan

rModel′ = writeAction(state,rModel,FULL,plans)

DevisePlanForNearCongestion′


rModel′ = writeAction(state,rModel,NEAR,plans)

DevisePlanForFarCongestion′


rModel′ = writeAction(state,rModel,FAR,plans)

Trigger′

triggerAction : PState×Execute Agent → Execute Agent

eAgent′ = triggerAction(state,eAgent)

DevisePlanForFullCongestion =̂ DevisePlanForFullCongestion′ → SKIPDevisePlanForNearCongestion =̂ DevisePlanForNearCongestion′ → SKIPDevisePlanForFarCongestion =̂ DevisePlanForFarCongestion′ → SKIPTrigger =̂ Trigger′ → SKIPMAIN =̂ µ T • (DevisePlanForFullCongestion2DevisePlanForNearCongestion2DevisePlanForFarCongestion); Trigger; T

The Execute Agent is responsible for executing the adaptation actions of the generatedplans. However since this agent is part of the adaptation concern, it cannot directly executethese plans. Hence this agent will direct the Monitor − ARTIS − Agent to execute the


generated plans. A single traffic signal cannot do a lot on its own and needs support from itsneighboring signals. This means that all the generated plans will require support from theneighboring signals. Hence a cooperation request will be sent to every required neighboringstation. It is like reserving resources for the execution of the generated plan and t is depictedby AcquireResources. After all the required resources have been acquired the generated planswill be executed. This is represented by the ExecutePlans process. After the execution of theplans the resources reserved by this signals will be released. Also the neighboring signalswill be notified about the result so that if they have reserved any resources upon our requestthey can release that too.

Execute Agent

rRequirement : ResourcesRequirementrModel? : PReflectionModel

AcquireResources′

newResources?PResource∆requiredResources∆availableResources∆alloc

availableResources′ = availableResources∪{newResources}requiredResources′ = requiredResources\{newResources}

ExecutePlans′

plans? : Planexecute : Plan×PState×PReflectionModel → PReflectionModel

plans ̸=∅∀(plan ∈ plans ∧ execute(plan,state,rModel))

ReleaseResources′

extraResources?PResource∆availableResources∆alloc

availableResources′ = availableResources\{extraResources}


AcquireResources =̂ [newResources? : Resource]• (AcquireResources′ ∧ rRequirement = UNSATISFIED)→ SKIPExecutePlans =̂ [plans? : Plan] • ExecutePlans′ → SKIPReleaseResources =̂ [extraResources? : Resource]• (ReleaseResources′ ∧ rRequirement = OVERSATISFIED)→ SKIPMAIN =̂ µ T • AcquireResources; ExecutePlans; ReleaseResources; T

4.3.4 Coordination Mechanism

For coordination between the traffic stations we define two type of roles. These two rolesidentify who initiated the communication. There will be no centralized controlling station asit may leads to single point of failure. Self-adaptive functionality enables every monitoringstation to work independently without the need for any centralized controlling server. Werefer to a set of collaborating traffic stations as an organization. It should be pointed out thata single traffic stations will be part of at least one organization.

Role ::= Sender | Receiver

The coordination protocol used by the agents is specified below.

CoordinationProtocolrole : Role

To represent the messages that be exchanged between the agents, we specify a Messagetype. It contains the identifier of the sender, the receiver and the actual message content.

Messageto : Idfrom : Idcontent : Content

Now we specify the model used by the traffic monitoring stations to keep track ofits coordinating stations. The neighbors represent the immediate monitoring stations. Amonitoring station can also communicate with its neighbor’s neighbors, which we referto as oneHopNeighbors. This will be useful when any monitoring station suddenly stopsworking then its neighboring monitoring stations can bypass it and continue to work. Every


monitoring station will send its traffic status to its neighboring stations and one hop neighbors.This message will serve as a heart beat for all the monitoring stations.

OrganizationPartnersneighbors : P IdoneHopNeighbors : P Id

Now we can specify the coordination mechanism for the fault detection. The Moni-toringStationOrganization represents a set of collaborating traffic stations to maintain thesmooth flow of traffic at any instant of time. Here messages represents all the messagesthat have been exchanged between the traffic stations that belong to this organization. Thetimeout denotes the timeout policy for this organization. Lastly we specify a predicatestating that every agent in the dependency model has a communication link. The functionsenderOrReceiver means that either one of the sender or receiver of the channel.

MonitoringStationOrganizationprotocol : CoordinationProtocolpartners : OrganizationPartnersmessages : PMessagetimeout : Time

∀p : partners.neighbors • ∃ l : chan • senderOrReceiver(l) = p ∧∀q : partners.oneHopNeighbors • ∃ l : chan • senderOrReceiver(l) = q

4.3.5 Complete Traffic Monitoring System (TMS)

We specify the traffic monitoring system’s attributes and processes. Processes represents thedifferent on going activities and communication between the agents. Attributes representsthe instantaneous values of different elements.

TMS attributes == {TrafficSignal, TrafficSensorInAgent, Monitor Agent, Analyze Agent,Plan Agent, Execute Agent }

TMS processes == {ChangeTrafficStatus, ChangeTrafficType, UpdateNeighbors, AnalyzeIm-ageData, AnalyzeVideoData, GetTrafficData, UpdateKnowledge, Trigger, AnalyzeTraffic-Data, UpdateKnowledge, DevisePlanForFullCongestion, DevisePlanForNearCongestion,DevisePlanForFarCongestion, AcquireResources, ExecutePlans, ReleaseResources }

TMS environment is an environment with the TMS attributes and processes.


TMSEnvironmentEnvironment

attributes ⊆ TMS attributesprocesses ⊆ TMS processes

A domain model contains representations of entities necessary for the provision ofrequired features. Here EnvironmentRepresentation specifies the attributes of the environment.Domain model is specified as a passive class. The channel c is used for communication withany one of the active classes. The domain model here represents the K (Knowledge) part ofthe MAPE-K feedback loop.

DomainModelModel[EnvironmentRepresentation]map : PAttribute ↔ EnvironmentRepresentationenvr : chan

dommap ⊆ {attrs : PAttribute | attrs ⊆ envr?.attributes}ranmap = {r : EnvironmentRepresentation | r ∈ rep}

A RepairStrategy contains multiple repair actions for each traffic station.

RepairStrategyactions : Id×PTask

A SelfHealingSubsystem represents the module of traffic station that will provide theself-adaptive capability. It contains repair strategy and organization for a single monitoringstation. The first predicate states that the self-healing manager can only read and write thelocal repair strategy and dependency model. The second predicate states that we have acommunication link with every agent present in the dependency and repair actions. It isspecified as an active class continuously monitoring the system.


SelfHealingSubsystemrs : RepairStrategyorganization : MonitoringStationOrganizationstate : PStatemodels : PReflectionModelcomputations : PComputationc : chanreadAction : PReflectionModel×PState → PStatewriteAction : PState×PReflectionModel → PReflectionModel

∀c : computations •domc.readAction = {m : PReflectionModel | m ⊆ models • (m,c.state)} ∧domc.writeAction = {m : PReflectionModel | m ⊆ models • (c.state,m)}Read =̂ [m? : PReflectionModel; state? : PState] • c?(m,state)→ readAction → c!(state)→ SKIPWrite =̂ [state? : PState; m? : PReflectionModel] • c?(state,m)→ writeAction → c!(m)→ SKIP∀repairAction : rs.actions • ∃ol,nl : chan;• senderOrReceiver(ol) = id1∧ senderOrReceiver(nl) = id2MAIN =̂ µ T • (Read 2 Write ); T

A LocalTrafficMonitoringStation contains single TrafficMonitoringStation and SelfHeal-ingSubsystem. Here TrafficMonitoringStation corresponds to the local managed systemand it can be sensed and adapted by the SelfHealingSubsystem. It also contains SIMBAcommunicator agent for communication with any agent within the platform or outside theplatform. An agent is added to the multi-agent system via AMS which assigns a uniqueidentifier to every agent. Similarly an agent is removed from the multi-agent system viaAMS.

LocalTrafficMonitoringStationlocalManagedSystems : PLocalTrafficMonitoringStationselfHealingSubsystem : SelfHealingSubsystemsca : SIMBACommunicatorAgent

domselfHealingSubsystem.selfHealingManager.sense ={(localTrafficMonitoringSystem,selfHealingSubsystem.selfHealingManager.state)} ∧domselfHealingSubsystem.selfHealingManager.adapt ={(localTrafficMonitoringSystem,selfHealingSubsystem.selfHealingManager.state)}

We will have LocalTrafficMonitoringStation for all the five monitoring stations of the Mus-lim Town Mor signal namely MTM1 LocalTrafficMonitoringStation, MTM2 LocalTraffic

4.4 Formal Verification of the Traffic Monitoring System 55

MonitoringStation, MTM3 LocalTrafficMonitoringStation, MTM4 LocalTrafficMonitoringStation and MTM5 LocalTrafficMonitoringStation. Similarly we will have four Local-Traffic MonitoringStation for the four monitoring stations of the Thokar Niaz Baig sig-nal namely TNB1 LocalTraffic MonitoringStation, TNB2 LocalTraffic MonitoringStation,TNB3 LocalTrafficMonitoringStation and TNB4 LocalTrafficMonitoringStation.

Finally we can specify the DistributedTrafficMonitoringSystem. It comprises of all theLocalTrafficMonitoringStation. We use external choice operator between all the active classesto allow a choice of DistributedSelfAdaptiveSystem according to the environmental events.

DistributedTrafficMonitoringSystemMTM1 ltms : MTM1 LocalTrafficMonitoringStationMTM2 ltms : MTM2 LocalTrafficMonitoringStationMTM3 ltms : MTM3 LocalTrafficMonitoringStationMTM4 ltms : MTM4 LocalTrafficMonitoringStationMTM5 ltms : MTM5 LocalTrafficMonitoringStationTNB1 ltms : TNB1 LocalTrafficMonitoringStationTNB2 ltms : TNB2 LocalTrafficMonitoringStationTNB3 ltms : TNB3 LocalTrafficMonitoringStationTNB4 ltms : TNB4 LocalTrafficMonitoringStation

MAIN =̂ µ T • (Environment 2 MTM1 ltms 2 MTM2 ltms 2 MTM3 ltms2 MTM4 ltms 2 MTM5 ltms 2 TNB1 ltms 2 TNB2 ltms 2 TNB3 ltms2 TNB4 ltms); T

4.4 Formal Verification of the Traffic Monitoring System

We will integrate the bounded delay response requirements of agents as part of the QoSservices. For verification that agent’s actions conforms to bounded delay response, itsrequirements will be formally represented as a validity problem. The validity problem willthen be solved with the help of TAPAAL model checker. The TAPAAL is a verification toolfor extended timed-arc Petri-nets with its own verification engine. We can create models ofthe system under consideration and perform automated verification using fragments of TCTLvia transformation to timed automata.

4.4.1 Timed Arc Petri-Net Models of the MTM and TNB Signals

We formally specified the different traffic monitoring stations of the MTM and TNB sig-nals in section 4.3. Each traffic monitoring station had a single MonitorARTISAgentproviding the domain functionality. The TCOZ based specification captured the behav-


ior and state based attributes of the system. In Timed Arc Petri-net models of eachsignal, the states MTM Red, TNB Red, MTM Yellow, TNB Yellow, MTM Green andTNB Green corresponds to the attribute SignalStatus of the entity TrafficSignal that ismonitored by the In-agent named TrafficSensorInAgent. This In-agent is then controlledby the MonitorARTISAgent deployed on each station. The transitions MTM RedToYellow,TNB RedToYellow, MTM YellowToGreen and TNB YellowToGreen corresponds to the oper-ation ChangeTrafficSignal of entity TrafficSignal.

The Timed Arc Petri-net model of the Muslim Town Mor signal is shown Figure 4.5. Thefive stations of Muslim Town Mor signal have been represented by the acronym MTM. Thesimulation will start with the Start state with a single token. The transition Initialize willforward the token to all the Red states of the five signals. The transition MTM RedToYellowdepicts the change in signal state from red to yellow. Initially all the signals will be in red state.Since there can be only one signal in green state at any time, we have defined five constantsfor this purpose namely MTM1 Delay, MTM2 Delay, MTM3 Delay, MTM4 Delay andMTM5 Delay. A single unit of delay corresponds to 20 seconds. This means that eachsignal will remain green for 20 seconds and it will for other signals in red or yellow statefor 80 seconds. The transition MTM YellowToGreen depicts the change in signal state fromyellow to green. Since there can be only one green signal at a time we have a convergingstate named Converge. We have two transitions for each signal to show the status of greenlight. For this purpose Turn MTM Green depicts that the signal is about to be green whereasMTM Turned Green depicts that the signal has been green. The properties of interest wewant to verify on our model are specified in Table 4.1.

The initial computation tree of MTM signal is shown in Figure 4.6. Because the completecomputation tree of the five stations of MTM signal is too large to be fit into single image,the computation tree has been truncated into five parts. The computation trees of station 1,station 2, station 3, station 4 and station 5 of the MTM signal are shown in Figure 4.7, Figure4.8, Figure 4.9, Figure 4.10 and Figure 4.11 respectively.


Fig. 4.5 Timed Petri-Net model of the Muslim Town Mor signal.

Fig. 4.6 Initial computation tree of the Muslim Town Mor signal.


Table 4.1 Properties for correct functioning of the Muslim Town Mor Signal and theircorresponding TCTL formulas in TAPAAL.

Query Formula Result

Is MTM1 signal working?

EF ((MTM Signal.MTM1 Red = 1and MTM Signal.MTM1 Yellow = 0and MTM Signal.MTM1 Green = 0)or (MTM Signal.MTM1 Red = 0 andMTM Signal.MTM1 Yellow = 1 andMTM Signal.MTM1 Green = 0) or(MTM Signal.MTM1 Red = 0 andMTM Signal.MTM1 Yellow = 0 andMTM Signal.MTM1 Green = 1))

Satisfied

Is MTM1 signal’s green lightworking?

EF (MTM Signal.MTM1 Red = 0 andMTM Signal.MTM1 Yellow = 0 andMTM Signal.MTM1 Green = 1)

Satisfied

Is MTM1 signal’s yellow lightworking?


Satisfied

Is MTM1 signal’s red lightworking?


Satisfied



Satisfied



Satisfied



Satisfied



Satisfied



Satisfied





Satisfied



Satisfied



Satisfied



Satisfied



Satisfied



Satisfied



Satisfied



Satisfied



Satisfied



Satisfied



Satisfied

Is there at most one green traf-fic signal?

AG MTM Signal.MTM1 Green+ MTM Signal.MTM2 Green+ MTM Signal.MTM3 Green+ MTM Signal.MTM4 Green +MTM Signal.MTM5 Green <= 1

Satisfied


Fig.

4.7

Com

puta

tion

tree

ofth

eM

TM

1si

gnal

.


Fig.

4.8

Com

puta

tion

tree

ofth

eM

TM

2si

gnal

.


Fig.

4.9

Com

puta

tion

tree

ofth

eM

TM

3si

gnal

.


Fig.

4.10

Com

puta

tion

tree

ofth

eM

TM

4si

gnal

.


Fig.

4.11

Com

puta

tion

tree

ofth

eM

TM

5si

gnal

.


The timed Petri-net model of the Thokar Niaz Baig signal is shown in Figure 4.12. Thefour stations of Thokar Niaz Baig signal has been represented by the acronym TNB. Thesimulation will start with the Start state with a single token. The transition Initialize willforward the token to all the Red states of the four signals. The transition TNB RedToYellowdepicts the change in signal state from red to yellow. Initially all the signals will be in red state.Since there can be only one signal in green state at any time, we have defined four constantsfor this purpose namely TNB1 Delay, TNB2 Delay, TNB3 Delay and TNB4 Delay. Asingle unit of delay corresponds to 20 seconds. This means that each signal will remaingreen for 20 seconds and it will for other signals in red or yellow state for 60 seconds. Thetransition TNB YellowToGreen depicts the change in signal state from yellow to green. Sincethere can be only one green signal at a time we have a converging state named Converge.We have two transitions for each signal to show the status of green light. For this purposeTurn TNB Green depicts that the signal is about to be green whereas TNB Turned Greendepicts that the signal has been green. The properties of interest we want to verify on ourmodel are specified in Table 4.2.

The initial computation tree of the TNB signal is shown in Figure 4.13. Because thecomplete computation tree of the five signals of Thokar Niaz Baig is too large to be fit intosingle image, the computation tree has been truncated into four parts. The computation treesof station 1, station 2, station 3, and station 4 of the TNB signal are shown in Figure 4.14,Figure 4.15, Figure 4.16, and Figure 4.17 respectively.


Fig. 4.12 Timed Petri-Net model of the Thokar Niaz Baig signal.


Table 4.2 Properties for correct functioning of the Thokar Niaz Baig Signal and their corre-sponding TCTL formulas in TAPAAL


Is TNB1 signal working?

EF ((TNB Signal.TNB1 Red = 1and TNB Signal.TNB1 Yellow = 0and TNB Signal.TNB1 Green = 0)or (TNB Signal.TNB1 Red = 0 andTNB Signal.TNB1 Yellow = 1 andTNB Signal.TNB1 Green = 0) or(TNB Signal.TNB1 Red = 0 andTNB Signal.TNB1 Yellow = 0 andTNB Signal.TNB1 Green = 1))

Satisfied

Is TNB1 signal’s green lightworking?

EF (TNB Signal.TNB1 Red = 0 andTNB Signal.TNB1 Yellow = 0 andTNB Signal.TNB1 Green = 1)

Satisfied

Is TNB1 signal’s yellow lightworking?


Satisfied

Is TNB1 signal’s red lightworking?


Satisfied



Satisfied



Satisfied



Satisfied



Satisfied



Satisfied





Satisfied



Satisfied



Satisfied



Satisfied



Satisfied



Satisfied



Satisfied

Is there at most one green traf-fic signal?

AG TNB Signal.TNB1 Green+ TNB Signal.TNB2 Green+ TNB Signal.TNB3 Green+ TNB Signal.TNB4 Green +TNB Signal.TNB5 Green <= 1

Satisfied

Fig. 4.13 Initial computation tree of the Thokar Niaz Baig signal.


Fig.

4.14

Com

puta

tion

tree

ofth

eT

NB

1si

gnal

.


Fig.

4.15

Com

puta

tion

tree

ofth

eT

NB

2si

gnal

.


Fig.

4.16

Com

puta

tion

tree

ofth

eT

NB

3si

gnal

.


Fig.

4.17

Com

puta

tion

tree

ofth

eT

NB

4si

gnal

.


4.4.2 Communication Model of the MTM and TNB Signals

The communication model of the MTM and TNB signals are show in Figure 4.18 and Figure4.19 respectively. Start state is the shared state among the two signals. It initially containssingle token depicting the random occurrence of an event. There are five ARTIS agentsin MTM signal namely MTM1 ARTISAgent, MTM2 ARTISAgent, MTM3 ARTISAgent,MTM4 ARTISAgent and MTM5 ARTISAgent. There are four ARTIS agents in TNB signalnamely TNB1 ARTISAgent, TNB2 ARTISAgent, TNB3 ARTISAgent and TNB5 ARTISAgent.Each ARTISAgent in MTM and TNB model corresponds to the MonitorARTISAgent deployedat that TrafficMonitoringStation. The real-time nature of the model is specified by usingconstants to handle the deadlines. For MTM signal these constants are MTM1 T, MTM2 T,MTM3 T, MTM4 T and MTM5 T. For TNB signal these constants are TNB1 T, TNB2 T,TNB3 T and TNB4 T. We use transition Trigger to give equal chance of firing an event to allthe traffic stations. All the arcs fromEvent Occurs state to ARTISAgent state are transportarcs that will preserve the age of the token. This will ensure that from ARTISAgent state,only the events that satisfy the deadlines are fired. We have also added age invariants to allthe Event Occurs state of both signals to enforce urgency. This will ensure that no necessarydelays for token’s age are performed.

We specify the properties we want to verify in EF fragment of the Timed ComputationalTree Logic (TCTL) logic to ensure the correctness of the communication model of both thesignals in Table 4.3. Majorly we want to verify if an agent is able to communicate with allthe agents of his signal. Also and agent should be able to communicate with all the agentsof his neighboring signal. These will make sure that in case a communication link is down,that problem will be identified as its property will not be satisfied. For real-time control oftraffic congestion these requirements are necessary. The properties we want to verify arewhether all the ARTIS agents of the MTM signal able to communicate with all the otherARTIS agents of the same signal or not. Similarly whether all the ARTIS agents of the TNBsignal able to communicate with all the other ARTIS agents of the same signal or not. Ifthese properties are satisfied then this means that the intra-signal communication between thetraffic signals is working fine. Then we verify the inter-signal communication. This meansthat all the ARTIS agents of the MTM signal should able to communicate with all the ARTISagents of the TNB signal and vice versa.


Fig. 4.18 Communication model of the Muslim Town Mor signal.


Fig. 4.19 Communication model of the Thokar Niaz Baig signal.


Table 4.3 Properties for correct functioning of the communication model of Thokar NiazBaig and Muslim Town Mor Signal. Their corresponding TCTL formulas in TAPAAL is alsoshown.

Query Formula ResultCan MTM1 ARTIS agent com-municate with MTM2 ARTISagent?

EF (MTM Model.MTM1 ARTISAgent = 1 andStart = 1 and MTM Model.MTM2 ARTISAgent =1)

Satisfied

Can MTM1 ARTIS agent com-municate with MTM3 ARTISagent?


Satisfied



Satisfied



Satisfied



Satisfied



Satisfied



Satisfied



Satisfied



Satisfied



Satisfied

Can TNB1 ARTIS agent com-municate with TNB2 ARTISagent?

EF (TNB Model.TNB1 ARTISAgent = 1 and Start= 1 and TNB Model.TNB2 ARTISAgent = 1)

Satisfied



Satisfied



Satisfied


Query Formula ResultCan TNB2 ARTIS agent com-municate with TNB3 ARTISagent?


Satisfied



Satisfied



Satisfied

Can MTM1 ARTIS agent com-municate with all the ARTISagents of the TNB station?

EF ((MTM Model.MTM1 ARTISAgent = 1 andStart = 1 and TNB Model.TNB1 ARTISAgent =1) and (MTM Model.MTM1 ARTISAgent = 1 andStart = 1 and TNB Model.TNB2 ARTISAgent =1) and (MTM Model.MTM1 ARTISAgent = 1 andStart = 1 and TNB Model.TNB3 ARTISAgent =1) and (MTM Model.MTM1 ARTISAgent = 1 andStart = 1 and TNB Model.TNB4 ARTISAgent =1))

Satisfied



Satisfied



Satisfied





Satisfied



Satisfied

Can TNB1 ARTIS agent com-municate with all the ARTISagents of the MTM station?

EF ((TNB Model.TNB1 ARTISAgent = 1 andStart = 1 and MTM Model.MTM1 ARTISAgent= 1) and (TNB Model.TNB1 ARTISAgent = 1 andStart = 1 and MTM Model.MTM2 ARTISAgent =1) and (TNB Model.TNB1 ARTISAgent = 1 andStart = 1 and MTM Model.MTM3 ARTISAgent =1) and (TNB Model.TNB1 ARTISAgent = 1 andStart = 1 and MTM Model.MTM4 ARTISAgent =1) and (TNB Model.TNB1 ARTISAgent = 1 andStart = 1 and MTM Model.MTM5 ARTISAgent =1))

Satisfied



Satisfied





Satisfied



Satisfied

4.4.3 Computational Statistics of the Discovered Markings, Trace andTransitions

The communication model presented in the previous section was executed on a system withIntel Core i5 processor and 8GB memory. The computational statistics of the discoveredmarkings, trace and transitions fired during the verification process are shown in Table 4.4,Table 4.5 and Table 4.6 respectively. For succinctness, all these parameters are shown for onlyone property name Can MTM1 ARTIS agent communicate with all the ARTIS agentsof the TNB station?. The discovered markings is the number of found markings. Theexplored markings is the number of markings taken out of the waiting list during the search.The stored markings is the number of markings found in the passed/waiting at the end ofverification. The verification time is the time taken in seconds for the property to be verified.The memory usage is the memory used in mega bytes for the verification of this property.

The count for each transition triggered for the satisfaction of this property are shown inTable 4.5. As the name implies TNB refers to the transitions at the Thokar Niaz Baig Signaland MTM refers to the transitions at the Muslim Town Mor signal. One out of many possibletraces for the satisfaction of this property is shown in Table 4.6.


Table 4.4 Statistics for markings, verification time and memory usage.

No. Attribute Result1. Discovered Markings 22853782. Explored Markings 1584783. Stored Markings 2818464. Verification Time 235.67 s5. Memory Usage 5478 MB

Table 4.5 Table showing statistics for transitions fired.

No. Count Transition1 118345 MTM Model.Trigger2 118345 TNB Model.Trigger3 68216 TNB Model.Init TNB1 Updates4 63962 TNB Model.T115 52363 TNB Model.Init TNB2 Updates6 46602 TNB Model.Init TNB4 Updates7 43866 MTM Model.Init MTM1 Updates8 41676 TNB Model.TNB1 Updates9 36319 TNB Model.TNB2 Updates10 30536 MTM Model.Init MTM2 Updates11 28191 TNB Model.TNB3 Updates12 27021 MTM Model.Init MTM4 Updates13 23144 MTM Model.MTM1 Updates14 22212 MTM Model.T1115 21605 MTM Model.MTM2 Updates16 21487 TNB Model.TNB4 Updates17 15942 MTM Model.MTM3 Updates18 13845 MTM Model.MTM4 Updates19 4571 MTM Model.Init MTM5 Updates20 3074 TNB Model.Init TNB3 Updates21 2042 MTM Model.Init MTM3 Updates22 716 MTM Model.MTM5 Updates


Table 4.6 Table showing trace for the verified property.

No. Transition1 Initial Marking2 MTM Model.Trigger3 TimeDelay: 14 MTM Model.Init MTM1 Updates5 MTM Model.MTM1 Updates6 TimeDelay: 17 MTM Model.Init MTM1 Updates8 MTM Model.Init MTM2 Updates9 MTM Model.MTM2 Updates10 MTM Model.T1111 TNB Model.Trigger12 MTM Model.T1113 TNB Model.Trigger14 TimeDelay: 115 MTM Model.Init MTM1 Updates16 MTM Model.Init MTM3 Updates17 TNB Model.Init TNB1 Updates18 TimeDelay: 119 MTM Model.Init MTM2 Updates20 MTM Model.T1121 TNB Model.Init TNB1 Updates22 TNB Model.TNB1 Updates


4.4.4 Fault Handling using Self-Adaptive Functionality

We demonstrated the application of SMARTS framework using the following possible failurescenarios. One-hop neighbor policy will be used for the self-organization.

1. Failure of single traffic monitoring station at a signal.

2. Failure of single traffic monitoring station at two signals consecutively.

Failure of Single Traffic Monitoring Station at a Signal

We took the MTM signal for this scenario. Suppose that MTM3 signal stops working due tosome error. Before its failure every station of this signal had communication link with theirtwo neighbors. The failure scenario is elaborated using the Figure 4.20. After re-organizationand re-establishment of the communication links the system is shown in Figure 4.21.

Failure of Single Traffic Monitoring Station at Two Signals Consecutively

For this scenario we assume that in addition to the previous scenario i.e failure of MTM3signal, the TNB1 signal has stopped working also. The failure scenario is elaborated usingthe Figure 4.22. After re-organization and re-establishment of communication links thesystem is shown in Figure 4.23.


Fig. 4.20 Failure of single traffic monitoring station at Muslim Town Mor signal.


Fig. 4.21 Re-organization of the system after failure of single traffic monitoring station.


Fig. 4.22 Failure of two traffic monitoring stations at two locations of the Muslim Town Morsignal and Thokar Niaz baig signal.


Fig. 4.23 Re-organization of the system after failure of two traffic monitoring stations.


4.4.5 Run-time Adaptation of the System Based on Congestion Situa-tion

In this section we demonstrate the situation of how the system will adapt itself to the changingtraffic situations. We consider the case of congestion at one of the monitoring station of theMuslim Town Mor signal i.e MTM2. For the formal specification we define the followingtypes and predicates.

MessageType ::= Inform | RequestInform ::= Congestion | Neighnor ChangeCongestion ::= TrafficTypeRequest ::= Change Signal Duration

Message is a predicate specified as

Message(U,W,X,Y,Z): Message with meta-information U (meta-information contains themessage Id and time stamp). Sent by sender W to receiver X containing MessageType Y andcontent Z.

Since there is congestion at MTM2, the rest of the stations at this signal needs to beinformed. The congestion at MTM2 was detected by the MAPE-K feedback loop. The nec-essary plans for handling the congestion includes informing its one-hop neighbors about thecongestion so that maximum time (green signal) can be given to MTM2. Its correspondingneighbors are MTM1 and MTM3.

Message(U,MTM2,MTM1,FULL CONGESTION,MSG)

MTM2ARTISAgent

MonitorARTISAgentid : Idc : chanmeta info : ID×TIME


SendMessage′

receiver? : MTM1ARTISAgenttime stamp? : TIMEFULL CONGESTION? : TrafficTypecontent? : Content

Message(id× time stamp,SELF,receiver,FULL CONGESTION,content)

SendMessage =̂ [id? : Id; time stamp? : TIME; receiver? : MTM1ARTISAgent;FULL CONGESTION? : TrafficType; content? : Content] •SendMessage′ → c!(Message)→ SKIPMAIN =̂ µ T • SendMessage; T

This in turn will initiate a series of messages between all the stations of this signal.The formal specification of these monitoring stations and their corresponding messagesexchanged has been specified in Appendix A.1.




To limit the exchange of messages between station to ensure real-time behavior, themessages for congestion alert will always be N-1 (where N = number of stations). SinceMuslim Town Mor signal is connected via MTM3 to Thokar Niag Baig signal, the TNB2will coordinate with its one-hop neighbors about the congestion situation. Here MSG willnotify the corresponding stations that the congestion is not at this particular signal but theneighboring signal.

Message(U,TNB2,TNB1,FULL CONGESTION,MSG)


TNB2ARTISAgent


SendMessage′

receiver? : TNB1ARTISAgenttime stamp? : TIMEFULL CONGESTION? : TrafficTypecontent? : Content


SendMessage =̂ [id? : Id; time stamp? : TIME; receiver? : TNB1ARTISAgent;FULL CONGESTION? : TrafficType; content? : Content] •SendMessage′ → c!(Message)→ SKIPMAIN =̂ µ T • SendMessage; T

Again this will initiate a series of messages between all the stations of this signal. The for-mal specification of these monitoring stations and their corresponding messages exchangedhas been specified in Appendix A.2.



As discussed above by default each station remains green for 20 seconds. This meansthat at MTM signal since there are 5 stations then each will have to wait for 80 secondsbefore it turns green. In this situation to clear up the congestion at MTM2 its green time willbe increased to 60 seconds. The remaining four stations will remain green for 10 seconds now.

Message(U,MTM2,MTM1,Change Signal Duration,10)


MTM2ARTISAgent


SendMessage′

receiver? : MTM1ARTISAgenttime stamp? : TIMEChange Signal Duration? : Requestcontent? : Content

Message(id× time stamp,SELF,receiver,Change Signal Duration,content)

SendMessage =̂ [id? : Id; time stamp? : TIME; receiver? : MTM1ARTISAgent;Change Signal Duration? : Request; content? : Content] •SendMessage′ → c!(Message)→ SKIPMAIN =̂ µ T • SendMessage; T





As there is no congestion at the neighboring signal of Thokar Niag Baig it can also adjustits signal duration to accommodate the maximum traffic from MTM signal. At TNB everystation remained green for 20 second also but waited for 60 seconds. The green duration forTNB2 will now be 50 seconds and it wont change the waiting time of other stations.Message(U,TNB2,TNB1,Change Signal Duration,10)


TNB2ARTISAgent


SendMessage′

receiver? : TNB1ARTISAgenttime stamp? : TIMEChange Signal Duration? : Requestcontent? : Content


SendMessage =̂ [id? : Id; time stamp? : TIME; receiver? : TNB1ARTISAgent;Change Signal Duration? : Request; content? : Content] •SendMessage′ → c!(Message)→ SKIPMAIN =̂ µ T • SendMessage; T


Message(U,TNB2,TNB3,Change Signal Duration,10)

Message(U,TNB3,TNB4,Change Signal Duration,10)

In this section we formally verified the real-time properties of the traffic agents. Wecreated Timed-arc Petri-net models of the complete traffic management system and then usedTAPAAL model checker for the formal verification. We ensured that the system is deadlockfree and bounded by specifying the properties in AF, AG, EG, and EF fragments of TCTL.The reachability analysis of the different traffic stations was also performed and depicted bytheir computation trees. For succinctness we only showed the computational statistics for asingle query but the rest of the queries can be analyzed in the same way. We elaborated thefault tolerance and run-time adaptation ability of the system. For fault tolerance a case ofsingle and multiple traffic stations failure was discussed and how the system re-organizes itselfin each case was shown. The run-time adaptation of the traffic system based on congestionsituation was discussed and how the different system entities coordinated via predicates for

4.5 Application Areas and Socioeconomic Benefits 92

managing congestion was shown. With the increasing complexity and dynamism of RTMASsa precise conceptual model of the system might provide useful insights before the system isactually developed.

4.5 Application Areas and Socioeconomic Benefits

Other than the smart traffic management as demonstrated by our case study there are a largenumber of areas where our proposed SMARTS framework can be used to improve the theoryand practice of modelling, designing, and implementing complex systems. Here we willdiscuss some of these in detail. It can be used to model mobile robots in multi-robot pathplanning. In this case every robot is assigned a set of task that it has to perform in a real-timeby choosing the most feasible path (not necessarily the shortest). It can also be used to modelonline auction systems. In these auctions the price fluctuation is real-time and these couldbe monitored by a monitoring agent that keeps track of every single event taking place andinform the stakeholders when an event of interest will take place. It can also be used tomodel online ticket reservation system that offers better choices in comparison to the priceline system. Agents will manage the preferences and interests of each party involved andcoordinate with other agents in teal-time to recommend the most feasible option to the buyer.It can also be used for the real-time management of an ATM network. In this case the agentsmain task is to consider link bandwidth allocation and dynamic routing of data. It can be usedfor electricity transport management, which is the process of monitoring and controlling thecycle of generating, transporting and distributing electrical energy to industrial and domesticcustomers. In this case the agents purpose is to reduce the operator’s cognitive load incritical situations, and to decrease the response time for making decisions. It can also beused for real-time scheduling for taxi companies. In this case rather than humans taking thedecisions of dispatching the taxis, the task will be performed by different agents. Differentagents will accommodate different clients based on geographical location and re-scheduletaxi service before confirming order acceptance to the client. The system will have the abilityto update schedules in intervals between two events, in real time for optimization. Althoughin Pakistan the concept of Smart homes has not been introduced but in technologicallyadvanced countries thus is an active area of research. The aim is to improve the efficiencyand optimize the energy consumption of smart homes. Our proposed framework can used forthe modeling of such Smart homes where multiple interactive intelligent agents collaboratein an environment to reduce energy consumption while striking a balance between consumerscomfort, energy cost and peak energy saving in the distribution grid. This list of applicationareas is too large to be discussed here. However the main objective in all of these areas is to


model a distributed complex network where a number of agents coordinate with each other togive optimized performance in a real-time environment and be able to handle faults and nodefailures to provide a minimum quality of service. SMARTS will help to design the systemfrom a high-level point of view, identifying the number and type of the real-time agents inthe system and detailing the inter-agent relations and the required interaction protocols. Itwill help to define the temporal aspects of different tasks, define the interactions, protocolsand the necessary messages and their contents, schedulability of the tasks etc.

With respect to the socioeconomic benefits of the conducted research, some of these arenear sighted and some are far sighted. For example traffic congestion is a major concernfor nearly all them major cities of Pakistan. Although increase in current infrastructure is aproblem but a bigger problem is to efficiently utilize the already existing infrastructure. Allthe traffic signals in Pakistan are either timer based (automatic) or manual controlled by thetraffic sergeants deployed at these signals. A major hurdle these sergeants face is that theyonly have the traffic insights of the signals where they are deployed and usually have no ideaabout the neighboring signal situations. So in extreme case a sergeant might be completelyidle at a signal whereas his neighboring sergeant is managing a completely congested traffic.The same problem is with the timer-controlled signals where it will automatically changeits lights based on time and not traffic congestion. Using our SMARTS framework thisproblem can effectively solved. There is an increasing trend of ecommerce in Pakistan andthe concept of online auction is also new. In case of online auction systems the buyers canget a competitive used product by real-time bidding process. The current automated biddingprocess uses an algorithm to show the few highest placed bids and the complete system iscentralized. In case of failure the whole system may break down. In this case the idea ofmulti-agent systems with de-centralized ability cane be effectively utilized. These distributedreal-time multi-agents systems will have a better fault tolerance and self-organizing ability. Incase of online ticket reservation system a client either calls the agency or uses its website toreserve a ticket. After giving the necessary details the systems reserves its ticket. The client isnever informed about the different options available rather the automated system uses price asthe most feasible criteria. This system can be effectively managed by a real-time multi-agentsystem where different agents will coordinate in real-time to find the most feasible ticketbased on different criteria like total time of flight, reputation if the company in terms ofcustomer satisfaction, etc. Additionally the agent can re-organize itself based on client historyto better facilitate him. Our proposed framework can also be used to resolve the commonATM link down problem in Pakistan. All ATM networks in Pakistan are centralized so whena client enters its credential to use the ATM they are sent to the server for verification. Otherthan this all the customer data is also stored in a central location. This creates a single point if


failure and customer often have to face link down problem especially during the peak hours.Using SMARTS each ATM node will be a real-time agent itself coordinating with the restof the agents that are part of the network. Any change in customer’s data will necessitatethe updating of all the knowledge base of all the agents. Pakistan is in electricity crisis thesedays where the total electricity generation is far less than the total electricity consumption.During peak hours in summer an occasional problem is the shut down of power generationhouses due to over loading. The process of electricity routing is still manual and the operatorfor this purpose only has idea about its local location. The proposed framework can usedto efficiently route the electricity from the grid stations. In case of real-time multi-agentsystems these agents will remain in constant communication to coordinate the load situationamong others. The concept of using online Taxi reservation system is rising in Pakistan andapplications like Uber, Careem, etc has made is much easier for people having smart phonesto utilize the service. With these applications the customer orders a taxi and the automatedapplication based on customers location notifies the nearest taxi. These applications havea centralized database, which is processed in real-time and all the decisions are taken onthis server. Rather than a centralized processing server these applications could be modifiedto work on the principle of real-time multi-agent systems. Each agent will handle a set ofcustomers from a limited geographical area and it will only have knowledge of that area.In this case when an agent stops working the system will continue to work. It can also beused for real-time scheduling for taxi companies. In this case rather than humans taking thedecisions of dispatching the taxis, the task will be performed by different agents. Differentagents will accommodate different clients based on geographical location and re-scheduletaxi service before confirming order acceptance to the client. The system will have theability to update schedules in intervals between two events, in real time for optimization. Ourproposed framework can also be used to the use of electricity on a per house basis. The ideais to use the technology of Smart Homes. In technologically advance countries the concept ofSmart homes has already been used where a set of intelligent agents control all the householdappliances to use them on a need per basis. The basic purpose is to reduce the electricity andsave as much of it as possible. Pakistan is already facing a huge electricity shortage so thisconcept can be very effective for us.

Chapter 5

Conclusion and Discussions

The multi-agent systems paradigm has been in use for the ubiquitous and pervasive environ-ments and they are seen as a key enabling technology to model critical components of a largenumber of distributed applications. To ensure a high degree of reliability of these systemstheir formal modelling is necessary as state of the art in the self-adaptive software systemsrecommend the use of formal methods. A comprehensive review of the related works revealsthat there is a lack of research on consolidating design knowledge for real-time self-adaptivemulti-agent systems. Hence there is a dire need of formal vocabulary that can be used for theconceptual design of any real-time multi-agent system with self-adaptation.

In this work we propose a framework named SMARTS for the formal modelling ofself-adaptive real-time multi-agent systems which can be used for the formal architecturalspecification of any real-time multi agent systems. It is an extension of the FORMS referencemodel as proposed in [12]. The major limitation of the FORMS reference model is thatit is not directly applicable to the multi-agent systems paradigm. Our framework uses thereflection perspective and unification with distribution perspective of the FORMS referencemodel into the SIMBA agent architecture and overcomes this limitation. It provides aclear distinction between entities providing the domain functionality and the reflectivecomputations needed for the adaptation. Self-adaptive functionality is provided by using fourset of interfaces namely Monitor, Analyze, Plan and Execute, each targeting four phases ofthe MAPE-K feedback loop. We used TCOZ for the formal specification of our frameworkand the major advantage is that we can utilize the active class concept of TCOZ to expressthe non-terminating behavior of the autonomous agents. The provision of communicationchannels in TCOZ greatly simplify the class definitions, class referencing, enhancing theirmodularity. The framework as a whole is FIPA-compliant and the run-time schedulabilityensures that the tasks meet their deadline when deployed. We demonstrated the applicationof SMARTS using a case study of real-time traffic signal. The case study elaborates the

96

scenario of fault tolerance in case of a node failure and real-time traffic congestion controlin a distributed environment. For formal verification we used Timed-Arc Petri-Nets andcreated traffic models in the TAPAAL model checker. We verified properties to ensure thecorrectness of the traffic models by specifying them in TCTL. The specified properties checkthe fault tolerance and real-time constraints of the traffic models using transition intervalsand token’s age. For visual interpretation of the traffic models we created their computationtrees. To analyze the complexity of the complete traffic system we show traces of the verifiedproperties, number of times a transition was triggered and number of times a place wasvisited. These computational statistics are useful for a system designer to ensure that thesystem is live and deadlock free.

Our approach provides future directions for integrating TCOZ, timed petri-nets and agentcommunication as a flexible and powerful tool for formal modelling of complex real-timesystems. Formal verification will help to prove the correctness of the system being modelledwhich in turn will increase the confidence in the correctness of these systems. Anotheradvantage of our approach is that the formal specification of SMARTS is provided in TCOZwhich is an extension of Z-language. This will minimize the time required to understandthe SMARTS framework as it is usually difficult for researchers to understand the complexformal constructs. Our formal vocabulary is generic enough to express a real-time multi-agentsystem of any domain. It is also fine grained enough to test the properties of the system forthe provision of domain functionality. The research conducted will help to formally modelself-adaptive real-time multi-agent systems at the design time. For future work we intend towork on the issues of communication between multiple self-adaptive systems using diverseagent platforms. Specifically issues related to the agent communication languages for diverseagents with self-adaptive ability.

Published, Accepted and SubmittedWork

Published and Accepted Work

1. Qasim, Awais, A. R. Kazmi, and Ilyas Fakhir. "Formal specification and verificationof real-time multi-agent system using timed Arc Petri Nets." Advances in Electricaland Computer Engineering 15.3 (2015): 73-8. (Published)

2. Qasim, Awais, Syed Asad Raza Kazmi, and Ilyas Fakhir. "Executable Semantics forthe Formal Specification and Verification of E-agents." Indian Journal of Science andTechnology 8.16 (2015). (Published)

3. Qasim, Awais, and Syed Asad Raza Kazmi. "MAPE-K Interfaces for Formal Modellingof Real-Time Self-Adaptive Multi-Agent Systems." IEEE Access 4 (2016): 4946-4958.(Published)

4. Fakhir, Ilyas, et al. "Concurrency in Intuitionistic Linear-Time µ-Calculus: A Casestudy of Manufacturing System." Indian Journal of Science and Technology 9.6 (2016).(Published)

5. Awais Qasim, Syed Asad Raza Kazmi, and Ilyas Fakhir. "Critical analysis regardingcognition of intelligent distribution agent." Science International 27.5 (2015): 4447-4454. (Published)

6. "Temporal modelling and verification of multi-robot concurrent activities". IndianJournal of Science and Technology 9.48 (2016). ISSN: 0974-6846. (Published)

7. Ilyas Fakhir, Asad Raza Kazmi, Awais Qasim, Farooq Ahmad. "A Learning-BasedAutonomous System for Driving a Car using CLARION". International Journal ofComputer Science & Information Security 14.12 (2016). ISSN: 1947-5500. (Pub-lished)

98

8. Awais Qasim, Syed Asad Raza Kazmi. "Formal Modelling of Real-Time Self-AdaptiveMulti-Agent Systems". Intelligent Automation & Soft Computing, 2016. ISSN: 1079-8587. (Accepted)

Submitted Work

9. Awais Qasim, Syed Asad Raza Kazmi. "SA-ARTIS-Agent for Formal Modelling ofReal-Time Multi-Agent Systems". Intelligent Automation & Soft Computing, 2016.ISSN: 1079-8587. (In Revision)

10. Syed Asad Raza Kazmi, Sana Abubakkar, Awais Qasim. "Formal Modeling andVerification of the Operational Modes of Pacemaker". Indian Journal of Science andTechnology, 2016. ISSN: 0974-6846. (Submitted)

11. Imran Rafique, Hina Gul, Salman Rafique, Ilyas Fakhir, Asad Raza Kazmi,AwaisQasim. "Optimized Application Level Checkpoint Based Load Sharing Model forHeterogeneous Mobile Grid Computing". Indian Journal of Science and Technology,2016. ISSN: 0974-6846. (Submitted)

References

[1] Nicholas R Jennings, Katia Sycara, and Michael Wooldridge. A roadmap of agentresearch and development. Autonomous agents and multi-agent systems, 1(1):7–38,1998.

[2] Vicente Julian and V Botti. Developing real-time multi-agent systems. IntegratedComputer-Aided Engineering, 11(2):135–149, 2004.

[3] Delbert Tesar. Next wave of technology. Intelligent Automation & Soft Computing,22(2):211–225, 2016.

[4] Ranjith Ravindranathan Nair, Laxmidhar Behera, Vinod Kumar, and Mo Jamshidi.Multisatellite formation control for remote sensing applications using artificial poten-tial field and adaptive fuzzy sliding mode control. Systems Journal, IEEE, 9(2):508–518, 2015.

[5] Rogério De Lemos, Holger Giese, Hausi A Müller, Mary Shaw, Jesper Andersson,Marin Litoiu, Bradley Schmerl, Gabriel Tamura, Norha M Villegas, Thomas Vogel,et al. Software engineering for self-adaptive systems: A second research roadmap. InSoftware Engineering for Self-Adaptive Systems II, pages 1–32. Springer, 2013.

[6] Albert Benveniste and Gérard Berry. The synchronous approach to reactive andreal-time systems. Proceedings of the IEEE, 79(9):1270–1282, 1991.

[7] Sandro Bologna and Nancy G Leveson. Foreword reliability and safety in real-timesystems. IEEE Transactions on Software Engineering, (9):877–878, 1986.

[8] Albert MK Cheng. Real-time systems: scheduling, analysis, and verification. JohnWiley & Sons, 2003.

[9] Lothar Thiele and Reinhard Wilhelm. Design for timing predictability. Real-TimeSystems, 28(2-3):157–177, 2004.

[10] Selma Saidi, Rolf Ernst, Sascha Uhrig, Henrik Theiling, and Benoît Dupontde Dinechin. The shift to multicores in real-time and safety-critical systems. InHardware/Software Codesign and System Synthesis (CODES+ ISSS), 2015 Interna-tional Conference on, pages 220–229. IEEE, 2015.

[11] Vicente Julian, Carlos Carrascosa, Miguel Rebollo, Jose Soler, and V Botti. Simba: anapproach for real-time multi-agent systems. In Topics in Artificial Intelligence, pages282–293. Springer, 2002.

References 100

[12] Danny Weyns, Sam Malek, and Jesper Andersson. Forms: Unifying reference modelfor formal specification of distributed self-adaptive systems. ACM Transactions onAutonomous and Adaptive Systems (TAAS), 7(1):8, 2012.

[13] Awais Qasim, Syed Asad Raza Kazmi, and Ilyas Fakhir. Executable semantics forthe formal specification and verification of e-agents. Indian Journal of Science andTechnology, 8(16), 2015.

[14] Sooyong Park and Vijayan Sugumaran. Designing multi-agent systems: a frameworkand application. Expert Systems with Applications, 28(2):259–271, 2005.

[15] David L Martin, Adam J Cheyer, and Douglas B Moran. The open agent architecture:A framework for building distributed software systems. Applied Artificial Intelligence,13(1-2):91–128, 1999.

[16] Michael Wooldridge. Semantic issues in the verification of agent communicationlanguages. Autonomous agents and multi-agent systems, 3(1):9–31, 2000.

[17] Laura Giordano, Alberto Martelli, and Camilla Schwind. Specifying and verifyingsystems of communicating agents in a temporal action logic. In AI* IA 2003: Advancesin Artificial Intelligence, pages 262–274. Springer, 2003.

[18] Laura Giordano, Alberto Martelli, and Camilla Schwind. Specifying and verifyinginteraction protocols in a temporal action logic. Journal of Applied Logic, 5(2):214–234, 2007.

[19] Massimo Benerecetti, Fausto Giunchiglia, and Luciano Serafini. Model checkingmultiagent systems. Journal of Logic and Computation, 8(3):401–423, 1998.

[20] David JT Sumpter, Guy B Blanchard, and David S Broomhead. Ants and agents: aprocess algebra approach to modelling ant colony behaviour. Bulletin of MathematicalBiology, 63(5):951–980, 2001.

[21] Alessandro Giua and Carla Seatzu. Modeling and supervisory control of railwaynetworks using petri nets. Automation Science and Engineering, IEEE Transactionson, 5(3):431–445, 2008.

[22] Ghulam Ali, Sherafzal Khan, Nazir Ahmad Zafar, and Farooq Ahmad. Formal mod-eling towards a dynamic organization of multi-agent systems using communicatingx-machine and z-notation. Indian Journal of Science and Technology, 5(7):2972–2977,2012.

[23] Sofia Kouah, Djamel Eddine Saïdouni, and Jean Michel Ilié. Synchronized petri net: Aformal specification model for multi agent systems. Journal of Software, 8(3):587–602,2013.

[24] Sama Khosravifar. Modeling multi agent communication activities with petri nets.International Journal of Information and Education Technology, 3(3):310, 2013.

[25] Lily Chang, Xudong He, and Sol M Shatz. A methodology for modeling multi-agentsystems using nested petri nets. International Journal of Software Engineering andKnowledge Engineering, 22(07):891–925, 2012.

References 101

[26] Albert Pla, Pablo Gay, Joaquim Meléndez, and Beatriz López. Petri net-based processmonitoring: a workflow management system for process modelling and monitoring.Journal of Intelligent Manufacturing, 25(3):539–554, 2014.

[27] Francis Guerin. Specifying agent communication languages. Citeseer, 2002.

[28] Rogier M van Eijk, Frank S de Boer, Wiebe van der Hoek, and John-Jules Ch Meyer.Process algebra for agent communication: A general semantic approach. In Communi-cation in Multiagent Systems, pages 113–128. Springer, 2003.

[29] Arni Hermann Reynisson, Marjan Sirjani, Luca Aceto, Matteo Cimini, Ali Jafari,Anna Ingolfsdottir, and Steinar Hugi Sigurdarson. Modelling and simulation of asyn-chronous real-time systems using timed rebeca. Science of Computer Programming,89:41–68, 2014.

[30] Yixiang Chen. Stec: A location-triggered specification language for real-time systems.In Object/Component/Service-Oriented Real-Time Distributed Computing Workshops(ISORCW), 2012 15th IEEE International Symposium on, pages 1–6. IEEE, 2012.

[31] Thillainathan Logenthiran, Dipti Srinivasan, Ashwin M Khambadkone, and Htay NweAung. Multiagent system for real-time operation of a microgrid in real-time digitalsimulator. Smart Grid, IEEE Transactions on, 3(2):925–933, 2012.

[32] Alessio Lomuscio, Hongyang Qu, and Franco Raimondi. Mcmas: an open-sourcemodel checker for the verification of multi-agent systems. International Journal onSoftware Tools for Technology Transfer, pages 1–22, 2015.

[33] Savas Konur, Michael Fisher, and Sven Schewe. Combined model checking fortemporal, probabilistic, and real-time logics. Theoretical Computer Science, 503:61–88, 2013.

[34] Jun Sun, Yang Liu, Jin Song Dong, Yan Liu, Ling Shi, and Étienne André. Mod-eling and verifying hierarchical real-time systems using stateful timed csp. ACMTransactions on Software Engineering and Methodology (TOSEM), 22(1):3, 2013.

[35] Álvaro Herrero, Martí Navarro, Emilio Corchado, and Vicente Julián. Rt-movicab-ids: Addressing real-time intrusion detection. Future Generation Computer Systems,29(1):250–261, 2013.

[36] Meng Guo and Dimos V Dimarogonas. Multi-agent plan reconfiguration under localltl specifications. The International Journal of Robotics Research, 34(2):218–235,2015.

[37] Warda El Kholy, Mohamed El Menshawy, Amine Laarej, Jamal Bentahar, FaisalAl-Saqqar, and Rachida Dssouli. Real-time conditional commitment logic. In PRIMA2015: Principles and Practice of Multi-Agent Systems, pages 547–556. Springer, 2015.

[38] Ioannis Filippidis, Dimos V Dimarogonas, and Kostas J Kyriakopoulos. Decentralizedmulti-agent control from local ltl specifications. In Decision and Control (CDC), 2012IEEE 51st Annual Conference on, pages 6235–6240. IEEE, 2012.

References 102

[39] Emilia Garcia, Adriana Giret, and Vicente Botti. A model-driven case tool fordeveloping and verifying regulated open mas. Science of Computer Programming,78(6):695–704, 2013.

[40] Zhuang Li and Huaikou Miao. Formal specification and reasoning for situated multi-agent system. In Computer and Information Science (ICIS), 2015 IEEE/ACIS 14thInternational Conference on, pages 455–460. IEEE, 2015.

[41] Vincent Hilaire, Pablo Gruer, Abderrafiaa Koukam, and Olivier Simonin. Formaldriven prototyping approach for multiagent systems. International Journal of Agent-Oriented Software Engineering, 2(2):246–266, 2008.

[42] Tim Miller and Peter McBurney. Multi-agent system specification using tcoz. InMultiagent System Technologies, pages 216–221. Springer, 2005.

[43] Elisabeth Ball and Michael Butler. Event-b patterns for specifying fault-tolerancein multi-agent interaction. In Methods, models and tools for fault tolerance, pages104–129. Springer, 2009.

[44] Graeme Smith and Kirsten Winter. Incremental development of multi-agent systemsin object-z. In Software Engineering Workshop (SEW), 2012 35th Annual IEEE, pages120–129. IEEE, 2012.

[45] Didac Gil De La Iglesia and Danny Weyns. MAPE-K formal templates to rigorouslydesign behaviors for self-adaptive systems. ACM Transactions on Autonomous andAdaptive Systems (TAAS), 10(3):15, 2015.

[46] Danny Weyns, Nelly Bencomo, Radu Calinescu, Javier Camara, Carlo Ghezzi, Vin-cenzo Grassi, Larse Grunske, Paola Inverardi, Jean-Marc Jezequel, Sam Malek, et al.Perpetual assurances in self-adaptive systems. In Assurances for Self-Adaptive Systems,Dagstuhl Seminar, volume 13511, 2014.

[47] Nadeem Abbas, Jesper Andersson, Muhammad Usman Iftikhar, and Danny Weyns.Rigorous architectural reasoning for self-adaptive software systems. In Proceedingsof the 1st Workshop on Qualitative Reasoning about Software Architectures, pages1–8. IEEE, 2016.

[48] Rajeev Alur and David L Dill. A theory of timed automata. Theoretical computerscience, 126(2):183–235, 1994.

[49] Rajeev Alur, Alon Itai, Robert P Kurshan, and Mihalis Yannakakis. Timing verificationby successive approximation. Information and Computation, 118(1):142–157, 1995.

[50] Jeffrey O Kephart and David M Chess. The vision of autonomic computing. Computer,36(1):41–50, 2003.

[51] Mary Shaw. Beyond objects: A software design paradigm based on process control.ACM SIGSOFT Software Engineering Notes, 20(1):27–38, 1995.

[52] Jeff Kramer and Jeff Magee. Self-managed systems: an architectural challenge. InFuture of Software Engineering, 2007. FOSE’07, pages 259–268. IEEE, 2007.

References 103

[53] Peyman Oreizy, Nenad Medvidovic, and Richard N Taylor. Architecture-based runtimesoftware evolution. In Proceedings of the 20th international conference on Softwareengineering, pages 177–186. IEEE Computer Society, 1998.

[54] David Garlan, Shang-Wen Cheng, An-Cheng Huang, Bradley Schmerl, and PeterSteenkiste. Rainbow: Architecture-based self-adaptation with reusable infrastructure.Computer, 37(10):46–54, 2004.

[55] Kurt Geihs, Roland Reichle, Michael Wagner, and Mohammad Ullah Khan. Modelingof context-aware self-adaptive applications in ubiquitous and service-oriented environ-ments. In Software engineering for self-adaptive systems, pages 146–163. Springer,2009.

[56] Björn Bartels and Sabine Glesner. Verification of distributed embedded real-timesystems and their low-level implementations using timed csp. In Software EngineeringConference (APSEC), 2011 18th Asia Pacific, pages 195–202. IEEE, 2011.

[57] Björn Bartels and Moritz Kleine. A csp-based framework for the specification,verification, and implementation of adaptive systems. In Proceedings of the 6thInternational Symposium on Software Engineering for Adaptive and Self-ManagingSystems, pages 158–167. ACM, 2011.

[58] Awais Qasim, Syed Asad Raza Kazmi, and Ilyas Fakhir. Formal specification andverification of real-time multi-agent systems using timed-arc petri nets. Advances inElectrical and Computer Engineering, 15(3):73–78, 2015.

[59] Ina Schaefer and Reiner Hahnle. Formal methods in software product line engineering.Computer, 44(2):82–85, 2011.

[60] Didac Gil de La Iglesia. A formal approach for designing distributed self-adaptivesystems. 2014.

[61] Antonio Filieri, Henry Hoffmann, and Martina Maggio. Automated design of self-adaptive software with control-theoretical formal guarantees. In Proceedings of the36th International Conference on Software Engineering, pages 299–310. ACM, 2014.

[62] Phillip A Laplante and Seppo J Ovaska. Real-time systems design and analysis: toolsfor the practitioner. John Wiley and Sons, 2011.

[63] Jonathan S Ostroff and Richard F Paige. Formal methods in the classroom: The logicof real-time software design. In Real-Time Systems Education III, 1998. Proceedings,pages 63–70. IEEE, 1998.

[64] Aftab Ali Haider and Aamer Nadeem. Formal modelling languages to specify real-timesystems: A survey. International Journal of Future Computer and Communication,2(2):130, 2013.

[65] Paul Z Kolano. Proof assistance for real-time systems using an interactive theoremprover. In International AMAST Workshop on Aspects of Real-Time Systems andConcurrent and Distributed Software, pages 315–333. Springer, 1999.

References 104

[66] Yoo Jin Lim, Gwangui Hong, Donghwan Shin, Eunkyoung Jee, and Doo-Hwan Bae.A runtime verification framework for dynamically adaptive multi-agent systems. In2016 International Conference on Big Data and Smart Computing (BigComp), pages509–512. IEEE, 2016.

[67] Nazir Ahmad Zafar, Sher Afzal Khan, and Keijiro Araki. Towards the safety propertiesof moving block railway interlocking system. Int. J. Innovative Comput., Info &Control, 8(7):5677–5690, 2012.

[68] Danny Weyns and Radu Calinescu. Tele assistance: a self-adaptive service-basedsystem examplar. In Proceedings of the 10th International Symposium on SoftwareEngineering for Adaptive and Self-Managing Systems, pages 88–92. IEEE Press, 2015.

[69] Kenneth Johnson, Roopak Sinha, Radu Calinescu, and Ji Ruan. A multi-agent frame-work for dependable adaptation of evolving system architectures. In 2015 41stEuromicro Conference on Software Engineering and Advanced Applications, pages159–166. IEEE, 2015.

[70] Verena Klös, Thomas Göthel, and Sabine Glesner. Adaptive knowledge bases in self-adaptive system design. In 2015 41st Euromicro Conference on Software Engineeringand Advanced Applications, pages 472–478. IEEE, 2015.

[71] José M Gascueña, Elena Navarro, and Antonio Fernández-Caballero. Model-drivenengineering techniques for the development of multi-agent systems. EngineeringApplications of Artificial Intelligence, 25(1):159–173, 2012.

[72] Marina Ntika, Petros Kefalas, and Ioanna Stamatopoulou. Formal modelling andsimulation of a multi-agent nano-robotic drug delivery system. Scalable Computing:Practice and Experience, 15(3):217–230, 2014.

[73] Zeineb Graja, Frédéric Migeon, Christine Maurel, Marie-Pierre Gleizes, andAhmed Hadj Kacem. A stepwise refinement based development of self-organizingmulti-agent systems: Application to the foraging ants. In International Workshop onEngineering Multi-Agent Systems, pages 40–57. Springer, 2014.

[74] Matt Webster, Clare Dixon, Michael Fisher, Maha Salem, Joe Saunders, Kheng Koay,and Kerstin Dautenhahn. Formal verification of an autonomous personal roboticassistant. Formal Verification and Modeling in Human-Machine Systems, 2014.

[75] Didac Gil de la Iglesia, Juan Felipe Calderón, Danny Weyns, Marcelo Milrad, andMiguel Nussbaum. A self-adaptive multi-agent system approach for collaborativemobile learning. IEEE Transactions on Learning Technologies, 8(2):158–172, 2015.

[76] Xinjun Mao, Menggao Dong, and Haibin Zhu. A two-layer approach to developingself-adaptive multi-agent systems in open environment. International Journal of AgentTechnologies and Systems (IJATS), 6(1):65–85, 2014.

[77] Jonathan Bonnet, Marie-Pierre Gleizes, Elsy Kaddoum, Serge Rainjonneau, and Gre-gory Flandin. Multi-satellite mission planning using a self-adaptive multi-agent system.In 2015 IEEE 9th International Conference on Self-Adaptive and Self-OrganizingSystems, pages 11–20. IEEE, 2015.

References 105

[78] Yuhan Guo, Gilles Goncalves, and Tienté Hsu. A multi-agent based self-adaptivegenetic algorithm for the long-term car pooling problem. Journal of MathematicalModelling and Algorithms in Operations Research, 12(1):45–66, 2013.

[79] David Sanderson, Jeremy Pitt, and Dídac Busquets. Interactions of multipleself-adaptive mechanisms in multi-agent systems. In Proceedings of the 2013IEEE/WIC/ACM International Joint Conferences on Web Intelligence (WI) and Intelli-gent Agent Technologies (IAT)-Volume 02, pages 301–308. IEEE Computer Society,2013.

[80] Lijun Shan, Chenglie Du, and Hong Zhu. Modeling and simulating adaptive multi-agent systems with camle. In Computer Software and Applications Conference(COMPSAC), 2015 IEEE 39th Annual, volume 2, pages 147–152. IEEE, 2015.

[81] Frank D Macías-Escrivá, Rodolfo Haber, Raul del Toro, and Vicente Hernandez.Self-adaptive systems: A survey of current approaches, research challenges andapplications. Expert Systems with Applications, 40(18):7267–7279, 2013.

[82] Hosny Ahmed Abbas, Samir Ibrahim Shaheen, and Mohammed Hussein Amin. Or-ganization of multi-agent systems: an overview. arXiv preprint arXiv:1506.09032,2015.

[83] Christian Krupitzer, Felix Maximilian Roth, Sebastian VanSyckel, Gregor Schiele,and Christian Becker. A survey on engineering approaches for self-adaptive systems.Pervasive and Mobile Computing, 17:184–206, 2015.

[84] Luciano Baresi. Self-adaptive systems, services, and product lines. In Proceedings ofthe 18th International Software Product Line Conference-Volume 1, pages 2–4. ACM,2014.

[85] Mariachiara Puviani, Giacomo Cabri, Nicola Capodieci, and Letizia Leonardi. Build-ing self-adaptive systems by adaptation patterns integrated into agent methodolo-gies. In International Conference on Agents and Artificial Intelligence, pages 58–75.Springer, 2015.

[86] Mazeiar Salehie and Ladan Tahvildari. Self-adaptive software: Landscape and researchchallenges. ACM Transactions on Autonomous and Adaptive Systems (TAAS), 4(2):14,2009.

[87] Danny Weyns and Jesper Andersson. On the challenges of self-adaptation in systems ofsystems. In Proceedings of the First International Workshop on Software Engineeringfor Systems-of-Systems, pages 47–51. ACM, 2013.

[88] Jiming Liu. Autonomous agents and multi-agent systems: explorations in learning,self-organization and adaptive computation. World Scientific, 2001.

[89] Rajanikanth N Kashi, Meenakshi D’Souza, S Kumar Baghel, and Nitin Kulkarni.Formal verification of avionics self adaptive software: A case study. In Proceedingsof the 9th India Software Engineering Conference, pages 163–169. ACM, 2016.

References 106

[90] Nicolas Brax, Eric Andonoff, and Marie-Pierre Gleizes. A self-adaptive multi-agentsystem for abnormal behavior detection in maritime surveillance. In KES InternationalSymposium on Agent and Multi-Agent Systems: Technologies and Applications, pages174–185. Springer, 2012.

[91] Nicolas Brax. Self-adaptive multi-agent systems for aided decision-making: anapplication to maritime surveillance. PhD thesis, Université de Toulouse, UniversitéToulouse III-Paul Sabatier, 2013.

[92] Sara Rodríguez, Dante I Tapia, Juan F De Paz, Javier Bajo, Juan M Corchado, andAjith Abraham. Self-organizing multi-agent system for management and planningsurveillance routes. Computing and Informatics, 31(5):1081–1100, 2012.

[93] Licong Zhu, Hongming Cai, and Lihong Jiang. Minson: A business process self-adaptive framework for smart office based on multi-agent. In e-Business Engineering(ICEBE), 2014 IEEE 11th International Conference on, pages 31–37. IEEE, 2014.

[94] Moamin A Mahmoud and Mohd Sharifuddin Ahmad. A self-adaptive customer-oriented framework for intelligent strategic marketing: A multi-agent system approachto website development for learning institutions. In Agents, Multi-Agent Systems andRobotics (ISAMSR), 2015 International Symposium on, pages 1–5. IEEE, 2015.

[95] Hosny A Abbas, Samir I Shaheen, and Mohammed H Amin. Self-adaptive large-scalescada system based on self-organised multi-agent systems. International Journal ofAutomation and Control, 10(3):234–266, 2016.

[96] Paulo Leitão, José Barbosa, and Damien Trentesaux. Bio-inspired multi-agent systemsfor reconfigurable manufacturing systems. Engineering Applications of ArtificialIntelligence, 25(5):934–944, 2012.

[97] Nelson Rodrigues, Paulo Leitão, and Eugénio Oliveira. Adaptive services reconfigura-tion in manufacturing environments using a multi-agent system approach. In GermanConference on Multiagent System Technologies, pages 280–284. Springer, 2015.

[98] Gaël Clair, Elsy Kaddoum, Marie-Pierre Gleizes, and Gauthier Picard. Self-regulationin self-organising multi-agent systems for adaptive and intelligent manufacturingcontrol. In 2008 Second IEEE International Conference on Self-Adaptive and Self-Organizing Systems, pages 107–116. IEEE, 2008.

[99] Fu-Shiung Hsieh and Jim-Bon Lin. A self-adaptation scheme for workflow manage-ment in multi-agent systems. Journal of Intelligent Manufacturing, 27(1):131–148,2016.

[100] Jianxi Fu and Yuanlue Fu. An adaptive multi-agent system for cost collaborativemanagement in supply chains. Engineering Applications of Artificial Intelligence,44:91–100, 2015.

[101] Sushma Kumari, Akshit Singh, Nishikant Mishra, and Jose Arturo Garza-Reyes. Amulti-agent self-adaptive architecture for outsourcing manufacturing supply chain. InAdvances in Sustainable and Competitive Manufacturing Systems, pages 1185–1196.Springer, 2013.

References 107

[102] Sushma Kumari, Akshit Singh, Nishikant Mishra, and Jose Arturo Garza-Reyes. Amulti-agent architecture for outsourcing smes manufacturing supply chain. Roboticsand Computer-Integrated Manufacturing, 36:36–44, 2015.

[103] Ahmad Mortazavi, Alireza Arshadi Khamseh, and Parham Azimi. Designing ofan intelligent self-adaptive model for supply chain ordering management system.Engineering Applications of Artificial Intelligence, 37:207–220, 2015.

[104] Baudouin Dafflon, Jose Vilca, Franck Gechter, and Lounis Adouane. Adaptiveautonomous navigation using reactive multi-agent system for control law merging.Procedia Computer Science, 51:423–432, 2015.

[105] Baudouin Dafflon, Bofei Chen, Franck Gechter, and Pablo Gruer. A self-adaptiveagent-based path following control lateral regulation and obstacles avoidance. In HighPerformance Computing & Simulation (HPCS), 2014 International Conference on,pages 452–459. IEEE, 2014.

[106] Horst F Wedde and Sebastian Senge. Beejama: A distributed, self-adaptive vehiclerouting guidance approach. IEEE Transactions on Intelligent Transportation Systems,14(4):1882–1895, 2013.

[107] Shen Wang, Soufiene Djahel, and Jennifer McManis. A multi-agent based vehiclesre-routing system for unexpected traffic congestion avoidance. In 17th InternationalIEEE Conference on Intelligent Transportation Systems (ITSC), pages 2541–2548.IEEE, 2014.

[108] Didac Gil de La Iglesia and Danny Weyns. Sa-mas: self-adaptation to enhance softwarequalities in multi-agent systems. In Proceedings of the 2013 international conferenceon Autonomous agents and multi-agent systems, pages 1159–1160. InternationalFoundation for Autonomous Agents and Multiagent Systems, 2013.

[109] Samreen Laghari and Muaz A Niazi. Modeling the internet of things, self-organizingand other complex adaptive communication networks: A cognitive agent-based com-puting approach. PloS one, 11(1):e0146760, 2016.

[110] Teemu Leppänen, Meirong Liu, Erkki Harjula, Archana Ramalingam, Jani Ylioja,Pauli Narhi, Jukka Riekki, and Timo Ojala. Mobile agents for integration of internetof things and wireless sensor networks. In 2013 IEEE International Conference onSystems, Man, and Cybernetics, pages 14–21. IEEE, 2013.

[111] Kristof Van Moffaert, Tim Brys, Arjun Chandra, Lukas Esterle, Peter R Lewis, andAnn Nowé. A novel adaptive weight selection algorithm for multi-objective multi-agent reinforcement learning. In 2014 International Joint Conference on NeuralNetworks (IJCNN), pages 2306–2314. IEEE, 2014.

[112] Danni Yu, Qingshan Li, Lu Wang, and Yishuai Lin. An agent-based self-adaptivemechanism with reinforcement learning. In Computer Software and ApplicationsConference (COMPSAC), 2015 IEEE 39th Annual, volume 3, pages 582–585. IEEE,2015.

References 108

[113] Hongbing Wang, Qin Wu, Xin Chen, Qi Yu, Zibin Zheng, and Athman Bouguettaya.Adaptive and dynamic service composition via multi-agent reinforcement learning. InWeb Services (ICWS), 2014 IEEE International Conference on, pages 447–454. IEEE,2014.

[114] Hongbing Wang, Xiaojun Wang, Xingzhi Zhang, Qi Yu, and Xingguo Hu. Effectiveservice composition using multi-agent reinforcement learning. Knowledge-BasedSystems, 92:151–168, 2016.

[115] Hongbing Wang, Xiaojun Wang, Xingguo Hu, Xingzhi Zhang, and Mingzhu Gu. Amulti-agent reinforcement learning approach to dynamic service composition. Infor-mation Sciences, 363:96–119, 2016.

[116] Min Liu, Shijun Xu, and Siyi Sun. An agent-assisted qos-based routing algorithm forwireless sensor networks. Journal of Network and Computer Applications, 35(1):29–36, 2012.

[117] Sara Rodríguez, Juan F De Paz, Gabriel Villarrubia, Carolina Zato, Javier Bajo, andJuan M Corchado. Multi-agent information fusion system to manage data from a wsnin a residential home. Information Fusion, 23:43–57, 2015.

[118] Jean-Pierre Georgé, Marie-Pierre Gleizes, Pierre Glize, and Christine Régis. Real-timesimulation for flood forecast: an adaptive multi-agent system staff. In Proceedings ofthe AISB, volume 3, pages 109–114, 2003.

[119] T Srinivasan, Vivek Vijaykumar, and R Chandrasekar. A self-organized agent-basedarchitecture for power-aware intrusion detection in wireless ad-hoc networks. In 2006International Conference on Computing & Informatics, pages 1–6. IEEE, 2006.

[120] Zhiping Peng, Bo Xu, Antonio Marcel Gates, Delong Cui, and Weiwei Lin. A studyof a multi-agent organizational framework with virtual machine clusters as the unit ofgranularity in cloud computing. The Computer Journal, 2016.

[121] Vivek Nallur and Rami Bahsoon. A decentralized self-adaptation mechanism forservice-based applications in the cloud. IEEE Transactions on Software Engineering,39(5):591–612, 2013.

[122] Fu Hou and Xinjun Mao. Cross-clouds services autonomic management approachbased on self-organizing multi-agent technology. Concurrency and Computation:Practice and Experience, 2016.

[123] Fabrizio Messina, Giuseppe Pappalardo, Corrado Santoro, Domenico Rosaci, andGiuseppe ML Sarné. A multi-agent protocol for service level agreement negotiation incloud federations. International Journal of Grid and Utility Computing, 7(2):101–112,2016.

[124] Jérémy Boes, Frédéric Migeon, Pierre Glize, and Erwan Salvy. Model-free opti-mization of an engine control unit thanks to self-adaptive multi-agent systems. InInternational Conference on Embedded Real Time Software and Systems-ERTS2 2014,pages pp–350, 2014.

References 109

[125] Usman Wajid, M Brian Blake, and Iman Saleh. Track report of adaptive computing(and agents) for enhanced collaboration (acec 2014). In 2014 IEEE 23rd InternationalWETICE Conference, pages 1–2. IEEE, 2014.

[126] Nicolas Brax, Eric Andonoff, Marie-Pierre Gleizes, and Pierre Glize. Self-adaptiveaided decision-making-application to maritime surveillance. 2013.

[127] Tom Jorquera. An adaptive multi-agent system for self-organizing continuous opti-mization. PhD thesis, Université de Toulouse, Université Toulouse III-Paul Sabatier,2013.

[128] Benedikt Eberhardinger, Hella Seebach, Alexander Knapp, and Wolfgang Reif. To-wards testing self-organizing, adaptive systems. In IFIP International Conference onTesting Software and Systems, pages 180–185. Springer, 2014.

[129] V Botti, Carlos Carrascosa, Vicente Julián, and Jose Soler. Modelling agents in hardreal-time environments. In Multi-Agent System Engineering, pages 63–76. Springer,1999.

[130] Brendan Mahony and Jin Song Dong. Timed communicating object z. IEEE Transac-tions on Software Engineering, 26(2):150–177, 2000.

[131] Awais Qasim and Syed Asad Raza Kazmi. Mape-k interfaces for formal modelling ofreal-time self-adaptive multi-agent systems. IEEE Access, 4:4946–4958, 2016.

[132] "Demographia World Urban Areas. 1 April 2016.". ”http://www.demographia.com/db-worldua.pdf”. Retrieved 2 September 2016.

[133] S Innamaa. Self-adapting traffic flow status forecasts using clustering. IET IntelligentTransport Systems, 3(1):67–76, 2009.

[134] Xinting Pan, Yunlong Guo, and Aidong Men. Traffic surveillance system for vehicleflow detection. In Computer Modeling and Simulation, 2010. ICCMS’10. SecondInternational Conference on, volume 1, pages 314–318. IEEE, 2010.

[135] László Z Varga. A game theory model for self-adapting traffic flows with autonomousnavigation. In Autonomic Road Transport Support Systems, pages 13–28. Springer,2016.

[136] Byungkyu Brian Park and Myungsoon Chang. Realizing benefits of adaptive signalcontrol at an isolated intersection. Transportation Research Record: Journal of theTransportation Research Board, (1811):115–121, 2002.

[137] Thomas Leo McCluskey, Apostolos Kotsialos, Jörg P Müller, Franziska Klügl, OmerRana, and René Schumann. Autonomic Road Transport Support Systems. Springer,2016.

Appendix A

Run-time Adaptation of the SystemBased on Congestion Situation

A.1 Formal Specification of Monitoring Stations at MTMSignal to Handle Congestion at the MTM2 Station

MTM2ARTISAgent


SendMessage′




A.1 Formal Specification of Monitoring Stations at MTM Signal to Handle Congestion at theMTM2 Station 111

MTM1ARTISAgent


SendMessage′




MTM3ARTISAgent


SendMessage′




A.2 Formal Specification of Monitoring Stations at TNB Signal to Handle Congestion at theMTM2 Station 112

A.2 Formal Specification of Monitoring Stations at TNBSignal to Handle Congestion at the MTM2 Station

TNB2ARTISAgent


SendMessage′




TNB3ARTISAgent


SendMessage′



A.3 Formal Specification of Monitoring Stations at MTM Signal to Disseminate SignalDuration 113


A.3 Formal Specification of Monitoring Stations at MTMSignal to Disseminate Signal Duration

MTM2ARTISAgent


SendMessage′




MTM1ARTISAgent


A.4 Formal Specification of Monitoring Stations at TNB Signal to Disseminate SignalDuration 114

SendMessage′




MTM3ARTISAgent


SendMessage′




A.4 Formal Specification of Monitoring Stations at TNBSignal to Disseminate Signal Duration

A.4 Formal Specification of Monitoring Stations at TNB Signal to Disseminate SignalDuration 115

TNB2ARTISAgent


SendMessage′




TNB3ARTISAgent


SendMessage′




Formal Modelling of Real-Time Self-Adaptive Multi-Agent ...prr.hec.gov.pk/jspui/bitstream/123456789/9055/1... · Awais Qasim (2013-PhD-CS-18) March 2017. iv Research Completion CertiÞcate

Documents