The UTA AVL-Institutionalizing SBD in a University . · PDF fileThe UTA AVL: Institutionalizing Simulation-Based ... The table below summarizes ... 2 Develop Federation Conceptual

Reyes et al.: The UTA AVL: Institutionalizing Simulation-Based Design in a University Setting

Page 1 of 25

Department of Computer Science and Engineering University of Texas at Arlington

Arlington, TX 76019

The UTA AVL: Institutionalizing Simulation-Based Design in a University Setting

Arthur Alexander Reyes ([email protected]) Aarathi P. Narayanasamy ([email protected])

Arvind K. Ramanathan ([email protected]) Jose R. Espino ([email protected]) Vijai Mohan ([email protected])

Monica Nadkar ([email protected])

Technical Report CSE-2003-14 This report was also submitted to The Seventh IEEE International Symposium on Distributed Simulation and Real Time Applications, October 23-25, 2003, Delft, The Netherlands, http://sentosa.sas.ntu.edu.sg:8000/~dsrt2003/ .


Page 2 of 25

The UTA AVL: Institutionalizing Simulation-Based Design in a University Setting1

Arthur Alexander Reyes Aarathi P. Narayanasamy Arvind K. Ramanathan

Jose R. Espino Vijai Mohan

Monica Nadkar

Dept. of Computer Science and Engineering University of Texas at Arlington

Arlington, TX, 76019 U.S.A.

Abstract The University of Texas at Arlington Autonomous Vehicles Laboratory (AVL)

will be organized around the concept of Simulation-Based Design (SBD). SBD drives the engineering process for complex systems: models and simulations of varying fidelity, abstraction, and scope are evaluated to eliminate unfit designs as early as possible, before significant resources have been consumed developing them further. In the AVL, SBD will use simulation, emulation, and stimulation (SES) to evolve functional models and simulations into hardware/software test beds and finally into deliverable systems. Design data are organized with respect to their utility in maximizing commonality among engineering development, test and evaluation, mission development, and training. The AVL’s SBD methodology will be implemented using the DoD/IEEE High Level Architecture (HLA) infrastructure for distributed, interactive, real-time, simulation. This paper describes the organization of the AVL from the vantage points of principles, process, and tools. A companion paper describes the organization of the AVL from the vantage point of applications and curricula.

Keywords Autonomous Vehicles Laboratory remote control Autonomy SBA AVL SBD cooperative control SES COTS interoperability simulation methodology Defense Modeling and Simulation Office simulation, emulation, stimulation DMSO simulation-based acquisition Environments simulation-based design HLA UAV MAS University of Texas at Arlington multi-agent system unmanned aerial vehicles

1 Submitted to the IEEE DS-RT 2003 conference.


Page 3 of 25

1. Introduction to Simulation-Based Design 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 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 enables engineers to use simulation methods more cost-effectively than analytical methods. Simulation-supported engineering design processes are now typical. Simulation-based design (SBD) [CBD, KH] 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.

Another hope is that SBD will produce models and simulations with greater commonality and reduce redundant development of models and simulations for the needs of engineering development, test and evaluation, training, and mission development. The practical need to make models and simulations integrate across the project can give rise to conventions and standards that will further allow work to be performed in parallel over geographically-separated teams. Another important process in SBD is “simulation, emulation, and stimulation” (SES).

“Simulation” emphasizes the execution of constructive, functional models (e.g., the simulation of a flight control computer’s behavior). “Emulation” adds interpreters for embedded, compiled application software (e.g., the simulation of flight control computer hardware as it runs the operational flight program (OFP)). “Stimulation” replaces interpreters with actual flight processors running OFPs (e.g., a flight control computer box, running the OFP, is interfaced to the rest of the simulated vehicle in a laboratory set-up).

The University of Texas at Arlington (UTA) Autonomous Vehicles Laboratory (AVL) will use SES to migrate simulated unmanned aerial vehicle (UAV) subsystems out of the 100% simulated world and into the 100% real world. Along the way, intermediate AVL test beds will retain communication links with what’s left of the simulated world in which they were developed, thus easing design evolution.

SBA, SBD, and SES are important concepts with a host of practical applications. As such, they need to be institutionalized within baccalaureate engineering educational curricula. You can read about the educational context of the AVL in the companion paper [UTA AVL].

1.1. Essential Vocabulary of M&S There exist essentially three types of models and simulations: constructive,

virtual, and live.


Page 4 of 25

Constructive simulations represent systems and their employment through the use of extensive, complex mathematical and decision-based modules and statistical techniques. A constructive simulation is a computer program. The user inputs data to cause an event to occur then gets the results. For example, a military user may input data on a military unit telling it to move and to engage an enemy target. The constructive simulation determines the speed of movement, the effect of the engagement with the enemy, and any battle damage that may occur. Results can be provided digitally or visually, depending on the type of simulation used. [MSIAC]

Virtual simulations represent systems both physically and electronically. Think of a video game or a cockpit mockup used to train pilots--these are virtual simulations. [MSIAC]

Live simulations are simulated operations conducted by real operators using real equipment. Military training events using real equipment are live simulations. They are considered simulations because these events are not conducted against a live enemy. [MSIAC]

1.2. Processes vs. Tools; Development vs. Execution As shown in Table 1 “M&S Processes vs. Tools; Development vs. Execution”,

the two essential dichotomies at work in our plan for the UTA AVL are M&S development vs. M&S execution; and M&S processes vs. M&S tools. Table 1 “M&S Processes vs. Tools; Development vs. Execution”

processes tools

development FEDEP+SBDo Integration of M&S dev tools is via EAI.o Make extant models, sims, & HW HLA-compliant.

execution FEDEP+SES o Integration of M&S execution is via HLA RTI. The UTA AVL’s systems engineering process for UAVs will be based upon the

Federation Development and Execution Process (FEDEP) [FEDEP] with SBD extensions [CBD]. In other words, all engineering artifacts will be organized with respect to the need to support M&S. We want to merge simulation artifacts and engineering design artifacts to the greatest extent possible. SBD will never scale up if it requires two sets of documents and artifacts to be maintained for every project. The FEDEP is applicable to HLA federations [DFW1997], which are a kind of distributed simulation. We will talk about HLA later. The UTA AVL’s “execution” process for UAVs will be based upon the FEDEP with SES extensions [CW]. In other words, UAVs mockups, test benches, test beds, prototypes, and manufacturing will be organized to maximize synergy with M&S.


