A Multi-Agent Approach to Vehicle Monitoring in Motorway - CiteSeerX

A Multi-Agent Approach to Vehicle Monitoring in Motorway Enrico Appiani1, Maurizio Martelli2 , and Viviana Mascardi2 1 Elsag s.p.a., Via Puccini 2, 16154 Genova, Italy [email protected] 2 DISI – Universit`a di Genova Via Dodecaneso 35, 16146, Genova, Italy Fax +39 010 3536699 fmartelli, [email protected]

Abstract. This paper describes CaseLP, a prototyping environment for MultiAgent Systems (MAS), and its adoption for the development of a distributed industrial application. CaseLP employs architecture definition, communication, logic and procedural languages to model a MAS from the top-level architecture down to procedural behavior of each agent’s instance. The executable specification which is obtained can be employed as a rapid prototype which helps in taking quick decisions on the best possible implementation solutions. Such capabilities have been applied to a distributed application of Elsag company, in order to assess the best policies for data communication and database allocation before the concrete implementation. The application consists in remote traffic control and surveillance over service areas on an Italian motorway, employing automatic detection and car plate reading at monitored gates. CaseLP allowed to predict data communication performance statistics under different policies of database allocation.

1 Introduction For Police and Financial Police, the control of wide sections of motorway represents a powerful means to individuate vehicles of suspects, trace their movements and take the proper actions consequently. Such control takes place by a distributed network of car detection and licence plate reading systems, placed at motorway service areas, sending their transit information to control centers and detecting possible matches with suspect number-plates. Besides law enforcement, this kind of car monitoring can be useful for vehicle transit control, such as in motorway gates, parking areas and urban zones with restricted access. The scenario for vehicle monitoring is extremely complex since it involves a large number of heterogeneous entities. They can be human entities (the policeman who inserts a new number-plate to be monitored or who receives an alarm concerning a suspect vehicle), physical entities (remote cameras for getting number-plates images, communication infrastructure) and software ones (the client interface, the application server and the remote sensor control with image processing for licence plate reading). Due to the heterogeneity and complexity of this scenario the assessment of the real framework

2

E. Appiani, M. Martelli, V. Mascardi

for vehicle monitoring requires a careful design and the full understanding of all the involved parameters, as well as their relations and mutual influence. The distinguishing features of the entities involved in the application, namely their heterogeneity, their physical distribution, the ability to autonomously accomplish their specific tasks but also to interact with other entities to achieve a common goal, highlight the suitability of a Multi-Agent System (MAS) approach for modeling the scenario. An agent is commonly described as an entity situated in some environment, perceiving it and capable of flexible autonomous actions in order to meet its design objectives. Flexibility is specified as responsiveness (ability to react in timely fashion to changes happening in the environment), pro-activeness (ability to pursue a long-term goal) and sociality (ability to interact with other agents or human beings belonging to the system) [4]. This definition matches quite well the features characterizing the entities in the vehicle monitoring application. Once understood that the MAS metaphor can be properly adopted for modeling this scenario, it is also necessary to identify the best method to follow in order to develop the real monitoring environment, starting from the initial specifications and requirements. The development of a working prototype is a good choice since it allows to easily test and modify some design choices and to get immediate feedbacks on their impact on the global scenario. According to these considerations, the Computer Science Department of Genova University (DISI) and Elsag s.p.a., an international company working in several service automation fields, have developed a working prototype of the vehicle monitoring application modeled as a MAS. This prototype has been used to improve the application specifications, to properly dimension the communication channels, and finally to provide a formal specification to be followed during the implementation stage. The implementation has been completed successfully and the vehicle monitoring apparatus has been installed in the motorway section between Salerno and Reggio-Calabria (Italy); it is currently used by the Italian Police, Financial Police and by the “Autostrade” (motorway) organization for traffic monitoring. The aim of this paper is to describe how CaseLP, a prototyping environment for MAS developed by the Logic Programming Group of DISI, has been used to model and prototype the vehicle monitoring application. The organization of the paper is the following: Section 2 describes CaseLP, Section 3 describes the vehicle monitoring application and Section 4 shows how a prototype of the application has been modeled and realized in CaseLP. Section 5 compares our approach with simulation and CASE, presents future improvements and concludes the paper with other possible industrial applications which may benefit from it.

2 CaseLP: a Prototyping Environment for Multi-Agent Systems The development of an application following the MAS metaphor is a very delicate enterprise: the MAS approach is usually adopted when the application needs to be modeled in terms of more complex entities than processes or objects, which interact following some communication protocol and which act with a certain degree of autonomy. Following a clear development methodology greatly helps the application developer in his/her job.

A MAS Approach to Vehicle Monitoring in Motorway

3

At the Computer Science Department of Genova University two of the authors have developed CaseLP, a prototyping environment for MAS which also provides a development method and a set of tools and languages to support the development stages. The acronym CaseLP stands for Complex Application Specification Environment based on Logic Programming: CaseLP was originally conceived as a logic-based environment where the specification of the agents could be provided in two different logical languages and executed/animated. As the research on CaseLP went on, other non-logical specification languages have been added to CaseLP in order to make it closer to the habits of users from the industry, who are not usually very accustomed with LP. Now CaseLP integrates various specification languages and provides the means to semi-automatically translate them into executable programs (one for each agent) written in an extended Prolog with communication capabilities and a safe management of state updates. The execution of the agents is controlled by an engine which maintains a trace of the events the user wants to monitor and provides on-line and off-line statistics on the simulation execution. The CaseLP framework is graphically depicted in Fig. 1: the integration of external components is also shown. The high level specification of agents can be written in any of the specification languages described in Section 2.2. In a very near future also UML will be available as a specification language integrated within CaseLP: we are currently working at describing agents using a suitable subset of UML and translating the UML agents into executable Prolog agents. For this purpose a textual representation of UML is used.

o

o o o

High level specification of agents

CaseLP engine

Executable specification of agents

Communication links

Legacy software

Legacy software integration Compilation process from high level to executable spec.

Fig. 1. CaseLP framework.

The prototype development, which deals with the specification, implementation and execution of agents, is carried out following a well defined and experimented

4


methodology. Section 2.1 describes the methodology, while section 2.2 describes the tools CaseLP provides to support any step of the methodology. The CaseLP approach to MAS development is to clearly separate the task of defining the agent architecture, namely the agent’s internal components and the control flow among them, from the task of defining the application-dependent knowledge of agents. For example, agents may have a reactive architecture, characterized by an event-queue and a set of event-condition-action rules, or they may be conceptualized in terms of humanlike belief-desire-intentions, and so on. The data structures and control flow necessary to make these architectures work are very different. The agent architectures are domain-independent and, once defined, can be reused for multiple applications. Since all the agents involved in the vehicle monitoring application share a reactive architecture, where reaction is triggered by the reception of a message, we just marginally face all the issues related with the definition of different architectures and the consequent choice of “the right agent architecture to do the right thing”. For sake of clarity, the method we propose in this paper is a simplification of the complete CaseLP method described in [8] and it is limited to the steps we followed for the development of the vehicle monitoring application. As far as the tools and languages are concerned, we just give a brief overview of all of them and, in Section 4, we exemplify the adoption of some of them for the vehicle monitoring application. 2.1 Prototyping method The CaseLP method is summarized in the following steps: 1. Static description of the application architecture. In this step the application developer defines: – the classes of agents that the application needs. A class is characterized by the kind of the agents belonging to it, e.g. if they are yellow page facilitators, or if they are interfaces towards external software, and so on; the architecture of agents; the services required and provided by the agents in that class; – the instances of each class that will form the MAS; – the interconnections between agents, that is, how a service provided by an agent is linked to a service required by another agent. 2. Description of communication between agents. Each provided or requested service needs a specific conversation between the agents providing and requiring the service. This step allows to specify the sequence of exchanged messages, as well as their content. 3. Description of the procedural knowledge of each agent class. Agent instances belonging to the same agent class, described in the first step of the method, share the same procedural knowledge depending on the agent’s class and on the communication protocol the agent adheres to, as described in the second step of the method. The way the agent’s procedural knowledge and state are formalized depends on the agent’s architecture.


5

4. Verification and testing of the agent’s specifications. If the language adopted for the specification of the agents is executable or animable, it is possible to verify some properties of the MAS behavior before implementing the prototype. 5. Prototype implementation. The specification of the agents given in the previous steps are (semi)-automatically translated into an executable piece of code. In order to implement the agents, all the details concerning their architecture must be completely specified. However, the burden of this task will not fall on the application developer. The CaseLP approach is to provide the application developer with a pre-defined library of architectures from which he/she can choose the most appropriate ones. The architectures in the library have been specified, verified and tested before being employed. 6. Execution and testing. In the final step of the method the prototype is tested in different conditions, in order to evaluate its behavior in as many situations as possible. This kind of testing does not ensure that the prototype is correct, since it is usually not possible to exhaustively test it in all the possible initial conditions which can take place. Nevertheless, a good choice of test cases gives a reasonably high confidence in the prototype correctness and allows the prototype developer to get important feedbacks on the system behavior. If flaws are detected, a revision of the previous steps of the method is possible. This refinement cycle through the method steps can go on until a “correct” prototype is obtained. 2.2 Prototyping tools and languages MAS-adl: a simple architectural description language. In the first step of the method MAS-adl, a simple, customized, architectural description language [5] for MAS, is adopted. MAS-adl describes three main constructs: AgentClassDef defines the classes of agents used in the MAS under construction; AgentInstancesDef defines the instances of classes previously defined i.e., the agents that constitute the MAS; LinksDef defines the directed links between instances of agents, from a service provided by an agent to a service required by another agent. The use of MAS-adl for the vehicle monitoring application is described in Section 4, while its full syntax is described in [7]. Tools for conversation model. The second step of the method describes the conversation model of the MAS. The agent communication language is a subset of KQML [9]. The conversation model is defined by choosing, for each service, the sequence of messages (conversation), as well as their performative and the content of each message. A relation s defines which conversations eventually start during other conversations. Let 1 = fm1 ; : : : ; mk g be a conversation composed by messages m1 ; : : : ; mk and let 2 be another conversation. 1 s mi 2 denotes that 2 must start after message mi in 1 has been handled by the receiving agent. 1 s ?mi 2 denotes that 2 eventually starts after message mi has been handled by the receiving agent. In the latter case, the decision about starting 2 is up to the receiving agent. ACLPL. In the third step of the given method the agents’ procedural knowledge is defined. CaseLP provides three languages for describing this knowledge; the simplest one, suitable for specifying the simplest kind of agents, namely the reactive and proactive ones, is ACLPLwhich allows to define both reactive and proactive rules. A reactive

6


rule has the form on message Msg check Condition do ActionsList This rule is fired by a message taken from the agent’s mail-box, and if the condition is satisfied, corresponding actions are executed. Condition expresses what must be true in the current agent’s state in order to execute a sequence of actions. If it is satisfied the actions are executed; they usually deal with state update or communication. A proactive rule is similar to a reactive one, but it only depends on the state condition. The agents in the vehicle monitoring application have been specified with this language, as described in Section 4. The syntax of ACLPL can be found in [8]. HEMASL and Ehhf . There are many applications where the agents involved need to be conceptualized in terms of mentalistic or emotional attitudes, thus requiring a more complex architecture than the reactive or proactive ones. In such situations where ACLPL is inadequate, the description of the agents can be formalized using either HEMASL or Ehhf . Thus being extremely different, the two languages share a common feature: they can be used to specify both the architecture of agents, and their procedural knowledge and initial state. As we have already highlighted, the specification of the internal structures and control flow of CaseLP agents is kept separate from the specification of their domain-dependent knowledge. HEMASL have been purposely designed for describing agents at both the architecture and domain-dependent knowledge levels, while Ehhf , which was not conceived as a language for specifying agents, has proven to be very suitable also for this purpose. [6] provides a complete description of HEMASL design, while [2] and [1] describe the adoption of Ehhf as an architecture specification language and as a procedural knowledge specification language respectively. HEMASL. HEMASL allows to specify MAS in which agents are characterized by – a state which contains the data that may change during the execution of the agent; – a program, namely that part of procedural information that does not change during the execution of the agent; and – an engine which controls the execution flow of the agent by providing a metainterpreter for the program and for the data (state) on which the program operates. In order to describe the agent at both the architectural and domain-dependent levels, HEMASL supports a hierarchy of four concepts going from the description of the agent’s abstract and concrete architecture, to its complete definition in terms of domaindependent knowledge (agent’s class) and initial state. This approach combines features borrowed from the object-oriented paradigm (abstract architectures do not need to be fully implemented, like abstract classes; more agent classes can share the same concrete architecture which is extended by the class domain knowledge; agent instances play the same role as objects in OO languages) together with a simple procedural language for describing the engine of the agents. The agent program is expressed is some architecture-dependent language for which the engine is a meta-interpreter. We have already developed engines for existing agent architectures, and we are currently working on extending this library. We think that HEMASL features make it suitable for adoption by industrial users who are more accustomed with the imperative and object-oriented paradigms than with the logic one.


7

Ehhf . The linear logic language Ehhf [3] is an executable language for modeling concurrent and resource sensitive systems based on the general purpose specification logical language Forum [10]. Ehhf has a multiset-based logic combining features of extensions of logic programming languages like Prolog, e.g. goals with implication and universal quantification, with the notion of formulas as resources at the basis of linear logic. A Ehhf -program is a collection of guarded multi-conclusion clauses. Clauses of this kind consume the resources (formulas) they need in order to be applied in a resolution step. For this reason they can profitably model the dynamics of agent execution, where the old state is “consumed” when the agent moves in a new state. Moreover, thanks to its support of concurrency, Ehhf easily models the autonomous concurrent entities which form the MAS. The adoption of Ehhf is particularly suitable to safety critical applications, where model checking is needed to ensure the specification correctness w.r.t. some critical property. The relevant features of the application can be modelled in Ehhf which, thanks to its interpreter, can be used to prove properties of the specification. PROLog for AGents. The target language for implementation is ProlAG (PROLog for AGents), an extended platform-independent Prolog language. ProlAG is defined as standard Prolog extended with communication capabilities and with safe state updates. The predicates for state update are safe in the sense that they can be backtracked. The predicates for communication allow agents to send messages asynchronously, and to perform both blocking and non-blocking message reception. Semi-automatic compilers from ACLPL and Ehhf into ProlAG have been developed, as described in [8]. CaseLP Simulator and Visualizer. The obtained ProlAG prototype is tested using the CaseLP Simulator. The simulator provides the means to set the simulation parameters, such as the time grain and the simulation length, as well as some parameters of the communication network. In particular, it is possible to set the latency and reliability of the communication channels between any couples of communicating agents. It is also possible to associate a weight to any message which can represent any measure significant for the application. As an example, it can represent the number of bytes necessary to code the message itself, or a rate of the message importance, and so on. The simulation provides the complete trace of the events (communication or state change events) that the developer decided to monitor. It also provides statistical information on message exchange: the maximum and average number of messages of a certain type per time unit or time interval, the maximum and average weight of messages per time unit or time interval and their standard deviation. A graphic version of the simulation execution and statistics is provided by the CaseLP Visualizer.

3 The Case-Study: Vehicles Monitoring in Motorway Elsag has been designing and integrating remote surveillance systems, including automatic detection and reading of licence plates, since 1990. They have been applied in different scenarios, such as: motorway gates and service areas; parking areas; urban sectors with traffic limitations; entrance/exits of harbours and commercial areas.

8


Each application has its own user interface, distributed configuration and database schema; however, they are all based on the “intelligent sensor” called LPR (Licence Plate Recognizer), a software component hosted in standard PCs equipped with frame grabbers linked to cameras. The relevant process, called “ O2 CR” (Out-door OCR), is applied to each camera’s video flow, with no need for specific vehicle passing sensors. In fact, motion detection limits the number of relevant video frames; on each frame, image segmentation localizes the regions of interest; on each region, character segmentation detects the licence plate characters, if present; the specialized OCR recognizes them; finally, context processing provides feedback to region segmentation and camera set-up (such as adaptation to changing illumination). The specific application, which has been modeled by a MAS, implements the monitoring of vehicles entering and exiting the service areas of a motorway section, between Salerno and Reggio Calabria in Italy, whose specific characteristics are heavy traffic in most days (being a main connection in south Italy) and toll-free transit, sometimes allowing vehicles to enter and exit the motorway at the service areas themselves. These peculiarities fostered, more than for other motorway sections, the need for traffic monitoring with automatic alarm detection, this consisting in detection of signalled vehicles, such as stolen or improperly used ones. In the rest of description, transit defines a recognized car plate number with related time/place stamp and reference image (back side of the detected vehicle), black list is a list of signalled licence plate numbers and alarm is a transit whose licence plate matches an item in a black list. The configuration is distributed on a protected TCP/IP WAN, using both cables and satellite links with limited bandwidth, and includes the following physical and software entities: – Executive Center (EC): client site of motorway management or Police, with one or more client stations, allows to browse transits, get alarms, visualize vehicle images, modify the black lists, and require database operations according to users’ privileges; – Application Server: usually centralized on a server machine or server LAN, coordinates any communication with the Executive Centers and the Surveillance Areas (see below), dispatches alarms according to ECs’ requests (black lists can be different, so each EC must get just the alarms of interest) and manages the central transit/alarm database; – Surveillance Area (SA): hosts the peripheral intelligent sensors on one or more PCs in a LAN, located at a service station, gets video frames from the local cameras, generates transits and alarms by storing a local black list, sends transits and alarms to the Application Server. The communication topology is therefore star-like around the Application Server, with more ECs and SAs linked to it, as represented in Fig. 2. Direct links between EC and sensors in SAs are just used for direct video monitoring, but this function usually employs different cameras and does not take part in the intelligent alarm system. Communication takes place by TCP/IP messages with dedicated session protocol. Current evolution is towards higher level, standard middleware such as CORBA between Server and SA, CORBA or HTTP (Web-based clients) between EC and Server. The main messages between an EC and the Application Server are:


9

Fig. 2. Motorway Monitoring Application Architecture

– requests to inquiry/browse/modify the transit database, with related answers; – requests to inquiry/browse/modify the black lists (signalled) database, with related answers. The black lists can be specific of each EC, and each signalled licence plate number can be limited to a subset of SAs; – incoming alarms requesting attention by operators; while the main messages between the Application Server and the SAs are: – requests to update each SA’s local black lists. In fact, this allows for fast alarm detection directly by SAs, while the Server takes care of dispatching alarms to the right ECs; – incoming transit lists; – incoming alarms. Data allocation (for instance, whether to centralize the database of transits or keep it distributed on SAs) and communication strategies had to be modeled in advance, in order to take the best solutions before achieving physical implementation on the real WAN. Besides, modeling each entity’s behavior was needed to pre-test the entire message exchange system against coherence, deadlock absence and performance. To this objectives, application prototyping by means of CaseLP proved to be very effective, as described in the next section. A careful work was made to make the specification as modular and extensible as possible, keeping into account the possibility to have more application servers managing and exchanging information coming from different motorway tracks.

10


4 Realization of the Prototype in CaseLP In this section we exemplify how some of the tools described in Section 2.2 have been used in the various steps of the method. As already said, not all the languages provided by the CaseLP environment have been used for this application. The aim of CaseLP is to let the developer choose the most suitable and useful languages according to the application features. Static description of the application architecture. As introduced in Section 3, three classes of agents have been identified for this application: the executive center (EC), the surveillance area (SA) and the common server (EC SA SERVER), called Application Server in the previous section. One of the reasons for developing a working prototype was to understand whether it was better to maintain a distributed database of monitored transits (different databases should be maintained by the surveillance areas, each one containing information on the transits occurred in that specific area) or a centralized one (maintained by the EC SA SERVER, and containing all the transits occurred in all the surveillance areas). The static descriptions in the centralized and distributed settings are almost the same, there are only small differences concerning the monitored transits of numberplates. In case of a centralized solution, the surveillance areas asynchronously send an update of transits to the EC SA SERVER. The frequency of this update is parametric, and different experiments have been done in order to choose the best one. In this case, when an EC needs informations on transits, it just interacts with the EC SA SERVER which provides the answer. If the databases are distributed, the surveillance areas do not send any information on transits to the EC SA SERVER; when an EC asks the EC SA SERVER for obtaining information on transits, this query is forwarded to the SAs involved in the query, and the answers are combined into a unique answer sent to the EC. In the rest of the section, we deal with the MAS specification for the centralized solution of the transit database. The specification in the distributed case is quite similar. agentclass EC_SA_SERVER { kind: logical; architecture: reactive; requires: update_plate_trans; update_wanted_plate; alarm_wanted_plate; provides: alarm_wanted_plate; wanted_plate; update_wanted_plate; plate_trans;} agentclass EC { kind: logical; architecture: reactive; requires: plate_trans; wanted_plate; alarm_wanted_plate; provides: update_wanted_plate;} agentclass SA { kind: logical; architecture: reactive;


11

requires: update_wanted_plate; provides: update_plate_trans; alarm_wanted_plate;} agentInstances { 1 ec_sa_server EC_SA_SERVER; 20 ec EC; 23 sa SA;} link { ec*.plate_trans