2. LITERATURE REVIEW
2.4 Multi-Agent System (MAS)
2.4.2 Agent Model
According to the above definition, the first fundamental property of an agent is its ability to act autonomously. That is, an agent is situated in an environment, in which it can sense and act as Figure 2.3 shows, and has complete control over its own actions in that environment (Bussmann et al. 2004)
Figure 2.3 Basic Model of an Agent (Bussmann et al. 2004)
2.4.3 Agent Interaction
As defined above, the second fundamental property of an agent is its ability to interact with other agents. The environment an agent is situated in is usually not purely passive. There are other agents which also act autonomously and pro-actively. To meet its goals, an agent may have to avoid negative or be able to exploit positive interactions with other agents. In particular, certain goals may not be achievable with the limited capabilities
of a single agent, but only if a whole set of agents works cooperatively towards these goals (Bussmann et al. 2004).
In general, interaction is any kind of information exchange that influences the actions of another agent (Bond and Gasser 1988). Interactions can thus take many different forms.
This subsection will only briefly review the main types of interaction techniques, namely
coordination and negotiation, that are most commonly used in agent based production
control (Bussmann et al. 2004).Coordination
Coordination is the process by which agents ensure that their community acts in a well-defined manner (Jennings 1996; Bond and Gasser 1998). The agents are dependent on each other for performing certain actions in order to arrive at the desired over all system behavior. Malone and Crowston (1994) therefore define coordination to be simply managing dependencies between activities. To achieve agent coordination, it is therefore necessary first to understand the possible dependencies that may exist and then to derive interaction techniques that are able to handle these dependencies.
Several researchers have modeled and classified dependencies between agents.
Castelfranchi et al. (1992) as well as Sichman et al. (1994) have modeled the goals and the plans of agents and have investigated how these can be dependent on other agents’ goals and plans to analyze how cooperation can evolve from three dependencies (Jennings 1996;
Inverno and Luck 2001; Sichman and Conte 2002; Yu 2002). In particular, the dependencies are distinguished as follows:
z Unilateral dependence: One agent is dependent on another, but not vice versa.
z Mutual dependence: Two agents are dependent on each other for the same goal
or plan.
z Reciprocal dependence: Two agents are dependent on each other, but for different goal and plan.
Negotiation
As for coordination, negotiation is a common form of interaction between human beings and has therefore been extensively studied in sociology (Pruitt 1981). In sociology, any interaction is regarded as a negotiation in which the participants of the interaction, usually called parties, have a conflict of interests, but must come to joint decision. Pruitt (1981), for instance, defines negotiation as follows:
Negotiation is a process by which a joint decision is made by two or more parties.
The parties first verbalize contradictory demand and then move towards agreement by a process of concession or search for new alternatives (Pruitt 1981).
The contract-net protocol (CNP) is a simple, but efficient, protocol for assigning tasks to individual nodes in a network (Smith 1980). It assumes that one node has a task that needs to be executed by another node and that there are potentially several nodes that are able to execute this task. The node with task is called the “Initiator” and the other nodes are “Participants” as shown in Figure 2.4. The Initiator initiates the protocol and proceeds as follows. First, it announces the “cfp” (call for proposal) to the Participants. The Participants answer with a bid. The necessary information provided in the bid was specified by the Initiator in the announcement message. The Initiator compares the bids and chooses the best bid according to its preferences. The node which has sent the best bid than receives an award message and is said to have a contract with the Initiator about the execution of the task. The other nodes may or may not receive a reject message.
Figure 2.4 Sequence Diagram of Contract-Net Protocol (Pruitt 1981)
2.4.4 Agent Application Domains
There are several orthogonal dimensions along which agent applications could be classified. They can be classified by the type of the agent, by the technology used to implement the agent, or by the application domain itself. This study chooses the domain type, since this view fits best with the objectives of this study.
Industrial Applications
Industrial applications of agent technology were among the first to be developed: as early as 1987, Parunak (1996) reports experience with applying the contract net task allocation protocol in manufacturing environment. Today, agents are being applied in a wide range of industrial applications (Jennings and Wooldridge, 1998).
z Process Control
Process control is a natural applications for intelligent agents and multi-agent systems, since process controllers are themselves autonomous reactive systems. It is not surprising, therefore, that a number of agent-based process control applications should have been developed. The best known of these is ARCHON, a software platform for building multi-agent systems, and an associated methodology for building applications with the platform (Jennings 1995). ARCHON has been applied in several process control applications, including electricity transportation management (the application is in use in northern Spain), and particle accelerator control. ARCHON also has the distinction of being one of the earliest field-tested multi-agent systems in the world.
z Manufacturing
Parunak (1987) describes the YAMS (Yet Another Manufacturing System), which applies the well-know Contract Net protocol (Smith, 1980) to manufacturing control. A manufacturing enterprise is modeled as hierarchy of workcells. The goal of YAMS is to efficiently manage the production process at the plants. To achieve the enormously complex task, YAMS adopts a multi-agent approach, where each factory and factory component is represented as an agent. Each agent has a collection of plans, representing its capabilities. The contract net protocol allows tasks to be delegated to individual factories, and from individual factories down to flexible manufacturing systems, and then to individual workcells.
The contract net protocol (CNP) is based on the idea of negotiation, and hence YAMS views the problem of deciding how best to process a company’s product manufacturing requirements as a negotiation problem. A some-what similar approach was developed in (Wooldridge et al., 1996), where the problem of determining an optimal
production sequences fro a factor was analyzed using the tools of game and negotiation theory.
z Air Traffic Control
Kinny et al. (1996) describe a sophisticated agent-realized air traffic control system known as OASIS. In this system, which is undergoing field trials at Sydeny airport in Australia, agents are used to represent both aircraft and various air traffic control system in operation. The agent metaphor thus provides a useful and natural way of modeling real-world autonomous components. As an aircraft enters Sydeny airspace, an agent is allocated for it, and the agent is instantiated with the information and goals corresponding to the real-world aircraft.
Commercial Applications
z Information Management
As the richness and diversity of information available to us in our everyday lives has grown, so the need to manage this information has grown. The lack of effective information management tools has been given rise to what is colloquially known as the information overload problem. Put simply, the sheer volume of information available to us via the Internet and World Wide Web represents a very real problem. The potential of this resource is immediately apparent to anyone with more than the most than the most superficial experience if using the WWW. But the reality is often disappointing. There are many reasons for this. Both human factors and organizational factors conspire against users attempting to use the resource in a systematic way (Jennings and Wooldridge, 1998). The information overload problem can be characterized in two ways: (1) Information filtering and (2) information gathering.
One important contributing factor to information overload is almost certainly that an end user is required to constantly directly the management process. Three such projects are listed as follows:
1. Maxims: (Maes, 1994) describes an electronic mail filtering agent called Maxims. The program learns to prioritize, delete, forward, sort, and archive mail message on behalf of a user.
2. Newt: (Maes, 1994) also describes an example of an Internet news filtering program called Newt. This program, implemented in C++ on a UNIX platform, takes as input a stream of Usenet news articles, and as output gives a subset of these articles that it is recommended the user reads.
3. The Zuno Digital Library: A digital library is an organized, managed collection of data, together with services to assist the user in making use of this data. The Zuno Digital Library (ZDL) systems is a multi-agent system that enables a user to obtain a single, coherent view of incoherent, disorganized data sources such as the World Wide Web, a user’s own data, collections of articles on publishing house sites, and so on (Zuno, 1997).
z Electronic Commerce
Currently, commerce is almost entirely driven by human interactions; humans decide when to buy goods, how much they are willing to play, and so on. Some commercial decision making can be placed in the hands of agents. As an example, Chavez and Maes (1996) describe a simple electronic marketplace called Kasbah. This system realizes the marketplace by creating buying and selling agents for each good to be purchased or sold respectively. Commercial transactions take place by the interactions of these agents.
z Business Process Management
Company manager make informed decision based on a combination of judgment and information from many departments. Ideally, all relevant information should be brought together before judgment is exercised. However obtaining pertinent, consistent and up-to-date information across a large company is a complex and time consuming process.
For this reason, organizations have sought to develop a number of IT systems to assist with various aspects of the management of their business process. Project ADEPT (Jennungs et al., 1996) tackles this problem by viewing a business process as a community of negotiating, service-providing agents. Each agent represents a distinct role or department in the enterprise and is capable of providing one or more services.
Besides the industrial and commercial applications, software agents were also tried to apply in the medical and entertainment fields (Jennings and Wooldridge 1998).
Similar to the applications of the agent-based business process management, this study applies the multi-agent system approach to integrate and manage the cross-organizational processes of A/E and GC, which will be the infrastructure for facilitate the fast-track construction in a D/B project.
2.5 Object-Oriented System Development (OOSD)
Object-oriented system development (OOSD) stems from the Simula programming language in the 1960s (Dahl and Nygaard 1966). Simula was used to create computer simulations using objects such as ships, buoys, and tides in fords (Satzinger et al 2000).
Objects are the abstractions of physical and conceptual things that have relations, attributes, and behaviors. Object orientation (OO) is the concept that treats every physical and
conceptual thing as the objects (Booch 1994). The OOSD views a system as a collection of interacting objects that work together to accomplish tasks (Satzinger et al 2000). This approach is an entirely different approach to traditional methods such as structured approach and information engineering approach. It develops the software applications in terms of component objects, classes of related objects, and frameworks of related objects and classes.
The OOSD approach views a system as a set of interacting objects. In addition, these objects are described in an abstract manner. Therefore, an incremental and iterative method is suitable for implementing OOSD (Pittman 1993). A system development life cycle generally includes six phases: plan, analysis, design, implement, test, and maintenance. Developing incrementally means to refine systems in steps, whereas, iterative development denotes to grow up systems with looping processes (Firesmith 1993).
The schematic diagram of the incremental and iterative method is shown in Figure 2.5.
Unlike the waterfall approach, the incremental and iterative method delivers the whole system using several iterations. Each iteration builds one portion of the system (incremental) on previous delivery. Since the method accomplishes a portion of the whole system at a time and each development cycle recovers software errors occurring in previous delivery, development risks and complexity are reduced effectively (Caspers 1994;
Satzinger et al 2000). This method also cuts down the overall costs and the development time.
Analysis
Design Test
Plan
… Maintenance
Implement
…
Data flow Legend
Process Division Cycles
…
Data flow Legend
Process Division Cycles
Figure 2.5 Incremental and Iterative Method (Ko, 2002)
For communicating with system participants and modeling and documenting OO software systems, proper notation is required in OO system development life cycle (Vadaparty 2000). The Unified Modeling Language (UML) has been adopted as a standard OO specification language by the Object Management Group (OMG) for specifying, visualizing, understanding, constructing, and documenting OO software using OO concepts (Systä 2000). The OMG is a consortium that develops and propagates uniformity in OO systems. The UML provides several robust models including use case, class, object, component, deployment, sequence, collaboration, statechart, and activity diagrams for users to describe applications for different purposes (Booch et al. 1999). It has also received de facto approval by system developers for modeling software under various OO system development processes (Larman 1999). Therefore, the UML standardized notation is an appropriate notation system for modeling OO systems (Coleman et al. 1997).
Based on the OOSD approach, this study applies the UML to develop the Design-Build Process Collaboration system (DBPCS) to facilitate the fast-track construction.
CHAPTER 3
INTEGRATED DESIGN-BUILD FRAMEWORK (IDBF)
3.1 Problem Description of Integrated Design-Build Framework
This study aims to create an Integrated Design-Build Framework (IDBF) as the architecture to execute a design-build project by combining a fast-tracking mechanism and design-build delivery method with the processes reengineering philosophy. Therefore, to develop the IDBF, the primary concerns about facilitating the fast-tracking construction by process integration are necessary to determined.
Fast-tracking network is the target of the IDBF
The purpose of cross-organization process re-engineering in this research is to facilitate the fast-track construction in the D/B projects. To achieve this purpose, a fast-tracking network needs to be schemed preliminarily so that the re-engineered cross-organizational processes of A/E and GC can then be designed for implementing the fast-tracking network. Therefore, how to determine the fast-tracking phases and their overlapping relationships is the first concern for developing the IDBF. To overcome this problem, dividing a D/B project into several design-build packages and identifying their sequential relations are two essential tasks. As the fast-tracking phases and overlapping relationships are determined, a fast-tracking model depicting the network of fast-tracking construction can be created subsequently.
Collaborative process model of A/E and GC is essential for fast-tracking
Because design and construction activities respectively executed by A/E and GC are both included in the fast-tracking phases, how to cooperate between A/E and GC is the
second concern in the IDBF. Accordingly, aiming at the collaboration between A/E and GC’s processes, this study applies business process re-engineering (BPR) philosophy to generate the collaborative process model of A/E and GC. For this purpose, some problems and constrains for creating the collaborative process, inherited from the natures of BPR philosophy and design-build projects, are necessary defined preliminarily.
First, the created collaborative process is project-oriented one, due to the different constitution of different design-build project allies; i.e., the collaborative mechanism may differ from projects due to different processes within alliances’ organizations. Moreover, for both GC and A/E, since a design-build team is a temporary alliance, and several design-build projects may possibly concur, the collaborative process model is properly created based on the original processes without changes or modifications for the existing processes so that design professional and GC can perform their collaborative process model under the usual processes. Accordingly, recognizing the collaboration links and potential information flows between design professional and GC’s processes is the core for creating a collaborative process model. Interoperability of process is the main focus of the cross-organization process reengineering. The processes of A/E and of GC can be integrated from an information processing viewpoint based on the input-operation-output paradigm.
Second, to reengineer the processes across the boundary between design professional and GC, an abstract process model providing formal representation of process characteristics is necessary at the beginning of process reengineering (Scheer, 2000; Irani et al., 2001). However, under circumstances addressed by Cheng (2003), it is often difficult if not impossible for managers to accurately describe by category the operational processes of a construction company and of a design professional. Generally, ISO specifications are
useful references for process modeling due to the details they provide on management processes and activities; therefore, this study refers to the ISO specifications and applies the eEPC diagram of the ARIS modeling language (Scheer, 2000) to depict graphic process models providing a visual view of the abstract process model. When process models are generated, two processes can then be compared with similarity measures to determine the possible collaboration links and information flows between them.
An information system for managing the execution of the fast-tracking and the collaborative process model is the significant infrastructure in the IDBF.
Unlike the traditional linear design and construction procedure, complexities of project execution and potential risks may increase with the overlapping activities in the fast-track construction. Besides, the activities within the collaborative process model are distributed over A/E and GC’s organizations. Thus, how to manage the execution of the collaborative process model to facilitate the fast-tracking is the final concern in the IDBF.
To overcome this problem, a process management system is significant for executing the collaborative processes. The process management system needs not only the capability to manage the execution the collaborative processes, but also the function to manage the execution of fast-track phases in a D/B project.
Summarily, to develop the IDBF, the fast-tracking model, the collaborative process of A/E and GC, and a process execution management information system are the three primary components needed to create. Following this idea, the architecture of the IDBF is developed.
3.2 Architecture of Integrated Design-Build Framework
The three models encompassed by the IDBF include the (1) fast-tracking model, (2)
collaborative process model, and (3) Design-Build Process Collaboration System (DBPCS), as shown in Figure 3.1. The fast-tracking model is the constitution of design-build modules (DBMs) as derived from an analysis of the axiomatic design (AD) method. Each DBM is assigned a project sub-goal, to be achieved by the collaborative design and construction processes within the collaborative process model (CPM). The fast-tracking phases of a Design-Build (D/B) project can be determined based on DBM overlapping relationships.
Moreover, the collaborative process model is composed of collaborative design and collaborative construction processes, both of which are generated using the Cross-Organizational Process Re-engineering Method (COPReM). The COPReM is used to identify areas of overlap between A/E and GC processes to determine activities that are common to both. The bottom layer of the IDBF is addressed as the Design-Build Process Collaboration System (DBPCS), which serves as the IDBF implementation infrastructure.
The fast-tracking and collaborative process models created, respectively, in the first and middle layers, are both conceptual models that are difficult to implement due to their complexity. To overcome this problem, the DBPCS must be designed to implement fast-tracking and integrated process models automatically.
Figure 3.1 Architecture of Integrated Design-Build Framework (IDBF)
To develop three layers in the IDBF, this study first applied the axiomatic design (AD) methodology to map a D/B project into customer, functional, physical and process domains by zigzagging decomposition and creating dependency matrices. Figure 3.2 shows AD mapping relationships. Each associated domain consists of specific characteristic vectors such as customer need {CN}, functional requirement {FR}, design proposal {DP} and construction process variable {CPV}. Concurrently, the design matrix [A] between {FR}
and {DP} vectors and the construction matrix [B] between {DP} and {CPV} vectors can
and {DP} vectors and the construction matrix [B] between {DP} and {CPV} vectors can