Page 5 of 25

1.3. Implementing SBD via HLA We propose to use the DoD/IEEE High Level Architecture (HLA) for Modeling

and Simulation for our distributed, interactive, real-time, hardware-in-the-loop simulation execution infrastructure. Specialized commercial, off-the-shelf (COTS) and custom simulators, such as Simulink [Simulink], and OPNET Modeler [OPNET], will interoperate over the HLA software bus (i.e., the HLA runtime infrastructure or RTI). E.g., the flight dynamics of UAVs can be accurately simulated in Simulink, while the wireless communication between the same UAV agents can be accurately simulated in OPNET simultaneously. Hence aspects of each UAV will be “federated” over a set of specialized simulators. In addition to COTS simulators, DoD contractors, laboratories, and universities have created HLA-compliant federates for a number of extant systems. These can be reused to make SBD federations richer.

2. FEDEP: The Federation Development and Execution Process

The Federation Development and Execution Process (FEDEP) is a generalized process/methodology for HLA federations. The HLA FEDEP Model and the HLA FEDEP Checklists provide a generic high-level framework that assists in defining specific tasks and activities to support the building of distributed, interactive simulations. The six-step process describes the six major steps involved in the FEDEP as a set of activities accompanied by the necessary resources. It is to be tailored to meet the needs of the project at hand. The table below summarizes the steps, activities, and artifacts of the FEDEP. Table 2 “FEDEP Steps, Activities, and Artifacts” FEDEP Step FEDEP Activity FEDEP artifact1 Define Federation Objectives 1.1 Identify Needs 1.1 needs statement

1.2 Develop Objectives 1.2.A federation objectives statement1.2.B initial planning documents

2 Develop Federation Conceptual Model 2.1 Develop Scenario 2.1 federation scenario2.2 Perform Conceptual Analysis 2.2 federation conceptual model2.3 Develop Federation Requirements 2.3.A federation requirements

2.3.B test evaluation criteria3 Design Federation 3.1 Select Federates 3.1 identified federates

3.2 Allocate Functionality 3.2 allocated federates3.3 Prepare Plan 3.3 federation development plan

4 Develop Federation 4.1 Develop FOM 4.1.A FOM4.1.B FED file

4.2 Establish Federation Agreements 4.2 scenario instance4.3 Implement Federation Modifications 4.3.A modified federates

4.3.B RTI RID file5 Integrate & Test Federation 5.1 Plan Execution 5.1.A modified RID file

5.1.B FEPW5.2 Integrate Federation 5.2 integrated federation (incl. code)5.3 Test Federation 5.3.A testing data

5.3.B tested federation6 Execute Federation & Prepare Results 6.1 Execute Federation 6.1 raw execution outputs

6.2 Process Output 6.2 derived outputs6.3 Prepare Results 6.3.A corrective actions

6.3.B user feedback6.3.C reusable products

Activities are subdivided into steps. Each step generates one or more artifacts. The steps and artifacts involved in the FEDEP are outlined below: In Define Federation Objectives, a needs statement that addresses the objectives subject to the available


Page 6 of 25

resources is documented. Eventually a detailed objectives statement is drafted along with the initial planning documents. In Develop Federation Conceptual Model, the conceptual model represents the real world problem applicable to the federations in the defined environment. It basically describes the entities and actions (without specific reference to the simulations used in the federation) that fulfill the federation objectives. Also the objectives are refined into well-defined requirements in this step. The federation scenario and test evaluation criteria documents are also generated. In Integrate and Test Federation, this step plans the execution of the federation. It establishes the interconnection between the federates and tests the federation before execution. In Execute Federation and Prepare Results, the federation is executed, output is processed, results reported/processed and reusable components of the federation are archived.

The FEDEP Model along with the FEDEP Checklists provided us with a starting outline to build the federations meeting our objectives. Because we did not have any example FEDEP artifacts to start with, we divined the structure of FEDEP documents by carefully reading the FEDEP and FEDEP Checklists.

We customized the FEDEP artifacts to cater to our objectives. As more knowledge is gained, the process will represent the best practices available for building HLA federations as it is not restrictive and allows the users to generate any necessary documentation not listed in the FEDEP to aid the development of their specific federation. So it never levies any constraints and can be catered to any kind of requirement.

3. Organization of Tools in the AVL The figure below shows the conceptual organization of tools in the AVL. Tools in

a region above depend upon tools in the adjoining region below. The foundational collection of tools supports configuration management of all development and execution configuration items. Requirements management tools allow requirements documents and models to be written, refined, traced, verified, and validated. Change management tools enable defect logging, impact evaluation, and resolution. Modeling and code generation tools help frame problems, refine solutions, and generate source code implementations for simulations as well as for embedded UAV software. Testing and SES tools support verification models, simulations, and embedded software. Project management tools help define work breakdown, tasks, and keep track of status. Project administration tools organize sets of related artifacts and manage their relationships. FEDEP tools help enforce that the extended FEDEP is followed: engineers perform the appropriate tasks at the appropriate times.


Page 7 of 25

Figure 1 “Organization of Software Tools in the AVL”

The Appendix describes tools we plan to use in the AVL to support the execution and development of HLA federations.

4. Relations between Artifacts and Tools in the AVL The table below summarizes which FEDEP artifacts will be related to which tools

in the AVL. The rows in the upper half of the table represent the FEDEP artifacts. The rows in the lower half of the table represent artifacts typically developed in systems engineering processes. Columns in the left half of the table represent tools for developing aspects of HLA federations. Columns in the right half of the table represent tools for executing HLA federations.


Page 8 of 25

Table 3 “How Artifacts are Related to Tools in the AVL” DEVELOPMENT Tools (incl some constructive non-HLA exec tools) EXECUTION Tools (constructive, virtual, live)

FEDEP artifact

Rational C

learCase

Rational C

learQuest

Rational ProjectC

onsole

Rational Adm

inistrator

FED

EP+ enactment tool

Rational R

equisitePro

DM

SO

FEPW

DM

SO O

MD

T

Rational R

ose/XD

E

OPN

ET Modeler

OneSA

F

Matlab Sim

ulink

I-Logix Rhapsody

Matlab Sim

