Performance Modeling of the Advanced Field Artillery Tactical Data System John R. James, Dan Ragsdale, Joseph Schafer, Tim Presby = ABSTRACT: Planning of complex activities is a deliberative process and automation support for re-planning activities should provide for cognitive modeling of the planning process. One approach for modeling military planning systems is to partition the process into separable components and analyze the components individually. This paper takes the position that the cognitive model should contain details of the domain being supported and, especially for support of on-line replanning, knowledge of the system implementation architecture – including performance modeling of the implementation architecture. A possible issue is the failure of the separable components assumption when the system is composed of components (i.e. components are not separable when the inputs to system components are affected by the outputs of the components). We discuss these thoughts in some detail and provide an overview of a test bed framework being implemented to perform experiments on the validity of this approach. In particular, we are interested in creating analysis tools that apply metrics to sensed data to assist in determining when a re-planning activity is required and in prioritizing re-planning activities. The framework is intended to support experiments with military decision making and, in particular, with re-planning activities that support execution of a military Operation Order (OPORD). We are investigating use of a new simulation tool to accumulate information at the message-packet-level and perform analysis at the networkapplication-level. We discuss use of this framework for pattern recognition of activities distributed in time and space. We provide an introduction to our approach for partitioning the problem space and some ideas on design of experiments using this approach. Finally, we assert that this level of detail is required to enable assessment of the information assurance situation to support evaluation of risks, as well as implementation and application of metrics for analysis of alternatives for reacting to attacks and monitoring of the selected alternatives. KEY WORDS: problem partitioning, distributed computing, metrics, performance modeling, latency, cognitive modeling, pattern recognition
I. INTRODUCTION Information Operations is a new area of responsibility for military units and a new area of interest for military All of the authors are with the Information Technology and Operations Center, Department of Electrical Engineering and Computer Science, United States Military Academy, West Point, New York 10996. Phone: (845) 938-5563; email:
[email protected]. The views expressed herein are those of the authors and do not purport to reflect the position of the United States Military Academy, the Department of the Army, or the Department of Defense
institutions. This interest is motivated by the realization that increased reliance on benefits accrued from expanded use of information system technologies creates both opportunities for offensive information operations capabilities and vulnerabilities for defensive information operations capabilities. Commercial enterprises face similar opportunities/vulnerabilities in the electronic commerce area. Information Operations are characterized by the wide range of target/defended system dynamics as well as by the increased complexity of interaction of system components. Before automated support can be provided to detect and react to information assurance attacks, some model of the system is needed to support detection of attack situations, analysis of response options, and execution of selected responses. A current approach for large-scale system modeling assumes that the system can be decomposed into a set of components that are systems in their own right so that the system being studied can be analyzed as a composed System of Systems (SoS). Military operations rely upon structured planning and replanning processes that produce a series of products that support comparison of current system state to estimates of “normal” system state. Among these products are: the Task Organization (which provides relations among Task Force (TF) elements), the Signal Annex (which provides relations between System Architecture hardware and software components), and the synchronization matrix (which relates expected unit activities to execution of key events in support of realization of the commander’s concept of the operation). Unit movements and engagement operations are continuous and occur on different time and spatial scales but are normally approximated as a series of discrete events. This paper presents a novel view of the information assurance modeling problem as one where detection of anomalous SoS behaviors should be viewed as a mixedsignal system identification problem where some of the system components contain feedback loops. The term mixed-signal refers to the fact that some system components can be modeled using discrete-event models while other components are appropriately modeled using continuous models. The detection problem is then to produce an estimate of the state of the system by analyzing signals from available sensors that sample the state of discrete and continuous components. Many control system engineers would not consider such a view as particularly novel, particularly those who have been involved in the hybrid-system efforts of the past ten years where this problem has been studied in detail for control
system problems. However, system engineers of military command and control systems normally model command and control systems using discrete-event models only. The validity of these approaches depends upon the assumption that any continuous aspect of the problem can be adequately approximated by discrete-event models. This paper argues that a better and more useful model of information assurance problems can be constructed by employing a control systems view of the composed SoS. This paper also provides an overview of tools and techniques that are being incorporated into the design of a test bed that applies this view. II. ORGANIZATION
consider the components of the problem domain models and architectures as containing feedback loops. III. FIRE SUPPORT PLANNING PROBLEM An analysis framework for performance modeling of the fire support process must be capable of capturing the military decision-making process that begins with receipt of a mission and continues through each of the following four planning stages: analysis of alternative courses of action to accomplish the mission, generation an operations plan to execute the chosen course of action, monitoring the execution of the plan, and re-planning, as necessary [21-23, 42-45]. For Army operations, the timeliness [20] of Battlefield Functional Area (BFA) activities is dynamically determined using a synchronization matrix that is produced during the military decision-making process (MDMP) [27]. An important aspect of the planning and re-planning process is that it occurs at multiple levels simultaneously (see Figure 1) and is centered on the concept of the operation. This concept reflects the movement of forces and coordination of the various BFA activities (armored and light infantry maneuver, fire support, air defense, logistics, …) to accomplish the overall mission.
This paper presents two related notions: (1) high-level, relatively slow, decision support systems can benefit from treating (i.e. modeling and identifying) feedback control properties of relatively fast system processes, and (2) Automation support for planning and re-planning activities should explicitly consider the relative “time constants” of similar processes at different echelons (i.e. fire support planning at Battalion level is completed much faster than fire support planning at Corps level). The paper will (1) assert that the fire support planning problem is a “system Commander Staff of systems” problem and Staff Actions Actions that contains feedback loops, (2) Receive Mission Feed discuss conditions back for partitioning the to Discuss Higher problem into Staff Mission separable Guidance From components, (3) Higher Staff indicate some timesensitive activities Prepare Staff Estimates Staff whose Commander's Estimate Estimates synchronization requires explicit Develop Guidance Alternative consideration of to Preferred and Other Courses of Action Subord feedback loops, and Alternatives Staff (4) discuss ideas on a test bed framework Feed back Selected Course for conducting Prepare From of Action Subord Plan/Order experiments to Staff investigate performance
Commander Actions
Guidance/ Warning Order From Higher CDR
Feed back to Higher CDR
Analyze Mission/ Restate Mission/ Prepare Guidance
Coordinate
Prepare Commander's Estimate Guidance/ Warning Order to Subord CDR
Decide on Courses of Action
Feed back From Subord CDR
Control Plan
Direct
Execution
modeling of fire support Figure 1. Multiple levels of abstraction of force-level control processes. Use of reference architectures for component-based design and analysis of Following the reasoning presented in [21] the partitioning large-scale systems has become fairly widespread. of the overall system into smaller system components is Considering major system components as systems in their assumed to require consideration of feedback loops present own right has led to the characterization of their in system processes. This is not a new position. Indeed, the composition into the implementation architecture of the component aggregation and disaggregation problem has overall system as the “system-of-systems” problem. The been repeatedly studied [2, 3, 4, 11, 15]. A good summary approach taken here is to consider the fire support planning is found in [39]. Furthermore, the problem domain of at problem as a “system-of-systems” problem and also to least one of the system components (e.g. the target engagement problem or the quality-of-service-based
bandwidth allocation/reallocation problem) is usually assumed to be a “mixed-signal” problem. The automation support for the United States Army is being implemented in accordance with a fully specified enterprise architecture [8]. The Army Enterprise Architecture (see Figure 2) is envisioned as being incrementally implemented as the requirements contained in the operational architecture are met through the fielding of the hardware and software of the system architecture that is constructed in accordance with the constraints of the technical architecture. Operational Architecture (OA) is the total aggregation of missions, functions, tasks, information requirements, and business rules
Operational Architecture
Technical Architecture
Technical Architecture is the “building codes” upon which systems are based
Joint Interoperability
Systems Architecture is the physical implementation of the OA, the layout and relationship of systems and communications
System s Architecture
Figure 2. Army Enterprise Architecture The first digitized division (FDD) is just now being formed and, over time, the Army will become increasingly more dependent on the proper operation of the local area networks (LANs) present in the Tactical Operation Centers (TOCs) at the different echelons of command. Within a digitized division the planning processes summarized in Figure 1 are being supported by several Battlefield Functional Area (BFA) automation systems which enable planning and execution activities for armored and light infantry maneuver, fire support, air defense, logistics and other battlefield operating systems. The central element for coordination among the BFAs is the Joint Common Data Base (JCDB). The JCDB will be the mechanism for sharing data at each echelon with the BFA systems individually updating the corresponding systems at each echelon (See Figure 3)[40].
JCDB Data Distribution CORPS BFA BFA
REPLICATE/
REPLICATE/
BFA
BFA DISTRIBUTE
JCDB
DISTRIBUTE
REPLICATE/ DISTRIBUTE
DIVISION BFABFA
BFA BFA
REPLICATE/
REPLICATE/ DISTRIBUTE
JCDB
DISTRIBUTE
BRIGADE BFA BFA
REPLICATE/
REPLICATE/
BFA
BFA DISTRIBUTE
JCDB
DISTRIBUTE
• BFA Systems Replicate/Distribute vertically • JCDB Populated horizontally at each echelon by BFAs
BATTALION BFABFA
REPLICATE/
BFA DISTRIBUTE
REPLICATE/
JCDB
BFA
DISTRIBUTE
Figure 3. JCDB Data Distribution The implementation of the different system architectures for battalion, brigade, and division levels is just now being accomplished for the first digitized division (FDD) and integration of systems at the Corps level and with other
divisions will follow. The methodologies for integration of the system components into the different system architectures will be implemented using the Defense Information Infrastructure Common Operating Environment (DII COE). Different Command and Control architectures (particularly the networked, distributed architecture versus an autonomous architecture or a centrally-controlled architecture) for the air defense engagement problem are compared in [12]. The need to explicitly model system communication components in [12] is certainly different than many large-scale systems modeling efforts. This explicit modeling was driven by the interactions of the system components in the feedback loops of the engagement processes. Moreover, the range of system dynamics, together with explicit support for adapting goals and methods of the higher-level control plan is not the problem normally encountered in mixed-signal control analysis and design. For an analysis framework, prudent resource management (as well as practical engineering concerns) requires that minimal required effort be expended to achieve “closeenough” models of system dynamics, similar to the philosophy of Professor Lotfi Zadeh’s soft-computing effort [24]. A major hurdle in such an endeavor to reactively determine what is “close enough” is to determine what is “timely enough”. In this regard, the ideas of E. Douglas Jensen [20] concerning “soft-real-time” system analysis as a necessary compliment to “hard-real-time” analysis are especially appropriate. IV. PARTITIONING THE FIRE SUPPORT PROBLEM INTO SEPARABLE COMPONENTS Performance modeling of the Field Artillery Tactical Data System (AFATDS) requires understanding of the integration of the execution of the joint force concept of maneuver with the execution of the calls for supporting fire that assist the individual unit maneuvers. Identification of the major components of such a large-scale, distributed system is a daunting task. Fortunately, the Army has evolved the system to be supported over many decades of field experimentation with Army task forces and with joint and combined task forces composed of other service components (i.e. Marines, Air Force and Navy) and other nations components. The major Army automation system components are the BFA systems and the synchronization of the operation of the automation components has been greatly simplified by breaking the overall problem down into synchronization of the BFA sub-problems. This toplevel problem decomposition and solution synthesis is achieved during the planning process by construction of the synchronization matrix and, for fire support planning, through construction of the execution matrix. Thus, for resolution of questions relating to the separability of components we focus on the issues relating to when the output(s) of components affect the input(s) of other components in the feedback loops that exist in the fire support decision processes.
For example, commanders and staffs usually apply the 1/32/3s rule of time allocation in which a given echelon takes a maximum of 1/3 of the estimated time remaining prior to commencing execution of a task in order to complete their planning activities and allocate a minimum of 2/3s of the estimated time remaining prior to commencing execution of a task to subordinate echelons in order for them to complete their planning activities. Violations of this rule, while not necessarily leading to planning disconnects between echelons, are candidates for analysis. Similarly, Figure 3 indicates that the JCDB is updated by echelon from Battalion level through Brigade and Division levels to Corps level. In general one would expect that the timeliness of decisions at battalion level, where planned maneuvers are normally completed in a few hours, will be considerably shorter in duration than at Corps level, where planned maneuvers are normally completed in a few days. For example, an initial allocation of combat power through a given task organization of available units might be altered by a commander during execution to reflect changing priorities or losses due to hostile activity. The accomplishment of a reorganization process will be considerably faster at battalion level where platoons might be moved between companies than at division level where battalions might be moved between brigades. The update of the Advanced Field Artillery Tactical Data System (AFATDS) execution matrix concerning which units are to be supported for which tasks will be achieved through synchronization with the Maneuver Control System (MCS) which will update the changes to the task organization. Our identification problem is then to filter the observed signals into appropriate sets of data for the unit being analyzed and to compare known patterns for separable components to patterns observed in the data being analyzed. Metrics are needed to determine closeness of observed patterns to expected patterns. Anomalous activity is then indicated (detected) when differences exceed some userdetermined threshold. Each of the divisional system architectures will be different and will change as new equipment is introduced. As each division deploys to conduct operations, each operations order (OPORD) executed by units will comply with the operational architecture of the AEA with changes as needed to accommodate current circumstances. The technical architecture will change slowly to accommodate new technologies. Thus, the majority of the new work is to create an analytical framework for analysis of the fire support information assurance problem as a “system of systems” problem of composition of dynamical decision components that change over time. For example, consider the issues surrounding detecting and reacting to Information Operation attacks during a battalion (Task Force XXI) deliberate attack. Two documents produced either separately during the MDMP or as part of an Operations Order (OPORD) are the Task Organization and the Signal Annex. The Task Organization provides the hierarchy of units conducting the operation and the Signal Annex provides the description of the mobile, fixed, and local area-network communications used during the operation.
A test bed is being constructed that will be able to use results from simulation models such as the Corps Battle Simulation (CBS – which requires extensive user participation), Eagle (which has extensive support for generation of attrition-based simulation from a commander’s concept of the operation), and CASTFOREM (which requires extensive preparation of a scenario for high-fidelity simulation of attrition-based outcomes). Each of these simulations, and others, provide command and control message traffic (e.g. verbal reports and orders) and situational awareness data traffic (e.g. position, status and activity data) corresponding to an operational scenario. The test bed we are constructing will run as a set of applications on the Information Warfare Analysis and Research (IWAR) laboratory at the United States Military Academy (USMA) and will use a set of intelligent agents to model unit activities and detect information operation attacks. The Task Organization and Signal Annex network knowledge from simulated operations will be used to apply evaluation technologies to enable the agents to make an assessment of whether the status of the operation execution is normal (Green), somewhat abnormal (yellow), or definitely anomalous (red). For larger units, a Synchronization Matrix (Execution Matrix) is constructed in the final stages of the Military Decision Making Process (MDMP) development of Operation Orders (OPORDs) and indicates unit activities in support of executing critical phases of the Commander’s concept. The Fire Support Plan is one of the key plans that support construction of the synchronization matrix. Another planning product that is used in detailed planning of executing the concept of the operation is the Operational Schedule (OPSKED). The OPSKED and Fire Support Plan contain brevity codes that reference specific pre-planned target concentrations during key events in synchronization of phased maneuvers by maneuver elements and fire support activities by fire support elements (such as suppression of enemy activity in an objective area while engineer elements are clearing a minefield). The activities described above provide a required few “first steps” for agents to access and interpret information flowing from scenarios implemented on force-on-force, attrition-based model of combat operations. Similarly, preliminary analysis of any operation is necessary to enable agent-based detection of operations activities that are anomalous to those expected to be present in executing the commander’s concept of the operation. Additionally, analysis of the set of anomalous events to make an assessment of whether the status of the execution is normal (Green), somewhat abnormal (yellow), or definitely anomalous (red) will require the agents to have a deeper understanding of what range of deviation from “normal” is expected before the activity becomes “abnormal” or “anomalous”. For simulated activities, message delay or loss can be used to simulate IO attacks. Such results would be at the application layer level of the AEA Technical Architecture since this is the level at which message traffic occurs. To make the assessment of anomalous activity “real”, the simulated environment should be made as close as possible to the actual environment of the “system of
new capability for OPNET Modeler, the Application Characterization Environment (ACE) module. The Product Management Office, Field Artillery Tactical Data System (PM, FATDS) has provided the USMA Information Technology and Operations Center (ITOC) with an AFATDS system. The CBS/Eagle simulations, 4th ID network simulation, and JCDB system will be running on separate computers in the IWAR laboratory. OPNET has a module that implements the DMSO High Level Architecture (HLA) which supports explicit control of synchronization of distributed applications using timed events. We expect to be able to answer questions such as: “What is the data base access time for AFATDS to obtain item X from the JCDB?”, or “What is the change in the data base access time for AFATDS to obtain item X from the JCDB when change Y occurs in the network?”
systems” that makes up the Army XXI Systems Architecture. The Next Generation Performance Model (NGPM) of the Communication-Electronics Command (CECOM) Research Development and Engineering Center (RDEC) is being implemented using extensions to OPNET modules to provide the ability to model the Force XXI environment at the network level. We intend to use the NGPM to support assessments at the platform layer or network layer [9]. For example, OPNET could be used to model the Army tactical local area network (LAN) [7] or the joint task force network [25] and assess network-level attacks against command and control systems such as the Advanced Field Artillery Tactical Data System (AFATDS). The concept is summarized in Figure 5.
V. DESIGN ENVIRONMENTS FOR NONLINEAR SYSTEMS IDENTIFICATION
CBS/ Eagle
Most large, complex automation systems (e.g. finance, transportation, maintenance) are built and reliably maintained while applying an underlying assumption that each individual component is independent of all other components (i.e. the next state and output of each component depends only on the current component state and the current input to the component). However, for a large class of systems, the presence of feedback loops among sets of system components Local Remote invalidates the independence assumption for those AFATDS AFATDS coupled components and, therefore, reliable system construction requires explicit identification of process feedback loops and their use in the system development process. Also, for large systems, eventbased decisions make the models highly non-linear, Corps Battle Simulation (CBS)/Eagle provides Legend with possible emergent dynamics dependant upon realistic scenarios. A local Advanced Field Artillery choices made by humans-in-the-loop. One widely used Tactical Data System (AFATDS) is on our network. 4th ID Network: The local AFATDS uses the 4th ID network to set of nonlinear models for approximating military access critical information stored in the Joint DMSO Simulations: systems is the Lanchester-based attrition models [15] Common Data Base (JCDB) and in databases of other used for estimating battle outcomes. Although actual AFATDS systems. Connectivity and the 4th ID OPNET Simulations: warfare is considerably more nonlinear than the network are modeled using OPNET Modeler. relatively well-behaved Lanchester equations, they are, Figure 5. Test Bed Concept none-the-less, used to model the continuous-system components of most fielded event-based military systems Future command and control systems of Joint Task Forces simulations. The discussion found in [15] is an excellent (JTFs) will be a network of applications running in a summary of the challenges present in aggregation and distributed environment. These applications, such as disaggregation of military models. The problem of AFATDS, will depend upon timely distribution of data nonlinear, mixed-signal system identification occurs widely stored in the Joint Common Data Base. This project aims in control system science and engineering [1-4]. Such to create an initial capability for conducting metrics-based models can lead to chaotic system state and chaotic system experiments concerning performance of distributed response. While most applications seek to avoid the applications under a variety of operational conditions. The conditions for onset of chaos, others have discovered that test bed will leverage Army investments in Defense physical system data (especially in biological sciences) Modeling and Simulation Office (DMSO) compliant exhibit chaotic behavior. While electronics engineers simulations such as the Corps Battle Simulation (CBS) and continue to use the mixed-signal term, in the past ten years Eagle. The test bed will also use Army-developed models control engineers have began to refer to mixed-signal th of the 4 ID network and the OPNET Modeler commercial problems as hybrid systems problems [31]. network-modeling tool to achieve a capability to evaluate The web page of the IEEE Control System Society (CSS) performance characteristics of distributed applications. Technical Committee on Hybrid Dynamical Systems [50] Implementation of the test bed will depend upon use of a has links to several active research groups and also to some
Local JCDB
computer packages for modeling hybrid systems. In addition, environments at the University of California at Berkeley [3] and Georgia Tech [2] support efforts in a Software-Enabled Control (SEC) initiative funded by the US Department of Defense. The SEC sites discuss use of software-enabled control to direct autonomous air vehicles. As with other hybrid control problems, the central, enduring difficulty has remained that, while we are able to simulate the composed problem, we are unable to discover all failure modes of complex, adaptive systems whose dynamics are approximated by the composed models. We are, thus, able to reliably react to known failure modes but are unable to guarantee a controlled response to undetected failure modes. Thus, similar to the development of the flyball governor for steam engines and the electronic feedback amplifier for telephone lines, engineers have again progressed to the point of building useful and (normally) reliable systems whose performance capabilities exceed the analytical capabilities of current theoretical approaches to predict, verify and validate system performance.
[14]
[15]
[16]
[17]
[18]
[19]
[20] [21]
VI. CONCLUSION
[22]
We have presented the notion that analysis of automation support systems distributed in time and space should use models which explicitly consider the feedback loops used in military command and control systems. We also provided an overview of a test bed being constructed which will use this approach and discussed some situations in which explicit analysis of feedback loops is required.
[23] [24] [25] [26]
[27]
VII. REFERENCES [1]
[2] [3] [4]
[5] [6] [7] [8]
[9]
[10]
[11] [12]
[13]
Zadeh, L. A., “The Evolution of Systems Analysis and Control: A Personal Perspective”, IEEE Control Systems, Vol. 16, No. 3. pp. 9598, 1996. Georgia Tech Software-Enabled Control (SEC) web page: http://controls.ae.gatech.edu/projects/sec/ U. C. Berkeley Software-Enabled Control (SEC) web page: http://sec.eecs.berkeley.edu/ Xerox PARC Spatial Aggregation Language (SAL) web page: http://www.parc.xerox.com/spl/members/zhao/stanford-cs329/saldoc/index.html Headquarters, Department of the Army, FM 100-6, Information Operations, August 1996. Headquarters, Department of the Army, FM 100-5, Operations, May 1997. Headquarters, Department of the Army, FM 24-7, Tactical Local Area Network (LAN) Management, October, 1999. Office of the Director of Information Systems for Command, Control, Communications, and Computers (ODISC4), The Army Enterprise Architecture Master Plan, Vol.1, 30 September, 1997. Office of the Director of Information Systems for Command, Control, Communications, and Computers (ODISC4), Joint Technical Architecture –Army, Version 6, May 8, 2000. Defense Information Systems Agency (DISA), Defense Information Infrastructure – Common Operating Environment (DIICOE) Integration and Runtime Specification (I&RTS), Version 4, October 1999. DARPA Autonomous Information Assurance Program web page: http://web-ext2.darpa.mil/iso/IA&S/IASPIP990811Final.html James J. and R. McClain “Tools and Techniques for Evaluating Control Architecture,” Proceedings of the 1999 IEEE International Symposium on Computer Aided Control System Design, Kohala Coast-Island of , Hawaii, USA, August 22-27, 1999. Internet Security Systems, Adaptive Network Security Handbook, http://www.iss.net/.
[28]
[29]
[30]
[31]
[32]
[33] [34] [35] [36] [37] [38] [39]
[40]
Benveniste, A and K. Åström " Meeting the Challenge of Computer Science in the Industrial Application of Control: An Introductory Discussion to the Special Issue" IEEE Transactions on Automatic Control, Vol. 38,pp.1004-1010, 1993. Davis, Paul K, Aggregation, Disaggregation, and the 3:1 Rule in Ground Combat, RAND Report MR-638-AF/A/OSD, http://www.rand.org/publications/MR/MR638 Committee to Review DOD C4I Plans and Programs of the Computer Science and Telecommunications Board of the Commission on Physical Sciences, Mathematics, and Applications of the National Research Council, Realizing the Potential of C4I Fundamental Challenges, National Academy Press, Washington, D.C. 1999 Depart of Defense Instruction Number 5200.40, “DoD Information Technology Security Certification and Accreditation Process (DITSCAP)”, 30 December 1997. Troy, Eugene F., NIST-ITL, “Common Criteria: Launching The International Standard,” http://csrc.nist.gov/cc/info/cc_bulletin.htm 24 November 1998. Common Criteria for Information Technology Security Evaluation, Common Criteria Version 2.1 / ISO IS 15408 http://csrc.nist.gov/cc/ccv20/ccv2list.htm August 1999. Jensen, E. Douglas, “Real-Time for the Real World”, http://www.real-time.org/no_frames/mitre.htm JCS Publication 1, “Joint Warfare of the Armed Forces of the United States”, 10 January 1995. JCS Publication 3-0, “Doctrine for Joint Operations”, 1 February 1995. JCS Publication 5-0, “Doctrine for Planning Joint Operations”, 13 April 1995. Berkeley Initiative in Soft Computing, http://www.cs.berkeley.edu:80/projects/BISC/bisc.welcome.html Department of the Army, Field Manual FM 100-14, “Risk Management,” Washington, DC, 23 April1998. Department of the Army, Field Manual 101-4 Multiservice Procedures for Joint Task Force Information Management JTF-IM, MRCP 6-23A, NWP 3-13.1.16, AFTTP(I) 3-2.22, April 1999. Department of the Army, Field Manual FM 101-5, “Staff Organization and Operations, ” Washington, DC, June 1996 Department of the Army, Field Manual FM101-5-1. MCRP 52A, “Operational Terms and Symbols”. Washington, DC, 30 Sept 1997. Department of the Army, Field Manual FM101-5-2., “U. S. Army Report and Message Formats” Washington, DC, 5 March 1999. anonymous, “Assessing Task Force XXI (TF XXI) Digitization Section 1: Fort Hood company/battalion attack,” undated, unclassified summary. Kohn, W., John James, Anil Nerode, and Jin Lu, “MultipleAgent Hybrid Control Architecture for the Target Engagement Process (MAHCA-TEP) Technical Background, Simulation Requirements, and Engagement Model,” 25 August, 1994. Intermetrics, Inc. Technical Report delivered to Odyssey Research, Inc. under the DARPA DSSA program, administered by Dr. Norm Coleman, US Army ARDEC. MIL3 – Third Millennium Technologies, OPNET – Decision Support Software for Networks and Applications, http://www.mil3.com/ IEEE Control System Society Technical Committee on Hybrid Dynamical Systems, http://www.nd.edu/~lemmon/hybrid/index.html Modelica - A Unified Object-Oriented Language for Physical Systems Modeling http://www.dynasim.se/modelica.html VHDL-AMS, http://vhdl.org/, http://www.vhdl-ams.com/ Verilog Hardware Description Language, http://www.cadence.com System-Level Design Language, http://www.inmet.com/SLDL/ James, J. R., “Modeling Information Assurance Dynamics: An Initial Concept”, DRAFT, May, 2000. Otter, M., and F.E. Cellier (1995), Software for Modeling and Simulating Control Systems, The Control Handbook (W.S. Levine, ed.), CRC Press, Boca Raton, FL, pp.415-428. Carnevalle, Robert J., DISA DII COE Conference, 15 April 1999.
