onesaf testbed baseline assessment - Defense Technical ...

ADST-II-CDRL-ONESAF-9800101 MAY 8,1998

ADVANCED DISTRIBUTED

SIMULATION TECHNOLOGY II

(ADST II)

ONESAF TESTBED BASELINE ASSESSMENT

(DO #0069)

CDRL AB02

FINAL REPORT

FOR: NAWCTSD/STRICOM 12350 Research Parkway Orlando, FL 32826-3224 N61339-96-D-0002 DI-MISC-80711

BY: Lockheed Martin Corporation Lockheed Martin Information Systems ADST II P.O. Box 780217 Orlando, FL 32878-0217

Approved for public release; distribution is unlimited

UNCLASSIFIED

ÜTIC QTJAL1TY I*9PBC*BD4

19991115 095 L..

REPORT DOCUMENTATION PAGE Form Approved

OMB No. 074-0188 Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing this collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project 10704-0188), Washington, DC 20503

1. AGENCY USE ONLY (Leave blank) 2. REPORT DATE 8 May 1998

3. REPORT TYPE AND DATES COVERED final

4. TITLE AND SUBTITLE Advanced Distribution Simulation Technology II (ADST-II) Onesaf Testbed Baseline Assessment Final Report

6. AUTHOR(S)

5. FUNDING NUMBERS NS1339-96-D-0002

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

Lockheed Martin Information Systems ADST-II P.O. Box 780217 Orlando Fl 32878-0217

8. PERFORMING ORGANIZATION REPORT NUMBER

ADST-II-CDRL-ONESAF-9800101

9. SPONSORING / MONITORING AGENCY NAME(S) AND ADDRESS(ES)

NAWCTSD/STRICOM 12350 Research Parkway Orlando, FL 32328-3224

10. SPONSORING / MONITORING AGENCY REPORT NUMBER

11. SUPPLEMENTARY NOTES

12a. DISTRIBUTION / AVAILABILITY STATEMENT Approved for Public release; distribution is unlimited

12b. DISTRIBUTION CODE

13. ABSTRACT (Maximum 200 Words) During the summer of 1997, the US Army Simulation Training and Instrumentation Command (STRICOM) supported an analysis effort to study the potential architectural implications of the One Semi-Automated Forces (OneSAF) operational requirements. The OneSAF Operational Requirements Document (ORD), developed by the government's OneSAF Integrated Concept Team, defines OneSAF as a "composable, next generation CGF that can represent a full range of operations, systems, and control processes from individual combatant and platform to battalion level, with a variable level of fidelity that supports all models and simulation (M&S) domains." [1, page 1] The analysis effort [2] concluded that an evolution approach using Modular Semi- Automated Forces (ModSAF) or the Close Combat Tactical Trainer Semi-Automated Forces (CCTT SAF) would not satisfy the variety of OneSAF uses nor would it be a maintainable or extensible solution. The analysis further concluded that a new OneSAF architecture should be developed that maximized the reuse of legacy SAF development experience, concepts, design, and code at every opportunity. However, to reduce the technical risks of the architecture development, research and a thorough domain analysis should be conducted prior to this development.

14. SUBJECT TERMS ADST-II, ModSAF, simulation

15. NUMBER OF PAGES 177

16. PRICE CODE

17. SECURITY CLASSIFICATION OF REPORT UNCLAS

18. SECURITY CLASSIFICATION OF THIS PAGE

19. SECURITY CLASSIFICATION OF ABSTRACT

20. LIMITATION OF ABSTRACT

NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89) Prescribed by ANSI Std. Z39-18 298-102

ADST-II-CDRL-ONES AF-9800101 MAY 8,1998

Document Control Information

Revision Revision History Date Initial Release 04/24/98

FNL_RPT.DOC Approved for public release; distribution is unlimited

L


EXECUTIVE SUMMARY vii

1 INTRODUCTION 1

2 Problem Statement 1

2.1 Industry Background 1

2.2 OneSAF Development Strategy 2

3 Analysis Activity 3

3.1 Analysis Approach 5

3.1.1 Technical Characteristics Process 6

3.1.2 Migration Assessment Process 6

3.2 Technical Characterization 7

3.2.1 SAF Development History 8

3.2.2 Systems 9

3.2.2.1 System Architecture 9

3.2.1.2 Development Environment 16

3.2.1.3 System Performance 18

3.2.1.4 System Protocols and Standards 19

3.2.1.5 Simulation Services 23

3.2.2 Models 24

3.2.2.1 Physical Models 24

3.2.2.2 Behavior Models 28

3.2.2.3 Synthetic Natural Environment 35

3.2.3 User Control 46

3.2.3.1 General Characteristics 46

3.2.3.2 Tactical Map 46

3.2.3.3 Overlay 47

3.2.3.4 Execution Matrix 47

3.2.3.5 Triggers & Control Measures 48

3.2.3.6 Command From Simulator 49

3.2.3.7 Task Organizations and Unit Roles 49

3.2.3.8 User Interface Construction 49

FNL_RPT.DOC Approved for public release; distribution is unlimited >»


3.2.3.9 Specific Windows and Editors 50

3.2.4 High Level Architecture (HLA) 51

3.3 Migration Assessments 51

3.3.1 Behaviors Assessment 52

3.3.1.1 Behaviors Focus Group Activity 53

3.3.1.2 Behaviors Options 53

3.3.1.3 Behaviors Assessment Results 55

3.3.2 System Assessment 56

3.3.2.1 System Focus Group Activity 56

3.3.2.2 System Capabilities 57

3.3.2.3 Assumptions 57

3.3.2.4 Assessment Results 58

3.3.3 Synthetic Natural Environment Assessment 58


3.3.3.2 Assessment Highlights 58

3.3.3.3 Results 59

3.3.4 Physical Models Assessment 60

3.3.5 User Computer Interface Assessment 61

3.3.5.1 UCI Focus Group Activities 61

3.3.5.2 UCI Capabilities 62


3.3.5.4 Assessment Results 63

3.3.6 Migration Summary 63

4 Summary 64

5 References 65

6 Acronym List 66

Appendix A-SAF Behaviors A-1

Appendix B - SAF Entities B-1

Appendix C- Migration Assessments C-1

FNL_RPT.DOC Approved for public release; distribution is unlimited «v


List of Figures

FIGURE 1: ONESAF AVENUES OF APPROACH 3

FIGURE 2: DISTINGUISHING CHARACTERISTICS PROCESS 6

FIGURE 3: CAPABILITY MIGRATION ASSESSMENT PROCESS 7

FIGURE 4: MODSAF SYSTEM DIAGRAM 10

FIGURE 5: CCTT SAF SYSTEM DIAGRAM 10

FIGURE 6: CCTT SAF WS PROCESSES 12

FIGURE 7: CCTT SAF CGF PROCESSES 12

FIGURE 8: MODSAF DYNAMIC TERRAIN SYSTEM 20

FIGURE 9: PHYSICAL MODEL INVOCATION IS PERFORMED THROUGH GMI 25

FIGURE 10: BEHAVIORS MIGRATION OPTIONS 54

FIGURE 11: ONESAF TESTBED INTERFACE TO CCTT PVD 63


ADST-H-CDRL-ONESAF-9800101 MAY 8,1998

List of Tables

TABLE 1: MIGRATION CRITERIA 5

TABLE 2: ONESAF TESTBED ANALYSIS TEAM 6

TABLE 3: MODSAF PHYSICAL SLOC 15

TABLE 4: CCTT SAF PHYSICAL SLOC 15

TABLE 5: CCTT SAF AND MODSAF GMIS 26

TABLE 6: CCTT SAF AND MODSAF HULL MODELS 26

TABLE 7: CCTT SAF AND MODSAF WEAPON MODELS 26

TABLE 8: CCTT SAF AND MODSAF SENSOR MODELS 27

TABLE 9: CCTT SAF AND MODSAF DEPLOYABLES 27

TABLE 10: CCTT SAF AND MODSAF DAMAGE ASSESSMENT 27

TABLE 11: BEHAVIOR MIGRATION ASSESSMENT 56

TABLE 12: SYSTEM MIGRATION ASSESSMENT 58

TABLE 13: SNE MIGRATION ASSESSMENT 60

TABLE 14: PHYSICAL MODEL ASSESSMENT 61

TABLE 15: UCI MIGRATION ASSESSMENT 63

TABLE 16: MIGRATION ASSESSMENT ROLLUP 64

FNL_RPT.DOC Approved for public release; distribution is unlimited VI


EXECUTIVE SUMMARY

Computer Generated Forces (CGFs) are computer systems that emulate the battlefield entities and units whose tactical behaviors and decisions are either made, in part, by human operators (Semi-Automated Forces) or automated decision algorithms (Automated Forces). A number of products have been developed to support Army applications in three modeling and simulation domains: Training, Exercise, Military Operations (TEMO); Advanced Concepts and Requirements (ACR); and Research, Development and Acquisition (RDA). In January 1996, the Deputy Undersecretary of the Army (Operations Research) tasked the Army Materiel Systems Analysis Activity (AMSAA) to conduct an assessment of the various CGF systems for their application to the three domains. The primary object of this study was to assist the Army in developing an optimum investment strategy for evolving its CGF products. The assessment's results recommended that the Army develop a common CGF architecture that would address the linkage and interoperability of models and simulations.

During the summer of 1997, the US Army Simulation Training and Instrumentation Command (STRICOM) supported an analysis effort to study the potential architectural implications of the One Semi-Automated Forces (OneSAF) operational requirements. The OneSAF Operational Requirements Document (ORD), developed by the government's OneSAF Integrated Concept Team, defines OneSAF as a "composable, next generation CGF that can represent a full range of operations, systems, and control processes from individual combatant and platform to battalion level, with a variable level of fidelity that supports all models and simulation (M&S) domains." [1, page 1] The analysis effort [2] concluded that an evolution approach using Modular Semi-Automated Forces (ModSAF) or the Close Combat Tactical Trainer Semi-Automated Forces (CCTT SAF) would not satisfy the variety of OneSAF uses nor would it be a maintainable or extensible solution. The analysis further concluded that a new OneSAF architecture should be developed that maximized the reuse of legacy SAF development experience, concepts, design, and code at every opportunity. However, to reduce the technical risks of the architecture development, research and a thorough domain analysis should be conducted prior to this development.

Due to programmatic constraints the Army accepted the technical recommendation but was not able to execute the recommendation in the near term. The Army Model and Simulation Executive Council (AMSEC) directed a OneSAF development plan that focuses the near term evolution of an existing SAF system, either ModSAF or CCTT SAF. This near term OneSAF Testbed will be used to support research and development for the next generation OneSAF architecture experiments, will be extended toward providing a BBS replacement capability and will provide the training capacity currently implemented by CCTT SAF.

Starting March 1998, the US Army Simulation Training and Instrumentation Command (STRICOM) has supported a five week analysis effort to develop a recommendation of the SAF system to be used as the baseline for integrating ModSAF and CCTT SAF capabilities into a OneSAF Testbed baseline. Given the prioritization to provide the follow capabilities, this analysis recommends an integration effort starting from the ModSAF baseline:

FNL_RPT.DOC Approved for public release; distribution is unlimited vii


• A similar capacity for "Plug N Play" (i.e., extensibility) as provided by CCTT SAF and ModSAF,

• A capacity to be extended toward providing a battalion level behavior Application Program Interface (API),

• A capacity to support research and development experimentation associated with the OneSAF object architecture using current SAF capabilities,

• A breadth of modeling capability as provided by CCTT SAF and ModSAF, • A training capability as provided by CCTT SAF and ModSAF.

The recommended approach will build the OneSAF Testbed using the ModSAF architecture and models. The integration approach will include selectively re-engineering CCTT SAF models and architectural characteristics into this C language baseline and extend the ModSAF architecture through software engineering enhancements. The detailed technical characterizations for ModSAF and CCTT SAF and the detailed assessment artifacts that led to this recommendation are provided in this report.

FNL_RPT.DOC Approved for public release; distribution is unlimited via


1 INTRODUCTION Starting March 1998, the US Army Simulation Training and Instrumentation Command (STRICOM) has supported a five week analysis effort to develop a recommendation of the SAF system to be used as the baseline for integrating Modular Semi-Automated Forces (ModSAF) and Close Combat Tactical Trainer Semi-Automated Forces (CCTT SAF) capabilities into a OneSAF Testbed baseline. The OneSAF Testbed will be used for the follow activities:

• To support research and development for the next generation OneSAF architecture experiments,

• To be extended toward providing a BBS replacement capability through a Battalion level behavior API, and

• To provide the training capacity currently implemented by CCTT SAF.

The objectives of this analysis were to provide a recommendation of the SAF system to be used as a testbed baseline from which to evolve toward OneSAF and to identify the technical characteristics of both ModSAF and CCTT SAF.

This document reports the results of this OneSAF Testbed analysis effort. The organization of this report includes a description of the OneSAF problem and the interim solution known as the OneSAF Testbed in Section 2. Section 3 describes the technical characteristics of ModSAF and CCTT SAF and the results of the assessment. The complete list of behaviors and entities implemented within each system is contained in Appendices A and B, respectively. The detailed migration assessments are contained in Appendix C.

2 Problem Statement The Army has many uses for products that emulate entities and units within a synthetic tactical environment. Several systems have evolved over the past 10-15 years to support these uses. In recent years, the Army and DoD have tried to initiate a plan for encapsulating these multiple efforts into a single investment that supports these many similar requirements. This initiative has been called SAF merge and SAF Integration, among other names, but is now known as OneSAF.

2.1 Industry Background

Computer Generated Forces (CGFs) are computer systems that emulate the battlefield entities and units whose tactical behaviors and decisions are either made, in part, by human operators (Semi-Automated Forces) or automated decision algorithms (Automated Forces). A number of products have been developed to support Army applications in three modeling and simulation domains: Training, Exercise, Military Operations (TEMO); Advanced Concepts and Requirements (ACR); and Research, Development and Acquisition (RDA). In January 1996, the Deputy Undersecretary of the Army (Operations Research) tasked the Army Materiel Systems Analysis Activity (AMSAA) to conduct an assessment of the various CGF

FNL_RPT.DOC Approved for public release; distribution is unlimited 1

ADST-II-CDRL-ONES AF-9800101 MAY 8, 1998

systems for their application to the three domains. The systems considered in this analysis were the Battlefield Environment Weapon System Simulation (BEWSS), the Close Combat Tactical Trainer (CCTT) Semi-Automated Forces (SAF), the Interactive Tactical Environment Management System (ITEMS), the JANUS system, the Joint Conflict Model (JCM), the Joint Tactical Simulation (JTS), and the Modular Semi-Automated Forces (ModSAF).

The primary object of this study was to assist the Army in developing an optimum investment strategy for evolving its CGF products. The assessment's results included the recommendation for the Army to continue supporting multiple CGFs over the following five years to meet all domain requirements. Additionally, it recommended that the Army develop a common CGF architecture that would address the linkage and interoperability of models and simulations, and support Defense Advanced Research Projects Agency (DARPA) and Defense Modeling and Simulation Office (DMSO) initiatives focused on developing a common architecture.

In May 1997, the Deputy Commanding General, Training and Doctrine Command, approved the Mission Need Statement for the OneSAF model. The Integrated Concept Team (ICT), lead by AMSAA, developed the One Semi-Automated Forces (OneSAF) Operational Requirements Document (ORD) during the summer of 1997. [1]

2.2 OneSAF Development Strategy

During the summer of 1997, the US Army Simulation Training and Instrumentation Command (STRICOM) conducted an analysis effort to study the potential architectural implications of the OneSAF operational requirements. The OneSAF ORD, developed by the government's OneSAF Integrated Concept Team, defines OneSAF as a "composable, next generation CGF that can represent a full range of operations, systems, and control processes from individual combatant and platform to battalion level, with a variable level of fidelity that supports all models and simulation (M&S) domains." [1, page 1]

This OneSAF analysis effort analyzed the operational requirements of a OneSAF development that will support the TEMO; ACR; and RDA domains' uses for a Semi- Automated Forces system. The objectives of this analysis were as follows:

• Derive the OneSAF architecture characteristics from the government provided ORD, • Baseline CCTT SAF and ModSAF architectural components, models, and interfaces

for potential evolution into a OneSAF product, and • Conduct a OneSAF architecture analysis and risk assessment.

The analysis effort [2] concluded that an evolution approach using ModSAF or CCTT SAF would not satisfy the variety of OneSAF uses nor would it be a maintainable or extensible solution. The analysis further concluded that a new OneSAF architecture should be developed that maximized the reuse of legacy SAF development experience, concepts, design, and code at every opportunity. However, to reduce the technical risks of the



architecture development, research and a thorough domain analysis should be conducted prior to this development.

Figure 1: OneSAF Avenues of Approach

Due to programmatic constraints the Army accepted the technical recommendation but was not able to execute the recommendation in the near term. As illustrated in Figure 1, the Army Model and Simulation Executive Council (AMSEC) directed a OneSAF development plan that focuses on a near term evolution of an existing SAF system, either ModSAF or CCTT SAF. This interim OneSAF Testbed will satisfy the following requirements:

• Must replace ModSAF with no decrease in existing functionality and capability, • Must replace CCTT SAF internally in the CCTT system with no decrease in existing

functionality and capability, • Must be capable of providing battalion level behavior APIs which can be used by the

three Domains to further develop battalion and above level behaviors, • Must be hardware platform independent with the priority on existing CCTT SAF and

ModSAF platforms, • Must provide internal DIS/HLA interface (with respect to SAF Systems only), • Ease migration to a new, next-generation OneSAF Architecture, and • Must support the ability to add new equipment, units, behaviors, physical models,

editors, and synthetic environment representations.

3 Analysis Activity The OneSAF Testbed baseline analysis provides a technical characterization of both ModSAF and CCTT SAF capabilities and assesses migration approaches from these SAF baselines into the OneSAF Testbed baseline. This analysis included a recommendation as to which system or combinations of systems would provide the most effective baseline from which to develop the OneSAF Testbed baseline. The analysis considered the migration approach while specifically addressing the criteria in Table 1.

FNL RPT.DOC Approved for public release; distribution is unlimited


Cost Benchmark Performance Program Risk Adaptability to new Technologies and Architectures Technical Feasibility Ease of coordination and integration of multiple

developers Existing Program Impacts User control (add, modify, tailor) Infrastructure Issues Other areas as required User Interfaces Development timeline of no more than 24 months Advantages of each existing Interoperability with existing simulations baseline Disadvantages of each existing baseline

Table 1: Migration Criteria

The assessment considered the ModSAF 4.0 beta and CCTT SAF 5.1.2 baselines. The analysis team assumed that the CCTT system integration effort would be conducted after the 24-month OneSAF Testbed integration. The team also assumed that CCTT SAF and ModSAF extensions would continue during the 24-month period and that any integration of those extended capabilities into the OneSAF Testbed could be conducted after its initial development. The hardware platforms to be supported by the OneSAF Testbed are limited to SGI, SUN, PC (Linux), DEC Alpha, IBM (AIX), and Motorola (AIX). The team concluded early in the assessment that the OneSAF Testbed must be implemented only in C language (compilable in C++) in order to satisfy the portability and accessibility capability already available by ModSAF. The C++ compiler requirement will allow any further extensions or experimentation using the Testbed to be developed using Object-Oriented Programming.

The priority for the OneSAF Testbed characteristics were defined as follows:

1. A similar capacity for "Plug N Play" (i.e., extensibility) as provided by CCTT SAF and ModSAF in their identified baselines,

2. A capacity to be extended toward providing a battalion level behavior API, 3. A capacity to support research and development experimentation associated with the

OneSAF object architecture using current SAF capabilities, 4. A breadth of modeling capability as provided by CCTT SAF and ModSAF, 5. A training capability as provided by CCTT SAF and ModSAF.

This section describes the analysis approach for the OneSAF Testbed baseline assessment, describes the technical characterization of ModSAF and CCTT SAF, and summarizes the migration approach assessments.

3.1 Analysis Approach

To achieve the OneSAF Testbed analysis objectives, a set of tasks were implemented by the SAIC - Lockheed Martin team (listed in Table 1). The implemented tasks are described as follows:



Identify the distinguishing characteristics for both ModSAF and CCTT SAF, Assess the capabilities by discussing and recording those CCTT SAF and ModSAF capabilities and implementations that must be maintained in the OneSAF Testbed, Conduct a migration path assessment that identifies the alternative migration paths for each critical component of the OneSAF Testbed and evaluate the migration approach with respect to the assessment criteria.

Person Role Wesley Braudaway, Ph.D. SAIC Manager / Project Director / CGF Architect Jeff Bergenthal LM Manager / ModSAF Engineer Anthony Courtemanche SAIC ModSAF Assessment Lead Se Hung Kwak, Ph.D. LM ModSAF Engineer Michael Longtin LM ModSAF Engineer Dan Coffin LM ModSAF Engineer Mark Torpey LM ModSAF Engineer Wendy Richardson LM ModSAF Engineer Bob Burch SAIC CCTT SAF Assessment Lead Jon Watkins SAIC CCTT SAF Engineer David Blanchard SAIC CCTT SAF Engineer Gene McCulley SAIC CCTT SAF Engineer Peggy Hughley SAIC CCTT SAF Engineer

Table 2: OneSAF Testbed Analysis Team

3.1.1 Technical Characteristics Process

As illustrated in Figure 2, the analysis team identified the distinguishing characteristics and capabilities from both systems to be studied. The list of characteristics were normalized between the two systems and served to focus the technical characterization and migration assessment for a complete analysis. The complete list of characteristics were categorized into behavior, system, synthetic natural environment, physical model, and user-computer interface characteristics. The migration assessments were conducted on each of these categories.

Figure 2: Distinguishing Characteristics Process

3.1.2 Migration Assessment Process

The analysis team assessed the migration options for each category of technical characteristics using the process illustrated in Figure 3. For a particular characteristic



category, each assessment team (ModSAF and CCTT SAF teams) presented the unique characteristics and implementation approaches of their system to the other assessment team. The assessment team leads jointly developed an assessment template to be completed by each assessment team as they evaluated the migration options for integrating the other system's unique characteristics or implementation approach into their system's baseline. These templates defined how the assessment teams would evaluate the migration options from the perspective of the option's technical feasibility, integration program risk, impact to ModSAF users and developers, impact to CCTT SAF users, impact to ModSAF research activities, impact to CCTT extension efforts, adaptability to new technologies and costs relative to the alternative options. Each assessment team then determined how the characteristics and/or implementation could be migrated into their baseline. The assessment teams evaluated these migration options in terms of the criteria identified in their assessment template. The two teams then jointly reviewed the consolidated findings to reach consensus on the resulting quantification of the migration options for the particular category. After all categories were analyzed, the assessment quantification for each criterion across the categories was totaled to provide a combined assessment from which to determine a baseline recommendation.

Perform Project

Specific Populate Findings Assessment on Capabilities and

Migration

ModSAF Product Team

Whole group to populate/modify final product and finalize migration

assessment

Figure 3: Capability Migration Assessment Process

3.2 Technical Characterization

This section provides a side-by-side technical characterization of the ModSAF and CCTT SAF baselines with respect to their system level, modeling (physical, behavioral, and synthetic natural environment), and user computer interface characteristics. This characterization includes discussion about the system's Software Lines of Code (SLOC), time management techniques, behavioral representation, terrain representation, verification and validation, development language, development environment, hardware platforms, and interoperability and adaptability to other key Army and commercial systems and software. Additionally, this technical characterization describes the maintainability, portability, extensibility, reliability, availability, data collection, traceability, repeatability, flexibility, and affordability of each candidate system.



3.2.1 SAF Development History

ModSAF was designed specifically as a modular, data-driven architecture whose characteristics are based on years of lessons learned through SAF development legacy. The ModSAF architecture was specifically designed to provide all of the general capabilities needed by any entity level virtual modeling system. The ModSAF architecture was also designed to allow the easy development and integration of models that become part of the ModSAF system. The characteristics of the architecture are that it is a single-process architecture and a layered inverted architecture. That is, lower level models are not necessarily invoked though a top-down sequence of procedure calls but rather register themselves to be called based on the occurrence of particular events. To accomplish this characteristic and its data-driven programming style, the ModSAF architecture makes extensive use of particular C-language constructs, most specifically function pointers. Although the ModSAF architecture was developed with general characteristics of SAF models in mind, no explicit set of models were initially required as part the architecture design. A large and diverse development community has added models into the ModSAF architecture over time. These additions range from models developed to support a specific experiment at a US Army Battle Lab, to detailed mine/countermine models in support of the JCOS ACTD, and the environmental and dynamic terrain models in support of the STOW ACTD. This clearly demonstrates the accessibility and extensibility of the ModSAF architecture design.

CCTT SAF was designed specifically to satisfy the modeling and system requirements for the CCTT system. However, CCTT SAF's design was re-engineered using the Ada language based on the ModSAF architecture, since the CCTT SAF design occurred after the initial implementation of ModSAF. Therefore, at the high level of design CCTT SAF and ModSAF are very similar. The CCTT architecture was designed specifically to satisfy CCTT's requirements and no more because of a very short schedule requirement. Adding risk to this short development schedule was a set of challenging requirements that were not satisfied by either ModSAF or any other legacy SAF at that time. These requirements included a very large set of validated and verified combat instruction sets (CISs), a very large and densely populated terrain database, a set of dynamic environment capabilities (e.g., destructible buildings, smoke, weather effects, etc.), and very stringent performance requirements. All of these factors along with CCTT SAF's special roles within the CCTT system caused the CCTT SAF design to diverge from the ModSAF baseline.

CCTT SAF is not as extensible as ModSAF because it did not need to support as diverse a set of developers. CCTT SAF's architecture is designed as a multiple process and multiple thread architecture where the dead reckoning functionality, the network interface, and Plan View Display are separate processes to take advantage of CCTT's multiprocessor platform. CCTT SAF also shares a significant amount of common code within the CCTT software baseline for scenario initialization, terrain interoperability and system component interoperability. The specific areas where ModSAF and CCTT SAF differ are the behaviors architecture since CCTT's design was driven by a specific set of required CISs rather than a requirement to be a general behavior model development environment. Also because CCTT



SAF was designed as a robust production system using Ada, it takes advantage of the language's strong typing and encapsulation practices.

3.2.2 Systems

For the purposes of this side-by-side technical characterization of ModSAF and CCTT SAF, 'systems' will include the features present in each SAF to allow it to operate as part of a larger simulation capability. This includes both the hardware and software architecture as well as the corresponding integration of the SAF software into the surrounding systems. This also includes the development processes, the system performance capabilities, the protocols and standards guiding the system's development and use, and the core simulation services used by the simulation.

3.2.2.1 System Architecture

The system architecture comparison of each SAF includes the system configuration, exercise interface, software architecture, software structure, integration, and accessibility, as described in the following sections.

3.2.1.1.1 System Configuration Overview Both ModSAF and CCTT SAF were designed to be distributed Computer Generated Forces systems. The system approach for both systems share some similarities due to the fact that CCTT SAF was based on a re-engineering of selected approaches from an early version of ModSAF.

3.2.1.1.1.1 System Diagrams Figure 4 shows the ModSAF system. ModSAF is composed of two main executables that can be distributed in many ways. The first main executable is the SAF Station. SAF Stations are the human interface to the ModSAF system. The second main executable is the SAF Sims. The SAF Sims provide the modeling capabilities for the ModSAF entities and organizations. SAF Sims and SAF Stations communicate with each other through the use of the Persistent Object (PO) database. This is a distributed database that uses the PO Protocol (POP) to maintain the distributed database. In addition, ModSAF uses the DIS protocol or the SIMNET protocol to communicate synthetic environment physical information. The PO database communicates information between the models that is not represented in DIS or SIMNET. The PO provides command and control information for the simulation of organizations (DIS and SIMNET are oriented to the physical world). Additional executables are noted below.

• DTSim - Dynamic Terrain Simulator: Simulates the dynamic terrain protocol and standards for ModSAF.

• DTScribe - Dynamic Terrain Scribe: Provides persistence, serialization, and distribution of dynamic terrain information.

• Logger - The Logger provides the capability to log DIS or POP PDUs for later analysis or broadcast.



RTI RD - The RTI Reliable Distributor implements TCP/IP-based reliable communications for the RTI version s. Blaster - The Blaster provides the capability to broadcast large amounts of entity state PDUs for network loading testing. ModStealth, TAOS, and CFOR represent executables that are not part of ModSAF but the baseline provides interface support for these executables.

SAF Sims DTSim DTScribe ModStealth TAOS

SAF GUIs Logger RTIRD Blaster CFOR

implies using RTI-s not part of ModSAF

Figure 4: ModSAF System Diagram

Manned Modules

SAF WS

CCTT System Components

CCTT SAF components

Figure 5: CCTT SAF System Diagram

Figure 5 shows the runtime distribution structure for CCTT. CCTT has similarities to the ModSAF structure. For CCTT, the SAF WS and OC WS are equivalent to the SAF GUI and provide the human interface for the SAF operator and the OC trainee respectively. The CGF corresponds to the ModSAF SAF Sim. The CCTT system consists of other executables such

FNL RPT.DOC Approved for public release; distribution is unlimited 10


as the Manned Modules (crew cabin simulations), MCC (master control), AAR (after action review), and the DI WS (dismounted infantry trainee station). CCTT uses DIS to communicate information about the synthetic environment (once again a description of the physical characteristics ofthat world). CCTT SAF uses the SAF Entity Object Database (SEOD) as a distributed object database for communication between the workstations and the CGF simulators. The SEOD uses the CGF Protocol to communicate data changes and events for command and control information. One point of comparison between the ModSAF diagram and the CCTT diagram is that CCTT SAF exists as a integral sub-component of a larger system.

3.2.1.1.1.2Process Architecture ModSAF is configured as a single process. All processing is located in a single thread of execution. CCTT SAF is configured as a multi-process system. The following diagrams illustrate the processes in each of the CCTT SAF components.

As shown in Figure 6, the SAF WS component consists of six processes that all communicate through shared memory. The processes are described below.

• SAF WS - This is the SAF WS GUI process. It provides the control over the CGF entities and organizations.

• Comm - This is the communications model process. It provides a simulation of the SING ARS radio for simulated radio traffic.

• PVD - This is the Plan View Display process. This provides the map view of the exercise as well as the graphical overlay capabilities.

• Entity Database - This process handles the processing of remote and local entities for communication via DIS protocols. It provides an abstraction over the entity state PDUs as well as the dead reckoning algorithms.

• Network Manager - This process handles all incoming and outgoing network traffic.

• Routing - The routing process allows routes to be generated for the SAF operator without interfering with other realtime processes.

FNL_RPT.DOC Approved for public release; distribution is unlimited H

ADST-II-CDRL-ONESAF-9800101 MAY 8, 1998

PIE (radio)

SAFWS Comm PVD

\ ^

Shared Memory Routing

/ \ Entity

Database Network Manager

FDDI

Figure 6: CCTT SAF WS Processes

The CGF component consists of 3 main processes as shown in Figure 7. Two of the processes (Entity Database and Network Manager) are shared processes with the SAF WS and perform the same functions. The additional process is the CGF process. That process provides all the modeling for CCTT SAF entities and organizations.

CGF

Shared Memory

Z Entity

Database Network Manager

FDDI

Figure 7: CCTT SAF CGF Processes

3.2.1.1.2 Exercise Initiation/Management ModSAF exercise initiation and management is localized to the ModSAF executables. It has the ability to create, modify, save or load scenario files, overlay files, and minefield templates. ModSAF accepts simulation management PDUs for start/resume, stop/pause, and



restart. ModSAF uses the concept of a DIS exercise number as well as a partition number for the PO database to allow the partitioning of sets of ModSAF executables between DIS exercises and within exercises.

CCTT SAF is a sub-component of the CCTT training system. For this reason, it has an integrated approach to exercise initiation and management. In CCTT, the MCC (Master Control Console) provides a centralized capability to control all aspects of resource assignments, exercise initiation, and exercise management. CCTT SAF participates in this CCTT exercise protocol. Exercises are centrally stored in an NFS mount that is accessible to all components in the CCTT system. The MCC is responsible for the initialization of components to an exercise and the selection of the exercise to run. This information is communicated to the CCTT system components through a series of simulation management PDUs. CCTT SAF has the ability to create, modify, and delete scenario files and overlay files. The interactions with the CCTT system for starting an exercise are outlined below.

• Exercise assignment - CCTT SAF responds to the create entity and remove entity simulation management PDUs. The create entity PDU assigns the workstations and CGF simulators to a DIS exercise and initiates the system protocols for health and fault status. The remove entity PDU removes an asset from the exercise and places it in a mode to accept a new create entity PDU.

• Initialization - Exercise initialization consists of a series of PDU transmissions that are outlined below.

• Scenario Assignment - Scenario assignment is performed through the use of DIS action/response PDUs

• The first is the environmental PDU. It contains the assignment of the synthetic natural environment, weather information, time of day information, environment manager assignments, and checkpoint intervals.

• The second is the CGF specific PDU. It provides information on the assignment of a CGF to the exercise and a boss assignment. CCTT SAF uses the concept of a boss assignment from the MCC. Since the CGF collection is a peer to peer relationship (rather than a master/slave) one platform is identified as the boss to allow for singular events to be handled (such as creation of relocatables and load balancing).

• The third is the SAF specific PDU. This contains information on the boss assignment for the workstations, force side information, and the name of the exercise. The boss designation allows for one workstation to load the exercise.

• Exercise control - CCTT SAF responds to the DIS start/resume, stop/pause, and restart PDUs.

• Health status - CCTT SAF responds to periodic health status request messages from the MCC.



3.2.1.1.3 Software Architecture ModSAF is a single-process architecture. It makes extensive use of function pointers to provide a variety of capabilities as shown below.

• Callbacks - Callbacks provide ModSAF with a registration structure for assigning handlers for a variety of purposes.

• Inverted architecture - ModSAF uses callbacks to invert the architecture. This provides a mechanism for models to register their functions for various purposes such as ticking and event handling.

• Developer defined named events - A developer may create a symbolic name for an event, define when an event is triggered, and support registration of handlers for these events.

• Scheduler - Periodic and one-shot appointments are implemented as function pointers to tick handlers.

• Key technique for extensibility - ModSAF uses the registration capability and the inverted architecture to minimize affected code for new unit or model additions to the system.

ModSAF has callbacks and data driven techniques as the basis for its architecture. This is used in the Graphical User Interface design, entity configuration, network protocols, and behavioral combinations (taskframes).

CCTT is a multi-process architecture. CCTT SAF makes use of multi-process threading to allow for execution of models on the symmetric multi-processing platform used by CCTT. CCTT was written in Ada 83, but makes limited use of function pointers. These are used to implement a callback structure similar to ModSAF. This callback structure is used to allow for registration of event handlers (predefined events) and scheduler appointments (periodic and one-shot). The CCTT SAF architecture is data driven as well but not to the extent of ModSAF.

3.2.1.1.4 Software Structure ModSAF is a flat hierarchy of about 555 C software libraries. Each library contains (or may contain) a makefile, header files, C source files, data files, GUI resource files, and TeXInfo library documentation. There is a small set (about 10) of source directories containing the main program.

The CCTT SAF software library organization mirrors its design decomposition. It is divided into directories and subsystems (a Rational Apex concept). Subsystems contain the Ada packages (specifications and bodies). CCTT relied on the integrated development environment (IDE) of Apex to build the executables and did not use makefiles. The execution environment contains all the data files and GUI User Interface Language (UIL) files necessary for the execution of CCTT SAF. These are organized along the system architectural types (i.e., the system applications such as the SAF Workstation and the CGF). In CCTT SAF, there is no equivalent documentation to the ModSAF TeXInfo files.

FNL_RPT.DOC Approved for public release; distribution is unlimited I4


ModSAF SLOC is characterized in Table 3. In this table, ModSAF SLOC is measured in physical lines of code (excluding whitespace and comments), which has been a traditional code-size metric for ModSAF. CCTT SAF SLOC is characterized in Table 4. Traditionally, CCTT SAF has measured SLOC as logical lines of code (which includes only one line of code for every executable statement, no matter how many lines of text that statement spans), however this table presents physical lines of code to provide data that is easier to compare with ModSAF. Depending on the amount of multi-line statements, there will always be more physical SLOC than logical SLOC for a given piece of software.

Component SLOC

Shared 125,817

Simulation 543,965

Network 67,717

GUI 85,607

Other 99,911

Total 923,107

Component SLOC

CGF 617,549

System Services 100,626

SAF WS 31,068

Total 749,243

Table 3: ModSAF Physical SLOC Table 4: CCTT SAF Physical SLOC

3.2.1.1.5 System Integration ModSAF is integrated into numerous training, research and development environments as shown below.

• National Guard Training (interoperation through DIS) RDA studies (interoperation through DIS) BBS linkage/STOW-A SOAR CFOR DARPA STOW '97 (interoperation through DIS)

CCTT SAF software components are integrated throughout the CCTT system (as well as system components integrated into CCTT SAF).

• Network Manager • Entity Database • CGF Terrain Algorithms/Data • TOC workstation support • DIWS • PVD



In addition, the SEOD file format is the system exercise format for the CCTT system and the CGF SEOD code is shared by many CCTT components.

3.2.1.1.6 Accessibility ModSAF is distributed to a wide user base. Processes and organizations (TWSTIAC, DIS Service Center, DMSTIAC, and Nations) have been in place since 1993 that allow the easy distribution and maintenance of the baseline. CCTT SAF is just now being fielded and its distribution is handled by Nations for STRICOM. Presently, the CCTT SAF system is distributed as a sub-component of a larger distribution of the CCTT training system. The ModSAF distribution provides documentation on the build process for SAF and provides readily available build tools that support multiple hardware platforms. The CCTT SAF distribution provides well documented and scripted builds for the CCTT system of which CCTT SAF is just a component. Executables are provided as part of the distribution but to be used, the host system must be configured as a CCTT training site computer. While the automated CCTT build scripts use this configuration assumption, there is nothing inherent in the technical and resource requirements of the CCTT SAF software that limits it to only running in this mode. In fact, several research projects currently use CCTT SAF as a stand- alone system.

ModSAF and CCTT SAF are not specifically designed to provide extensive data collection. ModSAF provides data collection through the logging of DIS PDUs, special verification and validation data PDUs, and built in debug switches. CCTT SAF provides data collection through DIS event or Data Analysis Report (DAR) PDUs, the SEOD Visual Interface, and Aprobe (a real-time debugging tool that was used to support formal VV&A).

ModSAF was developed to allow extension. It relies heavily on a data driven development approach that facilitates modification. In addition, ModSAF provides naming conventions for their library structure, developer courses, and scripts to add new libraries. CCTT SAF was not designed for distributed development. As a production system, it was developed by a co-located Integrated Development Team (IDT). Since this was a large program with a short schedule, the IDT relied heavily on development tool support. CCTT SAF provides some level of data driven design, however, additions to the system rely on code changes.

3.2.1.2 Development Environment

As described in the following sections, the differences in procurement and intended use for each SAF system resulted in very different development environments.

3.2.1.2.1 Development Language and Tools ModSAF was developed in a research environment and had no restrictions on the language or development processes imposed on CCTT by DoD-STD-2167A. For this reason, ModSAF was originally developed in C. CCTT SAF was developed as a subsystem of the CCTT training system in Ada 83. The ModSAF code is being converted to be compilable by C++ compilers, but it will not use any object oriented language techniques provided by the C++ language.



The development tools for each system were a result of the development language and the intended use for each system. The ModSAF development environment was primarily distributed among many companies and organizations. As stated earlier, ModSAF was not bound to military development standards (2167A) and provided best commercial practices for its processes. ModSAF provides scripts (awk, sed, lex, etc.) and makefiles to support distributed development and experimentation. Also, to keep development costs low ModSAF makes use of the GNU (freeware) tool set. Compilation support is provided either by the operating system native UNIX C compilers or GNU gcc. To promote consistency in a distributed development environment, tools were developed to verify the documentation and programming style of ModSAF code (Interdoc and Interck). ModSAF also provides tools for the generation of task templates to further standardization of behaviors. CCTT SAF does not provide such a tool. CCTT was developed under DoD mil-standard 2167A and has the process and development environment to reflect it. CCTT used Rational Apex and OC Systems PowerAda as the compilation environment. Design and development tools consisted of StateMate, ObjectMaker, RTM, Interleaf, and CMVC. CCTT was developed in a co-located Integrated Development Team with a finite schedule and pre-specified requirements. Runtime support for ModSAF relied on UNIX and GNU through the use of the DBX and gdb debuggers. CCTT relied on Apex, PowerAda adbg, Aprobe, and the developed DIS Visual Interface tool. Analysis support for ModSAF was achieved through the use of V&V Data PDUs while CCTT used the Visual SEOD Interface tool, Map Pages and Aprobe. Aprobe, a standard tool from the PowerAda suite, provided a limited capability for data collection in support of the V&V process. Specifically, software engineers with knowledge of the CCTT SAF architecture and data flows could instrument the system, collect and interpret data.

3.2.1.2.2 Development Process As stated earlier, ModSAF relied primarily on a distributed development process. In this process, ModSAF code was distributed to many organizations who developed various capabilities as their needs required. The ModSAF baseline was centralized, procedures were established for integration of new capabilities into the baseline, and a review board considered these changes for inclusion in the official baseline. The baseline (under ADST and ADST II) was managed using RCS, CVS, and Clearcase as well as the previously mentioned development environment.

CCTT was developed in an Integrated Development Team consisting of TSM, STRICOM, Nations (IV&V), Lockheed-Martin (prime), SAIC (SAF/CGF), and ECC (manned modules). CCTT was developed under a modified evolutionary development model with 7 builds spread over 4.5 years. The developers of the IDT were co-located in the same facility and shared the development environment and lab. CCTT has been transitioned to Post Deployment Software Support (PDSS) consisting of Nations and SAIC.

3.2.1.2.3 Hardware Environment ModSAF was developed to execute on multiple platforms. Specifically, ModSAF executes on the Silicon Graphics (SGI), SUN, PC (Linux), and DEC Alpha platforms. The minimum



requirement for a ModSAF capable platform is a PC (Linux) platform costing approximately $5K. CCTT SAF was developed as a subcomponent of a larger production system and was not ported to other platforms. A CCTT SAF platform is an IBM or Motorola AIX computer system and costs approximately $8K.

3.2.1.3 System Performance

The following sections compare ModSAF and CCTT SAF in terms of capacity, scalability, user workload, and reliability.

3.2.1.3.1 Total Capacity Comparable total capacity and benchmarks are difficult to provide for these two systems. To accurately compare capacity, identical scenarios are required to be built. Currently, this is not possible given the configurations of the two systems. Specifically, ModSAF and CCTT SAF do not execute on a common system. In addition, they do not share common synthetic environments or models. The best that can be done is to characterize existing benchmarks with the realization that the numbers are not directly comparable.

ModSAF expects a processor with a minimum of 128 Mbytes of RAM with 256 Mbytes recommended for performance. ModSAF performance numbers are divided into two groups. The first group is a stand-alone capability with no remote entities or network interactions. The second group is in a network environment with 800 external entities (provided by an external program). This provides information on the interaction across DIS and does not include C2 interactions. For the stand-alone version, a 300 MHz Pentium II supports 200 vehicle simulations while a 195 MHz SGI R10000 supports 112. For the network version, the Pentium supports 132 entities while the SGI supports 80.

CCTT SAF expects a processor with a minimum of 128 Mbytes. CCTT SAF performance numbers are measured as a participant in a DIS exercise owing to the fact that CCTT SAF is a sub-component in a larger system. CCTT SAF is required to provide 25% spare processing capability with 48 vehicles per CGF simulator. This is measured in an 851 entity exercise with 201 manned modules entities and 650 CGF entities. This includes the processing required for the C2 and the interaction of up to 30 SEOD clients.

3.2.1.3.2 Scalability ModSAF currently partitions the PO Database into groups of 8 maximum participants due to scalability concerns. Each partition is initialized independently and does not share C2 information. CCTT SAF typically supports up to 30 SEOD clients and does not partition within an exercise. CCTT SAF does partition between exercises with each SEOD client belonging to only one exercise.

3.2.1.3.3 User Workload ModSAF workload was measured during certain Ft. Knox D-site experiments to be on average 40 entities per operator. There was a high variance depending on the side or activity of the entities. During the Synthetic Theater of War (STOW) project, ModSAF averaged up



to 100 entities per operator. CCTT SAF is required to support 120 entities per operator as its baseline case.

3.2.1.3.4 Reliability Army SAF (based on ModSAF) had average runs of 24 continuous hours during the STOW 97 ACTD exercise. No information presently exists on the ModSAF 4.0 baseline. CCTT SAF requirements are for 1504 hours MTBF.

3.2.1.4 System Protocols and Standards

The following sections describe the network protocols and standards used by each SAF system

3.2.1.4.1 Standards ModSAF provides support for a variety of standards for synthetic environment communication: DIS 2.0.3, DIS 2.0.4, and SIMNET. In addition, it provides support for the HLA through the use of the RTI version "s" (i.e., the version used by the DARPA STOW program). ModSAF also provides standards for bumper numbers, task organizations, appearance bits for damage, entity enumeration standards, and articulation modeling. CCTT provides support for DIS 2.0.4 and has an extensive interoperability document to support interoperation with the system. In addition, CCTT also provides standards for bumper numbers, task organizations, appearance bits for damage, entity enumeration standards and articulation modeling with CCTT specifics.

3.2.1.4.2 Dynamic Environments ModSAF provides an extensive simulation of dynamic environment inherited from the STOW development. The ModSAF baseline provides for the DTSim that assesses damage to pre-positioned and dynamic objects due to detonations (not collisions). Dynamic objects (multi-state, repolygonalized, linear, abstract and entities) supported are shown below.

Tank ditches (abstract and repolygonal) Wire (abstract and linear) Fighting positions for hull and turret defilade (abstract and repolygonal) Minefields (entities) simulated down to individual mines Lane markers (entities) Craters (abstract and repolygonal) Dragons teeth (linear, abstract, and multi-state) Rock drops (multi-state) Bridges [HAB, AVLB], buildings (multi-state)

ModSAF also provides simulations of a dynamic virtual world (DVW). The capabilities supported are shown below.

• Uniform and gridded weather • Smoke (obscurants)



Flares Vehicle dust Continuous time of day Atmospheric haze Clouds (cumulus, stratiform, ciriform) Uniform ocean surface model Total Atmospheric and ocean server interface (TAOS)

Ethernet

Figure 8: ModSAF Dynamic Terrain System

Figure 8 outlines the processes that are associated with the ModSAF dynamic terrain system. The process for changing the terrain using these services is outlined below.

• Client (a DT APP) sends Engineering Change Notice (ECN) to DTScribe • DTScribe catches ECNs and is the ECN traffic cop • DTScribe sends "fully specified ECNs" back out. • DTSim processes any parameterized ECNs, if any, such as repolygonalization

requests. If any, it resends the ECN back to the DTScribe. • DT Agents embedded in applications catch the fully specified ECNs from the

DTScribe and modify the local representations. • DTSim provides two services: repolygonalization (from parameterized ECNs) and

incidental damage assessment (i.e., from detonation PDUs), and a very trivial DT GUI

• Late joiners ask for necessary ECNs from DTScribe.

CCTT provides a simulation of dynamic terrain through the Environment Manager (EM). The MCC provides the EM site/application and IP address to all the applications in an



exercise. Typically, two EMs are added to an exercise with one EM being a hot swap for fault tolerance. The EM assesses damage to pre-positioned and re-locatable objects due to detonation (not collision). Flares are not simulated by the EM but rather simulated by the firing entity. The objects simulated by the EM are listed below. In addition, smoke is modeled only after it detaches from the vehicle.

• Minefields • Lane Markers

• Buildings . Logcribs

• Brid§es . Abatis • Tank ditches • Wire • Defilades • Fighting positions

Craters Ribbon bridges AVLB (after placement)

The CCTT EM protocol provides environmental PDUs for point objects, linear objects, and areal objects. Late joiners communicate an action/request PDU to request a rebroadcast of the current objects and their state.

ModSAF provides an extended simulation of minefields. ModSAF supports hand emplaced, mechanical, artillery, customized, and point mines. In ModSAF, minefields are simulated as collections of individual mines. ModSAF uses two DIS PDUs to model minefields: minefield PDU and mines PDU. The mine models determine mine detonations. Damage is assessed by the vehicle. CCTT models the same types of minefields but simulates them as areas and uses probabilistic models rather than modeling individual mines.

3.2.1.4.3 System Protocols CCTT SAF participates in several system protocols as a sub-component of a training system. These are outlined below.

• Reset • 48 checkpoints are saved • checkpoint interval defined by MCC • Stop/Freeze PDU (stop for reset) • Action Request PDU (recall checkpoint data #)

• DRC (Daily Readiness Check) Structure for DRC but presently not used within CCTT SAF

• BIT (Built-in-Test) Action Request PDU, Application returns OK, checked about 1 per minute.

• POST (Power-On Self Test) (AIX stores data in file) • MM Code - Return Go for Host computer only

• CCTT Error Detection, Recovery, Logging • Event Reporting: Report Exception handling sends error events

but no longer used.



3.2.1.4.4 Data Analysis and Review (DAR)

CCTT provides a protocol for system components to report data used for after action review. Data Analysis and Review (DAR) reports are sent for any firing and detonation event providing additional information not found in the standard DIS event PDUs. DAR reports are generated for minefields as a special protocol called the mine detonation event report PDU. In addition, all vehicle simulations send DAR reports for any damage events. DAR reports are also generated for mission request of indirect fire, indirect or Close Air Support (CAS) fire reports, and minefield entry events.

3.2.1.4.5 Battlefield System Protocols

The following battlefield system protocols support the modeling of key tactical capabilities within the CCTT training system. CCTT SAF recognizes these protocols.

3.2.1.4.5.1 Operations Centers CCTT provides several protocols for integration with the OC trainee stations and their behavioral models. The protocols are a combination of interactions through the CGF protocol and DIS. These are listed below.

Repair Failed vehicle issue Service Request PDUs to approaching Maintenance Unit continuously Battle Damage Assessment (BDA) - Maintenance sends a Data Query PDU • Vehicle sends data defining damage type Repair Complete for particular subsystems (complex set of time outs and authorizations)

Recovery • M88 issues a TOW request (Action Request PDU "hitch") • Towed vehicle returns Action Response PDU "complete" • Movement by each model (no transfer of control)

• 5 Meter offset • Mass of vehicles affects M88 dynamics

• M88 issues an Action Request PDU "unhitch" • Towed vehicle returns Action Response PDU "complete"

Resupply (between Manned and CGF) • Tether/Untether to MM (Action Request/Response) • Service Station Supply from MM (Action Request/Response) • Tailgate Resupply

• Tether-subgroup Action Request/Response • Initiate-Tailgate-Resupply Action Request/Response

AVLB After Detached (using EM protocol), its damage is controlled by EM Reattach (using EM protocol)



For many of these protocols, ModSAF supports similar PDUs (e.g., recovery, resupply) but minor differences exist in the semantic details of the protocols.

3.2.1.4.5.2Dismounted Infantry Workstation (DI WS) CCTT SAF established standard protocols for the integration of the DI WS, various manned modules, and CCTT SAF. DI WS entities can mount CGF vehicles and manned modules. CGF DI only mount CGF vehicles and never mount manned modules. Three PDUs are used to coordinate the mount/dismount capabilities of CCTT. The first is the action request PDU called the mount intent. This PDU establishes a relationship between the collection of DI WS entities and the vehicle they plan to mount. The second is the mount action/response PDU that initiates the actual mount behavior. The third is the dismount action/response PDU that initiates the dismount behavior. In CCTT SAF, the damage assessment is performed on mounted DI if the vehicle they are mounted on is damaged.

3.2.1.5 Simulation Services

The simulation services present in each SAF system provide core simulation functions. Each SAF system has similar capabilities as described in the following sections.

3.2.1.5.1 Time Management ModSAF and CCTT SAF time management capabilities are similar. Both systems provide for real-time and simulation time clocks. Both systems rely on Network Time Protocol (NTP) capabilities to ensure that wall clock time is synchronized between distributed components.

3.2.1.5.2 Executive ModSAF and CCTT SAF executive services are similar. Both systems provide for the allocation and management of computational resources through periodic events and deferred functions (one-shots or time ordered events). Both systems provide for high priority and low priority queues, non-preemptive scheduling, and frame stretching. ModSAF has been altered to provide as fast-as possible processing (available during stand-alone use) while CCTT SAF is multi-threaded to take advantage of Symmetric Multi-Processing (SMP).

3.2.1.5.3 Parameter Data Both systems provide the organization, loading and defaulting of parametric data. ModSAF provides default data capabilities through architectural features while CCTT SAF provides it through individual application standards. ModSAF provides for more of its capabilities to be parametric owing to the requirements for distributed development and experimentation.

3.2.1.5.4 Information Abstraction ModSAF provides for DIS PDU abstraction by supporting a data driven description of the information in a DIS PDU. This allows for the redefinition of the semantics of the information in DIS (responding to various standards) through the use of data files rather than code changes. CCTT provides DIS PDU encapsulation to isolate the applications from the



data representations in the PDUs. This minimizes code impacts of changing protocols to specified packages. However, this does not support multiple protocols without coding impact. ModSAF also provides support for bi-endianness.

3.2.1.5.5 C2 Database Both systems provide a command and control (C2) database capability that is similar. CCTT SAF's SEOD was based on a re-engineering of the ModSAF PO Database. Each of the objects in the database is defined by the clients (typically the behaviors). The definition of the data for ModSAF is associated with the behavioral models. CCTT SAF centralizes this in the SEOD subsystem in multiple package specifications. ModSAF distributes entire object updates and provides for bi-endianness (that is, correct interoperation between computers with differing standards for byte order within a word). CCTT SAF provides for distribution of both objects and events, while ModSAF only distributes objects. CCTT SAF uses attribute updates to reduce bandwidth and increase capacity. In addition, the distribution mechanisms and behavioral architecture of CCTT SAF permits the distribution of a unit organization across multiple platforms. This is currently not possible in ModSAF. The CCTT SAF data model and the application models support a segmented route. This allows for a small route object for typical routes with the ability to chain route objects together for longer routes. This combined with a route abstraction allows for small storage requirements and large route segments.

3.2.2 Models

The following sections describe the modeling capabilities in each system, categorized according to physical, environmental, and behavioral models.

3.2.2.1 Physical Models

Physical models are the simulations of real-world physical devices, such as vehicle hulls or sensor systems. As shown in the following sections, ModSAF and CCTT SAF have very similar approaches to physical modeling.

3.2.2.1.1 General Descriptions

Both CCTT and ModSAF systems include an equivalent level of vehicle classes that are sufficient for supporting typical simulation exercises. For example, both systems have Ml tanks, M2 Armored Personal Carriers, AH64 helicopters, etc.

In order to effectively cover the huge number of classes of vehicles, both systems instantiate a vehicle by assembling components called physical models. In general, hull, turret, sensor, and gun physical model components constitute a vehicle. For example, tank track model (the hull model), daytime optics, night vision, IR sensors (the sensor models), generic turret (the turret model), and main gun and machine gun (the gun models) constitute a Ml tank model in both systems. This composition is specified in a data file. Therefore, each vehicle type is associated with a vehicle physical model composition file.



Behavior models interface with the physical models through well-defined APIs called GMIs (Generic Model Interfaces). In order to make the Ml tank (define above) move, the movement behavior provides a proper command by calling GMIs supported by the hull physical model. Then the hull physical model, which is a generic physical model that interfaces to a specific physical model, calls a proper physical model. In this case, it is a tracked physical model that has Ml tracked hull characteristics. This relationship is drawn in Figure 9. Instead of using the Ml tracked model, the SAF behaviors always go through a software interface whose sole purpose is to provide generic access to physical models. In other words, the behavior models can uniformly invoke functionality regardless of the physical model that executes the invocation. For example, "Set Speed" GMI can be equally used for Ml tank tracked model as well as AH64 helicopter hull model. Thus, the GMI based function invocation implements one very important object oriented programming mechanism, namely polymorphism.

Figure 9: Physical model invocation is performed through GMI

As discussed above, both physical models are essentially equivalent at the conceptual level. Their implementation is also largely equivalent except for small implementation details. The minor differences come from the choices of programming languages ~ Ada for CCTT SAF and C for ModSAF.

3.2.2.1.2 GMI Implementation

Translation from GMI invocation to that of a corresponding physical model is the key difference between the two systems. In CCTT SAF, the translation is performed by a dispatch table written in an Ada case (when) statement. For example, when the above "Set Speed" for a Ml tank is invoked through the "Set Speed" GMI, the dispatch table finds a target function from the table and invokes the function related to the Ml tank hull physical model. Therefore, if a new hull physical model is introduced to CCTT SAF, then the dispatch table needs to be updated. Because the dispatch table is textually embedded in the Ada code that represents the hull GMI file, the file must be textually edited, compiled, and linked before the new model is utilized.

ModSAF uses a function pointer registration scheme to resolve the target function that is in the target physical model. Registration of function pointers is performed dynamically in ModSAF. Thus, a new physical model can be introduced in ModSAF without textually editing the ModSAF GMI libraries.

Table 5 lists the current GMIs supported by both systems.



CCTT SAF GMIs

Hulls, Turrets, Resource Models, Weapons, Sensors

ModSAF GMIs

Hulls, Airframe, Turrets, Guns, Deployables, Sensors, Esensors, DsgDetector, MineDetectors, Communication

Table 5: CCTT SAF and ModSAF GMIs

3.2.2.1.3 Model Types

Physical model types are classified into the following categories: hull, turret, weapon, sensor, communication, deployable, damage assessment.

3.2.2.1.3.1 Hulls

Both systems have an almost identical list of hull models. Details are listed in Table 6.

CCTT Hull Models

Tracked, wheeled, DI, FWA, RWA, missile, stationary

ModSAF Hull Models

Tracked, wheeled, DI, FWA, RWA, missile

Table 6: CCTT SAF and ModSAF Hull Models

3.2.2.1.3.2 Turrets

CCTT SAF and ModSAF have only one turret type called generic turret physical model. Weapons and sensors are mounted on components instantiated by the generic turret physical model. A vehicle can have multiple turret components if needed.

3.2.2.1.3.3 Weapons

The weapons models supported by each SAF system are listed in Table 7.

CCTT Weapon Models

ballistic, projectile, missile launcher

ModSAF Weapon Models

ballistic, artillery, missile launcher, rocket launcher, bombrack, laser designation, MICLIC

Table 7: CCTT SAF and ModSAF Weapon Models

3.2.2.1.3.4 Sensors

Sensors are further classified into optical, radar, and generic sensors. The supported sensor types are listed in Table 8.

CCTT Sensor Models

Optical • Direct view • Night vision

ModSAF Sensor Models

Optical • Direct view • Night vision



• Infrared • Infrared • Thermal • Thermal

Radar Radar • LOS radar • Generic radar

Generic Sensor

Table 8: CCTT SAF and ModSAF Sensor Models

3.2.2.1.3.4.1 Optical sensors

This sensor is the most extensively used sensor in both systems. This is a line-of-sight class sensor. However, depending on the wavelength used by a sensor, the sensor performance is greatly influenced by environmental effects, such as smoke, fog, clouds, etc.

3.2.2.1.3.4.2 Radar

This sensor type simulates radio frequency line-of-sight sensor.

3.2.2.1.3.4.3 GSM (Generic Sensor Model) No specific sensing frequency is associated with this model. Instead, it facilitates the implementation of new sensing algorithms. A major use was a ground-based sensor that automatically reports activity of targets within a designated area.

3.2.2.1.3.5 Communication

ModSAF has a generic radio physical model. This model can instantiate any radio type. However, no propagation aspect is modeled. CCTT SAF does not support radio models.

3.2.2.1.3.6 Deployables

Two systems equally support deployables. The details are in Table 9.

CCTT Deployables

Plow/roller, AVLB, Tent extensions

ModSAF Deployables

Plow/roller/rake, Deployable bridge, Mine deployables

Table 9: CCTT SAF and ModSAF Deployables

3.2.2.1.3.7 Damage assessment

Various damage models are supported. Table 10 lists the details.

CCTT Damage Assessment ModSAF Damage Assessment

Direct fire, Indirect fire, Stochastic, Deterministic Direct fire, Indirect fire, Stochastic

Table 10: CCTT SAF and ModSAF Damage Assessment



3.2.2.1.4 Configurability

As discussed before, each vehicle type is configured via vehicle configuration data files that allow a user to simply construct vehicle data files using the components listed above. Therefore, both systems have equivalent level of configurability.

3.2.2.1.5 Extensibility

GMI facilitates physical model extension. However, as discussed before, CCTT SAF requires textual editing of the GMI dispatch table while ModSAF does not require modifications. Each physical model is implemented with one clear software unit. CCTT SAF uses one Ada package, while ModSAF employs one C software library. Therefore, both systems essentially support the plug and play paradigm. Physical models are easily plugged in and out.

3.2.2.1.6 V&Ved Models

Physical models of the two systems are implemented based on AMSAA's compendium. This implementation approach is applied to:

• sensor performance

• delivery accuracy (ballistic guns)

• direct fire rate of fire (ballistic guns)

• direct fire damage assessment

• indirect fire damage assessment

Fair fight requirement with CCTT manned modules led to extensive tuning of the CCTT SAF physical model performances.

3.2.2.2 Behavior Models

A computer generated force must have an implementation of the behaviors of the forces that it represents. Both CCTT SAF and ModSAF are dominated (in code size and development effort) by their respective behavioral modeling components. In comparing the two suites of behavioral models, a large number of similarities, and a few key differences become apparent.

3.2.2.2.1 Behavioral Specificity The two systems take different approaches to populating the virtual world with simulated behaviors. ModSAF takes an approach of attempting to maximize behavioral commonality at the expense of behavioral accuracy. ModSAF behaviors are very generic, and can easily be instantiated on almost any entity with nothing more than a few data file modifications. Many of the behaviors have been implemented to be data-driven, with various configuration parameters to specialize a behavior for a specific purpose. Under this approach, for example, a road march behavior can be used on any ground vehicle or ground unit, however, the



subtleties that distinguish a Tank Platoon roadmarch from a Mech Platoon roadmarch, such as doctrinal stop points, are not represented.

On the other hand, all CCTT behaviors are baselined to a specific Combat Instruction Set (CIS), and explicitly represent the different subtleties between like behaviors documented in the CISs. There are separate code modules representing the Tank Platoon roadmarch and the Mech Platoon roadmarch. In many cases, the components that are common between two or more behaviors, for example basic road movement, have been abstracted into a common service used by those behaviors. Unfortunately, this is not always the case, and duplicate implementation of common behaviors does exist in the software. Despite the coding inefficiency, however, there is a better match to CIS-documented behaviors using this approach, as there are logical places within the software to represent and implement behavioral subtleties that are distinguished by unit.

3.2.2.2.2 Behavior Organization The two systems take different approaches to the organization of their behaviors.

With respect to software organization, CCTT S AF has a unit-oriented behavior architecture, where behaviors are organized by the types of units that can run them. For example all behaviors corresponding to a BLUFOR tank platoon are organized into one Ada package. As stated earlier, ModSAF has a flat organization of libraries, including the behaviors. ModSAF does distinguish unit-level behaviors from vehicle level behaviors, but the layering of behaviors is not explicit in the source code structure.

In the area of runtime organization, ModSAF uses a task frame approach to organize behaviors. Multiple tasks run in parallel in a given task frame. A module called the task manager performs the scheduling of behaviors within one or more task frames for a unit. The task frame supports parallel cooperative activity. One use of parallel tasks is to support the checking of reaction trigger conditions in parallel with normal behaviors. CCTT takes a more explicit control flow approach, where a specific behavior does an explicit check of trigger conditions prior to the main body of behavior execution. In this sense, CCTT has a more cooperative behavior approach, in that the behavior can explicitly control when to check for certain conditions or when to perform certain functions. ModSAF's independent tasks within a task frame result in a more competitive behavior implementation. Because of this, in some cases it may be more difficult for the ModSAF developer to accomplish his objectives in a ModSAF behavior.

Both systems have a notion of behavioral hierarchy, where, for example, company behaviors may issue platoon behaviors to be executed by the company's platoons. This hierarchical approach present in both systems has a tremendous benefit in simplifying the development of higher echelon behaviors, however it has the unfortunate side effect of requiring that lower level behaviors be built prior to higher level behaviors. This causes some amount of serialization during the behavior development process. Also, it is frequently the case that a higher level behavior requires subordinate behaviors that had not been identified as needing to be implemented.



3.2.2.2.3 Low-Level Behavior Approach The two systems take different approaches in their low-level behavior approach. Low-level behaviors control physical systems within a vehicle. ModSAF calls these behaviors "vehicle tasks", while CCTT SAF calls these "crew behaviors".

In ModSAF, a competitive behavior approach is taken for low-level vehicle tasks. The ModSAF behavior framework encourages developers to implement multiple tasks that run in parallel. An example of this is the vehicle search behavior, which slews a tank's turret back and forth to scan an area for suspected enemy. A vehicle targeting behavior can run in parallel to this search behavior, to control the turret for tracking a target. These two behaviors compete for access to the turret resource. At any given time, only one of the behaviors should actually command the turret to change its azimuth. A prioritization mechanism is used to arbitrate these competing demands. In ModSAF, a mutual arbitration approach is used, where each task that intends to use a resource must declare its intention to the prioritization module. Resources categories are defined for most physical systems, such as the hull resource, the turret resource, the gun resource, and the sensor resource. A finer level of categorization can be supported, for example to separate driver sensors from turret- mounted sensors.

The process of requesting a resource can take many forms. For example, a behavior may request access to a resource whenever the behavior is in a certain state, or whenever a certain predicate function returns TRUE. The prioritization module accepts all the requests and then selects which task will get exclusive control of a resource. If more than one task requests the same resource, a data-file driven priority list is consulted to pick the highest priority task. The system is called mutual arbitration because each task must be written in such a way that it is aware that it is competing with other tasks and may not get its desires satisfied.

This competitive approach to low-level behaviors can support very complicated control flow between software modules. This power of expressiveness can sometimes be difficult to control by a developer, however, the ModSAF implementation has a very positive benefit of making it very easy to add new vehicle-level behaviors. The prioritization service module is service-based, and its code does not need to be modified when new vehicle-level behaviors are added (however, this module's static data-file may need to be extended to properly address the relative prioritization of a new task with respect to other tasks). This implementation allows a new vehicle behavior to be added into the system without having to explicitly modify software that arbitrates when this vehicle behavior can run and use resources.

In CCTT SAF, a more cooperative behavior approach is taken for crew level behaviors. A number of modules encode the crew level behaviors, such as the driver crew or weapons crew. These modules have explicit control over vehicle resources and were designed to manage these resources to avoid conflicts. This approach has an appeal in explicitly implementing the inherent close-coupling of low-level behaviors, potentially eliminating unnecessary competition and computation. It is likely that this more direct-call interface to vehicle behaviors and vehicle resources can allow implementation of more expressive direct control and coordination.



However, the close coupling approach in CCTT SAF's crew behaviors is not without its cost, and that cost is the embedded complexity of these all-encompassing crew behaviors. By incorporating all of the weapons crew in one module, it may be difficult to allow sub-module replacement or refinement. For example, unlike ModSAF, it is not possible in the existing CCTT SAF crew architecture to develop an entity that uses all of the weapons crew except for a specialized threat-assessment module. The sub-models are not plug-replaceable, as they are in ModSAF's vehicle tasks.

3.2.2.2.4 Specialized Behaviors Both CCTT SAF and ModSAF represent specialized behaviors that merit attention.

Each system supports a Command from Simulator behavior that allows a manned simulator to lead a platoon of SAF vehicles. Each system has approaches to allow the CGF vehicles and the manned simulator to work cooperatively. Within CCTT, a great deal of attention has been placed on the development of this behavior, and a number of specialized CISs have been developed to allow the SAF operator to support coordination between the manned simulator and the SAF platoon. ModSAF has also developed some of these capabilities, such as a cue-fire function that forces the SAF vehicles to wait for the manned simulator to fire before they will engage the enemy. It is most likely the ModSAF implementation has not seen as much use as is intended within CCTT, however, ModSAF does support this capability for both tanks and rotary wing aircraft. Insufficient time prevented a complete side-by-side analysis of these behaviors and further examination of their relative strengths and weaknesses should be performed as follow-on to this study.

It appears that CCTT SAF has implemented more robust low-level behaviors supporting target search and engagement. A modified scanning algorithm has been implemented that supports lingering on detected but not-yet identified targets, as well as revisiting of known targets during the general scanning process. Once engaged, a distribution of fire algorithm ensures a good allocation of shooters to targets. CCTT SAF can employ multiple weapons on one platform, which ModSAF cannot currently do.

Because of its breadth of use, ModSAF has a larger number of varied specialized behaviors that go beyond ground armored combat. For example, ModSAF supports Theater Missile Defense (TMD), chemical detection, and a number of future systems, such as ASTAMIDS, MMCM, and ORSMC mine-detection and mine clearing vehicles.

3.2.2.2.5 Behavior Representation Each system has both similar and unique characteristics of the basic architectural representation for behaviors. The following sections describe these characteristics, compares and contrast them for ModSAF and CCTT SAF.

3.2.2.2.5.1FSM Representation The two systems have both similar and differing behavior representations. Each system uses Finite State Machines (FSMs) to implement behaviors. The FSM approach breaks down a behavior into one or more states. During each state, a behavior may perform some activity.



Transitions between states are performed based on certain state-specific criteria, such as the completion of an activity or the receipt of some input.

Though the FSM approaches in both systems are similar, the implementations of the FSMs are quite different. CCTT SAF encodes FSMs using Ada native language capabilities. An FSMs control structure is encoded as an Ada 'case' statement, where each branch of the case corresponds to a different state. The case statement dispatches to a branch according to the value of the current state, and once within a branch, the current state may be modified to become another state based on some triggering condition. Although the language construct for an Ada FSM is standardized (i.e., the case statement), the organization of the code and its dependent data structures and calling routines can vary according to the preferences of the behavior developer.

In ModSAF, a customized FSM representation was developed. Called the Asynchronous Augmented Finite State Machine (AAFSM) language, this representation is an extension of standardized C syntax. ModSAF scripts convert AAFSM files into pure C code prior to compilation. The AAFSM language standardizes the types of data structures used by each ModSAF behavior, and the code generation performed by the ModSAF scripts takes care of the "house keeping" maintenance of these data structures, including reflecting data changes to the persistent object database and detection of externally-generated input parameter changes.

The AAFSM language extensions allow ModSAF behavior developers to express the textual layout of the state machine and to declare each of the machine's states and transition using explicit syntax. The language supports normal operation of the state machine, as well as the ability for the behavior to specify how to react to changes in the behavior's input during operation (these are called parameter events). This forces the behavior developer to think about how the behavior should respond to input changes in each state. For example, a movement behavior might respond to its input route changing by computing the nearest new waypoint to head toward.

The net effect of the use of the AAFSM format in ModSAF is that all behaviors have a similar software structure that is easily recognized by ModSAF behavior developers.

3.2.2.2.5.2Behavior Communication

CCTT SAF takes a much more real-world approach to communication between behaviors. In CCTT SAF, all behavior cooperation is implemented through a reports and orders paradigm. Behaviors can cause subordinate units to act by issuing orders, and subordinates indicate their behavior progress by issuing reports. This approach results in a looser coupling between behaviors at different hierarchical levels, since a standard order or report format defines the interface. In ModSAF, behaviors directly modify parameter inputs to subordinate behaviors.

One ramification of CCTT SAF's approach is the increased maintenance requirement on the orders and reports data structures. This formal interface makes it somewhat more difficult to extend behaviors to do such things as adding new parameters. A benefit of CCTT SAF's



approach is the reports and order data structures can form a useful API for other external uses.

CCTT SAF implements behavior communications that may result in the modification of a data structure as a request to the owner ofthat data structure. This forces a receive-order serialization of requests, which obviates the need for arbitration of object changes. An example is the way that a unit's mission is modified. The user interface does not directly manipulate the mission, but instead sends requests to the unit that owns the mission to modify its mission. This decouples specific actions, such as modification, from the data model and data structure, such as lists.

The orders and report paradigm forces the implementation of report processing within CCTT. Every tick of a unit calls one or more functions to handle battle loss reports and spot reports. These functions poll for the existence of an event for the unit (such as receipt of report), and responds appropriately to those reports.

3.2.2.2.5.3Behavior Ownership

ModSAF and CCTT SAF take different approaches to ownership of unit behaviors. In CCTT SAF, an explicit simulation object represents platoons, companies, and other higher-level units. These objects are responsible for when their respective behaviors run. In ModSAF, the vehicle that is currently "in-charge" of a given platoon or company is made responsible for running the platoon or company's behaviors. In a sense, all unit behaviors execute within a vehicle context. This is accomplished as a service of the task manager, which locates all the behaviors that a particular vehicle should execute.

The approaches have relative strengths and weaknesses. In ModSAF, the attrition of a leader will cause some leader context information to be lost for coordinating the behaviors of its subordinate units. This is more closely matched to what happens in the real world. In CCTT SAF, the execution of the platoon behavior is unaffected by vehicle attrition. An advantage of the CCTT SAF approach is that the behavior processing of superior units such as platoons and companies can be reduced compared to the processing required for vehicles, as less frequent updates are required for these higher level behaviors.

3.2.2.2.5.40rder Decomposition

The execution of behaviors by a military unit requires that higher echelon behaviors be decomposed into appropriate behaviors for subordinates. For example, a company attack mission may require that the company's platoons conduct various subordinate behaviors in support of the company's mission. The process of turning a high-level order into one or more low-level orders is called order decomposition.

ModSAF and CCTT SAF take different approaches to order decomposition. Both systems rely on a representation of a Task Organization (TO) to describe the military organization of superiors and subordinates. In CCTT SAF, orders are composed when assigned, primarily through the user interface. When an order is assigned, a special module decomposes that order for the appropriate subordinates. When performed at the user interface, the user has



instant visibility into what the units and subordinates will do. The user may make changes to the decomposition, and may save those changes as part of the scenario exercise.

In ModSAF, order decomposition does not occur until the behavior is activated at runtime. The user does not have up-front visibility into what the higher-level mission will do at the lower level. When the behavior is started, the behavior directs the runtime decomposition to the subordinate units. This allows ModSAF behaviors to perform accurate decomposition based on the runtime environment. For example, if at the time that the company behavior is started, one of the company's platoons has been completely attrited by combat, the company behavior can choose to intelligently decompose the mission to only the surviving platoons. In CCTT SAF, the decomposition process cannot anticipate the battle state that will exist when the order is actually executed.

These two approaches to order decomposition have varying strengths and weaknesses. The ability to edit and save the decomposition is a powerful benefit of the CCTT approach, while the ability to perform decomposition based on runtime information is a powerful benefit of the ModSAF approach. The CCTT approach may have a closer match to real-world mission planning.

3.2.2.2.6 Behavior Control Paradigms Both ModSAF and CCTT SAF support 3 basic types of behavior control. Pre-planned missions are specified by the SAF operator in the construction of an execution matrix for a unit. The execution matrix specifies the sequencing of behaviors (either CISs or task frames) for a unit, and allows control of the transitions from one behavior phase to the next. Transitions can be specified based on time, crossing a control measure, on command from the operator, or some other simulation event. The types of transition triggers are described in the UCI section.

The SAF operator has the ability to modify the mission during execution, which is the second type of behavior control. ModSAF supports the modification of mission graphics and behavior inputs, as well as the concept of Immediate Interventions that make temporary modifications to the mission. These modifications can be restored (resumed) at a later time. CCTT SAF supports Command Overrides, which present a limited set of modifiable parameters for a mission, such as speed and formation.

The third type of behavior control is the ability to implement automatic reactions in ModSAF, or the Situational Interrupts (SI) in CCTT SAF. CCTT SAF contains codified reaction tables specified by doctrine and CIS. ModSAF has reactions enabled by data files specifying the contents of task frames. When activated, a reaction or SI overrides the current mission with a new behavior. The reaction or SI can be resumed at the direction of the SAF operator.

Behavior control requires the use of some type of User Computer Interface (UCI). ModSAF supports the ability for tasks to specify their corresponding task editor via a data file associated with the particular behavior library. This allows new behaviors to be added to the



ModSAF without requiring new UCI code to be developed. CCTT SAF does not have this capability.

3.2.2.2.7 Traceability & V&V Status The two SAFs have different requirements on traceability and V&V. ModSAF has had some of its behaviors based on interim CIS specifications, however, many have been implemented based on best engineering judgment and various sources of contractor- and government-based knowledge acquisition. In support of certain exercises such as the Anti-Armor Advanced Concept Demonstration (A2ATD), some ModSAF behaviors have been verified, validated, and accredited for use within a particular exercise. Also, some amount of V&V has been performed under the auspices of the ModSAF Integrated Development Team (IDT) as part of the ModSAF management by STRICOM. However, ModSAF has not undergone exhaustive V&V.

CCTT SAF has had very strict traceability and V&V requirements.

CCTT SAF development has had the advantage of being able to refer back to CIS specifications to resolve questions concerning correct behavior implementation.

3.2.2.2.8 Behavior Breadth & Depth ModSAF has a total of 106 assignable task frames, composed of 234 separate unit or vehicle tasks. Approximately 26 reactive task frames are implemented, and each of these is embedded in some unit behavior that decides to start the reaction.

CCTT SAF has 276 CGF CISs, as well as 75 OC behaviors. There are approximately 373 FSMs in the CCTT SAF baseline.

3.2.2.3 Synthetic Natural Environment

Synthetic Natural Environment (SNE) represents the passive/non-sentient parts of the simulation, including terrain/features, ocean, and weather. SNE provides services to support behavioral models in reasoning/planning and physical models in correctly responding to ground truth.

Throughout this section, "terrain" means land/terrain skin/terrain features and "environment" means weather, ocean state, and effects (like flares).

3.2.2.3.1 Interface Structure & Architecture The overall interface structure of CCTT and ModSAF SNE are one of the biggest differences, even though these interfaces provide much the same functionality.

ModSAF's terrain representation is subdivided into independent modules with no externally enforced or visible hierarchy (although there is, of course, a dependency hierarchy within the SNE modules based upon which module calling structure). Also, ModSAF's terrain libraries often export very primitive data (e.g., individual features) through their external interface. For example, libctdb's external interface (i.e., libctdb.h file) contains the routine to get height of terrain and also provides the complete definition of the ModSAF's compact terrain



database (CTDB) structure (over 4,000 text lines). This exposes the casual users to the module's most private (and volatile) data. This approach supports swapping out or adding modules at the expense of interface complexity and a requirement for strong developer discipline. For example, a new module that relies on primitive terrain data can be added without expanding or modifying libctdb, but only developer discipline prevents the movement of a bit in a CTDB feature representation from impacting many modules.

ModSAF's environment representation (DVW) is much more strongly structured, in that libenvironment provides the primary means for extracting environment data (via tags and resolvers). DVW's flexibility is provided by allowing any library(ies) to register their ability to support a tag (or many tags). This leaves the interface strongly abstracted and consistent while allowing the ability to swap libraries / capabilities beneath this interface.

Because ModSAF's terrain and environment capabilities were developed independently, they are not fully integrated across all libraries and capabilities. A given ModSAF consumer (e.g., a sensor) that is impacted by both terrain and environment must separately query those areas, or use another library which does so. The inter- and intra-relationships between SNE libraries and their users must be tracked based upon dependencies (#include relationships) and code inspection. For example, a developer may wonder if a concealment-finding routine considers tactical smoke from libenvironment or just terrain/features from libctdb The developer would have to look through both directories to understand these dependencies.

By contrast, CCTT's SNE interface is strongly centralized and encapsulated at the Environment CSC (and PVD CSCI for 2D viewing data). No portion of a CCTT database file is visible from (or is with'd by) an external package specification. For example, CCTT's model reference terrain database (MrTDB) could be swapped out without impacting an external consumer or external specification. CCTT CGF's Environment software component (CSC) is the sole source for SNE query/reasoning services, and always integrates all underlying data into a single answer for callers (just as the PVD CSCI is the sole source for 2D display information). This strict encapsulation dictates the functionality that needs or operates on primitive SNE data must be pulled into Environment CSC. To emphasize this structure, Environment CSC software is stored hierarchically where only the Environment root directory provides external interfaces and subcomponents of Environment are in subdirectories which consumers may not use. Environment CSC's external specifications are split by type of function (e.g., line of sight, cover and concealment, route planning) to lessen the extraneous material a given customer must wade through. A user of height of terrain functionality need only look at a 300 line specification.

While ModSAF's decentralization and wide-open interfaces require strong developer discipline (and experience), they also provide a great deal of flexibility. Environment CSC's interface supports formal software engineering principles (encapsulation/hierarchy), but it thereby lessens the flexibility and codevelopment possibility ModSAF supports.

3.2.2.3.2 Database Format & Primitives The terrain databases of ModSAF and CCTT share a common ancestor in SIMNET TDB. CCTT SNE used libCTDB (circa CTDB format 2) as a starting point for reuse and database



format. ModSAF's CTDB format 2 and CCTT's MrTDB were very similar in terms of functionality, but they branched off and simultaneously evolved along separate paths because they were driven by different requirements. A few years later, however, in an effort to produce a common terrain database that was available in both MrTDB and CTDB formats (for a SAF interoperability exercise), features that MrTDB supported that CTDB did not support (i.e., basis sets and model references) were added to CTDB.

3.2.2.3.2.1 Header/Global Data Both CCTT SAF and ModSAF databases contain the zone number, the northing, and the easting of the southwest corner. These numbers describe the database's location on the surface of the earth. Both also contain the database's length and width in meters, which describe the geographic extents of the database. ModSAF databases also contain the geographic extents in latitude/longitude format.

Both databases use models to store repeated/common data, both recognize subdivisions of databases in terms of pages (cacheable units) and patches (feature containers), although CTDB also uses a quadtree storage scheme for its abstract features. MrTDB also has the "obstacle/avenue linkage" to maintain a connection between obstacles and features which override those obstacles.

3.2.2.3.2.2Coordinate Systems

ModSAF supports the following coordinate systems

• geocentric • topocentric (arbitrarily placed) • geodetic (latitude/longitude) • Universal Transverse Mercator projection (UTM) • milgrid (MGRS) • global coordinate system (GCS)

CCTT SAF supports the following coordinate systems

• geocentric (for DIS PDUs only) • topocentric (arbitrarily placed, used internally throughout CCTT software) • geodetic (latitude/longitude, for database origin only) • Universal Transverse Mercator (UTM) projection (for PVD only) • milgrid or MGRS (for PVD only)

Because it supports the global coordinate system, ModSAF databases may have unlimited geographic extents and may span multiple UTM zones. Earth curvature effects on intervisibility and elevation are taken into account for GCS databases. CCTT databases do not support GCS and cannot span multiple UTM zones.

3.2.2.3.3 Terrain Skin Representation

Both ModSAF and CCTT SAF support uniform grids for terrain skin representation. Both



support arbitrary grid post spacing and diagonalization can be specified on a per-grid post basis.

TINs, or triangulated irregular networks, are used to represent terrain skin whose granularity is too great to be represented by the uniform grid. The gridposts are ignored in areas of the terrain skin covered by TINs.

ModSAF has two representations for TINs: microterrain and terrain elements. Microterrain is the more compact way to represent TINs. Microterrain stores the vertices of the terrain skin polygons as well as soil type information. Terrain elements include not only vertices and soil type information, but also information about the TIN topology. This greatly increases the computational efficiency of the intervisibility algorithms. Because of terrain elements, algorithms using fully-TINed databases perform reasonably well whereas these algorithms using the same fully-TINed database stored as microterrain would perform very slowly.

CCTT SAF only supports microterrain as its TIN representation, although it does use a specialized representation for emulating TIN-like data for cut and fill features.

ModSAF supports an advanced attribute database that can be used to store an arbitrary amount of information associated with each soil type code. There can be up to 256 soil types per patch (typically 500m X 500m). CCTT SAF supports up to 256 soil types, although only 32 of these are used.

3.2.2.3.4 Feature Representation

A number of terminology and storage-scheme differences complicate any comparison of features supported by the two SAFs. For example, CCTT does not draw a distinction between "abstract" vs "physical" features (except by how the features are used), whereas CTDB stores and retrieves them separately (even using different storage structure: quadtree vs patches, respectively). ModSAF does not draw a distinction between static and dynamic terrain features (e.g., treelines and deployed fences are both physical linear features), while CCTT stores and retrieves them separately (terrain features vs relocatable objects).

Rather than force the comparison into terminology foreign to both systems, ModSAF's terminology is used for the feature comparisons (with differences noted for CCTT), and dynamic terrain is covered separately.

3.2.2.3.4.1 Physical Features

ModSAF's physical features can be loosely described as those which may impact intervisibility (except, for example, laid linear features), and are oriented toward a description of geometry. They are the descendants of features stored in CTDB format 2 prior to integrating quadtree (with extensions to handle new features such as fences as linears).

Volume Features represent a three-dimensional mass resting on the terrain surface. The vertices of the "roofline" of the feature are stored in the database. It is assumed that the volume rests on the ground; thus, "floating" volumes cannot be represented. Both ModSAF and CCTT SAF can represent the following volume features:



• Buildings (includes power poles, towers, etc.) • rock drops (known in CCTT as rock outcroppings)

The only significant difference here is that CCTT also supports full model references for geometry (that is, a building instance may also be described as a point and orientation, with the footprint of the building described in a model for dynamic placement). This helps preserve the meaning of a single building (or bridge) across patch boundaries (instead of splitting the building into two), and could also support changing of footprints based upon damage (although only height is used now based upon the CCTT database source).

Linear Features are defined in ModSAF as having a height significant enough to have an effect on intervisibility. In CCTT, "Linear Feature" is analogous to "Laid Linear Feature" described below. Both ModSAF and CCTT SAF can represent the following linear features:

• treelines (although CCTT's version was never tested due to changing requirements) • wire • fences (several types)

Additionally, ModSAF can represent dragon's teeth. Note that wire and fences are described in CCTT as "Linear Relocatables".

Treelines are ModSAF's answer to an SlOOO-specific solution to tree density (paper-thin green wall representing many trees).

Tree Canopies are "circus tent"-like structures with a canopy top represented as a TIN. Treelines surround the outer edge of the canopy. This is a cheap (both computationally and storage wise) method of representing forests. Tree canopies are ModSAF's representation of an SlOOO-specific visual scheme. CCTT uses individual trees in all cases (never treelines or canopies), but space is provided for both in MrTDB.

Aggregate Features are a collection of features that can be referenced and instanced. They are commonly used to represent forests made up of individual trees (as opposed to tree canopies). Forests are commonly represented in this manner by placing tree templates in a tiled fashion to make up the bulk of the forest, then individual trees are placed along the perimeter of the forest, so that its perimeter does not consist of straight edges. Representing forests in this manner greatly reduces the storage requirements for forests made up of individual trees. This technique was heavily used on CCTT's databases, especially the forested Primary 1.

Both ModSAF and CCTT SAF support aggregate features, although CCTT takes advantage of the representation features unique to the Evans & Sutherland databases for better performance (specifically, plane-slope is stored with instance and implied grid masks are used). The relative performance implications of the more or less generic approaches are unknown.

Laid Linear Features have a specific width and rest on top (conform to) the terrain surface. They have no height that can affect intervisibility. Both CCTT and ModSAF support roads and rivers in this form. CCTT fully expands the outer boundaries of all linears (whether



conformal or not). While ModSAF's centerline representation is more computationally efficient, it leaves gaps in turns (especially sharp turns or wide linears) and also when crossing a patch boundary at an angle (not perpendicular). These gaps can lead to terrain type anomalies, such as a dust cloud suddenly appearing while following an asphalt road.

CCTT calls these features "linear features", and treats railroads the same way. Railroads are an abstract feature in ModSAF, as shown below.

Abstract Features can be loosely described as abstractions that are important to the simulation, but do not affect intervisibility, although some are abstractions of physical features that can impact line of sight (e.g., bridges). These features are the descendents of the old quadtree database (and are stored as a quadtree), which integrated into CTDB to form format 3.

As described above, CCTT does not draw a distinction between abstract vs physical features, except as implied by the functional use of the representation.

ModSAF can represent the following abstract features (italics = not in CCTT):

tree canopy (CCTT: uses forest boundaries) soil defrag steep slope railroad pipeline political boundary powerline label (CCTT: part of PVD database) tactical sign offroad segment bridge (CCTT: obstacle/avenue linkage, road net, and separate feature type) crater (CCTT: point relocatable object) ditch (CCTT: linear relocatable object) fighting position (CCTT: point relocatable object) dragon's teeth berm camouflage rubble (CCTT: relocatable object) snow miclic contaminant hydro surface (CCTT: areal feature) hydro subsurface

CCTT SAF can represent the following (italics = not in ModSAF): • forest boundaries (analogous to tree canopy edge bits) • soil defrags (typically no-go only)



steep slopes label (part of CCTT PVD database) railroad (as a CCTT linear feature) bridge (via obstacle/avenue linkage, road net, and separate feature type) crater (point relocatable) ditch (linear relocatable) fighting position (6 types, point relocatable) log crib (point relocatable; ModSAF could handle a volume physical feature) minefield (obstacle for path planning; ModSAF supports minefields, they are not part of SNE)

• obstacle/avenue linkage (stores "avenues" through obstacles, e.g., bridge over river or road over no-go terrain type).

Multi-Level Terrain refers to multiple valid elevation values at a given 2D location. Both ModSAF and CCTT SAF can represent bridges and overpasses. ModSAF handles tunnels, while CCTT has limited but untested capability with tunnels.

ModSAF takes multi-level terrain one step further and can represent multiple elevation structures. Multiple elevation structures (MESs) can represent buildings with multiple floors and rooms. MESs can represent walls, windows, doors, and stairways. They are also used, in addition to multi-elevation microterrain, to represent bridges, tunnels, causeways, and overpasses.

Model References are used by both SAFs for storage efficiency. A model contains information about the characteristics of a certain terrain feature, for example, a tree. Instead of storing the same information for each feature, the instance of the feature references the model. Thus, many features with similar characteristics can reference the same model. This eliminates duplication of storage of feature characteristics.

Most model capabilities are the same for both SAFs. The differences are:

ModSAF only: • Linear models for treelines, fences, and dragon's teeth (ModSAF uses the same model for

trees/treelines that CCTT uses for trees only).

CCTT only: • CCTT building (volume) models include footprint information that may selectively be

used by model instances (this supports footprint changes from damage and patch crossing buildings).

• CCTT also has bridge span models that may be used to capture the presence of a single bridge which spans multiple patches.

Network Topologies support planning. Both ModSAF and CCTT SAF store precomputed road network topology, as well as relationships between various cross-country obstacles. This information is used by both SAF systems to compute routes.



3.2.2.3.5 Dynamic Terrain Dynamic terrain refers to features that can be created, modified, or deleted during runtime (or planned pre-ex and instantiated at initialization).

ModSAF's dynamic terrain approach, as developed during STOW, is very different from CCTT's. Both systems' representation reaches beyond SAF into other system components: STOW's Dynamic Terrain Object (DTO) includes DTscribe, DTsim, and ECNs; CCTT uses Environment Manager, MCC, and point/linear/areal PDUs for relocatable objects. These differences are not discussed here.

Independent of differences with the overall architecture/system components, CCTT and ModSAF handle dynamic terrain very differently within their SNE software. CCTT processes dynamic terrain (relocatable objects) separate from terrain features for storage, retrieval, and representation. A given external routine, such as line of sight, separately queries terrain, features, entities, and relocatable objects. There are, of course, some interrelationships between these components, such as features or relocatable objects overriding portions of the terrain skin. In contrast, ModSAF largely integrates dynamic terrain into the in-memory copy of CTDB. CCTT's approach adds some complexity and miscorrelation caused by treating relocatables as an exception to the terrain database, while ModSAF's more generic approach requires locking any modified patches/pages into memory thus limiting scalability.

CCTT's system-wide dynamic terrain approach was heavily influenced by system integration (specifically, image generator costs and correlation) and thus is very CCTT-specific. The network and internal representation of dynamic terrain objects matches the E&S relocatable object representation and geometry closely. For example, tank ditch segments are multiples of 30m long and all relocatable objects are treated as instantiatable models, just like entities. However, CCTT's SNE routines are probably more tightly and completely integrated with the abstract representation of the limited CCTT relocatable object set as a result of this extensive system integration.

ModSAF has virtually unlimited dynamic terrain capabilities in that any feature that can be represented can also be changed dynamically. This includes changes made to the terrain skin. Craters, anti-tank ditches, and fighting positions of arbitrary dimensions and can be "sewn in" to the terrain skin.

CCTT supports the relocatable objects (italics = ModSAF does not support):

• Log crib (but could be volume feature) • Abatis (but could be volume feature) • tank ditch - can be composed of up to four segments, with segment lengths of 30, 60, 90,

or 120 meters • concertina wire fence (same as tank ditch) • fighting positions (fixed geometry in CCTT)

• infantry fighting position • overhead covered infantry position • machine gun prepared position • covered machine gun bunker



• hull defilade vehicle fighting position • minefield • armored vehicle launched bridge (AVLB) • building rubble • ribbon bridges

3.2.2.3.6 Environment Environment includes weather, ocean state, littoral regions (tides), illumination, and environmental effects (such as flares or tactical smoke). The SAFs are overwhelmingly different in these areas.

3.2.2.3.6.1 Natural Effects ModSAF simulates the following weather phenomena: temperature, dewpoint, relative humidity, barometric pressure, wind velocity, precipitation type, precipitation rate, extinction type, extinction amount, extinction coefficient, ray visibility, visual range, illumination, sky over ground, cloud cover, cloud ceiling, cloud height, cloud type, sim time, sun position, moon position, moon phase, contrast, solar illumination, lunar illumination, and sky illumination. ModSAF's implementation of these phenomena is universally more complex and complete than CCTT's.

CCTT SAF represents the following weather phenomena: rain state, visibility range, haze state, haze visibility range, haze ceiling, fog state, fog visibility range, fog ceiling, cloud state, cloud ceiling, cloud base, cloud visibility range, lunar illumination, temperature, humidity, wind speed, and rain soak. CCTT's implementation of each of these is as an ambient, global parameter with no relationship or dependency between each other except as enforced at the system MCC. Each of these parameters is provided as a value that can be retrieved by consumers. Only rain soak has a side effect on SNE services. That is, rain soak modifies the terrain type values passed back upon a surface type query to reflect "wet" surfaces. CCTT has no ocean/littoral capabilities.

3.2.2.3.6.2Man-Made Effects ModSAF supports the following man-made environmental effects:

• signal and illumination flares • tactical smoke (from smoke grenades, burning vehicles, and muzzle smoke) • vehicle dust (dust kicked up by moving vehicles and muzzle blasts)

CCTT SAF supports the following man-made environmental effects:

• flares (treated as point in air with associated circle of light on ground; numbers limited by CCTT system).

• tactical smoke (from smoke munitions; modeled only as simple opacity and type)

3.2.2.3.7 SNE Services The previous section on interface structure describes the overall approach of each system to presenting an external interface to customers. Also an extensive comparison of interfaces is



provided in the appendix containing the detailed SNE assessment. This section describes functional differences as visible from each system's SNE external interface.

3.2.2.3.7.1 SNE Query I Primitives Terrain-related queries and primitives were found to be surprisingly similar, although there are numerous differences in details partly caused by the use of different language features, such as macros.

Munition flyout: CCTT has a dedicated routine for this capability with some selectable intersection criteria. This capability could be built out of existing libctdb routines.

Collision Detection: ModSAF supports a simple collision detection algorithm which uses the ground intersection service to detect ground or feature intersections along the ray starting with a vehicle's position during the previous tick and ending with that during the current tick.

CCTT S AF provides a more sophisticated collision detection algorithm that utilizes bounding volumes of both vehicles and terrain features. In addition to the entire entity, parts of entities (turrets, hulls, and guns) may individually be checked for collisions.

3.2.2.3.7.2SNE Reasoning Again, overall SNE reasoning was similar at a gross level. In this case, there were some notable differences.

Observation Posts: CCTT SAF contains an algorithm which searches for observation posts (high elevation points) in a specified area. ModSAF currently does not have this functionality.

Concealed Routes: ModSAF provides a concealed route planning algorithm which finds routes that are as concealed from the enemy as possible. Any number of enemy descriptors may be provided as input to the service. The three types of enemy descriptors are enemy direction, enemy location, and enemy area. CCTT SAF does not compute concealed routes.

Cross-Country Route Planning: ModSAF's cross-country route planner considers only large terrain obstacles such as forests, rivers, lakes, and steeply sloped areas. It also knows about bridges so it can plan through choke points. It currently does not know about minefields and other dynamic countermobility obstacles with the exception of dynamically placed bridges. ModSAF's representation is orthogonal to a Voronoi diagram (travel through midpoints of segments connecting neighboring obstacles). It is used for platoon-level route planning, and returns corridor width information with its output route. ModSAF treats cross- country and road routing as separate planners.

CCTT SAF's cross-country route planner runs as a separate process. It, too, considers large terrain features such as forests, rivers, lakes, no-go areals and steep slopes. The CCTT cross- country planner does not recognize bridges (the user is required to request road points in the route). CCTT will consider selected dynamic obstacles (known minefields, ditches, and fences). CCTT uses a visibility graph from which corridor width cannot easily be extracted. The planner has a validation feature that verifies manually created or modified routes for



trafficability. CCTT provides a single interface to both cross-country and road route planning, but the two planners cannot consider each other's data. The user must still specify each point as cross-country or road; the planner just stitches them together.

For both SAFs, all routing information is built does not, and loaded into memory at initialization. Both also support destruction of intersections in the road network.

Near-Term Planning: ModSAF's near-term entity-level movement planner is a three- dimensional planner (x, y, and time). It considers all obstacles, including other vehicles, trees, and buildings, as well as everything considered by the cross-country planner. Each vehicle has its own "localmap," which describes the obstacles in the vicinity ofthat vehicle. The path planner then takes these obstacles as input and plans a smooth path through them using cubic splines. Several paths are considered. The optimal (shortest) path is chosen as the planned path. The concept of an "attractive path" is also supported, where a path through an obstacle may be specified. This feature is often used in breaching countermobility obstacles.

CCTT SAF's near-term movement planner is nearly identical to ModSAF's movement planner in terms of supported functionality. CCTT's planner does not include time explicitly (this is handled by CCTT's driver code); thus, dynamic entities are handled only by request from the caller. Also, CCTT's planner makes use of the obstacle/avenue linkages in MrTDB so it can follow roads through steep slope areals, breaches through obstacles, and over/under- passes. These avenues can be selectively blocked by the caller (e.g., do not consider a particular breach through a minefield). CCTT's planner also handles fighting positions / vehicle scrapes as an obstacle or destination based upon the caller's objectives.

3.2.2.3.8 Terrain Tools This section describes the offline test tools and compilers available for both SAFs.

3.2.2.3.8.1 Compilers Both systems' compilers use a "front-end" / "back-end". The biggest difference between ModSAF and CCTT database generation are the sources that can be used and CCTT's division into multiple compilers / databases. ModSAF has a separate database for routing, but everything else is handled by CTDB. However, only CTDB is built by a "compiler", because routing databases are constructed from CTDB by ModSAF's runtime code if one does not already exist. CCTT, on the other hand, has three separate "back-ends": one for the dedicated PVD database, one for the dedicated radio database, and one for all other databases (MrTDB for geometry, MrsTDB for routing, and EmTDB for Environment Manager).

There are numerous terrain database sources available for ModSAF. There are compilers that convert from SI000, EaSiest, and Multigen to CTDB. A SEDRIS-to-CTDB compiler is currently under development. There is also a CTDB-to-CTDB compiler that is used to convert from one version of CTDB to another and to incorporate post-processed features. ModSAF's preprocessor analyzes a CTDB database, and compiles a list of all of the terrain skin polygons that exceed a specified steepness threshold. It then coalesces these polygons and outputs the bounding footprints of these steep areas to an ASCII file that is used by the


CTDB-to-CTDB compiler.

CCTT compilers presently ingest only a CCTT-specific format known as SIF++. The CCTT compiler front-end could be replaced to export data from other sources; this approach is being used for an experimental SEDRIS-to-MrTDB compiler. CCTT SAF handles post- processing via multiple "passes" of the compiler, so there is no distinction between post- processing and the compiler passes. CCTT supports steep slopes, forest boundaries, obstacle/avenue linkages, soil defrag, cut and fill, etc., in this manner.

3.2.2.3.8.2Viewers & Debugging Support ModSAF has a debugging tool that allows one to view all of the terrain skin polygons and features, perform intervisibility checks as well as soil and elevation queries. It also has the capability to view the terrain in 3D.

ModSAF also has a program that lists pertinent information about all of the terrain skin polygons and features in a given database in ASCII format. This is useful for debugging feature encoding algorithms and for comparing the results of successive database compiles.

CCTT also supports all of these capabilities with an interactive Motif tool called GIDGET. The 3D viewer is limited to a static VRML image of a selected portion of the database (<lkm x <lkm). GIDGET supports all major functions at Environment CSC's interface, including collision detection, relocatable object placement, obstacle avoidance, routing, cover and concealment, etc. To support these routines it can simulate placement of entities and relocatable objects, as well as state changes to buildings and bridges. This allows line of sight, for example, to be tested with all possible features, entities, and relocatable objects in a standalone environment. CCTT's text dump is available using the same point-and-click interface, but only dumps out data for selected feature(s) and/or terrain skin by page or patch (not the entire database).

3.2.3 User Control

Both ModSAF and CCTT SAF are controlled with a suite of graphical user interfaces (GUIs) which form a User Computer Interface (UCI). The capabilities of each system's UCI are described below.

3.2.3.1 General Characteristics

ModSAF supports a single display for both the user input and tactical map. CCTT requires a 2-display workstation configuration. ModSAF employs a tiled window presentation where no windows will obscure other windows. CCTT SAF makes use of many pop-up windows that the operator can position and iconify on his workstation.

3.2.3.2 Tactical Map

For each system, the tactical map displays the terrain features, simulated entities, and simulation effects for the DIS exercise. Both tactical maps support arbitrary zoom levels and panning. ModSAF supports runtime generated contour intervals while CCTT SAF uses pre- generated contour lines for redisplay speed. Each system supports the selective display of


feature classes and forces, and contains tools to display terrain elevation and area intervisibility information. In addition, ModSAF supports the display of terrain profile, line intervisibility between points or entities, and query of the environment or soil information at a given location.

CCTT SAF's tactical map is hosted on a separate display from the main user interface. In addition, the tactical map is part of the Plan View Display (PVD) system, which runs as a separate process from the SAF workstation. The SAF workstation and PVD communicate through a shared memory protocol. The PVD software is a common component shared by many other CCTT systems. ModSAF's tactical map is hosted on the same display as the rest of the ModSAF user interface, and runs as part of the same workstation process.

Both systems display entities using either top-down pictures that show vehicle articulations such as turrets and guns, as well as the ability to display doctrinally correct unit and vehicle symbols using FM-101-5 symbology. CCTT SAF makes extensive use of hard-coded binary images for icons, while ModSAF supports completely data-driven icons and vehicle pictures. ModSAF's vehicle pictures support arbitrary scaling, while CCTT SAF's have a set of fixed sizes.

3.2.3.3 Overlay

Each SAF workstation contains a capability to create tactical overlays containing graphical control measures such as phase lines, coordination points, and assembly areas. CCTT SAF supports a fixed set of 6 doctrinal overlays (Maneuver, Fire Support, etc.), while ModSAF has no predefined overlays other than a default unnamed overlay. Both systems allow the selective display of certain overlays. In each system, the user can create, modify, or delete overlay symbols. ModSAF has more of a direct manipulation interface in which the user can click on a symbol in order to edit it. A specialized library to support on-screen sensitivity of objects on the tactical map provides direct visible feedback as to what objects are currently selectable by the mouse, depending on current editor configuration. In CCTT SAF, the user must select the correct mode before he can click on an overlay symbol, and no highlighting of selectable objects is visible. CCTT SAF has a larger palette of specific tactical overlay symbols, while ModSAF supports more generic symbols such as "line" and "area". Each system can support the separate loading and restoring of overlays separate from the scenario (or exercise) file.

3.2.3.4 Execution Matrix

The control of the behaviors of simulated entities is performed using an execution matrix paradigm. The execution matrix divides a mission into phases, where each phase has one or more unique behaviors for each unit and entity in a tactical organization. Trigger conditions cause the mission to progress from one phase to the next. ModSAF's execution matrix is organized with units on the left column and phases running left to right. CCTT SAF's execution matrix is organized with units at the top row, and mission phases running top to bottom. Developers of the execution matrix of both systems claim Subject Matter Expert (SME) input drove the layout of the matrix.

FNL_RPT.DOC Approved for public release; distribution is unlimited 4?


In CCTT SAF, the cells of the execution matrix contain CISs for the specified unit. The user selects which CIS for each cell based on a filtered list of CISs appropriate for that unit's echelon, side, and type. In CCTT SAF, the execution matrix can be sparse, allowing for a varying number of CISs for a particular unit in a particular mission phase. In ModSAF, the cells of the execution matrix contain task frames for the specified unit. The user selects which task frame for each cell based on a filtered list of task frames appropriate for that unit's echelon, side, and type. In ModSAF, and execution matrix can only have one task frame per unit per mission phase.

Each system provides editors to parameterize the contents of an execution matrix cell. In ModSAF, data-driven editors are provided for each unit-level behavior in a given task frame. The system supports forced choices that must be filled out by the SAF operator before the cell is completed. The operator can modify various default parameters for each task as well. In CCTT SAF, a custom-written editor is provided for each CIS. These editors also support forced choices and the modification of default parameters.

Both systems allow the modification of execution matrix cell parameters (either CISs or Tasks in a task frame) during execution to support Fragmentary Orders (FRAGOs). ModSAF behaviors are required to react correctly to modifications of already running behaviors, while CCTT SAF behaviors are not.

Both systems show the modification of the current mission as an outcome of reactions or situational interrupts. In ModSAF, modifications to the current mission show as colored cells whose textual content shows both the original behavior and current reactive behavior. In CCTT SAF, modifications to the current mission show as colored cells that have been inserted before the currently running cell.

Both systems support an alternate execution matrix that allows the operator to construct a new mission while a unit is executing a current mission.

3.2.3.5 Triggers & Control Measures

In the previous section, it was stated that trigger conditions separate mission phases in an execution matrix. The two systems have different capabilities with respect to the control and specification of these triggers.

Both SAF systems support triggers for completion of a previous mission phase, crossing a control measure, or "on order" from the SAF operator. ModSAF also supports triggering from the duration of the previous mission phase, or from a global h-hour clock. CCTT SAF supports triggering from an absolute time since the beginning of the exercise. Also, CCTT SAF supports triggering from other units' activities, including starting an order, completing an order, or crossing a control measure. CCTT SAF supports the logical AND-ing of multiple trigger conditions. ModSAF's behavior architecture supports a suite of logical operations to combine triggers, such as AND, OR, and NOT, but the user interface does not allow the specification of these logical combinations.



3.2.3.6 Command From Simulator

Both systems provide an interface to the command from simulator behavior described earlier. ModSAF's behavior allows a manned simulator to be substituted into an existing platoon. ModSAF vehicles perform station keeping relative to that manned simulator and will exhibit cue fire, firing only when the manned simulator has fired. The ModSAF operator can control the SAF portions of the platoon with immediate intervention commands, such as change formation, change speed, and halt.

In CCTT SAF, the operator role plays the platoon being commanded by the simulator. The simulator is allowed to replace either the Platoon Leader or Platoon Sgt. position. The operator enables the platoon to fire based on doctrinal rules of engagement, such as hold, fire at sector, and free.

3.2.3.7 Task Organizations and Unit Roles

Both systems make extensive use of a task organization structure to organize military units. In CCTT SAF, the operator has the ability to attach or detach units during scenario construction or during runtime. In both systems, a scheme of vehicle markings and bumper numbers is employed for DIS-based tracking and analysis of exercise vehicles. In CCTT SAF, the vehicle marking scheme is fixed, while in ModSAF, a default scheme is provided and it may be overwritten by the operator. The user has the ability to create task organization templates for later use, and he is able to draw on a library of doctrinal and user created organizations during scenario construction.

Within the CCTT SAF software, behavioral "role" information is derived from the task organization data structures present in the SEOD. This role information is used to group vehicles for particular behavior functions, such as determining the particular vehicles that make up a particular section within a platoon. CCTT SAF behaviors use groups of vehicles or units organized by role as their primary data structure for coordination. The behavioral role abstraction includes capabilities to deal with propagation of roles due to attrition.

Although ModSAF has task organizations described in easily modified data files, no capability to modify task organization during scenario creation is available. Runtime modification of a "Functional Organization" allows temporary modification of the task organization. The user can employ specialized "Report-To" and "Accept" task frames to effect runtime modification of the task organization.

In ModSAF, some behaviors, such as bounding overwatch, make use of temporary functional organizations to coordinate groups of vehicles. The concept of behavioral role is not institutionalized within ModSAF software.

3.2.3.8 User Interface Construction

The two SAF systems have different approaches to construction of the user interface. CCTT SAF uses standardized User Interface Language (UIL) data files to describe windows and widgets. A UIL compiler converts this into a UID file that is loaded by the system to create windows, establish symbolic widget names, and establish symbolic callback names. User



interface developers write software to assign the correct Ada functions to be called when the specified widget is activated. New behavior development may require new user interfaces within the exercise editor to specify CIS parameters. These user interfaces will require new UIL files and modification to user interface software.

ModSAF has built its own runtime GUI construction capability based on data files. A suite of pre-defined widgets is available to ModSAF developers. These widgets, and the data structures that they modify are completely specified in data files that are loaded at runtime. UCI developers in ModSAF need only write software that accesses the data structures modified by the UCI. In the case of behavior development, the behavior developer requires no UCI modifications. A behavior editor infrastructure (libtaskedit) allows the proper plugging in of new task editors into the system without the behavior developer doing anything other than declaring the behavior data structures and widgets in a data file.

3.2.3.9 Specific Windows and Editors

The following describes specific windows found on each system.

CCTT SAF contains a unit editor for view and modification of the task organization and unit parameters (marksmanship, fuel, ammo, opening range, damage level, fire status). Multiple unit editors may be open at one time.

CCTT SAF contains an exercise editor which is used to create and select units, overlays, terrain, and CISs. CIS parameters may be specified from this editor. The user can add and remove units with this editor. During runtime, the exercise editor allows FRAGOs to be inserted into the execution matrix.

CCTT SAF contains a UCI controller which supports pre-exercise terrain selection, and selection of PVD symbol types. From this editor, the user can issue command overrides or modify unit parameters. Also, the vehicle control editor can be used from the UCI controller to provide direct control of a vehicle.

ModSAF supports a user preference editor used to configure the layout of the UCI, as well as the default units to represent information such as speed and distance. A PVD editor allows control of icon sizes on the map, DIS events to be animated (such as shooting or collisions), ranges of contour lines, and the PVD refresh rate.

ModSAF supports a terrain tool which provides a rich suite of terrain analysis functions, such as terrain profile and line and area intervisibility with the terrain and between vehicles. An environmental tool allows querying and modification of the simulated environment, such as temperature, weather, and sea state. An illumination editor allows visualization of the relative contributions to light intensity as well as sun and moon position.

ModSAF has two editors for fire support. A message-based fire support control editor sends appropriate DIS radio messages to artillery units, while another editor allows the arbitrary detonation of artillery at the SAF operator's control (also known as the "bomb button").

ModSAF has a number of editors to modify unit information, such as the rules of engagement editor and the damage editor.



3.2.4 High Level Architecture (HLA)

The ModSAF 4.0 Beta baseline supports the STOW version of the High Level Architecture's Runtime Infrastructure (RTI). ModSAF's HLA integration is regarded as a shallow integration where the ModSAF's internal data model is essentially DIS PDUs and its System Object Model (SOM) simply recasts this DIS data model directly into an HLA object model. This implementation supports the Federation Management, Declaration Management, Object Management, and Data Distribution Management services of the RTL There is a desire to modify the ModSAF baseline to utilize the HLA standard RTI interface version 1.3. Additionally there is a desire to modify the ModSAF internal data model to be more object- based to more fully satisfy the intent and flexibility provided by HLA compliance. Both of these efforts are currently being implemented under DMSO sponsorship.

The CCTT 5.1.2 SAF baseline does not support the HLA and does not utilize the RTL However, prototype development to support DMSO's Platform Proto-federation experiment was conducted using the CCTT SAF system. This experiment demonstrated the ability to implement a shallow integration of the HLA into the CCTT SAF architecture using a similar approach as used for ModSAF.

3.3 Migration Assessments

Following the technical characterizations for each category of SAF system capabilities (e.g., Behaviors, Physical Models, etc.), assessments were performed on the migration of the characteristics and capabilities of one SAF system to the other. In most cases, only two migration options were considered:

• Migration of CCTT SAF capabilities into the ModSAF architecture, and • Migration of ModSAF capabilities into the CCTT SAF architecture.

The exceptions to this were the Behaviors Assessment where additional migration options were assessed that involved architectural extensions, and the User Computer Interface Assessment where only one option is feasible. The two focus teams developed the migration options for a particular category in parallel. Each migration option was developed and analyzed with respect to meeting the intended OneSAF Testbed use and providing the desired OneSAF Testbed characteristics described above in Section 0.

A subsequent set of meetings were held in which each focus team presented their migration option(s), and a joint assessment of the migration options were performed. Each migration option was assessed on the criteria described below. A relative rating, on a scale of 1-10, was provided in each criteria, with 1 being low risk/impact/effect and 10 being high risk/impact/effect.

• Technical feasibility: An assessment of the technical risk involved with the migration option. Considerations included the need for architectural extensions/enhancements, need for major new design, and the ability to implement the option within current technology.



• Program risk: An assessment of the schedule risk associated with the migration option.

• Impact to existing ModS AF community: An assessment of the impact that the implementation of the migration option would present to the community of existing ModSAF developers and users. Considerations included the ability to provide current level of ModSAF capabilities, interfaces (internal and external), extensibility, and performance.

• Impact to ModSAF development: An assessment of the impact that the implementation of the migration option would have on current DoD-sponsored ModSAF development efforts, and the ability of those efforts to be integrated into the OneSAF Testbed.

• Impact to existing CCTT Program: An assessment of the impact that the implementation of the migration option would present to the CCTT user community. Considerations included the ability to provide current level of CCTT SAF capabilities, external interfaces, and performance.

• Impact to CCTT development: An assessment of the impact that the implementation of the migration option would have on current DoD-sponsored CCTT SAF development efforts, and the ability of those efforts to be integrated into the OneSAF Testbed.

• Adaptability to new technology: An assessment of the effect that the implementation of the migration option would have on the ability of new technology to be integrated into the OneSAF Testbed.

• Relative cost: An assessment of the effort to implement the migration option, considering the same assumptions, factors, and requirements, with respect to other migration options within the same category. This criteria was rated in terms of staff months of effort required to implement a migration option in isolation (i.e., without regard to the impact of the migration options selected in other major areas).

The following sections provide an overview of the migration options considered in each major area. The detailed assessments are contained in Appendix C.

3.3.1 Behaviors Assessment

The significance of behaviors within each system cannot be overestimated. Behaviors represent the largest component of each simulation system. This is both in terms of lines of code (SLOC), and effort expended. It was discovered that there were substantial differences between how each system represented behaviors, as identified in the system characterizations previous described. A surprising conclusion by both ModSAF and CCTT SAF behavior developers was that the current state-of-the-art for behavior representation and implementation in each system is sub-optimal today. Developers in both communities see behavior implementation as a Research and Development (R&D) area more than a straightforward development. Each behavior expert could come up with a list of improvements that they felt needed to be developed in order to make behavior implementation more correct, easier to develop, and less error prone.



The results of the behaviors assessment are described in the following sections.

3.3.1.1 Behaviors Focus Group Activity

The behaviors focus group consisted of behavior architects and developers from the ModSAF and CCTT SAF development communities. The group analyzed approaches for satisfying the following requirements:

• Support all currently implemented CCTT CISs

• Retain V&V status for CCTT behaviors as much as possible

• Support all currently implemented ModSAF task frames

• Support capability to easily add behaviors into the system without excessive code rework

In the course of the assessment, six options were generated for achieving the requirements stated above. The options range from migrating behaviors from one system to the other, to making architectural enhancements to ease migration, to supporting dual architectures, to developing a fresh start. The options can be seen in the next section with the following diagram and the accompanying list.

3.3.1.2 Behaviors Options

Figure 10 shows the six options that were considered for the behaviors assessment.

• Option 1: Re-implement missing behaviors from ModSAF into existing CCTT infrastructure (no modification to the infrastructure)

• Option 2: Re-implement missing behaviors from CCTT SAF into existing ModSAF infrastructure (no modification to the infrastructure)

• Option 3: Develop new unified behavior representation and implement all behaviors in it

• Option 4: Extend ModSAF with additional infrastructure to ease re- implementation of CCTT behaviors within ModSAF

• Option 5: Extend CCTT SAF with additional infrastructure to ease re- implementation of ModSAF behaviors within CCTT SAF

• Option 6: Develop capability to run both ModSAF and CCTT SAF behaviors within the unified SAF

On the left vertical axis are the choices of using one of the two architectures to do a straight implementation of the missing behaviors. These are reasonably well understood options of just developing new behaviors in a native environment. The problems with these options are that, although it may be possible to represent a CCTT behavior in a ModSAF architecture, or vice versa, you will likely lose key system requirements.



Implementing ModSAF behaviors in CCTT (option 1) would sacrifice the ability to easily add new behaviors into the system to, for example, support analysis, without major modifications to many subsystems.

Implementing CCTT behaviors in ModSAF (option 2) would sacrifice assignment-time order decomposition, support for periodic check-pointing for restart, and operational distribution of

units across simulation resources (i.e., vehicles in a platoon on different CGF simulators).

©

p r e s e r v e

A r c h i t e c t u r e

Start with CCTT

Start with ModSAF

E n h a n c

"■£

A r c h i t

■: e

c t u r e

© • Received Most Focus

©■

Recommendation of Summer

Study

©

■ Received Most Focus

Figure 10: Behaviors Migration Options

If given a choice, both ModSAF and CCTT SAF experts would like to do option 3, which is to start from scratch in some new behavior development technology. This option could be forward-looking to new requirements, such as behavior editing and visibility of behavior algorithms, which are both OneSAF ORD requirements. Because this is a research topic, no candidate approach for option 3 surfaced. The assessment team was not able to judge how long it would take to develop a new behavior architecture, but the team expected that it will take longer than is available for the development of the testbed.

Options 4 and 5 take the approach that if we cannot start new, let us identify what can we do to enhance the exiting architectures to:

1) make the migration cheaper, and

2) make the migration satisfy more requirements



In the case of ModSAF, this includes adding architecture to speed up development, and address some capabilities like order decomposition. In the case of CCTT, this includes making its architecture more extensible.

A final option, option 6, was also considered. This option proposes to somehow support both behavior architectures simultaneously. This would be an attractive option because you could conceptually preserve the V&V characteristics since you would no be re-implementing the CCTT behaviors. The problem with this option was that:

1) The team could not come up with a feasible technical solution to have dual architectures (that does not mean there is not one)

2) The maintenance would be horrific (two sets of behaviors AND two architectures)

3) The option is very unattractive from the point of view of software implementation. Developers would become frustrated trying to extend such a dual system, not having clear guidance as to which architecture to do development in.

With consideration to technical feasibility and the shortness of time to perform the assessments, options 4 and 5 received the most focus.

The detailed assessments for all options are found in Appendix C.

3.3.1.3 Behaviors Assessment Results

The assessment identified a significant risk associated with the sheer size of the behaviors in each system, and the extensive dependencies that behaviors have with respect to the rest of their native software system. Each approach that starts with an existing baseline will experience difficulty in bringing over behaviors from the other baseline. This implies that behavior migration has a substantial per-behavior cost. Each baseline choice has risks of failing to satisfy requirements. In the case of starting with ModSAF, the risks are in the area of validated functionality or usability. In the case of starting with CCTT SAF, the risks are in supporting extensibility, which is a capability that is proven over time.

The following table provides the summary of the assessment results in each criteria area. Note that in all cases, a lower number is better. Except for cost, everything was scored from 1-10. Cost is in person-months.



Options that did not receive primary focus were not fully assessed in all areas such as cost.

Technical Program Impact to Impact to Impact to Impact to Adaptability to Cost feasibility risk existing ModSAF existing current new-

Risk ModSAF development CCTT CCTT technology communit program development risk

y Option 1 3 2 7 7 1 1 10 260 pm

Option 2 1 7 1 1 7 7 3 425 pm

Option 3 NA NA NA NA NA NA NA NA

Option 4 2 4 2 2 4 4 3 379 pm

Option 5 4 4 3 3 1 1 4 469 pm

Option 6 9 8 1 8 1 8 7 NA

Table 11: Behavior Migration Assessment

The assessment team focused on options 4 and 5, which were deemed to be the most feasible options that satisfied a full range of requirements. The team focused almost exclusively on cost as the driver, assuming that cost was proportional to schedule, and that schedule was going to be the most difficult item to satisfy. There are, of course, other approaches to supporting combinations of criteria. For example, one could add each criterion together and take the lowest. In this case, you could treat 379 person months as a '3', and 469 person months as a '4'.

Looking at cost, the assessment team settled into choosing option 4, starting with ModSAF. This was not an obvious choice. We cannot say the full range of implications of this choice. Losing the reports and orders paradigm from CCTT may be detrimental to the implementation of CCTT behaviors within ModSAF. The team did not have enough time to evaluate this and other details.

3.3.2 System Assessment

For this system capability assessment, this section describes those priority issues and expectations that were the focus for this particular migration assessment. The system focus area provides the basic framework and architecture for all the application code. In addition it provides all external views and interfaces to the SAF system. The system area considers all over-arching functionality with wide impacts.

3.3.2.1 System Focus Group Activity

The system focus group was responsible for the migration assessment for the system issues for ModSAF and CCTT SAF. The categorization of capabilities to consider was determined



first from the technical characterization taxonomy. From this list, the group developed technical interchange meeting presentations to describe the capabilities of each system. These capabilities were discussed and an agreed list of capabilities was formulated for the system assessment. Two approaches were identified for the migrations are as follows:

• Option 1: Use CCTT SAF System Capabilities as a basis and add the missing system capabilities from ModSAF.

• Option 2: Use ModSAF System Capabilities as a basis and add the missing system capabilities from CCTT SAF.

The detailed assessments for these options are in Appendix C.

3.3.2.2 System Capabilities

The following list outlines the system capabilities considered by this focus group. This list was constructed by the combination of system capabilities through the technical interchange meetings and the technical characterization taxonomy.

• Data Collection • Architecture

• Command and Control Protocols (PO vs. SEOD) • Allocation and migration • Communications/Networking • Support for RTI-s • Information abstraction • Support for bi-endianness • Time management • Process architecture

• System capabilities • CCTT system integration

• MCC • AAR • OC Interface • Interoperability

• Concurrent exercises • Battalion level workload • System configuration • User accessibility • Developer accessibility • Portability

• Hardware platform • Language and programming standards

3.3.2.3 Assumptions

The common goals of the system focus group, independent on which path is taken, are to use C (compilable by C++), not Ada. Also the resulting system must support running on SUN, SGI, PC (Linux), Dec (Alpha), and IBM/Motorola (AIX) systems.



3.3.2.4 Assessment Results

The assessment illustrated a significant risk associated with exercise initialization for CCTT. This presented technical risks in the translation of the SEOD file format and CGF protocol as well as schedule risk necessary to mitigate the technical risk. This risk was shared by both options. The assessment recommended Option 2 (start with ModSAF). However, it was noted that threading, as it is implemented in CCTT SAF, must be migrated to the ModSAF system approach for performance. Further analysis must be performed regarding the migration of SEOD capabilities to the PO as well as the system interfaces inherent in CCTT. The following table provides the summary of the results. Refer to the system assessments in Appendix C for a more detailed description of each option.

Technical Feasibility Risk

Program Risk

Impact to Existing ModSAF community

Impact to ModSAF Development

Impact to current CCTT program

Impact to current CCTT development

Adaptabilil y to new technology risk

Relative cost

Option 1 3 2 2 2 5 2 5 42.5 pm

Option 2 4 4 2 2 5 2 3 40.5 pm

Table 12: System Migration Assessment

3.3.3 Synthetic Natural Environment Assessment

The SNE assessment examined the feasibility of using the SNE software of either CCTT SAF (Option 1) or ModSAF (Option 2) as a baseline and incorporating unsupported capabilities from the other system. The SNE assessment considered not only runtime capabilities, but also runtime databases, compilers, and correlation with other systems, such as image generators.

The SNE assessment was made easier by the degree of technical exchange between the CCTT and ModSAF communities in SNE over the past few years, including the widely publicized SNE improvements as part of STOW and various ModSAF efforts to absorb CCTT's SNE extensions into the ModSAF baseline.

3.3.3.1 Assumptions

This assessment assumed that the final system is to be implemented in C (compilable by C++) and that the resultant SNE must contain the union of CCTT and ModSAF SNE capabilities. Also, the terrain database sources and feature content of both systems must be supported. Finally, the boundary with behaviors was drawn such that behavioral support utilities (like path planning) were deemed part of SNE. A detailed list of each system's components included with SNE is provided in the appendix.

3.3.3.2 Assessment Highlights

In general, it was discovered that the runtime capabilities and databases were very close on the terrain side to the extent that requirements overlapped; this is not surprising, since the two



systems share a common starting point in database format and CCTT reused a number of libctdb routines. Despite this, the biggest overall factor discovered during the assessment was the difference in breadth of functional capabilities, as illustrated in the technical characterization and detailed assessment. CCTT's SNE representation does not contain a number of capabilities that ModSAF/STOW has, including:

• advanced terrain skin topology • multiple elevation structures (i.e. building interiors) • DVW (dynamic virtual worlds; phenomenology effects not found in CCTT) • DTO (dynamic terrain object capabilities partly unsupported by CCTT) • GCS (global coordinate system)

These capabilities are extensive enough to discourage use of CCTT as a baseline because of the volume of software that would have to be re-engineered, especially in light of the need to convert CCTT software to C.

The greatest advantage of using the CCTT software as a baseline is the investment in integration with the CCTT system as a whole (including manned modules, visual systems, and user-specific requirements and user-directed performance modifications). However, the combination of an Ada-to-C conversion, plus the integration of significant functionality from ModSAF means that significant effort would still be required with CCTT interoperability and correlation.

Regardless of the approach taken with the runtime functionality and databases, the database generation software would need to be based on ModSAF's compiler, which already handles a wide range of database sources. Although a CCTT database has been built in CTDB format, there is likely to be substantial work in this area to build a repeatable, production-capability CCTT database generation capability from the ModSAF compiler baseline.

3.3.3.3 Results

Three significant risks were identified during this assessment:

• CCTT system impact (interoperability, fair fight, user performance directed modifications)

• Generation of CCTT databases (availability of database compilers) • Numerous specific technical risks and areas of further study (enumerated in the

detailed assessment)

The summary of the options is shown in Table 13, while the detailed assessment can be found in Appendix C. The SNE assessment strongly supports the use of ModSAF as a baseline for OneSAF testbed (option 2), largely because it contains substantially more functional breadth than CCTT and is already implemented in C.

Technical Program Impact to Impact to Impact to Impact to Adaptability to Cost Feasibility Risk Existing ModSAF Existing Current New

Risk ModSAF Community

Development CCTT Program

CCTT Development

Technology Risk

Option 1 8 7 5 5 5 5 5 132 pm



Option 2 3 3 3 2 8 8 3 103 pm

Table 13: SNE Migration Assessment

3.3.4 Physical Models Assessment

The physical models focus group activity involved three steps. First, the group baselined the physical model capabilities for CCTT SAF and ModSAF. Then they analyzed the approaches for the combination of capabilities. Based on the initial analysis, two options were generated for consideration.

During the initial analysis efforts, the group recognized the following significance related to both physical models. Both systems have a similar classification structure for the physical models. This obviously eased the assessment task. This characteristic automatically leads to low technical risks, low program risk, and minimal program impacts. Detailed descriptions about these risk and program impacts can be found in Appendix C. The group also identified that CCTT models have the most recent V&V status because of its daily use requirement for training, while ModSAF's physical model architecture provides better extensibility. The extensibility of ModSAF comes directly from extensive usage of function pointer registration scheme that is characterized as inverted architecture.

The same two options were considered for physical model assessment as was consider for the other categories. Option 1 starts with the ModSAF baseline and incorporates CCTT models within the ModSAF physical model architecture. Options starts with the CCTT SAF baseline and incorporates ModSAF models within the CCTT SAF physical model architecture.

The focus group's goal, independent of either migration path of the above options, was to construct a model suite that has the best combination of performance, validity, usability, extensibility, and commonality. Thus, the approach envisioned by the group for both options was the following. Whenever possible, the two models would be unified. However, if the unification will not be possible, two models would be implemented in the target OneSAF testbed. Finally, the C programming language was chosen as the implementation language regardless of the options.

Option 1 maximizes the extensibility of ModSAF while implementing the CCTT physical models. Thus, the resultant system will be easier to construct than that of Option 2. However, the V&V process would be more involved because the CCTT models will be re- implemented on top of the ModSAF physical model architecture. There will be a risk that the re-implemented CCTT models might not perform as before in the native CCTT architecture. The level of this risk should be minimal. After examining all of the CCTT models and investigating ModSAF architecture for estimation of the re-implementation task, the assessment group computed 34 relative person months in order to complete the task of unifying physical models of the both systems using option 1.

Option 2 has an advantage that the CCTT requirements are automatically met by the direct use of the CCTT models in their native architecture. The V&V process is minimized for the CCTT physical models. However, in order to re-implement the ModSAF physical models, the CCTT physical model architecture will have to be extended to include the ModSAF's



inverted architecture. Therefore, this option was determined to be more costly than Option 1. Additionally, all of the CCTT SAF Ada code will have to be translated into C language. When all of these cost items are added, the cost associated with unifying the physical models of two systems was estimated as 50 relative person months using option 2. This option carries a slightly higher risk than Option 1 because of the architecture extension for re- implementing the ModSAF models.

The summary of the above two options are shown in Table 14 while the detailed assessment can be found in Appendix C.

Technical feasibility risk

Program risk

Impact to existing ModSAF coniniunit y

Impactto Impact to Impact to ModSAF existing current CCTT development CCTT development

program

Adaptability to new technology risk

Cost

Option 1 1 1 1 1 2 2 2 34 pm

Option2 3 3 2 4 1 1 2 50 pm

fable 14: Physical Model Assessment

3.3.5 User Computer Interface Assessment

The significance of the UCI assessment is due to its visibility. The ModSAF and CCTT SAF UCIs are the first interface that any SAF user encounters when using these systems. Therefore, imperfections in the UCI migration will have immediate visibility to the OneSAF testbed development program.

3.3.5.1 UCI Focus Group Activities

The UCI focus group was responsible for the migration assessment for the human interface issues for ModSAF and CCTT SAF. The categorization of capabilities to consider was determined first from the technical characterization taxonomy. From this list, the group developed technical interchange meeting presentations to describe the capabilities of each system. These capabilities were discussed and an agreed list of capabilities was formulated for the UCI assessment.

During the categorization of capabilities, it was recognized that there were driving capabilities that must be incorporated in the final system. It was identified that

• The UCI be C based, • Window/widget generation be data file driven, • The data model supports data file descriptions of offsets, and • The architecture needs to be inverted to support extension.

Each of these requirements for extension and portability directly conflict with the CCTT UCI implementation and architecture. The CCTT assessment team determined that incorporation of ModSAF capabilities would require a complete rework of the CCTT UCI. It was further determined that this rework would be essentially equivalent to new development. This was based on the fact that only the requirements and screen content could be reused from the



CCTT approach. This is true because the UCI architecture and implementation, hard code the structure of the models and their data as well as the functionality of the UCI. The UCI has minimal data driven capabilities limited to the pure unit organizations, behavior assignment lists, and data ranges. Even with this level of data driven capabilities, the contents of the data files are directly driven by the code structure. Any additions to the UCI required both data file changes and code changes. Incorporating this design in the OneSAF Testbed would constitute a step backwards when compared to the data driven capabilities of ModSAF (specifically, all window contents and attributes are data driven). It was determined that the result of a new development from CCTT SAF would be equivalent to an evolved ModSAF UCI. Therefore, this focus group reasoned that the only viable option was an evolution of the ModSAF baseline.

The detailed assessment for this option is in Appendix C.

3.3.5.2 UCI Capabilities

The following capabilities were considered during this focus group.

• Main window • Exercise Editor • Unit Editor • Unit status window • Report window • Alert windows • Vehicle control editor • PVD capabilities

• Tactical map • Overlay editor

3.3.5.3 Assumptions

The following assumptions were generated for this assessment activity.

• PVD subsystem from CCTT must be preserved • Common component used extensively throughout CCTT systems • Implies that CCTT PVD, including tactical map and overlay symbols must be

present in OneSAF testbed • Both CCTT's popup oriented and ModSAF's tiled approach must be maintained

It was identified that a new interface and supporting architecture would be added to ModSAF to allow communications between the ModSAF application and the CCTT PVD application. The ModSAF PVD would be adjusted to allow running with or without the PVD (where PVD refers to everything that is displayed on the "map"). When use of the CCTT PVD is desired, the ModSAF PVD would be disabled and ModSAF would switch to using the new interface to communicate with the CCTT PVD using the CCTT PVD API.

As shown in Figure 11, a new interface and architecture would have to allow ModSAF to communicate via the existing CCTT PVD API shared-memory message queue. There will be



issues with an Ada application sharing a shared-memory segment with a C application, the most obvious being "data understanding" (C and Ada do not use the same memory layouts for things like structures and arrays, etc.). It is assumed that these issues can be overcome with reasonable amounts of effort.

Shared memory

ModSAF PVD

PVD API

UCI

PVD API

UCI

Figure 11: OneSAF Testbed Interface to CCTT PVD

Once the architecture is enhanced, the appropriate function calls and hooks will have to be added to ModSAF (in similar fashion to where all the existing ModSAF PVD functions and hooks). ModSAF Editors that currently use the ModSAF PVD for input (or output), would have to be modified to understand that a ModSAF PVD might not exist, and if appropriate take their input from the CCTT PVD (via the CCTT PVD API).

3.3.5.4 Assessment Results

Table 15 shows the result of the UCI migration assessment. With only one choice available, there is no utility in comparing this assessment with other assessments.

Technical feasibility

Risk

Program risk

Impact to existing

ModSAF community

Impact to ModSAF

development

Impact to existing CCTT

program

Impact to current CC FT

development

Adaptabilit y to new

technology risk

Cost

Option 1 4 1 1 4 3 2 2 38pm

Table 15: UCI Migration Assessment

It should be noted that though this is the best and only choice within the constraints of this study, this recommendation does not address the potential advantages that could be afforded by performing new development using new UCI technologies. One example would be the development of Java-based UCI capabilities that would allow the exploitation of web-based deployment of the SAF UCI. An approach such as this might increase the usability and accessibility of the SAF for a variety of uses. This approach was not evaluated due to an assumption that new development would be out of the scope of the initial testbed development.

3.3.6 Migration Summary

Table 16 provides a rollup, exclusive of the User Computer Interface assessment, of the various migration assessments. The relative costs shown in the table are not meant to show



the total effort required to implement the OneSAF Testbed; rather, they are meant to provide a relative comparison of the efforts associated with selecting either CCTT SAF or ModSAF as the starting baseline.

rlodSAF Technical Feasibility Risk 18 10 Program Risk 16 12 Impact to Existing ModSAF Community 12 10 Impact to ModSAF Development 14 10 Impact to Existing CCTT Program 12 16 Impact to CCTT Development 9 16 Adaptability to New Technology 16 13 Relative Cost 694 557

Table 16: Migration Assessment Rollup

Given that data-driven extensibility and a C language base (compilable in C++) are the key characteristics of the OneSAF Testbed, the following is recommended:

• The starting baseline for the OneSAF Testbed will be ModSAF 4.0 • CCTT SAF models will be selectively re-engineered in C from the CCTT SAF

code (not from the models' requirements) • Extensions to the ModSAF architecture and models will be made to capture

strengths from CCTT SAF

This recommended approach achieves the highest priority OneSAF Testbed characteristics with a low degree of risk:

• A similar capacity for "Plug N Play" as provided by CCTT SAF and ModSAF • A capacity to be extended toward providing a Battalion level behavior API • A capacity to support R&D experimentation associated with the OneSAF

Objective Architecture using current SAF capabilities

The recommended approach will also aim to achieve the lower priority OneSAF Testbed characteristics, but with a higher degree of risk associated with achieving these characteristics:

• A breadth of modeling capability as provided by CCTT SAF and ModSAF • A training capability as provided by CCTT SAF and ModSAF

4 Summary This document described the analysis effort and its artifacts for recommending the baseline SAF from which the OneSAF Testbed should be developed. These artifacts include a description of the technical characteristics of ModSAF and CCTT SAF. The OneSAF Testbed will be used to support research and development for the next generation OneSAF



architecture experiments, will be extended toward providing a BBS replacement capability through a Battalion level behavior API, and will provide the training capacity currently implemented by CCTT SAF. This analysis recommended the development of the OneSAF Testbed by integrating the desired CCTT SAF characteristics into the ModSAF baseline. However, enough technical detail and assessment artifacts are provided so that should a different prioritization for the OneSAF Testbed characteristics or different evaluation criteria weighting be desired, the reader should be able to reevaluate this recommendation.

5 References [1] "One Semi-Automated Forces (OneSAF) Requirements Document", OneSAF Integrated Concept Team Requirements Subgroup, August 22,1997.

[2] "OneSAF Analysis, Final Report", Document Number, SAIC-98/7768&00, Science Application International Corporation, 12479 Research Parkway, Orlando, FL 32826, September 26, 1997.



6 Acronym List A2ATD Anti-Armor Advanced Concept Demonstration AAFSM Asynchronous Augmented Finite State Machine AAR After Action Review ACR Advanced Concepts and Requirements ACTD Advanced Concept Technical Demonstration AMSAA Army Materiel Systems Analysis Activity AMSEC Army Model and Simulation Executive Council API Applications Programmer Interface ASCII American Standard Code for Information Interchange ASTAMID Airborne Standoff Minefield Detection System S AVLB Armored Vehicle Launched Bridge

BBS Brigade and Battalion Simulation BDA Battle Damage Assessment BEWSS Battlefield Environment Weapon System Simulation BIT Built-in Test BLUFOR Blue Force

C2 Command and Control CAS Close Air Support CCTT Close Combat Tactical Trainer CFOR Command Forces CFS Command From Simulator CGF Computer Generated Forces CIS Combat Instruction Set CSC Computer Software Component CSCI Computer Software Configuration Item CTDB Compact Terrain Database

DAR Data Analysis Report DARPA Defense Advanced Research Projects Agency DI Dismounted Infantry DI WS Dismounted Infantry Workstation DIS Distributed Interactive Simulation DMSO Defense Modeling and Simulation Office DMSTIAC Defense Modeling, Simulation and Technology Information

Analysis Center DoD Department of Defense DRA Dead Reckoning Algorithm DRC Daily Readiness Check DT Dynamic Terrain



DTO Dynamic Terrain Objects DVW Dynamic Virtual World

E&S Evan and Sutherland ECN Engineering Change Notice EM Environment Model EmTDB Environment Model's Terrain Database

FM Field Manual FRAGO Fragmentary Order FSM Finite State Machine FWA Fixed Wing Air

GCS Global Coordinate System GIDGET Graphical Interactive Database General Evaluation Tool GMI Generic Model Interface GUI Graphical User Interface

HAB Heavy Assault Bridge HLA High Level Architecture

ICT Integrated Concept Team IDE Integration Development Environment IDT Integrated Development Team IP Internet Protocol ITEMS Interactive Tactical Environment Management System IV&V Independent Verification and Validation

JCM Joint Countermine JCOS Joint Countermine Operations JTS Joint Tactical Simulation

LOS Line Of Sight

M&S Modeling and Simulation MCC Master Control Console MES Multiple Elevation Structures MGRS Milgrid MHz megahertz MICLIC Mine Clearing Line Charge MM Manned Module MMCM Magnetic Mine Counter Measure ModSAF Modular Semi-Automated Forces MrsTDB Multi-level Routing Support Terrain Database MrTDB Model Reference Terrain Database



MTBF Mean Time Before Failure

NFS NTP

Network File System Network Time Protocol

OC Operations Center OC WS Operations Center Work Station OPFOR Opposing Force ORD Operational Requirements Document ORSMC Off-Route Smart Mine Clearing

PDSS Post Deployment Software Support PDU Protocol Data Unit POP Persistent Object Protocol POST Power On Self Test PVD Plan View Display

R&D Research and Development RAM Random Access Memory RDA Research, Development and Acquisition RTI Runtime Infrastructure RWA Rotary Wing Air

SAF Semi-Automated Forces SAF WS Semi-Automated Forces Work Station SEDRIS Synthetic Environments Data, Representation and Interchange

Specification SEOD Semi-Automated Forces Entity Object Database SI Situational Interrupts SIF Standard Interchange Format SLOC Statement Lines Of Code SME Subject Matter Expert SMP Symmetric Multi-Processing SNE Synthetic Natural Environment SOM Simulation Object Model STOW Synthetic Theater Of War STRICOM Simulation Training Instrumentation Command

TAOS Total Atmospheric and Ocean Server TEMO Training, Exercise, Military Operations TIN Triangulated Irregular Networks TMD Theater Missile Defense TO Task Organization TOC Tactical Operations Center TWSTIAC Tactical Warfare Simulation and Technology Analysis Center



UCI User Computer Interface UID User Interface Data UIL User Interface Language UTM Universal Transverse Mercator

VV&A Validation, Verification and Accreditation



ADST-ll-CDRL-ONESAF-98000101

Appendices

Appendix A - CCTT SAF and ModSAF Behaviors

Appendix B - CCTT SAF and ModSAF Entities

Appendix C - Migration Assessment Detailed Data

i ON ON

m W oo % > O <

ä S Q U HH 1—1

H 00 Q <

□ □ □ □ □ □ □ □ □ □ □ □ □ □ 5

ffl n n □ fa Bs| □ S t Rib

S- o > -a M

CN

fa < 00

H H U U

s

O

J3

5

fa < 00 -o o

00 H H U U «4-1 o e o

• i-H +-> o

JD

*o o u

Ö

-3 cs a»

a

on Ö o VI i-i

o o

1>

•S a

5

ö o o o

W

1/3

a S t/3

S, w >

<

§ o P 00

co C 00

H U

o u o'

w > o

o p Q

§

•8 c

O

w

H P U pa X w

H -I

W H

8 p

c 0ß

■s c öJ)

e •s c ■s

Ö

O o Z

o Z

o Z

o Z

■S

o

c o a o c o e o c o c o s o co

I to

s pa

CO CO

pa

CO

P3

CO

cs CQ

CO

pa

-a O "" PH

P ►J pa

pi o PH

P l-J pa

PS1

o P-. p oa

pi o PH

P J 03

PÜ o

pa

pi o PH

3 pa

pi o o

oa pa

•S St a en CO c/a V3

<, < o 2

o CO

s pa

o B S S

oa

□ □ □ □ □ □ □ □ □ □ □ □ □ □

00 ON ON

00

<

CO

5 n n n n ~ rA

Bio

DC o

GO Pi Ü w <*

o 00

5 > w

l-J u

00 pa

w D o

00 00

>

<

<

pa

Q1

<

3 < o H O

to a o

u

E < s

PH

W 1 w1

H O <

00 00

| o J3

a 0)

s § S u s p 5

> o

OH

P U o o

o

w OH

w s O _1 5 El 3 a

ca 1 o

oq P 00

<

pa

u w X a

w Q

P oo

1 u B ca U

u e ca U

o

U

ta D, CO

(5 ca LH "05 ca

'S »—i

J3 J£ JD _a> ju u <D <L> 0> a> ca

CO Ö 3 3 3 3 3 JJ x> -o -3 -2 Sb CB C3 ca ca ca ca ca ca ca ca "« a

op ca a .SP

B .SP

B .SP

B .SP .1 B

.SP B

.SP s

.SP .§> d> u CD _a> ca ca ca ca

< 'co CO 1 *CO

CO 'co

CO *co co

*co CO

CO CO

'to CO

'co CO

'w CO

CO CO « i Ü 3

ca 1 1 1 1 <. c

00 <. <. <. <■ <. <, <, <, <. .1 up a .SP .1 .SP

c CO | 1 [ 1 1 1 1 1 1 p +-•' CO CO "co "co *co CO *co "co CO

O CO o o o O o O O o o CO CO CO CO CO CO CO CO

z < Z Z Z z z z z z z < < < < < < <c <;

p a 00

1

>]

erf i-J < > <

z Z Z z z z z z z z "3 Q o o o o o o o o O o

O

HH >-H HH

P 3 J J J hJ ►J HJ J J J < < < < < < < <: < <

c3 t- (_, J_

t: L.

t; £ £ £ fc £ H £ t t H cä t!

C8 C3 ca

<, < < < < < < < < < < o

2, o o O

2, o o o o

| PH Q

erf1 orf1 prf' Pi1 pi1 Pi' Pi1 oi1 erf1 Pi' Pi' Pi1 pi1 Pi' erf1 oi1 Pi1 Pi'

o o o o o O o O O o O O o O O o o O PH PH PH s PH b PH PH PH PH PH PH PH PH PH PH PH B Pi 5 Ä p P p P P P P P P P P P P P P P

Q J P HJ J J J J J J J ►J J hJ J ►J KJ -1 J J J < ca < pa pa pa pa m pa pa pa pa P3 pa pq pa pa pa pq pq pq

a o e a B B B B a B B B B a a a e B B a a ca _o o _o _o O _o o _o _o O O o o o o O O o o j3 o cä ca ca CS ca ca ca ca ca C3 ca ca ca ca ca C3 ca ca ca

W a tJ t! t! ts ts ts ts e a C e fci ti ts n e e e s C3 e3 03 ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca pq m m oa m pa pa PQ pa pa P3 pa pa oa oa pa CQ pq pq

4> 12

erf Crf crf oi Pi Pi Pi PS1 Pi Pi Pi erf erf erf erf erf erf prf erf O O o o o o o O o o O o o o O o O O O

bo s P PH

P He P

PL,

P 5 s 5 PH

P PH

p PH

P PH

p PH

P s PH

P PH

P s s B J ►J HJ HJ _l j J j J HJ HJ J _l -J J J HJ HJ j CQ m pa pa m pa m pa pa pa pa pa oa pq pq pa pq pq pq

i <

00 1

< t/3 f,

W 00

z JH o <C

ä ^ 00 Q z U o H-( 1—4

1

H < W

00

3 c O

^

CO

d o

3 o p.1

o,

PJ PH

o K1

o ca *S 1-

2

Hi

O 1 1 >-

S PJ

w1

Ü < O*)

<

PH PH ca

O

o o1

o JH

•3 d

o1

13 u d

"o ca

■*-» CO

o 1

O

O. 3 CO

<L>

3. Q. 3 CO <L>

d _o 'co

CO

'S

^1 S

> < w

s1 w1

>

1 PJ on on

<l

P on

I' cj (3 <L>

C3 0)

o c3 i>

o ca

o ca c2

CD

c2 CÜ

13 _d

CL>

CO _«> (D M u ÜJ _a> o _aj J2 ID o _o> (U _a> <D CO

< 3 3 3 3 3 3 3 3 3 3 3 3 5 3 5 3 ^ eS ca CB a ca ca ca C3 ca ca ca ca ca CS ca ca ca IM C d d d a d d

.!> d d d d d .1 d d d

0) .SP 60 .60 60 .SP .SP .SP 00 Öß M 00 6B 60 60 60 w p *co 'co 'co CO 'co 'co *lo CO CO CO CO CO CO en CO CO CO

CO CO CO CO CO CO CO 1/) CO CO CO CO CO to CO CO CO

< < < < < < < < < < < < < < < < <

o o o o o q o Pi e, Pi

-, Pi ^1

pi e, ^ >-' >-' >-' >.' >-' >-' Pi Pi Pi Pi Pi pi Pi H-l J ►J J ►J J -J <; < < < < < < > > > > > > > < < < < < < < □ o. o. o. Ü. o. o. o, □ '3

P Q1 o1

Q1 Q1 Q1 Q1 Q1

□ D □ □ □

§ s § S § § § S3 t; O

1M

CO

1 S3 t: o

c3

O

ia o

ca

o

[3

o

c3 ti o

O o O o o O o

s. s. s. s. s. s. s. s. s. s, «, <, <, <, «, <, <, □ Pi1 *' *' Pi1 *' Pi1 Pi1 Pi1 Pi1 Pi1 Pi' Pi1 *' Pi1 Pi1 Pi' Pi1

□ o o O o o O o o o o o o o o o o O b p s s 5 b

p b p

b P

[3H

P P p b P s b

P PH

P PH P Ä

b P §„ □ P _) ►J ,-J _) _J HJ J J J J OH J 5b J SJ

J & -1 & J & -" & □ m CO PQ oa CQ pa PQ pa oa P3 m o oa o pa O oa o pa o oa o pa o

□ □ □ □ □

CO >-. O

d

"«3 d o

d o

d o

d o

d o

d o

d o

d o

d o

d o

>. >. §

>% § d

ca

>> >> d ca

>% §

u PJ

C8 ca CO ca

1 cs

1 ca ca ca

1 ca ca

S o

Q. B o i

O. a o

sx B o

D. B o

S o

1) 05 (x,

ffl oa pa oa PQ m PQ PQ pa oa U u u U O O O

□

DD

DD

D

9800

101 <

00

3 Pi pi Pi Pi Pi oi Pi Pi Pi Pi Pi Pi Pi Pi Pi Pi Pi

H H U

o o o o O o O O o o o o o O o o O 33 b

p s b P P s b

P b P P P s P s § &

PH

P b P s

>-J J J J ►J -I HJ J HJ pj J J J J HJ KJ J O CQ PQ oa pa pa pa PQ pa pa P3 pa PQ oa pa m pa pa

f>

00

^ ON

< m ^ W 00

% ^ O <

ä s Q U h—1 _ H 00

D D D n □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □

CO M o

'g ffl

H H U

D^u

X) 03

.1» CO CO

< I- o> CO

p

"2

> o

§ u GO

•s .1

CO CO

<

Ü 5 00

> W

O 03 D oo

■8

§ 3

O Ü

o 00

pi > u W, w 00

1 < J Ü Z w Q

1

S > o

o

00 < 5, 1 H H

00 U U £ D P O O Q H Z Z U o O H

U H w 00 X a S

w

Q

e •s a W)

ea c 00

o Z

c 60

o z

e (50

o z

a

o z

XI a a ao

o Z

■S e WO

5 o Z

•s

o z

u

•S & 5)

3 o Z

pi

>

3

o

O

ex S o U

D. 6 o O

CX

6 o U

ex S o U

e a. S o U

c 03 CX

6 o O

ex S o U

a, S o U

a, e o U

ex S o U

!■ o U

g a. e o O

Pi o

pa

oi o

Pi O

s s pa CQ

pi o

►J pa

o P j pa

o p

pa

pi o ft, D J CQ

Pi O

pa

Pi o Pi o o B B S pa CQ pa

Pi o

pa

00

Q

•S

o Z

■

g ex S o O

Pi O fin

P

pa

00

Üi ON ON

< xr\ W oo

£ ^ o <

ä S Q U M HH

H 00

□ □ □ □ □ □ □ □ □ □ D □ □ □ □ □ □ □ □ BIS

c/5

O

"g ■s CQ

© M

o H

oo

s 1> p

*0 t/1 CO J-H o <

w1

PL, W

Q.

B o 'S tH D ex

1' 5

•o C3 o

■z _o

'S s s

5

ß _o ]^ 'co O

*! CL>

to E a> +-»

HB CJ CO

5

o C0

5 s o IM

D IH

5 u

■3

2 13 in

CD

.3

JJ "u

CO ■*-» co

w o CD

u CD

5 2 5 3

ß

o1 5 O

p 00 3 1

u c

"53 o B s o

<L>

to D. P

^ _o ca > o

u1

> o

1 u C0

i o C0

i o co

i o CO

i o CO

"CD

a § £ H

CO

U u o Q PH "co 5 Pi Pi

CD

PS Pi

5 JB _CD CD cd B 3 3 3 So co CO CS

'to co .1 B

.SP ß

.SP Ja — _o _o> JJ _aj J2 _aj -H

u CD CD — _ea JJ JD

C/3 '« 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 c/l cd cd co CO CO co co co CO co C0 CO CO CO CO C0

u* <. <, <. s B B B ß ß ß ß B ß B ß e e B s <u 00 .SP .SP .SP .SP .SP .SP ao ÖD 60 Ö0 ÖO Öß oo 00 00 OT | 1 p +-*1

'co *CO *crt *w 'co 'co *lo CO co co CO co co co co co o o o co VI co ert co co co co co CO CO co co co co co

Z £ £ < < < < < < < < < < < < < < < <

o O o Di oi pi ^, h ^ >-' >-' >-' oi P51 P* hJ J J < < < > > > < < < <->, O, ü, Q1 Q1 Q1

p 3 O

3 O O fr fr b b & & & & b fr fr fr fr fr fr fr

CD CL> CD <U ■2- JZ CD <u CD <D CD CD CD -H

K P5 Pfi C t 't; c tt tt 't: c c C t: 'v. l, t: C V,

<. <, <■ <. <■ <, <, <, <, <, <, <, <, <, <, <, <, <, *' *' P-' *' Od' PH' *' PH' Pd' p-1 Pi1

PH' *' x[ Pi' Pi' PH' Pi' Pi1

o O o o o o o o o o o o O o o o o o o s B s PH

P & PH

P fe PH

P PH

P PH P

P- P

PH

P PH

P s § s s PH

P PH

P j fu P &H HJ O< _) _) J J J J HH HJ J J J hJ J HJ HJ hJ CQ O « o CQ o CQ m CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ

"33 p^ >» >. >* >% >-. >-> >> >^ >. >^ 5^ >* >^ >> >> >^ ^» ^ & co § § S § S B

co § § g ß co § § a ß

co § § § § ■fl O. D. D. o. CH n. D. o. D. a. D. o. o. & D. o. a. o- o. o E E E a B E s S s S E s S £ e S e E E

o o o o O o o o o o o o o o o o o o o U O u U O U U O U o U u U u U U O u U

CD

rs P51 PS" <X P< PC Pi PÄ & PH pä eej PC p* PÄ e. PH PÄ Pi P: O o o o o o o O O o O O O o O o o o o

»3 PH P

pH p £> PH

P PH p

PH P

PH

P PH

P PH

P PH P

PH

P PH

P PH P

PH

P & B § § s J p j HJ J J ►J J hJ J J ►J J _) ►J ►J h4 J hJ CQ ca CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ

I

<

PL, ON < 1—1

rr\ „ w 00

z >* O <

ä 2 Q u HH )—i

H &Q

n n n n n n n □ □ □ □ □ □ □ □ □ □ □ _ □ © HS □ ©

00

00 Z o H

2 W

Ü

a s CD

"8 OH

o 1

00 <

O H1

_1 H 1 H P Ü U J

*. Ü U

< 00 s (S Z

PJ > £ s Z

CD

E 3 EX

c _o 'co

CO

s. CD

'S .g

00

o P Q

w >

H P o

00

O 00

H

Q

P 00

<

o

00 H W Ü Pi <

Ü <

00 H W

Pi

o <

KJ w >

p O

00

§

O 00 00 1

3 3 E Z W H Z J CQ Ü Ü w H Z CO CD

PH Pi £ o u X PJ <

o u ss s P 00 § § X

w O u

-3 3 CD <L> CD _aj Jjj a> cd c 3 3 3 3 3 3 -2 -o CJ) CO co CO CO CO CO CO CO

*co JK _o> u CD o c .SP

c c c .2?

c .SP

c .2P

CD a> a> .1 .1 < 3 3 3 3 3 'co 'co 'co 'co 'co "co •s H5 ^ CO CO

co 03 CO CO co CO CO CO CO CO CO CO CO CO CO CO

0) c

.SP c

.2? c

.SP 00 .1 <, <, <, «, <, <, c

.£P .1 c .SP «, <, co

p CO CO CO CO CO 1 **> ^ 4-1 1 +-' *co CO '35 *-' <-.'

CO CO CO CO CO O O O o O O CO CO CO o o < < < < < z Z z z Z z < < < Z z

PH 5 PH

z < OH PH

1 z < PH PH

>-

5 < < 1 s o o

2 o o o o o 1

o o PH

s o u,

PH

s o PH

s o u o u, o o o o o o o o o o1 o1 o' o1 o' w u w w PJ w PJ J hJ J J J

*J E, K, K, 1 =1 K, E, Kl

PJ Ö s s, s, 'S D H1

3 H

P> «' «' «' «' «'

C? fr c? P P P P p P o u u u u O U •is < < < < < < < < <; ^ ^ «; ^ t t ti

00 00

00 00

oo oo

00 oo

00 00

00 00

00 oo

00 oo t p t t fc

<, <, <, <, <. <, <, <, <, <, <■ <, <, <, <, <, *' Pi' oi1 Pi1 *' *' *' Pi1 Pd1 p> o-1 Pi1 Pi1 Pi1 oi1 Pi' O o o O O O O O O O O o o o o o D P

PH

p PH

P s PH

P PH

P s P- P

PH

P PH

P PH

P PH

P § § s J _) J H4 J HJ J J J J ^ J „ -J J J HJ hJ CQ CQ PQ CQ >- CQ ^ CQ > CQ >- CQ >* CQ > CQ >« CQ >* CQ CQ CQ CQ CQ

o >> >^ >> >> >. >% >. >% >> >> >. >% >v >> >. &• e c e a § c c c s c c c s c H s "5 S co co co CO co CO CO CO co co CO cd cd cd J3 EX EX EX EX EX EX EX EX EX EX EX EX EX EX EX EX u W 6 E E E E E E E E E E E E E E E

o o o o o o o o o o o o o o o o U U U U u U U u U u U u u u U u

12 oi Pi Pi Pi Pi pi P- Pi eS Pd Pi Pi Pi Pi Pi Pi O O o O O O O O O o O o o o o O

GO s s PH

P PH P

PH

P PH

P PH

P P-, P

PH

P PH

p PH

P PH

p PH

p s PH

P B J J HJ J hJ hJ J J J HJ J HJ J hJ KJ J ffl m CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ

I

<

□ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ _ □ o HS

o '£



U H Ü z <, § O

s NM

5 P

PJ

H > g

PJ

PJ PJ > H U PJ •—> CQ

>- J

S T3

o

00

00

PJ

00 O

t< s PJ Z

> H U

W

U

O

CQ o

<

> CQ

PJ

HH 00 O

> o

5 PM PH

P 00

3

00

PJ < H U <

H KJ

D 00 < PJ

PJ

> PJ

3 oo CQ o, i

H HJ

P < oo

 PJ

3 g 5 < o

< y

U 1

i H

W

< s 3

oo O z1

5 < Q H3 Q

00 oo

t' oo

5 1

W N

z <

< 00

UJ1

U

<

Pi o

5, oo

§ P

00 O

H s PC p U u o J5 P PH o o 9 2 o § PJ

Q

P 00

o CQ

< 00 ES

CQ

oo z E

PH U PJ

P U

pi o g o 03

p- PM

P u <:

O o S3 3 P

00 00 < <

o u w Q

X PJ o pj

PH PJ PH § 00

P 00

P 00 £ <

H3 _CU JJ cu a> CD (U CL> TO C 3 3 x> .O .o •s •2 Sb CO co ca C3 C3 co co

'co c .SP

e .SP

B 00

c 60

c 60 — ja J£ J£ — _u _o eu ja _cu 4> .B ,22 .22

c ,60

c .SP

< "en "t/1 *tvi 3 3 3 3 3 3 3 3 3 3 3 3 3 3 'co *co CO CO CO CO CO co CO CO CO co co CO CO CO CO C3 CO co co CO CO

<L> <, <. <. <, <, c 60

c 60 .1 s

.SP c op c

.SP s

.SP c 00

c 00

c 60

e 60

e 00

c 00

c 60 <, <,

CO 1 i . J . J p +J1

■4-*' 4-» -»-» 'co 'co CO *CO "co '« *co CO en CO CO CO CO CO 'S +■* O o o O o en CO CO CA en CO CO CO CO CO CO CO CO CO o o Z 2 2: Z Z < < < < < < < < < < < < < < z z > > >< > > Z Z Z z z < <

PM < eu

< PH

< p-

§ s £ 2 £ O O o o o Ü. O, o. <->, s s S s s s s s 5 s £ s s 2 s s o1

w o1

PJ

1 o PJ

o1

PJ

o1

►J PJ

< < < < < < < < < < < < <; < < <

", B. PJ

", PJ PJ PJ PJ PJ PJ PJ PJ

^ s, PJ

f-,

'S D

Kl Ki sl Kl Kl >' >-' >-' 1

:*' >-' >-' >-' ^' ^' >«' >' >-' JH1 ;*' >-' *' u a1 a1 a1

(J z z z 2 z z z z Z z Z z z z z z < < < < < < < < < < < < < < < <

£ £ < 2 £ PH PH

s PH PH PH

2 PH PH § PM P- PH PM

2 1 § § H H E- o o o o o o o o o o o o o o o o

<. < <. < <. Ü. o, o. o, o, Ü, u, o 1 o, o, o. u i ", o, o. ",

*' Pi' Pi' Pi' Pi1 Pi1 Pi1 ^ Pi1 pi1 Pi1 Pi1 Pi1 Pi1 Pi1 Pi1 P.1 Pi1 Pi1 Pi1 Pi1

o O O o o o o o o o o o o o o o o o o o o P- PH u. PH PH PH ÜM PH PH s PH PH PH PH PH PH PH PH B &

PH

P P P p P P p p P P P P P P P P P P ►J ►J J J J J J HJ hJ J HJ J J HJ J -J HJ HJ hJ ►J HJ

CQ CQ ffl CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ 03

o ?►> >-> >% >> >% >> >> >> >> >> >> P^. >% >% >. s^ >^ ^ >» >> >^ c c c c c c § § e c c c s c c e c c c s s "33 3 3 3 3 CO CO co co CO CO C3 co CO CO CO co co CO CO

43 D. O. a. n. D. a. a. a« O. a. o. a, ex a. a. a. p. o. D. D. DM u

PJ B B a S S 6 S S S S s B S B B S S s s B B o o o o o o o o o o o o o o o o o o o o o O O U U U U O U U U u U O U U U U U U u u

."2 Pi Pi pi Pi PH oi PÜ Pi Pi Pi Pi Pi Pi Pi Pi Pi Pi Pi pi Pi Pi O o o o O O O O o o O o O o o o O O o O O

co s PH UM PH PH PH PH 5 PH PH s PH PH PH PH PH PH PH PH PH PH

P P P P P P P P P P P P P P P P P P ►J J ,-J J J J ►J HJ J J J J HJ J J J ►J HJ HJ hJ HJ

CQ m CQ 03 CQ CQ CQ CQ CQ m CQ CQ CQ CQ PQ CQ 03 CQ CQ CQ CQ

00

PH ON ON

< m W oo £ > O <

ä %

Q U h—H HH

H t/3

□ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ Bs| U o\ U

Kl

o • I—t

5 0) m

00

Ö o öS

■s tu

o.

o CQ

<

1 o

o pH D m

§ ex S o U

u O

oo

I 00

O

Ü Ü O w

Q Q

O m

o m

3 00

O PÜ 2 ei n <, ", PH H1 z OM

s <

o P O

Ü

* o < > *i w Q H ^ LJ > PJ u H P. tu 00 PJ Q

X SS

00

U

w u

oo ffl O

P1

w

o PH

ü

o. o. o.

PJ J Q

O

< PJ PJ > > >

2

C8 c 3 <

H CO G O

Ü T3 G <

K o1 o1 o1 o H

u o u u t)

^J es (3 S3 cd ert fY< <L> <L>o<L><L>a>£>a)<L>&><Da>oa>a> §333332333333333

co .£p .£P .£P ,£P .£P .£P .5P .£P .£P .£P .SP .£P .£P .£P .SP ^ -rf* "co "co "to *co *co "co "co *CO *CO CO CO to CO CO CO -£ ^COCOtOtOtOCOCOCOtOCOCOtOCOCOCOCQ

s 3 3 5 3 5 5 3 5 3 3 3 3 3 3 3 I ^Dooooooooooooooooo < <

<

s o

o. u.

o D

<

o

s o b

J ffl

pq

PH

s o

o

I cu

O

o U. PH D P HJ m m

PJ

P- S o o

o PH

HJ CQ

<

? < PH

o u

o PH

D J PQ

< PH

S o

o PH

D m

<

PH

o

5 o PH

m

<

PH

s o

o PH

HJ m

<

> $

z p^

o o

p.1

o PH

D m

o PH

D m

<

1 o o ül 3 Pi

o PH

D HJ ffl

Pi o

HH m

<

PH

o

o PH

D HJ m

t3fl 61) an a G .9 tH (H »H (L> ca 4> 0) <L> U

.9 G G CU) ÖÜ CU) e G G

PJ PJ PH

Pi o PH

D HH ffl

PH O PH

m

p- o PH

D HJ m

60 ,G 'C n> u .9 M

pd o PH

D J ffl

60 .G 'C a> <a G

"51) G

Pi o PH

_1 ffl

cx 6 o

a. S o

U U

g s o U

a, E o U

G CB D. 6 o O

§ a. S o U

§ S o U

S o O

cs a. 6 o O

S o U

9 o U

a. S o U

G G C8 C3 a. a 9 9 o o U U

9 o u

p. 9 o U

G CB a, 9 o O

c C3 D. 9 o u

cx 9 o u

O

HJ HJ m m

aJ si o o

PH

HJ m

cd Pi o o PH PH

D D J HJ m m

Pi o PH

D J m

pi o PH

D J m

Pi o PH

m

pi o PH

o ffl

Pi o p» D ffl

Pi o PH

D ffl

Pi O

Pi o

s s ffl

HJ m

pi o PH

D HJ ffl

Pi O PH

D HJ ffl

Pi o PH

►J m

Pi o PH

P HJ m

Pi o PH

D ffl

Pi o PH

o HJ ffl

Pi o PH

D ffl

ctf. CX

Pi

1)

1) Pi

x> JO x> -O JO ct) m ca C3 en G c G c G 6U 00 ÖD 5D 6Ü

_G 'u u ej

.9 c

S' Pi O PH

D m

cx 9 o U

Pi o PH

HJ m

00

< ON

m W oo

£ ^ O <

ä s Q U 1—t h-H

H

Q <

n n n n n n n n n □ □ D □ □ □ □ B_« Do»

Bio

l-H O

5 ffl

■s e oo

a o "3 XS u W

u "2 35

s

•s s 00

60 .a 'C

CD

.9 60

5 Pi O to P CQ

a, S o U

O

c o

XS o X! O is

e X) u 'J3 e

ex V3

ffi ffi P Q H

c o

CD CX

o

ex a. 3 c/i u

öS.

0) P.

o

u es C <

E

9 o

x> co 'S o o I w -S

o (8 co

X>

ID

J ,s

Pi. u.

<L>

«3 a> e

13

e o

o &l 60 .9 +-> X! eo

60 •o 'C

o

J2 u

Q

«' O. 43 u

C3

CQ

O. W

B O U

a o U

o C3

03

a o U

o

a

Xj ">

> CD

'£ Pi

B S3

x) <D (IJ x> 60

«3 2, 12

.9 J m, S, o

Fi >J P _* C/3 h

fn B c/l

S O

Q

•8 •s B 50 w .PH .-H~ .*H-

■s B 60

•s fi 00

X) CO B 60

X) ca B 60

•8 OX)

x> B 00

XI ca

a ■s B 60

•8 a eo •s E 60

■s B 60

•s ■8 ä §b

•s B oo

-8 -8 B 60

60 .g 'C

eu g 'eo c

o p-, D D3

60 c CD V g

'5b B

Pi o D CQ

60 .g 'l-

0> CD g

"Sb s

S' Pi O

P J D3

60 .g CD CD g

'eb s

Pi O b- P

pa

60 .g 'C

CD CD g

'eb B

pi o P J oa

60

.9 CD CD g

'5b

3 pi o PH

P J CQ

60 .g CD CD

.9 60 a

2' pi O PH

P m

60 B

60 a

60 .9

Ii *" is CD ID .9 60

5 pi o fe P CQ

u CD

.9 60

pi o

CQ

CD CD g

'5b a

2' pi O PH

P CQ

60 a

"C CD CD g

'5b a

S' Pi O

pa

60 .9

CD CD

.9 60 B

pi o

CQ

60 .g 'C

CD <L>

.9 60 B

Pi o

PQ

CD CD

.9 60 B

Pi O PH

CO

8 o. 9 o O

9 o O

8 ex 9 o U

a ca D. S o U

8 9 o O

8 D. 9 o U

8 9 o U

8 D. 9 o u

o. 9 o O

>. >-. a B <tt ro n. D. 9 9 o o U u

Ou 9 o O

8 ex 9 o U

8 ex 9 o U

ex 9 o U

I ex 9 o U

ex 9 o U

8 ex 9 o U

8 ex 9 o O

Pi o

oa CQ

Pi o PH

P CQ

Pi O PH

P

pa

pi o PH

P

pa

pi o PH

P J CQ

Pi O PH

P

pa

pi o PH

P

pa

ci o PH

P J pa

Pi o PH

P J CQ

Pi O PH

P HJ pa

pi o PH

P

pa

Pi o to P oa

Pi o to P CQ

Pi O to P oa

Pi o to P

CQ

Pi Pi o o

CQ PQ

Pi O to P oa

Pi o to P CQ

■8 B 60

VI VI VI VI W VI VJ VI VJ VJ VJ VJ VJ \*i <*J VJ «J WJ <*J -' -'

<<<<<<<<<<<<<<<<<<<<<

60 60 .9 .9

CD CD

.9 60 fi

Pi O

CQ

8 & 9 o U

Pi o

■ <

00

< ON

tn (V

w oo

Z > o <

ä s Q U H-t hH

H CO Q <:

n n □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ ^ □ o HS

to

o

a> CO

CO

H

o M CJ ca <D

CO u ta

s _o *CO

CO

5 c 3 O

l-C

5 CO <L>

c

o1

5

o C3 2

«a C

o

^1

"o ca +-» CO

XI 'S ex <D

Od 1

CO CD

o ■*-» CO

CL> u

4Ä o o

■»-» CO



'C o

X! ü

"S CO

3 > o

a. CO

CD u

u C3 CO

o c3

U CO D

Ü ca eg

ca 3 a- CD

> O

2 ca

o CO

E 1 1 X! +-» 3

ex CO ><

•4-»

ca s X O H •a Crf erf Pi DÄ eä Pi p 00 w < H < 'Q W K

CO c

.£P 'co <L> a> a> CO a> CO u CO <L> CO CO co u CO co

CO

< X) X> X> X> X> X3 Xi x> X) X) X> X3 x> Xi X) Xj X> XJ X> X> X> C3 CO CO ca C3 ca C3 C3 CO C3 ca ca ca ca C3 ca ca ca ca C8 ca

.1 c op .1 c

60 3

.2? c

.£P c

.£P .1 e .2?

C .op

c .op

3 oc

c 3 00

3 oo .§> .1» c

oo .1 3 00

3 00

en p co 'co CO *CO "co 'co *co VI 'co *co 'co CO CO CO to CO CO CO CO CO CO

co CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO

< < < < < < < < < < < < < < < < < <: < < <

-♦-» ■*-» •4-J CO CO CO CO o o O O

#4-» fcl fci *l *l 'S

p x»1 T31 T)1 T31

3 t: t t! ts tS ts ts t: ts c V, tt t; ts ts ts ts ca

E eo C3

E o O o o O O O o O o O O o o o o o E P a D. CX CX cx CX ex cx CX cx cx CX CX CX CX CX ex E E 3 E a CX CX ex ex cx ex ex cx ex ex ex CX CX CX CX & C- 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 o o O o

00 oo 00 00 00 00 00 00 00 1

00 00 1

00 1

00 1

00 I

00 1

00 1

00 1 u. u. u. °,

erf1 erf1 erf1 erf1 erf1 erf' erf1 *' öi1 *' *' Pi1 erf1 prf1 prf1 erf1 erf' erf1 erf1 erf1 erf'

O O O O O O O O O O O O O O O O O O O O O b b b b b B b tu u. tu b tu tu b b b s b S b

& P P P p P P p p p P p p P P P P P HJ J J J HJ j J HJ J J J J J _) HJ J HJ HJ J J J 03 m m « 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03

e o >> >> >-. >> >^ >> >^ >. >. >. P>% >-. >^ >. >> >> ?^ "5 c

C3 S § § § s ca

c ca § § § § § § c

ca § § 43 D. a, CX ex ex ex CX CX CX CX ex ex ex CX CX CX ex w 6 E E 6 S S s E E E E E E E E E E

o o o o o o o o o o o o o o o o o a* cy C3" o" U U O U U U U U U U U U U O U U O X ffi X X

CO

."2 a: erf erf erf erf erf Crf oi oi oi Pi erf Pi Pi Pi erf Pi Pi erf Pi Pi o O O O o O o O O O o O o o o O O o O o o

00 b b tu fx. b b b s tu tu b tu b b b 5 b b b § b P P P p p P P P P P P P P P P P P P J _> J HJ HJ J J J J ►J J »-I J J J j _J J ►J H-l J CO PQ m m 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03

©

oo

< ON ON

r/> n

W 00

Z >« O <

ä s Q U HH hH

H 00

n n n n □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □

O

'g m

&0

H H U D &Ö

z o p oo O *i

T3 < u1

> o

CO C O

1 M Ü

00

Z w eu D. O

o CO

< CU

2

W P U

5 p w W

03

O O P

CQ

PH

w

tx 3 CO CD

CO

5

■a1

B 3 O »-,

u

c

o1

3 cu B

? 3 ■S en

3 LH

'3 a.

■4-»

c

E _o *en en

S, <L> -t-2

S w H P

1

> P o 55 w

o

Ü 09 OO

5 s pq 00 oo

H 5C Ü

5 T3

(D > O

CU PH

cj CO CU

Pi

u CO

Cd

o co

pi

cj CO CU

Pi

O CO eu Pi

CO <L> 3 a-

Pi o

35

CO .B

<L>

H

o S 00

Q

p u w X w

P O w X w

PM

P u u o

W P Q

CH

p u u o

PH

P U u o

00

3

-2 3 _4> CU CU cu CU 03 a ap

'co en

<

3 X> X> X> HO CO CO eo CO CO

— -2 JU _u B — _a> _- _u _4> _0J — eu _a> M JB .!> B

.SP B

.SP .1 .1» 3 3 3 3 3 3 3 3 3 3 3 3 5 S 3 5 en "en "eft en CO CO co CO CO co CO CO CO CO CO CO CO CO CO CO CO CO eft eft en CO

Ut a E a c c s B B B B B B B B B B <, <, <, < <

a> 60 SP .SP .SP 60 ÖJ) .SP ap .SP .SP .SP .SP .SP .SP .SP .SP ^l ^1 CO

p 'en W5

'en CO

"co CO

'in en

'co CO

'co en

"co en

"co CO

'eo en

"co en

'en CO

"en en

"en en

"en en

'co en

'en eft o o O O

4-1

o < < < < < < < < < < < < < < < < Z 2 ^ Z z

z z ^ Z z Z Ä Z z z o o o o o o O o o o

Cft o

en O

CO O

CO O

co O

to o

to o O O O O o o o o o o P o o p

■y p-, Pi, P*. °i, °-, P*. Pi, P"1, ^i P-, ^i H H H H H H H H H H 'a P ■o1

e •o1

a •o1

a ■a' B B

■a1

B W §

T,1

ß T51

B •o1

s < <

p < P

< P

< P

. o. u. t>. O. O, U. Ü, <•>, v. <, <, <, <, <, <i <l <, <, <, *' *' Pi1 Pi' *' Pi' Pi' pi1 Pi' Pi1 Pi' Pi' Pi1 Pi1 Pi' ai1 Pi1 Pi' Pi' Pi' Pi1

O o O O O O O O O O o O o O O o o O O o O P- D

PH

p PH

p P P PH

P PH

P s UH

P P p P tt-, p P

PH

P PH

P PH

P B £ § § P P P P P J ►J p J J J P p P P P P p p p P CQ CQ ca CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ m CQ CQ CQ CQ CQ CQ

c o 3 B B B E B B B B B a J3 O o O O o O O O O o o o o o O o O o o o o W

-t-» 4-* +H ■4-» ■t-i -M +2 a* O" a* ty ty ty tr ty ty a* ty 'S eo _2 CO CO 'S CO eo CO CO

X P X ffi P ffi S ffi ffi X DC E E E E E E E E E E

"2 Pi erf pi Pi a! Pi Pi Pi Pi Pi Pi pi pi oi pi Pi pi pi Pi Pi ci o O o O O O o O O o O o o o O O o o o o O

i35 PH PH b P- PH u- P. s n- Ü- ÜH b PH PH PH PH PH PH PH

§ £ p p P p P P P P p P P P P P P P P P P P P P P P J p P J J P P P P P P P P p p CQ ca CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ CQ

00

< r/> W oo

£ ^ o <

ä s Q U ►—1 HH

H 00

□ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □

C/3 u O

'g X3

CQ

H H U

DSu

>- O 0 >

O u.

s > 0 O

H < §

«' w1 £ H (/1 00 erf CO

§ § > H O to

to w

to w O 1 § H >-

5 3 a 5 Q

O

CO < O

to D U O

O 0 Q, K, s, O S S s co1 1

CO «/>' co H H O to to to to 00 00 CO <J U O U

•s a 60

00 .a* .a* —

XI X w CO c c 60 60

X) CO C 60

O 1 .»

O en

w >

CO to U

to

*<

S to W Q

Q W H

O

a <

§ 00

u

w >

o S (Z)

Q

to

CO

CO

J CQ < H CO to

c 60

XI CO a 60

X) CO c 60

•8 X) C3

Xi CO c 60

■s c 60

•s c 60

•s a 60

D u w X w

X co s 60

c o o CO

to* O to D J (23

c c o o o o to to

Pi o to D J CQ

O to D CQ

e o o 'S

oi O to O J CQ

e o o to to

Pi O to D J CQ

c o o 03

to

Pi O to D J CQ

c o o to to

Pi O to D _! CQ

e o o to to

Pi O

CQ

ö o o

to

a: o to

►J CQ

c o o to to

Pi o to D CQ

c o o 'S to

to1

O to D

CQ

c o o to to

Pi O to D J CQ

e o o to

Pi O to O J CQ

•8 c 60

c o o to to

to- O

CQ

M

1

<

00

< ON Os

r/) W 00

% >H

O <;

ä S Q U 1—H HH

H t/5

D n n n n n n n n □ □ □ □ □ □ □ □ □ o DSL

BI8

u O

i> ffl

%

H

'S a 00

u 53 >

O

■8 c 60

a o o

^ 00 ,-1 w

s 00 tu oo o >.' w

P < 00

U 00 u <r u OH

•s c 00

D 00

H Z w w > o s, z w s u oo

> *—I oo oo

§ P 00

u w H _l o,

2 oo CQ O

1 H a <f '6 C/3 i-i w > § 2 H

U <

H U

Ü oo

H U <

■S c 00

C3 c 00

c 00

CO c 00

c oo

c oo

o Z

•8 ■S CU

bh oo 60 co CO

Xfl CO CO

<, «, <■ .J •J ■J o O O Z Z Z

> <

a; < > <

§ §

o ft, P CD

Pi O ft, D £Q

8 c oo

o Z

c o o to E

c o o to E

c o o 'S E

a o o 'S E

c o o

E

C o o to E

Ö o o to

c o o to

c o o to E

c o o os E

e o o

E

-a O

CQ

Pi O ft P CQ

Pi o ft P J CQ

Pi O

CQ

Pi O ft P CQ

Pi O ft P CQ

Pi O ft p CQ

Pi O

CQ

Pi o

CQ

Pi O ft, P CO

Pi o ft, p J CQ

Pi o UH

P J CQ

>-> 2

o H O

H P Q W X PJ

•S c oo

o Z

c o o ts E

pi o u, P J CQ

■ <

■<r 00 r-i

I

<

ON ON 1

< Xfl r,

W 00

% ^ O <

ä s Q u h—i h-1 t-

H -a 00

5 >-• o

Q

E S1

W

o ca

5 c 3 O

3

b 1

u

s c

1-11 o

2 is u c

Ü o1

J2 ca crt

3

0 C3 V

If O

D.

^1 J3

.a ca 0.

«> o> ,N

H1 H1 s H, H H. H. (-. CO 1- 43

U < 3 > '3

a > O U

J3 +J

O

2 la a. CO

0 •S

Q 3 § § 3 at Pi Pi Pi 0 Pi Pi s Pi

ID Pi ffi

cd C3 p a

9 <

3 _a> o u a) cd c 3 3 3 -o 60 C3 03 C3 C3

*co a .SP I c

.SP c 60 jj _a> JD — J£ JD _aj _«> JO 0> _- J3 CU 0

< •fjj 3 3 3 3 3 3 3 3 3 3 3 3 3 3

co CO CO to ca ca ca ca C3 C3 ca ca ca ca ca ca C3 ca

tu <. <. <. «, c

.SP c

.SP c 60

c op c c .SP

c so .!> c

.SP G G G

SO G 50

G 60

CO I 3 +->' 4->' -t-» *co *« CO "lo 'w 'co 'co CO *co CO CO CO CO CO

o o o o co in en CO CO CO CO CO CO CO CO CO CO CO

z 2: Z Z < < < < < < < •< < < < < < <

< < < < ►J j HJ ►J

*l fci fcl fcl 1

>■' >.' >-' pi cü Pi 0$ j HJ J HJ

< < < < > > > > < < < < n o, o, o, o, n '3

P Q1 Q1 p1 Q1 <L>

u 0 CU O 0 0

<L> O u 0 0 O n n □ □ □

§ 3 § 3 e s s C ca C

c ca c C C c c G G G G G

O O o O •4-* 4-« 4J CD 1) 0 tu

■♦-» S CD & § § § Ü g

"S g

"c3 'ca g '3 '3 .s

ca g 'S

g "3

c '3 .9

ca .9 ca "ca

.9 ca

g "3

<. <. <, <, 5, s, s, s, s, S, s, 2, 2, 2, s, 2, 2, 2, □ Pi' *' Pi1 Pi' Pi1 Pi1 Pi1 Pi1 Pi1 Pi' Pi1 Pi1 Pi' Pi' Pi1 Pi1 Pi' Pi'

□ □

o ^ o ^ o „ o ^ o o o 0 0 O 0 O O O 0 0 O O

s§ s§ BE b Z P O

b D

b D

b P

b P

b P

b P

b p

b P

b P B B s b

P b P

J o J o J O J O HJ J J J ►J J J -J hJ J j J HJ J □ « H ffl H ffl H pa H m pa CQ pa pa pa M 03 oa « oa pa pa pa

□ □ GO 6

o

□ o n-H "3> c c a e a c c c c c s c c c G G G G > xs o o o o o o o 0 0 0 0 0 0 0 O O O O CO o o o o o o o o 0 0 0 0 0 0 0 O O O O

□ □ A W ts ta 'S J3 ta S3 ts 'S M ta 'S ta s 3 « ta ta ts ffl

5! E E E E b E E E E E E PH PH b b b b b

□ n 1010086

IDD

DD

00 32

Pi Pi Pi pi Pi pi Pi pi oi Pi pi Pi Pi Pi Pi Pi Pi Pi H H U

o O o o o O o O O O O O O 0 O O O 0 35 b b s b b b b b b b b b s b b b b b

pi p P D P P P P P P P P P P P P ►J _J _) HJ J J J J J J _) -1 J J ►J HJ HJ J

U m m pa pa m pa oa pa ffl pa pa m PQ pa pa pa P3 pa

oo fa <

ON ON

xr\ n W 00

£ > O <

ä s Q O H1 h-1

H 00 Q <

□ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □

co

-a

PQ fa < 00 r—«

n ° ^ □ 5 u 818

x> ca B 00

ö o

o W

a>

o C co B

■4-» g '3

B

x> C3 B 60

B O

S B

H S

00 Z O H En O

PL) H ■' b D o u

3 b U

a >

00 b O

s -1 Q O o

w o

X Q u f-l

H Pi Z < 6 U-l S w i

Q CT o C/) > y < Pi Q

u

z <

< D

O

—1 o O O O Pi aJ W

u C_> u U U u U o U

■s B 00

■s s 00

•s B 00

•s B oo

■8 c 00

•s B 00

Xl C3 B 00

X> ce

S> X> C3 B 00

•s B 00

x> ca B 00

•s B 00

8 s 00

•s B 00

X) C3 e oo

XI ca B oo

u 3 co B 00

s 00

<<<<<<<<<< < 0) (D u o u B B ca ca c a ß D a> 4>

e o o S b

Pi o b P -J

s o o S b

Pi O b P 03

B O o S b

Pi O b P HJ CQ

e o o ta b

Pi O b P CQ

B O o S b

Pi O

CQ

B O o S

Pi O b P CQ

a o o S b

Pi O

CQ

B O o S

pi O b P J CQ

B O o S

Pi O b P -1 CQ

c o o S

Pi O b P J CQ

E O o S

Pi O b P ►J CQ

a o o S

Pi O b P CQ

a o o S

oi O b P J CQ

a o o S b

Pi O b P CQ

a o o S b

Pi O b P J CQ

B O o S b

Pi O b P J CQ

c o o S b

Pi O b P CQ

a o o S b

Pi o

CQ

a o o

a o o

Pi O b P CQ

Pi O

CQ

a oo

< < <

a o o

ca ca ca b b b

Pi O

CQ

ID

I

00

fa ON ON

< r/) f>

00 z >< O <

ä s p u 1—I HH

H tzi

§

□ □ □ □ □ □ □ □ □ □ □ □ □ D □ □ □ fa Bs| □ o fc

CV3

O

ffl

ac P U X

00 W

H u

Pi W > o

1 o S Q

O m

i

H o a >

I-, 1 PJ

00 W H

U <, a

•s o OH

H t/)

Ü

PJ >

O

Pi W >

> < PJ

U

> H U <

w1

o

w b W

HJ

2 U

5 H

< l

s -J PJ >

w >

H

O

GO

W

U

PC w

t< o

Q PQ H

o s 00

Q W H

O

00

PQ

w 00 00 <

g PJ > 00 00

§ OH OH

00 03 O

<,

I' H 00 O OH

1

p < oo 00 <

Z o 00 00

1 I' 00

u 5 oo

-J 03 < H 00 PQ

u

PJ H D O PJ

PJ H D U PJ

w H P U w

H 00

5 > o

5 > O

P-, p o

OH

5 00

oo1 H

p < 00

o-1

5 H Z

PJ O < OH s PJ

Pd H P O PJ PJ

Q

u <:

X PJ

X w

X PJ

X PJ s§ O

P 00

P 00

p 00 <

00 <

< 03

O u X PJ S

JH 3 JD JU _4> <L> <D D a> a>

CO

.SP 3 3 3 x> x> x> -o -Q ^ CO CO CO CO CO CO co c a B B B B B B

< _jD _2> u ju .22 _cu _u _«> o a> a> .SP .SP .SP .SP .SP .SP .SP .SP 3 3 3 3 3 3 3 3 3 3 5 5 S 'co 'co 'cO *co 'co 'co 'to 'co

CO ca CO CO CO co C8 CO CO co CO CO co CO CO CO CO CO CO CO CO

c c .SP

c .SP

c .SP .1 c

.SP c

.SP c

.SP c

.SP e

.SP c

.SP .SP c

.SP «, <, <, <, «, <, <, <, CO

p *CO co

*lo CO

"co en

*co CO

CO co

'cO en

*«5 en

"co CO

'co CO

*CO CO

'co CO

'co CO

'co CO o o o s1 *H'

O *H'

O O +H1

o < < < < < < < < < < < < < z z z z Z Z z z

z Z Z z z z Z z z £ z S5 z z z z z z z z z 5 5 o o o o o o o o o o o O o o o o o o o o o o o o o o o o o o o o O o o o o o p o H H H H H H H H H H H H H H H H H H H H H

"tj < < < < < < < < < < < < < < < < < < < < < 'o _) J _) HJ -J ►J J J J J J J J _) hJ J J J J HJ J P ^1 fci fci *I ^I fci ^1 fcl fcl ^1 fcl °*l ^1 °-| ^1 ^1

OH | fcl fcl ^1 *! E I' =' I1 K1 K1 K1 E1 ffi1 K1 K1 ffi' K1 x1

=' X K1 ffi' K1 K1 ffi1

U a U o U U U U U U U U U o o o U U U U U w w w w PJ w u pq w w PJ Pä PJ w pj w w w PJ PJ PJ

s. s. 2, s s. s. s. s. s, 2, s, s, s, S, 1 s, s, =s, 2, S, 2, Pi' Pi1 Pi1 Pi1 Pi1 pi1 Pi1 Pi1 Pi1 Pi1 Pi1 Pi1 Pi1 Pi1 Pi1 oi1 oi1 oi1 Pi' Pi' Pi' o o o o o o o o o o o o o o o o o o o o o b b b b b b b b b b b b b s b b b b b s b D D P P P D P P P P P P P P P P P P P J _J J -J J J J J ►J -J ►J -J J J HJ J J J J HJ ►J CQ OQ P3 PQ 03 m OQ OQ OQ « CQ PQ 03 OQ CQ P3 03 03 CQ 03 OQ

c o

c B a c c e ts e c c c c C3 s c B B E s B a „ß o o o o o o o o o o o o o o o O o o o O o o o o o o o o o o o o o o o o o o o o o o o W <4_» ■*-» 4-» 4-» -4-* •»-» ■4-» ■*-> ■♦-* -t-» +H ■ti *H ti -ä

CO ca CO CO co co to CO to CO CO CO CO CO CO CO co co CO CO CO

E E E E E E E E E E E E E p^ OH OH b OH OH OH OH

<u -a

Pi Pi pi Pi Pi pi Pi pi Pi Pi Pi Pi Pi Pi Pi Pi oi Pi Pi Pi Pi o O o O o o O O O O O O O O o o o o o o o

00 b p

b D

b P

b P

b P

b b P

b P s b

P b P

b P

b P

b P

b p

b p

b p 5 b

p B s J HJ _) J HJ ■J J J J J -J J J J -J J HJ HJ HJ J ►J CQ pa PQ OQ OQ OQ CO PQ OQ OQ CQ OQ 03 CQ OQ 03 P3 03 CQ CQ 03

I

00

Ü, ON ON

< T—t

r/> W oo £ >< O <

ä s Q U HH HH

H 00

D n n n n n n n n □ □ □ □ □ □ □ □ □ □ □ □ DSU

l-H o

■g

m

<; 00

H H U

•a S3 00

a o

ja o W

H U

Q W H

O

o

s §

u u < <L>

B 60

ca as c M a yj \JJJ VU WJJ MJ W*.

43

c 00

43 C3 B

CO co

CO CO

o z z z

< < •s B 00

43 ca B (50

43 ca B

43 ca

ao •s B OB

■s B 60)

•s B 60

B 00

43 CO B

•8 B 60

■s B WO

■s B

43 ca s ao

43 ca B 50

I t I UJJ wjy WJJ uu UJJ uu WJJ wu w*/ +-1 +e *=» 'co 'co "co "co 'co "co 'en "co 'co +^

o z o z <<<<<< < <

«. «, «, O O O Z Z Z

5 5 5 o o o Z Z Z

O H < OH. to.

u u

pi Pi o o

oa pa

z Z Z Ü ü ü o o o H H H < < < HJ HJ J ^1 °*l to x1 £ ac u u u (U w w S. S. S Pi o ÜH

P m

pi o

P m

pi o

P 03

O H P O u

Pi o

3 03

o

<

t> P O u oo

Pi' O to P 03

O H <

H' p o u oo

Pi' o to P pa

§ o

<

H' p o u oo

Pi' o to P 03

g <

z P O u oo

O to P oa

o

<

t> P O u oo

O to P oa

B O o

•Sa

B O o ta to

B O o ta to

B O

to

B O o ta to

B O o ta to

E O o 'S to

B O o ta to

s o o 'S to

B O o ta

a o o

B o o ta

B O o ta

B O o ta

B O o ta to

fi o o ta to

B O o

to

B O o ta to

B O o

B O o

-2 .— to to

Pi O to P 03

Pi O to 3 03

Pi O to P 03

Pi O to P oa

oi o to P J 03

Pi O to P 03

Pi O to P 03

Pi O to P 03

Pi O to P J 03

Pi o to P J 03

Pi O to P 03

Pi O to P 03

Pi O

03

Pi o to P J 03

Pi O to P J 03

Pi O to P J 03

Pi O to P 03

Pi O to P 03

Pi O to P 03

Pi O to

3 03

•8

o Z

o

<

z> p O u oo

Pi' o to P J 03

B O o ta to

Pi O to P 03

■ <

00 IJL, ON

ON < r/1 W 00

Z >- o ä ^ Q U H-t 1—1

H r/5 Q <

n n n n □ □ □ □ □ □ □ □ □ □ □ □ □ &

□ 3Z1 f-1

i—, ° H

Bib

■s a 00

g o H1

U P Q

§

o Z

< w

p o

Pi o

a o o

J3 to

Pi O to P J ca

>—i

on oo

W D s § u

H U

u

u

u H

I W >

a

o ca.

w w w H H H P D P U U U w w w X X X w w w

o

w >

w H P o w X w

w Q

u

<

§

o

s §

oo

oo O

w H <

g 00 O

w

P < 00 00 <

W J U

00 m

00 to

Z O H ►—<

oo O

p u U

to DQ O U

W >

oo to U

8 c 60

<L> U

•8 •s -s c c 00 00

■s a 60

■8 yj W*J WU W W*J ^Vrf*J .^" .WM ,VW ,^^ .Ü, ,^H .X» ..-* ■ !-■

C3 B oo

c oo

•s c oo

U 0)

8 1 ß B oo oo

u <u ■8 -8 ß C oo oo

WD

< <. <. <. *. 1. <l 3 V) en

O O

Z Z o o o Z Z Z

o Z

o o Z Z

o Z

5 5 o o Z Z

CO

< <. CO ■S •S •8

bb 5 •S B 00

B 00

■8 B 00

o o Z Z

<

5 P o u o

oo oo.

Pi O

5 5 PQ 03

& p o u 00

O to 3 to

<

& P o u oo Pi' o to P J

<

P o H P O u u oo oo

O to P J DQ

Pi O

D3

<

P o u oo

o to P

< w

H' p o u oo

o to P ca

5 P o u ^' Pi o to P J CO

S <

P o o oo

o to P J 03

<

H P O _ u u oo oo

< W

p o

Pi o to P J 03

Pi O to P 03

< W

H- P o u oo

Pi' o to P ►J 03

<

P o u 2' Pi o to P HJ 03

<

5 o to P 03

O H <

o

03

§ O H <

! o to P ►J 03

<

o

03

P

B O o

M to

a o o 'S to

a o o t3 to

a o o to to

e o o

B O O

B O o 'S

B O o S to

a o o S

a o o S

a o o S to

a o o S to

a o o S to

a o o S to

a o o S

a o o S

e o o S

a o o S

a o o S

Pi o to P 03

Pi O

Pi o to

J 3 03 03

Pi O to P J 03

Pi O to P J 03

Pi O

03

Pi o to P J 03

Pi o to P J 03

Pi O to P J 03

Pi O to P 03

Pi O to P

Pi Pi o o

03 03 03

Pi O

-1 03

Pi O to P H-l 03

Pi O to 3 03

Pi o

03

Pi O to P hJ 03

Pi O to P 03

8 a oo

<<<<<<<

O

< <

Z

o to P 03 03

O

a o o S to

Pi O to P J 03

00

00

< ON

r/i ^ W 00

z ^ o <

ä £ Q U HH h—I

H on

□ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ ^ □ o HS

o

5 

5

Z o oo oo

> 00

PH w Q, z' s

u

I > o

o o1

7 00 o o ►J HJ

<l <! H R w >

UJ >

w < e o

HJ < 3 2 U w1

w1 w1 w1 w1 W

■-I u H H H H H o H O <

> 00 00

OH PH

p 00

00 o

H' J p < 00 00 <

w u

1 00 m

W

00 W

> H O

u Pi o PH.

oo w

> H U

o PH.

< oa

o PH OH

P 00 W

x> CO a 00

■s C 60

■s c 00

8 c 60

■s c oo

x> a a oo

8 c oo

■8 c 00

CB c oo

x> CO c 00

•8 c 00

•s c oo

x> C8 c 00

x> CO c oo

8 c

D'co *co *co *co *co "co co co co co co co co co co cococococococococococococococo <<<<<<<<<<<<<<<

x> ä nt C3 S c 01) (si) w w CA CO

<, <, *-' *.' O O Z S5

8 8 8

o Z

o o

o <

I O P

o o H <

fed

I o p

CO

z o o H <

o

P3

O H <

cu.

5 O

p H-I m

o < CU.

5 o b P _) m

<

5 o Pu P 03

§ O H <

o b P

pa

o <

I O PH

p

ffl

o <

o PH

P m

o <

I o Pu P m

o <

! o PH

P J oa

o <

I O PH

P

o o H <

z

o PH

P oa

o <

z

o PH

P oa

o <

! O PH

P J CQ

C C G o o o o o o ß cd cd

G O o 'S

G O o 15

G o o

s G o o

c o o

G o o

c o o

G o o

co ca cö es cd PH PH OH

G O o

cu

G o o

c o o a

G o o

c o o 03

G O o

G o o

M G o o

G o o

Pi O PH

P oa

o PH

3 oa

pi o PH

P J oa

pi o PH

P oa

OH

o

oa

oi o PH

P oa

Pi o PH

P oa

erf o p- p oa

oi o PH

P J 03

Pi o PH

P oa

Pi o

ci o PH

P oa

pi o PH

P J oa

pi o PH

P oa

ci o PH

P J oa

o PH

P oa

Pi o PH

P oa

ci o PH

P oa

pi o PH

3 oa

pi o PH

P oa

•8 G 00

< <. < <. o Z

G O o

cu

ei O PH

P oa

00

ON

tn W 00

£ >H

O <j

ä ^ Q U HH 1—1

H 00

□ □ □ □ □ □ □ □ □ □ □ □ □ □

C/3

o 5

cd n n n

Bsp BIB

t- tf o u < < pj H H J 2 O j <

o

1 1/3

g H U

2 Q H1

U <

§

u

o

Q1

PJ H

O

oo £ PH

51

PJ

H 00 oa

§ H O <

PH'

H

ü S j w > o

oo

PJ

u X PJ

o H 00

O

PJ HJ u < H 00 oa °. X

w u z

00

PJ1

Ü Z < X u

Q PJ

E PJ

5 5,

PJ j u

00 oa

PJ

Ü

oo

1 PJ

ß

"co co

P P H H H 2 ^1 p P >- CM u eS eS > _^l U tu X PJ

U PJ X w

PJ j Q

< £

<

£ U o

3 J£ u a> <L> u V <D co -- c 3 3 3 3 3 3 3 3 HO -2 XI x> X> -2 -2 bo cd eS cd cd cd cd cd cd cd cd cd cd cd cd cd

c B B B B B ß B ß 8 S ß ß ß B *co .SP .£P .SP M» öt) .SP .SP .5? <D u (u .2P 60 ÖD .2P .op ap .SP *^M

•< CO CO "co '« 'co 'co "co 'w 3 5 ^S 5 s 'to 'co 'lA 'w 'co *cfl 'co •s CO CO CO co CO CO co CO C0 cd cd cd C3 CO CO CO CO CO co co co L-

<, <, <, <, <, «, «, «, .1 .£P C öß .§> <, <, 5 <, <, <, <, .i> co

p +J ■J *-.' *J *J . 1 1 4-' crt *c/> "to *« CO 4-.1 +J +H1 +H1 4H1

co o O o o O O O o CO (/» Cfl CO CO O O o o O O o co

2: z z Z z z Z z < < < < < Z z Z Z Z £ z <

Z Z Z 2 2 z £ g 1 co

o o O O o o O o co

o o o O o o o O s, H H H H H H H H •4-»

'S p

< < Du

< < < CU

< CH

< OH

< ►J CU < < < < <

2 < < < < < < <

00

*' *' *' *' *' «' M1 ^1 PJ B B P PJ PJ PJ H B B PJ PJ

H B 2 < 5 3 1 2

< 1 I < § £ § s £ £ £ £ £ £ HH <

K K K s-. H. *-. H. t-, Ei Ci Ei ^1 El fei Ei Ei Ei fc| fc| fe| Hl

eS1 ei1 ei' es1 es' es1 eS1 ^ eS1 es1 es1 eS1 es' es1 es1 es1 es1 eS1 es1 eS1 es1

o O O O O O O O O O O O O O O O O O O O O Pu ÖH P. b PH PH s PH PH PH P- PH PH PH PH PH PH PH B § § P P P P P P P P P P P P P P P P P _) J J ►J HJ h4 hJ hJ J hJ J HJ HJ J J J J _) ►J HJ HJ

m oa oa oa oa pa m oa oa 03 oa oa oa oa oa oa 03 oa 03 03 03

Ö o c n c B B B a ß

43 o o o O O O o o T3 T3 -T3 X) T) TJ ■o T3 -o •o T3 T3 T3 o o o o O o O o o cd cd cd cd cd cd cd cd cd cd cd cd cd

PJ IS IS ts 'S ß 3 S 3 3 3 3 3 3 3 3 3 3 cd cd cd cd cd cd cd cd er O" er O" o* CT" er er er er er er er s s eü EC CU s CU CU oo 00 oo 00 00 OO 00 00 00 oo oo oo oo

»S ei eS eS eS eS eS eS eS eS es eS eS eS eS eS eS eS eS eS eS O O O O O O o O O O o O O O O O O O o O o

oo PH

P & 5 PH

P PH

P PH P

PH P

PH

P PH P s PH

P PH

P P- P

PH P

PH

P PH P

PH

P PH

P 5 S § _l j H-I -j j HJ J -J HJ J hJ J J J HJ J _) J j J HJ

oa oa oa oa oa pa oa oa oa oa oa oa oa oa oa oa oa oa 03 03 03

o

□ □ □ □ □ □ □ □ D □ □ □ D □ □ □ □ □ □ □

CO

O

"g ■s ffl

-5!

w u H

3 OO

Ü

►4

U

c^ <

Ü s

Ü s 1-4

CO Ü g ffi ;*: Ni < g 00

< O u, ^ <l

00 <

oo < o

O u s «'

<

Pi a

W >

U < %

i1 oo1

<

g1

> 03

> z w >

c

00 H PJ

9

00 H PJ Ü

w >

f-c

U 1

o oo 00

o &

PJ 00 oo

PJ o l-H

HH 3 *CO

Pi <

Pi < - Q ►j ^ Q P Q <

a H

PJ

Q

o u ^

'S cu OH

a w X w

03 P oo

H U <

00

<

PL) X PQ

u u o 03 P 00 § 00

2 u cu CU .2 _a> cu CU TO ö 3 3 3 3 3 "S •s a

*co CO

<

CO CO CO CO co CO CO

3 — 3

ja 3 3 3 3 3 _0>

3 .1 CO

c .SP *co

c .SP 'co

c .SP 'io

c .SP 'co 5 3

_cu 3

J2 3

cu a .SP *CO

c .SP "co

cu

co co co CO co CO CO co CO CO CO CO CO CO CO CO co ro CO CO TO

CO

p

c .SP 'co

CO

c .SP "cO

CO

s .SP "co

CO

c .SP 'co co

c .SP 'co

CO

c .SP 'co

CA

C .SP "co

CO

e .SP 'co

CO 5 o

5 o 3 O

3 5 c

.SP "co

CO

C .SP 'co

CO

c .SP 'co

CO

s .SP 'co

CO

.SP "co

CO 5 o 5

O .1»

CO CO

< < < < <c < < < Z Z £ Z z < < < < < Z Z <

OH OH OH PH OH 0- PH 0H OH 0H CU O O o O o o o o o o o ^ o O o o o o o q q o q

<

Pi PJ J

c c at pi Pi Pi Pi Pi Pi ^

p* ^ ei o _o K H. (-. f-, H. H, ^, ^-, ^, H,

'co co

CO CO >.' >*' >.' >.' ><' >.' >.' >-' >-' >-' z z 5 z 5 Z z

I' < <

2 5 £ Pi Pi Pi Pi oi oi pi oi o o o o o o o

'5 < > <

< > <

H-l < > <

l-J

< > <

<: > <

< > <

< > <

< > <

N-J < > <

< > < c^

H

J

g l-H HI HH

ex1 a.1 o. o o. Ü. u o. o. o. w, U, o, < < < < < < < < o o Pi1 o.1 Pi1 *' ßi1 p^1 Oi' at: Pi1 Pi1 oi1 wl ml ml ml ffll ffll ffll

2, 2, <, <■ <, «, <, <, <, <, <, Pi1 Pi1

5 Pi1

5 oi

5 Pi

OH' 00

Pi1 Pi1 <*' Pi1 Pi1 oi1 oi1 Pi' Pi' Cni' oi1 Pi' Pi' 1 1 o o o o o o o o o O o O o Pi Pi oi Pi Pi pi pi Pi PH PH PH P* P- P- UH ÜH Ü- UH u. PH PH o o o o o o o o p D p p P P P P P p P P P PH PH PH PH PH PH PH PH

_j _) _! _) j J J J J J J J HJ OH OH OH OH OH OH OH OH

m 03 m 03 03 03 03 03 03 03 03 03 03 o o o o O o o o

e o c c c c c c c c a> o o o o o o o o

J3 •a T3 D. O. n. Ou D. a. a D. a D. a, CO

03

CO

03 1 03

CO CO CO CO CO u W

eo 3 a"

CO 3 o*

OO

O o

O o

o S H

o o

O O

o

1 o o

O o

o o

O o

o

1 03 1 03 03 03 03

al Oi oi Pi ci Pi Pi ci Pi at at Pi Pi cu o O O O O O O O O o O O O Pi Pi Oi Pi Pi Pi Pi Pi oo ft,

p s 5 PH

p PH

D PH

P P B St, P

PH

P s PH

P PH

P O PH

o PH

O PH

O PH

O PH

O PH

O PH

o PH

j _J _j _) _l J J HJ HJ J HJ _) -H OH OH OH PH OH OH OH OH

03 CO 03 03 03 03 03 03 03 03 03 03 03 O o o o o o o o

■

W J Q

W Q

s

03

w

OH

D o o o

Ü S

>

H

W H D O w X w

Ü s <

w > w

<

x

<

<

< o H U

5 u p Q

■S a 60

Z5 £> JD CO co CO s C fi 60 60 60 yj w*j wu w« WM »wj WJ.

c

5 5 o o

CO a 60

^ <l <, +-» ■*-» ■*-» o o o z z z

B 00

o Z

Z3 .O ret CO B B 60 60

"So "öo 00 00

co B 00

•s B 00

•s B 60

5 5 5 o o o Z Z J5

■s B 60

•s B 60

5 5 o o Z Z

eg

.1 00

<

■S 8 60

•s

o z

•s B 60

O z

CO B 60

O Z

n n n □ □ a a n □ □ □ a □ a

CO )-H

□ a R~ Dor- nst BIO

C/2

B

B _o "3 u

W

«I

5 5 i—i t—i

P P

oi w

t-H

o UH OH

o

B O

Pi O UH P. o

Pi w _)

g en

pi' O UH OH o

Z Z Z o o o

<

Pi w ►J

g en

o CM

o

H <

Pi w ►J HJ

g en

Pi' O UH PH

o

w ►J J

g tn

Pi' O UH OH

o

I <

Pi tu J J

g en Pi' O UH PH O

z z 5 5

< < CO PQ

z

5 o UH PH o

! o UH PH

o

s s £ o o o

<

! o u. PH o

<

! o UH OH

o

<

! o UH PH

o

z z o o

<

! o UH PH o

< ffl. co.

s o UH PH o

B o B O

B O

B O

B O

B O

B O

B O

B O

B O

B O

B O

B O

B o B O

B O

co ca

CQ m

Kl CÜ Kt

CO CO rt 03 CQ 03

Pi o PH o

Pi o UH PH o

Pi o UH PH o

Pi o UH P- o

cs

03

Pi O UH PH o

co co

03 03

e3 eü cd

cd cd cd 03 03 03

co co

03 03

Pi O UH PH O

Pi o UH PH o

Pi o UH PH o

pi o UH PH o

Pi o UH PH o

Pi o UH PH o

Pi o PH o

co

03

Pi O UH PH o

CO

03

Pi O UH P- o

CO

03

Pi O UH PH o

CO

S 03

Pi O UH PH o

B O

CO

03

Pi O UH PH

o

PH

<

§

P u

■H o

PJ -j Q

Pi H < Z f-i w -J1

< 2 w <

2 PJ > o 2

,,,' PJ w PJ H H O D P < o u o w PJ z X X w w W

z o

z o on on

PJ D s

u

<

o

S PJ Z

H U <

PJ S D oo PJ

e § §

H W

9

< 2 PJ

< D o PJ

PH >*

PJ a

Z J PJ B HH H W Pi

«, °i > z P 2 U H U O o <

x> .£> 03 CB C c 00 oo CO en CO CO

<, <, ■J .J o o z z

■s c 00

■s C 00

X> ca c 60

•8 c oo

X> CO c 60

< < < < <

X> ca s so

X> £> x> X> X> Kl CO C8 a cS c C C c C 0/) oo O0 oo 0JI

eo CO CO CO co co en CO CO

«. < <, <, < *J ■J +J ■J o O O o O Z Z Z z z

■8 e oo

•s c oo

•s c 00 §> oo

a l> H

O

'8 X3

CU m

00

s D

□ :_? c-1

RIB

c

o PJ

•a 33

c

PQ

Pi O

P- o

c

pa

cd o PH O

al Pi W pq

ffl. CO

vo1

o PH

o

6 o U

Pi o ÜH PH

o

vo1

o PH

O

8 o. S o U

Pi o PH P- o

> Pi PJ H H < "I so

O PH PH

o

c ca D. S o U

Pi O PH PH

o

pi pj H H <

vo 00

o PH PH

o

S D. S o U

Pi o PH PH o

pi PJ

< ffl, 00

a1

It O PH PH

o

a E o U

Pi O PH PH

o

Pi

ffl, 00

O PH p- O

a ca

s o O

Pi O PH PH

o

Pi PJ H H < 03

I vo oo

o p- PH

O

D. E o U

Pi o PH PH

O

> Pi P-

< ca

i 00

o PH PH

o

8 D. E o u

Pi O PH PH o

Pi

<

00

O PH PH

o

E o U

Pi o PH PH

o

< »I vo 00

o PH PH

o

8 P. E o O

Pi o PH PH

o

Pi PJ

<

oo

o PH PH

o

c ca a E o U

Pi o PH P- o

pi

< oo

Q1

o PH PH

o

o u

Pi o PH PH o

pa.

< < 00 00

p

O PH PH

o

E o U

Pi o PH PH

o

p

o PH PH

o

>» 8 o. E o u

Pi o PH PH

O

Pi

P

It o PH PH

o

ft s o u

Pi o PH PH

o

pi PJ w

< < pa pa

i i en «n

< < oo oo.

P

o PH PH

O

ft E o U

Pi o PH PH

o

Pi Pi

pa pa i i m en

< < OO 00

p

:■ o PH PH

O

I ft E o O

Pi o PH

o

p

t> o PH PH

O

ft E o O

Pi o PH PH

o

to < W

§

Q

H &o Q <

-a

i4 U

<

8

o

u 3 < S 9 § §

P u pi

a' < H o W p4 <3 I 00 a! i-l w <* < MJ H U t)

U <

M-i p w <

2 H, 1 HJ . 1 H o

w H P u w o

u o

§

P ^ Pi w <C MJ

<£ 00

O H < O H <

cs a 00 yj WJV UU Wl.

x X X CS es CS B B s 00 so 00

o Z

o Z

o Z

c 60

•s B 00

■8 XI es

X es s oo

•s c 60 I UU UJJ UJJ WJJ WJJ UJJ WJL

"cO "cO *CO *Cfl *W5 *CO CO CO CO CO CO CO CO CO

<<<<<<<

■8 c oo

8 B 00

X) CS B 60

5 5 5 o o o Z Z Z

X cs B oo

x cs s oo

5 5 o o Z Z

B 00

8 B 00

8 B 00

■8 B 00

< < < < <

8 JJ JJ §3 8 " """ a

o Z

n n n □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □

C/3

o

'g m < DO

H H U

s p

B _o "53 j= o W

3 bo

w

pa

o CM o

8 s o U

oo on

Q

o MM CM

o

eä Pi E3 S

< < pa pa

i i

oo

a'

o MH CM

o

&o

Q1

o MM CM

o

Pi

< < oa oa

i i »—I r—t

< < &o &o

D1 Q1

<. <.

O O MM MM CM CM

o o

Pi w

oa.

< 00

Q1

2' O MM CM o

oi w H H < pa

< 00

D1

O PM CM o

Pi w H H < oa

oo

Q1

o MM CM

o

pa

00

Q1

o MM CM

o

< pa.

< 00

Q1

o MM CM

o

Pi PJ H H < pa

< 00

D1

O MM CM

o

«I

< pa.

i i

00

Q1

o MM CM

o

>- Pi PQ

pa.

< 00

Q1

O MM CM

o

b b ä Pi Pi Pi s e " I: t

>H >H >H

Pi Pi Pi

o

Pi o PM CM

O

<

o

o PM CM

o

o u

cs a E o U

B cs D.

E o U

g a. E o U

B cs a. E o U

g a, E o U

E o O

§

E o U

g E o U

g a. E o U

g ex E o U

B cs D.

E o U

B cs O.

E o U

g a E o O

g cx E o U

g CM

S o U

CM

I a E o U

I" I O O

Di Pi Pi o o o MM PM PM CM CM CM

o o o

Pi o PM CM

o

oi o PM CM

o

Pi o PM CM

o

Pi o PM CM o

pi o PM CM

O

Pi o PM CM

o

Pi o PM CM

o

Pi o PM CM

O

P4 O PM CM

O

Pi O PM CM

O

Pi o PM CM

o

Pi o PM CM

o

Pi o PM CM O

Pi o PM CM

o

Pi o CM

o

Pi o CM

o

Pi O PM CM

o

£? cs CM

E O U

Pi O PM CM

o

< w §

Q U

□ □ □ □ □ □ □ □ □ □ □ □ □ □ -8 □ 03

□ © £

BIB

e 60

B o <3 u

W

Z o So OO

w P

s H Z O u

<

o

o Pu QH

O

B S3 D.

O U

Oi o Pu cu O

w S D 1/5

9 §

z o H So O

S w z w

i

D < 00



o

o O a! H oo

w1

Z o

oo O

> oo Z w Pu w Q,

§

oo O

>.' Pi

w pj ex

D 00

> 00 3 Pu

U CU

w w p H

D P u o w w X X

u H P o u X w

J5 CU

p O o o

Cu p o u o

03

w oo oo

p . U U oo

O

a § si H oo

>•' cu p

u O

O Z O O

w > o

i H, z

2 p o w oo

w1 g Q g > O O CQ oi P cu oo

Ü

s oo

> J. W £-> <

z o i Sä

S o oo

2 a P H

z o oo1

§ U <

X3 -O X> fit CQ Bt B B B 60 00 Oil w co xn cfl C/) UD

«1 «1 <l

yj ViJ WJJ WU W*,

•s s 60

■8 B so

■s B 00

■s B 00

x> a a 60

■8 B 00 ■ OJJ OJJ OJJ UU UJJ UU UJJ WJJ UU UJ.

8 s 00

•8 B 00

ea B 00

x> C3 B 00

X) C3 B 00

■s fi 00

C3 s 60

1>

B 00

-8

o o Z Z z z < < < < < < < < <

o z

Pi Pi w w I: 1=

<

< H Pi O

o bu Cu O

s CB

6 o U

OH O Pu cu O

<

Pi

< CQ CQ

Pi Pi

O

Pi o tu CU o

8 Q. E o U

Oi O Pu cu O

o

o tu Cu o

§ D. 6 o U

0< O Pu CU O

>- 5H ^H > ^ > >- z Z z z z z Z < <c < < < < < Cu cu cu Cu CU CU

£ S § £ S s s o o o o o o o U, u, u, u, u, u, u

cu s O o.

Z < cu s O

Cu £ o o. u.

O tu OH O

§ Cu s o U

Pi O Pu cu O

Pi

o Pu OH o

8 s o O

Oi o Pu Cu O

oi O Pu OH O

a o U

Pi o tu Cu O

Pi

o Pu Cu o

ea D. E o U

Oi O Pu OH o

Oi

o tu CU O

8 a E o U

Oi O Pu CU O

oi O Pu OH o

8 ex E o U

oi o Pu OH o

oi o Pu cu O

B CQ O. E o O

Oi O Pu OH o

Oi o Pu Cu O

>> B C3 & E o U

oi o tu Cu O

oi O Pu CU O

B a a. E o U

Oi O Pu Cu O

Oi O Pu Cu o

8 a. E o u

oi O Pu CU O

8 a. E o U

Pi o Pu Cu O

I cu E o U

oi O Pu CU O

B cs a E o U

Oi O Pu OH o

8 a. E o U

oi O Pu CU o

a. E o U

Oi O Pu CU o

•8 B 00

<. < o Z

cu E o U

Oi O Pu CU O

in

<o OO M

i 0\ r—1

i

< 00 oo Z > o § ä ^ w

»—< OO OO

a u Q U ■ >—i H-1

1

H in

T3

O o

oo

OO

erf P OO

1 1 >—i OO OO

5,

OO

P OO

z o H OO

a u erf

erf

Q1

< O

< o H O <

V5 1-

o o, O < 1 Q W

w OO CO O

|

H a > < o o

9 oo1

§ P u <

z1

§

W

w OO

b W Q

1 H

< X

< X

> o

HH OO

O

a

5

<

I' <

8,

erf w j

i o

§ H-1 OO OO

W

OO

b W 1

<

a H

o prf

< Ü

<; w1

H P

O «1

erf1 H1

U P

w1

P s1 p

5 b <

H1

u p

W Prf'

5.

H1

P

H1

U P

b1

P H U W

Q

w w 1 Q O o P H D H

Q

CD 3 ■< < Q O Z w ^ ^ ^> Z w pq u U H Z Z OO OO s Z w o X < < 2 o X X u O _<D _ •g -O HO -o 00 es ^ as ca ca C3 ca ca CO C3 ca C3

"55 c .00

c .2P

C a .£P .1»

C .£P

ID ID ^> JD ^J .1 c .SP

c .SP

d .!>

d .SP

ID JD _aj ID

< 'co CO

'« 'co en CO

CO CO

"co CO i 3 3

ca 3 C3

3 ca

CO CO

'co CO

*CO CO

'55 CO

CO CO

'co CO 1 3

ca 3 ca i

<D <. <, <. <. <, <, 0X) c c .1» <■ <, <, <. <. <, d

.SP d 00 .1 CO 1 1 1

p *J' <-■ +-» -t-» ■4-» "en *co 'co *co CO •t-» +-» +-» ■4-» CO *CO CO CO o o O O o O CO CO « CO CO o O O o o O CO CO CO CO

z Z Z Z z Z < < < < < Z z z Z z z < < < <:

>- >» >- >» > >- > > ^ >H >: erf erf erf prf erf erf prf erf erf orf erf pq w w w w [jj w w w P F* S [: f: t P S S E t t < < < < < < < < < < < mi mi mi

ffl| mi mi mi mi mi mi mi > > > >«

□ □ □ □ □ □ 5 

OH

s o

Z

o

><

1 o

>- z SS s o

><

PH

o J

erf w

erf w J

w erf w

erf w

erf w

erf w u

<■

erf u

erf w ►J

b S o u a1 2

z < b s o o

2

z <

o b S o

D D □

erf erf erf erf erf b1

OO 1

b1

OO 1

b1

OO 1

b1

1

b1

en i

b' 1

b1

00 1

b1

1

b1

GO 1

b' CO 1

b1

CO 1 s, s, f, ^,

prf1 prf1 prf1 prf1 erf1 erf1 erf1 erf' prf1 prf1 erf1 erf1 prf1 erf1 erf1 prf1 erf1 erf1 erf1 erf1

prf1

O o o o O O O O O o O O o O O o O O o o o □ ft, PH b b b b b b b b b b b b b b fr1 b b b b

b PH PH PH PH b b b b b b b b b b b b b b b b □ O O O O O O O O O O O O O O O O o O O O O

□ □ C/3 a >> >, >. >-. >-. >. >% >, >> >> >-> >> >> >> >> >% >. >. >> >> >% o c c e c a c c c c § a d d d d a d § 5 d a □ "S ca a ra ca ca ca ca ca ca ca ca ca ca ca C3 ca ca C8

"> XJ a a a cm b p. O. n. O. a. (X b O. O. OH O. D, o. b b b

J3 o £ E E E 6 E E E E E E E E E E E E E E E E □ □

o o o o o o o o o o o o o o o o o o o o o

3 U U U O U O U U U O U U U U U U u U U U U

□ n

DD

I 01

01

C/3

H H U

ID erf erf erf erf Prf erf erf Prf erf erf Prf erf Prf erf erf Prf erf erf erf erf Prf

OO O o O O O O O O O O O O o O O O O O O O O □ ° b ÜH fc b b b b b b b b b b b b &< b b b b b PH PH PH b PH PH b b b b b b b b b b b b b b b □ <* U o O o O O O O O O O O O O O O o O O O O O

< on W

§

P U

H Q <

□ n n n □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □

OO ON ON

00

<

GO

o ■g 4) ffl

00

H H U

GSu

)—> H

z 00 O o PH |

H £ oo Pd

1-

o

s o

a § PS on

1

O

PJ > oo

PH PJ

? <

pa 2 PJ on oo

PH

2 Pi

PJ ►J PH PH

P oo H1

PJ > o

p H, z °, >« H 2 p u PJ oo

PJ1

Q

a 5 fed 00 <

PJ

> Pd PJ -J HJ

<. a

2 PJ o < a

u

3

PJ

o

00 m 3

00

p 00 < PJ

z o 00 00

i *

! PJ H pi

PJ > H-<

§ PH PJ

PH

s o cu 2 PJ

3 PH

s o

Ü

Pd H 00

>.' PH

J1

PJ > PJ

< s

Ü < a

Q

^'

pi Q

S 2 o u

I: 00

o1

z H PJ PJ

E,

U P

g oo 00 HH

P S

8, oo

g H U

P

H U <

1

5 oo

PH PJ

2' H

<

PJ

w 00 P3 O

H1

U P

H HJ

<

PJ H P

PP PJ P u P u P

u P U oo

> o o CQ

X H

o z z u

PJ PJ J Q t—H

s s 1 Q z O

PJ X X u u u O Z Pd D U o o X < < 2 O X PJ PJ o o o o o PH 00 J) u _4> (U 0) D

CO — 3 3 3 3 3 X> J2 -2 C3 CO co CO CO co CO CO

JU .— _a> 4J B JH U — _u d .SP

d .SP

d .SP

d .SP .1 .1 d

.SP d

.SP — _a>

< 3 3 3 3 3 3 3 3 3 "co "co *CO 'co CO CO *co 'co •s 3 co CO CO ea co CO eo C3 cä CO CO CO CO CO CO CO CO TO co d

.SP d

.SP c

.SP d

.SP d

.SP d

.SP d

.SP s

.SP d

.SP <, <, <, <, <, <, <, <, .1 CO

p *co CO

'co CO

'en CO

"co CO

*co CO

'co CO

'co CO

'co CO

"co CO o s1 *H'

O +H' O o o O o 'co

CO CO CO

< < < < < < < < < z z Z z Z z z z < <

PJ PJ

[: < < °°i W| >' >-' pd Pd

SH SH SH >- >H > >- >- > > > >- >* >- >- ;* >- PJ PJ z z z z 2 z z z z z z z z z z z z

►—1 HJ < < < < < < < < < < < < < < < < <

4-»

'3 PH

2 PH

2 PH

2 PH

2 PH

2 PH

2 PH

2 PH

2 PH

2 PH

2 PH

2 2 PH

2 PH

2 Pd P O o O o o o o o o o o o o o o o o

■ U <->, U. o, o, <->, o, o, o, w. u, u. u. °l u. u, u. Q1 Q1 i 1

*' fed1 a1 *' fed1 fed1 ^ fed1 fed1 fed1 i

fed1 fed1 fed' z z Z z z z z z z z z z z z z z ^ ^ ^ < < 5 < < < < < < < < < < < < < < P O H. H. K H. H. H. H. H. «-. f-, ^1 *-, f-, f-, ^, **, Hl

H, H, Pd' Pd' Pd1 Pd' Pd1 Pd' Pd1 Pd1 Pd1 Pd1 Pd1 Pd1 pd1 Pd1 Pd1 Pd1 Pd1 Dd' Pd' o O O o o o o o o o o o o o o o o o o PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH fr1 ^ £< ^ OH PH AH PH PH PH PH PH PH PH PH PH PH PH PH PH PH & >1 PH >-I

O O o o o o o O o o o o o o o o O O Pd O Pd

d >> >-» >-. >% >> >» >-. >. >> ?^ >^ >> >% >-. >> >% >> ^» >> B § c d d d c3

d d d d d § d d d s d E "33 8 s 3 ca CO C3 C3 CO co CO co co CO CO co co XJ D. o. O. D. a. o. o. n. O. ex o. a. a, a. O. o. o. CH a. o

W a E E E E E E E E E E E E E E E E E E o o o o o o o o o o o o o o o o o o o U U Q U O U U U O O U U O U U U U U u

T3 pd Pd Pi Pd Pd Pi Pd Pd Pd Pd Pd Pd Pd Pd Pd Pd Pd Pd Pd GO O o O o o O o o O O O o O o O O O O o

P-. PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH

O O o o o o o O o O o o o o O o O o o

00

[In

< ON as

r/> W 00

Z ^ O <

ä s Q u HH H

H 00

n n n n n □ □ □ □ □ □ □ □ □ □ □ □ Ho- □ ,-H f-H ,_, o f->

B18

o ■g

e 60

> o

D o w X w

HO ca s 50

D o u o

•S B 50

ffi > u pi Pi w <J _J *^j -1

1 H p Pi < -> s »

D < oo 00

H U

5 u Q

§ oo

H W Ü Pi

< 2

'<, w o < o

■8 B 50

■s S 50

ca B 50

O

•s fi 50

5 o 2

2. c 50

2

CO B 50

O

ca e 50

B 50

■s ca B 50

■s B 50

8 B 50

o H <

°-| < oo

o PH PH O

O H < PH.

< 00

D1

o PH PH o

o < PH.

< 00

Q1

O m PH o

O H < PH.

oo

o PH PH o

< B3.

oo

Q1

o PH o

o < PH.

<

o ÜH PH o

§ o < PH.

< 00

D1

O PH PH O

ex 6 o U

Pi o PH PH o

S o. S o U

Pi o PH PH o

8 ca ON

E o O

Pi O PH o

s o u

Pi O PH PH o

g S o U

Pi o PH PH o

B ca

E o U

Pi o PH PH o

D. s o o

Pi O PH PH O

n. E o U

Pi O P- PH

O

B o o ca ca

B o o

Pi O PH PH o

Pi o PH PH o

B o o

s

Pi o PH PH o

B O o

■ca

Pi O PH PH o

B O o ta

Pi O PH PH o

B O o

Pi O PH PH o

B O o ta

Pi O PH PH O

■8

<<<<<<<<

§ o <

*l

< 00

o1

O PH PH

O

fi o o to

Pi O PH PH O

00

o\ 00 r*

t PH

< ■

00 W 00

£ > O <

ä S Q O

1 l—H

z w 3

oo 00

§ H

ol PQ

1

H Pd 00 o s D

oo 00 IM

O >- O o PH, > < Q s < < w1

> oo

OH PJ b H <? W a 00

a o H W O Ü O

Z § g § 00 W z w1

oo

b W

3

H1 5 s

on Z o

o 00 oo

1 z

I1 it,

D O w w

Q

w S p 00

u E w

;.'

o S M Q

ä1

<:

D U pq

H

W H D O w

2 > o

H D u w

b a

0H

u

l-J o 5S w

t< o

i g 00 oo

w1

H z W

►J Q

w D 00

U D Q z

H-l w >

u w

i U <

o X § X W

X w

X w

u o § U

< o u 3 ES

O Q

X w <

Ja 3 u a> <L> (U CD a> o u B B B

ap B B

,öp <u D .1 < to CO CO CO co 3 3 3 3 ? 3 'co 'co 'co *lo 'co 5 5 CO

to CO CO CO CO CO cd C3 C3 CO co CO CO CO CO CO CO cd CO

<. <, <. <, <, .1» .1 c .£P

B 60

c B 00 <. <, <, <, <, B

00 a <, CO 1 1 , J p +J1 4-»' 4-> 4-> CO CO 'cfl 'co CO 'co ■*-» 4-» -I-» 4-> CO CO ■4—»

o o o o O CO CO CO CO CO CO O o o o o CO CO O Z z z z z < < < < < < z z z z z < < z

M 1—1 13 J J fal fei fcl oi1 Oi' OS1

w w w H H H z z z z z b b b

o o o o o o O O o o o o o o o y

D D

H H H H H z z z z z z z z z z z 13 3 < < < < <: o o o o o o o O o o o LÜ ."a J ►J ►J ►J -J o o o o o o o O o o o K s S □ □

a. ^1 Î Î Î H p H H H H H H H H H r< .1 .1 I 1

vo1 NO1 < < < < < < < < < < < H H H

Ö 2 i—< 1—4 ►J J J J J J ►J ►J ►J ►J HJ —) Ö □ □ < < < < < P<, °-, f^, °-, 0H, OH p-, î p*, ^1 P"1, p 00

1 00

1 oo

1 00

1 00

1 J1 J1 J1 J J1 J1 J1 J J1 J1 J1 < 00

< 00

< oo □ □ □

Q Q Q Q Q a o Ü a Ü Ü o o a Ü Ü oo 00 00

< <, <, «, <■ <, <, «, <, <, «, <, <, <, <, <, <, <, <, o.' oV O,' «*' OH' o.1 oi1 oi1 oi1

O.1 o.1 oi' oi1 oi1 cK1 o.1 o.1 Pi] o:1

O O O O O o o O o O O o o o O O ° b ^ b b ffi 2fc b ffi E W □ ÜH b ÜH b lb b u. b b b b b b b b b

b b b OH OH 0H 0H OH OH OH OH OH OH OH PH b □ o O O o o o o o o o o O O O O O O Ü O O o Ü

□ □ »H

Ö

□ O 13 c e e s c c c B s B fi B B s fi B E fi B '> J3 o o o o o o o o o O o O o o o O O o o

Es o o o o o o o o o o o o o o o o o o o o W 4_) 4_» 4>H 4-> 4-* +-» 4-» 4-» 4-4. 4-i 4-H 4-» 4-2 +J □ □

,£3 'S e5 03 J8 c5 s ts ■to .2 to CO « co CO CO CO co CO CO 0)

CQ E E E E E E E E E E E E OH b PH b b b b

□ □ ^ < 00

H H U

□ © □ 5 12 os1 c* OH OS Pi pi pi a; rt 0Ü Oil oi Pi Pi OH Od Pi OH o.

bo O O O O O O o o o O O o o o o O o O o H~ b ÜH b lb H< &H b b b b b b b b b b b b b

b OH OH 0H OH 0H OH OH OH OH OH OH b b b b b b b □ Ch U O o o o O o o O O O o o O O O O O O O

00

^ ON ON

< c/> W 00

£ >- O <

si s Q U HH )—H

H CO Q <

n n n □ □ □ □ □ □ □ □ □ □ □

CO l-H O

4> ffl

n n n n ^ ™

□ © fc SIB

•s c oo

x> CO c 00

o z

pi

O y j w

j D < oo

PH DC o a

< DC PJ1

H P O PJ X PJ

•S B 00

o Z

I, OO

o PH.

Pi

W J Q

H > oo

PJ w *,

00 z PL) > PH

PJ

PJ

W Q

a, 3 §, t PJ 12 e >' oo1 z o

H U P a >!

3 P u p PH

p OO PJ PJ U H 14

S X X U u o w PJ o 

3 2

o 6 H H 00 »-H

O OO o PH

Z PJ > PH

PJ PJ oo U

H PJ >

PH _l PJ m < o Q H K, i

1 < <

PJ PJ „ 1 H H > > CO B 60

O Z

X> CO B 00

■9 B 60

•s B 00

X> CO B 00

5 o

•8 B 60

■s B 60

•s B 00

■8 B 60

4>

B OO <D CO

< < < z z z z 5 5 o o Z Z

•S -8 B B

.SP .w> co B 00

X co B 00

PH

PJ H P- O y j PJ

p < oo oo

0 l-H

PH DC O Ü

S' Pi PJ H PH o y HJ PJ

J P < 00 00

PH ffi o a

Pi PJ H PH o y J PJ

? P < 00 oo

PH DC o Ü

§ O H <

Ü H

O PH PH o

o <

Ü

o PH PH o

B O o 'S

Pi O PH PH O

B O o to

Pi o PH p- o

B o o to

Pi O PH PH

O

B O o to

Pi O PH PH

o

B O o

B O o

Pi O PH PH O

Pi o PH PH o

B O o to

Pi O PH PH o

B O p CO

Pi O PH PH o

B O o to

Pi o PH PH o

B o o to

Pi O PH PH o

B O O to

Pi o PH PH O

E B o o o £ to to E E

pi o PH PH

o

Pi o PH PH o

s o o

M E

Pi O PH PH o

B O o 03

E

pi o PH PH O

B O O to E

Pi O PH PH o

Pi o PH PH o

■8 B oo

< < < < <

O H < HJ PH.

Ü H

$ O PH PH o

B B o o

to CO

Pi O PH PH

o

©

< W z o

Q U

t/3

n n n n □ □ □ □ □ □ □ □ □ □

)-H o

D D

□ o fc BlS

co S HH

H CO *i O H H1

&i PJ PJ

Oi 2 oi 9 oi

^ < < oi PJ K H.

§ s H U 

PH W

CO PJ

U

w >,

a S o u S

§

w CO

P- w

<!

t—H

CO

< o z

§

<

Z' °. CO

P O <

1

1

PJ

CO

§ PH PJ

i o

5: 0

a S PJ >

H O

z 0

I1 CO CO

1 OH

P O

H1

O

t-1

u P Q Z

W P £ z

D u w

w1

H D U PQ

Q

u S D CO

U Oi'

5 H1

U D P Z

H1

U PJ1

H D O PJ

3 z 0

Z

PJ1

H D u PJ

U 3 U o o X X § < < o O ,, X U O X o a> a> Cd .— c 3 3 3 3 3 -O x> ^J .fi * ^ •2 W) C8 to C3 CO CO CO co CO CO CO CO CO

c c c c c c c B c c C c *co a> d> .SP .SP .SP .SP .£P .SP .2P op .SP .£P .SP .SP < 5 5 *« 'lo 'to "« 'co 'co 'cfl *co 'co 5 ^ -S 'w "co 'co

to as en VI to « CO CO CO CO to c3 cd cd CO CO CO

1> c <. <. <. <. <■ <. <, <, <, C

.SP <, «, <, CO 1 1 1 1 , 1

P to co 4-» •*-» ■*-» +-* +-» +-» *i/i "co "co 4-» VI CO O O O o O o O O O i/} CO CO 0 0 O < < Z Z Z Z z Z z Z z < < < z z z

o 0 a 0 0 Ü hH HH

J 3 _1 J J ►J

fel fol fe| fel

PH 1 fei

Oi' oi' Oi' Oi' oi1 oi1

PJ PJ p PJ w PJ H H H H H 0- OH OH OH OH P-

z 2 z z z Z z Z z z z O O O O 0 O o O o o o o o o o o o y O y y y y o O o o o o o o o o o 3 J j H3 3 j

4-> H H H H H H H H H H H pj PJ s PJ PJ '8 < < < < < < < < < < < ffi K S X E, D _) J J J J J J »J J J J j 1 1 1 1 j

eu, P*. p<, P-1, p-, P-, fu, P"1, p-, P", ^I x 1^ u Ui Ni t^

s1 s1 s1 s1 s1 S' s1 s1 s1 s1 s1

< < 0 <

0 <c < <

Ü H 12 g g Ü o o Ü a g P t H t &

<, <, <. <. <. <, <, <. <■ <■ <, <, <, «, <, <, <, 0i' 0i' oi1 oi1 oi' Oi' Oi' Oi' Oi' Oi' oi1 oi' oi1 Oi' Oi' oi1 Oi' O O o o o O o O o O O O 0 O O 0 O PH PH PH PH PH UH PH PH PH PH PH ^ r ^ r ^ r fc r fe r

fe r OH OH OH OH 0H OH 0- OH OH OH OH OH H OH H OH H OH H OH H OH H o o o o O o O o o o o O ffi 0 X O K O ffi O X O ffi

Ö jg "3 Ö e c c c a c e c c c c c n e a C J3 o o o o o o o o o o o O 0 0 0 0 O o o o o o o o o o o o o O 0 0 0 0 O

W 4-* 4-J 4-» 4-> 4—* 4-» -4-* ■4-» 4-H

e3 co co to CO CO CO 'S co ■fo S CO co co CO CO CO

E E E E E E E E E E E E OH OH OH OH OH

.13 oi 0Ü oi oi oi oi oi oi Oi oi oi oi oi Oi Pi Oi ed <» o O o O O O O O O O O O O O O O O

u-, PH PH PH PH n- PH PH PH PH PH PH PH PH PH PH PH OH OH OH OH OH OH OH OH OH OH OH OH OH OH OH OH OH

o o o o O O o o o o o o O O O O O

ro

<!

oo

< ON ON

m W 00"

£ JH o <

ä s Q U )-H H-H

H CO

□ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ a Cl ~ r»

RSH BI8

CO

O

m fa 00

00

z H 0 W p °. ai

u b- 00

00 O PH $

X u

Pi <

w

p

Z O P

1 P PJ

00

3 p1 b1

1

tu

"2 O

P1

<

3 

0

5 0 s s 0 u 2 z1

°. 00 I p

3 w OH

S 0 Q 2

00 00

< w u § p

> 0

a p 2

P 00 < w

00

b W

<,

H U

z 0

s1 00 00

5

p1

< 0

< 0 P 0

W

P

w S P GO

H1

U D P Z

w1

H P U w

H P 0 w

H1

U P a z

W P 5 H z PQ

J P

PH

P u P 00

H1

U

ol H

Oi H1

O P P z P

w

Z

B1 P U w a

P 00

H U P P Z

§ O O

X X w <

0 0

0 u 0 § s JS 0

U < O O

X w s O

u

3 CD a> <L> <D _cg J2 s. _u CJ 4> <a CD CD a> CD C3 C 3 3 3 3 3 3 3 3 3 3 Ä -O -2 ^ -9 üß CO co CO CO CO CO co CO CO 03 CO CO co CO CO

"to c OX) .1 a> -2H Ja c

.SP c

.£P e c

.SP c

.2P C

.SP .§> c .SP

cu .1 c .SP .1 c

.SP .1 CD

< 'to CO 3 3 3 "crt 'c/5 "w *cn *W5 *w CO 'co ^ CO "en CO 'en CO •s CO CO CO co CO en C/5 cfl CO Crt « CO en cd CO en CO en CO TO 0 <. <. B c

00 e 6ß <, <. < <, <■ «. <, <, .1 <, <, <■ «, <, .1 CO

p 1 *J en en CO J J *H'

^jl *H'

^^t *H' *H' CO +H *H' *H' *.' 1

CO 0 0 en en Crt 0 O O O O 0 0 0 CO 0 0 0 O 0 CO

z Z < < < z z z z z z z z < z z z z z <

a O z j J 0 fc, fe, 0

w H b b

H H H H H H H X K ffi ffi X ffi < 0 Ü Ü Ü Ü Ü H4

z- z z z z z z z z z z J 3 J fcl 0 O 0 0 0 0 0 0 0 0 0 0 0 ^, fe. tL<, fc, fe, fe, S 0 y 0 0 0 0 0 0 0 0 0 0 0 H1

b

ol U

H1

b

ol U

H1

b

z 0

H1

b

U

H1

b H1

b

0 "a D

)—1

3 3

3 < < < <

l-J < < < <

^1

< <

^1

< <

w w W W W w W W w w W PH PÜ OH b1 OH 0Ä

a Q

O Q

O Q

Ü Q

Ü P

0 p

Ü P

Ü P

a p

Ü P

Ü P <, <, <, <, b1

s 2 2 2 2 2 2 2 2 2 2 2 ^ ^ £ ^ ^ £ <. <. mi ml ml ml mi mi mi mi mi ml mi

fc| fe| fc| fe| fc| fel *' *' *' «S1 b-1 oi1 Pi' oi1 Pi1 oi' oi1 Pi1 oi1 Pi' oi1 b-' Öd' Pi' b1' b1' 0 0 0 0 0 0 O 0 0 0 0 0 0 O O O O O 0 0 ÜH b , b b b p- b b b b b b b b & b b b b b AH H b H OH OH OH OH OH OH PH OH b b b b b b b b b b O X O ffi O 0 0 0 0 O O O O O O O O O O O O O

0 0

"ö3 a c s B B s c c s c s c c c a c c a B B J3 0 0 0 O 0 0 0 0 0 0 0 0 0 0 0 0 0 0 O O O 0 0 0 O 0 0 0 0 0 0 0 0 0 0 0 0 0 0 O O a 4-> ■«_» 4—1 -t—* ■4-* •!-» +H ■4-H +H *H +H +H +H

03 13 03 03 co CO CO 03 to s CO co co CO 03 co CO CO CO co b b s b b 5u E OH b b b b b b b b b b b b

a; a; PS* Pi PS1 OH OH PA ei OH 0Ä OS1 PH OH b1

«■ OH Oi Pi OH

do 0 0 0 0 O O O O O O O 0 O O O 0 O O O O b b b ÜH b ÜH b b b b b b b b b b b b b b OH OH OH OH OH OH PH OH b b b b b b b b b b b b O 0 O O 0 O O O O O O O O O O O O O O 0

I

<

00

fa ON as

< r/i r,

W 00

£ ^ o <

ä s Q U HH h-H

H C/2

n n n n □ □ □ □ □ □ □ □ □ □ □ □ □ fa Bs| HIB

00

O

'g

H So O °-,

cz>

< H H

PJ ►4

So O

a1 oo H

S o ^1

z PJ ,-J PH

—1 PJ ^ z 1 a z

o <

g < Pi P §

PJ H a PH

P ■s «,

PJ u < o o oi

00 O <.

oo

o o z PJ p < H *! ^ 2 h> 2

S o u

?!

o s So 00 PJ HJ u PJ

t<

Ü H 00

1 PH' J p

1

> o

M CO CO ►—1

5

Q J PJ

El PJ

s

CJ

Q1

a PJ > O U

PJ1

oo

§ PH W

5

O

PJ

1 1 PH

H

< X

1

z PJ

PJ > o

5

PJ oo

§ P- PJ Q <\

PJ

PJ

pj 00 00

<

o

I H 00

CJ PJ

O fci

00 PJ

u s PJ

PJ H P o

PJ H P CJ

1 co

1 D s

PJ HJ Q

p- p

PJ

s p t/3

H J P < o

00

pj (- p CJ

PJ H P U

PJ H P O

0H

P 0H P

x1 OH

P PH

P

PJ Q > O

PJ PJ H Z >- u w oo PJ PJ PJ CJ u CJ CJ 00 O X X o o JH JÜ J2 JJ (D co c 3 3 3 3 3 3 -2 GO ca CO CO CO co CO CO

*co j) o> d .SP .1) d

.00 .1» d 00

d d .SP

CO JK — (U .2 M IU 4> m d> (U

< 3 CO 1 C/3

en C/5

*co co

en en C/3 CO CO 3 3

CO 3 co 1 3

CO 3

CO ^ « 1 3 1 c &o a <. <, <. «. <. <, <, c

.SP c

.SP .SP d

.SP d t>0 t>0 .I C3

CO | i 1 i | 1 1 pi CO W3 "w *co *co "en 'co CO en en en en en

CO EO o o O o o O O en CO CO en CO CO en en en en en < < Z £ Z J5 Z Z z < < < < < < < < < < <;

Z z Z z z z Z z z o o o o o o o o o o o o o o o o o o H H H H H H H H H < < < < < < < < < J J J ►J 1-1 HJ J hJ HJ fcl fcl fcl °"l °*l fcl ^1 fcl *l

a 1

S a a a 1

a a < < < < < < < < < z z z z 5 z g g g g g

'S a a a a a a a a a o o o o

o o

o o o o o o

o o o o o o o o

o o P < <c < < < < < < < H H p H H H H H H H H

*, * *, *, *, *, ^, ^, *> < < < < < < < <

hJ < < <

w w PJ PJ « PJ pj pj ^i °-l ^1 fci ^1 °*i fci fci fci *i fai S £ S s s s s c s «:' Pi1 Bi1 rt' Pi1 Pi' Pi' g 1 1 ^i

s. s. 2. s. s. s. s. s. 2, s, 2, 2, 2, 2, 2, 2, 2, 1 1 I

oi1 Pi' pi1 *' Pi1 *' Pi1 pi1 fti1 oi1 Pi1 Pi1 Pi' oi1 Pi' Pi' oi1 oi1 Pi' oi' o o o o o o o o o o O o o o o O O O O O b PH P-, PH PH p. PH PH PH PH P- p- PH PH PH PH PH PH PH PH OH PH OH OH PH PH PH PH PH OH PH PH OH OH PH OH PH OH PH PH

O O o o o O o O O o O o o o o O o o o o

d

"<3 d d d d d d d d d d d d d d d d d d d d .C o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o R o

PJ +H 4-* •4-» ■♦-* ■*-» ■♦H ■*-» ■4-» ■+■2 +H +ä to to 03 to S CO CO eo to CO CO CO co CO CO co CO CO co CO

s E s s S s PH PH CÜ s E PH PH OH PH OH OH OH PH PH

12 oi «: Oi Pi Pi Pi Pi Pi Pi oi pi Pi Pi Pi Pi Pi Pi oi Pi Pi oo O o O O O o O O O o O O o O o O o o O o

ix p. PH PH PH PH PH PH PH PH PH p- PH PH PH PH PH PH PH PH OH OH OH PH PH PH PH OH PU OH PH PH OH PH PH PH PH OH OH PH

o o o o o o o o o o o o o O o O o O O o

00

< OS as

m W 00

£ ^ O <

ä s Q U i—i »—i

H CO

□ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □

HI8

a: O

"g 0) ffl

CO

c OX)

e o u

J3 u W

W H P O

oo 00 < PH

>

2

c 60

Z O o < p-J

*l Pi

O

o

D

W J J

I oo

U <

w oo

P. W D.

U P D Z o u

2 o oo 00

W D £

§

u

z o

°, oo

§ H U

H D u w X w

w

P oo

9 S

w o

00 PQ o

<:

l H U <

ES

oo

P 00 <

W oo

W

| 00 oo

Z o u oo

H U <

> oo < >

o Pi <

Q

s s £ fS

3 u p Q z o U U

o p Q

oo PJ

U

X w >.

00

H

P' P o w X w

w > o s. w H P U PQ X u

oo W J u S3 w

•8 c 60

X>

c 60

•8 c OB

a oo

•s a oo

X> ea C 60

•s e oo

•s c oo

■s X) ca c 60

s J2 J! ü ü ü Ü 5)

en •— .~

< < S o z z

5 5 3 o o o Z Z Z

5 5 o o Z Z

o o Z Z

•8 c oo

X) C3 a oo

8 a 60

XI as c 60

8 c 60

x> ea c oo

8 a 60

.Ü -22 J£ ca ca cd

c a ep op

<<<<<<<

<*> <. ^=1 3 S o S z z z

o < <x.

Pi o

o

o <

Pi

o PH

O

Pi

O PH

o

o

<

o PH

o

z o o H <

o PH PH

o

o <

Pi

o PH PH

O

o < PH.

Pi o PH PH

o

§ <

o PH PH

o

o

<

Pi

o PH PH

o

o < PH

pi S pi o PH PH

O

§ O H <

I o

o <

i1 o <

i1 u u

<

§

z o o <

i1

z o o H <

i s. s. s. s.

Pi o PH PH

O

Pi o PH PH

o

Pi o PH PH

o

I I

o § o <

o u

o

s. s. s. s. Pi o PH PH

o

Pi o PH PH o

Pi o PH PH

o

Pi o PH

o

Pi o PH

o

c c o o o o

■4-» +-» ca ca

c o o

_ ta PH EC

g o ta

Pi O PH PH

o

Pi o PH PH

o

Pi o PH PH

o

Pi o PH PH

o

c o o ta E

pi o PH PH

o

o o a

pi o PH PH

o

c o o

Pi O PH PH

o

c o o

"ca PH

Pi o PH PH

o

s o o ta

Pi O PH PH

o

ö o o 'S

Pi O PH PH

o

c o o

M

Pi o PH PH

o

a o o ta

Pi O PH PH

o

c o o ta

Pi O PH PH

o

c o o ta

Pi O PH PH

o

c o o ta cä E E

c o o

Pi O PH PH

o

Pi o PH PH

o

c o o ta E

pi o PH PH

o

e o o ta E

Pi O PH PH

O

s o o ta

Pi o PH

o

a o o

Pi O PH PH

o

ö o o ta

Pi O PH PH

o

□ □ □ □ D □ □ □ □ □ □ □ □ □ o

□ □ □ □ ^ □ ° L_ □ r-. f-H ■—, ° H

Bio

5

fa

CO

oo

00 O OH

X X w u u

1 J pi pi Q u 00 < oo oo ^ PJ < § 1 § § PH o i § < PJ

00 D oo oo Q1

< O Pi

El P oo J Q

< O

El L-i o

Z < W PJ

E- P O

00 00 < PH

>

PH

Pi PJ > o u

H pi PJ

E- U

< PJ

PJ p PH H

Pi PJ

5 00

1

i w 00

p.



-j

<

E^ 1 oo 00

PJ1

oo

PH

1

<

< o H O H

-J

s PJ >

HJ

HJ

> o

PJ Q

I s, 5, < o 2, i

oo

§' 1 PJ |

< s, o i PJ D u

w

P 00

H U Pi' PQ

W > 2

u D Q Z

H1

U P Q Z

PJ1

H P O PJ

pj1

H P O PJ H

PJ P s z PJ

HJ

Q

PJ s p oo 1

H1

U P a z

H U P Q z

PJ1

H P U PJ

PJ1

H P U PJ

oo1

Q u £ < < o o X X U U o § < o o X X U o H P H u o PJ PJ < Ä CD J2 CD CD CO 3 IB 3 3 3 3 3 3 3 5 3 ^S •s §) C3 ^ 13 13 (3 CO C3 a a cd cs cd ro

'co .1 c 00

c 00

c op

c s _4> ID CD <o .1 c .op .§>

C .00

s op

c .op CD CD .52 CD .§> co

< "co CO

'co CO

'co CO

'co CO

'co CO

*CO CO

3 to 1 1 1 'co

CO C/3 'co

CO 'co

CO 'cO

CO 3 1 3 CO 3 CO

CO

CD CO 5 5 5 5 5 J c

.op co

.1 .00 "co 5 5 i 5 5 5 C3

-SP "w3 .SP "co

c .op *CO

.SP 5 p o 5 O o O O en w Cfl c/> o o o O O o C/3 CO CO CO O

Z 2 Z z Z z < < < < Z z Z Z z Z < < < < z

z z Z z z Z z z z Z o o o o o O o o o O o o o o o o o o o o

O H ■<

§ o H •<

o E- <

§ z Z Z Z Z z z H E- H H H H H H H H 5 o O o O o o < < < < < < < < < < o

t-H o o o o o o o J HJ J h-J J J J J J HJ

H p- H H H f- PH 1 &l fcl fcl ^1 ^1 fcl ^1 ^l ^1 ■< <

'3 p < 0-

< 5-

< 0-1

< ►J PH

< PH

< PH Pi Pi Pi a Pi

>; pi Pi Pi Pi pi

-J J ^1

-J ^

l 1 1 1 1 1 PJ w PJ PJ PJ PJ PJ PJ PJ w >- i_3 HJ _j Z z z z z z > > > > > > > > > >

o o o o o o o o o o o o o o o o PH PH PH PH PH

O u u u u u u u u u u u u O O u PH PH PH PH

S, §, s, §, §, §, §, s, s, s, §, i S, §, S, §, P 00 1

P oo 1

P 00 )

P oo 1

pi' Pi1 Pi' Pi1 Pi1 Pi1 Pi1 Pi1 Pi1 Pi1 Pi1 Pi1 pi1 Pi' Pi' Pi1 pi1 Pi1 Pi1 Pi' Pi1

o o o o o o o o o o o o o o o o o O O O O PH PH PH PH PH PH PH PH PH PH PH ÖH PH PH PH PH u- PH PH PH PH

PH OH PH PH PH PH P- PH PH PH PH PH PH PH PH PH PH PH PH PH PH

o o O O O o o o o o o o o o o O O o o o o

C c e c c c c c c c c c c a c s c c s c c a

J3 o o o o o o o o o o o o o o o o o o o o o ü o o o o o o o o o o o o o o o o o o o 2 o

pa to 13 s 'S 03 t3 t3 'S t3 t3 13 03 13 13 13 13 13 13 13 13 Is s E E E E E E E E E E E E E E E E E E E E

CD Pi ÖH pi Pi pi Pi pi pi pi pi Pi Pi pi Pi pi Pi pi pi Pi pi Pi

oo o o O O O O O O o O o O o o o o O O O o O PH [in PH PH PH PH PH PH PH PH PH PH PH s^ PH PH PH PH PH PH PH

PH OH PH PH PH PH P- PH PH PH PH PH PH PH PH PH PH PH PH PH PH

O o o o o o o o o o O o o o o o O O O o o

■ <

1 u-, <

ON ON

r/l „ W oo

£ > o <

ä S Q U M t—H

H CO Q <

n □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ _ D ° <_

SIB

CO

o

"g x\

CO

H 00

O PH

oo 1

< H P 00 H z O S o

o

PJ H

13

Q PJ

< PJ

z o 00

< a 5

pj

PH PH

P 00

2

3 Ei

U <

o u z Ü <

Pi H

O H1

S X o

p

s, oo 00 < PH

>« m

PH

U

o So Ü H 00

t P-1 HJ p Pi PJ w o O z § W PJ CQ O o <* J 00

Z p1

a PJ > o u,

^i w 00 Q PH PJ Ä

>-l z z 00 o So oo

I a1

<

H

 o j

z PJ PH PJ Q,

PH' w 00 00

z

1 Ü z o Pi H 00

00

PJ1

o

Q1

<

.' PJ

PJ PJ X1

>■' x1 >.' PJ1

Q

> J 00 5

H PJ

Q

PH

P P 00

P < 00

P U O

PH

D PH

D P- P

P- P

PJ > g H P

U Z o w w w u V U O oo o U pi H H 12 z PJ

O o a 00 X X X u u u u z Pi o .2 cu .— _u a .SP

c .SP

c .SP .SP

< CO CO co CO 3 3 3 3 3 3 3 5 § 5 ? S 'co 'co "co *co CO CO CO CO 03 03 03 03 03 03 03 CO CO C3 ca 03 CO CO CO CO

<■ <. <. <, C .SP .!>

c .SP

c .SP

c .SP

c .SP

£3 .SP

c .SP .§> B .!>

C .SP <, <, <, <,

V) 1 . J 1 1

P ■4-» +-» +-» 'co CO 'co *co *« "co *co "co CO Xfl CO *co 4-» o o o 'S CO CO CO CO CO CO CO CO CO CO CO CO o o o o Z z z z < < < < <c < < < < < < <c z z z z

z z z z O O H < ^1

o o H <

o o H <

o o H <

z z z z z z z z z Z z z z z z z o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o

■4-* H H H H H H H H H H H H H H H H

5 < < < < < < < < <c < < <c < < <: < J J J J HJ J HJ J J ►J HJ J HJ HJ HJ HJ

>« >H' >- >- °-l fcl *! *l ^1 fcl fci *l ^1 *l fcl fcl fcl fcl fci fcl

p* PH PH

PH PH

a1 ^' ^' ^' a1 ^' ^' «' «' ^' i 1 i 1 ^' I

z z z z z z z z z z ^ z ^ ^ z z pi o o < < < < < < < < < < < < < < < < C/)

i 00

1 00

1 00

i f-, f-, f-, 1 H

1 f-, ^, f-, t-. H, H. ^, f-. ^, h ^, *' Pi1

PH' Pi' *' Pi1 Pi1 P-1 Pi1 oi' Pi1 Pi1 Pi1 Pi1 Pi' Pi1 Pi' Pi1 Pi1 Pi1

O O o O o o o o o o o o o o o o o o o o P- PH PH P- PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH OH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH

O O o O o o o O o O o o O o o o o o O o

c o

"53 e a e e e c c c c c a c c 13 c Ö c e c c J3 o o o o o o o o o o o o o O o o o o o o o o o o o o o o o o o o o o o o o o o o o

PJ 4-* 4-t ■4-» ■*-» ■*-» ■*-» -*-» -»-» H-» +H 'S 03 'S S s 03 03 S 03 S 03 to S C3 03 03 S CS CS (8

PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH P-

■IS pi Pi Pi Pi Pi 0Ä Pi Pi Pi Pi Pi Pi Pi Pi Pi Pi pi Pi Pi Pi bo O o O o o O o o o o o o o o o o O o O O

u. PH tin PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH P- o o o o o o O o o o o o o o O o o O o o

I

1

< ON t—1

oo W oo

£ ^ O <

ä s Q U h—1 l—\

H 00

n n n n n n n n n □ □ □ □ □

C/3

o

(I) m

D D n □ □ o HS BIB

5 t>0

■8 C OX)

PJ

! o PH PL, o

a o o ts

Pi O PH PH O

PJ

o

oo

I oo

P on < PJ

I w 00

Z

H U <

2

PJ

a'

on

§ H O < PJ' > CO

< >

W

Q

to ffl

i w

w PH

O

Ü1

sss 2

w S o

Pi < w u

Pi <

00 PJ -J

PJ U H P rn a, > , 1 H H U P Q §

O

00

u P

-1

PJ H P U w X PJ

w > o

w H P u PJ X PJ

Pi w w ,-J _l C ) _l < H H r* 00

<. HI o

a 5 PJ

00 W 2

o S u u n DC w >,

S z1 5

00 00

H1

O

u oo1

u

H 00

PJ D s

^ (- z Z s u o O

 o

D u u o

PJ

p 00

3

oo w u pa >.

o S 00

a

P U PJ PJ X X PJ PJ

X) X) HO at C8 C3 e c c 00 60 00 co CO CO EA CO CO

<, <, <, ■J +J ■J o O O Z z Z

■8 S»

■S c 60 yj 1-«*J W*/ W W*J W*.

< '" '" " " ~

P

•s c Oß

•s c ÖX)

1)

c 60 ^1 I UJJ UJJ WUJ «JJJ U« IM1

+e ■♦=? 'co 'co *w "co 'co 'lo -ti

C oo

•8 c oo

CO C oo

C 00

S3 c 00

JO

c 00

•8 a 00

c 00

o Z 2 < < < < < <

-t-» +H o o Z Z z z

1) CD

c c oo oo

•4-» +-» o o Z Z

•s s oo

o <

;■ z

S o PH PH

O

o < PH.

s o PH PH

o

o

5 o PH PH

o

<

o ÜH PH

o

§ o <

H' oo

§

Pi O PH PH

o

o <

& oo

Pi O PH PH

o

o <

oo

§

u pj

o PH PH

o

z o o < t-J z< oo

£5

x' u

Pi o PH PH

o

§ o <

H1 00 Z O

u

& Pi o PH PH

o

o <

H' oo

§ X' U PJ

o PH PH

O

z o o < PH

oo

o I

X o PJ

o PH PH

o

§ o < HJ

H' 00

§ x' u

Pi O PH PH

o

o <

z> oo

§ X' U PJ

o PH PH

O

< HJ

H' 00

u

u PJ

-' o PH PH

o

§ o <

H' 00

§ X' u

Pi o PH PH

o

o <

H1

oo z o

X' U

Pi o PH PH

o

§ <

H' 00

pi o PH PH o

Q < P

S1

Ü H

o PH PH

o

o H

o PH PH

o

c o o to

Pi O PH PH

o

a o o 'S

Pi o PH PH o

c o o

■S3

Pi O PH PH

o

s o p

Pi o PH PH

o

a o o

Pi O PH PH

o

c o o

Pi O PH PH

o

c o o

Pi O PH PH

O

c o p cd

Pi O PH PH

o

c o o 3

Pi O PH PH

o

c o o to

Pi O PH PH

o

c o o to

Pi O PH PH

O

c o o

Pi O PH P- o

c o o

Pi O PH PH

o

c o o ts

Pi o PH PH

O

c o p as

Pi O PH PH

o

a o o ta

Pi O PH PH

o

c o

1

Pi O PH PH o

Pi o PH PH

o

Pi o PH PH

o

■S c oo

< < <

Q

. s . o o o oo

a s

00 00

a

o PH PH o

•o -o •o at CS CB 3 3 3 IT cr tr

00 00 oo

Pi o PH PH o

PH

< w

§

Q U

00

□ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □

C/3 l-l O

tu

© M

oo Z o p oo O CM

1 1

fS z z o PJ

LH

H w § 1 Ü 00 ►J PH" PH

XJ o PH | o (2H

Pj' >

OH

P 00

m1 00

><

PH _1

oo

p PJ oo

PH

PJ HJ

00

s p PJ

00 00 PJ

U

£ pj

Z> o 00

5

PJ > O

H P U PJ

00

00

§ pH PJ Q

l

P- P O

PJ > 00

Z PJ PH

PJ

PH

P

PJ

u s PJ

o

■J

00

1

< PJ

00

§ PH

PJ Q

<

PH PJ

o p o z

00 00

1 z PJ

Q

PJ

p 00

00

< PJ

s PJ1

00

PH PJ

<

P- PJ

% O P Q Z

Z o 00 00

§ PJ1

t- Z

H HJ

1 P u PJ

PJ

Q

z o H oo O

? PH

P u

PJ HJ o X PJ

t> o p

00

o a o § <

o u o § u < o u o u X PJ

X PJ

o o s §

3 <L> _a> _«> a u a> cu cu (L> (L) 0) tu tu CO _H _H

tä 3 3 3 3 3 3 3 -o J2 JO JO -o x> X) -2 -2 -2 .£P es CS es es es es es es es es es es es es es es es

c c a s c C C c B ß B ß ß B C B ß 'co 4> <D d> 60 .£P 60 .SP .SP .60 60 60 60 60 60 60 60 60 60 60 60

<: PC ^ ^ 'co "co "co "« *w 'w cn c/l co co co co co co co co co CÖ CÖ CO CO co CO cn w co cn cn CO co co co co co co co co

C <, «, <, <, <, <, <, <, <■ <, <, <, <, «, <, <, <, P .J *J +J +H1 ^1 -t-» +j

| «-1 <J ♦H1 . I <-.' ■K1 *H' ♦H1 •M1 4H1

w w cn O O O o O O O O O O O O O O O o O

< < < Z 2 Z Z Z Z Z Z z z Z z Z z z z z

P Q Q P Q Q P Q Q ■4-» < < < <C < < < < < 'S P

P C 00

P a 00

P a oo

P O 00

P a P a 00

P a 00

P a oo

P a 00 <

Q <

D <

Q <

Q <

Q <

Q <

Q <

Q <

p <

p <

1 1 l l 1 „1 „1 l ^1 p P P P P P P P P p p s s 2 s s s s s s a a a a a a a a a a a a Ü o ü Ü a Ü Ü O 00

1 00

1 00

1 00

1 00

1 00 1 00 1

00 1

00 1

00 t

oo i

H H H H H H H H H 1 1 1 1 1 1 1 1 . ,1 1 i

<. < <, <, <■ <■ <, <, <, Q, Q, a. a, o, a a, a i Q, o, Q, V PH' *' PH' PH' Pi1 Pi' Pi' Pi1 Pi1 PH' PH' PH' p-1 PA1

Pi' Pi' Pd1 P41 p--1

O o O o o o O O O o o o o O o o o o O o PH PH PH PH PH PH PH PH PH PH p- PH PH PH PH PH PH PH PH PH

cu PH PH PH PH PH PH PH PH PH p- PH PH PH PH PH PH PH PH PH

O o o o o o o o o o o o o o O o O o O o

ß o

"öS .ß •a T3 T3 -o TJ •a T3 •o -o T3 T3 •o T3 -o "O T> ■a ■o T3 "O u CS CS es es es es es es CS CS es es es es CS es es es es es W s s 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3,

er er er er er er er er er er er er er er er er er er er er oo oo 00 00 00 00 oo oo 00 00 00 00 00 oo 00 00 00 oo oo oo

PS1 Pi P- c4 PH PH1 Pü £* PH Pi * P, PS1 ei PH PS1 PH1 Pü PH PS1

bo O O O O O O O o o O O O O O o O o O O O b PH PH PH PH PH PH PH PH PH PH P- PH PH PH PH PH PH PH PH

PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH PH 0H PH PH

O o o o O o o o o o o O o o o o o o o O

00 ff)

00

HH ON as

< *—i

r/> „ 00

z >- O <

ä s Q U H-1 h—1

H cvo

5

n n □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □

WS

O

ffl

CO

O

o

<N

fe .ts

§ I

WS +_i

3 ws

bi) 3 .S *ö

a 2 H >

Is 4>

p5

~a 4)

on H

O

o on W ►J O S w >

o Ü

c P 4-* a. u u u <

on W ►J U 55 w

y p W H

oo co H b co

h Jj'!

o

H Pu

s H

o

ON

on H

W :o

§ b W Q.

9 * on W J U X w

CO

Z w w

e o

o PU

a. 3 u u O

■I * cd

X < a <

on H

Ü co W

u 55 a >

s a

§

on H

O Pi Ü on W

U h-H

X w >.

on w o 55 w

<

on W

s

Q

co

W

u 55 w

J N N 2 o

c o

 o o Pi 1>

< <

Ü <> C nt

S Si CO Q u

C3 2 < u

CO e < <

w u 55 w

& < w u £

J N N 2 o

on W

u 55 w

o S S on W J

coü J W

Sa1

y w

§ on do

S PH

o CS

< OS as

m W 00

£ ^ O <

ä S Q U I—1 HH

H 00 Q <

D D D n n n D D D □ □ □ □ □

5 □ □ D o < n s ^ □1 o

£ S c p

o

Q Q

fin

en CO H

U s 00

o

o

00

o <* o

00 00 1> W PJ f> J J

•fi u u

^ w >, >

* o1 Q T3 tu § § £ O o o Pi c* *f o O

00 00 w w

00 00

<

O

m m.

9 9 O O

X w

w u

oo pa o

w

u od », tu

00 pa O

00 W

U 00 W

/—s 00 H

X W 5

§ o u o u

Q1 s Q § s' £ O u Ü öS ffi Pi o o O

oo w

<

o U.

s a

00 W

PH

S o u.

a



.s 43

MH

a) >> > P3 43 ^ <> u w re ti C < > "E. Q

> <L>

B <U

Pi

03

O ft, <o 60

C 3

00

"3

s

a. <D u u

E en

o (3 J3

60 c '•& c 3 o "e3

5 oo oo 5 < < < 03 K e C 'S ■s 43 J= o o o O O m aa CQ pa u u U u o U u

00

(X, as as

< (71 W 00

£ >H o <

ä S Q U M l_H

H 00 Q <

D n n □ □ □ □ □ □ □ □ □ □ □ □ □ □ H - 3i □ o «3 n ~ ^ □I o

00 W J o ffi

w w r>,

|2 H aihs

to W oo 6 Q H -"-1

u IS

CO CR

USA

O

N U

NI

NT

RO

L

c D £88 ■a

is § < H 5 J n

CO b § P & s .

s

I

00

w H

§ w >,

Q

> Q w rt u a

c o

o OH

a u o o

ca K O U

o

J3 u

B o '3 O

'S

J3

o H tJ o

00 u u

1> 00

60

'S >

a op

'So CO

1 r!

OH

ex o<

CO B D

o o O O o O O o u u U U U U U u

a CD

CO <D u B O U

en U ,S rrt

<L> i- > Tl <U

en en

ea O

u

00

< ON ON

r/i ^ W 00

z ^ o <

ä s Q <J h-l 1—1

H 00

n n n n n n n n n □ □ □ □ □ □ □ □ □ © HS LJ ON

C/l l-H O

"g <L>

C/3

oo H 00

PJ J u

00 oo 00 00 00 00 Z PJ PJ PJ PJ PJ PJ ^ J J J J J ►J . 00 Q U o U U U

£ 53 PJ >

F— oo 00 53 a 53 a a a s H Z PJ w PJ PJ PJ PJ w

< oo y 55

>, >. >. >. >. >, oo PJ J U

53

§ J1 _1

1 g z1 z1 z1 z1 z1

z DH PH Z P* PJ o

53 w

u 53 w

pj o u

o u

o o

o o

o u

o o

o o

D 00

u o

t—' u H-( s S s § § §

E- PJ H O a > >, 1 j ^1 J 1 <C > Q < o, 00

H w

Q

H oo W

o1

00 Di O

00 C/D s < < < < < <

co o1 Di <

O Di Ü

o s H1

O 2 H

00 H

u <

OO H

H

o Di H z o

O H oo H

oo PJ

PH 00 PJ HJ

PH

00 W

PH

00 W hJ

PH

00 PJ

PH

oo PJ ,-1

IS u

CO

'S 1

00 PJ ■J u 53

00 H

i

H PJ ►J u a

2 oo PJ

<_>

q Di Di H

z o

PJ

u 53 PJ

U

53 tu >,

S es S y ZH a o z

u M

a pj

U 53 PJ

u M

a PJ

53 PJ

U a PJ

U HH a PJ

D Di PJ Di PJ o o > _l w O O o > pi Di Di Di Di Di T3 PJ >, w > a u „1 Q >. r U 1 ü_ < < < < < < Q z %

i—• Q O Q z S1 o

00 o 00

o oo

o 00

o oo

o 00

o

"3 «3

00

o * ^ S a Q1

s N N 2

o 5 2 < o < a

Q1 PJ

$ ä' 1 i i I'

Q U H U O H H H o P H DH H H u. P- PL, PH PH PH

?—s

t ■. 00 PJ

u a PJ > /^*v

00 i 00 H S H

1 1 1 Q Q /~s ^-^ ^-^ >^*S ^-N

00 W J U

/—s 00

00 H

00 H

00 H

00 H

oo H

§ 00 W O

Di g § | § | o PJ a u 00* Ü .1 .1 .1 .1 .1

co C/)

00 PJ >.

00 W

53 H 00 w ä £ ä 1 1

[o H J a a1 U

> H 00 u ^^ p- /—^ PH PH PH PH

2 u PJ 1 1 W 00 00 00 oo oo 00 00

CO *'

53 PJ > o

oi »1

M

a w >

00 O ? U

a

53 w >,

H PJ

U

PJ HJ O

PJ J O

PJ J U M

PJ hJ U

PJ -J U

'S PJ -i w -i Ü fa ^1 ^1 a a a a 53 a o Q Q J Q 1

S' Q Q PJ PJ PJ PJ PJ w

< 00

g < § Q1

W X

§ § >j ;, >. >j >j >. £ p o z H O a

00 O O < ^ ^ < ^ ^

_o s oi £

00 m o

Di o Di Di ^ ^ £ £ ^ ^ < Ü fe Ü ü p-, ^—' & PH PH fe fe-

es c

a

'co co

s 4>

s CO

c o

(L>

o. O.

ffl s oo

_U o 3 O IM

.3 e

z

_5<s

o o OH u* D •o es CO Ja*

PH

o cS

> o CS

IS >

+-» S 3 o E

IS > es

O

"3 S

00

Ü

o es

<

DH



tsO PJ

< a <

o 'S

1 <

CO

CC5 E "ö> t> ■4-» 1) £P <«

"o "o ^ ^ & ^ * ^ H c_> Q Q Q D 5 w HH b P- PH PH PH PH P-

1 ON OS

< xr\ W 00

% >< O <

ä s Q U i—i HH

H 00

□ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ n ü ^ □1 o

O

oo t/1 tu P-I HJ 1-1 u u K X w w >, > 2 Z Ü Ü u u s s <' < £ £ u< UH

C/J 1/3 ro w W

U HJ HJ JÖ u u D

£ X X w tu

'3 >, > L-> Pi Pi ■o < < 4> o o

00 ro O 1

< < cfl £ £ u u. u.

03 oa (2 E 3 Pi

i <

c/> co W w -1 HJ U u « ffi p-i w >, > <' < £ £ u. u.

ID u

<

co W J U

X w

00 00 W W

u u 53 55

§

CM

<

> < D

s

ea PQ o

£ 3 Pi > < D

§

00 W J u x w > £' u Pi m.

a

00 00

a1 a1

o Pi o oo W

u

l £

O Pi a

u •s u m e 3 Ü

C o

o

§• u u O

*. &

00 oo w U4 ^^^ oo

00 W J o

_1 HJ CO H

oo W

oo W ►J

u X W

u 53 w

H oo

oo W

1 X w

H-l u X w

u

w u Pi

5 o.1

w

00

u 53 w >, 00 Pi

u 53 a

*<

Ü > o S s s Ö Ü < 2 S S s £ § S

£0 03 X

O

C o

m

O

c o

O ±i l-H H-1 CO

J3 O a

s s s

c _o u u +-» <o Q ID 60

T3 w

.s

a.

00

o OS u )M

pa

u ö 3 O

s s

i 00

xr\ W oo

£ >< O <

ä s Q U h—t HH

H CO Q <

n n n n n n n n n □ □ □ □ D

CD

m □ □ n s ^

w HJ u X w > u 5 in

<1> a! O O

JS cz> <L> m

*> J « i J

B K EJ w Tl > 0> £ Q

J2 "c3 % to o p H

Ü 1/3 w o X w >

oo w J u

,s

on m j u 3 pa

5

O

H OH.

Ü

w

00 W J u X pq

u Q U S

00 w j o £ >

o Pi Ü

00

cz) H

oo

oo H

00 Pi O

i Q

s a

o Pi o

00 00 W W J J U U )-* >-H

X ffi w W >, > Q1 Q § § O O Pi Pi Ü ü

00 00 00 H H H

a1 Q1 a1

§ g g o O o Pi Pi ad Ü Ü Ü oo 00 00 W W w HJ J HJ <_> u u X X X w w w >, >, >, Q1 a1

Q1

§ g g O o o Pi pi Pi Ü Ü Ü

a> >

e cu 'S P* tu > o

CO O.

Pi cu > o

c o



43

> o

o h a o u +■« O

I OH

tJ co a. a o

o cu

ID 3

3 O >

ID N > 1) ra T3 u C <u <u BÄ PS

o H

t* •e C3 o a. a. O cu Pi Pi

J3 u 13

*T3 ca

I

PH

<

W

§

00 ON

00

< 2

Q u

H t/5 Q

IS

e D T3

<U

O

O

00 H

□ □ □ □ □ □ □ □ □ □ □ □ □ □ £ n -^

R- £ n s °° □I °

c/3 (H O

5 o

i z

PH

H<( CO

E2

s

c D *-» a. u u <

i

< CO

•3 »i o! 00 co W W J HJ nd u y u X w

cd II

*d u

Cd co W

ü

53 w

I

co H

I < CO

co p W I J i4 O O

w r

II

co co

^ *d

$ cd co H

I

< H H

^ co cd w

Sy z K 1=5 w

u cd cd

co H

*d U <

I co H

Cd

co cd < CM

Cd' O H < Z Ü 00 W Q.

Q Z a

cd

co H

< co

00 5 w .1 J *d O U

00 H

J.

I cd

< co

cd Z co p w 1

u u

§9'

co Cd

e-,00 od't: o z

5 u

I

IS ÄS

co co

< ^ < < £h ^ ^ od Z cd Pd co 5 co co W l W pq J Nd H4 J 0 0 u u

K K w w >, > u 6cd

< < ^ ^ c^ cd,

00 W

O 5c w

«5 & D u 00

c o

co

s

<

ü

<

1

c D 0 > ^ ü O

CH

60 a

<L> T3 C

ts 3 C3 O

CQ CO

I I

3

Cd

Rt c 00 Ö

0

"3 to 0) Q 'S

a E D

co

60 *co

co <D

iS J u U

"o Q z >

0 -0

CO

MH 0 X j hJ

cd cd cd I I ■fi O

I

o H

cd

I

c

C3

1 Q D u co

c o

co u u

■g u co

oo PL, ON < m „ W OO

£ >* O <

ä s Q U l—l h-H

H on Q <

a n □ a a □ a □ □ □ □ □ a a a a a □ a □ a

l-c o

■g u

CQ

o <

00 H

2, Ö ■S

oo W ►J

£

PL,

§

oo H

oo H

oo H

r-s w o oo q

00 W >, H

U § I X w < Q1

a , ffi

>, Q Q >. Pi a

O O a1

o Pi PÄ ^ a! a Ü > s* Ü

a, (X 3 o

s en

Pi o Hi Pi <D C ) D. >% ts T> 3 o. M co o. r„j CO <1>

00 3

oo £

1 > O en

.S >

s o u a> £

Appendix B - SAF Entities CCTT SAF Entities


Appendix B - SAF Entities

This Appendix lists the complete set of entities that are implemented in CCTT SAF 5.1.2 and ModSAF 4.0 Beta version.

B.l CCTT SAF Entities

This following table lists the complete set of entities that are implemented for CCTT SAF version 5.1.2. For each entity, the table defines the side (BLUFOR or OPFOR) and the type of entity.

Side Type

BLUFOR Tank

BLUFOR Tank

BLUFOR Tank

BLUFOR Tank

BLUFOR Tank

BLUFOR Mech

BLUFOR Mech

BLUFOR Mech

BLUFOR Mech

BLUFOR Mech

BLUFOR Mech

BLUFOR Artillery

BLUFOR Artillery

BLUFOR Artillery

BLUFOR Engineering

BLUFOR Engineering

BLUFOR Engineering

BLUFOR Engineering

BLUFOR Engineering

BLUFOR Engineering

BLUFOR Engineering

BLUFOR Engineering

Entity

MlAbrams, — Ml Abrams (105mm)

M1A1 _Abrams, — M1A1 Abrams

M1A2,-M1A2

MlAlMineRollers, — M1A1 w/ Mine Rollers

MlAlMinePlows, - Ml Al w/ Mine Plows

M2A2, -- M2A2 Bradley Infantry Fighting Vehicle (IFV)

M3A2, - M3A2 Bradley Cavalry Fighting Vehicle (CFV)

Ml 13A3, - FMC Ml 13 Armored Personnel Carrier (APC), Ml 13A3

M981,-M981FIST-V

Ml064, - Ml064 120-mm Mortar Carrier

M93, - N93 NBC Recon. Vehicle

M270, - M270 Rapid Deployment Multiple Launch Rocket System

M109A5, - Ml09 155-mm SP Howitzer, M109A5

M109A6, - M109 155-mm SP Howitzer, M109A6

M88A2, - M88 Medium Recovery Vehicle, M88A2

M60A1, --M60A1 A VLB

M728, - M728 Combat Engineer Vehicle (CEV)

M9, — M9 Armored Combat Earthmover (ACE)

M577A2, - M577/M577A1/M577A2 Command Post

Ml 13, - FMC (Ml 13) APC Ambulance

M60_Bridge, - M60 Bridge, AVLB Launched

M60_Chassis_Without_Bridge,~

B-



Side Type Entity

BLUFOR Engineering Mtu20_Chassis_Without_Bridge, -

BLUFOR Engineering Mtu20_Bridge

BLUFOR Infantry Observation_Post, ~ USA Dismounted Infantry (non-visible), Observation Post

BLUFOR Infantry UsaSoldier, - USA Dismounted Infantry (DI) Soldier (Generic/No Weapon)

BLUFOR Infantry Usa_Soldier_M16A2, -- USA DI Soldier with M16A2 Assault Rifle 5.56-mm Colt

BLUFOR Infantry Usa_Soldier_M60, -- USA DI Soldier with General Purpose M60 7.62- mm

BLUFOR Infantry Usa_Soldier_M203, - USA DI Soldier with M203 Grenade Launcher

BLUFOR Infantry Usa Soldier Dragon, — USA DI Soldier with Dragon missile, M47

BLUFOR Infantry UsaSoldierJavelin, ~ USA DI Soldier with Javelin AAWS-M

BLUFOR Infantry Usa_Soldier_At4, - USA DI Soldier with AT4

BLUFOR Infantry Usa Soldier M249, ~ USA DI Soldier with M249 Squad Automatic Weapon (SAW)

BLUFOR Infantry UsaSoldierStinger, ~ USA DI Soldier with Stinger, FIM-92

BLUFOR Infantry UsaSoldierClaymore,-- USA DI Soldier w/ Claymore Mine

BLUFOR FWA F16, - General Dynamics F-16 Fighting Falcon, Generic

BLUFOR FWA A10A, - Fairchild Republic A-10 Thunderbolt II, A-10A

BLUFOR RWA Ah64, — McDonnel-Douglas AH-64 Apache

BLUFOR RWA Ah IS, - Bell Model 209 Hueycobra, Seacobra, Supercobra, AH-IS

BLUFOR RWA Uh60A, - Sikorsky S-70A, UH-60A Blackhawk

BLUFOR RWA Ch47D, ~ Boeing Models 114/414, CH-47D

BLUFOR RWA Oh58D, ~ Bell Model 406 AHIP, OH-58D Kiowa/Kiowa Warrior

BLUFOR Logistics M998, ~ LTV HMMWV, M998 Cargo/Troop Carrier w/o winch

BLUFOR Logistics M966, - LTV HMMWV, M966 TOW Missle Carrier, Basic Armor, w/ winch

BLUFOR Logistics M1025, - LTV HMMWV, M1025 Armament Carrier, Basic Armor, w/o winch

BLUFOR Logistics Ml043, - HMMWV, Ml043 Armament Carrier, Supplemental Armor, w/o winch

BLUFOR Logistics Ml044, ~ HMMWV, Ml044 Armament Carrier, Supplemental Armor, w/ winch

B- 2



Side Type Entity

BLUFOR Logistics Teledyne_4X4, - Teledyne 4x4 725-kg light forces vehicle

BLUFOR Logistics M151, - M151 4x4 362-kg light vehicle and variants

BLUFOR Logistics M58A3_Without_Rocket, - M58/M59 Mine-clearing Charge (MICLIC) (towed), M58A3

BLUFOR Logistics M58A3_With_Rocket, --

BLUFOR Logistics M977, -- Oshkosh Heavy Expanded Mobility Tactical Truck (HEMTT), M977 Cargo

BLUFOR Logistics M977 Mine Rollers, ~ Oshkosh Heavy Expanded Mobility Tactical Truck (HEMTT), M977 Cargo

BLUFOR Logistics M977 Mine Plows, -- Oshkosh Heavy Expanded Mobility Tactical Truck (HEMTT), M977 Cargo

BLUFOR Logistics M978, - Oshkosh Heavy Expanded Mobility Tactical Truck (HEMTT), M978 Fuel-Servicing

BLUFOR Logistics M984E1, - Oshkosh Heavy Expanded Mobility Tactical Truck (HEMTT), M984A1 Wrecker

BLUFOR Logistics M985, - Oshkosh Heavy Expanded Mobility Tactical Truck (HEMTT), M985 Cargo

BLUFOR Logistics M985 Mine Rollers, - Oshkosh Heavy Expanded Mobility Tactical Truck (HEMTT), M985 Cargo

BLUFOR Logistics M985 Mine Plows, ~ Oshkosh Heavy Expanded Mobility Tactical Truck (HEMTT), M985 Cargo

BLUFOR Logistics Ml078, - Ml078 Truck, Cargo; LMTV w/ Equipment

BLUFOR Logistics Ml079, - Ml079 Truck , Van; LMTV w/ Equipment

BLUFOR Logistics Ml083, -- Ml083 Truck Cargo; MTV w/ Equipment

BLUFOR Logistics M1083_Volcano, -- Ml083 Truck, Cargo; MTV w/ Equipment; w/ Vocano

BLUFOR Logistics M1089_Winch, ~ Ml089 Truck, Wrecker; MTV, w/ Equipment, w/ Winch

BLUFOR Logistics Ml091 Winch, - Ml091 Truck, Tanker; MTV w/ Equipment, w/ Winch

BLUFOR Logistics M992, -- M992 Field Artillery Ammunition Support Vehicle (FAASV)

BLUFOR Logistics PrestockAmmo, — Prestock Entity (Ammo)

BLUFOR Logistics PrestockFuel, — Prestock Entity (Fuel)

OPFOR Tank T80, - T-80 MBT, T-80

OPFOR Tank T80_With_Mine_Plow_Roller,~

OPFOR Tank T80Uv, - T-80 MBT, T-80UV

B- 3



Side Type Entity

OPFOR Tank T80Uv_With_Mine_Plow_Roller, -

OPFOR Tank T72, -T-72 MBT

OPFOR Tank T72_With_Mine_Plow_Roller, -

OPFOR Tank T72Bv, -T-72BV

OPFOR Tank T72Bv_With_Mine_Plow_Roller, -

OPFOR Tank T64Bv, -- T-64 MBT, T-64BV

OPFOR Tank T64Bv_With_Mine_Plow_Roller,»

OPFOR Tank T62, -- T-62 MBT, T-62

OPFOR Tank T62_With_Mine_Plow_Roller,-

OPFOR Mech BmplP, - BMP-IF w/ AT-4 ATGW

OPFOR Mech BmplKshm, - BMP-lKShM Unarmed Command

OPFOR Mech Bmp2, - BMP-2, BMP-2

OPFOR Mech Bmp3, - BMP-3

OPFOR Mech Brdm2, — BRDM-2 Reconnaissance Vehicle

OPFOR Mech Brdm2 At5 Atgm, - BRDM-2 Reconnaissance Vehicle,BRDM-2 w/ AT-5 ATGM

OPFOR Mech Mtlb_l VI2, - MT-LB Tracked Vehicle, MT-LB 1V12

OPFOR Mech Btr60P, - BTR-60, BTR-60P

OPFOR Mech Btr80, - BTR-80, BTR-80

OPFOR Artillery Spa_2S3, - M-1973 152-mm gun (2S3)(SO-152)

OPFOR Artillery Spa_2Sl, - M-1974 122-mm Howitzer (2S1)(S0-122)

OPFOR Artillery Zsu23_4, ~ ZSU-23/4 Quad 23-mm AAA

OPFOR Artillery Sal3Sam,-SA-13SAM

OPFOR Artillery Spa_2S6, - 2S6 Quad 30-mm/SA-19 AD System

OPFOR Artillery Sal5Sam,--SA-15SAM

OPFOR Artillery Spa_2S19, - 152-mm 2S19 (aka MSTA-S)

OPFOR Artillery Spa_2S23, - 120-mm Howitzer/mortar (2S23)

OPFOR Artillery Spa_2S31, - BMP Chassis w/120-mm Combination Gun (2S31)

OPFOR Artillery D30, - D-30 122-mm Gun-Howitzer

OPFOR Artillery Mtl2, - T-12/MT-12 100-mm Antitank Gun

OPFOR Infantry Cis_Soldier, ~ CIS Dismounted Infantry (DI) Soldier (Generic/No Weapon)

B- 4



Side Type Entity

OPFOR Infantry Cis Soldier_Ak74, -- CIS DI Soldier w/ Assault Rifle AK-74 and AKS-74, 5.45-mm

OPFOR Infantry Cis_Soldier_Rpg7V, - CIS DI Soldier w/ VAT Rocket Launcher RPG-7

OPFOR Infantry Cis_Soldier_Rpk74, - CIS DI Soldier w/ Light RPK-74 5.45mm

OPFOR Infantry Cis Soldier_Agsl7, - CIS DI Soldier w/ Plamya Launcher, 30-mm AGS-17

OPFOR Infantry Cis_Soldier_Sal6,-- CIS DI Soldier w/ Gimlet SA-16

OPFOR Infantry Cis_Soldier_At7, -- CIS DI Soldier w/ Saxhorn AT-7

OPFOR Infantry Cis_Soldier_At4, -- CIS DI Soldier w/ AT-4

OPFOR Infantry Cis_Soldier_Sal8,~ CIS DI Soldier w/ SA-18

OPFOR FWA Mig27, - MiG-27 Flogger (Generic)

OPFOR FWA Sul7, - SU-17 Fitter (Generic)

OPFOR FWA Su24, - SU-24 Fencer (Generic)

OPFOR FWA Su25, - SU-25 Frogfoot (Generic)

OPFOR RWA Mi28, - Mi-28 Havoc, Mi-28

OPFOR RWA Mi24P, - Mi-24/25/35 Hind, Mi-24P Hind F

OPFOR RWA Ka50A, - Ka-50 Hokum A Close Air Support

OPFOR RWA Mi8Tbk, - Mi-8/9/17/171 Hip, Mi-8TBK (Mi-17)("E" Uprated)

OPFOR Logistics Bat2, - BAT-2 Combat Engineer Vehicle

OPFOR Logistics Breml, - BREM-1 Recovery and Repair Vehicle

OPFOR Logistics Kmt5M, - KMT-5M Roller/Plow

OPFOR Logistics Uaz469B, -- UAZ-469B 4x4 600-kg Light Vehicle

OPFOR Logistics Gaz66, - GAZ-66 4x4 2000-kg Truck

OPFOR Logistics Kraz255B, - KrAZ-255B 6x6 7500-kg Truck (Generic)

OPFOR Logistics Kraz255B_Fuel, - KrAZ-255B 6x6 7500-kg Truck, Fuel Service

OPFOR Logistics GmzTml, — GMZ Tracked Mine Layer

OTHER Tank Chieftain, - Chieftain MBT

OTHER Tank Challenger, — Challenger MBT

OTHER Tank Amx30, -- AMX-30

OTHER Tank Amx40, - AMX-40 MBT

OTHER Tank LeolA4, - Leopard 1 A5 MBT, A4

B- 5



Side Type Entity

OTHER Tank Leo2, -- Leopard 2 MBT

OTHER Mech Warrior, - FV 510 Warrior

OTHER Mech AmxlORc, - AMX-10RC Armored Car

OTHER Mech Amxl0,~AMX-10IFV

OTHER Mech Marder2, — Marder 2

B- 6

Appendix B - SAF Entities Mod SAF Entities


B.2 ModSAF Entities

This following table lists the complete set of entities that are implemented for ModSAF version 4.0 Beta. For each entity, the table defines the country and the domain (ground or air).

Vehicle Country Domain

vehicle_US_IMF_Gateway US GROUND

vehicle_US_IMF_AOS US GROUND

vehicle_US_IMF_WAM US GROUND

vehicle_US_LAH_SADARM US GROUND

vehicleUSPGMMortar US GROUND

vehicle_US_VIRT_REMOTE_SENTRY US GROUND

vehicle_US_HunterVPS US GROUND

vehicle_US_RC2T US GROUND

vehicleUSMPLLauncher US GROUND

vehicIe_US_TOW_Launcher US GROUND

vehicleUSAGS US GROUND

HfeForm_US_DI_FOFAC US GROUND

vehicleUSOutrider US GROUND

vehicle_US_NLOS US GROUND

vehicle_US_Ml_CPS us GROUND

vehicle_US_GRIZZLY us GROUND

vehicle_US_VMMD us GROUND

vehicle_US_LOSAT us GROUND

vehicleUSStingray us GROUND

vehicle_US_Crusader_SPH us GROUND

vehicleUSCrusaderRSV us GROUND

vehicle_US_Crusader_M577A 1 us GROUND

vehicle_US_Crusader_M977 us GROUND

vehicle_US_XM8 us GROUND

vehicle_US_ASTAMIDS us AIR

B- 7




vehicleGermanyJAGUARl FRG GROUND

vehicleGermanyJaguarObs FRG GROUND

vehicleGermanyLEO 1A5 FRG GROUND

vehicle_Germany_LE02 FRG GROUND

vehicle_Germany_LUCHS FRG GROUND

vehicIeGermanyMARDER FRG GROUND

vehicle_Germany_Ml 13_Skorpion FRG GROUND

vehicle_Germany_Ml 13_ambulance FRG GROUND

vehicle_Germany_Ml 13_observer FRG GROUND

vehicle_UK_GR7_AIRSAF UK AIR

vehicle_USMC_AAV US GROUND

vehicle_USMC_AAV_C7 US GROUND

vehicle_USMC_AAV_REC US GROUND

vehicle_USMC_AAV_MINE US GROUND

vehicleUSAvenger US GROUND

vehicle_US_HMMWV US GROUND

vehicle_US_HMMWV_FDC US GROUND

vehicle_US_HMMWV_CCSIL_FO US GROUND

vehicle_US_HMMWV_AMBUL US GROUND

vehicleUSHETTrailer US GROUND

vehicle_US_M127 US GROUND

vehicle_US_M353_MICLIC US GROUND

vehicle_US_M 1073_ESMB US GROUND

vehicle_US_GBSFAAD US GROUND

vehicle_US_Ml US GROUND

vehicle_US_MlAl US GROUND

vehicle_US_MlA2 US GROUND

vehicle_US_AVLB US GROUND

vehicleUSHAB US GROUND

vehicle_US_AVLM US GROUND


B- 8




vehicle_US_CEV US GROUND

vehicle_US_ACE US GROUND



vehicle_US_M3A3 US GROUND

vehicle_US_M93_Fox US GROUND

vehicle_US_M2_Stinger US GROUND



vehicle_US_M106Al US GROUND









vehicle_US_Ml 13_ambulance US GROUND

vehicleUSMl 13_engineer US GROUND




vehicle_US_M270_GAT2 US GROUND

vehicIe_US_M270_M26 US GROUND

vehicle_US_M270_M77 US GROUND

vehicle_US_M270_ATACMS US GROUND


vehicle_US_M577Al_FDC US GROUND

vehicle_US_M577Al_CCSIL_FDC US GROUND

vehicle_US_M577Al_FSO US GROUND

B- 9

Appendix B - SAF Entities ADST-II-CDRL-ONESAF-9800101 Mod SAF Entities MAY 8, 1998











unit_US_M978_M979_FARRP US GROUND

vehicle_US_M35A2_FDC US GROUND

vehicle_US_FAC_WHEELED US GROUND

vehicle_US_FWA_RECON US AIR

vehicleJUSAlO US AIR

vehicle_US_F14D US AIR

vehicle_US_F14B_D_AIRSAF US AIR

vehicle_US_F16C US AIR

vehicle_US_F 16C_AIRSAF US AIR

vehicle_US_A 10A_AIRSAF US AIR

vehicle_US_F 15C_AIRSAF US AIR

vehicle_US_F 15E_AIRSAF US AIR

vehicle_US_Fl 17_AIRSAF US AIR

vehicle_US_U2R_AIRSAF US AIR

vehicle_US_KC 10_AIRSAF US AIR

vehicle_US_KC 135_AIRSAF US AIR

vehicle_US_AC 130U_H_AIRSAF US AIR

vehicle_US_MC 130E_H_AIRSAF US AIR

vehicle_US_MC 130N_P_AIRSAF US AIR

vehicle_US_E3A_AIRSAF US AIR

vehicle_US_E8A_AIRSAF US AIR

vehicle_US_RC 135_AIRSAF US AIR

B- 10




vehicle_US_EC 130E_AIRSAF US AIR

vehicle_US_Predator_AIRSAF US AIR

vehicle_US_EA6B_AIRSAF US AIR

vehicle_US_S3B_AIRSAF US AIR

vehicle_US_ES3A_AIRSAF US AIR

vehicle_US_E2C_AIRSAF US AIR

vehicle_US_P3C_AIRSAF US AIR

vehicle_US_AV8B_AIRSAF US AIR

vehicleUSJCC 130_AIRSAF US AIR

vehicle_US_F16D US AIR

vehicleJJSJFA 18C_AIRSAF US AIR

vehicle_US_FA 18D_AIRSAF US AIR

vehicle_US_RAH66 US AIR

vehicle_US_AH64 US AIR

vehicle_US_AH64J US AIR

vehicle_US_AH64D US AIR

vehicle_US_CH47D US AIR

vehicle_US_RAH66_LONGBOW US AIR

vehicle_US_OH58D US AIR

vehicle_US_UH60 US AIR

vehicle_USSR_BM21 USSR GROUND

vehicle_USSR_BMPl USSR GROUND

vehicle_USSR_BMP2 USSR GROUND

vehicleJJSSR_BRDM2 USSR GROUND

vehicle_USSR_BTR60PU USSR GROUND

vehicle_USSR_BTR80 USSR GROUND

vehicle_USSR_SA_9 USSR GROUND

vehicle_USSR_SA_15 USSR GROUND

vehicle_USSR_T62 USSR GROUND

vehicle_USSR_T72M USSR GROUND

vehicle_USSR_T80 USSR GROUND

B- 11




vehicle_USSR_URAL375C USSR GROUND

vehicle_USSR_URAL375F USSR GROUND

vehicle_USSR_ZIL131_FDC USSR GROUND

vehicle_USSR_ZSU23_4M USSR GROUND

vehicle_USSR_lV13 USSR GROUND



vehicleJUSSRJV16 USSR GROUND

vehicle_USSR_2Bll USSR GROUND

vehicle_USSR_2S12 USSR GROUND

vehicle_USSR_2Sl USSR GROUND



vehicle_USSR_XM375S USSR GROUND

vehicle_USSR_XMGlS USSR GROUND

vehicle_USSR_SA_6_FCR USSR GROUND

vehicle_USSR_SA_6_TEL USSR GROUND

vehicle_USSR_XMLTS USSR GROUND

vehicle_USSR_XMTSS USSR GROUND

vehicle_SWA_MAZ543 USSR GROUND

vehicle_USSR_FWA_RECON USSR AIR

vehicle_USSR_MIG23_AIRSAF USSR AIR

vehicle_USSR_MIG27 USSR AIR

vehicle_USSR_MIG27D USSR AIR

vehicle_USSR_MIG29 USSR AIR

vehicle_USSR_MIG29_AIRSAF USSR AIR

vehicle_USSR_Su 17_AIRSAF USSR AIR

vehicle_USSR_Su25 USSR AIR

vehicle_USSR_Su25_AIRSAF USSR AIR

vehicle_USSR_Su27_AIRSAF USSR AIR

vehicle_USSR_Fl_AIRSAF USSR AIR

B- 12




vehicle_USSR_Mi8 USSR AIR



vehicle_USSR_Ka50 USSR AIR

structure_AMMO_PALLET_GERMAN_AT2 FRG GROUND

structure_AMMO_PALLET_GERMAN_120HEAT FRG GROUND

structure_AMMO_PALLET_GERMAN_120SABOT FRG GROUND

structure_AMMO_PALLET_GERMAN_DM63 FRG GROUND

structure_AMMO_PALLET_GERMAN_DM81 FRG GROUND

structure_AMMO_PALLET_GERMAN_HOT FRG GROUND

structure_AMMO_PALLET_GERMAN_MILAN FRG GROUND

structure_AMMO_PALLET_GERMAN_PANZERFAUST FRG GROUND

structure_AMMO_PALLET_US_l 55_SADARM US GROUND

structure_AMMO_PALLET_US_DRAGON US GROUND

structure_AMMO_PALLET_US_HELLFIRE US GROUND

structure_AMMO_PALLET_US_HELLFIRE_RF US GROUND

structure_AMMO_PALLET_US_HYDRA70M 151 US GROUND

structure_AMMO_PALLET_US_HYDRA70M261 US GROUND

structure_AMMO_PALLET_USJA VELIN US GROUND

structure_AMMO_PALLET_US_L8A 1 US GROUND

structure_AMMO_PALLET_US_LOSAT_Missile US GROUND

structure_AMMO_PALLET_US_M 1 us GROUND

structure_AMMO_PALLET_US_M 107 us GROUND

structure_AMMO_PALLET_US_Ml 10E2 us GROUND

structure_AMMO_PALLET_US_Ml 16A1 us GROUND

structure_AMMO_PALLET_US_M 121A1 us GROUND

structure_AMMO_PALLET_US_Ml 35 us GROUND

structure_AMMO_PALLET_US_M240 us GROUND

structure_AMMO_PALLET_US_M329A 1 us GROUND

structure_AMMO_PALLET_US_M329A2 us GROUND

structure_AMMO_PALLET_US_M33 us GROUND

B- 13




structure_AMMO_PALLET_US_M392A2 US GROUND

structure_AMMO_PALLET_US_M449A 1 US GROUND

structure_AMMO_PALLET_US_M456 A1 US GROUND



structure_AMMO_PALLET_US_M548 US GROUND


structure_AMMO_PALLET_US_M58_chargelet US GROUND


structureJ^MMO_PALLET_US_M687 US GROUND







structure_AMMO_PALLET_US_M77_M26 US GROUND















B- 14




structure_AMMO_PALLET_US_M933_934 US GROUND


structure_AMMO_PALLET_US_MK22 US GROUND

structure_AMMO_PALLET_US_MLRS_MSTAR US GROUND

structure_AMMO_PALLET_US_MLRS_SAD US GROUND

structure_AMMOJPALLET_US_MLRS_SAD_ER US GROUND

structure_AMMO_PALLET_US_MX943 US GROUND

structure_AMMO_PALLET_US_NLOS US GROUND

structure_AMMO_PALLET_US_PGMM US GROUND

structure_AMMO_PALLETUS_STINGER US GROUND

structure_AMMO_PALLET_US_TOW US GROUND

structure_AMMOJ>ALLET_US_XM867 US GROUND

structure_AMMO_PALLET_US_XM898 US GROUND




structure_AMMO_PALLET_US_XR_M77 US GROUND

structure_MINE_PALLET_munition_US_BLU91B US GROUND

structure_MINE_PALLET_munition_US_BLU92B US GROUND

structure_MINE_PALLET_munition_US_HORNET US GROUND

structure_MINE_PALLET_munition_US_M 14 US GROUND

strucrure_MINE_PALLET_munition_US_M 15 US GROUND

structure_MINE_PALLET_munition_US_M 16 A2 US GROUND

structureJtfINE_PALLET_munition_US_M 18 A1 US GROUND

structureMINEPALLETmunitionUSM 19 US GROUND

structure_MINE_PALLET_munition_US_M21 US GROUND




structure_MINE_PALLET_munition_US_M73_mine US GROUND


B- 15







structure_MrNE_PALLET_munition_US_SLAM US GROUND

structure_MINE_PALLET_munition_US_VOLCANO_AP US GROUND

structure jVlINEJ?ALLET_munition_US_VOLCANO_AT US GROUND

structure J4INE_PALLET_MECH_Volcano US GROUND

structure_MINE_PALLET_MOPMS US GROUND

structure_AMMO_PALLET_USSR_120MM_MCS_E USSR GROUND

structure_AMMO_PALLET_USSR_125HE_Frag USSR GROUND

structure_AMMOJPALLET_USSR_125HEAT USSR GROUND

structure_AMMO_PALLET_USSR_125SABOT USSR GROUND

structure_AMMO_PALLET_USSR_127AA USSR GROUND

structure_AMMO_PALLET_USSR_127MG USSR GROUND

structure_AMMO_PALLET_USSR_145MG USSR GROUND

structure_AMMO_PALLET_USSR_23AP USSR GROUND

structure_AMMO_PALLET_USSR_3023_DPICM USSR GROUND

structure_AMMO_PALLET_USSR_30HE USSR GROUND

strucrure_AMMOJPALLET_USSR_30HE_2S6 USSR GROUND

structure_AMMO_PALLET_USSR_30HE_BMP2 USSR GROUND

structure_AMMO_PALLET_USSR_30HE_Ka50 USSR GROUND

structure_AMMO_PALLET_USSR_30SABOT_BMP2 USSR GROUND

structure_AMMO_PALLET_USSR_30SABOT_Ka50 USSR GROUND

structure_AMMO_PALLET_USSR_73HEAT USSR GROUND

structure_AMMO_PALLET_USSR_9K25 USSR GROUND

structure_AMMO_PALLET_USSR_ATP_H2 USSR GROUND

structure_AMMO_PALLET_USSR_BK_M_HEAT_FS USSR GROUND

structure_AMMO_PALLET_USSR_D USSR GROUND

structure_AMMO_PALLET_USSR_D_462 USSR GROUND

structure_AMMO_PALLET_USSR_D_540 USSR GROUND

structure_AMMO_PALLET_USSR_ER540 USSR GROUND

B- 16



Vehicle

structure_AMMO_PALLET_USSR_GASKIN

structure_AMMO_PALLET_USSR_GAUNTLET

structure_AMMO_PALLET_USSR_HR843A

structure_AMMO_PALLET_USSR_MASD_DPICM

structure_AMMO_PALLET_USSR_MCS_SMART

structure_AMMO_PALLET_USSR_MMB_120_SMART

structure_AMMO_PALLET_USSR_M_21_OF

structure_AMMO_PALLET_USSR_OF843B

structure_AMMO_PALLET_USSR_OF_45




structure_AMMO_PALLET_USSR_PS

structure_AMMO_PALLET_USSR_ROCKET_64

structure_AMMO_PALLET_USSR_SAGGER

structure_AMMO_PALLETJJSSR_SA_16

structure_AMMO_PALLET_USSR_SA_l 9

structure_AMMOJPALLET_USSR_SONGSTER

structure_AMMO_PALLET_USSR_SPANDREL

structure_AMMO_PALLET_USSR_SPIGOT

structure_AMMO_PALLET_USSR_SPIRAL

structure_AMMO_PALLET_USSR_UV32_57

structure_AMMO_PALLET_USSR_VOG_l 7M

structure_MINE_PALLET_munition_USSR_MON 100

structure_MINE_PALLET_munition_USSR_MON200

structure_MINE_PALLET_munition_USSR_MON50

structure_MINE_PALLET_munition_USSR_OZM3

structureJMrNE_PALLET_munition_USSR_PGMDM

structure_MINE_PALLET_munition_USSR_PMK40

structure_MINE_PALLET_munition_USSR_PMN

structure MINE PALLET munition USSR POMZ2

Country Domain

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

USSR GROUND

B- 17




structure_MINE_PALLET_munition_USSR_PTMIK USSR GROUND

structureJVnNEJ>ALLETjnunition_USSR_TM46 USSR GROUND

structure_MINE_PALLET_munition_USSR_TM57 USSR GROUND

structure_MINE_PALLET_munition_USSR_TM62 USSR GROUND

structure_MINE_PALLET_munitionJUSSR_TMD_B USSR GROUND

structure_MINE_PALLET_munition_USSR_TMK2 USSR GROUND

structure_MINE_PALLET_munition_USSR_TMN46 USSR GROUND

structure_MINE_PALLET_munition_USSR_TMRP6 USSR GROUND

structure_MINE_PALLET_munition_USSR_YAM5 USSR GROUND

structureAMMOPALLET GROUND

structureMINEPALLETmunitionYUGOJU GROUND

structure_MINE_PALLET_munition_YUGO_TMRP6 GROUND

structure_MINE_PALLET_munition_EGYPT_M80 GROUND

structure_MINE_PALLET_munition_ITALY_SB81 GROUND

structureMINEPALLETmunitionJTALYSBMV GROUND

structure_MINE_PALLET_munition_ITALY_SH55 GROUND

structure_MINE_PALLET_munition_ITALY_TC24 GROUND

structure_MINE_PALLETjmunition_ITALY_TC6 GROUND

structure_MINE_PALLET_munition_ITALY_TCE6 GROUND

structure_MINE_PALLET_munition_ITALY_VS 16 GROUND

structureMINEPALLETmunitionJTALYVSHCT GROUND

structure_MINE_PALLET_munition_OTHER_MIACAH GROUND

structure_MINE_PALLET_munition_OTHER_P2MK3 GROUND

structureMINEPALLETmunitionOTHERPTMIBAIII GROUND

structureMINEPALLETmunitionUKL 14 A1 GROUND

structure_MINE_PALLET_munition_UK_MK7 GROUND

structure_RPARTS_PALLET GROUND

structure_CONST_MATL_PALLET GROUND

B- 18

Appendix C - Migration Assessments ADST-II-CDRL-ONESAF-9800101 Behaviors Assessment Option 1 MAY 8, 1998

Appendix C - Migration Assessments

This appendix contains the detailed migration approach assessments for integrating from the CCTT SAF baseline or the ModSAF baseline into a OneSAF Testbed baseline. This appendix provides the behaviors, system, synthetic natural environment, physical models and user computer interface assessments.

C.l Behaviors Assessment

The behavior assessment considered six migration options listed as follows:

• Option 1: Re-implement missing behaviors from ModSAF into existing CCTT infrastructure (no modification to the infrastructure)

• Option 2: Re-implement missing behaviors from CCTT SAF into existing ModSAF infrastructure (no modification to the infrastructure)

• Option 3: Develop new unified behavior representation and implement all behaviors in it

• Option 4: Extend ModSAF with additional infrastructure to ease re-implementation of CCTT behaviors within ModSAF

• Option 5: Extend CCTT SAF with additional infrastructure to ease re-implementation of ModSAF behaviors within CCTT SAF

• Option 6: Develop capability to run both ModSAF and CCTT SAF behaviors within the OneSAF testbed

Behavior Assessment: Option 1 (Re-Implement ModSAF Behaviors in CCTT SAF)

Technical Description

Start with CCTT SAF as the baseline and migrate approximately 106 ModSAF behaviors, 240 ModSAF units, and ModSAF platforms into CCTT SAF. CCTT SAF will only be modified as necessary to support the incorporation of the additional ModSAF behaviors, units, and platforms. It will not be modified to incorporate any other ModSAF functionality or features. The following list provides a more detailed look at the approach for this option.

• Maintain the existing CCTT SAF Behavioral Architecture

• Maintain the existing set of 276 CCTT SAF behaviors

• Add each additional ModSAF unit as a distinct unit class (where a unit class is currently represented as an individual Ada package)

• Add each additional ModSAF behavior as a common FSM (where common FSMs are currently collected in separate Ada packages that can be accessed by all units)

• Where possible, generalize existing CCTT SAF behaviors to provide ModSAF functionality


• Extend the existing CCTT SAF GUI to support the additional ModSAF units and behaviors

• Extend the SEOD to support the orders and reports needed by the additional ModSAF units and behaviors

• Extend the CCTT SAF GMI to support the additional ModSAF platforms and platform capabilities

• Extend the CCTT SAF crew level behaviors to support both additional ModSAF unit- level behaviors and additional ModSAF platforms and platform capabilities

• Extend the Order Decomposition capability to support the additional ModSAF units and behaviors

• Re-engineer CCTT SAF behaviors and behaviors architecture into C

Advantages of using this Approach

The principal advantages of this approach are low cost and low technical risk. Although ModSAF has far more units and platforms than CCTT SAF, the cost of implementing either a unit or platform is substantially less than the cost of implementing a user-assignable behavior (in both systems). Since CCTT SAF has far more user-assignable behaviors than ModSAF, the cost of migrating behaviors, units, and platforms from ModSAF to CCTT SAF is actually less than the cost of migrating behaviors, units, and platforms from CCTT SAF to ModSAF. Also, although ModSAF behaviors are implemented in a subsumptive architecture, there is no reason to believe that those same behaviors can't be implemented in a cooperative architecture. This assertion is supported by the fact that there is overlap between the behaviors that have been implemented in CCTT SAF and ModSAF (e.g., both systems have platoon, company, and battalion behaviors, both systems have traveling, bounding overwatch, and traveling overwatch movement behaviors, etc.)

Disadvantages of using this Approach

The principal disadvantage to this approach is that it does not meet ModSAF's extensibility requirements. The resulting baseline will not have:

• Architectural integrity - in general, FSMs will be collected in libraries rather than being represented as distinct libraries

• Dynamic debugging - debugging information will only be available when the FSM developer builds in the appropriate debugging statements

• Run-time modifications to FSMs - only certain pre-defined run-time modifications to unit behaviors will be allowed (e.g., speed, spacing)

• User-configurable reactions - each unit's reactions will be implemented in a dispatch table

• Tools for generating FSMs - developers will continue to build FSMs by hand • Data-driven GUI - modifications to the GUI will have to be implemented in code • Status monitor - there will be no status monitor to provide details of executing behaviors

C- 2


Technical Feasibility

This approach has very little technical risk and is therefore technically feasible. The strategy for migrating ModSAF units, behaviors, and platforms to CCTT SAF will have to address the change in behaviors architecture (cooperative vs. subsumptive), and the change in data structures (public and private task data vs. SEOD data). However, once a conversion technique has been developed, that technique can be applied iteratively to the ModSAF units, behaviors, and platforms.

Requirements satisfaction

This approach satisfies all of CCTT SAF's requirements since it is CCTT SAF with an extended set of behaviors. This approach does not satisfy ModSAF's extensibility requirements, and the specific limitations are listed in under Disadvantages.

Performance

The performance requirements are met by this approach since it represents the CCTT baseline and CCTT currently has the most stringent requirements.

Schedule

This approach has very little schedule risk because the only long-lead item is the task to establish the technique for converting ModSAF units, behaviors, and platforms into CCTT SAF units, behaviors, and platforms. Once this task has been accomplished, developers simply apply this technique iteratively.

Reliability

This approach should result in a baseline that is at least as reliable as CCTT SAF.

Scalability

This approach should result in a baseline that is at least as scalable as CCTT SAF.

Behavior Requirements Satisfaction

Since this approach fully implements both CCTT SAF and ModSAF behaviors, the behavior requirements of both systems are fully satisfied.

Behavior V&V

Since this approach retains the CCTT SAF behaviors without modification, the only V&V effort should be associated with the conversion of CCTT SAF behaviors from Ada to C. This effort should be minimal when compared to the other approaches. Although the V&V agents may have to re-validate each behavior, there should be fewer defects resulting from a programming language conversion than from an architecture conversion.

C- 3

Appendix C - Migration Assessments Behaviors Assessment Option 1


Extensibility

This approach does not address extensibility. The specific limitations are listed under Disadvantages.

Baseline Maintenance

This approach does not adversely impact baseline maintenance beyond the existing problems associated with either ModSAF or CCTT SAF.

Adaptability to new Technology and Architectures

This approach will result in a OneSAF testbed that has the same capability as CCTT SAF to adapt to new technology and architectures.

Ease of coordination and integration of multiple developers

This approach will result in a OneSAF testbed that has the same capability as CCTT SAF to support the coordination and integration of multiple CCTT SAF developers. This approach will not support the coordination and integration of any ModSAF developers. ModSAF development and OneSAF testbed development would proceed along separate development paths.

Enumeration of capabilities to migrate

The Technical Description provides a list of capabilities that must be migrated and re-worked to support this approach.

Effort to migrate related to capabilities

ModSAF Behaviors Incorporation New Behaviors 106

Overlap 25% Per CIS effort (weeks) 7

Weeks effort 578 Months effort 144

ModSAF Units Incorporation New Units 240

Per CIS effort (weeks) 0.5 Weeks effort 120 Months effort 30

CCTT Behaviors Rework

C- 4



Behaviors Rework 86 Months effort 86

Total Months Effort 260

Assumptions on migration environment

The following list outlines the assumptions for this approach:

• The existing CCTT SAF behaviors will not have to be modified in any way (e.g., no impacts from GMI, SEOD, or vehicle behavior extensions)

• The existing CCTT SAF crew behaviors can be extended to support the additional ModSAF platforms and platform capabilities

• The CCTT SAF GUI will not need any new widgets to support ModSAF behaviors • There are no ModSAF behaviors which rely so thoroughly on a subsumptive architecture

that they can't be implemented in a cooperative architecture (where "can't" means "takes too much resources")

• The ModSAF behaviors can function within the information context of reports and orders • ModSAF background tasks can be implemented as built in behaviors of the Unit class or

specific doctrinal unit classes • ModSAF behaviors do not have to be validated

Assessment

The following table provides an assessment of this option for the specified criteria.

Criteria Low (1) Medium (5) High (10) Score Technical The technical The technical The technical 3 Feasibility risk feasibility is feasibility is feasibility is poor.

rated very good. good but the migration involves some very difficult technical issues.

The migration technical is very difficult or the approach has never been tried before.

Program Risk There is little There is a The migration 2 risk of the moderate risk of approach is very migration the migration risky and has never approach approach been attempted

before Impact to The approach The approach The approach has 7 existing has virtually no has some many impacts, the ModSAF user impacts to the impacts to the effort involved in community existing existing overcoming the

programs or programs that impacts are very community could be over large, or technically

C- 5



come with challenging moderate effort

Impact to The approach The approach The approach has 7 existing has virtually no has some many impacts, the ModSAF impacts to the impacts to the effort involved in development existing existing overcoming the community programs or programs that impacts are very (e.g., STOW) community could be over

come with moderate effort

large, or technically challenging

Impact to The approach The approach The approach has 1 existing CCTT has virtually no has some many impacts, the program impacts to the impacts to the effort involved in

existing existing overcoming the programs or programs that impacts are very community could be over



Impact to The approach The approach The approach has 1 current CCTT has virtually no has some many impacts, the development impacts to the impacts to the effort involved in (e.g., FBCB2) existing existing overcoming the

programs or programs that impacts are very community could be over



Adaptability to The resulting The resulting The resulting 10 new technology infrastructure or infrastructure infrastructure is not risk environment does not unified and should

can be easily support be completely extended extension and

will require additional enhancements to support future modification

redesigned to support extensibility

Relative Cost 260 mm

Criteria Assessment Justification

The following sections provide the rationale for the assigned scores.


C- 6

Appendix C - Migration Assessments ADST-II-CDRL-ONESAF-9800101 Behaviors Assessment Option 1 MAY 8,1998

The score of 3 was assigned to this criterion since the migration of behaviors from ModSAF to CCTT SAF should be straightforward. However, there may be some issues related to representation of subsumptive approaches in a cooperative system.

Program Risk

The score of 2 was assigned to this criterion since there is very little program risk. Once the initial technical issues associated with converting ModSAF units, behaviors, and platforms into CCTT SAF units, behaviors, and platforms have been resolved, the conversion process should be easy to measure and track.

Existing Program Impact

The score of'7' was assigned to the ModSAF impacts since this will have a substantial impact on all ModSAF based programs. In short, ModSAF developers would have to learn how to develop behaviors for CCTT SAF. The impacts to CCTT SAF current and future efforts are scored as '1' since the base system is CCTT SAF.

Adaptability to new technology

The score of 10 was assigned to this criteria since the resulting infrastructure will not support ModSAF's extensibility requirement.

Cost

Refer to the effort to migrate section.

C- 7


Behavior Assessment: Option 2 (Re-Implement CCTT Behaviors in

ModSAF)


ModSAF will be used as the baseline. Take the existing CCTT CISs and re-implement any missing functionality in them as ModSAF behaviors. Not all CISs would require new ModSAF behaviors because there is expected overlap (these are common behaviors). No architectural changes will be made to support the new CCTT SAF behaviors.

Models and/or vehicles in CCTT SAF that are not in ModSAF will have to be implemented as well.

Advantages of using this approach

• ModSAF behaviors are already done. • Use ModSAF behaviors as base for CIS migrated behaviors. • Upgrade of ModSAF building blocks to support CCTT behaviors may improve the

quality of some ModSAF behaviors. • Using a ModSAF base will ease re-baselining with new ModSAF technologies.

• Efficiency improvements • Behavior improvements (RWA, new Chem/Bio for STOW, Countermine (JCOS))

• No Ada (easier, cheaper, and faster development environment without Ada) • Takes advantage of the extensibility of ModSAF and it remains extensible. • Maintains composable characteristics of ModSAF.

Disadvantages of using this approach

• Total number of CCTT SAF behaviors x time to implement = large cost • Re-implementation of existing VV&Aed CCTT SAF behaviors. • Makes it difficult to keep up with CCTT enhancements. • Must V&V all new and common behaviors again. • Modification of building blocks increases the risk of breaking existing ModSAF

capabilities. • Do not have full compliance with all CCTT requirements.

• Order decomp vs. ModSAF dynamic decomposition • Check point (no approach identified)


Done lots of behaviors, so technically not challenging, but there will be lots of unsatisfied capabilities.

There will be risk in getting everything done in time (by "brute force").

C- 8


Program Risk


ModSAF requirements satisfied (by default) CCTT deficient according to list, below

FSM Language As-ls

Order Decomp not done Distributed Units not done Checkpointing not done Orders (in general) not done Logging of orders not done

Inefficiencies No timing mechanisms Difficult to handle subordinate management

Difficult to handle leader dying Difficult to handle taskorg changes.

Performance

It is unknown whether the ModSAF architecture satisfies the performance requirements needed by CCTT. There is no way to currently evaluate this.

Schedule

Estimate 425 mm. Plus, add V&V.

Reliability

As with all approaches outlined, there are echelon scalability limitations to using an FSM approach for behaviors. This approach does not make the problem worse.

Scalability

If interpreted as echelon, all current bottoms-up architecture approaches have echelon-scaling limitations.



See above.

C- 9



Behavior V&V

All re-implemented CISs (and their building blocks) would have to be V&Ved. We would recommend doing the V&V as was done originally for CCTT. Regression testing would have limited utility because the tests would be against a different baseline. There would need to be some interpretation of the results, and you could not take advantage of previous testing results.

Extensibility

No ModSAF extensibility lost. CCTT behaviors now extensible in the same style that ModSAF is.


There will be low maintenance because there will generally be only one implementation of each behavior. In some hopefully rare cases, there may be a CCTT version and a ModSAF version of the same behavior. Hopefully that is near zero.


New technology implemented in ModSAF derivatives such as Joint SAF will have a straightforward migration path to this unified architecture. New technology implemented in CCTT SAF (such as FBCB2) will require re-implementation in OneSAF.

Development Adaptability Assessment

Ongoing ModSAF development Good Ongoing CCTT SAF development Poor (re-implementation) Existing and ongoing STOW enhancements

Good

Joint SAF Good CFOR Good CCSIL Good Command Talk Good

OneSAF R&D Unknown


The OneSAF testbed can leverage off of the existing ModSAF and Joint SAF approaches for parallel distributed development.


• No new architecture.

• Implementation of CCTT-Training mode vs. unconstrained mode.

C- 10



Re-implementation of all CCTT CISs that are not common. Upgrade to building blocks. Includes:

• Movement • Shooting


This is a development activity.

Building Block Estimate (Man- Enhancements Months) Misc. 12 Movement 18 Shooting 6 Total 36

CISs CIS-CIS Per-CIS Effort Overlap Weeks

CIS Man- CIS Man- Weeks Months

346 75% 6.0 1557.5 389.25

CIS Development Architecture Bulding Block Man-Months Enhancements Man- Additions Man-

Months Months

Total Man- Months

324.38 0 36 425.25


• Expect to be able to reuse some existing ModSAF behaviors with CCTT SAF behavior re-implementation.

• Reuse as many physical models as possible.

Assessment

The following table provides the scores for the specified criteria.

Criteria Low (1) Medium (5) High (10) Score Technical The technical The technical The technical 1 Feasibility Risk feasibility is feasibility is feasibility is poor.



C- 11















Impact to The approach The approach The approach has 7 current CCTT has virtually no has some many impacts, the development impacts to the impacts to the effort involved in (e.g.,FBCB2) existing existing overcoming the






will require additional


C- 12



enhancements to support future modification

Cost 425 mm

C- 13


Behavior Assessment: Option 3 (New Architecture)


This effort results in a new behavioral design that is not an extension to either architecture. This architecture would result in a new set of primitives, controlling capabilities, and behavioral representations. Using this approach, all behaviors would be re-represented.


The architecture is designed to satisfy all the requirements.

Disadvantages of using the approaches

♦ Cost would be expected to be higher ♦ There would be schedule risk due to the increased new development requirements ♦ V&V effort would be increased since the behavior suite is newly developed


The technical feasibility of this approach is very good. This approach assumes that the resulting design is specifically tailored to the existing set of requirements and encompasses known future usages. The resulting system should be an optimal solution set for this focus area.


It is expected that this approach would satisfy all requirements placed on OneSAF testbed since the design would be tailored to this combined set.

Performance

Performance requirements for CCTT SAF would be fully met by this architecture since this would be a driving requirement for new development.

Schedule

There would be considerable schedule risk since this is a new design effort. All SLOC estimates would have to be applied to a full up development phase

Assessment

This option represents the suggestion of the summer study that was the development of a new architectural approach. This is not feasible considering the risks of a new development and the incorporation of 350+ behaviors. For this reason, this option was discarded and no estimation was performed on the necessary tasks.

C- 14


Behavior Assessment: Option 4 (Extend ModSAF with additional infrastructure to ease re-implementation of CCTT behaviors within

ModSAF)


This approach starts with ModSAF as the initial baseline. We will improve the behavioral architecture to facilitate the re-implementation of the CCTT SAF behaviors based upon existing CIS documents. There will be minimal or no changes to the current ModSAF behaviors, yet all of the CCTT SAF behaviors will be re-implemented within the ModSAF behavior architecture (with the appropriate extensions). The benefit of this option over 2 (implementing all CCTT CISs within the unmodified ModSAF architecture) is to make the re-implementation of the CCTT behaviors easier and cheaper.

FSM Enhancements

Additional FSM Abstraction Support

There are a number of capabilities that can be improved in the FSM language through the use of additional abstraction. These include management of subordinates (attrition, leader changes, TO changes), timing management, defaulting of events, storage management for created objects, and testing support for FSMs.

Designs for these modifications have been circulating between different members of the ModSAF development community for some time.

Event Based Task Transitions

The largest problem with supporting distributed units in ModSAF is the race condition where a task was monitoring the state of another behavior on a different machine. The problem is that if two state changes occur very quickly, and you miss the first state change due to dropping a PO packet, you will never get notified about the original change (which may be required in the FSM logic).

If we made the ending of the task an event (it already is an object-changed event) and we registered for that event, we would no longer need to poll for events. This will improve efficiency of tasks. Since we are almost always checking for the end of a task (except in the case of movement with utraveling and vmove), the state will not be changing after it goes to the end state, there is no problem of missing an intermediate change. Since we have already agreed that we need to re-visit movement in the upgrade building blocks section, this utraveling/vmove coupling will be on the list of things to address.

Potential to add additional CCTT-specific FSM abstractions

The best abstraction would allow us to adapt CCTT's implementation of behaviors or CISs directly into the abstracted approach.

C- 15


IST did a paper on converting CISs to ModSAF code, but they used a brute-force approach. This will provide little of use in supporting an improved FSM abstraction.

It is unclear that you can reduce behavior development arbitrarily. Perhaps no new abstractions would speed up the 5.0-week effort per CIS behavior that we assume with FSM language cleanup.

The CCTT FSMs rely on the CCTT behavior architecture, which is substantially different from the ModSAF behavior architecture. It is difficult to imagine an abstraction that could smooth all the differences between these architectures.

We may be limited to relying on behavior developers discovering opportunities for more abstractions during initial CIS development.

The ModSAF behavior assessment team believes that there is no feasibility in developing a new FSM language to support CCTT-specific abstraction.

Checkpointing

To support CCTT checkpointing requirements, ModSAF will develop a capability to periodically save scenarios, and to restore scenarios with the same DIS and PO IDs. This approach is comparable to CCTT's existing checkpointing implementation.

Order Decomposition

ModSAF will develop an order decomposition technique similar to that supported by CCTT. The capability to support runtime-decomposed orders will be retained in a backward- compatible manner so as to not disrupt the existing ModSAF behaviors.

Providing an order decomposition approach in ModSAF will be important in order to:

• Support CCTT users' existing insight into the decomposition process • Support CCTT's existing upfront user editability of decomposed orders • Support CCTT's capability to save modified decomposed orders.


This approach has the same advantages as option 2:

• ModSAF behaviors are already done. • The approach uses ModSAF behaviors as base for CIS migrated behaviors. • The upgrade of ModSAF building blocks to support CCTT behaviors may improve

the quality of some ModSAF behaviors. • Using a ModSAF base will ease re-baselining with new ModSAF technologies.

• Efficiency improvements (STOW) • Behavior improvements (RWA, new Chem/Bio for STOW, Countermine (JCOS))

• No Ada • Takes advantage of the extensibility of ModSAF and it remains extensible. • Maintains composable characteristics of ModSAF.

C- 16

Appendix C - Migration Assessments ADST-H-CDRL-ONESAF-9800101 Behaviors Assessment Option 4 MAY 8, 1998

In addition, new benefits of this approach includes:

• It satisfies the CCTT SAF and ModSAF requirements. • It cleans up, extends, and unifies the current ModSAF behavior architecture. • It provides a more open architecture and is more extensible. • It is cost effective; It will be easier and cheaper to implement CIS behaviors within

the extended ModSAF architecture. • It implements potential runtime efficiency improvements.


The disadvantages of this approach are similar to option 2:

• Total number of CCTT SAF behaviors x time to implement = large cost • Re-implementation of existing VV&A'd CCTT SAF behaviors. • Makes it difficult to keep up with CCTT enhancements. • Must V&V all new and common behaviors again. • Modification of building blocks increases the risk of breaking existing ModSAF

capabilities.

In addition:

• The extension to the existing ModSAF behavioral architecture needs to be done up front before any behaviors can be re-implemented. This presents an up-front scheduling problem that is mitigated by reducing the total schedule.


The architectural enhancements have been outlined and there is little risk in the implementation of these enhancements. Since we will be using the same AAFSM language with extensions and we have already developed many behaviors in this architecture, the technical risk of this approach is minimal. The only enhancement to which we do not yet have a design is the approach for order decomposition, however this is low risk since order decomposition is only an implementation that supports a requirement, not a requirement itself.

Program Risk


The ModSAF and CCTT SAF requirements will be satisfied.

Performance

As in option 2, it is unknown whether the ModSAF architecture satisfies the performance requirements needed by CCTT. There is no way to currently evaluate this. However, some of the architectural enhancements will support more event-driven behaviors and hence should allow for better total performance.

C- 17


Schedule

This approach has minimized the schedule risk from option 2. The architectural changes have reduced the estimate down by approximately 46 staff months. However, the total effort is substantial (379 staff months).

Reliability

As in option 2, there is no loss in reliability vs. ModSAF baseline reliability. It is unknown how to compare reliability between ModSAF baseline and CCTT SAF. STOW ACTD had average 10 hours uptime for Joint SAF during the 48-hour exercise, and Army SAF was approximately 24 hours. The only difference in reliability might be that new features have been added to the architecture. However these features are considered low-risk, and should not impact reliability once fully tested.

Scalability

As with all approaches outlined, there are echelon scalability limitations to using an FSM approach for behaviors. This approach does not make the problem worse.


Behavior V&V

As in option 2, all re-implemented CISs (and their building blocks) would have to be V&Ved. We would recommend doing the V&V as was done originally for CCTT. Regression testing would have limited utility because the tests would be against a different baseline. There would need to be some interpretation of the results, and you could not take advantage of previous testing results. However, the behavior design will make use of the original CCTT SAF behavior states wherever possible in order to maximize ease of V&V.

There is very little in these architecture enhancements that would help with V&V. We will implement an FSM exerciser that will help verify control flow. Note that this will not significantly help the V&V process, but will be a useful tool for developmental testing.

Extensibility

No ModSAF extensibility lost. CCTT behaviors will now extensible in the same style that ModSAF is. The architectural enhancements in this approach support better extensibility for behaviors. Nothing done here is in support or in detriment to of higher level behaviors (battalions). This is true in both CCTT and ModSAF.


As in option 2, there will be low maintenance because there will generally be only one implementation of each behavior. In some hopefully rare cases, there may be a CCTT version and a ModSAF version of the same behavior. Hopefully that is near zero.

C- 18



The enhancements are dominated by extensions to the FSM language. Once fully tested, there will be no new maintenance issues associated with this approach. So, the maintenance issues are the same as option 1.2 (which is low).


This approach has the same adaptability to new technology as approach 2. New technology implemented in ModSAF derivatives such as Joint SAF will have a straightforward migration path to this unified architecture. New technology implemented in CCTT SAF (such as FBCB2) will require re-implementation in OneSAF.

Development Adaptability Assessment

Ongoing ModSAF development Good Ongoing CCTT SAF development Poor (re-implementation) Existing and ongoing STOW enhancements

Good

Joint SAF Good CFOR Good CCSIL Good Command Talk Good

OneSAF R&D Unknown Ease of coordination and integration of multiple developers

This approach has the same ease of coordination as approach 2. The OneSAF testbed can leverage off of the existing ModSAF and Joint SAF approaches for parallel distributed development. The ModSAF architecture has already proven itself to be extensible within the CGF community, and the enhancements described here only improve that extensibility.

Cost


There are three efforts for this approach.

(1) The upgrade of the building blocks (2) Implementation of architecture extensions (3) Implementation of the CISs not already implemented in the new

architecture

There are several building blocks that need to be upgraded to support CCTT requirements. This includes movement issues (utraveling, vmove, movemap), and shooting issues (vassess, vtargeter), etc. These upgrades are also required for option 1.2. These enhancements are estimated in a table, below.

C- 19



(1) There are architectural pieces that need to be added to the FSM language for improving it. These estimates are included in a table below, and include the following items:

Abstract the subordinate management, which includes attrition, change of leader, and changes to task organization. Abstract a better timing mechanism (potentially based off of HHours) into the FSM

language or task manager. This would allow an event to be fired when a period of time has elapsed.

Support better defaulting of params events. There should be a default params events for each task.

Have the subordinate fire an event when its behavior completes so that we don't need to poll for it.

Abstract into the behavior architecture the storage management for creation of PO objects. This includes the storage as well as garbage collection. There is duplicated code in several places doing this right now.

Implement an FSM exerciser that would allow you to test the FSM without forcing the author to run the entire system. This may have a key role in helping the VV&A process.

(1) Implement all of the CCTT CISs not already implemented in this new architecture.


The time estimates are 379 staff months without including V&V. This is approximately 46 staff months less than option 2. This is a development activity.

Building Block Enhancements

Estimate (Man- Months)

Misc. 12 Movement 18 Shooting 6 Total 36

Architecture Enhancements

Estimate (Man- Months)

FSM Architecture 6 Checkpointing 1 Order Decomposition 12 Total 19

Per-CIS Effort Weeks

CIS Man- Weeks

CIS Man- Months

346 75% 5.0 1297.5 324.38

C- 20



CIS Development Architecture Bulding Block Man-Months Enhancements Man- Additions Man-

Months Months

Total Man- Months

324.38 19 36 379.375


• The assumptions are the same as option 2, namely: • We expect to be able to reuse some existing ModSAF behaviors with CCTT SAF

behavior re-implementation. • We expect to reuse as many physical models as possible.

• We assume that the architecture changes will gain us approximately 1 week per task therefore justifying the architecture changes.

Assessment

For each assessment criteria (each row), fill in the score columns and make an initial assessment of the weight for each category. Describe your rationale for each weight value. The Low/Medium/High columns qualitatively describe the meaning of each value for a particular criterion.









Impact to The approach The approach The approach has 2 existing has virtually no has some many impacts, the

C- 21



ModSAF impacts to the impacts to the effort involved in development existing existing overcoming the community programs or programs that impacts are very (e.g., STOW) community could be over







Impact to The approach The approach The approach has 4 current CCTT has virtually no has some many impacts, the development impacts to the impacts to the effort involved in (e.g.,FBCB2) existing existing overcoming the








Cost 379mm


In this section, describe your justification/rationale for the scores provided. Also describe your rationale for the initial weights assigned to each criteria.


All items to be modified are designed and understood, except for Order Decomposition. The system changes resulting from the designs are anticipated to be minor. If it were not for the

C- 22


current lack of a design for Order Decomposition, the total feasibility would be assessed as a

Program Risk

Program risk was assessed as a "4" because although all program requirements are met, there will be great effort involved, and there is risk to completing the task within schedule.


Existing program impact for ModSAF was assessed as a '2' due to the changes being applied to ModSAF and the potential rewrite of some behavioral support and models. Existing program impact for CCTT was assessed as a "4" because of the large V&V effort required to re-validate all CCTT-specific behaviors. This design will make use of the original CCTT SAF behavior states wherever possible in order to maximize ease of V&V.


This approach preserves the ModSAF architecture, and will not preclude the incorporate of future ModSAF-derived enhancements, such as developed under the STOW program. CCTT SAF enhancements will be more difficult to incorporate since this approach is disjoint from the CCTT SAF architecture. It is assumed that there will be more ModSAF-derived technology development for SAF than CCTT SAF, based on a distributed funding base that includes resources outside the Army.

Cost

Refer to the effort to migrate section for a discussion on cost.

C- 23


Behavior Assessment: Option 5 (Extend CCTT SAF)


Start with CCTT SAF as the initial baseline and incorporate architectural changes to satisfy extensibility. The CCTT SAF behaviors will remain largely unchanged in the sequencing of actions but the supporting software and control structure will be re-designed. This re-design includes a inversion of the control strategy where units and order handlers (FSM's or behaviors) are registered rather than hard-coded in the structure of the code. In addition, the concept of common behaviors will be unified between the BLUFOR and OPFOR systems to promote describable layering of the software. The crew system will remain largely unchanged except that extensions required for new ModS AF vehicle characteristics will be incorporated. In addition, the Weapon Crew model will be reworked into an FSM approach in a manner similar to the driver re-implementation during CCTT development (driver provides an existing model for the definition of a cooperative collection of FSM's). The UK CATT development effort supports this re-architecture in that they are performing some level of behavioral architecture re-design with similar approaches and objectives. The following list provides a more detailed look at the approach for this option.

• Maintain the overall CCTT SAF Behavioral Architecture • Concept of units that receive control individually • Communication by events • Keep organizational structure and capability for re-organization • Keep and modify the CCTT SAF crew design

• Keep the driver and low level path planning (move map) approach • Modify the weapon crew to incorporate FSM's as re-engineered from both

ModSAF and CCTT SAF • Keep the other crew approaches since they are designed to satisfy specific CCTT

requirements • Keep the concept of a decoupled crew behavioral model which receives inputs

only through messages and events • Alter the architecture to reuse good solutions of ModSAF

• Unify orders from specific unit based data models to more generic orders • Invert the architecture to remove the explicit structure in the code to support a

registration service for order handling and unit simulation • Units are described by data files • Orders handled by a unit are described by data files • Handlers for an order are described by data files • Central default situational context handlers with standard information which can

be replaced (battle loss, obstacle, spot lists, organization) • Partitioned data model • Multiple resumes from overrides implemented as stackable slots

C- 24


• External interface control accomplished by using the existing object interfaces in CCTT combined with the slot data model for symbolic lookup and introspection

• Configurable reactions • Background situational assessment tasks identified by the order • Default set of tasks supplied with the system which perform the current CCTT

situational assessments (ground enemy, obstacle, air threat, indirect fire) • The order supplies the behavioral responses to situational assessment task

messages (it provides the reactionary behavior to execute if the situational assessment task triggers).

• Create a message type of an assessment task trigger with appropriate reasons and data.

• Scenario save which supports pausing a scenario and restarting the scenario at a later time (while not relying on the previous distribution topology).

• Change the data model structure to a slot based approach (similar to an HLA data model) • Alter the FSM paradigm

• Formalize the FSM representation • Utility services and encapsulated representations of the state machine structure • Promote the FSM to an architectural type with a method of separation from the

supporting code and structures • Standard entry points to mimic standard functions for an FSM (prepare, execute,

pause, resume, interrupt, stop) • Formalize specific events for state transitions • Support for fully event driven FSM's rather than just periodic approaches (mission

space events and next tick events) • Tools for the generation of new FSM's (structure, files, data models, incorporation

into the system) • Expand the supporting architecture

• Domain analysis of CCTT and ModSAF code to identify reuse • Stress utility collections that support primitive services for behaviors (lead

identification, route manipulation, location manipulation, location, organization, C&C, location calculations, enemy context, control measure proximity, control measure construction)

• Identify events which cause transitions and provide primitive support for identification and notification (enemy sited

• Encapsulate all data models for events into service functions (crew orders, reports, all orders)

• Common FSM's formalized, standard interfaces/control, and documented for developer query and use

• Re-factorization of Behaviors • CCTT behaviors reengineering into C and supporting architecture • ModSAF behaviors redesigned into support architecture

• Support for parallel, cooperative FSM's at the crew level incorporates ModSAF subsumptive approaches

C- 25



The advantage of this option is that it retains the CCTT SAF behavioral approach thus minimizing any re-design or re-implementation of behaviors in a different representation. This minimizes risk by reducing the rework of the suite of CCTT complex behaviors to a re- factorization effort. In addition, the re-architecture embraces the major requirements of the unification. The ModSAF behaviors will be reverse-engineered and incorporated into this baseline.

• Encapsulation • Minimizing the ability to set data from other object promotes extensibility • Aligned to the real world model of information transmission • Decouples information management • Minimizes interactions between distributions • Each unit receives control individually • Promotes load shedding (degradation remains proportional) • Provides support for multi-threading at the scheduler

• Extensibility is improved • Inverting the architecture allows for minimal software design overhead when adding

new behaviors or units (registration for both units and orders that units handle) • Less concentration on unit formalism minimizes software design overhead for adding

new units • Generic order structure minimizes maintenance by increasing reuse of data model

elements • Lessons learned from ModSAF inversion of the architecture minimizes risk • Systemic approach to layering and primitive utilities centralizes capabilities

• Results in clear API's by formalizing interfaces • Clear selections for event generation • Clear use of contextual information • Minimizes maintenance by isolation of capability implementations in one place

• FSM formalization promotes standardization • Active FSM structure definitions promote addition of FSM capabilities system-wide

with minimal impact • Reduces process overhead for development of new behaviors (tool sets) • Data model standards promote multi-threading • FSM's trigger on events rather than periodic processing reduces behavioral

processing requirements • Standard entry points support system-wide standard control of FSM resources and

execution • Data model re-representation

• Supports extensibility by removing meta-data from the code structure and allowing for re-definition without code changes

• Distribution subsystem complexity is greatly reduced • Scenario file generation is simplified by allowing for ASCII representation

• Promotes the reuse of exercises between revisions of the data model

C- 26


• Promotes reuse and distribution of the exercise parameters to other technologies and representations (i.e. charts generated by a drawing package, distributed scenario generation, web-based browsing and examination of the scenario by other technologies/languages (Java)).

• GUI support reduced to simple engine without an understanding of the meta-data (GUI screens for a behavior are data driven and can be specified by the behavioral engineer)

• Close alignment to an HLA style of data representation allows for easy incorporation of HLA with the object model expressed in the models (rather than a translator at the bottom of the layers).

• Data model can be defined by the model directly with support from tool sets • CCTT SAF behavioral structure is not altered minimizing errors in re-representation of

behavioral models affecting verification and validation of doctrinally correct behaviors. • Concept of a cooperative behavioral model for the unit is preserved allowing for

language translation rather than representation translation • Primitive utilities and layering of the behaviors architecture represent an improvement

on an existing behavior rather than a re-design • The CCTT SAF behavioral model represents a more encapsulated and decoupled

approach to behavioral modeling compared to explicit manipulation of subordinate data models (unit CPU usage on CCTT represented 3% to 8% of the processor utilization)

• The Command From Simulator (CFS) model is preserved as a proven approach • Changes from PDSS on completion of requirements satisfaction would be easier to

incorporate • ModSAF generic unit behaviors can be represented using this extended CCTT SAF

paradigm • Extensibility would be addressed by incorporating lessons learned from internal

architectural re-design analyses, UK CATT re-archirecture and primitive re-structuring, and ModSAF modular, distributed support for behaviors.

• Legacy systems already exhibit portions of the requirements • CCTT SAF brings a set of doctrinal behaviors which satisfy CATT training

requirements • ModSAF brings concepts for modular behavioral infrastructure to support

extensibility • UK CATT is already in the design phase of a behavioral infrastructure re-architecture

to promote the easy addition of units and behaviors • Adaptability to new technologies and architectures is supported

• Layering promotes the addition of new concepts and technologies as long as the information flow is maintained at the interfacing level • A new technology or approach needs to use the underlying information flows

correctly • The depth of the perturbation to the information flow determines how deep into a

layer the new approach reaches

C- 27


• Standard layering approaches and the encapsulated nature of the CCTT SAF information flows promotes the incorporation by well defined flow of control and authority to alter information

• Inversion of the architecture allows for models to replace capability implementations at various levels as has been demonstrated on ModSAF

• Re-factorization of CCTT SAF behaviors minimizes the cost of the translation from Ada toC • All behaviors must be examined and converted to C no matter what the approach • Pre-defined methods of handling information flows through the use of layering and

architectural inversion are incorporated during the translation to C • The structure of the behaviors, decisions in the behaviors, and information flows are

maintained from the original design maximizing the reuse and minimizing the cost associated with the original validated behavior (i.e. it is not being re-represented in a different paradigm).

• All the CIS implementations must be visited for both the re-factorization and the translation to C so both could be done in parallel.

• V&V would take less effort since the underlying models have not changed

Disadvantages of using this Approach

The main disadvantage of this approach is that some development must be accomplished up- front which is not required for the options that use the existing baselines. In addition, this involves a translation of CCTT SAF Ada source code to C. However, the behaviors layer in CCTT does not use any Ada language specific constructs, which would reduce risk.

• Schedule/Cost risk • The re-design involves some effort that would not be required in a straight CCTT

SAF or ModSAF solution • There would need to be a domain analysis of the information flows and

supporting capability implementations for both CCTT SAF and ModSAF to determine the list of capabilities, the partitioning of these capabilities into layers, and re-factorization of the information flows

• This would introduce additional code for testing from an un-modified CCTT SAF or ModSAF baseline

• The CCTT SAF behaviors would need to be re-represented in C (this is actually a disadvantage when compared to an unmodified CCTT SAF solution only, the rendering of CCTT SAF behaviors in C is a given for most other choices)

• The re-design of the primitives and behavioral layers would delay the immediate incorporation or re-factorization of behaviors which, while a technically correct approach, might be counter to industry/user expectations

• The representation of behavior models in line with the current CCTT SAF approach changes what the ModSAF development community is currently using. This will result in changes to existing non-baseline ModSAF systems and some level of impacts to the community.

C- 28



The CCTT SAF behaviors are proven to satisfy the CCTT SAF requirements. The only questions associated with a straight CCTT approach are the Ada language and the extensibility of the behavior infrastructure. On the language issue, this option assumes a level of effort in the translation of the CCTT behaviors and infrastructure to C. This is technically feasible since the behaviors and the supporting infrastructure do not use the Ada language in any unique ways, and all language constructs used can be directly translated to C. In fact, the representation of the infrastructure in C facilitates the re-factorization issue of an inverted architecture (use of function pointers). The issue of extensibility of the CCTT SAF behaviors is rooted in the wish to provide extensibility for a user group that is new to CCTT. The re-factorization of CCTT SAF behavioral infrastructure does not represent changes in information flows or data models. It does represent how they are managed and flow through the system. In this manner, the re-factorization is applied to the simulation space only and not the mission space models. This is based on lessons learned from ModSAF infrastructural support for distributed development and extensibility.

Program Risk

Requirements Satisfaction

This fully supports the CCTT requirements since the underlying baseline is a CCTT baseline and the proposed approach does not alter the CCTT behavioral models or information flows. The ModSAF requirements will be mostly met in that all the ModSAF behaviors can be rendered in this architecture and extensibility is supported. What will not be met is any derived requirement to support the existing AAFSM language for behavioral definition.

There is some requirements satisfaction risk for the ModSAF development community. If the behavioral representation, control strategy, and implementation is changed, they will incur some impact in their existing efforts. However, the resultant changes should be a unifying change

Performance

This change does not adversely affect the performance characteristics.

Schedule

There is some level of schedule risk (development and testing) since the infrastructure is being re-designed, the behaviors are being re-factorized, and the data model representation is being re-worked (slot based). However, the addition of new units and behaviors should be easier.

Reliability

This represents a unifying modification and should retain or enhance reliability.

Scalability

C- 29


This does not affect the scalability limitations inherent in either of the systems.



Since the CCTT SAF behaviors are retained, this fully satisfies the specific CCTT requirements. There would be some issue of CCTT SAF's order creation time decomposition when compared to ModSAF's superior order decomposition to subordinates.

Behavior V&V

This approach should result in low PTR counts for the V&V effort since the structure of the behavior is determined from existing CCTT SAF behavior FSM's which have already been V&Ved.

Extensibility

Extensibility is the key component of this effort and therefore is the basis of this extention. This approach would benefit from lessons learned in designing ModSAF for extensibility.


This does not adversely impact baseline maintenance beyond the existing problems associated with either ModSAF or CCTT SAF.


There is nothing inherent in this approach that prevents adaptability to new technologies or architectures beyond the existing systems. The only affect is that current ModSAF developers will be exposed to a different method of behavioral design, unit and crew control, and primitive sets. This has impact to existing projects that rely on the AAFSM language or the ModSAF behavioral implementation. However, the decoupling of the crew and unit behaviors from the simulation space and a closer alignment with the mission space should provide more modular connections to the resulting system.


This approach should facilitate coordination and integration of multiple developers in a manner similar to the current ModSAF baseline. Developers, however, must be able to adapt to a different method of rendering behaviors and controlling subordinate units.

Cost


New Functionality (LSLOC) Multiple Resumes

FSM Abstraction 500

C- 30



3,000 External IF 500

Configurable Reactions 600 Total LSLOC

4,600 SLOC/Hour effort 3

Hours effort 1,533

Months effort 10

Infrastructure Rearchitecture CCTT Infrastructure PSLOC

250,000 SLOC/Hour effort 15

Hours Effort 16,667

Months Effort 104

ModSAF Behaviors Incorporation New Behaviors 106

Unique Behaviors 75% Per CIS effort (weeks) 7

Weeks effort 557 Months effort 139

Existing Behaviors Rework CCTT CIS's 346

Per CIS effort (weeks) 3 Weeks Effort 865 Months Effort 216

Total Months Effort

ModSAF Behaviors Incorporation

These numbers are based on the number of generic behaviors currently in ModSAF (106). The ModSAF analysis team determined that there was a 25% overlap between the behaviors for CCTT and ModSAF. It is estimated that 7 weeks per CIS will be expended to re- represent the ModSAF behaviors.

Infrastructure Re-architecture

C- 31



The infrastructure re-architecture is based on the amount of CCTT SLOC that needs to be revisited. The number in the table represents physical SLOC for the behavior common subsystem, the SEOD, and common utility packages in each of the behavior specific subsystems (such as BLUFOR, OPFOR small unit tactics). The SLOC/hour effort represents the lines of code that can be converted to a layered C implementation per hour.

Existing Behaviors Rework

These numbers are based on the number of selectable CIS's implemented in CCTT. This number does not include the reactive behaviors or the non-selectable common behaviors since the original estimate of 291 hours subsumed those developments. The estimate is that a CIS can be converted to C and re-factored in 4 weeks.


The following list outlines the assumptions for this approach:

• This approach expects to reuse design approaches from the current UK CATT behavioral re-architecture.

• This approach expects to result in an architecture that simplifies the incorporation of new behaviors and units.

• This approach assumes that the GMI interface approach to physical model control remains largely unchanged (for effort estimation purposes only)

• This approach assumes that the existing crew control model can be extended to support any unique vehicle capabilities in the ModSAF collection that is not in the CCTT system.

• This approach assumes that the AAFSM language and structure does not have to be retained to be compliant with the ModSAF replacement requirement.

• This approach assumes that the current model for the distribution of objects and events is not counter to the behavioral model approaches and requirements in ModSAF.

• This approach assumes that the conversion to C for behaviors occurs in parallel with the re-factorization of the behaviors and that there will not be a artificial programmatic requirement to fully convert CCTT SAF to a workable C version without alterations first.

Assessment

The following table provides quantification of the criteria (note the scale in the title bars, the numeric scale was never defined).

Criteria Low (1) Medium (5) High (10) Score Technical The technical The technical The technical 4 Feasibility risk feasibility is feasibility is feasibility is poor.



C- 32





















will require additional


C- 33



enhancements to support future modification

Cost 469mm


In this section, describe your justification/rationale for the scores provided. Also describe your rationale for the initial weights assigned to each criteria.


The score of 4 assigned to this criterion is based on the fact that the approach is tailored towards extensibility and feasibility. However, there is some rework of the representation of the data model that has not been implemented in any system to date. The starting architecture is currently in use and the prototypical re-architecture is being implemented on the Firm Fixed Price UK CATT program (which cannot suffer a technical infeasible approach).

Program Risk

Program risk is rated as a 4 because of the additional effort in the domain analysis and re- design of the behavioral infrastructure. This should result in a unified approach promoting easier extensibility allowing the ModSAF unique capabilities to be incorporated.


Existing program impact for ModSAF is rated as a 3 because of impact to current ModSAF users. This represents a change in the behavioral representation that these consumers are accustomed to. There would be some learning involved and potential re-tooling for these customers. CCTT impact is assessed as a ' 1' since its impact is minimized by this approach by retaining much of the behavioral representation and control strategy.


Adaptability to new technology is rated as a 4 due to the impact to new development currently being performed on STOW and other ModSAF derivatives as well as the lack of support for truly subsumptive behavioral representation currently on ModSAF. CCTT SAF work for PDSS, P3I, and UK CATT enhancements are supported.

Cost

Refer to the effort to migrate section for a discussion on cost.

C- 34


Behavior Assessment: Option 6 (Develop capability to run both ModSAF and CCTT SAF behaviors within the OneSAF testbed)


Start with ModSAF as the initial baseline. Modify the ModSAF infrastructure to support both ModSAF and CCTT SAF behaviors as is (with little or no changes to the two sets of behaviors). This can be done in one of two ways:

1. Link the Ada FSMs into ModSAF using a tool such as GNAT, such that wrapper functions are used and provide additional architectural support such that the Ada FSMs can be "run" from within ModSAF. There would need to be a SEOD to PO translation as well.

2. Use an Ada to C translator to convert the Ada FSMs to C. Either maintain the Ada or C version in the repository as the "master" version.

Advantages of using the approaches

• no reimplementation of existing ModSAF or CCTT SAF behaviors • VV&A effort is minimal • perhaps the cheapest short term solution in terms of cost and time • very high level of code reuse


• perhaps the most expensive long term solution in terms of cost and time due to maintenance of the "two headed system"

• duplication or overlap of the behavioral capabilities is not reduced • overall code size increases drastically • Ada code or "automatically translated" Ada code is undesirable • expected CCTT execution will be less efficient due to additional layers of function

invocations or poorly "translated" Ada to C code.


We have no idea what problems we might run into. We have not extensively used an Ada to C translator or GNAT and therefore are unaware of potential problems. We are trying to merge very different architectures and we will redefine how much we are going to have to pull over from CCTT. There are huge issues of whether the machine/compiler/linker will be able to handle to large size of this effort. Heavy risk associated with many unknowns.

Program Risk


C- 35

Appendix C - Migration Assessments ADST-II-CDRL-ONESAF-9800101 Behaviors Assessment Option 6 ^ MAY 8, 1998

Both systems' behavior requirements should be satisfied.

Performance

There are likely to be fairly significant performance issues due to the size and the wrapper approach. This approach will likely not satisfy the performance requirements of either system.

Schedule

Unknown at this time and therefore high schedule risk.

Reliability

Depends on the reliability of the tools and the translation process that is compounded with the reliability of both systems.

Scalability

This not a scalable solution is any way shape or form. When we are talking about behavior echelon scalability there should be only minor differences from the other approaches. However, if we are going to scale up, we will now have to effectively implement behaviors in 2 different trees.


Behavior V&V

Since only considering the Behavior V&V of CCTT, this should be a fairly low risk item. There should be less V&V effort since the behaviors remain the same.

Extensibility

This approach does not satisfy ModSAF's extensibility requirement.


By far this is the worst maintenance nightmare possible. In fact, it is worse than having 2 independent systems.


Half of the behavior architecture would be extensible to new technology and architectures. Which half would depend on where the new technology was developed. For example, bringing in STOW software would only work with the ModSAF behaviors (it would need to be implemented completely differently in the other). An advantage is that this would potentially be able to share common with the rest of the CCTT system.


C- 36



If a behavior was to be added to both the ModSAF side and CCTT side, the developers will have to know both systems.

Cost


Add CCTT SAF architecture and behaviors (including SEOD) on top of the low level ModSAF architecture.


This is an unknown. This has the potential of being the lowest cost alternative, but it is also the largest cost risk.


A huge assumption is that the CCTT behaviors will work with the physical models in ModSAF. If not, then other subsystems will need to be brought over. This may lead to more subsystems being brought over, which leads to the domino effect.

Assessment

For each assessment criteria (each row), fill in the score columns and make an initial assessment of the weight for each category. Describe you rationale for each weight value. The Low/Medium/High columns qualitatively describe the meaning of each value for a particular criterion.

Criteria Low (1) Medium (5) High (10) Score Technical The technical The technical The technical 9 Difficulty feasibility is feasibility is feasibility is poor.





programs or programs that impacts are very community could be over large, or technically

C- 37


come with challenging moderate effort












Adaptability to The resulting The resulting The resulting 7 new technology infrastructure or infrastructure infrastructure is not

environment does not unified and should can be easily support be completely extended extension and



Cost


C- 38


The assessment teams determined that the baseline impacts of dual competing architectures was not feasible and did not perform any costing assessment.

C- 39

Appendix C - Migration Assessments Behaviors Assessment Summary


Behavior Assessment Summary

This is the summary document we plan to fill out at the end of the assessments.

The migration approaches are as follows.

1. Re-implement missing behaviors from ModSAF into existing CCTT infrastructure. 2. Re-implement missing behaviors from CCTT SAF into existing ModSAF infrastructure. 3. Develop new unified behavior representation and implement all behaviors in it. 4. Extend ModSAF with additional infrastructure to ease re-implementation of CCTT

behaviors within ModSAF. 5. Extend CCTT SAF with additional infrastructure to ease re-implementation of ModSAF

behaviors within CCTT SAF. 6. Develop capability to run both ModSAF and CCTT SAF behaviors within the OneSAF

testbed.

Criteria Re-implement Re- Develop Extend Extend CCTT Develop ModSAF implement New ModSAFand SAF and Re- Dual

Behaviors in CCTT Behavior Re-implement implement Behavior CCTT SAF SAF Architect CCTT SAF ModSAF Architectu

Behaviors ure Behaviors Behaviors re in Capability

ModSAF Technical Feasibility Risk

3 1 N/A 2 4 9

Program Risk

2 7 N/A 4 4 8

Existing impact to ModSAF user community

7 1 N/A 2 3 1

Impact to existing ModSAF development community (e.g., STOW)

7 1 2 3 8

Impact to existing CCTT program

1 7 4 1 1

Impact to current CCTT development (e.g., FBCB2)

1 7 4 1 8

C- 40

Appendix C - Migration Assessments Behaviors Assessment Summary



10 3 N/A 3 4 7

Cost 260 mm 425 mm N/A 379mm 469 mm N/A

C- 41

Appendix C - Migration Assessments ADST-II-CDRL-ONESAF-9800101 System Assessment Option 1 MAY 8, 1998

C.2 System Assessment

System capability Assessment: Option 1

Use CCTT System Capabilities as a basis and re-implement the missing system capabilities from ModSAF.


Take CCTT SAF as the baseline.

Add the following ModSAF system capabilities to CCTT SAF:

Develop a Pocket SAF Develop or Support DT executables Develop or Support the ModStealth executable Develop or Support the Logger executable Develop or Support the Blaster Develop a strategy for partitioning the CGF Protocol Develop the approach for supporting the ModSAF protocols and protocol logics for

SIMAN, Environment, Minefields, Weather, and Exercise Management Develop the External APIs to the current users such as CFOR, Command Talk, Soar,

BBS, and other PO users.

Pocket SAF Capability Provide an executable version of the CCTT baseline that combines the capabilities of the SAF WS and the CGF.

DT executables Provide executables for these as part of the CCTT Baseline. Impact is loss of common code just as we're losing common code within CCTT.

ModStealth executable Provide executables for these as part of the CCTT Baseline. Impact is loss of common code just as we're losing common code within CCTT.

Logger executable Provide executables for these as part of the CCTT Baseline. Impact is loss of common code just as we're losing common code within CCTT.

Blaster Provide executables for these as part of the CCTT Baseline. Impact is loss of common code just as we're losing common code within CCTT.

CGF Protocol Partitioning Expand the SEOD object attributes to include a logical partition attribute and modify the network controller to filter on this attribute. Each object in a SEOD for a given node will be identified as belonging to a logical partition. Each partition will be a contained SAF WS and

C- 42


CGF suite and will not interchange information (except for any necessary simulation management objects).

ModSAF protocols Standardize API around protocol logic execution and provide pluggable modules: One for CCTT Standards and one for ModSAF standards Alternative: merge capabilities into the same logical stream and provide flags for which standard is to be used.

External APIs Modularize and standardize external hooks that have been established for ModSAF and provide the like capabilities within the CCTT SAF architecture.

Distribution Mechanism Merge the data models from both CCTT SAF and ModSAF in support of the unified clients. Incorporate the features from ModSAF that support GCS, endianess support, scenario save, and the ModSAF baseline RTI support.

Framework Rework Rework the current CCTT framework to develop a C language approach.


• All CCTT System Capabilities are satisfied with minimal effort. • ModSAF scalability issues related to the distribution mechanism are mitigated.


• Maintainability will be a lot of work for each duplicate set of functionality (ie. Supporting both minefield protocols, etc.).

• Extensibility will be compromised due to the duplicate sets of functionality in the system.

• Maintainability will be more difficult with translators and interpreters used to interface to existing un-modifiable CCTT components.


Overall, this approach is technically feasible but there are some challenges. These challenges are based on the conflicting desire to maintain backward compatibility with both system interfaces and the desire to merge disparate systems. The use of translators and interpreters are minimized due to their inherent problems with maintenance and the tendency to reinforce deprecated interfaces and data models. In addition, care must be taken to limit the single point translation of information that can promote bottlenecks in a distributed environment. Other system requirements which must be met are feasible considering the fact that the infrastructure (or simulation services) of both systems have similarities. For most of the external executables that support a protocol or service, the existing infrastructure can be reused promoting some level of ease of maintenance.

C- 43


Program Risk


All ModSAF requirements can be met. All CCTT SAF requirements will also be met. CCTT specific data requirements for the SEOD file format and the CGF protocol will be met by providing an implementation of the SEOD which translates the data model to the OneSAF testbed data model. In this manner, CCTT will suffer minimal impact caused by an addition to its code baseline that represents a new implementation to the SEOD API.

Performance

It is anticipated that the performance goals required by each capability will be met and not be degraded when compared with present systems.

Schedule

There is minor schedule risk associated with this option based on the additional requirements that are being re-represented in this baseline.

Reliability

There is no anticipated detrimental change to the reliability of each of these systems when compared to the current systems.

Scalability

This does not affect the scalability limitations inherent in either of the systems. There is an anticipated increase in the distribution system's inherent scalability based on the increased scalability of the SEOD when compared with PO scalability.


System capability Requirements Satisfaction

It is anticipated that all system capability requirements will be maintained and met.

System capability V&V

This change has no impact on V&V and provides no adverse impact on regression testing.

Extensibility

This change would incorporate system and architectural lessons learned from the ModSAF development that promoted extensibility. The impact to extensibility is anticipated to be minimal.


There is some issue of a loss of connection to the shared baseline of both the ModSAF systems and the CCTT system. The ModSAF capabilities which provide the DT executables,

C- 44


ModStealth executables, Logger executable, and Blaster executable rely on common code. It is anticipated that the resulting infrastructure will be usable to these systems but that their closeness to the resulting system will be less. In addition, the present shared infrastructure throughout the CCTT system will be removed and this baseline will incorporate new infrastructure components that will not be shared with CCTT.


There is nothing inherent in this approach that prevents adaptability to new technologies or architectures beyond the existing systems. The only affect is that current ModSAF developers will be exposed to architectural approach and system approach. This might provide some impact to developers that rely on specific implementations of system components in ModSAF.


This approach should facilitate coordination and integration of multiple developers in a manner similar to the current ModSAF baseline.

Cost


Pocket SAF - The approach for this capability is to combine the capabilities for the workstation and CGF code into one executable. This was the standard configuration for Build 2 for CCTT and is the present configuration for the DIMM.

DT executables, ModStealth executable. Logger executable. Blaster - The approach for these capabilities are to combine the current CCTT infrastructure components with each of the models and protocols that currently exist on ModSAF for these systems. This is the approach used for several services and systems in CCTT and is similar to the approach used on ModSAF.

CGF Protocol partition - The approach for this capability is to provide an attribute for each SEOD object in the current object data model. This attribute would be a byte which represents a logical partition. The SEOD code would then be modified to accept the assignment to a partition and filter incoming information based on this partition.

ModSAF protocols - There are two strategies for this capability that are outlined in earlier. The first approach would be to provide configurable modules that provide each set of protocols and can be replaced when needed. The second approach would be to provide both sets in one model set and parameterize which is used at any given time.

C- 45

Appendix C - Migration Assessments System Assessment Option 1


External APIs - The approach would be to identify the external APIs to be developed, identify what information or control is provided to the system capabilities, and incorporate modifications to the system for similar information and control to the CCTT baseline.

Distribution Mechanism - The approach would be to merge the data model requirements from ModSAF with the protocol and distribution mechanisms of CCTT. This approach would preserve the CCTT distribution scalability and capacity.

Framework Rework - The approach would be to convert the framework components to a C language representation. There would be minimal risk for this effort since the framework components are non-complex and their similarity to ModSAF infrastructure components facilitate selective reuse.

Effort to migrate related capabilities

Capability Months Pocket SAF 2.5 Dynamic Terrain 7.0 ModStealth 3.0 Logger 2.0 Blaster 0.5 Protocol partitioning 2.0 ModSAF Protocols 4.0 External API's 6.5 Distribution Mechanisms 10.0 Framework Rework 5.0

Total Months 42.5


• The OC and MCC components of CCTT SAF cannot be modified unless it is funded by this OneSAF project.

• The infrastructure components of the modified CCTT SAF is similar to the existing services and components in ModSAF

• The major reuse of the disparate executables is preserved in the support for the protocols and services in the client models and the infrastructure. This allows existing ModSAF models to be incorporated into the new infrastructure with the new information flows (i.e. the major models of the DTS-Sim can be re-hosted in this new infrastructure).

Assessment

C- 46




Criteria Low (1) Medium (5) High (10) Score

Technical The technical The technical The technical 3 Feasibility risk feasibility is rated feasibility is good feasibility is poor.

very good. but the migration involves some very difficult technical issues.


Program Risk There is little risk There is a The migration 2 of the migration moderate risk of approach is very approach the migration

approach risky and has never been attempted before

Impact to The approach has The approach has The approach has 2 existing ModSAF virtually no some impacts to many impacts, the user community impacts to the the existing effort involved in

existing programs programs that overcoming the or community could be over


impacts are very large, or technically challenging

Impact to The approach has The approach has The approach has 2 existing ModSAF virtually no some impacts to many impacts, the development impacts to the the existing effort involved in community (e.g., existing programs programs that overcoming the STOW) or community could be over



Impact to The approach has The approach has The approach has 5 existing CCTT virtually no some impacts to many impacts, the program impacts to the the existing effort involved in




Impact to current The approach has The approach has The approach has 2 CCTT virtually no some impacts to many impacts, the development impacts to the the existing effort involved in (e.g., FBCB2) existing programs programs that overcoming the

or community could be over impacts are very

C- 47

Appendix C - Mig ̂ ration Assessments ADST-II-CDRL-ONESAF-9800101 System Assessment Option 1 MAY 8,1998

come with large, or technically moderate effort challenging

Adaptability to The resulting The resulting The resulting 5 new technology infrastructure or infrastructure infrastructure is not risk environment can does not support unified and should be

be easily extension and completely extended will require

additional enhancements to support future modification


Cost 42.5mm


This section, describes the justification/rationale for the scores provided


Technical feasibility risk is a '3' due to the required re-implementation of the different ModSAF executables and the requirement to translate the SEOD data model (including support for GCS and endianness).

Program Risk

This criterion is rated as a '2' based on the re-implementation of the ModSAF executables and the re-forging of the data model.


This criterion is rated as a '5' for the current CCTT program based on the changes required to provide a SEOD translation layering to support the CCTT requirement for the SEOD file format and the CGF protocol (OC workstations). This would tend to invalidate the current exercise files and require translation to the new format. The other impacts are assessed as a '2'. Future CCTT development will use the new baseline and not be impacted by a change. ModSAF development will be minimally impacted except for exercise invalidation.


This criterion is rated as a '5' based on the need for an improved system capability to support future OneSAF architectural composition requirements. OneSAF will require additional enhancements to this underlying architecture to support OneSAF requirements.

C- 48


System capability Assessment: Option 2

Use ModSAF System Capabilities as a basis and add the missing system capabilities from CCTT SAF.


Take ModSAF as the baseline. Add the following CCTT SAF specific system capabilities into ModSAF: Comm, CCTT Protocol Standards, EM Protocol, DAR Messages, BIT (Built In Test), Repair/Resupply Protocol, DI Mount/Dismount Protocol, MCC (exercise initialization setup), OC, and DIWS.

Comm (Real Radio Communications) The Comm software is almost all in C, with some Ada wrappers. Comm cannot be modified. Use the existing Comm software from CCTT SAF and add a shared memory interface and manager into the ModSAF architecture that is equivalent to Comm's shared memory interface. Comm is kept as a separate process since CCTT SAF systems are designed for use on existing dual processor machines. This will help meet the performance requirements for CCTT SAF. The shared memory is allocated in big chunks and is managed by a shared memory manager. The shared memory will contain information about a unit's location and Signal PDUs. Comm will have the ability to be run from any ModSAF station, with the understanding that Comm depends upon other hardware that is not a part of OneS AF testbed software to run. ModSAF will need an editor for the user to specify the speaking unit or intercom to MCC or AAR channels. This editor will be available from ModSAF only when the Comm is also running.

Estimate: 4MM Work: Comm Editor, Shared Memory interface on ModSAF and Comm. Assumptions: Assumes ModSAF GUI choice for OneSAF testbed.

CCTT Protocol Standards 1. Add an entry in ModSAF's disconst.rdr file for CCTT SAF's DIS 2.0.4 enumerations that will be used when running in CCTT SAF mode. Use CCTT SAF's appearance bit methodology, enumeration standards, and articulation modeling when in CCTT SAF mode.

2. CCTT SAF conflicting requirement is to have in flight weapons cease to exist when pausing and resuming the exercise. When in CCTT SAF mode, follow CCTT's requirement, and when in ModSAF's mode, follow ModSAF's requirement to keep in flight weapons when resuming.

Estimate: 1MM for part 1,1MM for part 2 Work: disconst additions, minor coding Assumptions: ModSAF GUI chosen

C- 49


EM Protocol (Environment Manager) Use ModSAF's DT capabilities and add the missing capabilities from CCTT SAF into ModSAF (abatis and log cribs). Support both the ECN and EM protocols. The EM protocol will be supported by a translator to/from MSO and parameterized ECNs and EM PDUs.

Estimate: 6MM

Work: Adjust sizes of relocatable objects before they are created in order to adjust to CCTT SAF's representation limits, and can breach them properly. Develop a converter to/from ECN and EM.

Assumptions: ModSAF GUI chosen Risky - Assumes that these can be mapped!

PAR Messages (Data Analysis Reporting) DAR messages are DIS Event PDUs. Re-implement DAR messages in ModSAF, based on the CCTT SAF code.

Estimate: .5MM Work: We only need to write DAR PDUs (no receipt), less than 10 types. Assumptions: Protocol changes only

BIT (Built-in-Test) CCTT SAF's BIT is implemented with the Action Request PDU. Applications return OK status which is checked about 1 per minute. This is needed in ModSAF if we base our system capabilities on ModSAF because the MCC uses it.

Estimate: .5 MM Work: Make ModSAF capable of receiving Action Request PDU and sending out appropriate acknowledgement. Assumptions:

Repair/Resupplies Protocol Use the OC's Repair/Resupply/Recovery protocols in ModSAF.

Estimate: .25MM Work: minimal, only PDUAPI changes Assumptions: Just the protocol setup is trivial, assume the rest is addressed in the behaviors.

PI Mount/Dismount Protocol Implement CCTT SAF's mount/dismount protocol in ModSAF.

Estimate: .25MM Work: minimal, only PDUAPI changes Assumptions: Assume DIS only (no SEOD). Just the protocol setup is trivial, assume the rest is addressed in the behaviors.

C- 50

Appendix C - Migration Assessments ADST-II-CDRL-ONESAF-9800101 System Assessment Option 2 MAY 8,1998

MCC (Exercise File Init, Pre-Exercise setup) The MCC remains unchanged. The MCC depends upon SEOD and writes exercise/overlay files from SEOD. A setup time one-way translation must occur between MCC's SEOD representation and the new C2 representation of scenarios and overlays (not during runtime). This can be implemented in one of three ways, two methods are described here, and the other option overlaps with the OC, so the last option is described in the following OC section:

Create a separate external data model file conversion program that converts between SEOD/new-C2 scenarios and overlays. This is analogous to CTDB's file conversion program.

Modify the MCC to translate SEOD into new C2 format only when writing to a file. The OneSAF testbed's new C2 protocol would read these scenario/overlay files like any other.

These two options only meet the needs of the MCC since they only fix the startup scenario and overlay conversion. Both options are roughly the same cost. The first option is easier to do since it does not require any modifications to the MCC.

Issues are with translation (PO task state data, PDUs represented at different fidelities, etc...) or interpreting SEOD and using something like taskutil/unitutil to assign tasks and units, or only translating a subset of the PDUs.

The MCC also uses SIMAN PDUs for exercise initialization. These PDUs will have to work with ModSAF (start/stop, pause/resume, restart, delete entity).

Estimate :6MM Work: Develop a translator between C2 and SEOD for exercise init time only, and SIMAN PDU handling. Assumptions: Assumes both data models are mapable.

OC (Operations Center) There are two potential options with regard to the OC, only the first option also satisfies the MCC requirement: 1. Modify the OC to use new runtime C2 (data model, events, and protocol) instead of SEOD, if we use ModSAF as a starting point, and 2. Incorporate the OC capabilities into OneSAF testbed. The OC may be replaced in a few years. If the OC is going to be replaced before we really need to support it, then don't bother supporting the interface to the OC.

Estimate: 6MM for option 1,4MMfor option 2. Work: Option 2: Translate OC to C. Make more data driven, modular, and extensible. Replace SEOD with new C2 protocol.

Assumptions: Assume another task handles merging of PO and SEOD.

DIWS The DIWS has the same initialization issues as OC.

C- 51


Using ModSAF's PO as a basis and add CCTT SAF's SEOD Capabilities (Data Distribution)

We have the luxury in this case to have semi-equivalent capabilities since SEOD was based on PO. There are still many differences between the two, but at a higher level, they appear similar. There are three main components to PO and SEOD: the features, the protocols, and the data models. Both models support scenario/overlay saving and loading.

• Features

• PO features that are different from CGF (SEOD) • Partitioning of PO (large scale simulation support) • Big/little endian mixing • HLA/RTI • GCS

CGF (SEOD) features that are different from PO

• Events (reliability of events) • Strict Object Ownership (others request changes) • Supports about 30 machines using CGF Protocol together • Partial object updates (data reduction on network) • Distribution of units across machines • Better load balancing (boss concept) • Segmented routes

Estimate: 6MM Work: Merge SEOD's features into OneSAF testbed Protocols

PO Protocol PDUs

• Simulator Present • Describe Object • Objects Present • Object Request • Delete Objects • Set World State • Nomination

CGF Protocol PDUs

• Describe Application • Describe Object • Announce Object • Request Object • Delete Object • Describe Event

C- 52



• Request Event

Estimate: 3MM Work: Merge SEOD's protocols into OneSAF testbed

Data Models

The data models between the two systems are organized differently. All of the special features in PO and CGF (SEOD) need to be combined into the new C2 protocol for OneSAF testbed. The protocols need to be merged, and the data models need to be selectively merged. The merging of the data models will be the most difficult part of this task. The merging of SEOD data models should be done on an as needed basis. For example, add all data model components needed to support events, segmented routes, and boss concept, and merge in needed differences between comparable data models.

Estimate: 3MM Work: Merge SEOD's data models into OneSAF testbed


All ModSAF System Capabilities will already be done.

Scalability still exists on the ModSAF side. Both PO and SEOD have their own special features that will benefit in OneSAF testbed. A merge of the features of PO and SEOD will be support much more than any one system can.

All ModSAF PO capabilities will already be done. Scalability still exists on the both sides (CCTT SAF and ModSAF). Extensibility is greater than in any one system. The use of CCTT SAF's Boss CGF and SAF WS concepts in ModSAF should help ModSAF to do better distribution of units (load balancing).


Maintainability will be a lot of work for each duplicate set of protocols (ie. supporting both minefield protocols, etc.). Extensibility will be compromised due to the duplicate sets of protocols in the system.

Maintainability will be more difficult with supporting duplicate protocols.

The time to merge PO and SEOD will take longer than just settling with the capabilities currently in one system.


These tasks can be accomplished on a technical level. Converters/translators/interpreters are not ideal. They require constant maintenance, limit the scalability of the system as a whole, and make it difficult to extend the functionality.

C- 53


There are assumptions made about PO and SEOD having corresponding data models, which add to the risk of this work.

On a technical level, this merge of PO and SEOD is very feasible. This is due to the fact that SEOD was based on an older version of PO. Their high-level similarities make this merge very feasible.

There will be some risk with respect to the selective merging of the two data models.

Program Risk


All ModSAF requirements will be easily met. All CCTT SAF requirements will also be met, but will contain some form of translation/conversion for protocols, which will not meet OneSAF's extensibility requirement on the CCTT SAF side.

All ModSAF PO and CCTT SAF SEOD functionality requirements will be met.

Performance

Run-time translators will lead to decreased performance in the system. The performance of the resulting OneSAF testbed C2 protocol will be better than what is currently in either system.

Schedule

The mapping of data models in PO and SEOD increases schedule risk since it is not known at this time if the assumptions we made are correct.

There is a slight risk in schedule due to the large difference in data models between PO and SEOD.

Reliability

Because these approaches require significant changes to many parts of the system, especially near the protocol layer, there is some risk in reliability. The system needs to be thoroughly tested after these changes are made.

The reliability of the resulting OneSAF testbed C2 protocol will be better than what is currently in either system.

Scalability

Scalability will be met on both sides.

The scalability of the resulting OneSAF testbed C2 protocol will be better than what is currently in either system.



C- 54


The current system capability requirements for ModSAF and CCTT SAF will be met.

Extensibility

Extensibility with regard to protocols will be compromised because there will be duplicate sets of protocols that must be maintained in order to meet existing requirements from both systems.

Because the best features of both PO and SEOD will be merged, the system will be extensible toward modification of existing and new system capabilities.


Baseline maintenance will be more complicated because duplicate sets of protocols need to be supported and tested.

Regarding the merging of PO and SEOD, there is still a significant amount of work to be done to merge existing capabilities into the new system, but it will be easiest with this approach since the merge will contain the features of both systems.


The system capabilities in the OneSAF testbed will be as adaptable to new technologies as the current systems are, but are not as easily adaptable to both modes (CCTT and ModSAF) in OneSAF testbed at the same time since twice the work would need to be done to support duplicate protocols.

Merging the features of PO and SEOD makes the OneSAF testbed very adaptable to new technology and architectures, more so than either one of the SAFs could be alone.


The ease of coordination and integration of multiple developers will be equivalent to ModSAF's current capabilities since this system capability work will be based on ModSAF, but will require more work to test and debug the system since it will be larger and support different protocols.

Since this merge will be based on ModSAF's PO capabilities, the coordination and integration of multiple developers will be the same (or a little better) as what ModSAF's ability currently is for this.

Cost

Enumeration of Capabilities to Migrate

• Comm (Real Radio Communications) • CCTT Protocol Standards • EM Protocol (Environment Manager) • DAR Messages (Data Analysis Reporting) • BIT (Built-in-Test)

C- 55



Repair/Resupplies Protocol DI Mount/Dismount Protocol MCC (Exercise File Init, Pre-Exercise setup) OC (Operations Center) DIWS Using ModSAF's PO as a basis and add CCTT SAF's SEOD Capabilities

Effort to migrate related capabilities

Capability Months Comm (Real Radio Communications) 4 CCTT Protocol Standards 2 EM Protocol (Environment Manager) 6 DAR Messages (Data Analysis Reporting) .5 BIT (Built-In-Tesf) .5 Repair/Resupplies Protocol .25 DI Mount/Dismount Protocol .25 MCC (Exercise File Init, Pre-Exercise setup)

6

OC (Operations Center) 6 - option 1 4 - option 2 DIWS 3 - option 1 3 - option 2 Using ModSAF's PO as a basis and add CCTT SAF's SEOD Capabilities

12

Total 40.5


The OC and MCC components of CCTT SAF cannot be modified unless it is funded by this OneSAF project.

Assessment


C- 56



Criteria Low Medium High Score

Technical The technical The technical The technical 4 Feasibility Risk feasibility is feasibility is feasibility is poor.





Impact to The approach has The approach has The approach has 2 existing virtually no some impacts to many impacts, the ModSAF user impacts to the the existing effort involved in community existing programs that overcoming the

programs or could be over impacts are very community come with

moderate effort large, or technically challenging

Impact to The approach has The approach has The approach has 2 existing virtually no some impacts to many impacts, the ModSAF impacts to the the existing effort involved in development existing programs that overcoming the community (e.g., programs or could be over impacts are very STOW) community come with



existing programs that overcoming the programs or could be over impacts are very community come with


Impact to current The approach has The approach has The approach has NA CCTT virtually no some impacts to many impacts, the development impacts to the the existing effort involved in (e.g., FBCB2) existing programs that overcoming the



Adaptability to The resulting The resulting The resulting 3 new technology infrastructure or infrastructure infrastructure is not

C- 57



risk environment can does not support unified and should be be easily extension and completely extended will require



Cost 40.5MM



The assumptions about mapping PO and SEOD data models and the duplicate protocol support leads to a medium level assessment of its technical feasibility.

The technical feasibility of this approach is very good because it combined the best features of both (PO based) systems into OneSAF testbed.

Program Risk

The risk involves managing duplicate protocols and in mapping PO and SEOD data models.

Impact to existing ModSAF user community

There is very little impact to the existing ModSAF user community because this work is based on ModSAF. The score is '2' and not' 1' because as with any change, there is the potential to have some kind of impact of the existing ModSAF user community.

There will be a small amount of existing program impact due to feature, protocol and data model changes. The impact will be small because both system capabilities are already similar.

There will be some impact to the existing ModSAF community unless ModSAF remains unchanged. The impact will be much less with this option when compared to starting with CCTT SAF system capabilities since this work is based on ModSAF.

The PO and SEOD merger is going to be very useful to the existing ModSAF development community.

There is a medium level impact to the existing CCTT program because there is a significant amount of work required to meet the requirements of CCTT SAF.


This is not as easily adaptable as it could be because duplicate protocols need to be supported which requires twice the maintenance.

C- 58

Appendix C - Migration Assessments ADST-II-CDRL-ONESAF-9800101 System Assessment Option 2 MAY 8,1998

Taking the best features of both systems makes OneSAF testbed very adaptable to new technology.

Cost

The cost for this approach is more than the cost of just settling with one of the existing ModSAF PO or CCTT SAF SEOD protocols. It is probably the least cost when considering merging the two protocols together.

C- 59

Appendix C - Migration Assessments Synthetic Natural Environment Assessment


C. 3 Synthetic Natural Environment Assessment

Synthetic Natural Environment (SNE) Analysis

Introduction

This analysis covers the OneSAF testbed Synthetic Natural Environment. Two possible approaches for forming a union of CCTT Environment and ModSAF Environment capabilities are described, as well as a number of issues common to both. A quantitative analysis is provided, as well as supporting documentation on functionality differences, assumed SNE scope, and CCTT interoperability.

The analysis conclusion is that ModSAF environment software should be the starting point for OneSAF testbed SNE.

Criteria Assessment

The following table summarizes the criteria and the definition of low, medium, and high rankings. Rankings are provided for each criteria. The number of criteria at each rank is provided in the "Risk Ranking" row.

A quantitative evaluation is provided by assigning a score to each criterion. Higher ranking values are better (less risk)

This analysis shows significantly better score (lower risk) for the ModSAF baseline approach. In fact, with the given rankings, the CCTT Baseline approach would rank higher only if "Existing Program Impact" (namely, CCTT Interoperability) were deemed more important than all other criteria combined. A detailed justification for each ranking follows.

Criteria Low(l) Medium (5) High (10) Migrate Migrate within CCTT within

Baseline ModSAF Baseline

Technical The The technical The technical Feasibility technical feasibility is feasibility is Risk feasibility good but the poor. The 8 3

is rated migration migration is very good. involves some

very difficult technical issues.

technically very difficult or the approach has never been tried before.

Program Risk There is There is a The migration little risk moderate risk approach is very 7 3 of the of the risky and has migration migration never been

C- 60

r-^^.^^^^—^^^^ —

Appendix C - Migration Assessments ADST-II-CDRL-ONES AF-9800101 Synthetic Natural Environment Assessment MAY 8,1998

approach approach attempted before.

Impact to existing The The approach The approach 5 3 ModSAF user approach has some has many community has

virtually no impacts to the existing programs

impacts to the existing programs that could be over come with moderate effort

impacts and or the effort involve in over coming the impacts are very large or technically challenging.

Impact to existing The The approach The approach 5 2 ModSAF approach has some has many development has impacts to the impacts and or community (e.g., virtually existing the effort involve STOW) no impacts

to the existing programs

programs that could be over come with moderate effort

in over coming the impacts are very large or technically challenging.

Impact to existing The The approach The approach 5 8 CCTT program approach

has virtually no impacts to the existing programs

has some impacts to the existing programs that could be over come with moderate effort

has many impacts and or the effort involve in over coming the impacts are very large or technically challenging.

Impact to current The The approach The approach 5 8 CCTT approach has some has many development (e.g., has impacts to the impacts and or FBCB2) virtually

no impacts to the existing programs

existing programs that could be over come with moderate effort

the effort involve in over coming the impacts are very large or technically challenging.

Adaptability to new The The resulting The resulting 5 3 technology Risk resulting

infrastruct ure or environme nt can be

infrastructure does not support extension and will require

infrastructure is not unified and should be completely redisigned to

C- 61



easily extended

modifications to support modification.

support extensibility.

Cost 132mm 103mm


The CCTT baseline option is rated as '8' for the technical feasibility primarily due to the need to convert CCTT Ada software into C, which would certainly introduce bugs into the primitives of the implementation. Also, the wide breadth of ModSAF capabilities that would have to be assimilated into the CCTT Environment structure means that the majority of the capabilities of both systems would be rewritten or at least modified.

The ModSAF baseline option is rated as '3' for technical feasibility since the existing STOW capabilities cover a significant portion of the CCTT Environment capabilities and the ModSAF system is already implemented and tested in C. The risk of integrating a ModSAF - derived OneSAF testbed SNE into the CCTT system is covered separately.

Program Risk

The CCTT baseline option is rated as '7' because of the expected conversion to C, as well as the need to move a tremendous breadth of ModSAF/STOW capabilities into the CCTT structure.

The ModSAF baseline option is rated as '3' because the majority of CCTT capabilities are already available or are low cost to add. This leaves plenty of time and resources to directly address the only high-risk item identified for the ModSAF option, namely CCTT interoperability.


The CCTT baseline option is rated as '5' for its impact to ModSAF. Most of ModSAF's users are fairly flexible in terms of requirement specifications (if any). It is likely that the greatest impact would be to the industry-wide knowledge base on ModSAF's structure which would be sharply altered if using the CCTT Environment interface / architecture. Although the CCTT baseline approach may suffer instability due to the volume of code that would have to be re-engineered, this risk is covered under Technical Risk.

The ModSAF baseline is scored as a '3' for its impact to the existing community based on the incorporation of a new environment format. However, the overall impact should be minimal. The impact to the future development of ModSAF is scored as a '2' due to its correlation to the existing development. The impact to the CCTT community is scored as an '8' since the underlying language and representation will be changed. Because the analysis did not isolate a specific area that appeared unsolvable, this ranking could have been medium. However, a number of lesser issues, ranging from database generation from an Evans and Sutherland source to correlation with a different Environment representation within the CCTT system provide the possibility of problem areas. The largest risk here is not

C- 62

Appendix C - Migration Assessments ADST-II-CDRL-ONESAF-9800101 Synthetic Natural Environment Assessment MAY 8,1998

with the capability or flexibility of the ModSAF Environment representation, but rather with the stringent demands and requirements of CCTT (including extensive integration testing, and many person years of low-level, minor coding "tweaks" to support integration with other system components or to match a user request). ModSAF has never been involved in such extensive testing where an overriding consideration was meeting the needs of a specific program.


The CCTT baseline option is rated as '5' in adapting to new technology. Although the CCTT Environment structure is tightly aimed at a CCTT system solution, it does provide one of the essential elements for a strongly layered, composable system. Specifically, CCTT has a strong interface that fully hides implementation details from view (i.e. it would be relatively easy to replace the implementation behind the interface). This strong interface structure will serve CCTT well if it is decided to use the OneSAF testbed SNE software on all CCTT nodes, because the Ada interface can remain the same while replacing the database primitives underneath. The CCTT baseline does suffer from two negatives relative to ModSAF: its flexibility is unproven and it would require the addition of a second layer of interface structure behind the external interface to achieve the granularity of functional division that ModSAF's libraries exhibit.

The ModSAF baseline option is rated as '5' in adapting to new technology. ModSAF's strengths are a proven track record in uses ranging from SIMNET-D sites to extensive and varied research efforts. The ModSAF baseline suffers a number of potential negatives for support across many user domains, especially "production" oriented uses; these negatives are derived from ModSAF's history as an open, research-oriented system. Little software engineering process has been applied to ModSAF (although much of it is well documented via "info" files); this has allowed developers to do what "makes sense" to them with little controlling influence from a validation or end-user perspective. ModSAF has received little system-level testing with an end objective beyond the demonstration of new technology; this means that problems that have proven annoying in the past may become major issues when faced with rigorous demands for performance and functionality. The range of contributors to ModSAF leads to a hodge-podge of libraries with no easily discernible hierarchy or relationship (e.g. libaeenviron vs libenvironment); this may lead to problems with composability and maintainability. Perhaps most important, the need to keep the architecture as open as possible has lead to interfaces which are often tightly bound to the underlying implementation. This is true even in cases where a part of the interface is abstracted away, other routines in the same header file can bind a caller to the library's implementation.

Cost

The CCTT baseline option is rated as having high cost risk because of the volume of development and re-engineering required. Since the CCTT baseline was designed to match the needs of a specific system, it is risky to assume that its structure can be extended to include the full breadth of ModSAF/STOW capabilities. Because the required up-front development effort, there will be little calendar time available to deal with unforeseen issues.

C- 63

Appendix C - Migration Assessments ADST-II-CDRL-ONES AF-9800101 Synthetic Natural Environment Assessment MAY 8, 1998

The ModSAF baseline option is rated as having low cost risk because the majority of CCTT capabilities are already available or are low cost to add. This leaves plenty of time and resources to address unforeseen issues. The ModSAF baseline cost risk would have been Medium if existing program impact were not a separate criteria.

Recommendation

The "ModSAF as Baseline" approach is selected for OneSAF testbed Synthetic Natural Environment.

Because the only high risk item with the selected approach was identified as CCTT Interoperability, a more detailed discussion of this issue follows. The remaining sections provide supporting information on differences between CCTT and ModSAF, plus the portions of each system considered part of OneSAF testbed SNE.

CCTT Interoperability

Common Software

For interoperability purposes, it would be ideal if the OneSAF testbed SNE software could replace the existing Environment CSC software (by leaving the current Environment CSC interface in place and replacing the implementation behind it). If this is not practical for programmatic / cost reasons, then the run-time differences between the OneSAF testbed database representation and the Environment CSC would have to be analyzed for impact on correlation, fair-fight, and consistent functional results. Since some portion of the CCTT Environment software is used on every CCTT run-time component, the effort to conduct correlation and interoperability experiments may exceed the cost of integrating the OneSAF testbed SNE implementation.

If the OneSAF testbed SNE representation were to be used, an Ada-to-C wrapper layer would have to be added, which would include the ability to convert from OneSAF testbed types/interfaces to CCTT types/interfaces. Also, an additional analysis would have to be conducted to cover all interfaces / capabilities required by other CCTT components but not OneSAF testbed.

Production System Hardening and Integration "Tweaking"

The final OneSAF testbed system must be fully integrated into the CCTT system, which will likely mean extensive testing and discovery of problems or issues that would not have been uncovered given the typical uses of ModSAF.

Besides extensive low-level and system testing and hardening, an extensive effort will be requiring in fine-tuning the OneSAF testbed capabilities to the user needs of CCTT. It is estimated that the CCTT Environment team invested over 5 person years of effort after development completion on modifications and extensions besides bug fixes. The majority of this was in short-term movement control and reaction to source data errors or omissions for database generation. But the rest ranged far and wide: altering terrain geometry from source

C- 64

to avoid flipping modules on shoulders leading into wadis; new functionality supporting specific CGF units/behaviors; specialized collision capabilities for manned modules; altering mobility mappings based upon system needs such as what is visible on the PVD and/or visuals; fine-tuning dimensions of fighting positions, AVLBs, etc. to match the performance/maneuvering/collision of the modules as well as the visibility of the human trainees; database-specific filtering (e.g. of bushes in P2); database-specific optimizations (e.g. aggregate models); tweaking dynamic terrain placement routines such that the corresponding visual representation is easily seen; specialized support routines for primitive planning around relocatables (fighting position occupancy, automated exiting from vehicle defilades); supporting case-by-case user input on most major routines (e.g. many specific cases on what does or does not block a minefield breach lane based upon nearby entities, obstacles, approach angle, proximity of other breaches, etc.).

Regardless of the baseline selected, a new Environment (and SAF) implementation will expose the developers to the aforementioned integration issues, even those which have never been discovered or addressed before.

Database Generation

Regardless of the baseline approach selected, OneSAF testbed Environment should investigate solutions for database generation that do not use or rely on the "SIF++" files generated by Evans and Sutherland for CCTT. Instead, a more direct data extraction from E&S tools or, preferably, SEDRIS should be considered as replacements. Regardless of how this problem is approached, database generation is likely to be the second most costly part of integrating OneSAF testbed SNE into CCTT (second only to stability and integration effort).

Dynamic Terrain

The dynamic terrain network protocol in CCTT was aimed specifically at solving CCTT needs and is tightly coupled to the capabilities of CCTT systems (especially the visuals). As a result, OneSAF testbed will not use the CCTT Environment protocol as its native/preferred representation. CCTT Interoperability will thus require some form of gateway or conversion between CCTT's Environment Manager and the OneSAF testbed SNE capabilities. This could take place between servers (i.e. DTSim <-> Environment Manager), at the network object level (i.e. translation of CCTT PDUs to OneSAF testbed SOM), as a part of OneSAF testbed itself (i.e. a built-in capability to receive and interpret CCTT Environment PDUs), or by replacing the CCTT Environment Manager capability with OneSAF testbed's server (which would be capable of generating CCTT and OneSAF testbed network representations). Any mechanism selected must accommodate CCTT's use of unique identifiers and the visual-system derived geometry and state limitations (e.g. linear segments in multiple of 30, with breachlines possible a predefined locations).

PVD

The CCTT PVD had a specialized database to meet requirements for redraw time and for map-like displays. This included explicit storage of different levels of detail, thinning, altering geometry where required for map display (e.g. showing rivers at a standard width),

C- 65



adding labels, off-line calculation of contour lines, etc. Any differences between the OneSAF testbed and CCTT GUIs will introduce additional training overhead and could result in a different "look" to the 2D display of the terrain. Depending upon the approach selected for OneSAF testbed GUIs as well as CCTT integration requirements, the OneSAF testbed SNE could be required to match the functional/display characteristics of the CCTT PVD, generate a CCTT PVD format database, or generate a dedicated OneSAF testbed PVD database to directly replace some or all uses of the CCTT PVD.

Other Databases / Unexpected Issues

The radio database may need to be generated via the OneSAF database process or replaced with equivalent capabilities, if all other terrain generation capability of CCTT is replaced.

Because the Environment CSC and PVD CSCI are used across all components of CCTT in differing ways, it is very likely that a number of unexpected uses or tight dependencies have been built between these components.

Cost Details and Comparison

The following table provides the cost estimate for each option. Note that the estimates are sometimes the same for both options (e.g. database generation). This is because the resultant C implementation would be handled much the same way regardless of the baseline chosen for the remainder of the OneSAF testbed SNE development.

Descriptions for each of the line items follows the tables....

CCTT Baseline ModSAF Baseline Convert to C 50k lines * 80/day = 4 pm N/A CCTT Capabilities- >ModSAF

♦ Detailed differences search

♦ Interface Level ♦ Primitives ♦ Weather / Effects

N/A 11 pm

1 pm 3 pm 4 pm 3 pm

ModSAF Capabilities -> CCTT

♦ library restructure plan ♦ libCTDB/ICTDB/

DTO ♦ DVW ♦ Reasoning ♦ Other

29 pm

3 pm 12 pm 5 pm 5 pm 4 pm

N/A

OneSAF testbed Development

3 pm 3 pm

C- 66

Appendix C - Migration Assessments ADST-II-CDRL-ONESAF-9800101 Synthetic Natural Environment Assessment MAY 8, 1998

DB Generation Code/Test 16 pm 16 pm

♦ Detailed differences .5 pm .5 pm search .5 pm .5 pm

♦ Obstacle boundary 6 pm 6 pm reconst. 3 pm 3 pm

♦ Cut and fill (source 4 pm dev / 2 pm test 4 pm dev / 2 pm test dependent)

♦ CCTT source spec. cases

♦ SEDRIS source use DB 6 pm 6 pm Generation/Integration for PI and P2 ModSAF baseline issue N/A 8 pm (+ 5-21 pm investigation (execution execution) after investigation min- max)

♦ Routing DB generation 2 pm (+2-8) ♦ O/A Linkage use) 1 pm (+0-5) ♦ Structure I/F 1 pm (+0-2)

investigation 3 pm (+2-4) ♦ Near term planning tests 1pm (+1-2) ♦ Better DT memory

mgmt CCTT baseline issue 12 pm (+8 - 31 pm investigation execution)

Difficult to estimate before library restructure plan;

assume 1.5 * ModSAF case. CCTT Interop 14 pm - 16 pm 17 pm - 20 pm Development

3 pm dev / 3 test — or ~ 5pm dev / 4 test - or~ ♦ No Common Reuse -or- 1 pm dev / 3 pm test 2 pm dev / 4 pm test ♦ Common Reuse 3 pm 3 pm ♦ DT translator 2 pm 2 pm ♦ Specialized DTSim 3 pm 4 pm

module 2 pm 2 pm ♦ Weather/Effects ♦ CCTT DB performance

and special cases ♦ PVD CCTT Integration 15 pm 18 pm

C- 67


Total 107 -132 pm 84 -103 pm

Convert To C represents the initial conversion of CCTT Environment Ada software into C. This task is not required for the ModSAF option.

CCTT Capabilities -> ModSAF covers the implementation of CCTT capabilities not covered by ModSAF for the ModSAF as baseline option.

ModSAF Capabilities -> CCTT covers the implementation of ModSAF/STOW capabilities not covered by CCTT. The subcategories represent major ModSAF areas at least partly unsupported by CCTT. The cost for the ground capabilities is so high because line-by-line integration of capabilities would be required with lots of potential for conflicting implementation decisions and test problems, especially given the fact that the CCTT implementation would have been freshly converted to C. DVW and DTO would largely replace existing CCTT capabilities and therefore would be more of a bulk conversion to fit under the CCTT architecture.

OneSAF testbed Development covers effort required to step OneSAF testbed SNE up to interface or architectural changes that result from the integration of components outside of SNE (e.g. merging of physdb and ECDI). It is assumed that other development areas cover their cost to adapt to SNE interface / structure changes.

DB Generation Code/Test covers all database generation system development and stand- alone testing. The cost is the same for both baselines since the ModSAF database generation software would serve as the starting point with either option. Cut and fill is costed high in case the source data does not have directly usable TINs (either reconstruction is required or raw polygons have errors). The use of SEDRIS as a data source is estimated under the assumption that the existing SEDRIS-to-CTDB implementation is available for our use, plus a usable SEDRIS version of Primary 1 and Primary 2 is available prior to the SEDRIS development effort.

DB Generation/Integration covers direct effort to build, test, integrate, and repair CCTT Primary 1 and Primary 2 databases. Estimate includes some effort for specialization of database test tools, manual and automated self consistency check, as well as manual correlation tests against source visuals. Testing of these databases from the perspective of the ModSAF user is covered as well. However, problems caused directly by database density (including cut&fill density) are not covered. These problems may range from short-term movement control to performance (some of this is covered under CCTT Interop).

ModSAF Baseline Issue Investigation covers detailed investigation of a number of issues uncovered during our analysis. Each of these issues was too involved to reach a quick conclusion during this analysis effort, but was recognized as having a large potential for impacting the development. The estimate is shown as: A+(B-C), where A is the effort required to conduct a detailed study of the problem and decide on a development approach, while B-C represents a rough estimate of the min/max effort based upon the study results.

C- 68


♦ Routing database generation has the greatest possible impact depending upon what source data is available and how many problematic cases from the CCTT databases are already handled by the ModSAF database generation process.

♦ Obstacle Avenue linkages represent a concept CCTT implemented which avoided a number of problems encountered by ModSAF. If deemed useful, it should be fully integrating into the OneSAF testbed compilers, low-level representation, and short-term planners.

♦ Structured I/F investigation includes a study of ModSAF's current interface structure to see if elements of the CCTT approach would provide better encapsulation and support for future development.

♦ Near-term planning tests covers a parallel implementation and comparison of the ModSAF vs CCTT path planning capabilities. Entity-level movement is so critical to SAF success, that the analysis phase is given plenty of time.

♦ Better DT memory mgmt is intended to consider mechanisms to avoid locking an entire patch in memory when modified as a result of dynamic terrain changes. This approach may prove problematic in large CCTT exercises with hundreds of relocatables.

CCTT Baseline Issue Investigation represents the CCTT baseline equivalent of the preceding task. Because of the apparent shotcomings of the CCTT approach, this cost was not fully investigated. For purposes of this comparison, we assume the cost is roughly 1.5 times the ModSAF baseline investigation task.

CCTT Interop Development represents effort focused on connecting OneSAF testbed to the CCTT system. Some of this software would be more part of CCTT production than part of OneSAF testbed itself. See the section on CCTT Interop Issues for more details.

♦ No Common Reuse / Common Reuse: if the OneSAF testbed SNE implementation must correlate with both visuals and Environment CSC, additional cost is levied due to extra correlation tests and database generation software modification. If OneSAF testbed SNE replaces Environment CSC, then cost covers Ada-to-C bindings and integration testing specific to different CCTT components. Because this is an "OR" option, the total for this section is shown as a range.

♦ PVD is not costed pending better resolution of what is needed. See "Issues/Variables", below

CCTT Integration covers lab test time, test team support, PTR repairs, minor tweaks for customer issues, test tools, new development to support other integrators, bug tracing to SNE boundaries, and may even include modifications to CCTT software (e.g. if Environment CSC is still part of the system). Because the CCTT baseline option starts with a conversion to C, the difference between the two approaches is not very large.

Issues/Variables: ♦ Will CCTT common code be replaced with OneSAF testbed SNE? Both ways costed for

SNE only? ♦ What are the requirements for interop with CCTT PVD? Must OneSAF testbed look the

same? Will OneSAF testbed PVD replace CCTT's? Will we need to maintain correlation between CCTT and OneSAF testbed database generation systems for the

C- 69


PVD? Should we directly build a CCTT PVD database from the OneSAF testbed database generation system?

♦ What format will PI and P2 be available in, if not SEDRIS? What is the cost of having a third party create and maintain SEDRIS databases, including repairs as needed?

Assumptions: ♦ Costs cover effort required to coordinate SNE internal design, interfaces, implementation,

test, etc. Estimates do not cover status reporting, metrics, process execution, documentation (beyond the level of ".info" files), execution of formal process, etc. It is assumed these costs will be added based upon an LOE multiplier or based upon delivered SLOC across the system.

♦ Effort does not include extensive coordination across or travel to multiple development sites. It is assumed tools / cost for this is covered separately across the system.

♦ Cost for OneSAF testbed "standalone/system" integration is covered via delivered SLOC or some other global estimation, not included in SNE estimates.

♦ Other development teams include their own cost to adapt to OneSAF testbed interface changes.

♦ Besides stated assumptions, no sequencing or calendar-time considerations were included.

♦ SEDRIS-to-CTDB compiler is available from SEDRIS research projects and SEDRIS source for PI and P2 is available.

♦ Supplied SEDRIS PI and P2 will be repaired by producer when source data problems are discovered.

♦ If OneSAF testbed SNE doesn't replace Environment CSC throughout CCTT system, the cost provided assumes that some problems will be accepted and/or are unsolvable. Cost covers "good" correlation, not perfect.

♦ Database generation costs cover generation of the equivalent capabilities of the following CCTT databases: MrTDB, MrsTDB, EMTDB with the exception that full MrsTDB capabilities supported is determined under "ModSAF baseline issue investigation: routing DB generation). The CCTT PVD and radio databases are ignored. Also, estimates assume that there is no dedicated PVD database, except for thinned CTDB format.

♦ SNE plans for 3 pm of investigation/comparison between ModSAF and CCTT near-term movement control approaches. It is expected that behaviors will have a similar effort which would tie-in.

Supporting Material: Functionality Differences

The following information was generated during the OneSAF testbed Environment analysis effort to search for issues, problem areas, and differences between the CCTT and ModSAF Environment capabilities. While this is not intended to be an exhaustive, fully annotated list of all implementation differences, it is an excellent starting point for such a list.

This section includes the following: ♦ a summary of major issues that are known to require additional investigation. Most of

these issues impact both proposed approaches.

C- 70


• a list of issues with CCTT Interoperability which bear further investigation • a list of weather / effects differences • a detailed breakdown of the CCTT Environment interfaces (not including PVD) and their

counterparts in ModSAF. This information lead to the conclusion that ModSAF supports the majority of CCTT capabilities at an interface level.

• finally, a laundry list of possible differences provided largely without supporting information. The analysis effort did not allow for further investigation of the differences, but they are provided as useful information for the next phase of OneSAF testbed

General Issues

Following are some issues that will deserve front-end additional analysis as part of the OneSAF testbed project. Most of them will be influenced by the decisions of other OneSAF testbed development areas.

OneSAF testbed Development Impacts

Regardless of the baseline chosen, the SNE interface will change a least a little to accommodate the union of CCTT/ModSAF capabilities, so other OneSAF testbed developers will have to evolve with this changes. Likewise, all users of OneSAF testbed will be evolving their own areas, possibly requiring changes to existing interfaces and even introduction of new capabilities / interfaces to accurately reflect the new OneSAF testbed structure and capabilities. Obviously, these changes are difficult to cost in advance except as a project-wide estimate of interface upgrading.

The interface structure and style of Environment CSC vs the related components in ModSAF is often very different. ModSAF generally provides more low-level access with greater granularity, while Environment CSC provides a more abstract interface covering all inputs / outputs through a single set of Ada specifications. OneSAF testbed development should include an upfront analysis as to which style to adopt (independent of the chosen baseline), with an eye toward supporting future OneSAF testbed. It is the author's opinion that a stricter, explicitly hierarchical interface (i.e. enforced via subdirectories) will better serve OneSAF testbed objectives.

Environment CSC / ModSAF Differences

• Routing database generation and run-time use • Different approach to entity-level path planning • Different approaches to database components (CCTT compilers have flow control and

call common read API; ModSAF front-ends have flow control and call a write API).

Weather / Effects Differences

This sections describes the CCTT / ModSAF Weather and Effects differences from the perspective of supporting CCTT capabilities within ModSAF's DVW architecture.

Tactical Smoke:

C- 71


ModSAF supports tactical smoke based on the Army Research Lab's COMBIC model. COMBIC is a physics based obscurants model that includes diffusion, buoyant rise, and boundary layer models. ModSAF supports over 31 different smoke sources. Each evolves with time and is effected by weather conditions. Smoke opacity varies with location in the smoke plume and with time. CCTT appears to represent smoke by switching through 5 discrete representations (size and opacity) over time, under the control of the Environment manager.

Illumination

CCTT support discrete illumination states. For example, lunar illumination may be: None, Starlight, Halfmoon, Full Moon). ModSAF supports continuous, geospecific illumination based on the Army Research Lab's ILUMA model. ModSAF provides both direct and diffuse components of illumination.

Weather and Clouds

ModSAF supports 3 spatial weather models (uniform, observed, and gridded). Variable rates of snow and rainfall are supported. CCTT supports only the equivalent of ModSAF "uniform" weather. Limited parameters support haze, fog, clouds, and rain and rain-soak state.

Flares

CCTT aggregates flares to keep the IG load within system limits.

Interface Differences

Area Intervisibility CCTT: Area_Intervisibility and Initialize_Area_Intervisibility_State ModSAF: ctdb_point_to_point() and libtdbtool DESC: Computes intervisibility from a point to an area. NOTES: Libtdbtool calls ctdb_point_to_point() multiple times over an area to provide the user with an area intervisibility tool.

Awareness State CCTT: Clear, Object_State, RemoveObject, Update_Object_State ModSAF: Near-term movement planning (movemap) is updated by vterrain. All dynamic obstacles are updated immediately after the obstacles change state. The cross-country route planner, routemap, recognizes dynamic bridges, albeit not on a per-vehicle basis; all vehicles are instantaneously aware of dynamic bridges, regardless of side or proximity. Also, the cross-country route planner does not currently recognize minefields (although movemap does). DESC: Used to keep track of dynamic terrain features that are relevant to route planning, such as dynamic bridges (AVLBs)

C- 72



and minefields.

Collision Detection CCTT: DetectCollisions ModSAF: ctdb_find_ground_intersection() DESC: Used to find intersections of terrain features, vehicles, and/or the terrain skin with an arbitrary ray. NOTES: CCTT's version returns lots of information about the intersected object. ModSAF's version only returns the type of intersected object and its location. If the user desires more information, s/he can access it via libCTDB's feature extraction API.

Cover and Concealment CCTT: Initialize_Search_State

Location_Is_Hidden Search_For_Concealment Search_For_Cover SearchForForestedLocations SearchForHide Search_For_Hide_Fire_Positions Search_For_Outside_Forest_Locations

ModSAF: tr_search_for_cover() tr_search_for_concealment() tr_search_for_hide_pts()

DESC: These routines search for covered, concealed, or hidden locations. NOTES: Search_For_Forested_Locations can be done in ModSAF by first performing a search for concealed locations and then using ctdb_point_within_abstract() to determine whether the point is "forrested."

Dynamic Environment CCTT: Update_Prepositioned and Update_Relocatable ModSAF: ctdb_create_linear_feature()

ctdb_modify_linear_feature() ctdb_delete_linear_feature() ctdb_create_volume_feature() ctdb_modify_volume_feature() ctdb_delete_volume_feature() ctdb_create_abstract_feature() ctdb_modify_abstract_feature() ctdb_delete_abstract_feature() ctdb_create_terrain_skin() ctdb_modify_terrain_skin() ctdb_delete_terrain_skin()

DESC: These routines modify dynamic terrain features. NOTES: The ModSAF functions listed form a superset of the functionality offered by the corresponding CCTT functions.

C- 73


Tactical Smoke State CCTT: Update_Tactical_Smoke ModSAF: libsmokesim - provides the handler for the ENV_SMOKE effect DESC: These routines create or update tactical smoke. EFFORT: Rewrite every invocation of these CCTT functions to use the ModSAF interface.

Database Extents CCTT: environment: Database_Extents ModSAF: wld_get_playbox_extent() DESC: These routines get the geographical extents of the terrain database.

Database Origin Info CCTT: environment: GetUtmlnfo ModSAF: wld_get_playbox_utm_data() DESC: Obtains information that DIS needs to perform transformations on coordinates.

Initialization CCTT: environment: Initialize and Initialized ModSAF: env_init() DESC: Initializes the environmental simulation software.

Shutdown / Caching CCTT: environment: LookaheadRegions, Reset, Shutdown ModSAF: no corresponding functions DESC: These are administrative functions not required by the ModSAF environmental software.

Weather / Ambient Conditions CCTT: environmentaleffects: Get_Natural_Conditions, Get_Natural_Conditions_Numeric, Set_Natural_Conditions ModSAF: libenvconstant DESC: These functions are used to set the values of the following environmental parameters:

rain state, visibility range, haze state, haze visibility range, haze ceiling, fog state, fog visibility range, fog ceiling, cloud state, cloud ceiling, cloud base, cloud visibility range, lunar illumination, temperature, humidity, wind speed, rain soak

NOTES: ModSAF's libenvconstant provides a set of values for every environmental phenomenon simulated by ModSAF:

temperature, dewpoint, relative humidity, barometric pressure, wind velocity, precipitation type, precipitation rate, extinction type, extinction amount, extinction coefficient, ray visibility, visual range, illumination, sky over ground, cloud cover, cloud ceiling, cloud height, cloud type, sim time, sun position, moon

C- 74


position, moon phase, contrast, solar illumination, lunar illumination, sky illumination

Line of Sight CCTT: line_of_sight: Get_Entity_Visibility

lineofsight: Get_Obstacle_Visibility line_of_sight: Get_Point_To_Area_Visibility

ModSAF: ctdb_point_to_point() DESC: These functions provide intervisibility information between a point and an area, obstacles, or entities. NOTES: CCTT's "Get_Point_To_Area_Visibility" function maps directly to ModSAF's "ctdb_point_to_point()" function. The other two CCTT functions currently do not have ModSAF equivalents, although it would not require much effort to write them. They would simply call existing libctdb functions which have the necessary functionality. The new functions would essentially use existing libctdb functionality and mimic the interface of the CCTT functions.

Munition Flyout CCTT: munition_flyout: Munition_Flyout ModSAF: ctdb_find_ground_intersection() DESC: Returns information about where the specified line segment intersects the ground, terrain features, and vehicles. EFFORT: Rewrite every invocation of these functions to use the ModSAF interface.

Near-term planning support CCTT: obstacle_avoidance_map: Create

obstacle_avoidance_map: Clip_Segment obstacle_avoidance_map: Get_Extents obstacleavoidancemap: Inside obstacle_avoidance_map: Reset

ModSAF: libvterrain DESC: This is the code that creates the per-vehicle obstacle avoidance maps. This is handled by libvterrain in ModSAF and it has no public interface. EFFORT: none, provided we use ModSAF's method of keeping track of the local obstacle space (namely vterrain)

RWA Landing CCTT: obstacle_avoidance_map: Find_Clear_Landing_Point ModSAF: tr_search_for_landing_positions() DESC: Finds the location(s) of clear landing spots within a specified search area. The landing site(s) must be free of any terrain objects. NOTES: The CCTT version has an input parameter for a suggested location, while the ModSAF version does not. This should not be very difficult to add to ModSAF.

EFFORT: Rewrite tr_search_for_landing_positions() so that it takes a suggested location.

C- 75


OA Map Retrieval CCTT: obstacle_avoidance_map: Retrieve ModSAF: localmap_get_movemap() DESC: Retrieves the obstacle map for a given vehicle. EFFORT: none, provided we use ModSAF's method of keeping track of the local obstacle space (namely vterrain)

Breach Trafficability CCTT: obstacle_avoidance_map: Set_Funnel_Trafficability ModSAF: no corresponding function DESC: Tags a given obstacle as being immobile. This is used for vehicles, so that behaviors know if they are killed or disabled (and therefore essentially obstacles), or are just temporarily stopped.

NOTES: In ModSAF, an obstacle's velocity is attached to the obstacle's information, and the planner uses this. Theoretically, this functionality is already included in the ModSAF near- term movement planner.

Direct Path Creation CCTT: obstacle_avoidance_path: DirectPath ModSAF: no corresponding function DESC: Used by CCTT test programs to generate a path with obstacle avoidance turned off. NOTES: This is not a required function.

Flight Paths CCTT: obstacle_avoidancejpath: Plan_Flight_Path

obstacle_avoidance_path: Get_Agl_Points ModSAF: tr_contour_direction()

tr_contour_segment() tr_contour_desired_velocity()

DESC: Functions for the calculation of flight paths that follow the contour of the terrain without crashing into the terrain skin. NOTES: "Plan_Flight_Path" is a coarser version of "Get_Agl_Points." The corresponding ModSAF functions get the job done with one level of fidelity.

Near-term Planning CCTT: obstacle_avoidance_path: Plan_Path ModSAF: movemap_preplan_route() DESC: Plan a path through the terrain, avoiding obstacles. NOTES: ModSAF's version does not return a list of blocking obstacles if the plan failed. If CCTT behaviors really use this, it will have to be implemented in ModSAF.

Path validation CCTT: obstacle_avoidance_path: Validate_Path

C- 76


ModSAF: movemap_update() DESC: Called periodically to ensure the path is still valid (i.e. to make sure dynamically- placed obstacles don't make the path invalid).

Retrieve Bridges CCTT: prepositionedobject: GetBridgesInArea ModSAF: ctdb_next_abstract()

ctdb_bridge_info() ctdb_next_volume()

DESC: Obtains a list of bridges in a specified area. For ModSAF, bridges can be represented as abstract features with microterrain for the bridge decks, or as volume features (for destroy able bridges). NOTES: In order to make the interface nice and uniform, we may wish to write a function that will return all bridges, destroyable or not.

Entity Placement CCTT: regionalinformation: Find_Clear_Placement_Point ModSAF: no corresponding function DESC: Places a vehicle at the specified location on the terrain. If there is an obstacle at that location, then a search for a suitable location is made along a specified vector. NOTES: In ModSAF, intelligent vehicle placement for units is done by libformationdb, but there are no such checks done for individual vehicles. To write such a function should not be difficult.

Highest Post in Area CCTT: regionaMnformation: HighestPostlnArea ModSAF: no corresponding function DESC: Finds the (x, y) location of the highest elevation post in a given area. Microterrain is not considered. NOTES: There is currently no function in ModSAF to do this, but writing one would be trivial.

Point Off Road CCTT: regionaMnformation: Point_Off_Road ModSAF: no corresponding function DESC: Computes a point normal to the current road segment at a specified distance away. NOTES: There is currently no function in ModSAF to do this, but writing one would be trivial.

Region Classification CCTT: regionalinformation: RegionalClassification ModSAF: no corresponding function DESC: Provides a classification of the type of area around the supplied location. Possible return values are RegionOpen, Region_Woods, and Region_Urban.

C- 77


NOTES: There is currently no function in ModSAF to do this. Writing one would not be very difficult.

Defilade Exit Point CCTT: relocatable_object: FindDefiladeExitPoint ModSAF: ctdb_get_next_abstract() DESC: Returns the exit point for a fighting position object. NOTES: This information is available in the abstract data for a fighting position feature in ModSAF.

Retrieve Breaches CCTT: relocatable_object: GetBreachObjects ModSAF: no corresponding function DESC: Returns the relocatable objects breached by or breaching a given object. NOTES: This can be achieved in ModSAF via a pbtab search (to find the breachers) or via ctdb_next_abstract (to find the breachees).

Relocatable Object Retrieval CCTT: relocatableobject: Get_Relocatable_Object ModSAF: ctdb_get_next_abstract() DESC: Provides data on dynamic terrain objects; differences derive from storage and representation differences

Fighting Position Dimensions CCTT: relocatable_placement: GetDimensions

relocatable_placement: GetlnteriorDimensions ModSAF: ent_get_physdb() DESC: Gets the corresponding entity type of a relocatable object so its physical dimensions can be retrieved.

Movable Bridge Placement CCTT: relocatable_placement: PlaceBridge ModSAF: libubrdgbrch

libvposdeploy libvattach

DESC: Places a dynamic bridge across an obstacle on the terrain. NOTES: The code that does the checking to see if a given location is suitable for placing a bridge is contained within libubrdgbrch and is not public.

Not Investigated... CCTT: relocatableobject: Get_Smoke_Object

relocatableobject: Get_State relocatableobj ect: Give_Cc_Point_In_Fighting_Position relocatableobject: GivePointsInlnfantryFightingPosition relocatable_object: InFightingPosition

C- 78


relocatable_object: In_Infantry_Fighting_Position relocatable_object: In_Vehicle_Fighting_Position relocatableobject: ParallelpipedAroundRo relocatable_object: RelocatablelnsidePolygon relocatable_obj ect: Relocatables_In_Area

ModSAF: Mostly specialized variations of ctdb_get_next_abstract, some may require additional information be supported in CTDB or from a model library.

List of Functional / Representational Differences to Investigate

This list captures some underlying capabilities within the Environment CSC that may be different from ModSAF's implementation. Each of these will need to be investigated as part of the OneSAF testbed integration.

External Interface

Selectable tree trunk intersection for munition flyout Awareness state (for minefields) Maneuver_intent indicates whether a fighting position is an obstacle or an objective. Routing corridor widths (for bridges) Selectable road/cross/direct during throughout proposed route Use of handle for multi-level history Unit normal returned for height of terrain (MM only) Env CSC received entity information at interface (no use of DIS code) Env CSC provided geometry primitives plus general utilities for use by other CSCs

Functional support

Riverbed geometry for height of terrain (centerline linear problem) Trunk collisions Collisions with bridge/overpass sides (selectable via environment variable) Collisions with shoulders (steep terrain) (selectable via environment variable) Collisions account for "bumper height" (modules, by config file) Collision detection using full volumes Munition flyout hits span (and names it), span sides OA recognizes over/under for overpasses and bridges Generic map utility (used for placement, OA, etc.) Tree trunks, foliage radius, foliage height and distance above ground used throughout All around "tweaking" for integration (visuals, modules, operators, behaviors, etc.)

Terrain (Storage / retrieval)

Validation header (byte-wise storage at beginning to verify file type, purpose, and endianness) Centerline linear reconstruction problems (roads for mobility/dust, wide rivers, riverbed geometries)

C- 79


Aggregate models with virtual gridmasks and plane equations for performance Patch-crossing bridges/overpasses (l=many and side representation) What happens when an abstract feature (like a fighting position) crosses a storage boundary? Or are abstract locations "global" with quadtree only as a referencing tool?

Routing

Verify storage includes a segment for each point to nearest obstacle? Overlapping obstacles (forest gap with spanning steep slope) Obstacle boundary reconstruction or use of primitive areals from source in compiler Verify simplification doesn't create errors (S-curves)

Example issue: obstacle part way up between two forests that overlaps both. • Can't draw from each forest to obstacle • Can't "not draw" because last segment on each side would imply trafficability between

Dynamic Modifications

Use of PO and RO ID's as unique identifiers issue with patch crossers?

Need to verify use / reaction of every relocatable object: • visual appearance • functional effect behind Environment interface • data exported via Environment interface • protocol encoding limitations (e.g. linear segment lengths) • CCTT breaches don't break one thing into two things • path planning (through and around, including fighting positions as obstacles and complex

destinations)

External callers given geometric and abstract view of data (e.g. outer boundary and C&C positions within).

Compilers

Ramps leading to spans...connection checks? We did all tree and building placement (Z value) Had to use "special" (non-visual) areals for terrain types Had to remove linears "underneath" bridges and overpasses Linear boundary reconstruction (esp. wide rivers) difficult Fighting position interior geometries "built" by compiler Obstacle/avenue linkages created (C&F through steep slopes, multi-level terrain, bridge over water, road over no-go) Region classes calculated based upon density parameters from config files. Forest boundaries reconstructed from aggregate instances. Basis set roads NOT available via source (not used)

C- 80


Spans are n-sided beasts, must search for entry and exit edges. Config file based mapping of terrain type number to "meaning" (road, water, deep, impassable) Can use E&S "microterrain" from source? Otherwise, reconstruct ground for abstract C&F. Can get forest boundaries as areals? Labels reconstructed from different source (not SIF) for PVD Intersection models overlap with surrounding cut and fill Configurable damage assessment per building model and span

Utilities / Test

GIDGET provides access to all external routines (include OA map, etc.), plus dumps raw feature data. Simple 2D display for debugging, plus VRML viewer for selected regions. Need to ensure that the comparable ModSAF tools support similar stand-alone test capabilities.

Supporting Material: Scope

General Description

The OneSAF testbed Synthetic Natural Environment (SNE) Assessment covers the following areas: • Terrain/Environment/Weather databases and their compilers • Software that operates directly on (or encapsulates) these databases • Software that provides an abstract answer based mostly on primitive data from

Terrain/Environment Databases • PVD display software only to the extent that it directly operates on and draws

Environment data. Includes contour lines, tactical smoke, etc. Does not include overlays, overall GUI design, non-environment entities, etc.

• All environment "servers" which manage the state of terrain, environment, weather

CCTT components

For CCTT, the provided definition of SNE includes all or part of the following CCTT CSCIs/CSCs. This list includes all things that could be part of OneSAF testbed SNE, even though some may be shared with other areas (e.g. behaviors, GUI) and/or may not be included in OneSAF testbed because they are not required by CCTT SAF. • Database API CSC COMMON DATABASE UTILITY

Provides a common API to retrieve database source information. Hides details of source data from compilers and provides selected database features based upon filtering regions. Includes capabilities common to multiple database compilers.

• SAF Terrain Compiler CSC DATABASE COMPILER Target database compiler that generates MrTDB and MrsTDB (for use by the Environment CSC), and EMTDB (for use by the Environment Manager CSCI).

• PVD Compiler CSC DATABASE COMPILER

C- 81


Target database compiler that generates the PVD database for use by the PVD CSCI. • Radio DB Compiler CSC DATABASE COMPILER

Target database compiler that generates the radio database for use in communications degradation. NOTE: Radio DB will probably not be part of OneSAF testbed, since it is not used / required by CCTT SAF.

• Environment CSC COMMON SERVICE Encapsulates representation of terrain/features. Provides wide range of operations (line of sight, collision detection, route planning, short-term path planning, cover and concealment, etc.). Used by almost all CCTT components.

• PVD CSCI COMMON SERVICE Provides graphical display of terrain in map-like form.

• Environment Manager CSCI CCTT APPLICATION Acts as "owner" of the CCTT Environment, by determine prepositioned object states and authenticating creation/modification of relocatable objects. NOTE: Environment Manager may not be part of OneSAF testbed.

ModSAF libraries

For ModSAF the provided definition of SNE includes all or part of the following libraries. This list includes all things that could be part of OneSAF testbed SNE, even though some may be shared with other areas (e.g. behaviors, GUI).

Terrain Database

• CTDB SHARED DATABASE SERVICE Represents underlying terrain, and provides services to determine visibility, collisions, surface orientation and soil type, elevations, etc., and support graphical displays of the geography.

• World: SHARED DATABASE SERVICE Responsible for management of collections of terrain databases and data structures associated with them.

Dynamic Terrain

• DTOConst: NETWORK DATABASE UTILITY Provides a database of DTO features and translations for the network.

• DTACTDB: SHARED ARCHITECTURE SERVICE Provides ability to recieve incoming ECNs and make the appropriate modifications to the CTDB.

• DTAgent: NETWORK MANAGEMENT SERVICE Process of validating incoming ECNs and firing of appropriate callbacks.

• DTSim: SIM MANAGEMENT SERVICE Provides Dynamic terrain simulation services

• ECN: NETWORK ARCHITECTURE SERVICE Provides the infrastructure for sending and recieving ECNs.

C- 82


• Repoly: SIM MANAGEMENT SERVICE Librepoly provides DTOPOLYDATA strutures and functions used to repolygonalize terrain.

• Obstacle: GUI ARCHITECTURE C20BJ Provides ability to create obstacles from a graphical user interface.

• Obstutil: SIM ARCHITECTURE C20BJ Utility library that handles generic creation of obstacles.

• DitchUtil: SIM COLLECTIVE UTILITY Provides common functionality for ditch entity processing.

• Bridge: SIM PHYSICAL UTILITY Bridge simulation utility functions.

• MSO: SIM PHYSICAL UTILITY Multi-state objects simulation utility functions.

Dynamic Virtual Worlds

EnvAtm: SIM ENVIRONMENT SERVICE Environmental model for atmospheric transmissivity.

EnvCloud: SIM ENVIRONMENT SERVICE Environmental model for transmissivity through natural sky water clouds.

EnvConstant: SIM ENVIRONMENT SERVICE Constant environment model.

EnvContrast: SIM ENVIRONMENT SERVICE Contrast environment model.

EnvDB: SIM ENVIRONMENT SERVICE Gridded Weather database model.

EnvDust: SIM ENVIRONMENT SERVICE Vehicle dust model.

EnvDustIV: SIM PHYSICAL UTILITY Vehicle dust intervisibility effect model.

EnvEnt: NETWORK ARCHITECTURE SAFOBJ Environmental Entity management.

Envlllum: SIM ENVIRONMENT SERVICE Illumination environment model.

Envlnit: SHARED ENVIRONMENT UTILITY A library for initializing other environmental libs

Environment: SIM ARCHITECTURE SERVICE A library for dispatching requests for environmental state to the appropriate handler.

EnvObsWx: SIM ENVIRONMENT SERVICE Observed Weather environmental model.

EnvSea: SIM ENVIRONMENT SERVICE Collection of simple sea models.

EnvSimple: SIM ENVIRONMENT SERVICE Collection of simple environment models.

Smklnt: SIM PHYSICAL UTILITY

C- 83


Determines intervisibility effects of obscurant clouds. • SmokeRdr: SIM DATABASE UTILITY

Accesses data related to obscurant clouds stored in reader format. • SmokeSim: SHARED ENVIRONMENT SERVICE

The main ModSAF interface to the COMBIC smoke model (works in conjunction with SmokeRdr and Smklnt.)

• Weather: SIM ENVIRONMENT SERVICE A simple networked weather distribution library. Uses EnvEnt, Environment, and SimReq.

• FlareSim: SHARED ENVIRONMENT SERVICE The main ModSAF interface to the signal flare model.

Modified to Use DVW / Possible SNE

These libraries were modified or developed via the DVW project. Some of these libraries may largely "belong" to other areas, such as behaviors or vehicle modelers, but impacted by DVW. • Waveresp - hull response and sinking • Visual • Tracked • Vtargeter - "Target DR" to estimate target position when obscured by own smoke • Seaedit - Ocean editor • Envgedit - Gridded Weather Editor (aka Hand of God) • Simreq - Utility library for load leveling smoke and flares over PO • Ssmk

Reasoning Libraries

• EnvAssess: NETWORK ARCHITECTURE SAFOBJ An environmental assessment functionality library.

• EnvReason: SIM ARCHITECTURE SAFOBJ Provides reasoning functions to take environmental effects into accounts

• TeReason: SHARED ARCHITECTURE UTILITY Terrain reasoning related utility functions.

Route Planing and Movement

• MoveMap: SIM ANALYSIS SERVICE Generates courses through space-time which achieve a specified goal without violating physical constraints or colliding with obstacles.

• LocalMap: SIM ARCHITECTURE SAFOBJ Creates and destroys one libMoveMap movement map per vehicle.

• Route: SHARED MANAGEMENT UTILITY Generic route manipulation routines.

• RouteMap: SIM ANALYSIS SERVICE

C- 84


Unit level planning service. • Collision: SIM PHYSICAL SAFOBJ

Detects collisions with terrain features and other network entities. • CollPred: SIM PHYSICAL SAFOBJ

Predicts potential collisions and calculates simple avoidance maneuvers. • MESRoute: SIM ARCHITECTURE SAFOBJ

Performs unit routing through Multiple Elevation Surface objects. • VMove: SIM INDIVIDUAL SAFOBJ

Individual-level task for vehicle movement. • VTerrain: SIM INDIVIDUAL SAFOBJ

Individual-level local terrain awareness task. • UTraveling: SIM COLLECTIVE SAFOBJ

Unit-level traveling task.

Map Drawing

• TactMap: GUI COMMAND SERVICE Tactical map display which includes terrain features and an arbitrary number of dynamically created lines, text, pixmaps, pictures (defined using a simple language), BGRDB icons, and application-drawn objects.

• PVD: GUI ANALYSIS SAFOBJ&SERVICE Provides a set of controls for tactical map display, defines map interaction modes (zoom, pan, info), stealth/preview controls, and updates positions of network entities on tactical map.

C- 85

Appendix C - Migration Assessments ADST-II-CDRL-ONES AF-9800101 Synthetic Natural Environment CCTT Baseline MAY 8, 1998

Environment Assessment: CCTT as baseline


The initial effort associated with using CCTT Environment as the OneSAF testbed SNE baseline would be conversion of the software from Ada to C. C is extensively used throughout the simulation community, and C++ is now the language of choice in many simulation production programs (e.g. the JSIMS family). While Ada would surely meet the functional needs of many users, the research community which has traditionally relied on ModSAF would certainly prefer C over Ada.

Because the CCTT Environment CSC was oriented towards meeting CCTT requirements while ModSAF Environment capabilities were expanded throughout STOW, the main focus of OneSAF testbed SNE effort based upon CCTT code would be to move the extensive ModSAF capabilities over into the CCTT Environment architecture.

Thus, the Ada-to-C conversion would be followed by a transfer of a significant amount of capability from ModSAF into the CCTT structure.


This approach would provide three benefits: 1) The extensive effort of refining the CCTT Environment software to meet the specific

demands of CCTT would largely be retained. However, some of the finer capabilities may inadvertently be lost in the translation to C.

2) The CCTT Environment CSC has a strong, localized interface which completely isolates SNE software from the remainder of CCTT. CCTT Environment doesn't even rely on network services. This strong structure would automatically be retained using this approach.

3) CCTT interoperability would be improved, but it would not be guaranteed because of the conversion to C and the inclusion of a wide range of new ModSAF/STOW capabilities.

Disadvantages of using the approach

The disadvantages of this approach are numerous. An obvious negative is the need to translate the existing Ada software into C. Perhaps 25% of the original CCTT Environment implementation started from a C-to-Ada conversion from an earlier ModSAF version. As a result, the final software would sometimes bear a strong resemblance to existing ModSAF code, but it will just be "freshly developed" and thus require extensive testing.

A second negative is that the CCTT Environment structure was designed to meet CCTT requirements and thus is not necessarily able to support the full breadth of Environment capabilities implemented in ModSAF for STOW.

The biggest disadvantage of this capability is the simple fact the ModSAF largely supports the capabilities that CCTT Environment does but the opposite is not true. Using CCTT as a baseline would mean that almost all software in the OneSAF testbed implementation will

C- 86

Appendix C - Migration Assessments ADST-II-CDRL-ONESAF-9800101 Synthetic Natural Environment CCTT Baseline MAY 8, 1998

have been converted from Ada or will have been restructured to fit under the CCTT Environment architecture. In contrast, using ModSAF as a baseline would provide a large, stable base of capabilities from the start, with point modifications as necessary to match CCTT capabilities and support CCTT interoperability.

Because the cost, effort, and stability disadvantages of this approach are so great compared to the ModSAF approach, the remainder of the description of the CCTT baseline approach is brief. Most analysis effort is focused on the ModSAF baseline option, CCTT Interoperability, and enumeration of differences between CCTT and ModSAF Environment software.


The CCTT baseline option would be risky from a technical standpoint due to the need to convert CCTT Ada software into C, which would certainly introduce bugs into the primitives of the implementation. Also, the wide breadth of ModSAF capabilities that would have to be assimilated into the CCTT Environment structure means that the majority of the capabilities of both systems would be rewritten or at least modified.

Program Risk


The OneSAF testbed SNE implementation that would result from a CCTT baseline option should meet most or all requirements levied separately on CCTT and ModSAF. However, full CCTT interoperability would not necessarily be guaranteed by this approach because of the conversion to C and incorporation of many new capabilities.

Performance

The initial Ada-to-C conversion of CCTT software would probably not perform as well as the existing ModSAF Environment capabilities unless a separate optimization step had been performed on the converted software (because a straight conversion does not necessarily mean comparable efficiency between languages).

Schedule

The CCTT baseline approach would require a significant amount of extra development. Schedule risk would be much higher for this option compared to the ModSAF baseline option.

Reliability

The CCTT baseline approach would be much less reliable than the ModSAF baseline option because of the sheer volume of software to be modified.

C- 87

Appendix C - Migration Assessments ADST-H-CDRL-ONESAF-9800101 Synthetic Natural Environment CCTT Baseline MAY 8,1998

Scalability

Both Environment options would have comparable scalability. As discussed elsewhere, the CCTT Environment interface may support a stronger boundary between SNE and consumers, while ModSAF's greater granularity of libraries and low-level access is more flexible.


Fair Fight

See the separate section on CCTT Interoperability for an overall discussion of this topic. While the CCTT baseline option would better support CCTT fair fight and correlation, these items would still be at risk due to the planned conversion to C and incorporation of new capabilities.

Correlation

While the CCTT baseline option would better support CCTT fair fight and correlation, these items would still be at risk due to the planned conversion to C and incorporation of new capabilities.


Because of the planned conversion to C, this option provides no particular benefit for CCTT baseline maintenance.

Database Generation

Because the ModSAF database generation process has been proven with more data sources (and supports capabilities like endianness and TINs), the CCTT database generation process would only be retained to the extent required to support CCTT software that is not replaced by new OneSAF testbed capabilities and/or CCTT compiler capabilities that are not supported by ModSAF's compilers.


The CCTT baseline option is rated as having medium risk in adapting to new technology. Although the CCTT Environment structure is tightly aimed at a CCTT system solution, it does provide one of the essential elements for a strongly layered, composable system, namely a strong interface that fully hides implementation details from view (i.e. it would be relatively easy to replace the implementation behind the interface). This strong interface structure will serve CCTT well if it is decided to use the OneSAF testbed SNE software on all CCTT nodes, because the Ada interface can remain the same while replacing the database primitives underneath. The CCTT baseline does suffer from two negatives relative to ModSAF: its flexibility is unproven and it would require the addition of a second layer of interface structure behind the external interface to achieve the granularity of functional division that ModSAF's libraries exhibit


C- 88

Appendix C - Migration Assessments ADST-II-CDRL-ONESAF-9800101 Synthetic Natural Environment CCTT Baseline MAY 8, 1998

No significant advantages / disadvantages for the CCTT baseline relative to the ModSAF baseline approach.


Detailed cost is not captured for this option because it is so apparent from the analysis that use of the CCTT baseline would be much more costly than the ModSAF baseline.

A rough description of the cost is as follows:

1) Cost to convert CCTT Environment-related capabilities from Ada to C (-50,000 lines of Ada)

2) Cost to move STOW capabilities from ModSAF architecture to the converted CCTT Environment architecture (unknown number of lines)

3) Cost to integrate libCTDB internal differences (endianness, TINs). 4) Cost to support ModSAF-based programs (e.g. STOW's TAOS)


None relevant to selection of approach.

C- 89

Appendix C - Migration Assessments Synthetic Natural Environment ModSAF Baseline


Environment Assessment: ModSAF as Baseline


This approach involves using ModSAF as the baseline and implement any differences between CCTT Environment and ModSAF Environment in the ModSAF baseline. The following capabilities will be maintained:

1) Representation of all of ModSAF's and CCTT's terrain features, including: microterrain buildings trees treelines tree canopies roads rivers craters ditches berms dragons teeth rock drops or point blocks wire road blocks concertina wire minefield fences single fences fighting positions bridges camouflage canopies rubble snow log crib abatis

2) 256 soil types 3) Both diagonalizations in a single grid 4) TIN topology 5) Earth curvature support 6) UTM support 7) unlimited maximum geographic extent (databases can span multiple UTM zones) 8) dynamic terrain, including dynamic creation, modification, and deletion of terrain features as well as modification of the terrain skin 9) forests represented as basis sets 10) simulation of the following environmental phenomena:

• temperature • dewpoint

C- 90

Appendix C - Migration Assessments Synthetic Natural Environment ModSAF Baseline


relative humidity barometric pressure wind velocity precipitation type precipitation rate extinction type extinction amount extinction coefficient ray visibility visual range illumination sky over ground cloud cover cloud ceiling cloud height cloud type sim time sun position moon position moon phase contrast solar illumination lunar illumination sky illumination

11) near-term movement planning 12) cross-country movement planning


Feature support by CTDB is a superset of those supported by CCTT SAF. CTDB format 1 and MrTDB were very similar in terms of functionality, but then they branched off and simultaneously evolved along separate paths because they were driven by different requirements. A few years later, however, in an effort to produce a common terrain database that was available in both MrTDB and CTDB formats (for a SAF interoperability exercise), features that MrTDB supported that CTDB did not support (i.e. basis sets and model references) were added to CTDB. At that point, CTDB's functionality became a superset of MrTDB's functionality.

After the CCTT Environment baseline approach was determined (by late 1994), CCTT engineers were unable to incorporate any ModSAF ideas. In contrast, ModSAF often

C- 91

Appendix C - Migration Assessments ADST-II-CDRL-ONESAF-9800101 Synthetic Natural Environment ModSAF Baseline MAY 8, 1998

purposefully or coincidentally incorporated changes that CCTT had made from the common baseline. A quick list includes:

Purposeful integration of CCTT/MrTDB changes into ModSAF:

♦ variable diagonals by post, not by database ♦ use of models (trees, buildings) including opacity by model (not global) and trunk

radius ♦ aggregate models for forests ♦ support for CCTT mobility codes, including wet mapping ♦ support for building CCTT databases ♦ development of an E&S to CTDB compiler

Coincidental (developed separately for CCTT and ModSAF):

♦ Feature retrieval engine ♦ Use of terrain type palettes ♦ Better approach to cut and fill than microterrain (i.e. TINS) ♦ Reintroductionofmin/maxZ by patch ♦ Full overpass/bridge capability (correct dynamic entity avoidance, LOS, etc.) ♦ More generic approach to dynamic terrain (fighting positions, tank ditches, etc.)

Thus, ModSAF has largely "kept up" with CCTT/MrTDB changes, but the opposite has not been true since around the time STOW (ICTDB) started.

ModSAF, primarily via ICTDB and other STOW work, has added a lot of functionality never in the CCTT baseline. The effort to move all of these capabilities to CCTT is much greater than moving CCTT into ModSAF. This is overwhelmingly true in the weather/ocean/effects area, but even the libCTDB side has some major additions including endianness, TINs, GCS, and an advanced soil attributes storage representation which allows the representation of an arbitrary amount of information associated with the terrain skin soil types, including FACC codes. ModSAF/STOW also added the representation of building interiors via MESs. This includes the representation of buildings with multiple floors, internal walls, windows, doors, and stairways.

Because CCTT Environment has a strong, localized interface and few dependencies on other parts of CCTT (this was required because it was used everywhere in CCTT), it will be much easier to clearly identify what it takes to replace the Environment CSC interface and capabilities. It would be harder to clearly delineate ModSAF's environment from the rest of the system (different interfaces for libenvironemnt vs libCTDB, libCTDB is used directly at a "primitive" level, dependency on DTSim for repoly, etc.).

Finally, ModSAF is in C, and thus is closer to the "right" language to use, namely C++.

Disadvantages of using the approach

C- 92

Appendix C - Migration Assessments ADST-II-CDRL-ONES AF-9800101 Synthetic Natural Environment ModSAF Baseline MAY 8, 1998

There are several components currently used with CCTT SAF that will still be used "as is" in the OneSAF testbed system (AAR, for example). These components will need to use the MrTDB representation of the terrain database. If the OneSAF testbed used CTDB, then in order for everything to interoperate properly, there must be perfect correlation between the MrTDB representation and the CTDB representation of a given database. This perfect correlation will be difficult to achieve because of the storage representation differences between MrTDB and CTDB. As an example, MRTDB stores cut and fill features as parameterized abstractions (i.e. bank slope, river depth, etc.). CTDB stores them as TINs. Therefore, cut and fills are almost guaranteed not to correlate. This issue is discussed more in the Cost and CCTT Interoperability sections.


There is very little technical risk involved in implementing this approach.

A small number of functions will have to be written in order to fill the gap between MrTDB's functionality and CTDB's functionality; the functions which exist in MrTDB's public interface will have to be imported or reimplemented in CTDB. However, these are few and far between.

Program Risk


This approach satisfies all of both SAFs' requirements. Obviously, it satisfies all of ModSAF's requirements because it uses the ModSAF code. It also satisfies all of CCTT SAF's requirements because ModSAF's representation and simulation of the synthetic natural environment is almost a superset of CCTT SAF's representation, and the differences will either be reimplemented in OneSAF testbed, or migrated from CCTT SAF into OneSAF testbed.

Performance

Performance of ModSAF's SNE code is likely higher than that of CCTT SAF, since ModSAF has undergone more concentrated performance improvements in libCTDB. There is, however, a potential that the ModSAF architecture may not satisfy the performance requirements of CCTT SAF. Currently, there is no way to evaluate this.

Schedule

Since this approach doesn't involve any new radical implementation methods that have never been attempted before, there is little schedule risk.

Using ModSAF as the baseline is much less risky schedule-wise than using CCTT SAF as the baseline because less functionality has to be moved.

Reliability

C- 93


The synthetic natural environment code will be as reliable as ModSAF's synthetic natural environment code, which has been proven to be very reliable. The STOW ACTD had an average of 10 hours uptime for Joint SAF during the 48-hour exercise, and ModSAF 4.0 is expected to be even more reliable.

Using ModSAF as the baseline will most likely be more reliable than using CCTT SAF as the baseline because it will involve far fewer changes, and the ModSAF baseline is stable and proven. Also, using CCTT SAF as the baseline would involve converting the ADA code to C code, which will likely introduce numerous errors.

Scalability

This approach has the same scalability characteristics as the current ModSAF; the size of database that can be handled depends on the percentage of the database that exists within physical RAM. The size of the terrain cache can be configured on the command line at startup. If the terrain cache is too small, excessive thrashing can occur while running cache- unfriendly scenarios. This thrashing can adversely affect system performance.


Correlation

Since this approach uses only the ModSAF SNE architecture and not a hybrid of both SAFs, there are no correlation issues to address in the OneSAF testbed product. There are, however, correlation issues with respect to interoperating with existing CCTT components which will not be affected by the unification.


No differences from CCTT as baseline option.

Database Generation

Because the ModSAF database generation process has been proven with more data sources (and supports capabilities like endianness and TINs), the CCTT database generation process would only be retained to the extent required to support CCTT software that is not replaced by new OneSAF testbed capabilities and/or CCTT compiler capabilities that are not supported by ModSAF's compilers.


Because ModSAF is intrinsically a research and development tool, it was designed to be extensible and to accept new technologies. Its architecture is flexible and proven. It is for this reason that basing the synthetic natural environments on ModSAF will result in the OneSAF testbed code being more extensible, since CCTT SAF was designed in order to meet specific requirements, it is not as extensible as ModSAF.

C- 94



The ModSAF baseline has been proven in heavy parallel development on many platforms. An integration facility has been developed to maintain a constantly changing baseline.

C- 95

Appendix C - Migration Assessments Physical Models Assessment Option 1


C.4 Physical Models Assessment

Physical Model Assessment: Option 1

Start with the ModSAF Baseline and incorporate CCTT modeis.


Start with the ModSAF physical model infrastructure, and incorporate the CCTT physical models on a case-by-case basis. Models will be converted from Ada to C. Wherever possible, a CCTT model and its corresponding ModSAF model will be unified. If the unification of two models is not possible, then they will exist separately in OneSAF testbed.

In transferring the CCTT models to the ModSAF infrastructure, the code will be modified to work with the ModSAF architecture while maintaining the CCTT specifications as described in the CCTT CGF Physical Model Design Document.


• Maintain the extensibility of the ModSAF architecture • Takes advantage of ModSAF's "Plug and Play" capability • Maintains the capabilities of both systems' models • The transferring of the implementation of the CCTT models facilitates the V&V process.

The V&V process would be more involved if starting from the CCTT model specification.

• The requirements on the ModSAF side are automatically satisfied.


• V&V would have to be redone for the transferred CCTT models. • Where the unification of models is not feasible, multiple versions of a model need to be

maintained. • Incorporating updated capabilities to a unified model tends to be costly. • The transferring of models from one infrastructure to another introduces risk:

1. In order to make a CCTT model "fit into" the ModSAF infrastructure, the hooks to the infrastructure may have to be changed.

2. Due to the differences in the runtime characteristics of the infrastructures, the models may have to be modified in order to make them more adaptable to ModSAF's runtime characteristics.


Due to the extensible nature of the ModSAF architecture, this approach carries very little technical risk.

C- 96

Appendix C - Migration Assessments ADST-II-CDRL-ONES AF-9800101 Physical Models Assessment Option 1 MAY 8, 1998

Program Risk

This section outlines the program risk for this option.

Incorporation of CCTT models into the ModSAF architecture is, for the most part, achievable.


Because of the strong similarities in the physical models architecture between CCTT and ModSAF (namely, common use of the "Generic Model Interface"), the CCTT software should be very amenable to straight translation with few difficulties. The primary difficulty will lie with breaking some of the larger CCTT capabilities/packages into smaller, separate components matching the library decomposition of ModSAF. For example, the tracked hull package in CCTT is primarily designed for hull dynamics, but it also contains the tent extension model, because all tent simulation required in CCTT was associated with tracked vehicles. When moving this code over, it will have to be broken into independent pieces, such as hull dynamics, tent simulation, articulated parts, etc. A secondary concern is matching the physical model simulation with appropriate controllers, although this will need to be addressed cooperatively between physical models and behaviors; in general this will impact implementation decisions more than requirements satisfaction.

CCTT's functional requirements should be easily matched by the conversion to C and incorporation into the ModSAF architecture. The primary requirements risk will be in the areas of validation and integration test (i.e., verification of fair fight).

Performance

Because the CCTT physical models code is well suited to an Ada-to-C translation, it is expected that there will be little or no variation in performance. While there may be a slight loss of specialized performance tweaking because of the language translation, it is likely that this performance variation will be matched by the Ada vs. C performance difference. Thus performance risk is minimal, with the recognition that the translated CCTT models may need some fine-tuning once tested in C to meet specific CCTT loading requirements.

Schedule

This effort will be very safe from a schedule standpoint. Because ModSAF has its own variation of most CCTT physical model capabilities, the translation of CCTT models can be done in whatever order desired and either sequentially or in parallel as deemed most appropriate for supporting other teams' efforts. Because the translation will be relatively straightforward, there will be plenty of calendar time to resolve issues.

However, if there are any specific model capabilities that are required by specific CCTT behaviors, the development of those behavioral models must follow the completion of the porting of the CCTT physical models. Therefore, the schedule of the behavioral model development may be negatively impacted.

C- 97

Appendix C - Migration Assessments ADST-II-CDRL-ONESAF-9800101 Physical Models Assessment Option 1 MAY 8, 1998

Because of the likelihood of unforseeable problems arising during the testing of the CCTT models with their new behaviors, there is a reasonable risk of schedule impact during the later phases of the program.

Reliability

There will be minimal reliability risk with the physical models implementation resulting from this approach. The greatest issue will be the need to conduct thorough integration testing as part of the CCTT system to verify that the Ada-to-C translation is as stable as the original Ada implementation. Besides direct translation problems, the interaction of the controller systems and near-term path planning must be verified together with the physical models since these components depend so heavily on each other.

Once verified and tested, the reliability of the final system should be no worse or no better than that of either ModSAF of CCTT SAF.

Scalability

With respect to physical models, the scalability of the final system should be no worse or no better than that of ModSAF.


V&V

As part of the OneSAF testbed and CCTT system integration effort, the physical models should receive much the same kinds of V&V they received as part of CCTT, except that less detailed analysis will be required since the algorithms themselves have already been validated. Thus, the effort can focus primarily on ensuring that the implementation is free of Ada-to-C translation errors rather than conceptual/algorithmic flaws. Also, system integration should include "fair fight" experiments oriented toward the manned modules, although the existing CCTT SAF implementation could also be used for some comparisons if necessary.

No major risks are anticipated with V&V, although the LOE may be high.

The transferring of the implementation of the CCTT models facilitates the V&V process. The V&V process would be more involved if starting from the CCTT model specification.

Extensibility

The extensibility of the final system will be the same as that of ModSAF because the ModSAF infrastructure is being used as the baseline.

It is possible that there will be notable improvements in the extensibility of the final system over the current CCTT implementation. This is due the fact that functionality currently

C- 98



wrapped into large packages in CCTT will likely be broken down into smaller components which will be better-suited to localizing problems and swapping atomic components for improving or adding functionality.


In general, ease of maintenance of the final system will be equivalent to that of ModSAF. However, multiple models resulting from non-mergeability will have a slightly negative impact on ease of maintenance.


There is nothing inherent in this change that prevents adaptability to new technologies or architectures when compared with the existing systems.



Cost


In the following list, use the tables in the rest of the document as an enumeration of the models to migrate.

1. Update ModSAF GMI to handle all CCTT model capabilities. 2. Migrate each GMI-based CCTT physical model into ModSAF. 3. Migrate each non-GMI-based CCTT physical model into ModSAF (damage, etc.) 4. Unify similar CCTT/ModSAF models into one model (may be done during the

migration if assessed as technically feasible). 5. Perform validation testing.


The following table shows the relationships between existing CCTT and ModSAF GMI- based models. Non-GMI-based models (such as damage) are not included in this analysis.

CCTT CCTTP- ModSAF P- ModSAF Ratio Package Sloe SLOC Equivalent Architecture:: ■.■ .'fives' • '••; :...: ll§f#iÄil llll

628 libcomponents

Dynamics § ?t Hull

7,474 168 libhulls

C- 99



Tracked 1,993

4879 libtracked 2.45

Wheeled 1,635

2932 libwheeled 1.79

RWA 2,913

2416 librwa 0.83

FWA 2,647

2359 libfwa 0.89

Missile 642

3008 libmissile 4.69

Stationary 864

DI 1,588

1560 libdi 0.98

Turret Turret

1,244 678 libgenturret 0.55

Resources Resource Models 2,884

3197 libsubcomp 1.11

Weapons Weapon

7,195 11 libguns

Ballistic 1,875

Projectile 5,017

5151 libbalgun 1.03

Mlauncher 1,937

2222 libmlauncher 1.15

1809 libcmbtmodels 1019 libflyouteq

Sensors ,■•-•; •■■'!• ' -' ■•■.'; NMS^fM^ii i^^ÖiBBi^^ji,?ä"l^fii Sensor

2,265 19 libsensors

Radar 1,726

1545 libgenradar 0.90

Optical 6,998

5420 libvisual 0.77

444 libsensorutil

C-100



731 libpdetection

Total 50897 40196 0.79

The conclusions that can be drawn from this table are as follows:

1. In general there is a good correlation between CCTT packages and ModSAF functionality for physical models. In some cases, certain models are not represented in ModSAF (such as the stationary hull).

2. In many model-model comparisons, the ratio of ModSAF physical SLOC to CCTT physical SLOC is near-unity. In cases where this ratio does not hold, there may be good explanations. For example, ModSAF's missile hull contains specific Phoenix missile modeling, which may account for it's large size as compared with CCTT's model.

3. ModSAF has more "architectural" components separated as individual libraries. However the total comparable SLOC has ratio is very close to 1 (0.79). This would indicate that the CCTT model suite is comparable to ModSAF's model suite in terms of code size. From this fact, it may be possible to draw the inference that the model complexity of the two suites of models is equivalent.

If the last point is true, than the cost to migrate CCTT models into ModSAF should be no- worse than the development of a new ModSAF physical model. Since it is a migration and not a new development, the cost could actually be much less. Using this assumption, the following table provides a costing estimate of model development effort, based on a constant per-model cost.

Bottom's Up Model Development Estimate Number of GMIs 5 Per-GMI Infrastructure Update 0.5

Subtotal 2.5 GMI-Based Models 16 Per-Model Reimplementation 1.5

Subtotal 24 Non-GMI-Based Models: 5

Minefields Damage (Direct, Indirect)

Smoke,Flare Special Effects Per-Model Reimplementation 1.5

Subtotal 7.5 Total Man-Months 34


C-101



Expect to be able to convert the CCTT SAF implementations over to the ModSAF infrastructure. Existing CCTT SAF physical models follow the CCTT CGF Physical Model Design Document. This ensures that the required functionality of the CCTT models is not lost in the conversion process. There are no drastic differences between CCTT SAF's physical model interface and ModSAF's GMI. Any discrepancies between the two interfaces can be resolved without significant effort by ModSAF's extensible GMI infrastructure.

Assessment






Impact to The approach has The approach has The approach has 1 existing virtually no some impacts to many impacts, the ModSAF user impacts to the the existing effort involved in community existing programs that overcoming the



Impact to The approach has The approach has The approach has 1 existing virtually no some impacts to many impacts, the ModSAF impacts to the the existing effort involved in development existing programs that overcoming the community (e.g., programs or could be over impacts are very STOW) community come with



existing programs that overcoming the programs or could be over impacts are very

C-102



community come with moderate effort


Impact to current The approach has The approach has The approach has 2 CCTT virtually no some impacts to many impacts, the development impacts to the the existing effort involved in (e.g.,FBCB2) existing programs that overcoming the







Cost 34 Man- months



This approach is completely feasible and is assessed as a "1". ModSAF's physical model architecture was designed to support multiple versions of models. Program Risk

The program risk is assessed as "1" because all requirements should be able to be met. There already exist very strong similarities in both ModSAF and CCTT SAF's physical model architectures and implementations. Maintenance of fair fight will be addressed as part of validation testing.


Current programs should see no impact. CCTT will have to support revalidation of the models, but this is true of all approaches. Future programs will have only positive impacts as they will have a larger suite of physical models to choose from for reuse. Any model maintenance under CCTT PDSS or any new model development for CCTT will have a more difficult migration path into this ModSAF based OneSAF testbed architecture. However, since the GMI approaches are similar and since the models will be translated to have the same algorithms, this impact should be relatively low.


C-103

Appendix C - Migration Assessments ADST-II-CDRL-ONESAF-9800101 Physical Models Assessment Option 1 MAY 8,1998

Newly developed physical models within future programs will have a straightforward migration path into OneSAF testbed. However, new technology coming from OneSAF research, such as an O/O implementation of physical models that can exploit specialization through inheritance is not addressed by this approach.

C-104


Physical Model Assessment: Option 2

Start with the CCTT Baseline and incorporate ModSAF modeis.


Use CCTT physical model architecture as a basis and re-implement the suite of physical model capabilities from ModSAF. Where possible, unify common models. In addition, rework the architectural approach to invert the structure (remove the dispatch table approach for a registration approach).


• The primary advantage of this approach is that the CCTT requirements are met by the direct use of the CCTT models in their native architecture.


• The CCTT architecture was not designed to be extensible. • The GMI would have to be expanded to incorporate the new model types and capabilities. • The resulting rework of the model architecture would result in a similar approach to

ModSAF.


The technical feasibility of this approach is high. There are no technical risk items in this rework and incorporation of new models.

Program Risk

This section outlines the program risk for this option.


The CCTT requirements would be met directly since the CCTT models are being directly reused. It is anticipated that the incorporation of the ModSAF models and the inversion of the architecture would meet the ModSAF requirements.

Performance

Performance requirements would not be adversely impacted by this option.

Schedule

There would be a moderate schedule risk since the architecture would be inverted to incorporate ModSAF extensibility.

C-105

Appendix C - Migration Assessments ADST-II-CDRL-ONESAF-9800101 Physical Models Assessment Option 2 MAY 8, 1998

Reliability

This option does not adversely impact reliability. Scalability

This option does not adversely impact scalability. Scalability should be the same as the existing systems.



It is anticipated that existing requirements will be met and provide little impact to existing programs. There would be some level of analysis that would need to be performed on the common models. Specifically, a divergence between the model approaches would need to be examined and the expectations of each user examined to determine if both models would need to be supported (i.e. both tracked models are required based on the usage of the models).

V&V

This change would provide minimal impact to V&V since the CCTT models are being reused.

Extensibility

This change would increase the extensibility of the baseline architecture of CCTT by the incorporation of ModSAF concepts. The resulting extensibility would be equivalent to the current ModSAF extensibility.


There is no adverse impact to baseline maintenance for this approach. However, if it is determined that two implementations of a specific model are required, both set would need to be maintained in parallel for selected changes.


There is nothing inherent in this change that prevents adaptability to new technologies or architectures when compared with the existing systems.



Cost


• ModSAF Models missing from CCTT baseline. • Inversion of the architecture to match the ModSAF extensibility.

C-106



Incorporation of the CCTT models into the new inverted architecture.


Capability Months GMI 1 ModSAF Models 34 CCTT Models 13 Inversion 2

Total 50 mm


• The majority ModSAF entity component models are represented in CCTT. • The entities that need to be added do not provide significant conflicts with existing CCTT

component models or approaches. • The data associated with the ModSAF models is expressed in a similar manner to CCTT

data.

Assessment

Criteria Low (1) Medium (5) High (10) Score Technical The technical The technical The technical 3 Feasibility Risk feasibility is rated feasibility is good feasibility is poor.



Program Risk There is little risk There is a The migration 3 of the migration moderate risk of approach is very risky approach the migration

approach and has never been attempted before

Impact to existing The approach has The approach has The approach has 2 ModSAF user virtually no some impacts to many impacts, the community impacts to the the existing effort involved in




Impact to existing The approach has The approach has The approach has 4 ModSAF virtually no some impacts to many impacts, the development impacts to the the existing effort involved in

C-107



community (e.g., existing programs programs that overcoming the STOW) or community could be over



Impact to existing The approach has The approach has The approach has 1 CCTT program virtually no some impacts to many impacts, the

impacts to the the existing effort involved in existing programs programs that overcoming the or community could be over



Impact to current The approach has The approach has The approach has 1 CCTT virtually no some impacts to many impacts, the development impacts to the the existing effort involved in (e.g.,FBCB2) existing programs programs that overcoming the

or community could be over come with moderate effort






Cost 50 mm



This is scored as a '3' based on the need to rework the existing architecture for the models.

Program Risk

This is scored as a '3' based on the effort required to rework the architecture.


Impact to the current ModSAF development community is listed as a '2' due to the re- architecture effort will re-implement the existing models and provide a slightly different model. Impact to ModSAF developers is listed as a '4' since the architecture and models are different and may require a rework of their systems. Impacts to CCTT are scored as a' 1' since the underlying models and approaches are the same as are currently on CCTT SAF.

C-108



This is scored as a '2' since the resulting architecture will be extensible.

C-109

Appendix C - Migration Assessments ADST-II-CDRL-ONESAF-9800101 User Computer Interface Assessment MAY 8, 1998

C.5 User Computer Interface Assessment

UCI Assessment

Use ModSAF UCI Capabilities as a basis and add the missing UCI capabilities from CCTT SAF.


Common goals, independent on which path taken, are to use C (not Ada) in OneSAF testbed, support running OneSAF testbed on SUN, SGI, PC/Linux, Dec Alpha, and AIX.

It has been directed from PM-CATT that the only UCI related interfaces that must be preserved in CCTT are the components that are shared across the system. This implies that the CCTT PVD application is untouchable. Though the look-and-feel of the CCTT SAF workstation may be modified, certain key-features, such as the ability to have multiple- windows open to edit and control multiple units, must be maintained.

The migration approaches for UCI capabilities are as follows.

1. Use CCTT SAF UCI Capabilities as a basis and add the missing UCI capabilities from ModSAF.

2. Use ModSAF UCI Capabilities as a basis and add the missing UCI capabilities from CCTT SAF.

The first approach has been considered but is not seen as a reasonable migration approach due to the lack of data-driven extensibility in the basic CCTT SAF UCI. It is understood that the final product, an extensible, C-based, data-driven GUI should look like the ModSAF architecture instantiated with both ModSAF GUIs and CCTT SAF GUIs. Starting with a CCTT SAF base, recoding for extensibility, and adding the ModSAF GUIs is seen as an obviously more costly approach than starting with a ModSAF base and adding the CCTT SAF GUIs.

The only reasonable approach then is to take ModSAF as the baseline and to add the following CCTT SAF specific UCI capabilities into ModSAF.

In addition, the following enhancements will need to be made to the new baseline:

PVD API

Add a new interface to ModSAF to communicate to the CCTT PVD using the existing CCTT PVD API.

The CCTT PVD uses the CCTT PVD API to communicate with the other components via a shared memory message queue. An interface to this shared memory must be implemented to allow ModSAF to use that PVD. That interface includes tactical map operations, and the overlay editor (including graphics).

C-110

Appendix C - Migration Assessments User Computer Interface Assessment


ModSAF PVD

Modify the existing ModSAF UCI architecture to allow the ability to turn off (at startup time) the ModSAF PVD and use the new interface instead. There are several functionalities that currently depend upon having the ModSAF PVD available and these will all have to be adjusted:

• When running without the ModSAF PVD, do not tick the PVD vehicle subclass. Also, libpvd should not register for various events (such as detonations), and should not install the terrain redraw bitmaps handlers.

• Editors that depend upon the ModSAF PVD for input need an alternate method to obtain input. The editables that these editors use will need to be enhanced. One option is to add a button to the editable(s) that will popup a window that has a list of the available objects that make sense. For example, the Location3D editable would be modified to have this button. When pressed, it would popup a window that listed all the existing locations (i.e. Point Objects) and would allow the user to select one.

• All libraries that depend upon the existence of the ModSAF PVD would have to make sure that it exists before trying to perform operations on it. Alternately, add passive error detection to libpvd to simply ignore requests when running without a PVD.

• Pass an additional argument to the UCI related library init routines to indicate that there may be no PVD. For example, libpvd would be told not to create a PVD, libtactmap would be told not to install a tick routine to update the PVD, etc.

Multi-Instance Popup Editor Support

CCTT SAF supports multiple pop-up editors open to view the task-organizations and missions of different units. This supports concurrent control of multiple units by moving from one window to the next. This approach is fundamentally contradictory to ModSAF's tiled windows. The GUI infrastructure must be enhanced to support multiple instances of the same editor running using different data. This may have impact to architectural libraries such as libeditor and libSAFGUI.


All ModSAF UCI Capabilities will already be done, preserving the inverted, data driven ModSAF UCI architecture. The architecture would remain extensible and maintainable. In addition, the existing ModSAF UCI does implement much of the CCTT SAF UCI functionalities.


Due to requirements, two different PVDs will exist and could present limitations in terms of maintainability and extensibility. The look and feel of the CCTT UCI mostly likely will not be preserved.

C-lll



This approach is technically feasible. Except for the new shared memory API to communicate to the existing CCTT PVD, nothing in this approach is technically challenging. There will be a need for a thorough feature-by-feature comparison during the design and test phases of the effort to guarantee that no user-visible capabilities are lost from CCTT.

Program Risk


All ModSAF requirements will be easily met. AU CCTT SAF requirements will also be met, but the look and feel of the CCTT UCI will not be preserved. Performance

Performance will be comparable to the existing ModSAF UCI performance, and the CCTT PVD will be unchanged.

Schedule

There is a low to moderate risk in implementation of some of the more complex GUIs and interfaces. For example, the interface to the CCTT PVD may be difficult to implement in ModSAF, and it's integration with the rest of the system may be difficult to achieve. Also, the Execution Editor may be difficult to implement, as was demonstrated by the effort to implement it in CCTT.

Reliability

The ModSAF UCI architecture will be minimally changed and therefore should work as reliably as it does now.

Scalability

Scalability will be comparable to the existing ModSAF UCI scalability. Large CCTT exercises will continue to use the CCTT PVD, which can meet current CCTT performance requirements. Since the CCTT behaviors will be implemented, similar user workload should result in this system.



The current system capability requirements for ModSAF and CCTT SAF will be met.

Extensibility

Extensibility will be maintained. The ModSAF UCI architecture was designed with extensibility in mind.

C-112




There will be an impact to baseline maintenance since there will need to be support for both the ModSAF and CCTT PVDs. Also, the API to the CCTT PVD will not be under OneSAF testbed control, so external modifications to that API will require OneSAF testbed modifications and new releases.


The UCI capabilities in the OneSAF testbed will be as adaptable to new technologies as ModSAF currently is. If the CCTT PVD API changes, the new interface on the ModSAF side would have to change as well.


The ease of coordination and integration of multiple developers will be equivalent to ModSAF's current capabilities since this UCI capability work will be based on ModSAF.

Cost


See spreadsheet below.

C-113



Editor Capabilities Man-Months

Main Window 2

Load/Save Exercises (scenarios)

High-level edit of exercises

Exercise Editor 12

Execution Matrix

Scenario-time use

Run-time use

Order Inserts

Triggers

Lists of applicable CISs

Order Parameter Displays

Order Decomposition

Auto-generation of order parameters

Unit Editor

Task Organization 3

Attach/Dettach/Cross-Attach

Unit Parameters (weapons loads)

Palette of Units

Predefined (heterogenous, homogenous)

User Defined

Doctrinal Unit Markings

Command Overrides 1

(like Immediate Interventions)

Unit Status Window 1

Weapons Status

Speed Status

Behavior Status

Damage Status, etc.

Report Window 1

Filters

Select

Delete

Alert Windows 1

Select

Delete

Operator Notification 1

Pre-defined User Inputs

Vehicle Control Editor 2

Crew-behaviors

Fire

Tether

Goto Point

Spot Report Processings 2

(like Commander's View)

PVD Interface 12

Map Interface

Overlay & Graphics Interface

Total Man-Months 38


C-114



The CCTT PVD component of CCTT SAF cannot be modified, and a new interface would have to be added to ModSAF to hook up to the CCTT PVD API. It is assumed that any memory layout requirements to communicate with the shared memory can be satisfied via a new ModSAF C library interface.

There are roughly 40 libraries that comprise the ModSAF GUI. However, a small subset forms the core (libeditor, libtactmap, libpvd, libbgr, etc.).

There are roughly 70 functions in the CCTT PVD API. For each of these functions, it is expected that they will be created in the OneSAF testbed UCI API.

There are roughly 50 enumerated messages in the CCTT PVD API. Each of these will have to be created in the OneSAF testbed UCI API.

Assessment


Criteria Low Medium High Score Technical The technical The technical The technical 4 Feasibility feasibility is rated feasibility is good feasibility is poor.



Impact to existing The approach has The approach has The approach has 1 ModSAF user virtually no some impacts to many impacts, the community impacts to the the existing effort involved in




Impact to existing The approach has The approach has The approach has 1 ModSAF virtually no some impacts to many impacts, the development impacts to the the existing effort involved in community (e.g., existing programs programs that overcoming the STOW) or community could be over



Impact to existing The approach has The approach has The approach has 4 CCTT program virtually no some impacts to many impacts, the

impacts to the the existing effort involved in

C-115



existing programs or community

programs that could be over come with moderate effort

overcoming the impacts are very large, or technically challenging

Impact to current CCTT development (e.g.,FBCB2)

The approach has virtually no impacts to the existing programs or community

The approach has some impacts to the existing programs that could be over come with moderate effort

The approach has many impacts, the effort involved in overcoming the impacts are very large, or technically challenging

3

Program Risk There is little risk of the migration approach

There is a moderate risk of the migration approach

The migration approach is very risky and has never been attempted before

2


The resulting infrastructure or environment can be easily extended

The resulting infrastructure does not support extension and will require additional enhancements to support future modification

The resulting infrastructure is not unified and should be completely redesigned to support extensibility

2

Cost 38mm



The feasibility is rated as a "4" because of the potential integration difficulties with the CCTT PVD, and the complexity inherent in the Execution Editor.


There will be little to no impact to existing ModSAF users and developers as ModSAF's GUI architecture is only being enhanced, not replaced. There will be a moderate (4) impact to existing CCTT users and documentation, as the GUIs will change. There will be a slightly less (3) impact to future CCTT development, as it is anticipated that such future development will have minimal GUI modifications.

Program Risk

The only program risk is that the new GUIs may have some modified or missing functionality with respect to the current CCTT SAF system. This must be mitigated during design, implementation, and test, through the repeated use of side-by-side comparisons of features.

C-116



The adaptability risk is low (2), as ModSAF's architecture has basic extension capabilities. However, this approach does not take advantage of any new developments in GUI technology (e.g., Java, Swing, pluggable look-and-feel, HTML, VRML, low-cost 3D, etc.) which would likely be part of an ultimate OneS AF development.

Cost

See spreadsheet.

C-117

onesaf testbed baseline assessment - Defense Technical ...

Documents

Transcript of onesaf testbed baseline assessment - Defense Technical ...