ulink Stateflow

Matlab Sim

ulink RTW

Microsoft Visual S

tudio

AutoCAD

Microsoft Visio

Rational S

oDA

DM

SO R

TI

DM

SO FM

T

DM

SO D

CT

DM

SO FV

T

Rational TestM

anager

OPN

ET Modeler + R

TI IF

OneSA

F + RTI IF

OM

RC

Flight Sim + R

TI IF

Simulink + R

TI IF

Rhapsody + R

TI IF

OM

RC

Em

ulator + RTI IF

OM

RC

Stim

ulator + RTI IF

OM

RC

3-D R

ender+RTI I

1.1 needs statement1.2.A federation objectives statement1.2.B initial planning documents2.1 federation scenario2.2 federation conceptual model2.3.A federation requirements2.3.B test evaluation criteria3.1 identified federates3.2 allocated federates3.3 federation development plan4.1.A FOM4.1.B FED file4.2 scenario instance4.3.A modified federates4.3.B RTI RID file5.1.A modified RID file5.1.B FEPW5.2 integrated federation (incl. code)5.3.A testing data5.3.B tested federation6.1 raw execution outputs6.2 derived outputs6.3.A corrective actions6.3.B user feedback6.3.C reusable productsNon-FEDEP, Sys Eng. ArtifactsSystems Engineering Mgt. PlanEng. Aircraft DrawingsILS Support Equip. DrawingsPackaging & Handling DrawingsMaterials & Process SpecsInterface Master Tool DrawingsEngineering LayoutsProcurement Specs.Spec. Control DrawingsSource Control DrawingsEnvelope DrawingsSelected Item DrawingsStatement of Work (SOW)System Spec.Prime Item Development Spec.Critical Item Development Spec.Computer Program Config. Item Spec.Software Requirements Spec.Software Version Description Doc.Interface Control DrawingInterface Control DocumentMass Properties DataTrade Study DocumentationWork Breakdown Structure Dict.User's Manual for Fed & UAV

There are just too many kinds of artifacts shown in the table above. If simulation artifacts and systems engineering artifacts cannot be thoroughly consolidated, SBD is doomed as a concept: Contractors could be contractually obligated to generate both sets of artifacts. A research goal of the AVL is to synthesize a consolidation of FEDEP and systems engineering processes and artifacts for UAV projects in a university setting. This consolidation will result in an augmented FEDEP (which we refer to as the HLA-based systems engineering process) that addresses simulation-based acquisition, simulation/emulation/stimulation, and systems engineering needs.

5. Federation Iterations: Migrating through SES Our proposed methodology recognizes that any simulation has accuracy

limitations. During UAV design refinement, simulation accuracy limits will be reached for selected, simulated entities. When this occurs, our proposed methodology migrates the selected, simulated entities out of the HLA federation and into their corresponding


Page 9 of 25

test beds. Test beds provide greater fidelity than their corresponding simulated entities. Test beds also satisfy more subsystem requirements than simulations. Test beds remain in communication with the HLA federation via communication links. Mobile test beds use wireless communication links. Test beds “subscribe” to data published by other HLA federates (e.g., a mobile UAV test bed obtains target data from the HLA federation, because the targets have not been migrated to test beds and the UAV test bed does not feature the required sensors), just as they did when they were simulated entities. Additionally, test beds “publish” data to the HLA federation (e.g., simulated targets become aware when the location of a UAV test bed changes), just as they did when they were simulated entities.

5.1. SES and Hardware in the Loop Simulation Expensive, fragile and complex systems are hard to test. The HLA proposed

system is a combination of multiple subsystems where the output of the system is not merely the combination function of its present inputs, but instead is a function of present inputs and a combination of past inputs. The HLA test bed can also have multiple outputs and each of which is a function of several inputs. In this scenario, simulating the test bed would require an orthogonal approach and would not subscribe to the usual method of simulation and testing. The conventional simulation and testing approach would need to answer many intriguing questions and problems. In conventional software testing and simulations, breakpoints can be inserted at different point in the software and the application can be paused after each cycle to compare the obtained values with the expected values given the nature of the inputs to the system. It is however difficult to measure and quantify the output from the system based on inputs current and past which are relative to each other. It becomes increasingly difficult in our case as they devices attached to the simulator can be a HLA compliant peripheral or an actuator which can by itself have an embedded computer on it. It is not possible to stop the embedded computer on these devices to measure the output of the system based on systemic breakpoints. Additional challenges can include digital delays which can affect the output of the entire system. The approach which is best suited for simulating and testing the HLA proposed architecture is by employing Hardware in the Loop Simulation (HWIL). We describe the architecture of the HWIL and its proposed implementation in the following sections.

5.1.1. An Example Cooperative Unmanned Aerial vehicles (UAVs) will have a complicated autopilot

and navigational software built into it. The co-operative UAV’s may be designed and designated to fly together and obtain its flight goals by sharing information with each other. The typical inputs to an unmanned aerial vehicle would be the current airspeed, desired airspeed, current co-ordinates, pitch angle, angular acceleration and pitch rate. The output of such an UAV would be to deflect the flaps and move in a direction desired and communicate to the HLA its current coordinates which can further be broadcasted to each of the other co-operating UAVs in flight. The mentioned relationship between the inputs and output in this case is trivial, however its is important to note that controlling and coordinating the flight patterns of multiple HLA compliant UAV’s is a difficult and daunting task.


Page 10 of 25

Input to Simulator

Output of Simulator

The following diagram describes how an HWIL simulator can be used to obtain the required simulation and results.

Figure 2 “Block diagram of HWIL Simulator connected to Embedded HLA compliant system”

The Hardware in the loop simulator fools the embedded system into thinking that it is operating with real world inputs and outputs. In the above example, the HLA system is fooled into thinking that multiple UAV’s are in the air and are communicating. This simulation eliminates the need for complex air vehicles and expensive aircrafts which need testing. The HWIL simulator takes as input , the output of the embedded system and runs a series of computations and calculations based on the control logic that needs to be implemented and the output of the HWIL simulator is fed as input to the embedded system.

5.1.2. Architecture When designing a hardware-in-the-loop simulator, an important question is "how

