Towards Modelling Real Time Constraints
Amir Ashamalla
1
, Ghassan Beydoun
1
, Graham Low
2
and Jun Yan
1
1
School of Information Systems and Technology, University of Wollongong, Wollongong, Australia
2
School of Information Systems, Technology and Management, University of New South Wales, Kensington, Australia
Keywords: i* Requirement Models, Multi Agent System, Call Management Centre (CMC), Relationship Manager
(RM), Real Time Multi Agent Systems (RTMAS).
Abstract: Software agents are highly autonomous, situated and interactive software components. They autonomously
sense their environment and respond accordingly. Agents behaviours are often constrained by by real time
constraints such as the time in which the agent is expected to respond .i.e. time needed for a task to
complete. Failing to meet such a constraint can result in a task being not achieved. This possibly causes an
agent or a system to fail, depending on how critical the task is to the agent or system as a whole. Our
research aims at identifying and modelling real time constraints in the early phase of analysis which helps in
creating a more reliable and robust system.
1 INTRODUCTION AND
RELATED WORK
Agents’ key characteristics are autonomy,
interactivity, situatedness and cooperativeness
(Beydoun et al 2009; Beydoun et al 2006). They are
typically designed to meet local objectives as part of
a distributed system. A real-time agent is such an
agent with temporal restrictions in some of its
allocated responsibilities or tasks (Botti et al 2004).
This paper is motivated by the longstanding view
that the earlier you model real time requirements in
the software development life cycle, the more
reliable and robust the resultant system should be
(Boehm 1988; Sadrei et al 2007). Any future issues
and conflicts are identified and resolved in the
earlier stage of analysis rather than in later stages of
design and implementation when it is too late or too
hard to resolve. We identify a number of key real
time constraints that can be modelled during the
requirement analysis of the system. The rest of the
paper is organised as follows: We first discuss other
academics work on real time multi agent systems.
We then sketch modelling real time constrains. This
is followed by the details of the identified real time
constraints set. We then introduce a call
management system as a validation domain to
demonstrate how the identified real time constraints
set are integrated into the software development life
cycle using i* modelling. We finally conclude this
paper with a description of future work and
anticipated challenges.
Surprisingly, for MAS systems that are supposed
to be decentralised and distributed, a common
modelling approach to for ensuring realtime
constraints are met is through the use of a central
monitoring agent (master agent) (Neto 2009) which
receives completion reports from the rest of the
agents. The monitoring agent typically initiates a
redundant task if an agent charged with a task does
not report completing it within the required
timeframe (a real-time constraint) (Neto, 2009).
This approach clearly presents a single point of
failure and is contrary to the distributedness of MAS
and its engendered appeal. The approach pursued in
this research seeks to maintain distributedness,
fulfilling real time requirements identified during the
requirement analysis phase of MAS development.
Modelling real time agent interactions has been
considered in a number of real-time MAS
applications. Notable examples include: The London
Underground project Basra (2007) used agent
modelling to model messaging and actions taken by
other trains to avoid collision, a search and rescue
example (Micacchi 2008) modelled how a robot can
identify and then plan to avoid obstacles to rescue
victims in real-time, target tracking (Sabour 2008),
construction (Zhang 2009) and automated car
driving (Konrad 2006).
158
Ashamalla A., Beydoun G., Low G. and Yan J..
Towards Modelling Real Time Constraints.
DOI: 10.5220/0004064801580164
In Proceedings of the 7th International Conference on Software Paradigm Trends (ICSOFT-2012), pages 158-164
ISBN: 978-989-8565-19-8
Copyright
c
2012 SCITEPRESS (Science and Technology Publications, Lda.)
A principal requirement for real time systems is
fulfilling time constraints (Vahid 2010). When
developing a model for real time MAS, the relative
priority of the task should be taken into account, as
well as the task deadline. In another model
(Zambonelli 2001), agents broadcast their set of
tasks to agents they rely on, and negotiate these set
of tasks before they start executing their tasks. Our
work is closer to Lu (2006) who suggests task
negotiation and cooperation should happen on
regular basis to update task status. The work is
similar to ours in that it promotes a distributed
approach to monitor real-time constraints
satisfaction. However, it is based on a numerical
representation of the conditions that are quite
difficult for software engineer to use during the
analysis phase. The work actually relies on task
sampling frequency which may under some
conditions impact the overall performance (dangbing
2004).
Object Management Group (OMG) and IBM
have developed a new improved profile, called the
UML Profile for Modelling and Analysis of Real-
time and Embedded Systems (MARTE) (OMG,
2008). MARTE models the analysis and design of
real time systems based the following four
fundamental pillars: QoS-aware Modelling,
Architecture Modelling, Platform-based Modelling,
and Model-based QoS Analysis. MARTE has been
integrated into IBM rational rhapsody version 7.5.
Another modelling and analysis suite is UML-
MAST (Modelling and Analysis Suite for Real-Time
Applications).UML-MAST distributes the load
based on the cpu, memory and network utilization,
and not on the task priority or deadlines. The suit
uses equations and experience to calculate and
predict the tasks load or cpu, memory and network
usage and then load balanced the tasks based on it.
e.g. task data size based on parameter data types
indicates network traffic as well as the number of
nodes (routers) that are exchanged between the
sender and receiver, this enabled predicting traffic
on the node, though data size and number of
messages/tasks (Vahid 2009). These modelling suits
do not have graphical representations for the real
time constraints, especially not for multi agent
systems which is the focus of our research.
2 MODELLING AGENT
REAL-TIME CONSTRAINTS
In this section, we introduce fundamental concepts
that underpin modelling of agent real time
constraints. This includes an elaboration on the
difference between real time constraints, error
handling and fault tolerant systems.
A task taking too long to complete may be regarded
as a failed task when a real-time constraint applies.
Receiving the right answer too late becomes the
wrong answer (Gokhale 2004). Run time error and
exception handling in the development phase;
typically require a different set of tasks to be
initiated when an error occurs (Westley 2004). If the
task is mission-critical and takes too long to
complete, it can lead to unwanted consequences e.g.
dialling a number then having to wait long for an
answer cannot be regarded as successful- although
the phone rang. The fact that the response time was
too long means the task failed, as it did not meet its
time constraint. This is different from fault tolerance
where the latter focuses on the behaviour of the task
following a failure. This may include starting an
alternate task to fulfil the application goals. Our
research regards tasks taking longer than an
expected/accepted time period as “failed” to meet
the design goals, regardless of their eventual
outcome.
Accurate identification of the violation of a real-
time constraint can be complicated. It often requires
taking into account task dependencies. For instance,
a task A may take too long simply because it is
waiting for its required input from another task B.
The problem may lie with Task B rather than Task
A. In the context of agents within a MAS, this kind
of dependency may be compounded and take the
form of a chain of dependencies of tasks and agent
goals (Neto 2009). In other words, all agent features
must be considered and modelled (Cabri 2003) with
their time related features. Our research aims at
providing a knowledge representation to facilitate
identifying a sufficient set of activities to be carried
out by requirement analysts to later be able to
identify which task has failed to meet its time
constraints. We aim to be able to identify the
available and the proper behaviour set for the agent
to be notified, and to model the required recovery
behaviour when a task fails. In other words, two
types of knowledge have to identified and modelled:
the knowledge to identify the success or failure of
the task to meet its real time constraints and the
knowledge describing behavioural actions associated
with a failed task. It is worth noting that modelling
the behaviour criteria alone can lead to modelling a
fault tolerant system (Kopetz 2000), as the research
focus would be on what actions are needed to
recover from a task failure.
Towards Modelling Real Time Constraints
159
Our research will enable better planning to avoid
future problems that might arise as a result of not
meeting real time constraints. There has been some
focus in recent years on message exchange,
negotiation and MAS fault tolerance while not much
has been done on modelling the real time MAS in
the analysis phase. Our goal is not to address fault
tolerance issues. We synthesize a reliable and
precise analysis process to ensure that we capture
the real-time constraints and the concomitant
required agent’s behaviour. As part of formulating
this process, we identify a set of constraints that
guide analysts in modelling the real time component
of a task in the analysis phase of the software
development life cycle. This will facilitate
identifying alternative actions to be taken once a
task has been identified as failing to meet its real
time constraints. This set of behaviour actions can
range from logging an error to starting an alternate
task. Identifying these constraints in the analysis
phase can assist in identifying bottlenecks and better
distributing work load between agents. Our approach
highlights a higher level of proposed behavioural
tasks/ goals to be taken in case the task fails to meet
its real time constraints, as identifying the problem is
the first step towards fixing or avoiding it.
3 IDENTIFIED REAL TIME
CONSTRAINTS
The set of real-time modelling units we pursue
should be sufficient to do the following: model tasks
time constraints, identify when they are not met and
model their behaviour at that time. If the task takes
too long (exceeding the real time constraint) then the
agent would identify that this task has failed and
initiate a suitable behaviour to ensure that this
failure does not propagate and cause one or more
system goals to fail. We therefore propose two
categories of modelling units: one group identifying
if the constraint has been met or not and another
group describing what actions/behaviour to be taken
when a constraint is not met. We propose 2 units in
the first category and 10 for the second category.
The modelling units will describe if the constraint is
soft/hard, its priority, its criticality, estimated
duration, warning percentage, error percentage, tier
number, periodic occurrences and real time order.
Moreover, if the task should be retired or which
alternative task should be tried. For a given RT
constraint, there is no limit on the number of
behavioural criteria imposed. E.g. when a task fails
the model should indicate all possible alternate tasks
and arrange them according to a priority sequence.
The developer can identify the task priority
sequencing during analysis. These identified twelve
units are not exhaustive. The developer can always
add any new constraints and their graphical
representation to the diagrams. The constraints set is
summarised below with Identifying or Behaviour
indicating the category it belongs to and then a brief
explanation of the constraint and the symbol to
represent it as follows:
1- Identify if an RT constraint exist at all, then the
next 11 constraints can be used and the RT
constraint presence is marked using a table symbol
. Other constraints can be marked on top of
this.
2- Identify if the constraint is a Soft or Hard
constraint is identified. A hard RT constraint
enforces that the task must complete within the
specified time frame and if not is unacceptable or
of no value. The value of a task with a soft RT
constraint declines steadily after the deadline
expires. Tasks completed after their respective soft
RT deadlines have less value than those whose
deadlines have not yet expired (Vahid 2010).
3- Identify Constraint Priority
Priority
. This is the
importance of the task to be completed, the lower
the number the higher the priority i.e. P1 is the
highest priority task which should be completed
first, if at all possible.
4- Identify constraint Criticality
Critical
. This is an
indication of how critical a task is i.e. the effect a
failure of this task would have on the whole
system. If a highly critical task fails to meet its real
time requirement, the criticality level is directly
related to the priority level but they do not have to
be equal. As tasks can have a high priority level,
it’s important to complete on time. But if it fails,
the system in total might not be affected. While in
other cases a task failure can cause the whole
system to fail.
5- Identify Estimated Duration
Estimated Duration
, to
be used as a guideline to identify if the task has
met its real time requirement or not.
6- Identify Warning Percentage
Warning%
,to be
proactive in identifying the tasks that are unlikely
to meet their real time constraint and help them
fulfil these constraints by providing them with
more resources, or starting the alternate task.
(Brazier 2000).
ICSOFT 2012 - 7th International Conference on Software Paradigm Trends
160
Figure 1: Representing the identified constraints in a table like diagram.
7- Identify Error percentage
Error%
is used to
identify when a task has failed to meet its real time
constraints. If the percentage is exceeded, the task
has failed to meet its real time requirements. In
most cases this would be 100% but this could vary.
E.g. if there is a lag or lap time between 2 tasks i.e.
the time between one task ending and another
dependent task starting (Brazier 2000).
8- Identify Tier Number , this identifies the
affected agent if the task fails to meet its real time
constraints (Konrad 2006).
9- Identifying periodic occurrences (PER)
Loop Limit PER
, i.e. the schedule on which the task happens on
(Konrad 2006).
10- Identify Real time order (RTO) is denoted by
+2 sec
. This represents the time lag between
instances of the same task or between one task and
another dependent task starting (Konrad 2006).
This helps in identifying the time buffer required
to repeat a sequence of tasks before the system is
affected.
11- Behaviour Retry attempts
is the number
of times to Retry/restart the task before starting the
Alternate task.
12- The Alternate task (if any) to start in case the
initial task could not meet its real time constraint is
denoted by
AT
. This emphasis the robustness
characteristic of the MAS and ensures the system
reliability.
4 CALL MANAGEMENT
Beyond a one-to-one communication tool, telephony
is a tool for marketing, gathering information,
purchasing, selling and recently advertising.
Generally, business telephony needs are either
outbound calls to customers (e.g. telemarketing
products) or inbound calls (e.g. for customer
support, handling sales or enquiries). Companies
favour outsourcing their call management to
dedicated Call Management Centres (CMC) since
they tend to have the latest telephone technology and
equipment together with additional value-adding
software. The CMC’s specialized personnel and
training saves the client company time and money.
A typical CMC may have a number of corporate
clients (e.g. banks, insurance companies) and a few
thousand relationship managers (RM) attending to
phone calls to end-customers of its corporate clients
(Ashamalla et al 2009). To validate the
representational adequacy of the above constraints,
we model a call centre support MAS. We propose
using an intelligent distributed system (known as
Multi Agent Systems) to assist in customer
relationship management by routing calls and
allocate calling duties to the most appropriate
relationship manager (in terms of knowledge/skills
and availability) to maximize effectiveness.
The goal of this system is to match the
relationship managers (RM) (call centre workers
receiving and making calls) with the end customers
(EC) (the person on the other end of the phone line).
ECs receive/make calls to the call centre to receive
the service or product the call centre is offering. The
proposed MAS will mix and match the skills and
available RMs to increase call centre sales, customer
satisfaction and profits (Ashamalla 2009). The
system routes the calls to the appropriate RMs based
on the EC and RM skills, background, demographics
and performance. We will only present one agent
(Outbound calling system) due to space
requirements, as per below:-
The outbound calling system represents the
agent responsible for dialling numbers, detecting call
answers and routing calls to the available and
appropriate RM, the outbound calling system tasks
are:-
1- Dial number: The Calling system dials EC’s
numbers from the available pre loaded calling list.
2- Detect call answer: Detecting that a real person
answered the call and not an answer machine or a
busy line.
3- Start voice recording: Once an answer is detected
the calling system needs to start voice recording.
4- Detect available RM: The calling system detects
available RM’s in order to route calls to them.
Towards Modelling Real Time Constraints
161
5- Route call to matched RM: Once an available
RM is detected, the call should be routed to
him/her.
6- Retrieve EC details: EC details are retrieved and
displayed for the RM.
7- Retrieve script: The sale script and offers are
retrieved and displayed on the screen, for the RM.
8- Detect Call outcome: RM logs the call outcome
as sale, No sale, do not call or Call back.
9- Stop voice recording: Once the call has ended,
voice recording for that call should be stopped.
10- Reroute call for call back: The system
redials/recalls call back calls on the set date/time.
11- Reroute unanswered calls: Unanswered calls
are logged as a “no answer” call, to be recalled
later.
The first phase of developing the CMC MAS is
articulating the requirements in order to undertake
an appropriate agent oriented analysis. We perform
RE activities informally with i*(Yu 1995),
beginning with stakeholder requirement analysis and
rationale for the new system. We use the i* (Yu
1995) modelling framework to represent MAS
agents and the relationships between different
agents. Our early requirement phase generates a high
level description of system goals and roles expressed
in the i* model. In a MAS, agents depend on each
other to achieve goals and perform tasks. The
resultant i* model consists of two components: The
Strategic Dependency (SD) model which models the
different agents and the relations between them and
the Strategic Rationale (SR) model which models
the different tasks each agent has and the different
proposed alternatives to accomplish these tasks
(Ashamalla 2009). The choice of i* as a modelling
language is based on previous experience (Bresciani
2004) which has shown that i* is a good language to
express MAS requirements. In particular, the i*
‘actor’ lends itself to readily model the actors and
agents in a call management centre, our proposed
system is composed of a number of Actors (Agents
and Roles) (Beydoun et al 2009). OME3 tool was
originally used to model the MAS call centre as part
of our case study, however when we needed to
represent the proposed real time modelling units we
preferred using Microsoft Visio. As Visio stencil’s
provided a more efficient way to visually present our
proposed real time modelling units. The values
represent each individual task’s real time criteria,
e.g. The alternate task (AT) for the above task is to
log an error, the affected agent (TN) is the Matcher
agent which has the following soft constraints: the
warning level is 80%, the tolerable error level is
100%, the Real time order (RTO) is +2 minutes
between this task and the successive task, the
periodic occurrences (PER) is on a daily rate, the
Retry (R) attempts is 3 times, the task estimated
duration (ED) is 2 minutes, the task critical level (C)
is 3 and its Priority level (R) is also 3.
The case study has found that the matcher and
outbound calling system were relatively loaded with
rt constraints (13 and 11 rt constraints respectively)
making their work load in need to be redistributed,
or broken down to multiple agents. While the rm
agent has a relatively small number of rt constraints
(4 rt constraints).with only one monitoring agent
exits for the system, distributing the tasks among
agents resulted in a more balanced model. This has
identified alternative agents and tasks in the sr
diagram, in case the task does not meet its real time
constraint. It also highlights the affected agent where
bottlenecks might occur and the effects on the
system in general .i.e. If all affected agent (tn) links
point to one agent. This indicates that the agent has a
high probability of failing in case any of the linked
tasks fail. The tasks could be the agents or another
agent’s task that have a direct effect on the agent.
this model has led to 2 monitoring agents as not to
have a single point of failure. We identified 77 agent
tasks for the call centre mas. examining these tasks
using the real time constraint set results in
identifying 66 of the 77 mas tasks as potentially real
time. we will only present the outbound calling
agent agent’s tasks due to space requirements.
5 CONCLUSIONS AND FUTURE
WORK
This paper is part of our ongoing research aimed at
identifying and modelling real time constraints in the
early analysis stage of the development life cycle. It
also helps in identifying future bottle necks that
could arise as a result of overloading an agent with
too many real time constraints in the early analysis
phase. I.e. having all arrows point to a single agent
indicates that this agent is a potential bottle neck
and/or it is highly likely to fail. Our research aims to
enhance the performance of agent systems to meet
any real time constraints requirement. 12 modelling
units to represent real time constraints have been
identified based on academics and researches
recommendations (Brazier 2000, Konrad 2006,
Vahid 2010, Tran et al 2006) and others discussed in
Section 2 and 3. We also developed a case study and
some industry recommendations and we are
currently validating these constraints using expert’s
ICSOFT 2012 - 7th International Conference on Software Paradigm Trends
162
reviews and recommendations. The preliminary
results are so far encouraging. This result is very
dynamic in representing Real time constraints,
allowing any newly identified constraints to be
added to the model with the appropriate graphical
representation. Our next step in this research is to
propagate our real time constrains to agent goal
models. Further case studies and modelling tools to
further validate our results and research outcomes
will be needed. Expert reviews in the call centre and
MAS domains will be first contacted to review the
outcome, before extending to another domain of
collaborative e-Learning (Beydoun 2009).
REFERENCES
Ashamalla, A., Beydoun, G. and Low, G. (2009). 'Agent
Oriented Approach to a Call Management System',
18th International Conference on Information Systems
Development (ISD 2009), Nanchang, China,
September 16-19
Beydoun, G., Low, G., Mouratidis H. and Henderson-
Sellers B. (2009). 'A security-aware metamodel for
multi-agent systems (MAS)', Information and
Software Technology, 51(5): 832-845
Beydoun, G., Gonzalez-Perez, C., et al. (2006).
Developing and Evaluating a Generic Metamodel for
MAS Work Products. Software Engineering for
Multi-Agent Systems IV: Research Issues and
Practical Applications. A. Garcia, R. Choren, C.
Lucenaet al. Berlin, Springer-Verlag. LNCS 3914:
126-142.
Beydoun, G. (2009). "Formal concept analysis for an e-
learning semantic web". Expert Systems with
Applications 36(8).
Basra, R., Lu, K. and Skobelev, P. (2007). "Resolving
scheduling issues of the London Underground using a
multi-agent system." International Journal of
Intelligent Systems Technologies and Applications
2(1): 3-19.
Boehm, W. (1988). "A spiral model of software
development and enhancement." Computer 21(5).
Botti, V. and Julian, V. (2004). "Developing real-time
multi-agent systems." Integrated Computer-Aided
Engineering 11(2): 135-149.
Brazier, F., Cornelissen, F., Jonker, C., and Treur, J.
(2000). "Compositional Specification and Reuse of a
Generic Cooperative Agent Model." International
Journal of Cooperative Information Systems 9(3): 171.
Brazier, F., Mobach, D., Overeinder, B. and Wijngaards,
N. (2002). "Supporting Life Cycle Coordination in
Open Agent Systems." IIDS Group, Department of
Artificial Intelligence, Faculty of Sciences, Vrije
Universiteit Amsterdam.
Bresciani, P., Perini A., Giorgini P., Giunchiglia F. and
Mylopoulos J. (2004). Tropos: An agent-oriented
software development methodology. Autonomous
Agents and Multi-Agent Systems 8(3): 203-236.
Cabri, G., Leonardi, L. and Zambonelli, F. (2003).
BRAIN: A Framework for Flexible Role-Based
Interactions in Multiagent Systems. On The Move to
Meaningful Internet Systems 2003: CoopIS, DOA,
and ODBASE, Springer Berlin / Heidelberg. 2888:
145-161.
Conitzer V.(2007). AWESOME: A general multiagent
learning algorithm that converges in self-play and
learns a best response against stationary opponents.
Machine Learning 67 (1-2/may 2007): 23 - 43
Danbing S., John L., Lui S. and Kang S. (2004). "Trade-
Off Analysis of Real-Time Control Performance and
Schedulability." Real-Time Systems 21(3): 199-217.
Gokhale, S., Natarajan, B., Schmidt, C. and Cross, K.
(2004). "Towards real-time fault-tolerant CORBA
middleware." Cluster Computing 7(4): 331-346.
Horkoff, J. (2007 Thursday 24 of May, 2007 23:13:15).
"Visio." Retrieved 26/04/2011, 2011, from http://
tanne.informatik.rwth-aachen.de:7777/.
Konrad, J. (2006). Model-driven development and
analysis of high assurance systems. Department of
Computer Science. Michigan, Michigan State
University. Doctor of Philosophy: 443.
Kopetz, H. (2000). Software engineering for real-time: A
roadmap. Proc. 22nd Int. Conf. Software Eng,
Citeseer.
Lu, Roman G. and Shourong (2006). "Modeling
distributed real-time applications with specification
PEARL " Real-Time Systems 35(3): 181-208.
Micacchi, C. and Cohen, R. (2008). "A framework for
simulating real-time multi-agent systems." Knowledge
and Information Systems 17(2): 135-166.
Neto, A., Sartori, F., Piccolo, F., Vitelli, R., De Tommasi,
G., Zabeo, L., Barbalace, A., Fernandes, H., Valcárcel,
F. and Batista, N. (2009). MARTe: a Multi-Platform
Real-Time Framework. Proc. of the 16th IEEE NPSS
Real-Time Conference, Beijing, China.
Object Management Group (OMG). (2008). "UML profile
for modeling and analysis of real-time and embedded
systems (MARTE)" Retrieved 2-12-2010, from
http://www.omg.org/.
Sabour A., Faheem M. and Khalifa E. (2008). "Multi-
Agent Based Framework for Target Tracking Using a
Real Time Vision System." International Conference
on Computer Engineering and Systems, ICCES 2008
355-363
Sadrei, E., Aurum, A., Beydoun, G., and Paech, B. “A
Field Study of the Requirements Engineering Practice
in Australian Software Industry”, International Journal
Requirements Engineering Journal 12 (2007), pp.
145162.
Tran, QNN, Low, GC and Beydoun, G., “A Method-
ological Framework for Ontology Centric Agent
Oriented Software Engineering”, International Journal
of Computer Systems Science and Engineering, 21,
117-132, 2006.
Vahid, G. (2010). "Experience and challenges with UML-
driven performance engineering of a Distributed Real-
Towards Modelling Real Time Constraints
163
Time System." Information and Software Technology
52(6): 625-640.
Vahid, G., Y. Labiche, et al. (2009). "A UML-based
quantitative framework for early prediction of resource
usage and load in distributed real-time systems."
Software and systems modeling 8(2): 275-302.
Westley, W. and George, N. (2004). "Finding and
preventing run-time error handling mistakes."
SIGPLAN Not. 39(10): 419-431.
Yu, E. (1995). Modelling strategic relationships for
process reengineering. Computer Science. Toronto,
Canada, University of Toronto. Doctor of Philosophy:
131.
Zambonelli F., Jennings N. and Wooldridge, M.
(2001)."Organisational Abstractions for the Analysis
and Design of Multi-agent Systems " International
Journal of Software Engineering & Knowledge
Engineering 11(3): 1.
Zhang, C., Hammad, A. and Bahnassi, H. (2009).
"Collaborative Multi-Agent Systems for Construction
Equipment Based on Real Time Field Data
Capturing.” Electronic Journal of Information
Technology in Construction 14.
ICSOFT 2012 - 7th International Conference on Software Paradigm Trends
164