Simulation Practice and Theory 9 (2002) 167–192 www.elsevier.com/locate/simpra
An approach to integrating HLA federations and genetic algorithms to support automatic design evaluation for multi-agent systems Sajal K. Das *, Arthur A. Reyes Department of Computer Science and Engineering, University of Texas at Arlington, P.O. Box 19015, Arlington, TX 76019-0015, USA Received 1 March 2001; received in revised form 1 October 2001
Abstract We propose a novel design environment for developing multi-agent systems (MASs) for applications in mobile robotics. Because emergent behavior phenomena make it next to impossible to directly synthesize viable MAS designs from specifications, extensive simulation studies are needed to evaluate these designs. Furthermore, due to the fact that the design space for MASs systems is combinatorially large, the evaluation of candidate designs must be done in a hierarchical, multi-resolution, parallel and distributed manner. Our proposed design environment is based on US Department of Defense’s high-level architecture (HLA), an established software infrastructure for heterogeneous, distributed simulations. The proposed environment automatically generates and manages HLA federations (i.e., collections of distributed and/or parallel simulation and service federates) that communicate over runtime infrastructure (RTI) software buses. Each federation simulates a different candidate design for the MAS under development. Federations execute independently and in parallel. Our proposed design environment’s refinement component uses a genetic algorithm (GA) to select the best candidate designs from the current generation and generates a set of refined, next-generation, candidate designs. A federation is created and managed for each of the next-generation designs and the automatic design process is repeated. 2001 Elsevier Science B.V. All rights reserved. Keywords: High-Level Architecture; Genetic algorithms; Simulation; Multi-agent systems; Simulationbased design; Design environment
*
Corresponding author. Tel.: +1-817-272-7405; fax: +1-817-272-3784. E-mail addresses:
[email protected] (S.K. Das),
[email protected] (A.A. Reyes).
0928-4869/01/$ - see front matter 2001 Elsevier Science B.V. All rights reserved. PII: S 0 9 2 8 - 4 8 6 9 ( 0 1 ) 0 0 0 5 2 - 0
168
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
1. Introduction Inspired by technological advances in electronics, sensor, actuator, and power plant miniaturization, the U.S. Department of Defense (DoD) plans to develop a collection of autonomous weapon systems that are inexpensive, effective, and operate with each other in cooperative teams. Examples include low cost autonomous attack system (LOCAAS) [28], Future (Ground) combat system (FCS) [24], and smart sensor web (SSW) [12]. At this time, the most appropriate conceptual framework within which to formulate systems such as these is the emerging discipline of multi-agent systems (MASs) [13]. Under the MAS paradigm, each individual system component (such as a LOCAAS vehicle) is an ‘‘agent.’’ As hardware technologies in such systems gain maturity, DoD shifts its engineering emphasis to address the information technology (IT) needed to both integrate hardware technologies within systems and to enable individual weapon system components to cooperate with other weapon system components in an autonomous, intelligent, swarmed manner within environments that are uncertain, dynamic, and adversarial [17]. Companies wishing to develop mobile MASs cost-effectively need a low-risk, manageable, comprehensive, top-down, development methodology (with appropriate theoretical and tool support). The fundamental stumbling block that stymies development of such a methodology is that MASs are characterized by emergent behavior (EB). In EB, a collection of agents (i.e., an MAS) seems to act in a more organized manner than would be indicated by the behavior of each agent in isolation. MAS researchers are realizing that EB does not vary linearly with changes in specified MAS mission dynamics or changes in mission simulation fidelity [13]. In other words, slight changes in either can result in dramatically different EB. The EB phenomena often frustrate MAS robot developers because there exist unexpected but relevant differences between simulations and real-world implementations, causing costly redesign. Effectively mastering EB is an important challenge to defining a comprehensive engineering development methodology for MASs. Therefore, MAS researchers have used two principal approaches to understanding EB: (i) dynamic simulation of fully defined agent designs [13], and (ii) static analysis under large-scale equilibrium conditions [34]. Under dynamic simulation of fully defined agent designs, a collection of design simulations are instantiated and each is tested under identical initial conditions. Quantitative, statistical distributions of design performance and EB are generated. Static analysis under large-scale equilibrium conditions is analogous to models used in economic theory. Dimensions in MAS design space are manifold and for the most part, orthogonal. They include: intended mission scenarios; MAS paradigm; MAS architecture; distribution of skills among agents; number of agents; inter-agent communication protocol and bandwidth; agent memory size; agent rule set size; number, placement, and orientation of commercial, off-the-shelf (COTS) sensors and actuators on agents; type, sizing, placement, and orientation of propulsion system; etc. This results in a search space of large combinatorial size. MAS design space dimensions specifically
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
169
addressed by our research at this time include number of each kind of agent, kinds of equipment carried by each kind of agent, and spacial formation of agents at the start of each mission simulation. Another complicating factor in MAS development is the need for multi-objective, global design optimization. Agents envisioned by DoD will be mass-produced: inexpensive, lightweight, and expendable. DoD MAS redundancy will occur at the level of agents, rather than at the level of subsystems within agents. Thus, DoD MAS agent designs will feature highly constrained budgets for cost, weight, and power. Under these highly constrained budgets, it is unreasonable to expect that an information system integrated later onto an extant agent design will produce useful emergent, cooperative, multi-agent behavior. For example, because of changes in required resources for communication bandwidth and computing, it may be infeasible to redesign an extant agent to support a cooperation protocol and rule set with globally optimal MAS performance. Instead, we believe MAS design is mutually constrained under typical mission scenarios, extant sensors and actuators, physical limitations of aerial and ground platforms, etc. Each candidate MAS design must be evaluated to determine its mission effectiveness and cost. While it may be possible to use high-level, equilibrium-based, time-invariant quantitative models to make early MAS design decisions, eventually EB phenomena force later design decisions to be made after simulation studies of many MAS designs. To arrive at satisfactory MAS designs (which may be globally near-optimal because of limited agent design resource budgets), the design process requires generation and evaluation of a large number of candidate designs, EB sensitivity analysis, and a host of specialty engineering analyses (e.g., vehicle sizing, wireless communication protocol evaluation, etc.). Because EB is difficult to master, evaluation of MAS designs requires extensive simulation capabilities at various levels of abstraction. 1.1. Our contribution We address these issues by developing an automated design environment for MASs. Our proposed design environment enables engineers to automatically explore a large number of candidate operational concepts and detailed designs and select the most promising designs. We expect our design environment will significantly advance the state of the art in MAS design, because the MAS discipline has not yet produced a development methodology that can directly synthesize viable designs from specifications. Because insufficient theoretical results currently exist to inform direct, top-down synthesis of MAS designs from static mission specifications, we build our design environment around a large-scale, distributed and/or parallel, heterogeneous, simulation infrastructure: Defense modeling and simulation office’s (DMSO’s), high-level architecture (HLA) for modeling and simulation [9]. Our proposed design environment supports multi-objective design optimization via an automated design refinement (i.e., design search space control) component.
170
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
Candidate designs are evaluated with respect to a utility/fitness function specified by the engineer. The design refinement component uses a genetic algorithm (GA) to inform generation of refined designs from a collection of current designs. 1.2. Related work Our proposed design environment represents the first application of both GA and HLA to the problem of optimizing the design of MASs. To more clearly illustrate our contribution, this section very briefly describes related work. Because ours is the first, we discuss the four most closely-related bodies of work: (1) using HLA (or similar technologies) and GAs to automate engineering design, (2) using HLA (or similar technologies) to support engineering design, (3) simulation-based design of MASs, and (4) using GA as an engineering design optimization tool. 1.2.1. Using HLA and GA for Design ModSAF (modular semi-automated forces) [25] is a software technology supporting distributed interactive simulation (DIS) [16], the progenitor of HLA. ModSAF simulates the behavior of military forces. This is especially helpful in automating DIS military training applications, because it reduces the workload of human operators who facilitate training exercises. One problem encountered in SAFs is that their movements tend to be too predictable. Real military forces must move in less-thanpredictable patterns to reduce their vulnerability to attack. The work of [14] uses GAs to automatically design movement paths for simulated M1 Abrams main battle tanks within a simulated ModSAF environment. Good paths expediently get the simulated tank from the source to the destination, avoid obstacles, avoid getting lost, and are difficult to predict. This research appears to bear the greatest similarities with our own research. In [14], evaluating the fitness of each candidate path occurs offline from the DIS. In our proposed MAS design environment, evaluating the fitness of each candidate design occurs online via the HLA infrastructure. In [14], there are no interactions between tank agents and consequently no EB. In our proposed design environment, exploration of EB is a significant concern. 1.2.2. Using HLA for design Joint MEASURE (Mission Effectiveness Analysis Simulator for Utility, Research and Evaluation), reported in [36], demonstrates how HLA simulation can be used to analytic studies of mission effectiveness of systems within larger systems of systems. Two simulation environments supporting design of unmanned underwater vehicles have been presented in [7]. Because of the first environment’s poor performance, the authors chose to base the second simulation environment on HLA. 1.2.3. Simulation-based Design of MASs Engineering textbooks present theoretical models that describe the behavior of various physical phenomena (e.g., stress and strain in thin beams, fluid flow around bodies, heat flow between media, etc.). In their general form, these theoretical models
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
171
are unwieldy. If simplifying assumptions are made, these theoretical models are useful for deriving analytical solutions to simple problems. Computer simulation techniques allow theoretical models to be applied to complex problems without making simplifying assumptions that decrease the accuracy of the final answer. The advent of inexpensive, powerful computers now enable engineers to use simulation methods more cost-effectively than analytical methods. Simulation-supported engineering design processes are now typical. Simulation-based design (SBD) [8,18] formalizes, extends, and integrates these new engineering processes. SBD aims to reduce development risks by enabling many alternative operational concepts and designs to be evaluated before significant effort is expended developing poor designs. SBD emphasizes highly integrated software tool support for collaborative, concurrent engineering over the entire product lifecycle. SBD tool environments comprise extensible descriptions of both products and processes, the ability to easily assemble and invoke design and analysis tools and simulations, and a collaborative infrastructure that enable distributed engineering teams to work together. Authors in [11] and [29] report on a simulation testbed supporting SBD of a MAS to ocean sampling. 1.2.4. GA as an engineering design optimization method GA has become an established engineering design optimization method. There are thousands of articles describing application of GA to all branches of engineering design. A smattering of examples from several branches of engineering can be found in [21]. GA has become especially attractive for design problems where manual, analytical modeling of the relevant phenomena is too difficult. Many researchers, already skilled in traditional analytical techniques, have started to turn to GA to tackle more complex problems. For example, GA has allowed Kwak’s highly analytical research in flexible, multi-body dynamics and vibration [1,35] to evolve in the direction of designing (e.g., tuning) multi-parameter controllers for ‘‘smart structures’’ with active vibration suppression [19,20,23].
2. Proposed design environment The long-term objective of this research is to develop a comprehensive engineering development methodology (with theoretical and software tool support) for mobile, robotic, MASs. Our approach is to extend and adapt an extant framework for heterogeneous, distributed and/or parallel simulation, namely DMSO’s, HLA [9] to support comprehensive engineering development processes for MASs. The HLA provides the required support for evaluating a large number of candidate MAS designs in a parallel and distributed manner. The HLA also supports interoperability of heterogeneous simulation models across different programming languages, operating systems, CPU instruction sets, frame rates, state generation techniques (timeframe or discrete event), and networks.
172
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
2.1. Preliminaries on HLA The HLA consists of ‘‘Rules,’’ which govern the behavior of each overall distributed simulation (a ‘‘federation’’) and its members (‘‘federates’’); an interface specification, which defines the interface between federates and the runtime infrastructure (or ‘‘RTI’’), a supporting software component (bus) that is responsible for providing communication and coordination services between federates; and an object model template (OMT) which defines how federations and federates have to be documented [6]. A ‘‘federation’’ is a collection of federates and an RTI that targets a specific objective such as distributed, interactive training for a specific mission; or automated evaluation of a system design under a collection of mission scenarios. HLA’s interface specification [27] defines an application programming interface (API) with 129 access points (i.e., types, variables, procedures, and functions). These access points enable programmers developing HLA federations and federates to observe and control simulation objects and services in a disciplined and reusable manner. 2.2. Architecture of our proposed design environment A goal in developing our design environment is to reuse and apply extant software components and tools, such as DoD’s, ModSAF wargaming tool [14,25] and PARSA [30], and research tools such as SWiMNet [4,5]. In addition, we develop new software components to generate and manage federations and refine candidate designs. Fig. 1 shows a typical HLA federation supporting evaluation of a MAS design (i.e., ‘‘federation i’’). Boxes represent federates (i.e., simulation models and related tools). The software communication bus to which they are connected is the HLA RTI.
Fig. 1. A federation supporting evaluation of MAS design i.
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
173
The federate named MAS design i, represents a (generated) simulation model of the behavior of candidate MAS design i. The federate named threat T1 represents a (reused) simulation model for a threat. The federate calculate utility of design, which we develop for this research, observes the simulated behavior of MAS design i as it participates in the federation’s simulated mission. We will discuss details of utility functions later. The federate Wireless Comm Sim Tool represents an HLA-enabled, reused research tool for evaluating the performance of wireless communication designs, such as SWiMNet. Federates can participate in more than one federation simultaneously. Each federate is represented in a federation via an ‘‘ambassador.’’ In terms of object-oriented programming [3], federates can be thought of as ‘‘classes’’ (i.e., definitions of computational services). Federate ambassadors can be thought of as ‘‘objects:’’ specific instances of classes. Each federate ambassador maintains its own state that is specific to the federation in which it participates. According to HLA rules, multiple ambassadors of the same federate participating in simultaneous federations cannot communicate with each other over the RTI. Federate ambassadors enable reuse of genetic simulation models and tools in simultaneous federations. More than one federation can use the same RTI, but they cannot communicate with each other over the RTI. This is consonant with the notion that each federation represents an independent simulation ‘‘world’’ with a specific objective. The federate calculate utility communicates with the multi-federation manager (MFM), a software component we develop that generates a set of parallel and distributed federations to evaluate a collection of design candidates. Fig. 2 depicts the conceptual architecture of our proposed design environment. The two principle conceptual components of our proposed design environment are the MFM and the design refiner (DR), described below. 2.2.1. MFM The MFM, depicted as the large U-shaped component, takes as input a set of candidate MAS designs (assume there are N candidate designs). For each candidate design, the MFM creates a federation. Thus, there are N parallel, independent federations. Fig. 2 represents the lifetime of each federation by a horizontal bar stretching from the left side of the MFM to the right side of the MFM. In Fig. 2, text running left-to-right denotes operations invoked by the MFM. Text running top-to-bottom denotes (common) operations invoked by each federation. All generated federations are identical except each possesses a unique federate that models the behavior of the associated candidate design (i.e., MAS design i). All generated federations follow the same mission. The mission evaluates each design candidate in a sequence of interesting scenarios (e.g., launch, evade threats, search for targets, and attack targets). Each federation runs until its mission is completed or until it determines that the the mission cannot be continued (e.g., because all agents have been destroyed before attacking their targets). While each federation runs, the federation’s compute utility federate (ambassador) calculates the value of the candidate design’s overall utility value. Before each
174
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
Fig. 2. Conceptual architecture of our proposed design environment.
federation is terminated, the compute utility federate ambassador sends the utility value of the candidate design to the MFM. We denote this action by the arrows labeled U1 , U2 , and UN from each federation to the MFM. After terminating all federations, the MFM compares the utilities of each of the candidate designs and provides as output the best candidate designs to the DR. The number and distribution of best designs sent to the DR is selectable by the designer. 2.2.2. DR The DR component takes as input the most promising candidate designs resulting from the N federations. It makes use of a GA [21] to generate a new set of N candidate designs from the prior, promising designs. In the GA approach, each design is encoded on a chromosome such that the design parameter values map to bit sequences (or other suitable data type). Given a pool of parent designs, a new generation of designs can be generated via the genetic operations of selection, crossover, and mutation. From the current population of designs, the selection operation selects a subset to participate in crossover and mutation, based upon their fitness. In (onepoint) crossover, a next-generation design chromosome is the concatenation of part of one parent’s chromosome and part of the other parent’s chromosome. The crossover point is determined at random. In mutation, a design’s chromosome is mutated at random and copied to produce a new chromosome.
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
175
The N candidate designs produced by DR are input to the MFM and the automatic design process is repeated until a design is discovered that possesses a utility value that exceeds an designer-specified threshold. 2.3. Example: optimization via GA This subsection provides a miniature example of optimization via GA. Let each chromosome be a list of three bits. Let the utility/fitness function be the numeric, binary value of each chromosome (i.e., an integer between zero and seven, inclusive). Let the population size be six. Let the optimization continue until a chromosome possessing a minimum utility required (MUR) is discovered. Let the MUR be seven. Step 1: Generate a random, initial population of six chromosomes (i.e., a ‘‘gene pool’’), say 001, 011, 100, 000, 011, 001. In this example, because the population is not small with respect to the size of the state space (i.e., 23 ¼ 8 elements), we can expect to find more than one instance of the same chromosome. In real-world applications of GA, the population size is usually very small with respect to the state space size. Step 2: Evaluate the utility of each chromosome. 001 ! 1 011 ! 3 100 ! 4 000 ! 0 011 ! 3 001 ! 1 Step 3: Rank the chromosomes according to their utility. 000 ! 0 001 ! 1 001 ! 1 011 ! 3 011 ! 3 100 ! 4 Step 4: Select a specified fraction of the chromosomes exhibiting high utility. Let this fraction of the population be the best 50%. If any chromosome is found possessing the minimum required utility (i.e., seven), the optimization stops. The selected chromosomes serve as parents for the next generation of chromosomes. Unselected chromosomes are discarded. P1 ¼ 011 P2 ¼ 011 P3 ¼ 100 Step 5: ‘‘Mate’’ the selected chromosomes together via the crossover operation. Let there be exactly one crossover point and the location of the crossover point occurs at random anywhere after the first bit and before the last bit. Let crossover between parents occur at random until a population of the required size (i.e., six) is generated.
176
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
-------P3 ¼ 10|0 ! C1 ¼ 101 P2 ¼ 01|1 ! C2 ¼ 010 --------P3 ¼ 1|00 ! C3 ¼ 111 P1 ¼ 0|11 ! C4 ¼ 000 ---------P2 ¼ 01|1 ! C5 ¼ 011 P1 ¼ 01|1 ! C6 ¼ 011 -In the last crossover, child chromosomes C5 and C6 are identical because their parents are identical. The sixth step is to mutate the newly-generated generation of chromosomes. Let the probability that any bit will change value be 5%. C10 ¼ 101 C20 ¼ 010 C30 ¼ 111 C40 ¼ 010 ði:e:; second bit was flippedÞ C50 ¼ 011 C60 ¼ 011 The process now repeats with reapplication of step two: the utility of each chromosome is evaluated. C10 ¼ 101 ! 5 C20 ¼ 010 ! 2 C30 ¼ 111 ! 7 C40 ¼ 010 ! 2 C50 ¼ 011 ! 3 C60 ¼ 011 ! 3 Reapplication of step three ranks chromosomes by utility. C20 ¼ 010 ! 2 C40 ¼ 010 ! 2 C50 ¼ 011 ! 3 C60 ¼ 011 ! 3 C10 ¼ 101 ! 5 C30 ¼ 111 ! 7 Reapplication of step four finds chromosome C30 possessing the minimum required utility. Optimization stops. 2.4. Design methodology Our proposed MAS design environment will support a comprehensive MAS engineering development methodology comprised of (1) specification of mission and component constraints via our design environment, (2) automatic exploration of
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
177
the design space under these constraints via our design environment, (3) EB sensitivity analyses via our design environment, (4) prototype fabrication and testing, and (5) design refinement (i.e., step 1) based on evaluation of the prototypes. Because the proposed design environment uses HLA extensively, it should be easily extensible by DoD contractors and other MAS developers, who gain experience with HLA on current projects. Because the basic design environment will exist, developers will be able to focus their resources on extending it with their own custom simulation federates and specialty engineering analysis tools. This will lower development risks for MAS customers and developers. 2.5. High-Level design description This subsection provides more detailed and precise software design data for our proposed design environment. In contrast to the informal architecture diagram in Fig. 2, the diagrams in this subsection are more syntactically and semantically precise. The graphical software design specifications are expressed in functional design decomposition language (FDDL) [31]. FDDL is an emerging design notation that emphazises functional decomposition, pure functions, precise semantics, tree structure, and clean visual appearance. An FDDL graph defines a function and is comprised of a large rectangle that denotes the function or system (i.e., highest-level function) being designed. Within the large rectangle are trees of (smaller) function call rectangles and dataflows between them. Data flows through these trees up from leaves to roots. The output of the function/system being specified is generated by the one tree that has its root connected to the top of the function/system rectangle. free-floating trees compute intermediate data. Inputs to functions are shown as named arcs along their bottom edge. The output of a function is denoted by a single, named arc at the top of the function’s rectangle. FDDL is useful for refining functions declared in classes or abstract data types (ADTs) [2]. A class or ADT defines a type (e.g., generic stack type) and (1) constructor functions to create instances of the type (e.g., makeEmptyStack), modifier functions that change the value of instances of a type (e.g., push), accessor functions that observe aspects of the value of instances of a type (e.g., top, size, empty?), and functions that operate on two or more instances of a type to yield a new instance of a type (i.e., equalStacks?). As needed, FDDL reuses ADTs defined in the Standard ML of New Jersey (SMLNJ) Library [22]. FDDL function identifiers start with a lowercase letter. FDDL variable and type identifiers start with an uppercase letter. 2.5.1. Top-level design details Fig. 3 shows the first-level of functional decomposition within our design environment. The name of the first-level function is control. control corresponds roughly to the conceptual architecture’s DR component (i.e., bottom of Fig. 2). control takes as input Gene Pool, Fraction To Select, Bit Flip Prob, Min Util Reqd, and Num Of Cross Pts and produces Best Chromosome as
178
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
Fig. 3. control is the first-level function for our design environment.
output. Gene Pool is the initial collection of chromosomes. Gene Pool is an instance of type ChromoUtilMap.map, a refinement of SMLNJ’s genetic binary map ADT. Maps are analogous to arrays and can be thought of as a set of pairs. The index is the first component of each pair and the associated value is the second component. There cannot exist two pairs with the same index. In the case of Gene Pool, the indices are of type Chromosome and the associated values are of type Utility. Fraction To Select is a real number between zero and one inclusive that denotes the fraction of best chromosomes from Gene Pool to be selected for generating the next-generation Gene Pool. Bit Flip Prob is a real number between zero and one inclusive that denotes the probability that any bit in a chromosome will be mutated to the opposite value. Min Util Reqd is a real number greater than zero that denotes the GA stopping condition in terms of the minimum utility value required. Number Of Cross Pts is a natural number between one and the length of a chromosome minus one and denotes the number of crossover points to be used during the crossover operation. Design chromosomes must have length of at least two. Best Chromosome is the chromosome for the first design that meets Min Util Reqd. Functional decomposition proceeds by considering the output that must be generated and works ‘‘downwards’’ (i.e., toward inputs) to discover new or apply extant functions that will generate it.
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
179
Best Chromosome is generated by the conditional function (denoted by a black, equilateral triangle). The conditional function’s condition appears in the center subtree. The value to be returned if the condition holds appears as the right subtree. The value to be returned if the condition does not hold appears as the left subtree. The condition, Stop?, denotes whether the Utility of the best chromosome found thus far is at least as great as Min Util Reqd. Utility is viewed by selecting the second component of Best Chromo Util Pair. Best Chromo Util Pair represents a single index/value pair from Gene Pool. If this holds, Best Chromosome has the value of the best chromosome in Gene Pool. This Best Chromosome is computed by selecting the first component of Best Chromo Util Pair. If the condition does not hold, Best Chromosome has the value Recursive Best Chromosome, which is generated by a recursive call to control. Actual parameters to the recursive call to control are the same as when control was initially called, except the Gene Pool formal parameter has the actual parameter Tested Gene Pool. Recursive function call rectangles are shown in bold, as is the system’s rectangle. FDDL uses recursion in lieu of iteration. Tested Gene Pool is generated by manage Multi Federations. manage Multi Federations supports federation creation, execution, and termination. manage Multi Federations corresponds to the conceptual architecture’s MFM component. manage Multi Federations assigns a utility value to each chromosome in Gene Pool by instantiating and simulating a corresponding MAS design within an HLA federation. manage Multi Federations takes as input Untested Next Gen Gene Pool, which is generated by refine Designs. refine Designs satisfies the requirements for applying the GA operations of selection, crossover, and mutation. refine Designs takes as input Gene Pool, Fraction To Select, Bit Flip Prob, and Number Of Cross Pts. Best Chromo Util Pair is of type Chromosome * Utility (i.e., a pair) generated by taking the first element (i.e., the head of a list of elements) of a list of type (Chromosome * Utility) list sorted by descending Utility, Sorted Gene Pool. Sorted Gene Pool is generated by sort By Decreasing Utility, which takes Gene Pool as input. control requires no further decomposition, but manage Multi Federations, refine Designs, and sort By Decreasing Utility do. 2.5.2. Second-level design details The second-level of design details decomposable functions introduced in the toplevel design. Fig. 4 shows the design of manage Multi Federations. As specified in the FDDL design for control, manage Multi Federations takes as input UnTested Gene Pool and generates Tested Gene Pool. Tested Gene Pool is generated by assign Utilities, which takes as input Logs denoting the utility value for each tested design. Logs is generated by run Federations, which takes as input Federations from map Genotypes, which takes UnTested Gene Pool as input. Assign Utilities, run Federations, and map Genotypes require additional decomposition. At this time manage Multi Federations is not parameterized by a federation specification or federate specifications. Thus the
180
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
Fig. 4. manage Multi Federations controls the creation, execution, and destruction of federations to evaluate designs.
specific federates that participate in the federation and their configurations are ‘‘hard coded’’ into the design environment. Fig. 5 denotes the design of refine Designs. refine Designs generates UnTested Gene Pool. The last action performed on a gene pool before it is evaluated is mutation, here performed by the function mutate Gene Pool. mutate Gene Pool takes as input Next Gen Gene Pool and Bit Flip Prob. Next Gen Gene Pool is generated by ‘‘mating’’ a set of selected parent chromosomes via crossover, cross Chromosomes. Cross Chromosomes takes as input Best Chromosomes from the prior generation gene pool, Pop Size Reqd, and Number Cross Pts. Pop Size Reqd is a positive integer denoting the size of the initial Gene Pool. Pop Size Reqd informs cross Chromosomes when it can stop crossing parent chromosomes. Pop Size Reqd is computed by num Items, which is a predefined function on SMLNJ map objects such as Gene Pool. Best Chromosomes is generated by select Best Chromosomes, which implements the GA selection operation. select Best Chromosomes takes as input Gene Pool and Fraction To Select.
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
181
Fig. 5. refine Designs applies the GA operations of selection, crossover, and mutation.
Fig. 6 denotes the design of the third and final decomposable function used in control: sort By Decreasing Utility. As specified in the design of control, sort By Decreasing Utility takes as input Gene Pool. sort By Decreasing Utility first converts Gene Pool from a map to a list via the predefined map ADT function listItemsi. sort By Decreasing Utility uses the predefined sort function to sort the list of type (Chromosome * Utility) list using the supplied predicate lte Chromo Util Pair 2. lte Chromo Util Pair 2, which must be decomposed further, takes as input two instances of type Chromosome * Utility and determines whether the first pair is less than or equal to the second pair according to their Utility component values. sort generates Sorted Gene Pool, which is of type (Chromosome * Utility) list. 2.5.3. Third-level design details The third-level of design details decomposable functions introduced in the secondlevel of design detail. In the interest of space, this section describes only one such function: select Best Chromosomes. Other functions at the third-level of design
182
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
Fig. 6. sort By Decreasing Utility sorts Gene Pool by decreasing Utility value.
detail requiring refinement are assign Utilities, run Federations, and map Genotypes (from manage Multi Federations); mutate Gene Pool and cross Chromosomes (from refine Designs); and lte Chromo Util Pair 2 (from sort By Decreasing Utility). select Best Chromosomes is detailed in Fig. 7. As specified in the design of refine Designs, select Best Chromosomes takes a Gene Pool and a FracToSelect and returns a reduced gene pool, Best Chromosomes, containing the best chromosomes from Gene Pool. select Best Chromosomes determines the population size of Gene Pool via the predefined map ADT function num Items, producing N. N and Frac To Select are multiplied producing Num To Select Real, a real number denoting the number of best elements from the population that must be selected. Num To Select Real is rounded off into Num To Select Int via the predefined function round. Potentially in parallel, select Best Chromosomes also sorts Gene Pool by decreasing utility value via sort By Decreasing Utility, described in the prior subsection. This generates Sorted CU List of type (Chromosome * Utility) list. Next we need to take the first Num To Select Int-best elements in Sorted CU List. We do this via the predefined list ADT function take. This generates Best CU List. Then Best CU List is transformed back into a map Best Chromosomes via the predefined map ADT function listtomap. Because all the functions appearing in select Best Chromosomes already exist or have been designed, select Best Chromosomes’s design does not require further refinement.
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
183
Fig. 7. select Best Chromosomes takes a Gene Pool and a Frac To Select and returns a reduced gene pool containing the best chromosomes.
3. Example MAS application Let us now describe an interesting, example MAS application for our proposed design environment. This example illustrates the kinds of applications we envision for our design environment in the future and gives an idea of the multi-disciplinary nature of this research. Our example application is cooperative search and jamming of enemy anti-aircraft (AA) radars (i.e., an air defense suppression mission) via hierarchical teams of cooperative, autonomous, aerial robots. Three different kinds of aerial robots (i.e., agents) cooperate to accomplish missions. High-level, ‘‘master’’ agents feature sensors capable of detecting and distinguishing between enemy and allied AA radars (i.e., targets) at long-range, but have low-accuracy in pinpointing exact target location or number of targets in a region. Master agents have long-range broadcast communication with supervisory agents at the next lower level in the team hierarchy. Master agents represent one end of the agent design spectrum.
184
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
Low-level, ‘‘worker’’ agents feature short-range, high-accuracy target sensors but cannot distinguish between enemy and allied AA radars. Worker agents feature target jammers. Worker agents receive short-range broadcast communication from supervisory agents at the next higher level in the team hierarchy. Worker agents represent the other end of the agent design spectrum. Mid-level, ‘‘supervisory’’ agent designs exist between these ends of the design spectrum. In our operational concept, we envision an amorphous flock of agents, numbering in the dozens, composed of the three different kinds of agents. Master agents, which are few in number, cause the flock to move toward targets they detect at long-range. If detected targets are widely separated, each master agent’s desire to approach the nearest (group of) targets may result in splitting the flock into parts, each of which attacks a (group of) nearby target(s). As each flock gets closer to a (group of) target(s), supervisor agents more accurately detect targets via their intermediate-range target sensor and cause their subflocks to move toward the nearest target they can distinctly detect. Again, if there are more than one target and more than one supervisor, each supervisor will move toward the target(s) nearest to it, taking its subflock along with it, splitting the flock again. As a flock approaches target(s) closer, workers detect individual targets via their short-range, high-accuracy sensor. Workers orbit the nearest individual target and jam it. Supervisors and workers only approach AA radar emitters they can distinctly identify as targets and will not approach emitters that appear to be undergoing jamming attack. This avoids wasteful, duplicative jamming attacks. Thus the MAS starts off as one flock but gradually breaks up into smaller and smaller flocks to attack individual targets with short-range sensors and jammers. All agents are expendable. Our example design problem is to determine the numerical mix of the three different kinds of agents and determine what features each kind of agent will possess. The advantage of the MAS approach in this example is that each agent need only posses a relatively small set of simple sensors and behavior rules. Missions are accomplished via EB. Our hypothesis is that our design tool will discover a hierarchical MAS design comprised of a small number of master agents, a moderate number of supervisor agents, and a large number of worker agents. 3.1. Agent behavior rules We assume each kind of agent follows the same set of discrete behavior rules. 1 For any combination of situations, the behavior rules tell an agent what to do next.
1
In future work we expect to allow the design environment to select which individual rules each kind of agent should follow.
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
185
In Fig. 8, we list 18 agent behavior rules in the form of a detailed design for a standard metalanguage (SML) function [33]. The name of the function is ACT which takes the form of a decision table [10]. ACT is synchronous, clocked, and defined recursively. ACT’s response to all 18 combinations of input values is specified. ACT takes three parameter values as input and produces a list of agent actions as output. ACT’s first argument denotes whether or not the agent possesses a functioning jammer (true or false). This parameter is constant over the life of an agent. Signal channels are represented by lists: [] represents the empty list (e.g., a closed channel), (h::t) represents a non-empty list (e.g., an active channel), where h is the first element (i.e., the ‘‘head’’ of the list), :: is the list constructor operation that prepends a head element onto a list of elements, and t is the tail of the list (i.e., all elements that follow the head, which can be []). ACT’s output is also a list (of commands). ACT’s second argument denotes the state of the sensor channel that listens for broadcasts by supervisor or master agents to ‘‘follow’’. All agents have a ‘‘following’’ behavior in which they fly in a flock following a supervisor or master. The follow signal channel has three states: [] denotes that the follow signal channel is inoperative/not present, ((ldr::ldrs)::ll) denotes that currently the ‘‘follow’’ broadcast of a set of ‘‘leaders’’ (i.e., supervisors or masters) can be heard, and ([]::ll) denotes that currently no leader’s ‘‘follow’’ broadcast can be heard. ACT’s third argument denotes the state of the sensor channel that listens for targets. All agents have an ‘‘orbit’’ behavior in which they fly around a location in a clockwise circle at a radius and altitude determined by the kind of target sensor they have. Agents that are aware of more than one target and that are not equipped with jammers first orbit the nearest target for a defined duration and then move toward the second-nearest target, etc. Agents equipped with jammers have a ‘‘jam’’ behavior in which they orbit a target and emit a jamming signal at a radius and altitude determines by what kind of
Fig. 8. Behavior rules for each agent expressed as a synchronous SML function.
186
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
jammer they have. The target signal channel has three states: [] denotes that the target signal channel is inoperative/not present, ((tgt::tgts)::tl) denotes that currently a set of targets is detected, and ([]::tl) denotes that currently no targets are detected. All agents keep track of the location of the last target detected last_known_tgt (which is undefined if they have not yet detected a target). All agents have a ‘‘crash’’ behavior in which they fly to a location and ditch themselves into this location. They use this behavior when they run out of fuel (which makes them loose their sensor signals). ACT’s synchronous, clocked, recursive representation enables software engineers to (1) carefully consider what agents should do in response to any combination of inputs, (2) formulate the behavior in an elegant representation, and (3) synthesize hardware implementations (i.e., application-specific integrated circuits) directly from the final functional program [15]. The main drawback of a synchronous representation such as ACT’s is that a combinatorial number of cases can result. 2 By considering each of ACT’s cases, the reader can understand the high-level behavior of any agent. Finally, all agents also have a ‘‘proximity’’ behavior in which they avoid midair collisions with other agents when they detect a (very short-range) proximity broadcast of another agent. 3.2. Simulated hardware components for candidate agent designs Each kind of candidate agent design can be equipped with a collection of six kinds of radio receivers (RXs) and transmitters (TXs): target signal receivers, ‘‘follow’’ broadcast receivers, ‘‘proximity’’ broadcast receivers, jammers, ‘‘follow’’ broadcast transmitters, and ‘‘proximity’’ broadcast transmitters. Each kind of RX or TX comes in several varieties, each with an associated, simulated radiation pattern and range, power consumption, cost, and weight. As expected, RXs and TXs with long-range and broad radiation patterns consume more power, weigh more, and cost more than those with short-range performance. This information is relevant to sizing and costing each kind of agent’s powerplant and airframe. At this point in our research we use fictitious specifications for RXs and TXs. As we progress, we will obtain catalogs and specifications for COTS components and thereby define more realistic component models. 3.3. Simulated environment and mission specification We describe the battlefield environment in which candidate MAS designs are evaluated. The same battlefield environment is simulated in each HLA federation generated and executed by the MFM.
2 If more than one case produces the same output, then a control state has been potentially discovered. Control states reduce the number of cases by collapsing like cases together. A control state allows the system to ignore signals on at least one input channel.
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
187
Some care needs to go into specifying such battlefield federations. The federation development and execution process (FEDEP) [27] provides a collection of scripts by which engineers and customers can develop federations with relatively low-risk. FEDEP plays an important role in applying our MAS design environment. Our simulated battlefield is populated by a fixed number of threats and targets which are loosely based on the ‘‘Anti-Aircraft Artillery Simulation Model version 1.0’’ [27]. This model, which is expressed using the object model template (OMT) notation, is available at the HLA website [27]. The mission of our example MAS is to jam as many targets in the battlefield as possible for the greatest duration possible with as few losses as possible, and at the least cost. A formalization of this mission is found in the utility function that evaluates each candidate MAS design. 3.4. Encoding MAS designs in chromosomes The GA approach to design optimization requires candidate designs be encoded in chromosomes. This section describes our initial encoding scheme for the example MAS application. Each MAS design consists of a set of attributes (i.e., ‘‘features’’) and a corresponding value for each attribute. A MAS design comprises the design of each kind of agent in the MAS as well as the number of each kind of agent and the initial configuration of agents. All these must be represented in chromosomes. Our example MAS candidate design chromosome uses nine bits to represent each of the three kinds of agents (27 bits), seven bits to represent the number of each kind of agent present (21 bits), and two bits to represent the initial agent flight formation (50 bits total). Thus the design space has 250 ¼ 1; 125; 899; 906; 842; 624 potential designs. The bit assignments are shown below. • Bit assignments for each kind of agent: target signal RX: 00 none 01 short-range, high-accuracy 10 medium-range, medium-accuracy 11 long-range, low-accuracy ‘‘follow’’ broadcast RX: 00 none 01 short-range 10 medium-range 11 long-range ‘‘proximity’’ broadcast RX: 0 none 1 present target jammer TX: 0 none 1 present ‘‘follow’’ broadcast TX:
188
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
00 none 01 short-range 10 medium-range 11 long-range ‘‘proximity’’ broadcast TX: 0 none 1 present • Possible numbers of each kind of agent: number of master agents: 0–127 number of supervisor agents: 0–127 number of worker agents: 0–127 • initial agent flight formation: 3 00 random 01 ‘‘V’’ 10 circular 11 triangular 3.5. Agent sizing function An agent featuring only long-range RXs and TXs will consume more power, weigh more, cost more, and require more fuel than an agent featuring only shortrange RXs and TXs (or none at all). After a chromosome for a MAS design has been generated, the rough metrics for each kind of agent’s airframe must be determined. This is a problem in airplane sizing [32]. The size of the required powerplant must be estimated. Powerplant size is a function of the sum of all RX and TX power requirements, the weight of the agent, and the required speed and altitude for the agent. Weight of an agent is a function of powerplant size (i.e., airplane sizing is an iterative process), the sum of all the RX and TX component weights, and fuel weight. The cost of an agent is a function of the costs of its RX and TX components, the cost of its powerplant, the cost of its airframe, and the cost of its fuel. 3.6. MAS design utility function The MAS design utility function measures the overall ‘‘goodness,’’ ‘‘value,’’ or ‘‘utility’’ of a design. Utility considers both mission performance as well as cost. In our application, we measure utility as the ratio of performance over cost. Utility ¼
3
Performance : Cost
This could be refined in future work by making the initial formation a design problem in its own right.
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
189
Our design environment searches for designs that possess high performance and low cost (i.e., high utility). Both performance and cost have several components as discussed below. Performance ¼
targets X i¼1
agents X DurationAgent i Flight DurationTGT i Jammed þ : DurationTGT i Operational EnduranceAgent i i¼1
The first term in the Performance equation considers the duration during which ith target (TGTi) could not perform its mission because it was being jammed by agents. This term is normalized with respect to the duration during which the target was operational (i.e., nominally from the beginning of the simulation execution until the end of the simulation execution). The second term considers the duration during which each agent was able to successfully avoid threats. It is normalized with respect to the maximum duration the agent could perform its mission before running out of fuel (i.e., its ‘‘endurance’’). Notice Performance will always be non-negative. Cost of an MAS design is the sum of the cost for all agents in the design. Cost ¼
agents X
Costagent i ;
i¼1
where Costagent i ¼
RXs X
CostRX i þ
i¼1
TXs X
CostTX i þ Costpowerplant þ Costairframe þ Costfuel :
i¼1
The first two terms in the agent cost equation represents the sum of costs of all RXs and TXs with which that agent is equipped. The third term represents the cost of the powerplant with which that agent is equipped. The fourth term represents the cost of the airframe with which that agent is equipped. The fifth term represents the cost of the fuel with which that agent is filled. Recall that agent powerplants, airframes, and fuel quantities are sized after an agent’s RXs and TXs have been selected. Candidate agent designs that are devoid of RXs and TXs have non-zero costs because they still need powerplants, airframes, and fuel. Thus Cost cannot equal zero. We believe this initial utility function represents the most important features of a mission (i.e., to jam as many targets in the battlefield as possible for the greatest duration possible with as few losses as possible) and cost. Fitness functions are similar to utility functions, but fitness functions have codomain restricted to non-negative real numbers. This restriction is imposed by the GA method. Because utility is always non-negative, our fitness function and utility function are the same.
4. Conclusions and discussions We propose a design environment for mobile, robotic, MASs targeted primarily for DoD applications. This research contributes an approach to using GAs to
190
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
support design of MASs within HLA-compliant simulations. Our approach demonstrates the synergy between GAs and HLA with respect to parallel computations in the sense that GA needs simulations to determine utility/fitness of generated designs. Because each design is independent of other designs, designs can be evaluated in parallel. HLA supports these by providing a comprehensive infrastructure for parallel and distributed simulation. Because our design environment is based on free, research, commercial, and government software components that follow the HLA specifications, commercial MAS developers will be able to easily extend our design environment to support development of new MASs. Our MAS design environment will support DoD’s simulation-based acquisition (SBA) approach to business [26]. MAS developers extending our design environment will be able to more easily evaluate and demonstrate different MAS operational concepts early in the product lifecycle. This will reduce risk and cost by identifying infeasible operational concepts before significant resources are invested in developing them further. Via integration of specialty engineering design and analysis tools, our MAS design environment provides a clearly defined framework for multi-disciplinary collaboration. As needs are discovered, we will integrate specialty engineering tools into our MAS design environment. This will enable us to work with faculty familiar with those tools and to work with them to extend their tools to operate within the HLA framework. Making specialty engineering tools HLA-compliant will open up application areas for these tools.
References [1] M. Amabili, M.K. Kwak, Vibration of circular plates on a free fluid surface: effect of surface waves, J. Sound Vib. 226 (3) (1999) 407–424. [2] A. Bergstra, J. Heering, P. Klint (Eds.), Algebraic Specification, ACM Press Frontier Series, The ACM Press in Cooperation with Addison-Wesley, Reading MA, 1989. [3] G. Booch, Object Oriented Design with Applications, The Benjamin/Cummings Publishing Company, Redwood City, CA, 1991. [4] A. Boukerche, S.K. Das, A. Fabbri, SWiMNet: A scalable parallel simulation testbed for wireless and mobile networks, Wireless Networks 7(5)(September 2001)467–486, Kluwer Academic Publishers. [5] A. Boukerche, S.K. Das, A. Fabbri, O. Yildiz, Exploiting model independence for parallel PCS network simulation, in: R. Fujimoto, S. Turner (Eds.), Proceedings of the Thirteenth Workshop on Parallel and Distributed Simulation, PADS 99, IEEE Computer Society Technical Committee on Simulation, ACM Special Interest Group on Simulation (SIGSIM), SCS, IEEE Computer Society, Los Alamitos, CA, USA, 1999, pp. 166–173. [6] S. Straßburger, On the HLA-based coupling of simulation tools, in: H. Szczerbicka (Ed.), Proceedings, Modelling and Simulation: A Tool for the Next Millennium, 13th European Simulation Multiconference 1999. ESM’99, vol. 1, San Diego, CA, USA, June 1999, pp. 45–51, Polish State Committee for Scientific Research (NETIN), Chinese Association for System Simulation, Czech and Slovak Simulation Society. [7] J.A. Carson, J. Hunter, M. Colley, V. Callaghan, J. Standeven, Object-orientated frameworks for distributed, fine-grained simulation of underwater vehicles, in: D. Al-Dabass, R. Cheng (Eds.),
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
[8] [9]
[10] [11]
[12] [13]
[14]
[15] [16] [17] [18]
[19]
[20]
[21] [22] [23]
[24]
191
Proceedings of the 4th UK Simulation Society National Conference UKSIM’99, Nottingham Trent University, Nottingham, UK, 7–9 April 1999, pp. 195–200, ISBN 0 905488 38 5. A. Cox, E. Bouchard, D. Drew, SBD system design, Concurrent Eng.-Res. Appl. 4 (1) (1996) 35–46, ISSN 1063-293X, Technomic Publishing, USA. J.S. Dahmann, R.M. Fujimoto, R.M. Weatherly, The Department of Defense high-level architecture, in: Proceedings of 1997 Winter Simulation Conference, Atlanta, Georgia, USA, 7–10 December 1997, Winter Simulation Conference Board of Directors, San Diego, CA, USA, pp. 142–149. A.M. Davis, Software Requirements: Analysis and Specification, Prentice-Hall, Englewood Cliffs, NJ, USA, 1990. E. Eberbach, S. Phoha, SAMON: communication, cooperation and learning of mobile autonomous robotic agents, in: Proceedings of the 11th International Conference on Tools with Artificial Intelligence TAI 99, Chicago, IL, USA, 9–11 November 1999, IEEE Computer Society, AAAI, Virtual Intelligence Task Force, BU-CIS Center, IEEE Computer Society, Los Alamitos, CA, USA, pp. 229–236, ISBN 0 7695 0456 6. Delores M. Etter, Smart sensor web, http://www.dtic.mil/dusdst/. Jacques Ferber, Multi-Agent Systems: An Introduction to Distributed Artificial Intelligence, Addison-Wesley, Edinburgh Gate, Harlow, Essex, CM20 2JE, England, 1999, Translated from the French Les Systemes Multi-Agents: Vers une intelligence collective. J. Fugere, F. LaBoissonniere, Y. Liang, An approach to design autonomous agents within ModSAF, in: Proceedings of 1999 IEEE International Conference on Systems, Man, and Cybernetics IEEE SMC’99, vol. 2, Tokyo, Japan, 12–15 October 1999. IEEE Systems, Man, & Cybernetics Society (SMC), Science Council of Japan (SCJ), Society of Instrumentation & Control Engineers (SICE), Robotics Society of Japan (RSJ), Japan Society for Mechanical Engineerig (JSME), IEEE, Piscataway, NJ, USA, pp. 534–539, ISBN 0 7803 5731 0. N. Halbwachs, in: Synchronous Programming of Reactive Systems, The Kluwer International Series in Engineering and Computer Science, Kluwer Academic Publishers, Dordrecht, 1993. R.C. Hofer, M.L. Loper, DIS today [distributed interactive simulation], Proc. IEEE 83 (8) (1995) 1124–1137, Special Issue on Distributed Interactive Simulation. Marc Jacobs, Cooperative control in dynamic, uncertain, adversarial environments, http:// www.onr.navy.mil/, May 2000. N.E. Karangelen, N.D.T. Hoang, Simulation based design for large complex computer based systems, in: H.W. Lawson (Ed.), Proceedings of the 1994 Tutorial and Workshop on Systems Engineering of Computer-Based Systems, Stockholm, Sweden, 24–27 May 1994, Swedish Defence Mater. Adm., IEEE Computer Society, IEEE Task Force on Computer-Based System Engineering, IEEE Computer Society Press, Los Alamitos, CA, USA, pp. 116–123, ISBN 0 8186 5715 4. M.K. Kwak, K. Denoyer, Tuning of active vibration controllers for ACTEX by genetic algorithm, in: Smart Structures and Materials 1999: Smart Structures and Integrated Systems, Proceedings of the SPIE – The International Society for Optical Engineering, Newport Beach, California, USA, SPIE, vol. 3668, 1–4 March 1999, pp. 440–449. M.K. Kwak, S. Heo, Real-time multiple-parameter tuning of PPF controllers for smart structures by genetic algorithms, in: Smart Structures and Materials 2000: Mathematics and Control in Smart Structures, Proceedings of the SPIE – The International Society for Optical Engineering, Newport Beach, California, USA, SPIE, vol. 3984, 6–9 March 2000, pp. 279–290. K.F. Man, K.S. Tang, S. Kwong, Genetic Algorithms: Concepts and Designs, Advanced Textbooks in Control and Signal Processing, Springer, London, 1999, ISBN: 1852330724 (alk. paper). J. Mitchell, R. Viswanathan, Standard ML-NJ weak polymorphism and imperative constructs, Inf. Computation 127 (2) (1996) 102–116. M.K. Kwak, T.-S. Shin, Real-time automatic tuning of vibration controllers for smart structures by genetic algorithm, in: Smart Structures and Materials 1999: Mathematics and Control in Smart Structures, Proceedings of the SPIE – The International Society for Optical Engineering, Newport Beach, CA, USA, SPIE, vol. 3667, 1–4 March 1999, pp. 679–690. Federation of American Scientists, Future combat system, http://www.fas.org/man/dod-101/sys/land/ fcs.htm.
192
S.K. Das, A.A. Reyes / Simulation Practice and Theory 9 (2002) 167–192
[25] US Department of Defense, ModSAF (modular, semi-automated forces), http://www.modsaf.org/ publicmodsaf1.html. [26] Department of the Navy Acquisition Reform Office, Simulation-based acquisition, http://www.acqref.navy.mil/sba/. [27] Defense Modeling & Simulation Office, Modeling and simulation high-level architecture, http:// hla.dmso.mil/. [28] P. Proctor, USAF eyes LOCAAS as F-22 munition, Aviat. Week Space Technol. 146 (1997) 54–55. [29] M.W. Roeckel, R.H. Rivoir, R.E. Gibson, S.P. Linder, Simulation environments for the design and test of an intelligent controller for autonomous underwater vehicles, in: P.A. Farrington, H. Black Nembhard, D.T. Sturrock, G.W. Evans (Eds.), Proceedings of 1999 Winter Conference on Simulation WSC’99 Simulation – A Bridge to the Future, Phoenix, AZ, USA, IEEE, Piscataway, NJ, USA, 5–8 December 1999. [30] B.A. Shirazi, J. Marquis, A scheduling tool for parallel and distributed systems, in: Proceedings, 1996 IEEE Aerospace Applications Conference, Aspen, Colorado, USA, vol. 3, IEEE Aerospace and Electronics Systems Society, 3–10 February 1996, pp. 247–259. [31] Thomas D. Rethard Jr., Arthur Alexander Reyes, FDDL: A graphical functional design decomposition language, submitted to Proceedings of the 24th International Conference on Software Engineering, Buenos Aires, Argentina, 19–25 May 2002, ACM SIGSOFT, IEEE-CS. [32] Egbert Torenbeek, Synthesis of Subsonic Airplane Design: an Introduction to the Preliminary Design, of Subsonic General Aviation and Transport Aircraft, with Emphasis on Layout, Aerodynamic Design, Propulsion, and Performance, Delft University Press, The Hague: Nijhoff; Hingham, MA: Distributors for the US and Canada, Kluwer Boston, 1982. ISBN: 9024727243, with a foreword by H. Wittenberg. [33] J.D. Ullman, Elements of ML Programming, An Alan R. Apt Book, ML97 ed., Prentice-Hall, Upper Saddle River, NJ, 1998. [34] G. Weiss (Ed.), Multiagent Systems: A Modern Approach to Distributed Artificial Intelligence, The MIT Press, Cambridge, MA, 1999. [35] G.G. Yen, M.K. Kwak, Dynamic modeling of flexible multibody structures, IEEE Transactions on Aerospace and Electronic Systems 35 (1) (1999) 148–156. [36] B.P. Zeigler, S.B. Hall, H.S. Sarjoughian, Exploiting HLA and DEVS to promote interoperability and reuse in Lockheed’s corporate environment, Simulation 73 (5) (1999) 288–295, published by Simulation Councils, USA.