much hardware do we put in the loop?" At a minimum, the embedded system's computer has to be in the loop, since its software is being tested. In many cases, however, that will not be enough. As with many design decisions in our profession, this one requires hardware versus software trade-offs. We want the embedded software to see real inputs, to "think" that it's operating in the real world, and to have the world react properly to its outputs, we have to either include or simulate any hardware that stands between the embedded system and that world. The base architecture for our simulation based HLA system is as shown below. The system starts off as a collection of required parameter outputs that we want our UAV to address –flight control, avionics, flight dynamics and radio. These parameters are called in and addressed by the RTI (Run-time infrastructure) by localizing them as federates. The federates are then regressively simulated and unit tested using HWIL and then made to work alongside several other federate modules. Each of the federate modules are then simulated and integrated and form part of a larger test bed. The federate can be thought of a single composite system which in unison with other federates achieve the objective they were created for. In the context of HLA, we design the federates as UAV model airplanes which shall function in unison to form cooperative UAV’s. We would probably need just a single model UAV and the remainder of the UAV’s are virtually simulated using HWIL, by using the output of the flying UAV.

Output of Embedded System

Input to Embedded System Embedded

HLA System

HWIL Simulator


Page 11 of 25

Target UAV radios

UAV avionics

UAV flight dyn

UAV flight ctrl

test bed/ RTI IF

RTI

Target UAV radios

UAV avionics

UAV flight dyn

UAV flight ctrl

test bed/ RTI IF

Federate (Unit) Testing

Federation (Integration) Testing

Target UAV radios

UAV avionics

UAV flight dyn

UAV flight ctrl

test bed/ RTI IF

RTI

test bed UAV

virtual UAV

virtual UAV

Target UAV radios

UAV avionics

UAV flight dyn

UAV flight ctrl

test bed/ RTI IF

RTI

UAV avionics test bed

…

Simulation, Emulation, & Stimulation

Simulation, Emulation, & Stimulation (cont.)

Figure 3 “SES-based Migration in the AVL”


Page 12 of 25

5.1.3. Design of HLA compliant Device It is important to note that to design an extant device HLA compliant we would

need to implement the device as a federate object or part of the federate which forms part of the HLA. To make a device a federate object, the device would have to implement the procedures listed in the federate ambassador. Therefore each of the state of the device would have to be implemented using the procedures of the federate ambassador. The most common states of a hardware device could be as follows

• Init (Initializing state) • getState (obtain current state) • calibrate (move from one state or correct state) • exit (shutdown)

These typically would have to be implemented using the mentioned 40 procedure calls in the federate ambassador. This would make the device part of the federate. For participating in the entire HLA architecture, each of the devices would also need to interact with the underlying RTI framework which makes the system HLA. The RTI framework consists of close to 119 procedure calls which the device needs to call for changing states, communicate with other federates in the system and coordination. The general design therefore of a single device to be HLA complaint would be as shown.

Figure 4 “Making a Device HLA-Compliant”

Hardware Device

OEM APIs

init GetStat Calibrat ……………. Shutdo

Federate Ambassador

……… RTI Ambassador

………

RTI

Procedure Calls

Procedure Calls


Page 13 of 25

The federate shall implement the 40 procedure calls in the federate ambassador and shall call procedures from the RTI ambassador.

5.2. Federation Iteration Plan The table below represents the sequence with which we will add federates to the

AVL federation over time. “+RTI IF” means “with an added RTI interface to make it HLA-compatible.” We are responsible for all such HLA-compatibility retrofits to extant simulation execution tools. At the time of this writing, the AVL’s federation is at iteration #3: We work with Lockheed Martin Aeronautics to develop a simple federation over the Internet. This exercise will reveal technical and process incompatibilities that must be solved before more sophisticated federations can be jointly developed. We plan to then integrate several simple federates obtained from universities. This will give us practical experience working with other people’s code and artifacts. Then we hope to integrate several simple federates obtained via the DMSO’s Object Model Resource Center (OMRC). This will clarify the benefits of assembling federate object models from extant parts and perhaps show us how to obtain implementations for federates advertised at the OMRC website. The federates labeled “pilot-in-the-loop” up to “ground targets” will support the AVL’s entry into the AUVSI International Student UAV Competition (described in the companion paper [UTA AVL]). The federates labeled “OneSAF” and “D’Artagnon Cognitive Architecture” will support evaluation of UAVs that are designed to cooperate with each other in a multi-agent system (MAS). The last three federates will allow us to apply SES migration for embedded flight code.


Page 14 of 25

Table 4 “AVL Federation Iteration Plan”

RTI

OPN

ET Modeler+R

TI IF

scratch-build federate with LM

Aero

simple federates from

Universities

simple federates from

OM

RC

Matlab Sim

ulink+RTI IF

pilot-in-the-loop federate

RC

TX+RTI IF

Telemetry R

X+R

TI IF

grnd tgts federate from O

MR

C

OneSAF federate

D'Artagnon C

ognative Arch. federate

simulated flight code+R

TI IF

emulate flight code in R

hapsody+RTI I

stimulate flight code in SBC

+RTI IF

123456789

101112131415

6. Related Work

6.1. 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 [CHCCS]. Because of the first environment’s poor performance, the authors chose to base the second simulation environment on HLA.

ModSAF (modular semi-automated forces) [ModSAF] is a software technology supporting distributed interactive simulation (DIS) [HL], 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-than predictable patterns to reduce their vulnerability to attack.


Page 15 of 25

