Model Descriptor Metadata Datasets

405 © 2015 Open Geospatial Consortium The Dataset, Kind, and Index fields correspond respectively to the dataset number and component selectors 1 and 2; they match the D, S and T fields in the texture filename. The mipmap field defines the smallest and largest mipmap available for this texture. The value of this field is used to compose the W field in the texture filename of moving models see examples in section 3.5.2.4. The texture resolution is expressed in texels per meter 70 . It is the same for both the U and V axes even though it is recognized that it can differ between the two dimensions. The intent is to provide an indication of how precise the texture is when mapped to the model geometry. It helps client device decide which mipmap is more appropriate to use. The texture coverage is optional and defines the minimum and maximum values for the U and V texture coordinates. This information indicates if the texture is repeated along one or both axes. If the coverage is in the interval [0, 1], the texture is clamped; otherwise, it is repeated. 6.14.5.2 Texture Switch A Texture Switch is defined when switchable textures appear in the list of textures. Switchable textures are textures that can be exchanged for one another because they share the same UV mapping, as explained in section 6.13.5.2, Model Skin Textures. The section is formatted like this. Switch no=number name=name State no=number name=name textures=list ... Switch The switch number is a unique positive integer identifying the switch. The switch name is a unique string limited to 32 characters; all switches are uniquely identified by a number and a name. A switch has two or more states; each state selecting a list of one or more textures. State numbers are consecutive and start at 1. The state name is a unique string also limited to 32 characters. The list of textures associated with a state contains the texture numbers of the selected textures. Note that a state e.g., a skin may require more than one texture, hence the need to specify a list of textures associated with a state.

6.14.5.2.1 Example

Assume that the following two textures are stored in the M1A2 texture folder: \CDB\MModel\601_MModelTexture\M\1\M1A2\ D601_S004_T005_Wxx_M1A2.rgb D601_S005_T001_Wxx_M1A2.rgb 70 This unit of measurement texels per meter is akin to DPI dot per inch used to quantify the resolution of printers and displays. 406 © 2015 Open Geospatial Consortium Here is an excerpt of the model metadata presenting the two textures, the switch, and the two corresponding states. Textures Texture no=3 name=M1A2 Dataset601Dataset Kind4Kind Index5Index ... Texture Texture no=10 name=M1A2 Dataset601Dataset Kind5Kind Index1Index ... Texture ... Switch no=1 name=Paint Scheme State no=1 name=Uniform Beige Paint textures=3 State no=2 name=Desert Camouflage textures=10 Switch Textures The texture switch is named “Paint Scheme” because it controls the selection of the paint scheme to apply to the M1A2. The first state selects texture 3 which corresponds to a beige uniform paint; the second state selects texture 10 corresponding to a desert camouflage. Note that the texture switch mechanism is not limited to base textures; it can be used to switch light maps for example.

6.14.6 Model Configurations

Often, a single Model – especially a moving model – comes with a variety of possible equipment andor ordnance. This can be as diversified as fuel tanks, missiles, radio emitters, etc. To configure a model with its ordnance, the CBD Specification defines the concept of model configuration. A configuration defines the set of equipment and ordnance attached to the various stations found on the model. The configuration section is optional. It is a list of one or more configurations defined like this. Configurations Configuration...Configuration ... Configurations 6.14.6.1 Defining Stations in a Configuration A configuration is a sequence of one or more stations, each defining one piece of equipment in one location. 407 © 2015 Open Geospatial Consortium Configuration name=ConfigName Station name=StationName Location...Location Equipment...Equipment Station ... other stations as needed Configuration The configuration and station names are both optional and are used for documentation purposes only. The location of a station is defined by its fully qualified name as specified in section 6.5.5, Model Zone Naming. 6.14.6.2 Defining Equipment in a Station The equipment is defined by either its DIS identification or a reference to an external part, and an optional anchor point. Equipment name=EquipmentName Identification...Identification External_Part...External_Part Anchor...Anchor Equipment The equipment name is optional and is used for documentation purposes only. The anchor point is specified in the same manner as the location of a station, by providing its path on the subordinate model as specified in section 6.5.5, Model Zone Naming. 6.14.6.3 Defining Equipment Names Either a DIS emitter name or a DIS entity type identifies the equipment. When the equipment is an emitter, the syntax is as follow. Identification DIS_Emitter_Name...DIS_Emitter_Name Identification Emitter names are defined by the DIS standard. For DIS, refer to Section 8.1.1 of reference [4] for a list of DIS Emitter Names. For the HLA standard, the RPR-FOM lists all emitter names. To avoid confusion, both DIS and HLA refer to emitter names using numbers. For instance, the NATO emitter AS 15 KENT altimeter is referred to as emitter 8735. When the equipment is another entity e.g., a missile, its DIS entity type is supplied in the following manner. Identification DIS_Entity_Type...DIS_Entity_Type Identification Recall that the DIS entity type is a list of up to 7 numbers as defined by reference [4]. For example, the AGM-114K-SAL Hellfire missile would be referred to as: 408 © 2015 Open Geospatial Consortium DIS_Entity_Type List2 2 225 1 3 5 1List DIS_Entity_Type or DIS_Entity_Type Kind2Kind Domain2Domain Country225Country Category1Category Subcategory3Subcategory Specific5Specific Extra1Extra DIS_Entity_Type Equipment can also be defined by a reference to an external part if need be. A good example of such equipment is a fuel tank. External_Part Part_Number...Part_Number Configuration...Configuration External_Part The external part is identified by its part number as defined previously in the Parts section. The external part may also require it own configuration. Take the example of a Hellfire missile rack attached to an attack helicopter like the Apache. The rack can hold up to 4 missiles. Each missile attaches to one of four separate weapon stations located on the rack. For this more complex example, assume the rack has only two missiles out of four. This configuration can be specified with the following piece of XML. External_Part Part_Number1Part_Number Configuration Station name=Missile 1 Location\Missile_Rack\Attach_Point[1]Location Equipment Identification DIS_Entity_Type List2 2 225 3 5 1List DIS_Entity_Type Identification Equipment Station Station name=Missile 2 Location\Missile_Rack\Attach_Point[2]Location Equipment Identification DIS_Entity_Type List2 2 225 3 5 1List DIS_Entity_Type Identification Equipment Station Configuration External_Part With the help of model configurations, it is possible to create several variants of a single Model, each variant defined by its own configuration. 409 © 2015 Open Geospatial Consortium This way, one Apache can have two configurations, one when equipped with Hellfire missiles and one when equipped with rocket launchers.