The work of [FLL] uses genetic algorithms (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. In [FLL], evaluating the fitness of each candidate path occurs offline from the DIS.

6.2. Simulation-based Design of MASs Authors in [EP] and [RRGL] report on a simulation test bed supporting SBD of an

MAS to ocean sampling.

7. References [Administrator] Rational Administrator, Retrieved on May 27, 2003, from

http://www.rational.com/products/whitepapers/UCMprojectbaseline.pdf [AutoCAD] AutoCAD, Retrieved on May 27, 2003, from

http://www.fbe.unsw.edu.au/learning/autocad/cadnotes/chap1.htm [AUVSI] AUVSI Competitions, retrieved on 2003-06-01,

http://www.auvsi.org/competitions/. [AVW] Armstrong, J.R., R. Virding, C. Wikstrom, M. Williams, Concurrent

Programming in Erlang, Prentice Hall, Englewood Falls, NJ, 1995. [Brave] S. Brave, “Evolving Deterministic Finite Automata Using Cellular Encoding”,

Genetic Programming 1996: Proceedings of the First Annual Conference, The MIT Press, Cambridge, MA, 1996.

[CBD] A. Cox, E. Bouchard, D. Drew, “SBD system design”, Concurrent Engineering—Research and Applications 4 (1) (1996) 35--46, ISSN 1063-293X, Technomic Publishing, USA.

[CD] J. Clark and S. Deach, Extensible Stylesheet Language (XSL), Technical Report http://www.w3.org/TR/1998/WD-xsl-199980818, Word Wide Web Consortium, 1998.

[CHCCS] J.A. Carson and J. Hunter and M. Colley and V. Callaghan and J. Standeven, "Object-orientated frameworks for distributed, fine-grained simulation of underwater vehicles" Proceedings of 4th UK Simulation Society National Conference UKSIM'99, pages 195--200, 1999, editor D. Al-Dabass and R. Cheng, Nottingham Trent University, Nottingham, UK, 7--9 April, ISBN 0 905488 38 5.

[CW] COL Charles A. Cartwright, David K. Wallestad, Crusader Simulation Support Plan, U.S. Army/United Defense LP, November 1998, http://www.acq-ref.navy.mil/reflib/CrusaderPlan.doc .

[DCT] Data Collection Tool (DCT), Retrieved on May 27, 2003, from http://www.aegistg.com/hlaug/library/TOOL.doc

[DFW1997] J.S. Dahmann, R.M. Fujimoto, and R.M. Weatherly. "The Department of Defense high level architecture". In Proceedings of 1997 Winter Simulation Conference, pages 142-149, Atlanta, Georgia, U.S.A., 7-10 December 1997. Winter Simulation Conference Board of Directors, San Diego, California, U.S.A.

[DMSO] Department of Defense--Defense Modeling and Simulation Office, High Level Architecture Run-Time Infrastructure RTI 1.3-Next Generation Programmer’s Guide Version 5. https://www.dmso.mil/public/transition/hla/rti/.


Page 16 of 25

[EP] E. Eberbach and S. Phoha, "SAMON: communication, cooperation and learning of mobile autonomous robotic agents", Proceedings 11th International Conference on Tools with Artificial Intelligence TAI 99, pages 229--236, year 1999, Chicago, IL, U.S.A., 9--11 November, IEEE Computer Society, AAAI, Virtual Intelligence Task Force, BU-CIS Center, IEEE Computer Society, Los Alamitos, CA, U.S.A., ISBN 0 7695 0456 6.

[FEDEP] Defense Modeling and Simulation Office, High Level Architecture Federation Development and Execution Process (FEDEP) Model, Version 1.5, December 8, 1999.

[Ferber1999] 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.

[FLL] J. Fugere and F. LaBoissonniere and Y. Liang, "An approach to design autonomous agents within ModSAF", Proceedings of 1999 IEEE International Conference on Systems, Man, and Cybernetics IEEE SMC'99, pages 534--539, 1999, volume 2, Tokyo, Japan, 12--15 October, IEEE Systems, Man, and Cybernetics Society (SMC), Science Council of Japan (SCJ), Society of Instrumentation and Control Engineers (SICE), Robotics Society of Japan (RSJ), Japan Society for Mechanical Engineering (JSME), IEEE, Piscataway, NJ, U.S.A., ISBN 0 7803 5731 0.

[FMT] Federation Management Tool (FMT), Retrieved on May 27, 2003, from http://www.ecst.csuchico.edu/~hla/LectureNotes/Tools.ppt

[HL] R.C. Hofer and M.L. Loper, "DIS today [Distributed interactive simulation]", Proceedings of the IEEE, 1995, volume 83, number 8, pps. 1124--1137, August, Special Issue on Distributed Interactive Simulation.

[KH] 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.

[JCKCK] P. Johnson and W. Cronin and J. Kwiatkowski and M. Clingempeel and K. Kachejian, "Micro aerial vehicle communications architecture for urban operations", Unmanned Systems, 1997, volume 15, number 3, pages 18--22}, month Summer, annote Association for Unmanned Vehicle Systems International, U.S.A. Article also appears in RPVs Thirteenth International Conference. RPVs/UAVs. Remotely Piloted Vehicles. Univ. Bristol. 1998, pp.28/1-6. Bristol, UK.

[JMS] Johnson, Michael V. R. ; McKeon, Mark F. ; Szanto, Terence.; Simulation based acquisition: a new approach--Report of the Military Research Fellows, DSMC 1997-1998; Defense Systems Management College Press; Fort Belvoir, Va.; 1998; http://purl.access.gpo.gov/GPO/LPS10025;

[Koza] J.R. Koza, Genetic Programming: On the Programming of Computers by Means of Natural Selection, The MIT Press, Cambridge, MA, 1992.


Page 17 of 25

[LCMRSWX] Lowe, D. with Xin Chen, T. Mondor, T. Rus, N. Rynearson, B. Smith, S. Wright, and T. Xu, BizTalk Server: The Complete Reference, Osborne/McGraw-Hill, [Location], 2002.

[Matlab] Getting Started: Introduction to MATLAB 6.5, Retrieved on May 29, 2003, from MATLAB 6.5 Software Online Help

[ModSAF] U.S. Department of Defense, ModSAF: Modular, Semi-Automated Forces, http://www.modsaf.org/publicmodsaf1.html.

[MSIAC] Modeling and Simulation Information Analysis Center, A Modeling and Simulation Primer, http://www.education.dmso.mil/ms_primer.asp?a=s4&b=view&c1=272.

[NSF] Course, Curriculum, and Laboratory Improvement (CCLI) Educational Materials Development (EMD) and National Dissemination (ND) Tracks Program Solicitation, NSF 03-558, National Science Foundation, Directorate for Education and Human Resources, Division of Undergraduate Education, http://www.nsf.gov/pubs/2003/nsf03558/nsf03558.htm.

[OPNET] OPNET Technologies, Inc., OPNET Modeler, http://www.opnet.com, 2003. [PBS] Public Broadcasting Service, "Robots Alive!", episode of Alan Alda's Scientific

American Frontiers, http://www.pbs.org/saf/transcripts/transcript705.htm. [Prechelt] Lutz Prechelt, Defect classification, Section on Defect types, Retrieved on June