6.14.7 Model Composite Materials

The composite material table is the last component of the Model Metadata and is defined in section 2.5.2.2, Composite Material Tables CMT. 411 © 2015 Open Geospatial Consortium Chapter 7 7 CDB Radar Cross Section RCS Models

7.1 Introduction

For devices such as Radars, a geometric representation of a model may often provide a level of fidelity which is insufficient or inappropriate for use in simulation or alternately, it may not be feasible to compute a radar cross-section of the model in real-time. Alternately, a user may wish to incorporate real-world RCS data into the simulator client-devices in order to further improve simulation fidelity. To this end, the CDB Specification defines a RCS Radar Cross-Section model representation for use by Sensor Simulation client-devices such as Radar andor Sonar. It provides a signature model representing the overall relative reflectivity levels of a given Model Representation when viewed at discrete azimuth and elevation angles. The RCS data is then used in range and aspect calculations for the detection and classification of simulated targets either ground or moving. This chapter provides all of the information required to store RCS data within a CDB. Section A.7 of Appendix A provides a primer on radar, basic principles of operation and radar cross sections RCS.

7.2 RCS Data Model

This section concerns itself with the internal RCS model representation and its sub-structures, which forms a complete dataset layer.

7.2.1 RCS Model Structure

The CDB RCS data is organized so that client-devices can easily retrieve the following information from the RCS model Figure 7-1: Graphical Representation of the 3D Model RCS Shape Data below: The modeling physical parameters that were used to generate the RCS polar data. The RCS polar representation corresponding to one or more levels of resolution of the RCS polar data. The RCS polar representation corresponding to distinct radar mode of operation. The RCS polar representation corresponding to a distinct radar model type. RCS resolution refers to the angular pitch used in gathering RCS data for the model in question. At a given RCS resolution, it is possible to have two or more RCS polar representations due to the fact that the RCS data is computed based on a number of physical modeling properties such as the characteristics of the electromagnetic beam, its frequency, polarization, amplitude and phase. A simulated sensor operating in a given mode of operation, over a given range of 412 © 2015 Open Geospatial Consortium frequencies, will require the RCS data closest to this mode. It will therefore need to use the closest matching Polar Diagram from the RCS model data.

7.3 RCS Polar Diagram Data Representation using Shapefile

This section provides a detailed description of the content and format of RCS data for the CDB.

7.3.1 Shapefile Internal Data Structure