1, 2003, from http://www.ipd.uka.de/PSP/Dokumente/DefTyp/defecttypes.html [ProjectConsole] Rational ProjectConsole, Retrieved on May 27, 2003, from

http://www.rational.com/products/projectconsole/index.jsp [Real-Time Workshop] Real time workshop, Retrieved on May 27, 2003, from

http://www.mathworks.com/products/rtw/ [REM] A. A. Reyes, J. R. Espino, V. Mohan, “Ad Hoc Software Interfacing: Domain-

Specific Language (DSL) Toolkits Meet Enterprise Application Integration (EAI) Servers”, submitted to the 18th IEEE International Conference on Automated Software Engineering 2003.

[REMN] A. A. Reyes, J. R. Espino, V. Mohan, M. Nadkar “Ad Hoc Software Interfacing: Enterprise Application Integration (EAI) when Middleware is Overkill”, submitted to the Workshop on Architectures for Complex Application Integration (WACAI 2003) to be held at the The 27th Annual International Computer Software and Applications Conference (COMPSAC 2003), Dallas, USA, November 6, 2003.

[RRGL] M.W. Roeckel and R.H. Rivoir and R.E. Gibson and S.P. Linder, "Simulation environments for the design and test of an intelligent controller for autonomous underwater vehicles", Proceedings of 1999 Winter Conference on Simulation WSC'99: Simulation - A Bridge to the Future, 1999, editor P.A. Farrington and H. Black Nembhard and D.T. Sturrock and G.W. Evans, pages 1088--1093, volume 2, Phoenix, AZ, U.S.A., 5--8 December, IEEE, Piscataway, NJ, USA..

[RVJvG] Manfred Rosa, Jeroen Voogd, Hans Jense, and Paul van Gool, “Fidelity Requirements Specification: A Process Oriented View”, Proceedings of the 1999 Fall Simulation Interoperability Workshop, Orlando, FL, September 1999 (paper # 99F-SIW-032).

[Simulink] MATLAB Simulink, Retrieved on May 27, 2003, from http://www.mathworks.com/products/simulink/description1.jsp


Page 18 of 25

[SoDA] Rational Software Documentation Automation (SoDA), Retrieved on May 27, 2003, from http://www.rational.com/products/soda/qa.jsp

[Stateflow] MATLAB Simulink Stateflow, Retrieved on May 27, 2003 from http://www.mathworks.com/products/stateflow/description1.jsp

[Straßburger] S. Straßburger, "On the HLA-based coupling of simulation tools", appearing in Proceedings, Modelling and Simulation: A Tool for the Next Millennium. 13th European Simulation Multiconference 1999. ESM'99, pp. 45--51, 1999, H. Szczerbicka, ed., vol 1, San Diego, California, U.S.A., June, Polish State Committee for Scientific Research (NETIN), Chinese Association for System Simulation, Czech and Slovak Simulation Society.

[TestManager] Rational TestManager, Retrieved on May 27, 2003, from http://www.rational.com/products/testmanager/prodinfo.jsp

[UTA AVL] A. A. Reyes and A. Dogan, “Overview of the University of Texas at Arlington Autonomous Vehicles Laboratory”, submitted to IEEE DS-RT 2003.

[Weatherington] Dyke Weatherington, Unmanned Aerial Vehicles Roadmap 2002-2027, December 2002, Office of the Secretary of Defense (Acquisition, Technology, and Logistics), Air Warfare, http://www.acq.osd.mil/usd/uav_roadmap.pdf.

[ZHS] B.P. Zeigler, Luke] 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. Luke, lil-gp, http://www.cs.umd.edu/users/seanl/gp/patched-gp/, 1997.

8. Appendix: Tool Descriptions

8.1. Simulation Execution Tools Simulation execution tools run when an HLA federation is running. Not all

simulation execution tools use the HLA RTI. Some tools, such as Rational TestManager, will be interfaced within federates through their own interfaces with applications running within federates. Simulation execution tools reside in the Figure 1 region labeled “Testing and Simulation, Emulation, Stimulation (SES)”.

8.1.1. HLA RTI [DMSO] The Run Time Infrastructure (RTI) is the software used to support the operations

of a federation execution on the High Level Architecture (HLA). These operations or services provided besides the co-ordination and data exchange between federates during the execution is supported by the RTI. In cases of critical performance sensitive federations, the RTI Initialization Data (RID) file associated with the specific RTI implementation used in the federation is changed. The federation’s integration testing is done based on its ability to interact correctly with the RTI and exchange of data as described in the Federation Object Model (FOM). Specialized data collection tools can also be interfaced to the RTI.

8.1.2. Rational TestManager [TestManager] Rational TestManager represents a group of integrated tools that provide a

continuous tracking of progress toward the goals of the test plan. It eases test automation and is useful to uncover more defects, thereby producing high-quality software product. It


Page 19 of 25

allows useful information and metrics about the project to be available to the developers. It also improves the team communication.

8.1.3. DMSO Federation Management Tool (FMT) [FMT] FMT is used to manage federation execution and participating federates. It’s an

excellent debugging tool. It can act either as a simulation controller or a passive observant. Besides it performs the following functions:

• Understand where each participating federate is in time. • Maintain federate/federation synchronization. • Save federation status.

8.1.4. DMSO Data Collection Tool (DCT) [DCT] DCT is a flexible tool that provides the following features:

• Collects and analyses data based on reading FOM • Provides access to federation data at runtime • Provides persistent storage for the data for After Action Review (AAR) • The DCT uses a wizard-based interface to guide the user through the data

collection planning and execution phase. • It uses MS Access and MS Excel, for storing and analyzing the data. • It is available through the HLA Software Distribution Center, free of charge.

8.1.5. DMSO Federation Verification Tool (FVT) FVT assists in the integration and test phase. It verifies that the federates fulfill

their responsibilities (provided either directly or by the FEPW’s DIF files). It specifically can be used in individual federate testing or to cause reflections/interactions to be sent to the federate.

8.2. Simulation Development Tools

8.2.1. Configuration Management

8.2.1.1.Rational ClearCase Rational ClearCase is a configuration management tool. The various artifacts

involved in the development of a project like the needs, requirements, models, source code and test scripts are to be subject to tracking changes without affecting the normal schedule and working environment of the project. Rational ClearCase achieves all these and also offers version control, workspace management, process configurability and build management.

8.2.1.2.Rational ClearQuest Rational ClearCase can be used to provide status reports and aging and

distribution reports by using its query and report templates. It can be interfaced with Rational ClearCase for defect and change tracking. It involves a consistent submission, assignment, resolution and verification of artifacts.


Page 20 of 25

8.2.2. Documentation

8.2.2.1.Rational SoDA SoDA is a documentation support tool. It generates precise and compendious

documentation by automatically extracting information from the software-engineering tools (one or more) used. The documentation may include internal deliverables, end-user documents and informal documents or reports for design or code walkthroughs. Besides it also maintains consistency and reports and reflects defects and changes. And the generated document can be amended. The look and feel of the documents can be specified by the user using design templates, content and style definition rules.

8.2.3. Modeling

8.2.3.1.FEPW federation execution planner’s workbook The Federation Execution Planner’s Workbook (FEPW) is a planning tool used

during the design and development phase. It provides the execution-specific details of the federation. On completion of the workbook, a Data Interchange Format (DIF) file can be generated which can be used in other HLA applications. Intra-federation comparisons can be done besides identifying configuration changes. It basically provides a very formal and organized mechanism for describing the performance requirements and essential characteristics. The FEPW is a tool specifically developed to assist in planning federation executions: identify hardware and networking environment and specify the responsibility of each federate. It documents past federation executions.

8.2.3.2.OMDT Object Model Development Tools It is used to build new object models. It also allows the existing models or their

subsets (along with their other dependency components) to be modified. Other features include:

• Consistency checking • Syntax checking • Federation Execution Data (FED) file generation • External interfaces to commercial object model development tools • On-line users manual

8.2.3.3.Rational Rose/XDE Rational Rose is a visual modeling tool used to visualize, understand and refine

requirements and architecture of the models before implementation. It provides more scalability, flexibility and reliability to the systems. It aids in better code generation and makes team work easier. It basically implements the Unified Modeling Language (UML) to make models. XDE is designed for users of WebSphere Studio, Eclipse and Visual Studio .NET an eXtended Development Experience. Rose is best suited for all other environments not listed above.

8.2.3.4.Matlab MATLAB is a high-performance language for technical computing. Problems and

solution are mathematically denoted. It’s an interactive system used to solve technical


Page 21 of 25

problems especially matrix and vector formulations. Toolboxes (comprehensive collection of MATLAB functions), application-specific add-ons that allow the user to learn and apply specialized technology.

8.2.3.5.Matlab Simulink Simulink is an interactive and user-friendly tool for modeling, simulating and

analyzing dynamic, multi-domain systems that integrate with MATLAB enabling access of analysis and design tools. The features offered are:

• Building block diagrams • Simulation of system behavior • Evaluation of performance • Refinement of design • This tool is used to model dynamic solutions and the models developed are

hierarchical.

8.2.3.6.Matlab Simulink Stateflow Stateflow is an interactive design tool for modeling and simulating event-driven

systems. It provides a combination of graphical modeling and animated solutions for designing embedded systems containing supervisory logic. It’s based on state transition and control flow diagrams.

• Enables graphical representation of hierarchical and parallel states • Represents event-driven transition between states • Highly efficient, embeddable C code generation • Modeling support for legacy C code

8.2.3.7.Matlab Simulink RealTime Workshop (RTW) RealTime Workshop automatically generates ANSI C code from SimuLink

models. The generated programs are highly optimized, portable and are either real-time or stand alone non real-time simulations. Other features include:

• Reusability of code • Improvised interface • Code encapsulation • Generation of HTML reports and link to the Simulink model • Uses automatic pattern matching to reduce generated code size • Allows signal monitoring in real time

8.2.3.8.I-Logix Rhapsody family of Visual Modeling CASE Tools [Douglass]

It’s a UML based object-oriented analysis, design and implementation tool for embedded systems and software developers. Its salient features include:

• ROSE interface • Dynamic model/code associativity • Supports compilers and RTOS in code generation • Design level/Graphical debugging • Automatic linkage between compilations and design diagram


Page 22 of 25

Besides it also provides a host of other features and is more adequate for real-time system development than rose.

8.2.4. Requirements Management: Rational RequisitePro RequisitePro is a requirements management tool with a web interface, making the

requirements accessible in remote locations and multi-platform environments. It dynamically links the documents to a database thereby easing the organization (usually structured) and tracking of changes. It enhances the communication and management of requirements.

8.2.5. CAD: Autodesk AutoCAD AutoCAD is a general purpose, interactive computer aided drafting application

tool using which drawings can be edited or constructed. It is not capable of handling more than one drawing at a time.

8.2.6. Project Management

8.2.6.1.Rational ProjectConsole ProjectConsole automates the process of project status reporting. It maintains a

project website with a graphical dashboard based on collected data. This reduces the cost of building, updating and maintenance of a team Website besides saving the time and effort spent on status collection. It collects both standard and custom metrics. Decisions shall be a result of quantitative analysis and not on status reports. It provides better project predictability.

8.2.6.2.Rational Administrator Administrator is a tool used for creating and configuring artifacts.

8.2.6.3.Microsoft Project Microsoft Project is a tool used to create a detailed plan for projects. It also can be

used to identify, quantify, plan, assess, monitor and manage risks.

8.2.7. Process Support: HLA-Based Systems Engineering Process Tool

We plan to use the facilities of the Rational Unified Process (RUP) Toolkit to make a web-enabled process support tool for the AVL’s emerging HLA-based systems engineering process.

8.3. Interfacing Federation Development Tools Interfacing federation development tools is a problem in Enterprise application

integration (EAI) [EAI]. “Enterprise application integration may be defined as the cooperation of disparate systems and components to implement business rules in a distributed environment.” [LCMRSWX] In our case, “business rules” are parts of the HLA-based systems engineering process.


Page 23 of 25

Ad hoc software interfacing (AHSI) is a special kind of EAI. A tradeoff analysis classifies an EAI problem as an AHSI problem when middleware solutions are seen as heavy-handed. i.e., the planned EAI is not expected to become broad enough to justify the generality of a middleware solution. We have a research project in AHSI for systems engineering tools that are applicable to interfacing federation development tools as well [REM, REMN]. We suggest solving AHSI problems using Microsoft’s BizTalk Server.