Within a CDB, the RCS model is stored as a series of ShapeFiles in accordance with the ESRI Shapefile Specification. This section describes the Shapefile internal data structure for the representation of RCS model data. This format provides the required flexibility to create and visualize the RCS data: Easy modification of data attributes Simple visualization of RCS data in polar form Allow irregular steps in azimuthelevation XY Allow some possibly missing values RCS data is inherently two-dimensional in nature and is naturally organized as a two- dimensional array of RCS polar values computed at various azimuth and elevation angles from the target. Each element of this array represents the RCS data value over each uniformly distributed azimuth angle and distinct elevation angle. Therefore, each of such array element can be represented as a “Point” shape, with the azimuth angle value X at a given elevation angle Y, while at the same time storing the associated attributes such as the RCS, Amplitude or Phase data in the instance attribute database dbf file associated to the Shapefile. Typical azimuth angles would range between -180° and +180°, where as the elevation angles would cover from -90° to +90°. However, the RCS data set could potentially only cover just a partial range of those angles if data is incomplete for example. This can be visualized in the next diagram, showing RCS values at various azimuth angles corresponding to an elevation angle of 20° with respect to the model cube. Note that the axis conventions follow those described in Section 6.3, Coordinate Systems. 413 © 2015 Open Geospatial Consortium Figure 7-1: Graphical Representation of the 3D Model RCS Shape Data Partial RCS data is permitted, i.e., it is permitted to cover a sub-region of the RCS polar diagram with only points corresponding to known values. For example, consider an RCS model consisting of data values in 5 o elevation increments and 2 o azimuth increments covering the entire aspect angle range of the target. The CDB representation would consist of 180°5°+1 = 37 sets of 360°2°+1 = 181 points vertices for a full target aspect coverage; yielding 6697 point shapes with their attribute data. For each of those Shapefile point vertices, the X component represents the azimuth angle equivalent to longitude and the Y component represents the elevation angle equivalent to latitude; the RCS value and other attributes being stored in the instance attributes within the DBF file. The CDB specification defines eight prescribed values for azimuth and elevation increments. They are referred to herein as ModelSignature Significant Angle. The table below shows the correspondence between the ModelSignature LOD level number and the ModelSignature Significant Angle. A zimuth E levation 9 50 60 7 8 Gre y of values for degree elevation ots nt pes f drant of R alues 414 © 2015 Open Geospatial Consortium Table 7-1: ModelSignature Significant Angle per LOD ModelSignature LOD level Significant Angle Number of values 90° ≤ Significant angle Less than 8 1 45° ≤ Significant angle 90° between 8 and 32 2 22.5° ≤ Significant angle 45° between 32 and 128 3 11.25° ≤ Significant angle 22.5° between 128 and 512 4 5.625° ≤ Significant angle 11.25° between 512 and 2048 5 2.80° ≤ Significant angle 5.625° between 8192 and 32768 6 1.40° ≤ Significant angle 2.80° between 32768 and 131072 7 0.70° ≤ Significant angle 1.40° between 131072 and 524288 Such a data representation would typically produce the following diagram when viewed in 2D Figure 7-2: Polar Diagram of RCS Data in Planar Representation and 3D Figure 7-3: Polar Diagram of RCS Data in Spherical Representation polar forms color representing the RCS Intensity attribute: Figure 7-2: Polar Diagram of RCS Data in Planar Representation 415 © 2015 Open Geospatial Consortium Figure 7-3: Polar Diagram of RCS Data in Spherical Representation In addition, specific attributes within the Shapefile are required to specify other characteristics of the RCS data, like EM polarization mode and frequency that were used when characterizing the target’s RCS signature. Those are the class-level attributes and are described below. The data for each distinct RCS representation model requires two different types of attributes; RCS model class attributes and RCS instance attributes. 1. RCS Model Class-level attribution: These are attributes that can be shared by all of the RCS model instances of the RCS representation. The attributes and their values are logically re-grouped under a classname that stands for the entire attributes specific to the RCS model. All of the classnames are re- grouped into a model.dbf file referred to as the RCS Class Attribute file for the RCS model. See Section 7.4.1, Directory Structure Each row of the model.dbf file corresponds to a different classname. The first column of the file is the classname attribute and acts as the primary key to access subsequent table entries; all other columns correspond to the attributes represented by the classname. 2. RCS Instance-level attribution: This is the data that represents a particular instance of the RCS model for a RCS representation. The data is contained in 416 © 2015 Open Geospatial Consortium the attribution columns of the model.dbf file that accompanies the RCS’s .shp file. This .dbf file is referred to as the RCS Instance Attribute file of the RCS model. See Section 7.4.1, Directory Structure The first column of each row is always the classname attribute. The other columns in a RCS Instance Attribute file are used to describe further the associated shape. In summary, for a single RCS model in the CDB, the data files consist of: One .shp main file that provides the geometric aspect Points for each data instance of a RCS model. Two .dbf files one instance-level on a per RCS Shape basis, and one class- level at the RCS model level that collectively provide the attribution for all of the possible RCS models of a given RCS Model. One .shx index file that stores the file offsets and content lengths for each of the records of the main .shp file. The only purpose of this file is to provide a simple means for clients to step through the individual records of the .shp file i.e., it contains no CDB modeled data.

7.3.1.1 RCS Model Class-Level Attributes:

Many attributes within the Shapefile are required to specify the physical modeling parameters corresponding to those used to produce the RCS data; this includes, for instance, the electro- magnetic EM polarization mode and the frequency that were used when characterizing the target’s RCS signature. The CDB RCS model representation offers a comprehensive set of class attributes that are described below. It is important to note that these attributes are an elaborate set of fields to indicate in which physical environment the RCS data was computed, and does not necessarily reflect a precise operating mode of a particular radar. A description of the attribute information follows below. The reader should keep in mind that the 10-character limitation of attribute names is imposed by the dBASE III+ file format used by the Shapefile .DBF data format Table 7-2: XML Tags for Hot Spots Attribute Format Description Values Units CLASSNAME STRING Unique string identifying the RCS model class attribute characteristics Uniquely identifiable character string for the class name String of 32 characters VERSION STRING String representing the version level of the RCS Data XX.YY.ZZ String of 8 characters PROD_DAY INT Number representation of the computation day DD NA PROD_MTH INT Number representation of the computation month MM NA PROD_YEA INT Number representation of the computation year YYYY NA