BizTalk Server was created because Software businesses use different data representation for the same kinds of information. Bridging the syntactic and semantic differences requires both transformation capabilities and neutral information representations. Microsoft‘s BizTalk Server enables dissimilar applications to interoperate seamlessly using universal communication infrastructure. Extensible Markup Language (XML) is the foundation of this technology which has been approved by the World Wide Web Consortium (W3C).

The BizTalk Editor enables you to create the specifications to translate document formats to and from XML (if it is not already using this format), for each dissimilar application. Data formats, specified using the BizTalk Editor, are represented as generated XML Schema Definition (XSD) files. The BizTalk editor can also generate instances of data formats you define so you can check whether you are defining the data format correctly.

BizTalk Mapper creates XML Stylesheet Language for Transformation (XSLT) maps, which are used to transform the structure of an incoming document instance to the structure of an outgoing document instance. BizTalk Mapper uses built-in, reusable functions called “functoids” to enable more complex mappings between elements and attributes of two schemata.

BizTalk Orchestration is used to design business processes that manage overall application business logic. The tool is effectively a Visio modeling tool that provides a way for an organization to model its processes into a flowchart type drawing.

8.4. MArSHLAnd: A Tool Supporting Both Simulation Development and Execution

A multi-agent system (MAS) exhibits emergent behavior and may be composed of many sub-systems making top-down design difficult. MArSHLAnd (MAS+HLA) is a prototype for generating and testing MAS designs. It generates designs but also strives towards component reuse where the components are applications. The prototype consists of a genetic programming toolkit named lil-gp, OPNET—a COTS simulation package, and Erlang Run Time System. lil-gp and OPNET where never intended to interoperate, Erlang glue code is used to hold the components together. We present an overview of lil-gp, OPNET, and follow with an illustration of the prototypes architecture with accompanying explanation of the glue code’s functionality. Finally, future work planned for MArSHLAnd will be discussed.

OPNET Modeler [OPNET] is a mature network simulation application with a plethora of features such as protocol modeling, wireless modeling, finite state machine modeling, etc. It also supports programmatic access to functions for the creating and evaluating simulations via its External Model Access (EMA) library. EMA support for automated evaluation of the many candidate designs generated during a search of the state space and is extremely attractive when engaging in SBD.


Page 24 of 25

Lil-gp [Luke] is a C genetic programming toolkit (available at http://www.cs.umd.edu/users/seanl/gp/patched-gp/) used to facilitate the creation of genetic programming applications based on the work of [Koza]. It supports standard genetic operations (selections, crossover, mutation, etc.) as well as more advanced concepts such as automatically defined functions (ADFs) and co-evolution. The toolkit consists of a kernel and at a minimum two user defined functions. All genetic operations are the responsibility of the kernel. User defined functions evaluate and score each of the individuals in a population. The evolution of individuals terminates when a candidate with a perfect score is found or the limit on the number of generations is reached.

Figure 5: MArSHLAnd’s Inputs and Internals

Figure 5 depicts the inputs and components of MArSHLAnd. Input to MArSHLAnd takes the form user-defined functions that represent the genetic programming (GP) tree commands defined in [Brave]. lil-gp constructs an initial population of individuals composed of GP trees. The glue code is written in Erlang [AVW] and executes in ERTS. It provides a mean of transforming the proprietary data structure of an individual into a format amenable to execution in OPNET Modeler. OPNET incorporates the design, executes the simulation, and gathers statistics. The glue code transforms the statistics into a numeric score and provides score to lil-gp. The process is repeated for each individual in a generation. The next generation is created and evaluated unless a candidate with a perfect score is discovered or the limit on the number of generations is reached.

The current implementation of MArSHLAnd generates candidate designs and evaluates them, but is incomplete because it does not support HLA. We will extend MArSHLAnd to use HLA. [DasReyes] presents a methodology for generating and evaluating HLA compliant MAS. A federation is composed of a candidate design and a “federate calculate utility”. Each candidate MAS design is represented as a unique federation; if there are n candidate MAS designs, then there will be n unique federations. The n federations are evaluated in a parallel and distributed manner until the simulation terminates or all the MASs are destroyed. The top candidates are provided as input to the Design Refiner who is responsible for decided which candidates represent the most promising designs. A genetic algorithm (GA) is used to generate n new candidates and the simulation is run anew. The process continues until a design is produced that exceeds the specified utility value.

In order to enhance the approach described in the example and to obtain a generic solution, we intend to use an intermediate neutral format for data exchange. We planned to use XML for the same due to the availability of well known libraries for manipulating them. Additionally, XML has been extensively used in the industry for Enterprise


Page 25 of 25

Application Integration (EAI). Hence use of such a neutral format, suggests the need for fewer interfaces for every participating software. Context free transformation of XML to native or other XML formats can be easily accomplished using DSL techniques or by using XSLT [CD]. For example, let us consider the interoperability between software A and B where data flows from A to B. With the addition of intermediate layer, the semantic structure of the data (grammar of A’ Data) will be expressed through XSD (XML Schema Definition). Similarly another XSD that corresponds to the semantic structure of B’ input will be created. Now an XSLT will be created to map between various elements from the source XSD to destination XSD.

This mapping process is further eased by the use of graphical tools like Microsoft BizTalk Server to define the schema and transformation. BizTalk Server is accompanied with an editor used for defining and creating XSD. This also has the feature of creating XSD from a well formed XML instance. So we plan to plan to generate the XSD for both source (A) and destination’s (B) data. To specify the main transformations, we intend to use the BizTalk Mapper. Although simple transformations can be created directly using the drag and drop feature of the software, manipulated transformations are planned to be accomplished through Functoids and though traditional programming. Functoids is the programming interface for BizTalk which has the ability to interpret VBScript and Java Script. The use of graphical tools is preferred primarily due to the ease of specification and to increase maintainability. We also plan to implement some of the complex transformations by using System.XML package in the .NET framework. It should be noted that flexibility provided though programming the transformation is much higher compared to graphic tools. Hence a comparative study will also be conducted to identify the trade off between using the graphical tools for transformation and the traditional coding technique.

Documents

The UTA AVL-Institutionalizing SBD in a University . · PDF fileThe UTA AVL: Institutionalizing Simulation-Based ... The table below summarizes ... 2 Develop Federation Conceptual