WO2008073081A1 - Method and apparatus for acquiring and processing transducer data - Google Patents

Abstract

A method and apparatus for correlating raw transducer data in a system of transducers communicates transducer data to a common format. Transducer data and relationships between transducers are characterized in a common format, and interdependencies of transducers are defined for modeling a system. The data is time correlated from the various transducers. Data is archived, updated and exchanged without being corrupted.

Description

METHOD AND APPARATUS FOR ACQUIRING AND PROCESSING TRANSDUCER DATA

REFERENCE TO FLAT RELATED APPLICATIONS [0001] This application claims the benefit of United States Patent Application Serial Number 10/674,828 which was filed on October 1 , 2003 which claimed the benefit of and which was related to Provisional Application serial nos. 60/415,772 filed October 4, 2002, and 60/505,729 filed September 26, 2003, the teachings of which are incorporated herein by reference, word for word and paragraph for paragraph.

GOVERNMENT RIGHTS

[0002] This invention was made pursuant to U.S. Government contract nos. F33615-03-C-1437 (USAF);

F336I5-02-M-1189 (USAF); and DASG 60-030P-0280 (U.S. Army Space and Missile Defense Command).

REFERENCE

Submitted herewith is included "TransducerML Format Specification" Version 0.9beta, the material of which is fully incorporated herein by reference. The information incorporated was created on August 25,

2003 and is attached as Appendix A. BACKGROUND OF THE INVENTION

[0003] The present invention pertains to a method for establishing a common basis for the exchange and processing of transducer (Le. sensor and emitter) data acquired from a plurality of diverse transducers. In particular, the invention pertains to a method and apparatus for providing a common basis for capturing data in real time from diverse transducers. The data may be used immediately or may be archived without corruption

[0004] Currently standards exist for the capture of data. However, current standards' do not meet the accuracy and efficiency requirements for capturing in real-time multi-sensor data. Indeed, the failure to characterize data as sensor data misdirects the task and undermines the objectives of efficient and effective data capture. . ,

[0005] In many data capture applications, it is desirable to obtain data from one or more transducers at various locations. These data may be produced by various devices and may be expressed in a variety of forms. In order to be useful in a meaningful way, these data must be processed and correlated: However, the data is difficult to correlate because data from one type of transducer may be incompatable with the data from other types of transducers, and it is necessary to reconfigure the expression of the data in order to facilitate their utilization. Such reconfiguration sometimes results in a corruption of the data from its original form, which, in turn results in a loss of accuracy.

[0006] In addition, these data must be appropriately organized so that data from related devices may be accurately tracked in time and space. Such organization requires the generation of meta-data, i.e. data about data, having a complexity which increases as the complexity of the expressed form of the transducer data increases. This complex meta-data consumes valuable processor memory and diminishes processor efficiency.

[0007] The data produced by various transducers may be generated at different times and at different frequencies or intervals depending on the system requirements. For example, it may be necessary to record the position, or temperature of a sensor less frequently than it is necessary to record the image produced by such sensor This is because the image may change more frequently than the temperature of the sensor, and the motion of the sensor may be uniform, and hence its position may be readily computed.

[0008] At the same time, it may be necessary, in a particular application, to correlate the primary image data with the secondary temporal, positional and temperature data. In conventional systems this secondary data may be inserted in a header as meta-data preceding the image data. This form of data acquisition results in high processor overhead, and is inefficient and inconvenient to handle

[0009] Finally, it is difficult to transmit large amounts of data in an efficient manner, especially where the large amounts of complex meta-data are involved Here too, complexities associated with the diverse expression of data increase communications system requirements, particularly bandwidth and processor speed.

SUMMARY OF THE INVENTION

[00010] The invention is based upon the discovery that transducer data may be expressed or modeled uniformly in terms of a Transducer Characteristic Frame (TCF). Each transducer will have a unique TCF All models for a transducer will employ the same TCF structure.

a clusters

b. TCF

c. Samples

d Measurements

[00011] Models or descriptions of data follow a preselected hierarchy of measuiements, samples and clusters Spatial, timing and sequencing chaiacteustics of (he data employs the TCF. Data is correlated from any arbitrary set of transducers using the mode] and data structure. Interpretation of data -from the arbitrary set of transducers is achieved by interpolating samples occurring during successive acquisition time intervals or ticks. .Data is communicated from any transducer-using the preselected hierarchy-

BRIEF DESCRIPTION OF THE DRAWINGS

[00012] Fig. 1 is a schematic illustration of a sensor showing the stimulus and the response characteristics.

[00013] Fig. 2 is a schematic representation of an in-situ sensor and its corresponding response.

[00014] Fig. 3 is a schematic block diagram of a remote sensor showing the instantaneous field of view and the corresponding response.

[00015] . Fig. 4 is a schematic illustration of an active remote- sensor showing IFOV and the characteristics of the source illumination and response.

[00016] Fig. 5 is a schematic representation of a scanning IFOV remote sensor showing object and image space.

[00017] Fig. 6 is a generalized illustration of sensor frames showing dimensionality and relative timing samples for diverse sensors. . .

[00018] Fig. 7 is a schematic representation of a framing sensor showing the derivation of look angle vectors.

.[00019] Fig. 8 is a schematic representation of coordnate TCF samples for various sensors.

[00020] Fig. 9 is a description of spatial and timing data for a line sensor.

[00021] , .Fig. 10 is a description of the IFOV distribution for a sensor sample.

[00022] Fig. 11 is a description of the response spectrum of a sensor over its response range.

[00023] Fig. 12 is an illustration of the stimulus-response-transfer function of an exemplary sensor. . . . . . [00024] Fig 13 is a schematic illustration of a sample order for a sensor and a corresponding different transmission order for the same device

[00025] Fig 14 is a depiction of a basic Cartesian coordinate systme

[00026] Fig 15 is a depiction of a basic polar coordinate system

[00027] Fig 16 is a depiction of an earth centered coordinate system

[00028] Fig i 7 is a depiction of a platform coordinate system

[00029] Fig 18 is a depiction of coordinate transformations in euler angles

[00030] Fig 19 is an illustration of an exemplary coordinate transformation

[00031] Fig 20 is an illustration of an exemplary interpolation

[00032] Fig 21 is an illustration of exemplifying the relationship of sensor data taken at different rates

[00033] Fig 22 is a geneialized. schematic block diagiam of the overall system according to the invention

[00034] Fig 23 is a generalized schematic diagram of a conventional system

[00035] Figs 24°- 24c are schematic block diagrams of various embodiments of a generalized system according to the invention.

[00036] Fig 25 ia a schematic block diagram of an airborne capture and transmit system according to the invention

[00037] Fig 26 is a schematic block diagram of a terrestrial or ground receive processing and drsplay system according to the invention.

[00038] Fig 27 is a graphical representation of a model curve, which exemplifies a frequency response curve

[00039] Fig 28 is an example of an encoding fragement DESCRIPTION OF THE INVENTION

METHOD AND APPARATUS FOR ACQUIRING AND PROCESSING TRANSDUCER DATA

[00040] The invention is directed to a method and apparatus for collecting, organizing, correlating and communicating transducej. data from a plurality of diverse transducers A transducer is any device which produces an output which may be monitored Transducers may include known sensors or emmitters of various types which are discussed below Transducers may also include devices yet to be developed, but which according to the invention, may be readily incorporated in accordance with the TCF of the newly developed sensor,

[00041] As used herein, a transducer may be defined as any device that produces a response as a function of a stimulus (i e a sensor), or a device that produces transmitted energy (i ≤ an emitter) The term transducer is general and is used as such, the terms sensor and'emitter are particular examples of specialized transducers and are used throughout this discussion as appropriate Fig 1 illustrates a sensor producing an output (response) m response to an input (stimulus)

[00042] Theie are basically two general types of transducers, namely m-situ transducers es and remote transducers In-situ sensors are transducers that make measurements at the on gin of the stimulus They are typically m contact with an object of which a measurement is made Some examples are pressure and temperature sensors, rotational encoders, geo- positiomng satellites (GPS) and internal measurement units (MU) Fig 2 illustrates an m- εitu sensor m contact with an object and its response

[00043] A remote transducer, which can be active or passive sensoi, measures cbaracten sties of the environment represented by the state of a remote object Remote sensors typically measure energy modulation A remote sensor can be charactenzed as having an Instantaneous Field Of View (IFOV) Fig 3 illustrates a passive remote sensor with an IFOV wherein the information detected by the sensor is reflected energy Such sensors measure the emitance and reflectance of an object Such sensors typically rely on the illumination from ambient sources for their reflected illumination

[00044] Active remote transducers are sensors that piovide the necessary illumination in order to measure the τeflectance from the object The chaiactenstics of the illumination souice must be known Fig 4 illustrates such an active sensoi wheiein an illumination souice or emitter produces illumination and the sensor is responsive to the reflected energy from the object IFOV. In the example, the illumination source and sensor are each considered to be transducers.

[00045] Emitters can be^generally characterized as transducers which are the reciprocal, of a remote sensor. Instead of an input energy producing a response signal, an emitter uses an in put signal to produce an output energy. ■

[00046) Remote sensors may be further employed to scan the IFOV in order to cover, a wider field of view (FOV) by taking many samples, each sampling different space of their own IF.OV. As shown in Fig. 5, remote sensors, which scan the IFOV in the entire FOV either by sequencing multiple detectors or by moving the IFOV of a single detector and taking multiple samples from that detector during the motion are referred to as scanning sensors. The scanning of a remote sensor is typically implied in trie data structure of -the sensor response. Some imaging sensors rely on IFOV scanning to produce an image of the object space. Some sensors known, as framing sensors do not scan, -but have multiple detection with individual IFO Vs arranged in such a way so as to cover a large field of view. Samples making up a frame form a framing sensor are all from the same instant of time. The sample from a scanning sensor have sequential time sampling over an imaging interval. Although the data produced by such diverse systems have different characteristics, the invention provides a method and apparatus for combining the data from any number of diverse transducers.

[00047J The structure of all transducer data is described in the following hierarchy.

[00048] 1. Transducers produce measurements. A measurement is a single data point.

[00049] 2. A transducer sample comprises one or more measurements. Every measurement in a sample corresponds to particular temporal and spatial coordinates.

. [00050] 3. A Transducer Characteristic Frame (TCF) comprises a set of transducer samples. The TCF is the minimum set of samples that rriust be considered in order to characterize the transducer.

[00051] 4. Transducer data is sent in clusters. A cluster is a specified whole TCF. A cluster may be a portions set fraction of a TCF when the TCF is very large. [00052] The invention provides a method and apparatus for: (a) describing (that is, modeling) the particular data structure of any. transducer relative to the hierarchy of ■ measurements, samples, TCF and clusters; (b) communicating the data from any transducer using this hierarchy- and (c) correlating the data from any arbitrary set of transducers using ' the model and data structure. .

[00053} Transducers are normalized by providing a universal method of modeling transducer data based on a transducer characteristic frame (TCF).

[00054] Certain terms are used throughout the description and are thus introduced- generally below.

.[00055] The Transducer Characteristic Frame (TCF) is a set of samples comprising a series of measurments organized so as to compartmentalize the measurements in a way thatresembles the physical 'layout of the transducer.. If, for example-, the transducer is a push broom scanner having 1 x n pixels, the TCF will be organized in a 1¹X n array,

[00056] A model represents a feature of the transducer which may be expressed. For example, a pixel may have a selected orinetation with respect to the focus of a camera. This orientation has two spatial components, sometimes referred to as alpha (α) and beta (β) angles as described using a spherical- coordinate system. According to the invention, the model for α . is a series of numbers for the α component of each 1.x n pixel; and the β model is a series of . numbers for the β component of each 1 x n pixel. Other features, described hereinafter, will- be modeled in the same way so that all models of data look like the TCF of the transducer. The models appear as layers having the same appearance or corresponding properties and characteristics of a transducer. ■ ■

[00057] The dimensionality characteristic of the TCF is the number of object space coordinates needed to specify the spatial characteristics of each transducer sample relative to a transducer reference system. In normal three dimensional space, the dimensionality can be zero, one, two or three. It should be understood that dimensionality is not so limited, but may be easily expanded if desired. Each dimension of the TCF can be assigned a spatial coordinate from one of the coordinate systems. In the exemplary embodiments described herein, the object space can be either Cartesian coordinates, i.e. x, y, z coordinates, or spherical coordinates, i.e α, β, r coordinates. However, it should be understood that any coodinate system (such as cylindrical) may be adopted and incorporated into the system of the invention.

[00058] In situ transducers which have no IFOM have a single sample and have a dimensionality of zero. Examples of zero dimensional (that is, non-dimensional) transducers include rotational encoders, thermocouples, voltmeters, global position system (GPS), microphones and inertial navigation sensors shown in Fig. 6. Non-dimensional transducers are usually in-siru sensors. A. single sample may have one or more measurements.. For example, a thermocouple may give a temperature measurement. ¹A global positioning system (GPS), on the other hand, may produce latitude, longitude or altitude.measurements in a single sample.

[00059] One dimensional TCFs use one coordinate from the set of object space coordinates to characterize the spatial characteristics of each sample within the TCF. A radar sensor or a depth sounder are examples of a one-dimensional TCF, because each sample in the TCF represents the response or stimulus at a certain range from the transducer. See-Fig. 6.

[00060] Two dimensional TCFs use two coordinates to characterize the spatial relationship of each sample. Most imagining sensors have a two-dimensional TCF. An n x m framing sensor oτ a pan scan sensor, depicted in Fig 6, are examples of two dimensional sensors. The dimensions on the TCF can be any pair of coordinates taken from the coordinate,systems (Cartesian, spherical, etc.).

[00061] In accordance with the invention, all TCF models of a particular transducer have the same TCF configuration. If the TCF is 11 ,000 samples in a 50 by 220 grid, then all models will have 11000 values in a 50 by 220 grid. If the TCF is a 4 x 4 grid, the models of the data will be 4 x 4 as well. There is a one to one correlation between the samples of the measurement TCF and the tcfjnodels, Some common models of transducers include a coordinate TCF model; a temporal TCF model; and a sequence TCF model. Certain transducers have additional models which maybe employed to describe changes between samples particular to the transducer samples, for example, radiometric gain. In addition, models may be added as required to describe additional relationships as they become relevant, Any characteristic used to describe a sample which varies over the TCF may use a TCF model to describe that variance (e.g measuiement duration, gain). [00062] A coordinate model defines the spatial ambiguity of transducer samples. There is a coordinate model for each coordinate of a TCF. For instance, a two-dimensional TCF of 50 x 220 samples would have two coordinate models each with 50 x 220 cells

[00063] The coordinate model associates the transducer samples to the physical world In a framing sensor camera, for example, having a 4 x 4 array of 16 pixels, as depicted in Figs, 6 and 7, each sample has two dimension spatial components, namely α and β, associated in each sample dimension, x and y There are 2-dimensions modeling 3-dimensional space, leaving one dimension ambiguous The spatial ambiguity for a camera illustrated-in Fig 7, is based on the fact that rays pass through a vertex point located at the origin of the transducer reference system to stπke the transducer lying m a focal plane In Fig. 7, the sample in the upper right hand corner (sample x=0, y=4) will be pointing at an angle α (0,3) with respect to the transducer reference system ; and at an angle β (0,3) with respect to the transducer reference system . The sample (0,0) in the upper right hand corner will be pointing at a different angle α (0,0) and β (0,0) Likewise, each pixel has a corresponding alpha and beta measurement associated therewith The alpha and beta measurmentscontained in a TCF structure called a tcfjnodel, so that the data is self consistent Examples of the alpha and beta tcf models for the arrangement of Fig 7 are illustrated in Table I

TABLE I α (x,y)

[00064] Different transducers have different spatial characteristics . Fig 8, for example, illustrates TCFs for four types of sensors including a 4 x 4 framing sensor, a 1 x 16 pushbroom sensor; a 2 x 13 line scan sensor, and a 1 x 12 conical scan sensor The TCF for the 4 x 4 framing sensor is similar to the an angements of Figs 6 and 7 The alpha and beta values in the TCF for certain ones of the roeasurments are shown schematically asarrows labeled for the particular pixel. The orientation of the transducer reference system is . chosen such that the set of coordinates chosen model the ambiguity space (if any) of each sample. < .

[00065] The pushbroom sensor has alpha and beta measurements for the sample look vector in the TCF shown as arrows. The line scanner shown in Fig. S has the alpha and beta values identified in accordance with the TCF of a line scanner. The conical scan sensor also shown in Fig. 8 has a model of the alpha and beta values described as a 1 x 12 array of arrows.

[00066] The values in a coordinate model provide a common way to describe these different spatial ambiguities. The range of one dimension is divided up into a specified number of equal distance intervals called ticks. Fig. 9 illustrates an example of a simple two- dimensional coordinate model for a 1 x 7 sensor . Each-tick represents an interval in a coordinate model. The ticks allow the range of the coordinate to change without changing the tick count for each sample.

[00067] In Table II, the model for each sample 1-7 is shown in object space coordinates α and β for corresponding Image Space Coordinants.

TABLE π

[00068] Note that the sample image space coordinates and vector frame α and β have-the same TCF configuration for a 1 x n sensor.

[00069] Functional models provide -a way to represent functions. For example, the Instantaneous Field of Measurement (IFOM) ; the input/output transfer function (TF); and the frequency response are illustrated in Figs. 10, 1 l and 12 respectively,- In Fig.- 10, the response characteristic for a pixel element vanes over the IFOV, and this variation is characterized as a value over a selected number of spatial ticks. It should be noted that the distribution of spatial and timing coordinates do not need to create symetπcal rectagular arrays. The distnbution of samples may be random in either space or time or both

[00070J Fig. 11 is a normalized response function showing frequency response over a norminal bandwidth Fig. 12 shows the normalized input/output transfei function over a range of stimuli. In each case, the data representing IFOV Response, frequency response and I/O response may be expressed in terms of the TCF -for each sensor element (i.e may vary as a function of a sample position with the TCF).

[00071] The invention thus provides a means for not only modeling the sample measurements, but also provides a means for modeling the various characteristics associated with those transducer measurements A sample has a set number of measurements Each measurement has an arbitrary number of properties and characteristics. For the invention, properties are simple name-value pairs e.g frequency - Hz, angle - radians; volume - db; color - yellow and the like

[00072] Characteristics are a combination of related properties Characteristics may also include a curve, such as a simple sequence of numbers that maybe interpreted as a graph or curve. These curves represent variations inherent in measurements. In a camera, for example, depending on the position of the pixel with respect to the central axis, the sensitivity of the pixel may be higher or lower than a nearby pixel Alternatively, the frequency response of a sensor may vary over a range. The curve in Fig 11 illustrates this characteristic. Fig. 12 illustrates a response of a pixel or detector compared with the stimulus In other words, the response is a function of trie stimulus and must be taken into account. The correction factor for each pixel can be characterized by using a TCFjnodel of the transducer

[00073] The temporal model defines the relative time delays or offsets of each sample within a TCF relative to the first sample. The temporal model uses the TCF. Like the coordinate model, the values in the temporal model are given in time intervals also referred to as ticks. Table III illustrates an example of a two dimensional temporal model using time - ticks TABLE III

[00074] Functions or curves can be described by using -a numeric function model or . fjnodel. The range and/or endpoints ofthe independent variable comes from the calling element for the tjnodel. The fjnodel contains the set of data points representing the . , dependent variable spread linearly or logarithmically across the range ofthe independent variable. There may be one or two independent variables such that two or three dimensional functions can be modeled.

[00075] In a framing sensor such as shown in Fig. 6, all samples of a TCF are taken simultaneously, that is, there is no time offset between the First measurement in a sample and any other measurement in a sample in the frame. Accordingly, the temporal model of the framing sensor is represented by a 4 x 4 matrix of zeros in each of the boxes.

[00076] Fig 6 also shows a pan scan sensor, where each sample in a line is taken at the same time. The second, third and fourth lines are sampled on later ticks. As shown, the first line is at tick time zero (G) and lines 2, 3 and 4 are on successive corresponidg ticks (1), (2), . and (3) respectively,aε illustrated by the numerals inscribed in the boxes. It should be noted ' that tick increments can and should be much faster than the increment between samples so that nonlinearities in timing can be characterized.

[00077] For the 1 x 15 push broom scanner, as illustrated in Fig. 6, the samples are takeri .at the same time tick -zero. Thus the zeros are inscribed in all of the boxes. For the I x 15 line scanner in Fig. 6, the measurements are taken on successive ticks, hence the numbers 0, 1, 2 ....14 inscribed in the boxes.

[00078] The TCF is comprised of a set number of samples. Each sample is comprised of a set number of measurements. For instance, a camera may have 1000 by 1000 samples, called pixels, within its characteristic framework. In the example, the 1000 X 1000 samples makes an image having 1 million pixels (or 1 megapixel). If the camera is a black and white camera, then each-sample has one measurement that may be a gradient of black, e g 256 grey scales If the camera is a color camera, then each sample has three measurements, one for the gradient of cyan, magenta and yellow, or red, green, blue In either case, the samples are contained in the TCF, and there will be a sample of 1 million samples Each sample within the TCF has a corresponding coordinate, time and sequence to describe its relative or internal spatial orientation, its internal or relative timing relative to other samples within the TCF, and its sequence order in the transmission stream such that it can be sorted into its internal sample sequence For example, for the black and white camera, the data will be sent in a string of binary data The data may look like a string of numbers ***, ***; ***; This data string represents, for example grey scales whic follow the TCF of the sensor

[000791 If the device is a color camera, which has three measurements, for example Red (R), Green (G), and Blue (B) for each sample, the data will be sent by interleaving the binary measurement from each measurement. The data will be in groups of three measuments which have the form: ***, &&&, %%%; *" *,&&&,%%%

[00080] The sampling order is the order in which the samples are taken The sequence of samples can be any desired older The sampling order is given by the spatial or temporal orientation of the samples within a TCF, This order may be disturbed during the serial transmission of the data The order in which the samples are transported shall be the same as the order in which the timing and coordinate TCFs are transported. To retrieve the onginal order, the coordinate TCFs can be sorted. to retrieve the spatial order. The original temporal order will then result from the similar sorting of its TCF. To facilitate the sorting, a TCF will be used which gives the intended numenc position of each sample in the transported TCF (Fig 13).

[00081] The order in which transducer samples of a measurement TCF are transported through a communication channel i e. Sequence TCF, may vary greatly and may not always represent a left-o-nght, top-to-bortom, fronl-to-back scan of the TCF structure. One way to organize the data such that the data is organized spatially correct is to sort the data samples according the the coordinates of the coordinate TCF's This sorting although possible may be a computationaly intensive task. To facilate the sorting a sequencing TCF is introduced (Fig 13.). [00082] One way to describe the sequence is to order all of the samples in their intended order aad give them a serial sequence number using the lefl-to-nght, top-to-bottom, front-to- back sequence This organization has nothing to do with the temporal order in which the samples were acquired. It does relate to the relative spatial organization of the samples within the TCF (i e coordiante TCFs). There may be situtions where the intended organization of the data is not orthoginal (e g a random spatial distribution) In these situtmons it may be benefitial to assign a coordinate to the intended position of each sample If the TCF is a 2-dιmensional structure then two sequencing TCFs would be used, one sequence TCF for each coordiante One sequence TCF would indicate the column position of the sample and the other sequence TCF would indicate the row position of the sample Samples do not need to bepositioned at every column-row orderd pair If the spatial structure of the data is not orthoginal, ihen the non-orthoginal structure shall be described using an all inclusive orthoginal coordinate space Known approaches to the sequencing TCF implement the senal sequence number or the coordinate sets to represent the row, column, plane position of the samples

[00083] Encoding is a characteristic that must be defined for each measurement The encoding characteristic defines the bits, the data type, the units, and the range properties of a measurement The encoding characteristic provides the information required to allow applications to parse data within a cluster The model can provide any number of characteristics for a particular measurement Some characteristics include frequency response, instantaneous field of view and gain

[00084] The model can specify dependency, which is defined as a condition wheie the value of a property is dependent upon another property, or is dependent upon a measurement value generated by another transducer As indicated above, measurement is specified or identified as a name-value pair. To specify a dependency, on the other hand, a property has a name-dependency identifier e g gam - temperature, and the like, rather than a name-value pair The invention uses the dependency identifiers to define the relationship between transducers to thereby define a system

[00085] A system is an aibitrary set of transducers The invention characteπzes a system, by providing the individual models of the transducers and then specifying the mterdependency of the properties of the transducers using dependency identifiers |00086] As an example, a first- transducer may have variable gam dependent upon temperature. A second transducer may be a gain.sensor In a system incorporating these transducers, it would be necessary to define the properties of both transducers, and specify that the gain characteristic is dependent upon another value (measured by the gain sensor) That is, a property in the gam charactenstic would have a dependency identifier, and an association between the gain charactenstic of the data from the gain sensor would be specified.

[00087] In accordance with the invention, the interdepend encies are specified outside of the sensor models themselves. This approach enables system specifications to incorporate sensor models without changing the sensor models That is, systems can utilize "plug and play" sensor models.

[00088] To minimally characterize a transducer one must answer the questions of "what" is the measurement, "where" in space does the measurement relate to; and "when" in time did the measurement occur. The where (space) and when (time) charactenstics are answered.by a combination of the interior and exterior orientation of a transducer It should be noted that the inteπoi orientation is only applicable foi remote transducers There is no geometric interior orientation applicable to in-situ transducers

[00089] The transducer onentation characterizes the space-time relationship or geometry of the transducer data The interior and exterior orientation of a transducer complements each other to give a complete space-time relationship of the data The interior orientation is an orientation that remains constant with respect to the transducer reference frame independent of transducer position, attitude, motion or time This orientation accounts for any of the scanning mechanics or the space and time relationships between the samples within the transducer characteristic frame. The external orientation characterizes the position and attitude and timing relationship of the transducer reference system with respect to an external reference system. The world reference system is an external spatial reference system that will be the common reference system for all geo-spatial data (e g ECEF reference system).

[00090] A system of Coordinate and Reference System is used throughout this discussion Figs 14 and 15 respectively show the Cartesian and polar coordinate systems used to desciibe coordinates [00091] Figs 16 and 17 show two reference systems used in this discussion. Fig 16 shows an Earth Centered Earth Fixed (ECEF) coordinate system (further defined by WGS- 84). Fig 17 shows a transducer reference system. If a platform reference system is required, a transducer shall be assigned to it so that it can be measured -There is no assigned oπentation of the x, y, and z axis to the transducer. Any orientation may be used, depending which onentation works best for characterizing the interior orientation of the transducer data The description of the interior orientation may be expressed in terms of selected system coordinates (x, y, z, α , β , r). These coordinate assignments may be used to describe the interior orientation of the coordinate system axis to the transducer data.

[00092] Figure 1 S shows the convention used for determining the Euler angles (ω,φ,κ) for rotation transforms Particular attention should be made to the order in which the rotations (K then φ tfien ω) are made when defining the orientation of a transducer relative to the external reference. The order is reversed when describing the oritation of the external reference system relative to the transducer reference system

[00093] Key dependencies between transducers are position and attitude and their first and second derivatives Position may be measured with Cartesian or sphencal coordinates The attitude is measured with ω,φ.κ known as Euler angles

[00094] Fig 19 schematically illustrates an exemplary sensor S-m coordinate frame Fl expressed as xl, yl , zl, secured in a platform (e.g. m an aircraft). A in coordinate frame F2 expressed as x2,y2, z2 by an arm of length Rl. An IMU on the aircraft senses the attitude of the platform frame in coordinates co,φ,κ.; and a GPS senses the position of the sensors in the platform relative to the Earth . The attitude of the sensor S with respect to the IMU is given as a quantity derived from gimbol sensors Sx, Sy; Sz in frame F2 expressed as gX₂, gya, %^2 Accordingly, all necessary coordinates are available. It is not unusual for the frames to have a selectable or time varying attitude which may be measured and recorded over time

[00095] Using known coordinate transformations, the attitude of the sensor frame S may be fixed with respect to the position of the MU and the position may be found relative to the GPS The attitude of the IMU may be translated to the GPS position assuming the IMU and GPS form a ngid body. For example, the position dependency of (xl, yl, zl) of the sensor frame A with respect to the aircraft of frame A may be expressed as fixed numbeis, such as (12,005, -4 452, 0216) because the ami length Rl is fixed These numbeis iepiesent the fixed positional difference, i.e ((xl-x2), (yl-y2), (zl-z2)), between the origins of the frames Fl and F2.

[00096] Similarly, when the attitude of one transducer is determined (fixed) relative to another transducer, the attitude dependency of (ω,φ,κ) is specified as fixed numbers, such as (0.86, -0.86, 0.13). These numbers represent the difference angle between the axes of one transducer with respect to another transducer. Thus, the positional transformations define the relationship between coordinate systems for related transducer frames. If the attitude varies then the attitude dependency will retarget the appropriate sensor.

[00097] Positioning sensors are treated like any other transducer, This approach is an important concept of invention. Position dependency may be specified based on the value of a transducer measurement. For example, the attitude of gimbol sensors (Sx₁ Sy, Sz)may measure the attitude of a transducerf relative to the attitude of an IMU. The position of a global positioning system (GPS) sensor with respect to Earth Center Earth Fixed is dependent upon the position measurements measured by itself. Tn either case, the attitude position reading of a transducer is handled the same way as any other data There are no exceptions The only difference between the gimbol measurement and an image measurement, for example, is that the TCF of the gimbol is defined uniquely for the gimbol and the TCF of the image sensor is defined uniquely for the image sensor. Timing and sequencing may be different, but again, these aie handled in accordance with the TCF of the sensor. All data models and identifieres follow or are layered on the TCF of the corresponding device. Therefore, the system has a uniform and generic process for handling and communicating information. In addition, because the data is accurately timed and sequenced, it is possible to relate the data of different transducers in space and time.

[00098] The following is a simplified example from Fig 19 which is intended to illustrate how these interdependences work.

[00099] Sensor S is a scanning sensor or camera in sensor Frame Fl. Sensor S is attached to an arm of a given length R 1. The arm is attached to an aircraft A, in a platform frame Fl in an aircraft A, with attitude measured by an IMU and position measured by a GPS Sensor S2 (Sx, Sy₁ Sz) comprises roll gimbol encodeis that measure the attitude of sensor S relative to the aircraft gX₂, gy₂, gZ₂. Sensor S3 is global position system GPS that measures the position of theplatform relative to an earth-center earth-fixed (ECEF) coordinate system Sensor S4 is an inertial measunment unit IMU that measures the attitude of the aircraft relative to ECEF,

[000100] The resultan! exterior attitude and positions are the result of individual rotations and translations of the coordinate frames.

[000101] Many transducers are in reality a system of transducers, A transducer system topology provides the fundamental descriptions of how all of the transducer data relates Not all systems are alike so the system topology is descπbed on a system to system basis. This specification defines four types of relations Attached, Dangled, Position, and Attitude.

[000102] An Attached sensor is typically an m-srtu sensor measuring other parameters to support its host sensor The Attached relationship will be described in the attached sensor's nomenclature. An example of an attached sensor would be if one had a diagnostic sensor attached to the pnmary imaging sensor measuring another variable (such as vibration of temperature) An Attached element is empty and simply references another sensor. The presence of an Attached element means that the sensor referenced by the dependency element should be treated as if it had the exact same location and attitude as the sensor referenced by the Attached element

[000103] The Attached relation is used to attach sensors to transducer characteristics which describe changing parameters about a transducer system, such as receiver gain The Attached relation implies that there is a characteristic to "hook to". The sensor is measuring a changing parameter for that one of the transducer characteristics that TML models

[000104] The Dangle dependency is like the attached dependency except that there is no internal hook to a transducer characteristic. The Dangle transducer simple hangs off of another transducer and provides additional measurement relating to the transducer as a whole An example of a dangle relation would be a temperature measurement of a transducer's detector, to the vibration load on a particular transmitter.

[000105] The Position relation identifies the position of a transducer relative to the earth or another transducer The Position can be a fixed location or it can be variable, where the position is measured by a sensor The Attitude relation is similar to the position except the orientation of a transducer is described relative to the earth or another transducer If the orientation is variable the orientation maybe desciibed with a sensor, The Position and attitude relations are the principal relations for determining the exterior orientation of any transducer.. . . . . .

[OOOl 06] -The invention also provides a method for communicating data. In accordance with the invention, the transducer models are sent first followed the actual data generated by the transducers. .The models enable applications to correlate the data of transducers by . describing (1) what the data represents, (2) how to parse the clusters of data that are sent and (3) how to calculate the dependencies in the data, especially the dependencies of position and attitude. _. . . .

[000107) Each transducer .broadcasts data in clusters. The transducer model defines the size of the cluster. The transducer broadcasts these clusters at its own rate. Each cluster has a time stamp. The cluster contains either a set number of transducer characteristic frames (TCF) or a set fraction of a TCF. Each TCF contains a specified number of samples. The temporal model of the transducer specifies the time relationship between the time stamp of the cluster and the samples within a cluster. An application uses the temporal model to calculate'thσ time of a specific sample within a cluster. The time stamp on the cluster represents the time of the first TCF in the cluster. If multiple TCFs are in a cluster the other TCF time stamps can be calculated by adding the TCF period to the time stamp. If a TCF is broken into multiple clusters all clussters shall have the same time stamp.

[000108] A system defines that the properties of certain transducers are dependent upon the values of the data created by other transducers. Most notably, the position of one transducer will be dependent upon the readings of a position sensor. Since each transducer or sensor broadcasts at its own rate, there will not be samples from two transducers with the exact same time stamp. The resultant value for a transducer is calculated by interpolating the values from the other transducer.

[000109] The following example is intended to illustrate how to interpolate these dependent values in a system of three transducers. The system includes an attitude sensor Sa; a position sensor Sp; and an image sensor Si. The system broadcasts the following clusters depicted in Fig. 20 with the specified time stamps.

[000110] Tai-2456, attitude (pitch, roll, heading)

[0001115] Til, 2635, image . . ' (000112) TpI , 2762, position (latitude, longitude, altitude)

[000113] Ti2, 2789, image .

[000114] Ti₁ (32nd pixel)

[000115] Ta2, 2812, attitude

[000116] Ti2, 2893, image

[000117] Tp2, 2910, position,

[000118] In this example simplified to illustrate the concept, the image sensor has 100 TCF in each cluster. Each TCF is one tick later in the time stamp It is possible to calculate the point on the earth to which a set of pixels (samples) in a picture is pointing For example if the first sensor image is initaited at time stamp 2789, as shown, and the 32nd pixel in the cluster has time stamp 2821, i.e. 2789+32 (one tick per pixel). The time in quesiton i e of the 32nd pixel Ti is therfore: 2821.

[000119] In order to calculate the postion (latitude , longitude and altitude ), an interpolation is pei formed based on the readings taken at time stamps Tpl=2762 and Tp2=29l 0 which bracket the time T-2821.

[000120] The position at time T=2821 is calculated by interpolating between time stamps for Tpl=2762 and Tp2=2910.

[000121] Likewise, the camera attitude (pitch, roll, heading) for the time in question, i.e. T=2821 may be intrpolated from the attitude readings taken at TaI= 2456 and Ta2=2812 from the data shown above.

[000122] The invention may be described as a method and apparatus for acquiring in a universal way transducer data from the plurality of diverse sensors or emitters. The method is particularly useful for efficient and accurate real-time capture and observation of the data. The invention facilitates real time capture and utilization of the data because the data is presented in such a way that pertinent information is modeled in accordance with the Transducer Characteristic Frame (TCF). As a result, the data follows a scheme which is uniform and and self consistent, and which permits the system to readily accept new forms of transducers as they become available without significant modification of the system. In short, the system accepts transducers as so called "plug and play" devices. . . .

[000123] The invention, allows for accurate and precise acquisition of transducer data whichmay be readily processed, interpreted, archived and retrieved with known accuracy and precision and without corruption of -the acquired data.

[000124] The universality of the data format -allows for the importation of the data by standard communications protocols. _

[000125] The invention compartmentalizes the infonnation associated with each transducer sensor in such a way that it is possible to collect the information with reduced overhead.

[000126] Transducers have diverse characteristics tailored to function or performance requirements. However, any transducer may be characterized in .accordance with the model described herein which exemplifies the essential characteristics of the transducer. The TCF . is only part of the characterization. . Thus there is a self consistency of all models of tbe-data for any transducer.

[000127] It should be understood that the sensor response is fully still characterized by the "what", "where", and "when" characteristics. The "what" characteristics describe: what is being measured; encoding and formatting rules are used to describe the measurement; the units of the measurement; the uncertainties (absolute and relative) of the measurement; the frequency response of the detector;- the input-output transfer function; and the instantaneous field of view. . .

[000128] The "where" characteristics describe where (spatial position) in space the measurement corresponds. The spatial relationship of the sensor with respect to the platform is characterized by the sensed orientation of the platform and a time tag. If one wishes to characterize the position of the platform relative to some other location, for example, an earth surface station, the position and orientation of the platform relative to the earth is sensed and

[000129] The "when" characteristics describe when in time the measurement corresponds. . A time tag (tick) maintains relative timing between samples and frames, and an absolute time can be measured with a time sensor measurement which has a relative time tag associated with it. Time tags give relation timing between TCFs The timing TCF gives relative timing within the TCF and the world clock sensor provides absolute time Time tag in start tag of world time sensor correlate world time to system time tag.

[000130] If one wishes to know the relationship of a sensor relative to some remote location, it is necessary only to look at the various data and correlate the information by interpolation. In other words, the sensor data may be fused or summed with the platform data; and the platform data may be fused with the earth station data. In short therefore, it is only necessary to collect "what"; "where" and "when" data necessary to i elate the components in time and space. It is not necessary to calculate the various relationships among the components. Accordingly, the raw data for each sensor is collected independently of other sensors, The arrangement therefore simplifies data collection because complex calculation steps are not performed pnor to collecting and charactenzing the data. The arrangement thus avoids problems associated with data corruption, because data is preserved as it is taken without modification

[000131] In Fig 19 the chain of relationships is traceable back to some desired reference point e.g an Earth Centered Earth Fixed Reference ECEF system AU sensors should be traceable to ECEF. As shown, the position of the aircraft A relative to the Earth is defined by the earth platform vector R₂, which can be characterized as a absolute radial distance with an azimuth and elevation. Alternatively, the vector 2 may be characterized by Cartesian or spheπcal coordinates.

[000132] As can be appreciated, any consistent coordinate system may be employed to characterize these data Accordingly, it possible to know in real-time the position/attitude with respect to the sensor relative to the ECEF reference system. The above described characterization of sensor data transforms one reference system, for example, the reference system of the sensor to an ECEF reference system

[000133] In order to model the sensor data and represent it as a temporal model, each sample must have associated with it the time when it was acquired and what was being sampled at that instant For example, in the sensor data frame, there will be associated data in similar arrays to describe the timing and spatial data for each sample The values in each corresponding location of the timing tables relate to the relative time that the sample was acquired in relation to the other samples in the frame. The sampling rate within a TCF as well as the rate at which TCF are acquired may be quite different for different sensors

[000134] Fig. 21 illustrates this concept. Sensor 1 data occurs at a higher frequency and as different times than sensors 2-4 this is because it may be necessary to receive data which changes frequently, e g image data more often than condition data, e.g , temperature According to the invention, all data is time tagged so that the relationship of the data from any Sensor may be related temporally to any other sensor As previously noted, the data for any sensor maybe interpreted to relate it to a time tagged sample of any other sensor.

[000135] As noted above, it should be understood that the sampling order and transmission order maybe very different Data may be acquired in a certain sequence and transmitted in yet a different sequence and the received data maybe unscrambled at the receiving station in order to reconstruct the image or data In this connection the spatial data, i e. spatial vectors, may likewise be unscrambled using the a-priori information characterizing the sensor For example, if a senes of vector values are transmitted m a transmission order, the receiving station, being responsive to the vector values, may unscramble the data by comparing the vector information transmitted with the vector map of the sensoi frame In other words each spacial vector defines or characterized the corresponding sensor sample, including the location of the data in the sensor frame, and thereby orders the data accordingly. Indeed the transmission of sensor response samples may be random, but as long as the corresponding spatial coordinates (i.e vectors) are scrambled in the same order as the sensor response samples, the sampling order can be recovered by sorting the vectors in the spatial frame, then sorting the response frame in a similar manner.

[000136] Fig. 22 generally illustrates the overall system 100 according to the invention, employing a collection system 102 and a processing system 104 coupled over a link 106. The collection system 102 includes one or more sensors producing data 108. Each sensor has a corresponding model 110. Data generated by the various sensors 108 is transmitted over the link 106 in a common data and sensor model format The processing system 104 includes an application module 112 which receives and reads the data The application module 112 is responsive to a library 114 of common data format processing functions. Accordingly, all of the sensors may be modeled in the same way and their outputs may be processed and interpreted in a common and uniform way. The uniform modeling of all data of a transducei, in effect, constitutes preprocessing of data in such a way that it is self consistent and uncomφtable.

[000137] In contrast, Fig 23 shows a conventional arrangement In this arrangement, sensor data is collected in a common format. Typically this is a proprietary format which does not include a model of the sensor. The sensor data is sent to the processing system, where the application employs a unique sensor model to process the data The disadvantage is that each time a new sensor is developed, a new model must be incorporated into the system.' Whereas, with the invention, the models are transmitting with the data and the sensor consistent In conventional systems, processing occurs concurrently with or before modeling. Therefore, the data is not self consistent and may be corrupted before it is archived

[000138] Fig. 24 illustrates an airborne collection system 120 in which the data from sensors 122-1...122-n is formatted in data formatter 124 and transmitted over the link 126. The airborne system also includes ancillary data means 128-1...128-n for each corresponding sensor 122-1 ..122-n. The ancillary data means may be tailored for the corresponding sensor model. The ancillary data is sent along with the sensor response in. a data stream 128 as illustrated The transduce, data description may likewise be transmitted at the commencement of the transmission

[000139] Fig 25 illustrates a ground or terrestrial receive, process and display station 130 in which the data carried over link 126 is coupled to input parser 132 which separates or demodulates the data for each sensor into separate streams 134-1....134-n respectively. The streams include the sensor data and sensor data description for each sensor. The data is coupled to aprocessor module 136 including a processors 138-1. .138-n for processing the sensor data for each sensor, and a corresponding configuration module 140- 1...140-n. for processing the sensor data description in order to properly configure the processor handling the sensor. Each processor 138-1. .138-n may be coupled to an appropriate display 142- 1. 142-n. It should be understood that the various processing, display and configuration modules may be combined in an appropriate workstation as desired

[000140] As illustrated, the sensor data description is appropriately matched in the processor 136 for the sensor data to be processed . The software libraries, 142 are adapted to facilitate the universal interpretation of sensor data in the processor. 1000141] The model of the sensor system topology describes the relationship of the various sensors used in the multi sensor system. This modeling provides a cohesive picture to fuse all of the data together for the various sensors on board a platform. This model describes the chain of sensors and what parameters, if any, are modified by previous sensor measurements in the chain. For example, a detector look direction relative to a transducer is modified by the gimbol angles relative to the internal measurement sensor of the platform and the latitude of the platform relative to earth. This sensor environment data enables vectors to be manipulated and common reference frames to be converted into other common reference frames.

[000142] According to the invention, only appropπate parameters need to be captured such that the measurement errors can be accumulated throughout the chain to give the processes indication of resultant measurement error

[000143] From the foregoing it can be seen that it is possible to tie each sample and the sensor response frame to each sample in the timing and spatial frame. Accordingly, each sample can be mapped to any surface with relative ease The arrangement provides for rapid targeting based solely on data collected from the sensor system

[000144] In accordance with the invention the sensor data and metadata to describe the sensor are packaged in a form for transport to a remote location or to an archive. The shell is generic and uses a compatible markup language as a carrier for the data elements of the model, e.g : transducer markup language (TML) The shell does not add significant overhead to the basic data elements

[000145] The following is a description of the transducer markup language (XML) employed in the invention, The description has the material subdivided into a series of sections with section headings followed by TML text and, where appropriate, followed by explanatory text discussing the feature of interest.

[000146) Stream header

_<>ELEMENT tranεducerMli (system, (system_update* |data*)

< ¹ATTLIST tranεducerML version CDATA #FIXED "0 9beta">

[000147] The TML document represents a stieam. The opening tag initiates the stream A closing tag terminates the stieam. The fust element in the stream should be a system element^, The remainder of the stream is any sequence of syεtem_update elements and data elements

[000148] The element t ransducerML is the default root element Specific protocol implementations of TML may need to replace the root element

[000149] The default root element designates the veision of the schema (document type) When implement in protocols, the namespace designation, for the elements will indicate the version

[000150] System

[000151] System contains a sequence of models, sensors and dependencies, in that order. A system has a unique identifier

[000152] Models

[000153] The models element contains zero or more model elements The model element contains a datapoints element and may contain a description element The description element is geneiic throughout the schema

0 0154| mo e has an identifier unique within the system definition

1000155] A model defines a curve The data points are evenly distributed across the x-axιs The values are the positions relative to the y-axis The sample model M000l defines the curve shown in Fig 27

[000156] An empty set of data points such as model ST001 means that all of the values aie zero

[000157] Sensors

[000158] ensor N

[000159] A sensor has a identifier unique withm the system definition Preferably, sensosrs would use a uniform resource name (URN) as their identifier In a protocol implementation, a stream could begin with a simple empty sensor element as follows

[000160] The subscnber could check if it has this sensor definition already locally stored If not then the subscriber could look up the sensoi in some well-known repository If that should fail, then the subscnber could ask the publisher to- send the complete sensor definition

[000161] Within the stream, elements would reference the stieam by its shorter ID attribute rathei than its longer URN atUibute 1000162] Frames

[000163] A sensor contains a description and a single frame, A frame contains an space- time model and a single sample definition

[000164] The data elements wilhm the TransducerML stream represent a clustei A cluster may contain one frame, multiple frames, or a fraction of a frame The number of frames within a cluster remains consistent for a particular sensor The count attnbute indicates the number of frames per cluster.

[000165] Some sensors such as sound have very small frames It is useful to bundle several small frames into a single data element (cluster) to reduce overhead

[000166] Dividing a frame that is especially large (more than 500 kilobytes'?) may make it easier to parse and check for errors. If a cluster is a fraction of a frame, then the count attnbute will be less than I₁ as in "025" A sequence of clusters, that is data elements, that are the same frame would all have the same tune stamp

[000167] Space-time model

[000168] A space-time model has a time model, zero or more axis models and a sequence model The scf_dimeπsion attnbute indicates how many axis models there should be

(000169] With each of these examples, the models are straight zeroes, meaning that the samples are all instantaneous A more complex example is provided later in this document

[000170] Sample

[000171] A frame consists of samples The space-time model defines the relationship of the samples to space and time A frame will have a set number of samples For example, if the sensor provides an. image that is 1000 x 1000 pixels, then the sample size is 1 million

[000172] Each sample consists of one or more measurements If the sensor provides a monochromatic image, then each sample is one measurement of a gray scale If the image is color, then each sample is thiee measiuements foi red, green and blue MuI ti -spectral analysis

can actually create thousands of measurements for each sample

[000173] Measurements

[000174] A measurement contains a description and an encoding followed by zero or more properties or characteristics in any order.

[000177] The previous fragment defines a sample o three measurements or simplicity o explamation, the example above does not include some mandatory elements which are not relevant to the discussion The first measui emeiit is 6 bits, the second is 8 bits, and the third is 6 bits The total sample is 20 bits, which can be expressed with 5 hexadecimal characters shown in Fig 28

[000178] Using the sample encoding, the hex string "558Bl" would represent a first - measurement value of 13, a second measurement value of 57 and a third measυiemeπt value of 9

[000179] Padding

[000180] Measurements are given in bits The character data within the data elements is in hexadecimal encoding (0-9A-F) to avoid any special characters that would choke the XML parser If the measurements do not map evenly over four bits, then the character data is padded with zeroes at the very end of the cluster

[000181] Characteristics

[000182] Charactenstics provide more fidelity than pioperties A charactenstic element can contain a model element and zero oi more property elements Charactenstics enable us to communicate complex properties such as frequency response For instance, the following characteristic tells us that the frequency response is a typical bell curve extends from 300 μHz to 700 μHz

[000183] The frequency response charactenstic is shown in Fig 28

[000184] Properties

f000l 85] Descriptions and properties are generic to this schema. Descriptions are a collection of properties Properties are simple name- value pairs We take this generic approach for two reasons, First, it is impossible to anticipate all the properties necessary to communicate transducer information Second, we are able to treat all properties generically for display purposes or use within tools,

[000186] Measurement value dependencies

[000187] The attribute dependencyJD is set for reference later in the dependencies section. For instance, this characteristic flags the gain property of the stim_respjfcn (stimulus response function) characteristic as dependent upon some other sensor's measurement value A dependency will reference this dependency identifier in the dependencies section of the system definition

[000188] Dependencies are defined outside of the sensoi definition m order to enable plug- anά-play of sensors into different systems

[000189] Dependencies

[000190) The dependencies section enables us to plug-and-play sensors together into a system definition. We are primarily concerned with, plugging together the position and attitude of sensors. The position and attitude are the key properties necessary for most sensor fusion efforts. However, any property of a sensor can be dependent upon another sensoi measurement

[000191] The dependencies element contains zero or more dependency elements. Each dependency element references a particular sensor by its unique identifier All the dependencies for a particular sensor should be defined within a single dependency element

[000192] A dependency element contains either an attached element or a position and attitude element followed by zero or more dependentjvalue elements.

[ c/dependencαess 1

[000193] Attached, Position and Attitude

[000194] An Attached element is empty and simply references another sensor The presence of an Attached element means that the sensor referenced by the dependency element should be treated as if it had the exact same location and attitude as the sensor referenced by the Attached element.

dependency sensor_ref="S005" > I ottached sensor_ref="S00l"/> |

</deρendency> |

1000195] The Position element defines the x, y and z dimensional position of a sensor relative to another sensor. The difference is simple arithmetic The value added can be either a number or a measurement value reading If it is a number, then it must be accompanied by an accuracy value The following fragment states that the position of sensor S00l is dependent upon the location of sensor S002

[000196] The Attitude element defines the omega, phi and gamma (ω_;φ,γ) angle positions of a sensor relative to another sensor The Position and attitude of a particular sensor can be dependent upon different sensors

[000197] Measurement references

[000198] Changes in position and attitude are calculated from sensor Measurements. The measurement_value element defines the dependency. The measurement_value element refeiences the unique identifier of a sensor sample measurement defined in the sensors section

[000199] Any sensor property can be dependent upon another sensor measurement The following completes the dependency of the gain property for a sensor upon the measurement of another sensor

a a

[000201] See section [000175] Encoding

[000202] System updates

[000203] A system of sensors may change aftei the stream of data has begun These changes come as system_uρdate elements The system_ιφdate can contain new models, sensor updates or dependency updates For sensor updates and dependency updates, only the information that has changed is sent Updates are sent within the proper nested elements

[000204] In the following example, only the frequency response (freq_resp) charactenstic of measurement MS00 lE00l has changed However, measurement characteristics are nested within sensor, frame and sample elements A graphical representation of the frequency response is shown in Fig 27, (which has been earlier exemplified as a model curve )

[000205) Space-Time model example

[000206] Sequence model

[000207] The sequence model is read left-to-nght, top-to-bottom, front-to-back across the dimensions of the space model In this case, the x-dimension and y-dimension aie both 4, as indicated in their sample property

[000208] The other data points map to the physical dimensions m the sequence specified in the sequence model

[000209] Document type definition

[000211] [ ] The attached APPENDIX A contains a comprehensive example of

Transducer and is part of the disclosure therein

TransducerML

Format Specification

Version 0.9beta 25 August 2003

Developed Bv: IRIS Corporation Ann Arbor, Michigan

Proprietary - Property of Innovative Research. Ideas and Services Corporation ("IRIS") Distribution authorized to U S Government Agencies only, contains proprietary information

©COPYRIGHT IRIS CORPORATION, 2003 1 Summary

This specification was motivated by four principal requirements: 1) to rapidly and precisely locate particular measurements (e.g. target image) in space and time and enable the prediction of resultant errors on the final measurements, 2) provide a means to enable a single general purpose transducer (e.g. sensor) processor to process data from any transducer and synergistically fuse data from any set of complementary transducers, 3) provide a method for the common exchange and archive of raw transducer data over point-to-point and networked communication systems and on any recording medium, 4) provide a common method for the archive of "raw" transducer data preserving the geometric and measurement properties for reprocessing at a later time.

It is desirable to provide a sensor acquisition standard and compatible sensor processor in order to overcome the disadvantages described in the background by prior and current arrangements and meet the requirements of the prior paragraph. To accomplish this it is imperative to capture all pertinent digital sensor data events at the source while maintaining space-time relationships of all events and recordings. It is even more desirable to extrapolate these capabilities to capture and describe any transducer data. A transducer includes both sensors and transmitters.

This document describes a self-describing common transducer data format incorporating a common transducer model. This format will be referred to as TransducerML (TML). The TML data stream describes events as they happen at the source in a running time sequence. The data stream may be played back at the destination at the same time or at some later time in order to replicate events exactly as they happened at the source. This document describes a transducer acquisition format to enable the acquisition of transducer data and describe any transducer in terms of a common transducer model. Transducer parameters described using the model configure the processor to efficiently process the transducer data. This would theoretically enable a single processor to process any transducer's data, as long as the processor could process the full capabilities of the transducer characterization model.

The document begins by defining a new data exchange concept specifically tailored for transducer data (i.e. not display based). The concepts were initially developed for sensors but eventually expanded to handle transmitters as well. This was necessary because active sensors provide their own illumination of the object space. The response of these sensors is also a function of the illumination energy. So for these types of sensors it is necessary to characterize the transmitter as well. The format captures data created from multiple simultaneous events (transducer measurements) at the source and can replicate those events at a destination in the same time relationships as they occurred, at the same or different location, and at a later time ranging from nanoseconds to years. To make the format useable to a wide range of transducer systems it incorporates a methodology for characterizing transducer data which is common for all transducers. This characterization is utilized in the data format to self-describe the data structure to a "common" transducer processor. The transducer model and exchange format go to great lengths to characterize space and time relationships of the data and to characterize every measurement error. The TransducerML data stream represents events as they happen at the source in a running time sequence. The data stream may be played back at the destination at the same time or at some later time in order to replicate events exactly as they happened at the source. A sensor exchange and modeling concept known as the Transducer Mark-Up Language (TML) is provided which describes any transducer in terms of a common transducer model and provides an efficient data format for the exchange of the model and transducer data together or separately, thereby eliminating the need for developing unique implementations (separate support data extension as is currently done with the NITF format) for each new sensor. Transducer data captured and described according to the specification may be processed by a single "common" transducer processor. As new transducers are invented they can be described such that the common transducer processor may automatically adapt to process them.

The transducer model "describes the data" and relates the data to real world parameters. The detailed transducer mechanics are transparent. Transducer data is produced (response) by any receiver (sensor) or sent to (stimulus) any transmitter. A feature of the transducer model is the definition of the transducer characteristic frame, this is a unique frame structure for a transducer which contains the minimum set of samples required to characterize the transducer. The frames from different types of transducers are different. Each frame has a dimensionality indicating how many dimensional coordinates the data structure of the transducer requires. The characteristic frames can be used to acquire the transducer data and to associate modeling data to the transducer measurement data because there is a one-to-one relation between data and model. This is useful for characterizing the interior orientation of a transducer. The transducer model has corresponding frames used to describe spatial and timing relationships within the transducer data. For example, the dimensionality of an optical camera is 2; this means that the sensor generates data in a two-dimensional array. On the other hand the dimensionality of a thermocouple or accelerometer is zero. Typically, one sample, for example, temperature or acceleration, repeats on a periodic basis. Non-dimensional or zero dimensional transducers have only one sample in the Transducer Characteristic Frame. In such an arrangement, there is no dimensionality defined for the thermocouple or accelerometer because there is no implied special relationship between the samples in the frame.

With this common modeling capability sensors (real or virtual) can be used to describe dynamic parameters (metadata) used to describe a transducer's operating environment. The same modeling technique can be used to describe all of the sensors. To describe the relationship between the sensors a system topology concept was developed based on transducers as nodes and relationships as links between the nodes. Similar methodologies are used to model data structures in relational databases.

2 Background

The transducer data format described herein was demonstrated as a result of a scientific research contract sponsored in part by the United States Air Force and in part by private R&D funds. This format was developed for the purpose of providing a common means for capturing real-time multi-sensor and transmitter (i.e. transducer) data for processing in real time over a communication channel, or recorded and played-back later time. This document pertains to a concepts and methods for establishing a common basis for the capture, transmission, storage, and processing of transducer data acquired from of a plurality of diverse transducers. The motivation for this development was to achieve: 1) Higher accuracies in the derivation of target geo-spatial coordinates derived from remotely sensed data. 2) A common model to characterize sensors (transducers) in such a way as to facilitate the rapid synergistic fusion or combining of diverse sensor (transducer) data. 3) A common methodology for the exchange, archive and processing of diverse sensor data in such as way as to facilitate the interoperability among diverse sensor (transducer) systems. 4) Greater efficiency in the adaptation of new sensor data and the verification & validation of the data structures.

This concept was initially focused to address the needs of military intelligence gathering; however it is applicable to sensor data acquisition in general. Intelligence gathering is a game against time. We must be able to make decisions accurately and rapidly. These decisions are based almost totally upon intelligence information derived from sensors, either human or artificial. Ideally decisions are based on information acquired from multiple sources. Many time decisions must be made rapidly to save lives so it is necessary to acquires process and merge sensor data as fast and accurately as possible. Particularly in the areas of DOD airborne reconnaissance and missile defense. To understand the sensor acquisition process we can look at the reconnaissance cycle used in the C4ISR (Command, Control, Communications & Computers, Intelligence, Surveillance, and Reconnaissance) environment as an example. In a simplistic view an individual (requestor) will have a need for some intelligence. A Request for Intelligence is issued to a central coordination organization. This organization will determine if the information exist from earlier collections or if a new acquisition of data is required to answer the request. If a collection is required a mission is planned and programmed into the Air Tasking Order process. Figure 1 shows the typical reconnaissance cycle. Currently, IMINT (IMage INTelligence) sensor data is captured onboard reconnaissance systems during collection in the National Imagery Transmission Format (NITF) standard and system unique proprietary formats. The raw sensor data between sensor and processing is referred to as primary imagery. After acquisition this data is transported to a processing/exploitation function. The transport may be via various means including data link, physical exchange of recorded media, or network connection. At the processing/exploitation function the sensor data will be exploited to extract intelligence information to answer a particular intelligence request. The output of the exploitation function will be a report that answers the intelligence request. This report will include written interpretation of the sensor data as well as annotated imagery. The processed annotated imagery data produced as a product of the exploitation process is referred to as secondary imagery.

Figure 1 - Simplified Reconnaissance Cycle Currently no distinction is made between primary and secondary imagery. The National Imagery Transmission Format (NITF) is used for the format of the primary imagery as well as the format for the secondary imagery. Other system unique formats are used for the capture of primary data as well. Cross interoperability among the systems is not possible because of the differences in formats. In the United States NITF is the closest thing that exists for a common sensor data standard. Systems exist that use system unique proprietary formats; however each one is different and cannot be used as a "common" or "standard" for sensor data acquisition for all sensor system. It is difficult to have a data standard for both primary and secondary imagery because of different mutually exclusive requirements for each. To do so will compromise the capabilities of one or the other.

Some of the basic requirements for Primary Imagery format are:

> Capture any sensor data without degradation (processed or unprocessed),

> Adapt readily to new sensors,

> Be capable of capturing data from a wide array of sensors (IMINT, SIGINT, MASINT, positional, attitude, velocity, pressure, temperature, audio...)

> Enable accurate and precise geo location of data samples,

> Maintain error chain (relative & absolute accuracy & precision descriptors)

> Maintain highest geometric & timing fidelity of data,

> Enable precise correlation of multi-sensor data,

> Complement use of common processing - prior knowledge parameters,

> Minimize bandwidth overhead data,

> Minimize required processing for the writer,

> Re-transmit during capture > Editable data structure

> Characterize data latency and data skew

> Exploit during receipt of download

> Expedite Exploitation search by indexing events Generally Primary Imagery will be a push standard

Some of the basic requirements for Secondary Imagery are:

> Present an accurate representation of a target in question,

> General secondary imagery will be a push or a pull standard.

> Incorporate different media types, motion & still imagery, graphics, text, and sound.

> Geo-position of image pixels, registration to map grids

> Non destructive overlays

> Overlays and media types correlated through attachment levels

> Minimize processing for the reader

The requirements for primary and secondary imagery are vastly different. It is extremely difficult to satisfy both sets of requirements with a single acquisition standard. A separate standard for each would facilitate vast improvements in the capabilities, as well as logistics for handling raw and processed sensor data. The basic difference is that the primary imagery format is required to be a real time instrumentation standard based on sensor formats and the secondary imagery format is more of a non-real time display-based format. NITF is designed as a display base format standard for Secondary Imagery. Presently the intelligence community is trying to utilize NITF as both a primary and a secondary imagery format standard and for this reason is having difficulty satisfying some of the needs identified in the first paragraph. NITF is forced to operate in a primary imagery role through the use of Support Data Extensions (SDE). The SDE incorporates additional metadata, which is used to further modify or describe the data contained in the NlTF file. For example, to properly focus Synthetic Aperture Radar (SAR) imagery the SAR phase data must be corrected by the Doppler created from the motion of the aircraft. This requires very precise and accurate correlation between the SAR phase history data and the motion data from the Inertial Measurement Unit. NITF will record the SAR Phase History Data in the NITF segment and put the motion data in an SDE in the segment sub-header. The Pulse Repetition Frequency of the SAR and the update rate of the Inertial Measurement Unit (IMU) and not the same. When one tries to capture a fixed number of SAR returns in each segment the insert the IMU parameters into the sub-header there will be an inaccurate alignment of sensor to inertial unit data. For the SAR data this will result in poorly focused imagery and a loss in geo- positional accuracy when derived solely from primary data.

Figure 2 - Sensor Metadata

Within the NATO military community NITF as well as other imagery format standards are designed to handle an "image", not sensor (transducer) data. Typically the way every one of these standards work is the "image" data will be sent in a file, with metadata (e.g. latitude, longitude, altitude, etc..) embedded in the header of the image. Metadata is data about the image. Metadata can be divided into two categories, one set of metadata for the processing of the sensor data and another set of metadata for the exploitation of the sensor information. Sometimes elements may overlap theses boundaries. For example processing metadata may give details about the position and attitude of the camera system when a particular image is taken, as well as describing specific characteristics about the image such as resolution and dynamic range. The exploitation metadata give more administrative information about the sensor data. Examples of this are mission and flight numbers, security classification, etc. Metadata such as date and time support both sets. There have been attempts to standardize on metadata, but it is difficult to address every sensor and every application. Figure 2 shows how metadata is incorporated into classical sensors. To associate sensor data (i.e. image data with metadata) they are all captured in a single file format. The metadata is written into the headers of the sensor image file. This is fine until the need arises to derive high precision coordinates for targets from remotely sensed imagery. One key observation should be noted; many element of metadata come from other sensors (e.g. GPS) which are constantly outputting changing measurements. These sensors do not always update their measurements at the same rate as the primary image sensor. In the current sensor standards the only sensors that are treated as sensors are the imaging sensors, the data from other sensors such as GPS and IMUs are treated only as metadata to the imaging sensor. This implies that their importance is secondary to the imaging sensor, because their data is captured and recorded in the header of the image sensor. Figure 3 shows how sampling times of the various sensors within a system relate in time. All these sensors typically have their own characteristic sampling or update rates. So to sample all the sensors at the update rate of the imaging sensor would require sampling data from the IMU and GPS somewhere in between updates, thereby losing the relative time relationships. In addition many of the modern imaging sensors will acquire an imaging sensor frame over a finite aperture of time. Motions during that aperture must be known to remove distortions and to calculate geo- position of pixels. Unless the imaging and motion sensors are properly aligned in time and space these distortions can become significant. This will be described in more detail later. This methodology leads to inaccurate combining of image data to time sensitive metadata such as image position and attitude.

Transducer 1

Transducer 2

Transducer 3

Transducer 4

Figure 3 - Relative Time Sequence of Transducer Data Updates

Time sensitive metadata such as position and attitude are required to be precisely correlated to the image data in order to position the image data in space and time. By grouping this time sensitive data into the header of the image data all relative timing is lost. It would be preferable to time tag multi-source data with a common clock to maintain relative timing relationships.

Currently when a new sensor type in incorporated into NlTF a number of engineers are required to agree on what parameters are required to describe the new sensor type. These parameters are incorporated into a new Support Data Extension and this extension is inserted into the NITF file structure along with the data from the new sensor type. In order for a sensor processor to process that new sensor the processor must have a record of the new SDE and know how to process it. So whenever a new sensor type comes on board, a new SDE must be developed and then the industry needs to ensure that all processors are equipped with the proper applications to support the new SDEs. After a while there will be so many SDEs that it will be difficult to keep track of them let alone test them for compliance. This methodology leads to vast resources spent maintaining configuration control of sensor processor interfaces.

Being able to align transducer data in space and time from various transducers is fundamental to the fusion of data. The more precisely this can be accomplished the better transducer data can be synergistically combined extrapolate more information. Many sensor standards in the past only focus on a single sensor at a time. When it became necessary to combine data from other sensors such as providing position and attitude information to an image from an imaging sensor, many standards would treat the position and attitude information as metadata to the image. This meant that when the image is created, the position and attitude values at that time were tagged to the image. There was one sampling rate and that was driven by the main image sensor. The position update time is not known. There could be a second between positional updates on sensors. When traveling at 500 knots a lot of ground can be covered in a second. If better positioning of targets from sensor imagery is to be achieved, spatial and temporal measurements to the full fidelity of the sensors capturing the data must be accounted for. Many digital sensors create an image over a short duration in time in which considerable unwanted motions can occur. To adequately compensate for motion, sensors are required to measure precise temporal alignment of sensors which is paramount to the combining of multi-sensor data. Every transducer sample should come with at least three types of information. 1) What is the measurement, 2) Where the measurement relates to in Object Space, and 3) When the measurement was taken. .

Standards exist for the capture of sensor data. However, current standards do not meet the basic requirements for capturing in real-time multi-sensor data which may be exchanged and processed efficiently. For example, weapons targeting is typically accomplished based upon remotely sensed data. For this reason it is critical that target coordinates are derived as accurately as possible using the best information available. Sensor data geo-positioning requirements are becoming more stringent because of the need for increased targeting accuracies for precision guided weapons. Other sensing applications also require increased positioning accuracy.

This document will describe a method for capturing sensor (transducer) data in a digital format for electronic exchange on wire and/or wireless networks as well as for archiving onto recordable media. Figure 4 illustrates a generic functional flow for an airborne reconnaissance system. A key concept is the way a universal trnaducer model is used in describing the transducer in a common transducer data format. The model and the data format are complementary. There are basically two problems when trying to develop a common transducer exchange standard. The first problem is to adequately capture and describe sensor data such that a sensor processor can orient each sample's instantaneous ambiguity space in space and time. The second is to be able to display or represent the data to a human (or information processor) in an understandable and/or desirable form. Many models try to solve both problems simultaneously, which is very difficult to accomplish. A model should first be developed for the capture, transport, and archiving of sensor data, which also describes to a processor how to unravel the information contained in the sensor data. Then another model needs to be developed to describe how the originator intended the data to be represented. This document will focus on the exchange of transducer data.

The World Wide Web Consortium (W3C) recognized this when they developed XML (extensible Mark-up Language). XML is a transport mechanism only, it gives no instruction on how to represent the data. Cascading Style Sheet or XSLT (extensible Stylesheet Language Transformation) descriptions are needed to represent the data carried by an XML file.

Interoperability of sensor systems has been an issue even before sensors started creating their output in electronic form. Hundreds of standard sensor formats are, and have been, available for the common capture and archiving of sensor data. However, none are truly universal; in other words, they are all designed for a specific type of sensor and more probably a type of representation. When sensor data of various types need to be combined we must deal with multiple formats and sensor models and being different they do not always match well if at all. What is needed is a "standard" transducer (i.e. transmitter and receiver/sensor) model and a standard way of capturing, transmitting, and archiving transducer data such that multiple formats and multiple models are not required to process data from dissimilar sensors.

Typically the processing and exploitation function is performed at a ground processing facility separate from the mobile (airborne) collection platform, however with advancing technologies the locations of these functions become blurred. This document will focus on formatting sensor data out of the Transducer Acquisition Unit (TAU) through the communication or archive media and into the Transducer Processing Unit (TPU). The TAU and TPU are only generic names given to the formatter, which interfaces to the transducers, and the processor, which receives the specially formatted transducer data. The bold lines in Figure 4 illustrate the focus of this document.

Figure 4 - Simplified Multi-Sensor Reconnaissance system

In particular, this document describes a common method for characterizing transducers and employs this method in the exchange of transducer data from one system to another. Transducer data exchanged in this fashion shall promote the data fusion of transducer information and promote cross-system interoperability. Particular attention is paid to the space and time relationships among and within measurements as well as the precision and accuracy (relative and absolute) of measurements. The common model characterizes space and time aspects of both the internal and external orientations of the sensor (transducer) as well as measurement characteristics. A key characteristic is that all transducer measurements should be accompanied with an uncertainty figure of merit such that when a resultant measurement is taken the errors can be propagated through the system.

To facilitate the needs (or motivations) described in the previous paragraphs a new system concept was developed as a result of this effort and described herein. The basic requirements for this new system are as follows; 1) A single data exchange format and a single model for all sensors (transducers). 2) Processor can recreate events exactly as they happened live, purely from the format. 3) Capture any sensor (transducer) data without degradation (processed or unprocessed) in quality. 4) Adapt readily to new sensors (transducer). 5) Capture and describe data from a wide array of sensors (transducers) (MINT, SIGINT, MASINT, positional, attitude, velocity, pressure, temperature, audio...). 6) Know what the resultant accuracy and precision is of the data. 7) Maintain and trace errors end to end (relative and absolute accuracy and precision descriptors). 8) Precise time tagged measurement data, 9) Minimize data latency and data skew. 10) Enable precise correlation of multi-sensor (multi-transducer) data. 11) Common sensor processing (format describes sensors to the processor), i.e. A single processor can be used to process any sensor (transducer). 12) Minimize bandwidth and data overhead. 13) Minimize required processing for the writer (RMS). 14) Re-transmit during capture. 15) Process/exploit during receipt or download, prior to complete file transfer. 16) Editable data structure. 17) Support expedited exploitation by search and event query. 18) Adaptable to various communication methods (push, pull, simplex, duplex, single or multi channels). 19) Data exchange - ^"NOT data representation. 20) Plug-n-Play sensors (transducers).

The basic premise of this document is to develop a common model for all sensors then use sensors to describe the time variable metadata. Figure 5 is in contrast to Figure 2 in that some of the time critical metadata in Figure 5 is tracked by using a sensor. By handling sensors independently and time tagging data from all the sensors with a common system clock the data from all sensors can be correlated in time.

Figure 5 - Using Sensors to Track Time Critical Metadata

This new concept of giving all sensors equal importance and handling them all independently requires a mechanism to associate sensor to sensor. Where the metadata was incorporated into the header of an image the metadata was associated by the fact that the metadata was in the sensor image header so it belonged to that sensor. This specification will use a transducer- relationship concept, similar to entity-relationship modeling, to describe the relationships between sensors (transducers).

In some situations to properly characterize a remote sensor it is necessary to characterize the illumination of the object of which the sensor is measuring. This illumination may be either natural or artificial. If artificial illumination is provided by an emitter or transmitter then there must be a means to characterize the emitter. In this specification emitters are characterized the same as sensors. This specification characterizes transducers which refer to both receivers (sensors) and transmitters (emitters and in situ transmitters (actuators)). For this reason we refer to this model as a transducer model to describe the super class of receivers and transmitters. As used herein, a transducer may be defined as a device that produces a response as a function of the stimulus which may change as a function of time. More specifically for receivers or sensors the measurement is a digital sampling of the response of the sensor. For transmitters the measurement is a digital sampling of the stimulus. Figure 6 illustrates a Venn diagram of the classes of transducers and subclasses within receivers and transmitters. In the case of a receiver the stimulus or output can be inferred from the response by knowing the input/output transfer function of the detector. For transmitters the output of response can be inferred from the stimulus by knowing the 10 transfer function of the transmitter. The data captured from receivers (sensors) is the response (output) of the receiver (sensor). The data captured from a transmitter is the stimulus (input) to the transmitter. Table 1 shows examples of where transducers reside in the various classifications.

Figure 6 - Classes of Transducers

Table 1 - Examples of Transducers We shall continue our discussion of characterization of transducers by discussing spatial and temporal characteristics which affect the geometric properties of the transducers, principally remote transducers. A remote transmitter (emitter), as used herein, may be defined as a device that produces transmitted energy which is a function of an input signal, which may be a function of time. A remote receiver (sensor), as used herein, may be defined as a device that produces a digital response which is a function of a received signal characteristic. The flow of data (or information) through a receiver is opposite to that of a transmitter, characteristics used to characterize receivers can also be used to characterize transmitters as long as the processor processing either of the two devices realized that they are reciprocal relationships. Figure 7 illustrates the stimulus and response for both a remote receiver and transmitter. Both remote devices are characterized by having an Instantaneous Field of Measurement (IFOM). The IFOM is the volume of space which is either illuminated by a remote transmitter or sensed by a remote receiver. For imaging sensors this is typically referred to as the instantaneous field of view (IFOV).

When capturing transducer data, what does the measurement data represent? This is an important question because it depends on whether the data is from a transmitter or a receiver. The measurement from a receiver is a measurement of the response or the output from the receiver. The measurement from a transmitter is of the input or stimulus to the transmitter. The characteristics of the receiver input or the transmitter output can be extrapolated from the measured data by using input-output transfer function.

Receiver

information

Figure 7 - Remote Transducer Classes

The object space is the 3-dimensional environment in which we all live. Many characteristics can be measured in the object space and we capture some of these characteristics with receivers.

Remote transducers may be further employed to cover a larger spatial extent by either scanning a single detector or emitter, or staring of multiple detectors or emitters. By scanning a single detector or emitters measurement space (i.e. IFOM) a single detector or emitter can cover a larger space. The detector or emitter usually methodically scans the entire measurement area (i.e. FOM) by taking many samples, each sampling different space one sample after the other. Similarly remote transducers may be employed to cover a larger region by using several detectors or emitters each measuring a different area of space at the same instant. The key difference here is that staring transducers samples covering the entire FOM are all sampled at the same time, whereas scanning transducers are required to sample the entire FOM sequentially. To properly characterize the interior geometric properties of the transducer both the spatial and temporal characteristics must be described.

Figure 8 illustrates the use of scanning and staring process to enable transducers to cover a larger spatial area. If the samples are organized properly the data from the scanning and staring transducers can be used to generate an image. The scanning mechanics or staring element orientation of a remote transducer is typically implied in the data structure of the transducer data. This information must be known prior to processing the data, but it is very infrequently sent along with the data. Remote transducers which sample the FOM over a finite time duration are susceptible to motion disturbances during the sampling period. If data acquired during this period is not adequately correlated with the relative motions between the transducer and the environment then the spatial placement of the measurement data will be in error. This is an important fact to remember when acquiring data from scanning transducers. It should be noted that each sample within a specific frame (later to be defined as a Transducer Characteristic Frame) of a transducer will have spatial coordinates which are constant relative to the transducer reference system. The number of coordinates assigned to each sample depends on the shape of the ambiguity space. The coordinates are chosen from the set of coordinates which comprise either the Cartesian or spherical coordinate systems (x, y, z, alpha, beta, r).

Figure 8 -Scanning & Staring Transducers

The data from remote scanning and staring transducers are bundled into structures called frames. Each sample within a frame has a space and time attribute associated with it. Scanning transducers samples are acquired in sequence, such that there is a time difference between the time the first sample within the frame is acquired and the last sample in the frame. With starring transducers all samples in the frame are acquired at the same time. The previous paragraphs discuss an example using an imaging camera to illustrate some of the issues required to be characterized for the internal geometric orientation of a transducer. To minimally characterize a transducer one must answer the questions of "what" is the measurement, "Where" in space does the measurement relate to, and "when" in time did the measurement occur. The where (space) and when (time) characteristics are answered by a combination of the interior and exterior orientation of a transducer. We have talked briefly about the spatial aspects of the interior orientation.

It should be noted that the interior orientation is only applicable for remote transducers. There is no geometric interior orientation applicable to in situ transducers.

The transducer orientation characterizes the space-time relationship or geometry of the transducer data. The interior and exterior orientation of a transducer complements each other to give a complete space-time relationship of the data. The interior orientation may be thought of as an orientation that remains constant with respect to the transducer reference frame independent of transducer position, attitude, motion or time. This orientation accounts for any of the scanning mechanics or the space and time relationships between the samples within the transducer's data frame. The external orientation characterizes the position and attitude and timing relationship of the transducer reference system with respect to a world reference system. The world reference system is a spatial reference system that will be the common reference system for all geo-spatial data. Before continuing the discussion of transducer characterization we should review the common coordinate and reference system used in this specification.

A common set of Coordinate & Reference Systems shall be used for describing data in this specification. Figure 9 shows the coordinate systems used to describe coordinates.

x = const v = const ^: const α = const β = const r = const Figure 9 - Common Coordinate Systems

Figure 10 shows the two reference systems allowed in this specification. A platform reference system is not. required, if a platform reference system is required, then a transducer may be assigned to it so that it can be measured. There is no assigned orientation of the x, y, and z axis to the transducer. Any orientation may be used, depending on which orientation works best for characterizing the interior orientation of the transducer data. The description of the interior orientation will be in terms of a coordinate system coordinates (x, y, z, alpha, beta, r). These coordinate assignments used to describe the interior orientation set the stage for the orientation of the coordinate system axis to the physical transducer. The earth reference system on the other hand had a fixed orientation of its coordinate system described by WGS-84. Points in each reference system can be described by using either coordinate system (Cartesian or Spherical)

Earth Transducer

Figure 10 - Common Reference Systems

Figure 11 shows the convention used for determining the Euler angles (ω, φ, K) for rotation transforms. Particular attention should be paid to the order in which the rotations (K then <j> then ω,or ω then ψ then K) are applied depending on whether defining coordinates in the rotated reference system or the un-rotated reference system.

Describing Reference system (x"',y"',z'") in terms of Reference System (x,y,z)

The first rotation co is about z axis shown in red. Clockwise rotations as viewed looking at the origin from +z are positive.

The second rotation <j> is about the new y axis (y¹) shown in Green.

Eυler Clockwise rotations as viewed looking at origin from +y' are positive.

The third rotation K is about the new x axis Cx") shown in Blue. Clockwise rotations as viewed looking at origin

from +x" are positive.

Figure 11 - Convention for Coordinate System Transformations

An important characteristic to understand when characterizing the geometric aspects of transducers is the sample ambiguity space. The ambiguity space is defined relative to the transducer reference system and thus becomes part of the transducer's interior orientation. When a 2-dimensional sensor images a 3-dimensional environment there is an ambiguity in one dimension. An object from a 2-dimensional image is known to exist somewhere along the particular ambiguity space for that particular sample for the transducer. Different transducers have different ambiguity shapes. Figure 12 illustrates the ambiguity space for the camera. The shape of the ambiguity space is not always a straight line or ray. Different types of sensors have different ambiguity shapes. The set of coordinates used to characterize the sample coordinates with respect to its transducer reference system also characterizes the shape of the ambiguity shape. For example an alpha and beta angle define a ray, an alpha angle and a range or a beta and a range define two different circles or arcs. A single alpha defines a plane, a single beta defines a cone, and single r defines a sphere. Cartesian coordinates may be used to define ambiguity spaces as well.

-2

Figure 12 - Camera Ambiguity Space

Table 2 describes some different shapes for various sensors. The optical framing camera and the optical line scan sensor both have an ambiguity shape of a ray originating at the frontal optic node of the focused lens. The ray for a particular sample is defined by the alpha and beta angle spherical coordinate angle for the camera reference system. Radar sensors have an ambiguity shape of a sphere and if they are correctly processed they can be compressed to a constant range arc for each sample. These are only a couple of examples, more shapes such as cones and planes exist as well.

Table 2 - Example Ambiguity Shapes The ambiguity space is the volume of space of possible locations of an object. When a two dimensional image is made of 3-dimensional space, there is an ambiguity in one dimension. An object that appears in the image is known to be positioned somewhere within the ambiguity space. For a camera the shape of the ambiguity space is a ray. The ray originates at the frontal node of the optics. There is a ray for every pixel in the camera frame. When a pixel is centered on a small object there is a ray from the camera through the center of the object. This will be the shape and orientation of the ambiguity space. If the position and orientation of the camera is known, then when the picture is viewed then the location of the center of the object is known to exist somewhere within the ambiguity space for that pixel. The 3-dimensional coordinates of the object's center can be calculated by using another source of data. The other data can be another image of the center of the object from a different perspective of a known surface where the object is known to exist. To determine the 3-dimensional coordinate for the center of the object the ambiguity spaces from two or more receivers are transformed to a common reference system. The ambiguity spaces from the samples corresponding to the objects center will intersect at the 3-dimensional location of the object's center. Likewise if a surface is available then the ambiguity space for the pixel of the center of the object can be intersected with the surface to find the three dimensional location for the center of the object.

In addition to the interior geometric characteristics of remote transducers as discussed in the previous paragraphs there are measurement properties which must be characterized to adequately describe transducer properties. The following paragraphs describe some of the characteristics to describe the measurement or "what" characteristics.

> Transducer type - a transducer is a super class for including either transmitters of receivers. Transmitters and receivers can be each subdivided into the remote and in situ subclasses. This description is useful for determining what type of characterization is required for a particular transducer. For example, if a transducer is classified as an insitu receiver, then we would not expect the transducer to include characterization of the IFOM.

> Source of Reflective Illumination - Remote receivers measure reflected and/or emitted energy. If the measurement is a result of reflected energy, then a description of the source of the energy is important. The source may be natural illumination such as ambient illumination from the Sun or it may be artificial illumination from another remote transmitter.

> Measure duration - When a measurement is taken of some changing characteristic the integration or dwell time to acquire the measurement is important. An example of this would be the shutter speed of a camera.

> Frequency response/Power spectral density - The characteristic of how fast or slow a detector can respond to a changing input, or the range of sensitive frequencies is referred to as the frequency response of a receiver. Transmitters have a reciprocal characteristic known as the power spectral density. The power spectral density describes the frequency distribution of the output energy

> Polarization - For remote transmitters and receivers which rely on electromagnetic energy, the direction of the E-field is an important characteristic. Example: Horizontal, Vertical, Right, Left.

^ Measurement nomenclature - a description of the measurement is a required characteristic for all transducers. Example: Azimuth Gimbol Position > Observable - This is a description of what physical measurement is used to characterize the measurement. These descriptions should be from a set of pre-defined descriptions. Example: Average Power, RMS Voltage. Temperature difference, Angle, speed

> Units - This is the SI unit used to quantify the Observable of the measurement. These units should be selected for a set of predefined values. Examples: Kg, meters, seconds, Volt, Amp, Watts, Radians, deg Kelvin, meters/sec, radians/sec

> Data type - This characterized how the measurement value is digitally represented. The data type should be selected from a set of pre-defined values. Examples: unsigned integer, signed integer, real, complex, logical, character

> Allowable values/Range - It is helpful to confirm valid data sometime if the allowed range or allowed values are previously known. For example a certain receiver may only have a response range between 2 and 25, so if any values are received out of that range it can be considered invalid.

> Number of bits/measurement - When measurements are digitally captured it is necessary to know how many digital bits comprise the measurement. Typically the number of bits per measurement are integer multiples of eight.

> Actual number of bits/measurement - In some situations not all of the bits are required to represent the measurement value. It should also be known or mandated whether the data is right or left justified in the field. The actual bits/measurement value is indicative of the precision of the measurement. Example: An imaging sensor may output 12 pixels which are captured digitally in a 16 bit field. The 12 bit pixel occupies the least significant 12 bits of the 16 bit field, the remaining 4 bits are set to zero.

> Measurement Error - With every measurement there is some error associated with it. Errors should address both relative errors for determining differential error between two measurements, and an absolute error. Ideally every measurement should be accompanied with a characterization of its errors.

> Input/Output Transfer Function - This characteristic describes the relationship between the inputs to a transducer and the output. In the case of a receiver the output or the response is the measurement value, for a transmitter the input or the stimulus is the measurement value. This is usually shown by a plot of input vs. output. The measurement value is the independent variable in the transfer function and the Observable is the dependent variable. Characteristics which affect the transfer function as sensitivity, noise level, saturation, input dynamic range, output dynamic range, output gain, output bias, hysteresis.

> Measurement Reference - if measurement is a difference measurement (e.g. Phase, altitude), then the reference must be identified.

> Calibration - in some situations a transmitter or receiver may incorporate a calibrated input. The value of the measurement can then be compensated for any gain and bias errors by analyzing the difference between what the measurement to the calibrated source was and what it should be.

To complete the description of a transducer where and when characteristics the exterior (position, attitude, and time) orientation of the transducer must be known. The position and attitude is always measured relative to something else either another transducer or a common datum (e.g. Earth). The time is measured with a world clock which is common to all systems in the domain. When more than one transducer is utilized in a system of transducers then it is necessary to know the space and time relationship of one transducer to another. Transducer data from a plurality of transducers can be aligned in the proper spatial and temporal orientation by using a combination of the interior and exterior geometric orientations. Knowing the external relationships of one transducer to another is fundamental to transducer data fusion. In many situations position and attitude receivers provide data which provides the external orientation for a principal transducer. The principal transducer is positioned and/or attitudinally oriented relative to a position and attitude receiver. Position and attitude receivers measure their own position and attitude relative to a common datum (e.g. Earth) or relative to another position and/or attitude receiver. To characterize the exterior orientation of a transducer the resultant position and attitude relative to a common datum (e.g. Earth) must be calculated for each transducer in the chain.

Current image acquisition systems do not rely on this precision alignment of motion and position data to the image data. The position and motion data is only used to get the image close enough to register it to a reference image. The reference image is usually an ortho-image in which geographical coordinates can be calculated for every point in the image. When the data is registered to the ortho-image target coordinates can be extracted by cross reference. This process is acceptable, assuming reference images are available and you have the time to register the two images. Also, in some cases the accuracy of the reference images may not be sufficient to derive coordinates of required accuracy. As sensor technology improves the ability to derive accurate target coordinates directly from sensor data becomes more and more feasible. The metadata once required only to position images in the general vicinity of a reference image, now may be accurate enough to position data better than the previously used references. Having data this precise it becomes more important to be able to characterize the errors of the measurements, specifically the geometrical errors.

Sources of geo-position error are due to only a few contributors: atmospheric errors, installation alignment errors, transducer measurement and characterization errors, A/D quantization, timing and latency errors, and data timing association error. Many times it is just as important to characterize the error as it is to characterize the data. When a target coordinate is calculated from remotely sensed data it is imperative that the accuracy of the coordinate is known. It is important that we understand these errors so that we can characterize them and give error predictions on resultant measurement accuracies that are calculated from the raw transducer data. When transducer data is processed to derive critical information it is important that each of these error contributors are characterized. A responsible transducer data exchange format should provide the means to characterize these individual error contributors or the total resultant system error. Figure 13 shows a simplified diagram of the resultant positional and attitudinal errors which result in large target positional errors. Note however that this is a simplified diagram and does not show all contributors of random and systematic errors. The resultant positional and attitudinal errors may be the result of many sensor measurements. The errors must be propagated through the system to derive the resultant geometrical errors.

Atmospheric distortion is an error induced in remote transducers by the refraction of electromagnetic energy by the atmosphere. This error is not normally characterized by data contained in the data format. The error is normally calculated at the processor by knowing parameters such as altitude and incident angle to the surface. This however does not prohibit the use of sensors which measure the atmospheric distortion. Resultant Positional

Figure 13 - Geo-positioning Error Contributors

When dealing with dimensional data structures, the ordering of data is sometimes rearranged during the serialization of data required to transport or archive the data. For example a rectangular frame CCD camera may sample all of the detectors in a rectangular array at the same instant. However the array needs to be scanned serially for transmission. There are several ways in which the array can be scanned. It may be scanned left to right then top to bottom, or top to bottom then left to right, or there could be interleaving of fields within the frame. For a common transducer data format there must be a method to describe this reordering.

3 General Details of the Specification

This specification may be described as a method for acquiring, exchanging, archiving and processing, in a universal way, transducer data from the plurality of diverse transducers. The method describes a process which is particularly useful for capture and description of raw or original transducer data. This transducer format specification employs a "rigorous sensor model" to characterize transducers as a whole. A rigorous sensor model tracks and accounts for all of the motions and physics of the transducer system and its interaction with the environment. If it moves or changes it is tracked with a sensor. Every sensor is positioned relative to something. A common rigorous model applicable to any sensor will enable the model to be used to describe all sensors and their relations in the system of sensors. One unique characteristic of this model is that it treats everything as a sensor. This specification will facilitate a way to track and organize all the measurements required to facilitate a truly robust rigorous sensor model. Figure 14 shows the relation of several sensors in a system of sensors. All of the sensors in the chain must be characterized to fully characterize the last sensor in the chain.

Figure 14 - Rigorous Transducer Model

The specification describes a method for characterizing data from transducers such that a universal transducer processor can process the data, using the methods described herein, from a plurality of transducers without prior knowledge of transducer characteristics from any other source. The universality of the data format allows for the exchange and archive of the data by standard open systems protocols. Transducer systems utilizing this method may be able to interoperate among each other utilizing a wide variety of transducer data sources.

A self describing format called TransducerML (TML) which carries transducer data can configure a Transducer Processing Unit to read and process the transducer data. The data format which may be packaged in many forms (file, stream...) contains two basic entities: 1) data and 2) data description. The data description describes the data, such that a universal processor can process the data. The processor may receive the data description with the data or it may receive it by other means. The processor only needs to receive the data description once. Then data can be continually received after that.

Transducers produce measurements. Sometimes a transducer will capture many measurements characterizing different attributes about the environment. For example a multi-spectral sensor measures the reflectivity at different wavelengths. A GPS will sample latitude, longitude, altitude, velocity, etc. The set of measurements constitutes one sampling sample set or sample of the transducer. Figure 15 illustrates the hierarchy of the format data structure. Cluster

I I I TCF I ! I I

_„ _--- *"""^' Transducer Characteristic Frame TCF ^""^" .....^

I I I Sample || | I I

__„..-- Transducer Sample ^{"" "}"^* " ----._».

I I I Measurement Q I I

Figure 15 - TML data structure hierarchy

A Sample is composed of one or more measurements. Every measurement in a sample corresponds to the temporal and spatial coordinates associated with that sample. Samples of the measurement Transducer Characteristic Frame are composed of one or more measurements all corresponding to the same spatial ambiguity. A set of samples comprises the Transducer Characteristic Frame.

A Transducer Characteristic Frame is a key concept required to facilitate the association of transducer data to transducer modeling data. Transducers which scan with a small number of detectors or stare with an array of detectors require their data to be organized spatially such that the detector sample represents the spatial orientation intended. The samples within this group have space and time relationships which must be understood to characterize the data, particularly if there is any motion of the transducer. The minimum set of samples which must be considered to characterize a transducer comprise the Transducer Characteristic Frame. We will use these frames to group the data from the transducer as well as use the same size and shape of a frame to contain model data, such that there is a one-to-one relation between the model data and the transducer data.

Dimensionality is a characteristic of the TCF. The number of object space coordinates (x, y, z, alpha, beta, or r) used to specify relative spatial characteristics of samples is referred to as the dimensionality of the TCF. Sensors which have a single sample have no implied spatial relationships among other samples with the TCF, so single sample TCF sensors have a dimensionality of zero (0).

Non-dimensional TCF

One-dimensional TCF

Two-dimensional TCFs

Three-dimensional TCFs

Figure 16 - Transducer Characteristic Frames

The best way to explain this is by showing a few examples. A TCF is a logical organization of transducer Samples for the purpose of associating corresponding numeric transducer models. Figure 16 illustrates array configurations for the different dimensions of TCFs. Each type of transducer will have its own characteristic frame. For example: transducers such as rotational encoders, thermocouples, volt meters, GPS, inertial navigation sensors, all fall into the non- dimensional TCF category. These non-dimensional TCFs normally describe in situ transducers where there are no spatial assignments of coordinates to each of the transducer samples. Non dimensional TCFs only have one sample per TCF. One dimensional TCF transducers on the other hand have one coordinate, from the set of object space coordinates (x, y, z , alpha, beta, r), which is used to characterize the spatial relationship of each sample in the TCF. An example of this type of transducer is a radar. The sample that is captured by a radar receiver or transmitter represents the response or stimulus at a certain range from the transducer. There is no information that provides any other spatial information other than knowing the IFOM of the receiver and transmitter. Two dimensional TCF transducers are fairly common. All of the imaging sensors fall into this category. A camera for instance has a two dimensional TCF in which the object space dimension assigned to the horizontal dimension of the TCF is the Alpha angle and the vertical dimension is assigned the Beta angle as illustrated in Figure 18. A synthetic aperture radar processed image for example has a two dimensional TCF where the dimensions of the TCF are assigned to the alpha and range coordinates as illustrated in Figure 17. Coordinate TCF

Object space coordinates

Figure 17 - range and angle (alpha) assigned to TCF dimensions - Processed SAR example

Coordinate TCF

Figure 18 - angle (alpha) and angle (beta) assigned to TCF dimensions - Camera example

TCFs will be used to associate data from transducers with models which are used to characterize the data from the transducer. The principal types of TCFs which we will discuss are the:

> measurement TCF -contains the transducer data.

> coordinate TCF - describes the interior spatial characteristics of the transducer data, and

> timing TCF - describes the interior timing characteristics of the transducers. The measurement TCF contains a set of transducer samples. Other types of TCFs can be described on an as-needed basis. For example the gain of an array of detectors which comprise an array bay all have different bias and gain values. A TCF could be created which describes this variability across the TCF.

Transducer data is captured in mTCFs and transported in clusters. The size of the measurement TCF is the same size as the modeling TCF's so there is a one-to-one relationship between measurement and relative space and time. This provides the synchronization required between the data and the model, The measurement TCFs are all time stamped with the time of the first sample. This provides the time synchronization required to align the responses from multiple sensors.

The TCF structure will be used to associate measurements (transducer data), spatial, timing and other information needed to characterize the transducer. We will begin talking about transducer modeling by introducing the TCF model. Later we will use function models to describe other features of transducers. Some of the different TCFs used for interior orientation modeling are: Coordinate TCF, Temporal TCF, and Sequence TCF. There may be other TCFs to describe transducer characteristics which vary over the TCF such as radiometric gain. However they will follow the same sort of reasoning. There are zero or more TCF models associated with every transducer. TCF model elements are included in the TransducerML stream as part of the data_desc entity. The TCF model for a particular sensor is the same size, shape, and order as the measurement TCF (transducer data) so there is a one-to-one relationship between a transducer sample and the space time parameters for that sample. Every sample in a TCF has an associated spatial ambiguity and time relative to the other samples in the TCF.

The coordinate TCF (cTCF) which may be further divided, (cTCFx, cTCFy, cTCFz, cTCFα, cTCFβ, cTCFr): contain the set of interior coordinates for describing characteristics about the transducer data contained in the mTCF. The specific combinations of coordinates chosen for the cTCF's dimensions also define what the shape of the spatial ambiguity is. A two dimensional TCF will have two cTCF. Which two cTCFs are used will depend on which coordinates are used to describe the internal spatial relations. For example, if the TCF were of a camera then the two choices would be a cTCFα for the alpha coordinates and cTCFβ for the beta coordinates. A three dimensional TCF will require three cTCF to describe it. Figure 19 illustrates some example coordinate TCF of some sample transducers.

Conical Scan Sensor

Figure 19 - coordinate TCF examples

The choice of coordinates for a transducer also describes the ambiguity space for the particular sensor. The following list describes the possible ambiguity shapes that can be described by using one and two combinations of coordinates. Figure 20 illustrates the ambiguity space defined by the combination of alpha and beta coordinates.

> x→plane of const x > x&y-»line parallel to z axis

> y→plane of const y > y&z-»line parallel to x axis

> z→plane of const z > x&z-»line parallel to y axis

> α→plane of passing through the z axis 10 > α&β->line passing through origin

> β→cone of const angle β > β&r-»circle parallel to xy plane

> r-»sphere of const r centered on the z axis

> α&r-^circle with z axis as diameter centered at origin

15

Figure 20 - TCF Coordinates and Ambiguity Space Characterization

The numbers used in the cTCF to describe the spatial characteristics of the TCF are in "ticks" The range (FOV) of one dimension is divided up into n number of equal distance intervals called ticks. The position of each sample is measured in ticks. When the FOM changes the coordinates should remain approximately the same. There may be situations where a cTCF is referenced but the TCF model is empty. This may be the case to save space when the geometric characteristics are not that important. In this case the angular or linear distribution of the ticks with integer range can be considered linear. Figure 22 illustrates the use of ticks for measuring spatial coordinates of a 1x7 array 2-dimensional TCF. The first dimension is the alpha angle and the second dimension is the beta angle.

; 1 2 3 4 5 6 7

-12 -8 -4 0 4 8 Dim 1 Frame (α) 0 0 0 0 0 0 Dim 2 Frame (β)

Object Space Coordinates /

Figure 21 - Object Space to Image Space Correlation (Interior Orientation)

Figure 22 - Using ticks to measure coordinates

The tTCF frame gives the relative sample time of each sample within the TCF. These times are created by a sensor calibration process. The times within the TCF are measured in time ticks. Depending on the timing resolution desired, the number of time ticks can be increased or decreased during the calibration process. Time ticks divide to TCF frame duration (time of last sample - time of first sample) into a number of evenly divided time ticks. Each sample time occurs on a specific time tick relative to the first sample. This time for a particular sample is captured in the tTCF cell. Time ticks in the cell do not need to be consecutive, in fact ideally there should be at least a order of magnitude more ticks than samples in a particular dimension. This will enable the ticks to describe any aberrations or non-linearties in the timing.

If the timing of samples within a TCF is linear then the actual tTCF may not be captured in the TransducerML stream. The model will be an imaginary model with equally spaced time for each sample during the frame duration. Figure 23 shows some example tTCFs for some simple sensors.

Framing tTCF

Pushbroom tTCF

Line Scan tTCF

Conical Scan tTCF 1 2 3 4 5 8 9 10 11 12

Figure 23 - Timing TCF

The relative time of any measurement can be calculated by using the tTCF (interior orientation time) and the timestamp in the start tag. There is a one-to-one relation of tTCF time ticks and measurement samples. Figure 24 shows this one to one relationship between the timing TCF and the measurement TCF. The corresponding tTCF time tick measurement gives the offset time in time ticks from the time stamp of a particular measurement sample. The period of a tick is equal to the TCF duration divided by the number of time ticks. So the offset from the time stamp is equal to the tick measurement value times the time period of one tick.

Sample no. 3 4 5

Timing frame (when) modeling data

e (what)

Figure 24 - one-to-one relation of mTCF with TCF model

The spatial (where) and temporal (when) characterization of transducer data has been discussed. To complete the characterization we will require common parameters to describe the measurement or "what" characteristics. Many of these parameters are discussed in the background. A complete description of the measurement characteristics are described in the detailed specific description of the specification section. Function models provide a numeric way to represent functions which describe sensor characteristics such as: the Instantaneous Field of Measurement (IFOM), the Frequency response or the Input-output Transfer Function. The function models are described in the model element along with the TCF models in the TransducerML stream.

The IFOM may be described by a single number (angular range) representing the angular range of the IFOM. If a more detailed profile of the IFOM is required then the function model may be used. Figure 25 shows an example IFOM profile. The IFOM can be described using a function model as illustrated below. This would be described as a 2-dimensional model with data defined in an array of 1 row and 15 columns. The IFOM angular range is divided into a number of equal-angular intervals called ticks. Each column would contain 1 sample or data point characterizing the function. The data points describe the normalized magnitude of each tick increment. In this example 15 data points describe a normalized tear-shaped IFOM profile. There can be more than one IFOM profile for any transducer. One of the characteristics given the model in the description of the power level of which the IFOM represents relative to the receiver or transmitters sensitivity or power. For example there could be a -3db IFOM and a - 6db IFOM for a single receiver.

Example data to characterize the IFOM function:

> IFOM range (rads): .001

> No. of IFOM samples: 15 (14 ticks)

> Normalized data points (.15 .38 .62.73 .82 .95 .98 1.0 .98 .95 .82 .73 .62 .38 .15)

Figure 25 - IFOM Characterization

The frequency response for receivers or power spectral density for transmitters is another characteristic which can be modeled with the function model. They can simply be modeled by two numbers 1) the center frequency and 2) bandwidth. If a more detailed profile is required then a function model may be used to describe the profile. The frequency range is again divided into a number of ticks. The data points represent the normalized response for the frequency corresponding to each tick over the frequency range. The frequency range is then centered on the center frequency. Figure 26 illustrates an example frequency response function.

Example data to characterize the frequency response or PSD function: > Freq range (Hz): 1E3

> Center freq (Hz): 5E6

> No. of samples: 15 (14 ticks)

> Normalized data points (.2 .8 .9 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 .9 .8 .2)

Normalized response

frequency

x min x max

Figure 26 - Frequency Response Characterization

The Input-Output transfer function is another characteristic which may use the function model to characterize. The input/output transfer function describes the transfer function between the input stimulus and the output response in the case of a receiver, and the input signal and the output energy in the case of the transmitter. The input output transfer function can be modeled with a function model as described below. The response or signal range is divided up into a number of different measurements. In this function the measurement is always plotted on the range (x-axis) as the independent variable. The stimulus (for receivers) or response (for transmitters) is plotted on the domain (y-axis) as the dependent variable. Figure 27 illustrates the input-output function for both receivers and transmitters. The range is again divided up into a number of equally spaced data points. The function can be profiled by the set of data points each corresponding the set of equally spaced range values. Note however that the scale of the range can be linear or logarithmic. The input-output function is described as a normalized function. Gain (multiplicative) and bias (additive) factors are used to describe the actual input-output transfer function. The gain and bias values may be changing in which case they may be monitored by a sensor. In the following example 16 data points are used to characterize the input-output transfer function, (i.e.: If you had an 8 bit integer response with a range of 256 then you could very well list the stimulus that corresponds to each of the responses). The range for the transfer function is defined x_min and either x_max or x_range. The range corresponds to the allowed values of the measurement. The units of the domain are the same as the units for the measurement.

Example data to characterize the input-output transfer function:

> x min: 0

> x max: 255

> No. of samples: 16

> Normalized data points (.01 .1 .15 .2 .25 .3 .4 .5 .6.7 .75 .8 .85 .9 .95 1.0) Output Input (response) (stimulus)

-> Output x_range- (response)

x_mm xjnax (sensitivity) (saturation)

Figure 27 - Input-Output Transfer function Characterization

One of the features of TML is its flexibility to adapt to transducer modeling configurations. There are three methods for defining a transducer characteristic: 1) constant value, 2) a value measured by a transducer, 3) a constant value that varies over the TCF, 4) or a two or three- dimensional function model. For example, the gain measurement which is a characteristic of the input-output transfer function can be a fixed value in a field or the field can refer to another transducer to describe its changing state (refer to the dependency_id_ref attribute). Another way in which TML offers flexibility in the characterization of transducers is by the assignment of specialized TCFs. For example, if we take that same gain measurement, there are situations where the gain applied to certain detector elements within an array of elements varies element to element. A TCF of gain equalization factors would be described by the assignment of a gain TCF (refer to tcf_mod_ref attribute). Another way TML offers flexibility is by the assignment of function models to parameters. For example IFOM (instantaneous field of measurement) could be a single measurement, say 1.5 mrads. Or TML will allow the assignment of a function model to the IFMO parameter. The function model will allow the definition of a precise profile of the IFOM. The real flexibility comes when all three methods of defining a characteristic come into play. A transducer characteristic such as frequency response can be measured with a single value, or it may be assigned a model to describe the frequency profile. The characteristics of the frequency response profile (center frequency or frequency range (bandwidth)) can be defined by constant values or the characteristics can be assigned to either a TCF model or a transducer. The TCF model would describe any variations across the TCF while the transducer would capture any changes as a function of time of any of the parameters. A f cn_modif y element describes how the four methods interact.

TML is a mark-up language using the commercial standard XML (extensible Mark-up Language). The advantage of using XML is that it allows the description of the data structure of an exchanged message file or stream. XML uses a robust description technique (Data Type Description, DTD or XML Scheme) to describe the data model and organization of data elements being exchanged in an XML file or stream. The TML specification describes a unique DTD and XML Schema which explains the relationship of the data elements used to describe a transducer to a common processor. The data model described in terms of the Unified Mark-up Language (UML), DTD, and a sample XML implementation are described further in this document. It should be understood that only one DTD is required to characterize TML. The DTD is not modified to accommodate different transducers or different transducer characteristics. This enables a common processor which knows how to handle the DTD to process any file which is validated using it. Validation is the term used to describe that an XML file is in compliance with the rules set forth in the DTD or Schema. The actual transducer characterization takes place in the XML file or stream. TML is the root element in a file or stream. <tml> is the first and last thing sent in a TML data exchange. Within the <tml> element there are two other elements: <data_desc> and <data>. These two elements do exactly what their name implies. The data description <data_desc> element describes the data <data> element. The data element contains the transducer data and the data description element contains the description of the transducer data.

The DTD or XML Schema provides the rules for which an XML file is created. Readers and writers of XML files use the DTD or Schema to validate that the file or stream was created properly. This check is completed on every file or stream so the chances of improperly packed data is very small.

Synchronizing metadata is paramount to precision geo-location of targets imaged by imaging transducers, or more fundamentally transducer fusion. The concepts described here will enable metadata which is changing (e.g. aircraft position and attitude, receiver gain, transducer mode, diagnostic data, etc. ) to be described by a sensor either real or virtual. The metadata will be related by a dependency mechanism to be described later. Figure 28 illustrates time sensitive metadata being described by data from a meta-sensor. Then the meta sensor would be described using the common modeling techniques, referred to in Figure 28 as Fundamental Metadata.

Elementary building block

Figure 28 - Sensor to Describe Dynamic Metadata

If we use this model we can replace the time sensitive metadata from Figure 2 with meta-sensors as illustrated in Figure 29. Sensor System

Dynamic Metadata Dynamic Metadata Static Metadata Dynamic Metadata

Meta-sensor Meta-sensor Fundamental Meta-sensor metadata

Fundamental Fundamental Fundamental metadata metadata metadata

Figure 29 - Meta-sensors to Model Dynamic Metadata

This new method of handling transducer data where the data from each transducer is handled independently of other transducers (i.e. data from one transducer is not in the header of another transducer) brings about a new problem. There must be some mechanism to associate transducer data. Previously, the association was made by incorporating the data from one transducer into the header of another. Figure 30 illustrates a topology diagram for a system of transducers. The bubbles represent transducers and the lines in between represent the relation of one transducer to another. This is similar to entity-relationship data modeling.

gain

Figure 30 - System Topology Diagram

Many transducers are in reality a system of transducers. A transducer system topology provides the fundamental descriptions of how all of the transducer data relates. Not all systems are alike so the system topology is described on a system to system basis. This specification defines four types of relations: attached, dangled, position, and attitude.

An attached sensor is typically an in-situ sensor measuring other parameters to support its host sensor. The attached relationship will be described in the attached sensor's nomenclature. An example of an attached sensor would be if one had a diagnostic sensor attached to the primary imaging sensor measuring another variable (such as vibration of temperature). An attached element is empty and simply references another sensor. The presence of an attached element means that the sensor referenced by the dependency element should be treated as if it had the exact same location and attitude as the sensor referenced by the attached element.

The attached relation is used to attach sensors to transducer characteristics which describe changing parameters about a transducer system, such as receiver gain. The attached implies that there is a characteristic to "hook to". The sensor is measuring a changing parameter for that one of the transducer characteristics that TML models. .

The dangle dependency is like the attached dependency except that there is no internal hook to a transducer characteristic. The dangle transducer simple hangs off of another transducer and provides additional measurement relating to the transducer as a whole. An example of a dangle relation would be a temperature measurement of a transducer's detector, to the vibration load on a particular transmitter.

The position relation identifies the position of a transducer relative to the earth or another transducer. The position can be a fixed location or it can be variable, where the position is measured by a sensor. The position and attitude relations are the principal relations for determining the exterior orientation of any transducer.

The attitude relation is similar to the position except the orientation of a transducer is described relative to the earth or another transducer. If the orientation is variable the orientation may be described with a sensor.

Figure 30 illustrates an example of a transducer system topology. This example uses two primary transducers (CCD camera and IRLS) with six supporting transducers (roll encoders, vibration, gain, position, and attitude) The primary sensors are positioned and oriented relative to the roll encoders. The roll encoder position is fixed relative to the GPS, and the roll encoders measure its attitude relative to the IMU. The gain is an attached dependency the IRLS, measuring the setting for the gain measurement which is used in characterizing the input-output transfer function of the IRLS. The vibration is a dangled dependency, only measuring the vibration of the CCD camera.

The model of the transducer system topology describes the relationship of the various sensors used in the multi sensor system. This modeling provides a cohesive picture to fuse all of the data together for the various sensors on board a platform. This model describes the chain of sensors and what parameters, if any, are modified by previous sensor measurements in the chain. For example, a detector look direction relative to local earth is modified by the gimbol angles relative to the internal measurement sensor of the platform and the latitude of the platform relative to local earth. This sensor environment data enables vectors to be manipulated and common reference frames to be converted into other common reference frames. In-situ sensors may also be attached to another sensor to provide other measurements such as sensor state or diagnostic information. These can be described as well in the system topology. The dependency element in the system element of the TransducerML stream provides the sensor system topology

Many time sensors are mounted in vehicles that are in constant motion. Imaging sensors must rely on other sensors to provide them with position and attitude information, such as IMUs, GPSs, rotational and translational encoders, and many other sensors which are available to assist in the positioning and orientation measurement of the primary imaging sensor. There may be several positional and attitudinal translations that a transducer is subject to before its position and attitude can be described relative to earth. For example a sensor may be attached to a gimbol system which can steer the sensor. The gimbol system may be relative to an Inertial Navigation System that measures a platform's position and attitude. To calculate the sensor's attitude relative to the earth the transducer's relationship is to the gimbol must first be known. Then the sensor's relationship to the INS can be calculated by.knowing the gimbol's position and attitude relations to the FNS. The gambol roll encoder measures its attitude. The sensor's relationship to the earth can then be calculated by knowing the INS's position and attitude relative to the earth. The INS measures its own position and attitude.

Figure 31 shows this chain of measurements from various sensors to provide position and attitude data for the primary imaging sensor.

Earth Centered Earth Fixed reference system

Figure 31 - indirect target positioning through a chain of sensor measurements

All terrestrial transducers should be positioned and oriented relative to Earth. The common reference frame to serve as a datum for the combining of all sensors is the Earth Centered Earth Fixed reference system. The spatial and temporal Transducer Characteristic Frames describe the interior orientation of a transducer. The exterior orientation is described through the transducers position and attitude dependencies. Several iterations of the position and attitude may be necessary depending on how many coordinate transformations are required, do to intermediary sensors. The dependencies describe the relationships such as attitude and position of sensors to other sensors and to earth. Every sensor should be traceable back to earth. To determine the exterior orientation of the last transducer in the chain the position and attitude relations must be summarized through a process of coordinate transformations and vector additions. Figure 32 shows the resultant exterior orientation of the last transducer in the chain. Since not all transducers are attitude dependent - these sensors are not required to have attitude dependencies. Given the exterior and interior orientation of a transducer, target coordinates can be calculated. The pixel on the target represents a specific ambiguity space. The ambiguity space is very precise relative to the transducer reference system. If the transducer reference system can be positioned accurately enough relative to earth through the exterior orientation, then the position and orientation of the ambiguity space relative to earth can be determined. Now it is known that the location of the target is somewhere in the ambiguity space and it will be left to the sensor processors to intersect the ambiguity space with a terrain model or another ambiguity space to determine the targets three-dimensional earth coordinates. To determine the accuracy of the ambiguity space position, one must propagate the errors from every measurement alone the chain which resulted in the exterior orientation. The error of the target position is then the result of the exterior orientation error, interior orientation error and the terrain model error.

Earth Centered Earth Fixed reference system

Figure 32 - target location derivation from known interior & exterior orientations

The analog to digital-sampling of transducer measurements should be at least at a Nyquest rate of the changing observation in which the transducer is measuring. The digital samples are compiled into the characteristic frame of the transducer and give a timestamp for the time when the first sample of the TCF was acquired. This timestamp should account for any processing latencies. The goal is to have the time stamp coincide with the time in which the observation state occurred. The timestamp comes for a clock which is common to all of the transducers in a system. This is referred to as the system clock, and it provides relative time for the relative temporal alignment of transducer data. Figure 33 illustrates that transducers in a system all have their own rates in which they sample and output a TCF's worth of data. This concept enables a processor to maintain this relative timing relationship between TCFs of different transducer by the use of the system clock time tag. For precision transducer measurements a stable clock should be utilized. Temporal skew due to transport and archive data buffering and sequencing and sensor data latencies can be accounted for.

Figure 33 - Capturing the Relative Time Sequence

When it is necessary to combine data from the transducer system with other systems then it may be necessary to correlate the system time with a world time which is common to another system as well. When this is necessary a received (sensor) should be included as part of the transducer system which measures the world time and captures it in its own TCF. The TCF will be time stamped with the system time. Having the two clocks latched at the same moment enables any system clock time to be associated with a real world time.

The alignment of sensor image data to changing metadata is paramount to the precision processing and exploitation of sensor data, or more widely transducer data. Because digital data from transducers is sampled at different rates it is impractical to synchronize the sampling of all sensors to the same sampling clock. A master or system clock shall be used which can time tag all transducer data and provide a basis for the temporal alignment of data. Figure 33 shows how various sampling times of different transducers may look as they are plotted against time. A transducer may be described as either real or virtual. A virtual transducer can be created to characterize data which is changing as a function of time. This will enable the state of any data or metadata to be known at any instant in time, because all will be time tagged with a relative clock. This metadata element now can become a "metasensor" which can describe time varying metadata. In this concept all transducers are treated equally or captured and described in the same manner (using a common model). To determine the state of the system of transducers at any instant it will become necessary to interpolate sensor data from one update to the next. By maintaining the proper temporal relationships of the sensor updates this can be accomplished very precisely. This document will define a common model in which to characterize all transducers. This model contains a set of fundamental metadata required to describe any transducer to a common transducer or sensor processor. This fundamental transducer model will be described later. We will use this model to describe the sensors which are in turn used to describe a principal transducer. Instead of having metadata in the header of an image sensor, there will now be sensor data from multiple simultaneous sensors including the principal transducer or sensor, all of which are correlated in time. This also enables the use of very small headers and the capability to customize the data which is required to be associated. Now instead of having one sensor with metadata to support it in the header of that sensor, there can be a multitude of sensors each capturing a metadata parameter which is changing as a function of time. All these transducers will work in unison forming a system of transducers. To keep the relationships of the multitude of transducers straight this specification will also describe a transducer topology concept.

This specification will describe a method of capturing transducer data which is unlike other methods. The data from a transducer will be handled in units of the TCF. Each transducer will have its own TCF configuration. Each TCF of transducer data will be encapsulated in its own shell (measurementTCF) and time stamped with the acquisition time from a system clock and the transducer id number for where it came from. Data from all transducers within a system will be captured this way. Each transducer's data will be captured as though it were the only transducer in the system. The transducer data will not be accumulated to form rectangular images as other standards do, nor will sensor data be inserted into the header of another sensor.

By maintaining this strict temporal correlation of the state (measurement value) of each transducers measurement an instantaneous snapshot of the state of all transducers can be determined at any one instant, even though that instant may not align with the update of all of the sensors in question. By knowing when each transducer's update time was, its value can be interpolated or extrapolated by various means to determine its state at the time in question.

The configuration (size and shape) of the TCFs for a single transducer are all identical, such that there is a one-to-one correlation between samples of a TCF. For example the 5^th sample of the measurementTCF (mTCF) corresponds to the 5^th sample of the coordinateTCF (cTCF), which corresponds to the 5^th sample of the timingTCF (tTCF). If other TCF are defined in the data description then they shall associate in a similar manner.

Typically, spatial characterization of the sensor frame is accomplished by a sensor manufacturer, or at a central calibration facility, or the calibration may be approximated by the sensor system integrator, depending on the degree of accuracy required. The transducer characterization data needs to be sent to the processing location once. If the processing location already has the transducer characterization data it is not necessary to resend it. As hereinafter discussed, as the orientation and position of the transducer changes, appropriate data is communicated via other sensors to the processing location which allows for the rapid interpretation of the changing spatial information.

The timestamp is the precise time in which the sample measurement was taken. This time is used to time correlate all of the sensors in the system. This time will allow temporal corrections to be made by the processor to maintain relative time relationships between sensors. Temporal skew due to transport and archive data buffering and sequencing and sensor data latencies can be accounted for.

A cluster is a data structure mechanism to improve the amount of overhead required to send very small TCFs. For example, to send audio information, where a TCF is composed of one Sample and a Sample is composed of one measurement of 8 bits, and the TCF frame rate (sample rate) was 22KHz. the small headers of TransducerML would soon overwhelm the data and transmission overhead would be very high. To compensate for this, the cluster structure was introduced to group multiple TCF into one "transmission packet" or cluster.

Clusters can also be useful when sending very large TCFs, on the order of many MB. It may be desirable for a number of reasons to break up the large TCF into a number of clusters. A cluster may contain one or more TCFs, or may require more that one Cluster to encapsulate a single TCF.

Figure 34 shows the structure of the Cluster. A Cluster may be composed of one or more Transducer Characteristic Frames (in the case where TCF are small) or the TCF may be broken up into several Clusters (in the case where TCFs are large). The TSF is composed of one or more Samples, and each Sample is composed of one or more measurements.

Cluster

TCF TCF TCF TCF or

Cluster Cluster Cluster Cluster

Transducer Characteristic Frame (TCF)

Transducer Characteristic Frame (TCF)

Sample Sample Sample Sample

Sample

Measurement Measurement Measurement Measurement

Figure 34- Cluster/TCF/Sample hierarchal data structure

TCFs may be grouped into Clusters for transmission or archive efficiency. This may be required when the TCFs are relatively small. When TCFs are relatively large, each 7CF may be split among a set of Clusters. This would enable less latency in the sensor data and would provide synchronization points more often. Each TCF is composed of one or more Samples. The Samples may be arranged .in an n-dirnensional array as defined by the system initialization data. Each Sample is composed of one or more Measurements.

The TransducerML stream will be applicable to several external system configurations. There may be a real time full rate connection between the sensor collector and the processor, in which case TransducerML is used in a live transport mode. There will be "data on the wire" when the sensors are on and "blank space" when sensors are off. Sensor data may be recorded on digital media for replay at a later time or place.

The data description element is a sub element within the TransducerML stream. The data description element is composed of the models (TCF models and function models), transducer descriptions, and the transducer dependencies (system topology).

The data description Element is inserted into the TransducerML Stream at any point where the data description element configuration changes. Figure 35 illustrates a data description element inserted in the data stream to identify that the data description has been updated at this point.. There may be situations when during the TransducerML stream the configuration of the data description Element changes, (e.g. a sensor changes its TCF model), These changes or updates can be accounted for using a data description update element. The update may be a change or an addition. The data description has a system clock time tag in the start tag of the element. This enables the Processor to know exactly when the change occurred.

Start Data_desc The data_desc element describes transducer data model,

Initialization and interrelationships among the transducers in the system.

Data

Data The data element contains the real-time multiplexed Stream transducer data.

Data_desc On occasion, the data_desc element data may need to be Update updated during a transducer acquisition period. The updates are inserted when the change occurs.

Data Stream

End

Figure 35 - Complete data stream structure

The Data stream is composed of sensor clusters. If more than one sensor is in the data stream the sensor clusters will be multiplexed together. Figure 36 and Figure 37 show how this process takes place:

Figure 36 - Time sequence and duration of sensor events in data stream

Figure 37 shows the real-time sensor data multiplexed onto a serial channel. The Cluster is written to the channel at the completion of the Cluster. The timestamp (TS) represents the time of the beginning of the Cluster. Obviously, if more than one channel was available, the Clusters could be multiplexed across the channels using any number of multiplexing schemes.

IS IS IS

Figure 37 - Time multiplexed serial data stream

The sensor data and support data to describe the sensor are packaged for transport to a remote location or to an archive. The shell is generic and uses a markup language as a carrier for the data elements of the model. The extensible Mark-up Language (XML) was chosen as the shell for the exchange and archive of the transducer data and the transducer data description. The shell does not add significant overhead to the basic data elements.

Figure 37 illustrates an exemplary concept for transporting the data elements with the data elements put into tables and transported using a simple header. The header or mark-up for sensor data contains a high resolution time tag and an identifier for the originating sensor type of table being transported.

The time tag represents the value of time for the start of each frame. Fig. 8 illustrates varying sample period for different sensors. Sensors with different update rates are tagged accordingly to maintain frame to frame timing relationships.

Figure 38 gives an idea of how a TML data stream file might look. This is a simplified example of an imaging sensor a IMU and a GPS.

Figure 38 - TML Data Capture Concept

Often times sensor data must be serialized to fit into a communications channel or recording interface in order to transport or archive the data. Accordingly, the order in which the samples which are transmitted (transport order) may not always be the same as the order in which the samples were taken (sampling order). Even more importantly neither of these orders may describe the proper spatial ordering of the samples. The spatial order can be derived by sorting the coordinate TCFs. This can be a very laborious job. For this reason the sequence TCF was add to facilitate the sorting of samples into their proper spatial relationship. When the measurement TCF samples are re-sequenced for transport all of the associated TCF are sequenced the same way. Figure 39 shows two different ways that an array may be scanned for serial transport. There are obviously many different way to serialize the data, so the sequencing method must be robust enough to handle all possibilities. The sequence TCF has array coordinates associated with each sample location in the TCF. When the data is scanned to be serialized the sequence TCF is sent in the same sequence. When the sequence TCF is received it is then re-sequenced to put it back into its intended configuration. When the sequence TCF is sorted the associated TCF models and data are sorted in the same sequence.

3 - Sampling Order

2,4 - Sequence Order >v . - Sample Coordinate

Transport Order 1 Characterization (l,l)(l₎2)(l₎3)(l_>4)(2,l)(2,2)(2,3)(2,4)

Transport Order 2 Characterization (],l)(2,l)(i,2)(22)(l₎3)(2,3)(l_J4)(2,4)

Figure 39 - Sequence Order

To describe the relationships between the sample order and transport order, a sequence order has been defined. The sequence order is the order given to position each individual sample in it proper array position. For example, every sample of a two dimensional data structure will have two coordinates indicating its position in the Transducer Characteristic frame. The coordinates will represent row and column numbers. The next order is the sampling order. The sampling order is given by the timing order in which each sample of the TCF was acquired. The transport order describes the order in which the samples occur in the cluster. The order of the samples may have to be sorted in order to be put back into the proper sequence order.

The best way to explain the TML transducer model and its implementation into XML is to walk through a discussion on the Data Type Description. This walk through of the DTD has been attached to the Patent as Annex A. This Annex will break out the major portions of the DTD and graphically illustrate the data model associated with it as well as a discussion of the uses for each element of the transducer model. It is important to review this description to further understand the capabilities and application of TML.

3 4 Specific Details of the Specification

This detailed description of TML will walk through the Data Type Description showing the data model which is applicable to each section and a description of each element and associated attributes.

The XML document represents a stream. The opening tag initiates the stream. A closing tag terminates the stream. The first element .in the stream should be a system element. The remainder of the stream is any sequence of data_desc elements and data elements. The element TML is the default root element. Specific protocol implementations of TransducerML may replace the root element. The default root element designates the version of the schema (document type). When implemented in protocols, the namespace designation for the elements will indicate the version. TML implements a time tagged implementation of XML. What this means is that a system time clock count is inserted into the start tag of tml elements to signify the relative time (from the sys_clk) of when the data contained in each TML element was acquired. The system elk should be of sufficient resolution to adequately relate time differences at a transducer sample sub-sampling interval (approximately an order of magnitude faster that the fastest sample clock in the system) and enough digits to minimize the possibility of a roll over.

4.1 ELEMENT tml

Figure 40 - tml (root)element DTP:

<!KLEMENT tml (data_desc*, data*)> <!ATTLIST tml version CDATA #FIXED "0.92beta 030727" id ID IREQUIRED >

<!ELEMENT data_desc (sys_clk?, models?, transducers?, relations?) > <!ATTLIST data desc elk CDATA #REQUIRED > <! ELEMENT data (cluster+)>

Path:

© COPYRIGHT IRIS CORPORATION 2003 tml

Description:

The tml element is the root element. Every TML file or stream will have a beginning <tml> and ending </tml> tag. The TML (Transducer Mark-up Language) is a specific implementation of XML (extensible Mark-up Language), with a well defined Document Type Definition (DTD). TML is specifically designed for the exchange of simultaneous sensors and emitters (transducers) data. TML does not define how to represent the transducer data.

Data type: UTF-8 (character) Attributes:

> "version" - (fixed) the version attribute identifies the version of the TML to which the file or stream complies. Currently this value is fixed at "0.92beta"

> "id" - (required) a unique id or identifier is given to the entire TML file or stream. In the event that a single system is processing TML data from different systems the data can be related.

Child Elements:

> (0 or more) da t a_de s c elements and

> (0 or more) da t a elements

4.1.1 ELEMENT data desc Path: tml>data_desc

Description:

The data_desc element contains all of the information required of a TML processor to process data from any set of transducers. The data desc element may or may not become part of the TML data exchange, depending on whether the subscriber already has the data desc information or not. If the TML subscriber has never seen or processed the particular set of transducers or the particular configuration of transducers then the subscriber should request that the publisher send the data desc element prior to sending the transducer data. The subscriber also has the option to download the particular system element from a secure URN prior to receipt of the TML data. The data_desc element was designed with plug and play transducers in mind. The transducer element and the applicable model elements can be carried internally to each transducer. When a transducer is connected to a system it automatically supplies the system with the transducer element information including all of the model and calibration data. This data is automatically integrated into the TML data stream. The systems integrator need only configure the relationship of the transducer to the other transducers. A data description of a system of transducers may change after the stream of data has begun. These changes come as data_desc elements interleaved between data elements. The data description update can contain new sys_clk, models, transducer models, or relations updates. For transducer updates and dependency updates, only the information that has changed is sent. Updates are sent within the proper nested elements.

Attributes:

> ^λΛclk" - (required) identified the time using sys_clk time when data description applies. The state of data description is steady until updated. Updated data description elements will have new time values.

Child Elements;

> (0 or 1) sy s_cl k elements and

> (0 or 1) model s elements and

> (0 or 1) transducers elements and

> (0 or l) relations elements

4.1.2 ELEMENT data

Path: tml>data

Description:

The <data> element contains all of the <cluster> elements which carry the transducer data. This element carries "pure", "raw" transducer data. The <data_desc> element must be read to know that the format, structure, and relationships of the data clusters.

Child Elements:

> (1 or more) cluster elements

4.2 ELEMENT data_desc

The data_desσ element contains the sequence of elements: sys_clk, models, transducers and relations, in that order. A data_desc element has a unique identifier. The data desc element provides the metadata the ability to describe the various transducers which make up a

©CO YR GHT IRS CO PO IO transducer system. It provides a description of each of the transducers, how the transducer data is structured and the relationships between the transducers. The data desc element should be resident at the destination system prior to receiving any transducer data. The data desc element may be omitted from the stream if the receiving system already has the particular system element. Likewise any elements within the system element may be omitted from the system element if they are already resident at the destination, (e.g. transducer model)

Figure 41 - data_desc element

DTD:

< ! ELEMENT datajdesc (sys_clk?, models?, transducers?, relations?) > < ! ATTLIST data_desc elk CDATA ^REQUIRED >

< ! ELEMENT sys_clk (period, rel_accy?) > < ! ELEMENT per i od ( # PCDATA ) > < ! ELEMENT rel_accy (#PCDATA) > < !ATTLIST rel_accy tcfmod_dep_id_ref IDREF ttIMPLIED dependency_id~ref IDREF #IMPLIED >

< ! ELEMENT models (model+) > < ! ELEMENT model (mod_desc, datapoints) > < ! ATTLIST model type (fjmodel | tcf_model) IREQUIRED id ID #REQUIRED fcn_modify (replace | add | multiply) IIMPLIED >

< ! ELEMENT transducers (transducer+) >

< ! ELEMENT transducer (trans_desc, clust_desc, sample) > < ! ATTLIST transducer id ID IREQUIRED urn CDATA tIMPLIED >

< ! ELEMENT relations (dependency+) > < ! ELEMENT dependency (mod dep*, attached*, dangle*, position?, attitude?) > <!ATTLIST dependency trans_ref IDREF #REQUIRED >

4.2.1 ELEMENT sys_clk Path: tml>data_desc>sys_clk

Description:

The system clock is used to temporally align the start of transducer characteristic frames among frames from the same transducer and frames from other transducers. The sys_clk is a stable, high resolution counter whose count value is latched and recorded in the start tag of each transducer cluster at the instant the first sample of the first TCF within the cluster is measured. Ideally the sys_clk should run at least an order of magnitude higher than the highest sampling rate of any of the captured transducers. The sys_clk maintains relative alignment of transducer data. To correlate the transducer data with a world time reference (i.e. GPS, UTC) a chronograph can be utilized as one of the sensors in the transducer suite. The output TCF of the chronograph will have a sys_clk value in the start tag of the TCF or cluster. The sys_clk value and the world time captured by the chronograph sensor are then relatable.

Child Elements:

> (1) period element, and

> (0 or l) accy element

4.2.2 ELEMENT period Path: tml>data_desc>sys_clk>period

Description:

The period element describes the time period in seconds of one count of the sys_cl k .

Data type:

Float 4.2.3 ELEMENT rel_accy

Path: tml>data_desc>sys_clk>rel_accy

Description:

The rel_accy element describes the average drift in temporal accuracy over time. This value is unsigned. A value such as 1E-9 would indicate a one count error in 1E9 counts of the clock. The relative time accuracy needs to be taken into account when comparing data from different times. The temporal error may not be significant unless the time difference is large or the rel_accy is large. Temporal errors are a contributing error for the derivation of resultant positional and temporal error estimates.

Data type:

Float

Attributes:

> "tcfmod_dep_id_ref" - (optional) This attribute is used to reference a model dependency id which points to a TCF model that describes the relative accuracy as a function of sample position within the TCF.

> "dependency_ID_ref " - (Optional) This attribute is used if the relative accuracy of the parent element value varies with time and is measured by another sensor. The "dependency_id_ref" attribute is a reference to the dependency number which identifies the sensor that measures the <rel_accy> value.

4 . 2 . 4 ELEMENT models

Path: tml>data_desc>models

Description:

Models form the basis for describing the individual characteristics of each transducer. One objective of TML is to facilitate plug-n-play transducers into a system. The transducer models may be derived by the manufacturer or a certification facility and installed into the transducer or transducer interface. Preferably the models are carried along with the transducer and integrated into whatever system the transducer is plugged into. Each transducer will have a set of models to describe its characteristics to varying degrees of fidelity. The higher the fidelity of description required - the more robust the model descriptions are. In many cases the models can be implied (i.e. derived with actually sending or receiving them) as a first order fidelity. If higher fidelity is required then the detailed models must be sent. There are two types of models: function models (f_jnodel) and TCF models (tcf_jnodel). Function models are for characterizing transducer properties such as frequency response, input-output transfer functions and IFOM beam patterns. TCF models are for characterizing transducer properties which have parameters that vary as a function of sample position within the TCF, such as detector look angles, sample time within TCF, and radiometric correction. For example, the coordinate TCFs (cTCFα and cTCFβ) used to describe the α and β angle of the look vector of each particular sample within the TCF of an optical camera can be estimated by knowing the α and β range (FOV) and the number of rows and columns in that area. If the need arises to characterize any non-linearities or aberrations in the geometry the TCFs will actually be used. The TCF models used to describe a transducer have the same number of samples, the same number of dimensions and the same size of each dimension as the TCF used to capture the data from the transducer, so there is a one-to-one correlation between the measurement and the TCF model characteristic.

Child Elements:

> (0 or more) model elements, and

> (0 or more) transducer elements

4.2.5 ELEMENT model

Path: tml>data_desc>models>model

Description:

Function models (fjnodel) are for modeling functions. The function is described using a set of data points. The set of data points represent the range (dependent variable or y axis). The range data points comprise the f_model. To use the fjnodel the domain (independent variable or x axis) must be known. The place where the fjnodel is used in the TML structure will describe the domain by describing its start value, end value or range, scale (log|linear), and number of equidistant points between the start and end. Characteristics which can be modeled with fjnodels include but are not limited to IFOM profiles or point spread functions, input-output transfer functions, and frequency response or power spectral density functions.

TCF models (tcfjnodel) are for characterizing transducer attributes which have parameters that vary as a function of sample position with the TCF. This element contains the elements to describe a particular TCF model. TCF models relating to a single transducer all have the same structure, i.e. dimensionality, size, and sequence (or order). There is a one-to-one relationship between corresponding elements within a TCF from a single transducer. For example: the fourth sample of a coordinate TCF corresponds to the fourth sample of the timing TCF, which corresponds to the fourth sample of the measurement TCF, and so on.

Data type: UTF-8 (character) Attributes:

> "type" - (required) the model will either be a function model or a TCF model type.

> "id" - (required) A unique id or identifier is given to the function model. The convention for f rnodel id's are to begin each id with the letter "f followed by a sequential number. For example id="fθθl". A unique id or identifier is given to each tcfjnodel as well. The convention for tcfjnodel id's are to begin each id with the letters "tcf" followed by a sequential number. For example id="tcf001 ".

> "fcnjnodify" - (Optional) TCF models other than coordinate, timing, and sequence modify a transducer single value characteristic that may vary over a TCF such as gain. The TCF can either replace the single value characteristic, add to it, or multiply by it (replace | + 1 x). The following rules describe how the TCF model and the attached sensor modify the transducer characteristic. If no TCF or attached sensor is available for a characteristic then the characteristic is the single value found in the characteristic element. If a TCF model is available then the TCF model will modify the single value according to the "f cnjmodif y" attribute. If only an attached sensor is present then the attached sensor value will modify the single value according the to "f cn_modif y" attribute in the attached sensor. If both a TCF model and an attached sensor are present for a single characteristic then the TCF model will modify the single value according the the "f cn_modif y" attribute, and the attached sensor will modify the resulting value of the TCF model and the fixed value according to the "f cnjnodif y" attribute of the attached sensor.

For a transducer characteristic:

> Each TCF sample = (single element value) or

> Each TCF sample = (single element value) (replace | + 1 x) (each TCF model sample) or

> Each TCF sample = (single element value) (replace j + j x) (variable sensor value) or

> Each TCF sample = (single element value) (replace | + 1 x) (each TCF model sample) (replace I + 1 x) (variable sensor value)

Child Elements:

> (1) mod_desc elements and, ^ (1) datapoints element

4.2.6 ELEMENT transducers Path: tml>data desc>transducers Description:

The transducers element contains the set of all transducer elements in the system (or suite) of transducers. The transducer element is independent of the relation element. Each transducer stands alone until a systems integrator defines the relationships between the transducers.

Child Elements:

> (1 or more) transducer elements

4.2.7 ELEMENT transducer

Path: tml>data_desc>transducers>transducer

Description:

The transducer element contains the set of all data required to characterize a single transducer. Transducers may use models to characterize parameters or characteristics of a transducer. The models may be shared among transducers.

Attributes:

> "id" - (required) A unique id or identifier given to each transducer. The convention for transducer id is to begin each id with the letter "t" followed by a sequential number. Note: when a transducer is removed from one system and inserted into another the sequential id may change.

> "urn" - (required) The universal resource name identifies a location where the characteristics of a particular transducer can be found. This enables a transducer processor to read the transducer characteristics prior to receiving the transducer data, and negating the requirement to transmit the transducer description data along with the transducer data.

Child Elements y (I) trans_desc elements

> (1) clust_desc elements

> (1) sample elements

4.2.8 ELEMENT relations

Path: tml>data_desc>relations Description:

This element contains the set of <dependency> elements. The <Transducers> and <Models> elements stand alone and do not provide any connections (relations) between them. The <relations> element provides the exterior orientation and relationships between transducers & transducers, and transducers and models. The <relations> element data is completed by the transducer system integrator whereas the <transducers> and <models> element data contain the interior orientation of the transducer can be carried with each individual transducer for a plug and play capability. Relations are defined outside of the transducer definition in order to enable plug-and-play of transducers into different systems. The relations section enables us to plug-and-play transducer together into a data_desc definition. We are primarily concerned with plugging together the position and attitude of transducers. The position and attitude are the key properties necessary for most sensor fusion efforts. However, any property or characteristic of a transducer can be dependent upon another sensors measurement. The relations element contains zero or more dependency elements. Each dependency element references a particular transducer by its unique identifier. All the dependencies for a particular transducer should be defined within a single Relations element.

Data type: UTF-8 (character) Child Elements:

> (1 or more) dependency elements

4.2.9 ELEMENT dependency Path: tml>data desc>relations>dependency

Description:

This element describes a single relationship between a transducer and a transducer or a transducer and a model. Each dependency will be assigned a dependency id number. The dependencies do not identify where the dependency comes "from", the dependency id needs to be traced back to find where the dependency originates. The dependency only points "to" a model, a measurement or a transducer. There are five type of dependencies: mod_dep, attached, dangle, position and attitude. The model dependencies identify the TCF or function model assigned to a particular transducer. The attached dependency comes from a dependency reference from within the <transducers> element. The dependency will assign a measurement from an external (real or virtual) transducer to track a changing parameter from within a subscribing transducer. The dangle dependency is to associate other types of measurement to a particular transducer. This can be used to communicate mode settings or to associate diagnostic or transducer system health data. The dangle dependency does not originate from within the transducer element (i.e. does not have a "from" point). The dangle dependency provides data about the parent transducer as a whole. The description of the dangled transducer provides specific description as to its relationship with the parent transducer. The position and attitude dependencies provide the exterior orientation of a transducer relative to the earth or another transducer. All of the transducers should be referenced back to the earth (ECEF reference system) as the common datum.

Data type: UTF-8 (character) Attributes:

> "trans_ref " - (Required) This attribute identifies (transducer id number) what the id number of the parent transducer is (e.g. t004). Relationships always start from the top or principal transducers as the parent. This is the transducer that:

• is the parent of a model or another transducer

• is relative in position or attitude to another transducer or earth

• has another transducer attached to measure an dependent (embedded) characteristic of it

• has another transducer dangling from it to describe other characteristics without being attached to and embedded characteristic (e.g. mode setting, detector temp, vibration,...)

Child Elements:

> (0 or more) mod_dep elements and

> (0 or more) attached elements and

> (0 or more) dangle elements and

> (0 or 1) position element and

> (0 or 1) attitude element

4.3 ELEMENT model

The models element contains one or more model elements. The model element contains a datapoints element and may contain a description element. There are basically two types of models: function models and TCF models. TCF models have been discussed earlier describing characteristics such as how the spatial and temporal distribution of samples exist across the TCF and the sequence to describe how samples have been reorder due to transport. The function model can describe any 2 or 3 dimensional fraction such as IFOM, frequency response, or input-output transfer functions. The description element is generic throughout the schema. A model has an identifier unique within the data_desc definition. A 2-dimensional ftinction model defines a curve or the values of the normalized range of values (y) of a function where the domain (x) is defined elsewhere. The domain is defined by parameters such as xjrange, and x_center. The data points are evenly distributed across the domain (x-axis). The three dimensional functions only add another dimension to the independent variable.

Figure 42 - model element

DTD:

<!ELEMENT model (mod_desc, datapoints)> <!ATTLIST model type (fjnodel | tcf_model) #REQUIRED id ID #REQUIRED fcnjnodify (replace | add | multiply) tIMPLIED >

<! ELEMENT mod_desc (nomenclature, columns?, rows?, planes?) > <! ELEMENT nomenclature (#PCDATA)> <! ELEMENT columns (#PCDATA)> <! ELEMENT rows (#PCDATA)> <! ELEMENT planes (#PCDATA)> < !ELEMENT datapoints (#PCDATA)> <!ATTLIST datapoints count CDATA IREQUIRED >

4.3.1 ELEMENT mod_desc Path: tml>data_desc>models>model>mod_desc

Description:

The mod_desc element is common to the model elements within TML The mod_desc contains as a minimum a nomenclature for the model. If the TCF has a raster structure then the tcfjnodel descriptions will contain descriptions of the number of rows, columns and planes. The tcfjnodel datapoints will be read in column (left-to-right) then row (top-to-bottom) then plane (front-to-back) order respectively.

Child Elements:

> (1) nomenclature element, and

> (0 or 1) column element, and

> (0 or 1 ) row elem ent, and

> (0 or 1) plane element

4.3.2 ELEMENT nomenclature

Path: tml>data_desc>models>model>mod_desc>nomenclature

Description:

The nomenclature is a short name given to describe the model such as: "frequency response" or "alpha coordinate". Function models represent two dimensional functions (dependent and independent variables) and are used to describe transducer characteristics such as IFOV, frequency response, power spectral density, and input/output transfer functions. TCF models represent how transducer characteristics vary over the TCF such as relative locations of sample ambiguity spaces, sample timing relationships, and detector radiometric gain adjustments.

Data type: UTF-8 (character)

4.3.3 ELEMENT columns

Path: tml>data_desc>models>model>mod_desc>columns

Description:

Many times a remote transducer data structure relates to the spatial distribution of the samples which make up an image. If the model has an orthogonal data structure (the spatial distribution of samples may not be orthogonal and still have an orthogonal data structure, e.g. conical scan) then the samples within the TCF can be described as having row, columns, and planes. The row number is incremented after the column number has been incremented through the entire range. If the description of a model has a row, column, or plane descriptor the model can be easily organized into an n-dimensional matrix. The column increment is the most rapid incrementing dimension of the array. The column is normally thought of as having a constant x (row) and variable y (column) within a single plane of computer memory space.

Data type: Float

4.3.4 ELEMENT rows

Path: tml>data_desc>models>model>mod_desc>rows Description:

Many times a remote transducer data structure relates to the spatial distribution of the samples which make up an image, If the model has an orthogonal data structure (the spatial distribution of samples may not be orthogonal and still have an orthogonal data structure, e.g. conical scan) then the samples within the TCF can be described as having row, columns, and planes. The row number is incremented after the column number has been incremented through the entire range. The row is normally thought of as having a constant y with variable x dimension within a plane of computer memory space. The rows, columns and planes correspond to the transducer data structure and not the spatial or scanning structure of the transducer. A non-dimensional transducer will not have any rows, columns, or planes in its description. A one-dimensional transducer may have rows, columns, or planes in its description. A two-dimensional transducer may have rows and columns, rows and planes, or columns and planes in its description. A three dimensional transducer may have all three, rows, columns, and planes in its description. The samples with a TCF may or not be sorted, so even though a TCF can be organized into a neat matrix, it does not mean that samples are in their proper position relative to their spatial orientation. If a samples are not in their proper order, then a sequence TCF will be made available to re-sequence the transducer samples within the TCF space. If a TCF does not have an orthogonal structure then no rows, columns or planes description is given even though the transducer may have a dimensionality greater than 1. When this is the case the coordinate TCF's must be utilized to position the samples in space.

Data type: Float

4.3.5 ELEMENT planes Path: tml>data desc>models>model>mod_desc>planes

Description:

Many times a remote transducer data structure relates to the spatial distribution of the samples which make up an image. If the model has an orthogonal data structure (the spatial distribution of samples may not be orthogonal and still have an orthogonal data structure, e.g. conical scan) then the samples within the TCF can be described as having row, columns, and planes. The row number is incremented after the column number has sequenced through the entire range. If the description of the tcf has a row, column, or plane description then the tcf can be easily organized into an n-dimensional matrix. The plane number is the last number to increment after the row has incremented through its entire range. The plane is normally thought of as giving depth (z value) to the xy plane as it is organized in computer memory space.

Data type: Float

4.3.6 ELEMENT datapoints

Path: tml>data_desc>models>model>datapoints

Description:

The data points represent the ordinate or corresponding value of the independent variable. The independent variable is given in the location which references the function model. The independent variable is a set of equidistant points on the x axis. The scale of the x-axis can be linear or logarithmic.

Data type:

Float

Attributes:

> "count" - (required) This value represents the number of values which are separated by a space in the corresponding value of the datapoints element.

4.4 ELEMENT transducer A transducer has a identifier unique within the data_desc definition. Preferably, transducers would use a uniform resource name (URN) as their identifier. In a protocol implementation, a stream could begin with a simple empty sensor element as follows:

<transducer id="tθθl " urn=^llurn:x-dod:transducer:af: 123456789- 102"/>

The subscriber could check if it has this transducer definition already locally stored. If not, then the subscriber could look up the sensor in some well-known repository. If that should fail, then the subscriber could ask the publisher to send the complete sensor definition. Within the stream, elements would reference the stream by its shorter ID attribute rather than its longer URN attribute.

Figure 43 - transducer element

DTD:

<! ELEMENT transducer (trans_desc, clust_desc, sample) >

< !ATTLIST transducer id ID #REQUIRED urn CDATA #IMPLIED >

<! ELEMENT trans_desc (nomenclature, model_no?, serial_no?)> OELEMENT model_no (#PCDATA)> <!ELEMENT serial_no (#PCDATA)> <! ELEMENT clust_desc (tcf per_clust?, tcf)> <!ELEMENT tcf_per_clust (?PCDATA)>

<! ELEMENT tcf (tcf_desc, tcf_time?, tcf_coord*, tcf_seq*)> <! ELEMENT sample (measure+)>

<! ELEMENT measure (meas_desc, encoding, abs_accy?, rel_accy_intertcf?, rel_accy_intratcf?, freq_resp?, ifom*, io_xfer_fcn*, cal_ref*, meas_ref?)> < !ATTLIST measure id ID #REQUIRED > 4.4.1 ELEMENT trans_desc

Path: tml>data_desc>transducers>transducer>trans_desc

Description:

This is a description of the particular transducer and the measurements it takes, and possibly its relationship within the system. If the transducer is a virtual transducer it shall be noted in this description.

Child Elements:

> (1 ) nomenclature and

> (0 or 1) model_no and

> (0 or l) serialjio

4.4.2 ELEMENT nomenclature Path: tml>data_desc>transducers>transducer>trans_desc>nomenclature

Description

The nomenclature is a short name given to the transducer. Example: "Infrared Line Scanner"

Data type:

UTF-8 (character)

4.4.3 ELEMENT model_no Path: tml>data_desc>transducers>transducer>trans_desc>model_no

Description:

The value for this property identifies the model number for the subject transducer. If the transducer is a virtual transducer this element is not required. Data type: Float

4.4.4 ELEMENT serial_no

Path: tml>data_desc>transducers>transducer>trans_desc>serial_no

Description:

The value for this property identifies the model number for the subject transducer. If the transducer is a virtual transducer this element is not required.

Data type: Float

4.4.5 ELEMENT clust_desc Path: tml>data_desc>transducers>transducer>clust_desc

Description:

The <clust_desc> element contains the set of elements which describe the number or fractional number of TCFs per cluster (<tcf_per_clust> ) and the set of elements (<tcf>) which describe the incorporated TCF

Child Elements:

> (0 or 1) tcfjper_clust, and

> (l)tcf

4.4.6 ELEMENT tcf__per_αlust Path: tml>data_desc>transducers>transducer>clust_desc>tcf_per_clust Description:

The cluster is a data structure for transporting TCFs. Sometimes it is more efficient (i.e. less overhead) to group small TCFs into a larger cluster to transport them. Similarly, in other cases it may be beneficial to split up large TCF into smaller clusters to acquire a sync more frequently. When multiple TCFs are incorporated into a single cluster, the sys_clk in the start tag is the time for the first sample of the first TCF. The sys_clk for the following TCFs are calculated offsetting each TCF by the tcf_period. If the TCFs do not have periodic update rates then it is not possible to cluster TCFs. This element gives the integer number of TCF in a cluster (3 = 3 TCFs per Cluster), if the TCF is split into several clusters then the value shall be negative indicating the number of clusters per TCF (-3 = 3 Clusters per TCF). If multiple clusters are used to transport a single TCF then the sys_clk in each of the clusters for the same TCF shall have the same sys_clk value. The order or relative sequence of the clusters for a single TCF must not be disturbed during transport.

Data type: Integer

4. 4 . 7 ELEMENT tcf

Path: tml>data_desc>transducers>transducer>clust_desc>tcf

Description:

This element contains the set of elements which describe the characteristics of the TCF for a particular transducer. There will be one TCF described for every transducer.

Child Elements:

> (1) tcf_desc element

> (0 or l) tcf_time element

> (0 or more) t cf _coord element

> (0 or more) tcf_seq elements

4.4.8 ELEMENT sample

Path: tml>data_desc>transducers>transducer>sample Description:

This element contains the set of elements which characterizes the transducer sample. Every transducer will have at least one <sample> element. The transducer sample is composed of one or more measurements.

Child Elements:

> (1 or more) measure elements

4.4.9 ELEMENT measure

Path: tml>data_desc>transducers>transducer>sample>measure

Description:

This element contains the set of elements which characterizes each measurement of a transducer. There will be at least one measurement for every sample. More than one IFOM element can be used so that multiple power levels can be plotted. Likewise, more than one IO transfer function can be characterized so that the hysteresis can be characterized by plotting the forward and reverse direction of the function.

Attributes:

> "id" - (Required) The id enables each measurement to be indexed. Measurements can be attached to other measurements through the dependency relation.

Child Elements:

^ (1) meas_desc element y (1) encoding element

> (0 or 1) abs__accy elements

> (0 or 1) rel_accy_intertcf elements

> (0 or 1) rel_accy_intratcf elements

> (0 or 1) f req_resp or psd element

> (0 or more) i font element

> (0 or more) io_xf er_f en or oi_xf er_f en element

> (0 or more) cal_ref elements

> (0 or 1) raeas_ref elements

C 4.5 ELEMENTtCf

Transducer Characterization Frame

Figure 44 - tcf element

DTP:

<! ELEMENT tcf (tcf_desc, tcf_time?, tcf_coord*, tcf_seq*)>

<! ELEMENT tcf_desc (dim, coord_sys?, no_samples)>

<! ELEMENT dim (#PCDATA)>

<! ELEMENT coord_sys (#PCDATA)>

<! — spherical | cartisiean — >

<! ELEMENT no_samples (#PCDATA)>

<!ELEMENT tcf_time (tcf_duration, tcf_period, ticks, rel_accy?)>

< !ATTLIST tcf_time

«ιod_dep_id_ref IDREF # IMPLIED >

<!ELEMENT tcf_coord (coord_assoc, coord_range, ticks)> < !ATTLIST tcf_coord tcfmod_dep_id_ref IDREF #IMPLIED >

<! ELEMENT coord_assoc (#PCDATA)> <! ELEMENT coord_range (#PCDATA)> <!— e.g. FOV- > < !ATTLIST coord_range dependency_id_ref IDREF I IMPLIED >

<! ELEMENT tcf_seq (start?, end?)> <! ATTLIST tcf_seq tcfmod_dep_id_ref IDREF #IMPLIED >

< ! ELEMENT start (IfPCDATA) > < ! ELEMENT end ( #PCDATA) >

4.5.1 ELEMENT tcf_desc Path: tml>data_desc>transducers>transducer>clust_desc>tcf>tcf_desc

Description:

This element contains the elements which describe the TCF. The enclosed elements include the <dim> element, the <coord_sys> element, and the <no_samples> element.

Child Elements:

> (1) dim element and

> (0 or 1) coord_sys element and

> (1) no_samples element

4.5.2 ELEMENT dim Path: tml>data_desc>transducers>transducer>clust_desc>tcf>tcf_desc>dim

Description:

This is the dimensionality of the TCF. The dimensionality is equal to the number of spatial coordinates assigned the coordinate TCF. For example a CCD optical camera would have a two dimensional TCF. Each sample of the measurement TCP correlates to two coordinate TCFs which describe the alpha and beta coordinate for each sample of the TCF. Alpha and beta are the spherical coordinates relative to the transducer reference system.

Data type: Integer

Allowed values: 0, 1, 2, and 3. 4.5.3 ELEMENT coord_sys

Path: tml>data_desOtransducers>transducer>clust_desc>tcf>tcf_desc>coord_sys

Description:

This property will be utilized for remote sensors and emitters only. This property identifies the coordinate system used to characterize the transducers spatial coordinates. In situ sensors have non-dimensional TCFs, so no spatial coordinates are assigned to the TCF.

Data type: UTF-8 (character) Allowed values: "cartesian" and "polar"

4.5.4 ELEMENT no_samples

Path: tml>data_desc>transducers>transducer>clust_desc>tcf>tcf_desono_samples

Description:

This is an integer count of the number of samples in the entire TCF

Data type:

Integer

4.5.5 ELEMENT tcf _time Path: tml>data_desc>transducers>transducer>clust_desc>tcf>tcf__time

Description: This element contains the set of elements which describes the timing aspects of the transducers sampling characteristics. The timing characteristics include TCF time duration, TCF period, number of time ticks per TCF duration, and relative accuracy of the timing offsets. The tcfmod_jdep_id_ref attribute references a TCF model if appropriate which gives the temporal offset of each sample (in time ticks) in the TCF relative to the first sample. It should be noted that the time for the time ticks may be different than the sysjime. The sysjime clock count for each sample can be calculated by taking the clock value in the start tag and adding the corresponding offset calculated as follows; (t_n*(<tcf_time_duration>/<ticks>))/<period>, where t_π is the corresponding time tick value from the tTCF for a particular sample within the TCF.

Attributes:

> "tcfmod_dep_id_ref" - (optional) This attribute references the dependency which references the tTCF model.

Child Elements:

> (l) tcf_duration element and

> (1) t cf__period element and

> (1) tics element and

> (0 or 1) rel_accy elements

4.5.6 ELEMENT tcf_coord Path: tml>data_desc>transciucers>transducer>clust_desc>tcf>tcf_coord

Description:

This element contains the set of elements which describe the spatial characteristics of the transducer. There are n number of <tcf_coord> elements for each transducer, where n is the dimensionality of the transducer. Each sample from a transducer will have 0 or more coordinates assigned to it. The dimensionality of the TCF describes the number of coordinates assigned to each sample. Coordinates for transducer measurement samples are contained in coordinate TCF models.

Attributes:

> "tcfrαod_dep__id_ref" - (Optional) This attribute points (indirect pointer) to the dependency id which points to the TCF model which enumerates the spatial coordinate (identified in the <coord_assoc> element value, e.g. alpha) for the corresponding sample in the TCF. Child Elements: > (1) <coord_assoσ> elements ^ (1) <coord_range> elements

> (1) <ticks> elements

4.5.7 ELEMENT coord_assoc

Path: tml>data_desc>transducers>transducer>tcf>tcf_coord>coord_assoc

Description:

There is a <coord_assoc> element for each <coord> for each transducer. The number of coordinates for a transducer is defined by the dimensionality <dim> of the transducer TCF. The <coord_assoc> identifies the spatial coordinate assigned to a particular coordinate of the TCF or each sample. Coordinates are contained in the coordinate TCFs. A single coordinate TCF (cTCF) contains the value of a single coordinate for every sample in the TCF. If more than one coordinate is required then additional coordinate TCF shall be used. This element identifies which coordinate is assigned the cTCF which the <tcf_coord> references using the "tcfmod_dep_id_ref" (indirect pointer) attributes. Allowed values are for the <coord_assoc> element are: alpha, beta, r, x, y, and z.

Data type: Integer

4.5.8 ELEMENT coordjrange Path: tml>data__desc>transducers>transducer>tcf>tcf_coord>coord_range

Description:

There is a range value for every coordinate. The range describes the extent of the spatial coordinate described in <coord_assoc> . For example if the <coord_assoc> were alpha or beta then the range would be an angular measurement representing the Field of View. Likewise, if the <coord_assoc> were r, x, y, or z then this element would contain the linear measurement in meters describing the extent of the TCF relative to the transducer reference system. If the <coord_range> is variable then it will be measured with a sensor which is referenced using the "deρendency_id_ref " attribute. Data type:

Float

Attributes:

> "dependency_id_ref" - (Optional) This attribute points to the dependency id that points to the transducer which measures the coordinate range. The <fcn_modify> elements contained in the <dependency> describes how the sensor modifies the <coord_range> value.. For example the <coord_range> value could be multiplied by the sensor value.

4.5.9 ELEMENT ticks

Path; tml>data_desc>transducers>transducer>clust_desc>tcf>tcf_coord>ticks

Description:

This is the number of equal-time or equal-angular or equal-distance intervals which divide up the TCF time duration or coordinate range The number of ticks are typically an order of magnitude greater than the number of samples such that any perturbations or non-linearties in time or coordinates can be characterized.

Data type: Integer

4.5.10 ELEMENT tcf_seq

Path: tml>data_desc>transducers>transducer>tcf>tcf_seq

Description:

When measurement TCFs are exchanged or transported the. order may not be in sequential column, row, plane sequence. When measurements within the measurement TCF (mTCF) are- unordered the the other TCFs are unordered in the same manner. The measurement TCF can be sorted by sorting the coordinate TCFs, however this is a long process. To speed things up the sequence TCF was added to speed up the sorting on unordered samples. When this is the case a sequence TCF (sTCF) can be used which gives the column, row, plane coordinates for the unordered measurement TCF. When the sequence TCF is sorted then all the other TCFs are sorted in the same manner. There are n sequence TCFs, where n is the dimensionality (1-3) of the TCF. Each sTCF contains the column, row, or plane coordinates. The start and end elements give the starting and ending column, row, or column number for the sequence TCF.

Attributes:

> "tcfmod_deρ_id_ref " - (Optional) This attribute points to the dependency id that points to the TCF model that gives the Cartesian coordinate (column, row, plane) of each of the TCF samples.

Child Elements:

> (0 or 1) start element, and

> (0 or 1) end element

4.5.11 ELEMENT start

Path: tml>data_desc>transducers>transducer>tcf>tcf_seq>start

Description:

This element indicates the starting value of the transport order of the sequence for either the column, row or plane coordinate. If the TCF is a three dimensional structure then three TCFs will be required: one for column, one for row, and one for plane. The start and end number enable a simplified sequencing if only the scan direction changes. For example when row start and end number's are 1 and 714 respectively then the scan is properly sequenced and requires no column sorting in the row, however if the start and end numbers were 714 and 1 respectively then the columns in the row need to be reversed. The same applies to the row and plane coordinates.

Data type: Integer

4.5.12 ELEMENT end

Path: tml>data_desc>transducers>transducer>tcf>tcf_seq>end Description:

This element indicates the ending value of the transport order of the sequence for either the column^ row or plane coordinate. If the TCF is a three dimensional structure then three TCFs will be required: one for column, one for row, and one for plane. The start and end number enable a simplified sequencing if only the scan direction changes. For example when row start and end numbers are 1 and 714 respectively then the scan is properly sequenced and requires no column sorting in the row, however if the start and end numbers were 714 and 1 respectively then the columns in the row need to be reversed. The same applies to the row and plane coordinates.

Data type: Integer

4.6 ELEMENT tcf time

Figure 45 - tcf time element

DTD:

<! ELEMENT tcf_time (tcf_duration, tcf_period, ticks, rel_accy?)> <!ATTLIST tcf_time mod_dep_id_ref IDREF #IMPLIED >

<! ELEMENT tcf_duration (time, abs_accy?, rel_accy_intertcf?) > <! ATTLIST tcf~duration dependency_id_ref IDREF #IMPLIED >

<! ELEMENT time (#PCDATA)>

<!ELEMENT tcf_period (time, abs_accy?, rel_accy_intertcf?) > < !ATTLIST tcfjperiod dependency_id_ref IDREF #IMPLIED

>

<! ELEMENT ticks (#PCDATA)>

4.6.1 ELEMENT tcf_duration

Path: tml>data_desc>transducers>transducer>clust_desc>tcf>trans_time>tcf_duration

Description:

The elapsed time in seconds between the time of the first sample and the time of the last sample: This is the duration of the. TCF. The duration id divided up into ticks or a number of equal-time intervals. The sample times recorded in the tTCF are given in tick offsets within this duration. If the TCF duration varies then it can be measured with a sensor. The Mependency_JLd_ref " attribute points (indirect pointer) to the dependency id that points to the sensor which measures the duration.

Attribute List:

> "dependency__ID_ref " (Optional) If the time duration is not constant then the duration can be measured with a sensor. This attribute references a dependency id which references the sensor which measures the TCF duration. The <f cnjnodif y> elements contained in the <dependency> describes how the sensor modifies the <t cf_duration> value by either a multiply, add, or replace operation.

Child Elements:

> (1 ) t ime elements, and

> (0 or 1) abs_accy elements, and

> (0 or 1) rel_accy_intertcf elements

4.6.2 ELEMENT time

Path: tml>data_desc>transducers>transducer>clust_desOtcf>trans_time>tcf_duration>t ime

Description This element contains the time value in seconds for the <tcf_duration> and the <tcf _period> elements. The accuracy of this time is characterized in the parent element.

Data type: Float

4.6.3 ELEMENT abs accy

Path: tml>data_desc>transducers>transducer>clust_desc>tcf>tcf_time>tcf_duration>abs _accy

Description:

This value contains the 2 sigma value of the deviation of the absolute measurement accuracy based on NIST standards. If the abs_accy varies as a function of TCF sample position then a TCF model will enumerate the accuracy for each sample. The "tcfmod_deρ_id_ref" attribute will reference the dependency which points to the TCF model that describes the abs_accy as a function of sample position within the TCF. If the accuracy varies and can be measured then a sensor will capture the absolute accuracy value. The sensor will be referenced by the "dependency__id_ref " attribute. If the measurement accuracy values vary as a position within the TCF then a TCF model will characterize the 2 sigma accuracy as a function of TCF position. The <dependency> element will contain the function modifier which identifies how the sensor value modifies either the tcfjnodel values or the <abs_accy> element value.

Data type:

Float

Attributes:

> "tcfmod_dep_id_ref" - (Optional) this attribute points (indirect pointer) to the dependency id which points to the TCF model of the absolute accuracy values for each of the corresponding TCF sample locations.

> "dependency_id_ref" - (Optional) this attribute (indirect pointer) points to the dependency id which points to the sensor measuring the absolute accuracy of the measurement and modifies either the <abs_accy> value or the values of the TCF model according to the <f cn_modif y> element.

4.6.4 ELEMENT rel_accy_intertcf Path: tml>data_desc>transducers>transducer>clust_desc>tcf>tcf_time>tcf_duration>rel _accy_intertcf

Description:

This element identifies the relative accuracy of the measurement when the two measurements reside in different TCFs. The difference between two measurements is better the closer together they are. As the distance (time or distance) between the two measurements increases the larger the relative error becomes. The relative accuracy accumulates at the rate indicated by the value of this element. The inter-TCF (between different TCFs) accuracy is in terms of how many TCFs will accumulate one unit of error. For example a 1E-6 indicates 1 unit, 2 sigma, of error in 1 E6 TCFs when measurements are taken between two corresponding samples from two different TCFs of the same transducer (i.e. error/TCF). The error between corresponding samples of different TCFs may be different than continually accumulating the intraTCF error rate between them.

Data type:

Float

Attributes:

> "tcfmod_dep_id_ref " - (optional) This attribute describes any variation in accuracy across the TCF y "dependency" - (optional) This attribute points to the dependency id that points to the transducer (sensor) the measures the changing accuracy.

4.6.5 ELEMENT tcf_j>eriod Path: tml>data_desc>transducers>transducer>clust_desc>tcf>trans_time>tcf_period

Description

If the transducer has a periodic sampling rate of the TCF (i.e. frame rate) then the value of this element represents the number of transducer <tcf_duration> ticks for one cycle of a TCF (TCF start - to - TCF start). If the frame rate is variable then a sensor may be used to measure the rate at which the TCF samples. The "dependency_id_ref " attribute points to the dependency id that points to the sensor which measures the period of the TCF frame rate. If the TCF sampling is a one shot sample or random sampling then this property shall be omitted.

Data type: Float Attribute List:

> "dependency__ID_ref" - (Optional) If the TCF time period is not constant then the period can be measured with a sensor. This attribute references a dependency id which references the sensor which measures the TCF time period. The <f cnjnodif y> elements contained in the <dependency> element describes how the sensor modifies the <tcf_period> value by either a multiply, add or replace operation.

Child Elements:

> (l) time elements, and

> (0 or 1) abs_accy elements, and

> (0 or l) rel accy intertcf elements

4.6.6 ELEMENT time

Path: tml>data_desc>transducers>transducer>clust_desc>tcf>trans_time>tcf_period>tim e

Description

This element contains the time value in seconds for the <tcf_duration> and the <tcf _period> elements. The accuracy of this time is characterized in the parent element.

Data type: Float

4.6.7 ELEMENT abs accy Path: tml>data_desc>transducers>transducer>clust_desc>tcf>tcf_time>tcf_period>abs_a ccy

Description: This valυe contains the 2 sigma value of the deviation of the absolute measurement accuracy based on NIST standards. If the abs_accy varies as a function of TCF sample position then a TCF model will enumerate the accuracy for each sample. The "tcfmod_dep_id_ref" attribute will reference the dependency which points to the TCF model that describes the abs_accy as a function of sample position within the TCF. If the accuracy varies and can be measured then a sensor will capture the absolute accuracy value. The sensor will be referenced by the "dependency_id_ref " attribute. If the measurement accuracy values vary as a position within the TCF then a TCF model will characterize the 2 sigma accuracy as a function of TCF position. The <dependency> element will contain the function modifier which identifies how the sensor value modifies either the tcfjmodel values or the <abs_accy> element value.

Data type:

Float

Attributes:

> "tcfmod_deρ_id_ref" - (Optional) this attribute points (indirect pointer) to the dependency id which points to the TCF model of the absolute accuracy values for each of the corresponding TCF sample locations.

> "dependency_id_ref" - (Optional) this attribute (indirect pointer) points to the dependency id which points to the sensor measuring the absolute accuracy of the measurement and modifies either the <abs_accy> value or the values of the TCF model according to the <f cnjnodif y> element.

4.6.8 ELEMENT rel_accy_intertcf Path: tml>data_desc>transducers>traπsducer>clust_desc>tcf>tcf_time>tcf_period>rel_a ccy_intertcf

Description:

This element identifies the relative accuracy of the measurement when the two measurements reside in different TCFs. The difference between two measurements is better the closer together they are. As the distance (time or distance) between the two measurements increases the larger the relative error becomes. The relative accuracy accumulates at the rate indicated by the value of this element. The inter-TCF (between different TCFs) accuracy is in terms of how many TCFs will accumulate one unit of error. For example a 1E-6 indicates 1 unit, 2 sigma, of error in 1E6 TCFs when measurements are taken between two corresponding samples from two different TCFs of the same transducer (i.e. error/TCF). The error between corresponding samples of different TCFs may be different than continually accumulating the intraTCF error rate between them. Data type:

Float

Attributes:

> "tcfmod_dep_id_ref " - (optional) This attribute describes any variation in accuracy across the TCF

> "dependency" - (optional) This attribute points to the dependency id that points to the transducer (sensor) the measures the changing accuracy.

4.6.9 ELEMENT ticks

Path: tml>data_desc>transducers>transducer>clust_desc>tcf>tcf__time>ticks tml>data_desc>transducers>transducer>clust_desc>tcf>tcf_coord>ticks

Description: -

This is the number of equal-time or equal-angular or equal-distance intervals which divide up the TCF time duration or coordinate range. The number of ticks are typically an order of magnitude greater than the number of samples such that any perturbations or non-linearties in time or coordinates can be characterized.

Data type: Integer

4.6.10 ELEMENT rel_accy Path: tml>data_desc>transducers>transducer>clust_desc>tcf>tcf_time>rel_accy

Description:

This value represents the relative accuracy of the frame period. This value shall be represented in the same fashion as the rel_accy of the sys_clk element. Knowing this is useful in determining the temporal accuracy of the start time of a TCF which is embedded within a large cluster.

Data type: Float Attributes:

"tcfmod_dep_id_ref" - (optional) This attribute is used to reference a model dependency id which points to a TCF model that describes the relative accuracy as a function of sample position within the TCF.

"dependency_ID_ref " - (Optional) This attribute is used if the relative accuracy of the parent element value varies with time and is measured by another sensor. The "dependency_id_ref" attribute is a reference to the dependency number which identifies the sensor that measures the <rel accy> value.

4.7 ELEMENT measure

Figure 46 • measure element

DTD:

<! ELEMENT measure (meas__desc, encoding, abs_accy?, rel_accy_intertcf?, rel_accy_intratcf?, freq_re^'sp?, ifom*, (io_xfer_fcn I oi_xfer_fcn) *, cal_ref* , meas_ref? ) > <! ATTLIST measure id ID #REQUIRED >

<! ELEMENT meas_desc (nomenclature, meas_type, sen_incidient_energy_source?, meas duration?, direction?) > <! ELEMENT encoding (bits_meas, signif_bits_meas?, datatype, units?, min?, max?, allow* ) >

< ! ELEMENT freq_resp (x_range, x_range_ctr) >

<! — Bandwidth and center freq in Hz respectively, power spectrial' density for emitters — >

< ! ATTLIST freqjresp fmod_dep_id_ref IDREF f IMPLIED >

< ! ELEMENT ifom (ρwr_profile, dist_mult, ifom_alpha, ifom_beta) > < ! ATTLIST ifom fmod_dep_id_ref IDREF #IMPLIED >

<! ELEMENT io_xfer_fcn (x_scale, x_min, (x_max I x_range) , gain?, bias?) > < ! ATTLlST io_xfer_fcn dir (fwd I rev | both) tREQUIRED fmod_deρ_id_ref IDREF # IMPLIED > >

< ! ELEMENT cal_ref (stim_val+, resp_val+) >

< ! — allowes to designate a variable cal response ref (i . e . sensor) which cam be used to adjust the gain on the sensor from which the cal sensor was pointed from the # PCDATA value allows a fixed calibrated response data, a referenced dependency_id_ref points to a sensor whch as realtime updates of illumination values . — > <! ELEMENT meas_ref (#PCDATA) > < ! — measurement datum e .g . phase reference — > < ! ATTLIST rαeas ref dependency_id_ref IDREF #IMPLIED >

4.7.1 ELEMENT meas_desc Path: tml>data_desc>transducers>transducer>sample>measure>meas_desc

Description:

This is a human readable text description of the measurement.

Data type:

UTF-8 (character)

Child Elements:

> (1 ) nomenclature element and

> (1) meas_tyρe element and

^ (0 or 1) sen_incident_energy_source element and

> (0 or 1) meas_duration element and

> (0 or 1) direction element 4.7.2 ELEMENT encoding

Path: tml>data_desc>transducers>transducer>sample>measure>encoding

Description:

This element contains the set of elements which describe the encoding of each measurement. The encoding element contains several child elements including: bits per measurement, significant bits per measurement, data type, units, minimum value, maximum value, and allowed values

Child Elements:

> (l) bitsjneas element and y (0 or 1) signif__bits_meas element and

> (1) datatype element and

> (0 or 1) units element and

> (0 or l)min element and

> (0 or 1) max element and

> (0 or more) allow elements

4.7.3 ELEMENT abs_accy Path: tml>data_desc>transducers>transducer>sample>measure>abs_accy

Description:

This value contains the 2 sigma value of the deviation of the absolute measurement accuracy based on NIST standards. If the abs_accy varies as a function of TCF sample position then a TCF model will enumerate the accuracy for each sample. The "tcfmod_dep_id_ref" attribute will reference the dependency which points to the TCF model that describes the abs_accy as a function of sample position within the TCF. If the accuracy varies and can be measured then a sensor will capture the absolute accuracy value. The sensor will be referenced by the "deρendency_id_ref " attribute. If the measurement accuracy values vary as a position within the TCF then a TCF model will characterize the 2 sigma accuracy as a function of TCF position. The <dependency> element will contain the function modifier which identifies how the sensor value modifies either the tcfjnodel values or the <abs_accy> element value. Data type:

Float

Attributes:

> "tcfmod_dep_id_ref" - (Optional) this attribute points (indirect pointer) to the dependency id which points to the TCF model of the absolute accuracy values for each of the corresponding TCF sample locations.

> "deρendency_id_ref" - (Optional) this attribute (indirect pointer) points to the dependency id which points to the sensor measuring the absolute accuracy of the measurement and modifies either the <abs__accy> value or the values of the TCF model according to the < fen modi f y> element.

4.7.4 ELEMENT rel_accy_intertσf Path: tml>data_desc>transducers>transducer>sample>measure>rel_accy_intertcf

Description:

This element identifies the relative accuracy of the measurement when the two measurements reside in different TCFs. The difference between two measurements is better the closer together they are. As the distance (time or distance) between the two measurements increases the larger the relative error becomes. The relative accuracy accumulates at the rate indicated by the value of this element. The inter-TCF (between different TCFs) accuracy is in terms of how many TCFs will accumulate one unit of error. For example a 1E-6 indicates 1 unit, 2 sigma, of error in 1E6 TCFs when measurements are taken between two corresponding samples from two different TCFs of the same transducer (i.e. error/TCF). The error between corresponding samples of different TCFs may be different than continually accumulating the intraTCF error rate between them.

Data type:

Float

Attributes:

> "tcfmod_dep_id_ref " - (optional) This attribute describes any variation in accuracy across the TCF

> "dependency" - (optional) This attribute points to the dependency id that points to the transducer (sensor) the measures the changing accuracy.

4.7.5 ELEMENT rel_accy_intratcf Path: tml>data_desc>transducers>transducer>sample>measure>accy>rel_accy_intratcf

Description:

This element identifies the relative accuracy of the measurement when the two measurements reside in the same TCF. The difference between two measurements is better the closer together they are. As the distance (time or distance) between the two measurements increases the larger the relative error becomes. The relative accuracy in this element accumulates at the rate indicated by the value of this element. The intra-TCF (within a TCF) accuracy is in terms of how many measurements will accumulate one unit of error. For example a 1E-9 indicates 1 unit, 2 sigma, of error in 1E9 measurements when measurements are taken between two samples from within a single TCF (i.e. error/measurement).

Data type:

Float

Attributes:

> "tcfmod_dep_id__ref " - (optional) This attribute describes any variation in accuracy across the TCF

> "dependency" - (optional) This attribute points to the dependency id that points to the transducer (sensor) the measures the changing accuracy.

4.7.6 ELEMENT f req_^resp Path: tral>data_desc>transducers>transducer>sample>measure>freq_resp

Description:

For receivers this element describes the range of stimulus frequencies to which the detector is sensitive. For a transmitter this element describes the power spectral density of the emitted energy. If for any reason a plot of this function is required a function model can be associated with this characteristic. The "fmod_dep_id_ref " points (indirect pointer) to the dependency id that points to the fjnodel that describes the frequency characteristics. The <x_range> and <x_range_ctr> elements characterize the bandwidth and center frequency respectively. Figure 47 shows the characteristics which describe the frequency response. Child elements to the frequency response element describe these characteristics. Normalized response

frequency

-x_range- x min x max

Figure 47 - Frequency Response Characterization Data type:

UTF-8 (character) Attributes:

> "frαod_dep_αd_ref " - (optional) This is a pointer (indirect pointer) to the dependency id which points to the fjmodel which describes the frequency characteristics.

Child Elements:

> (1) x_range element and

> (1) x_range_ctr element

4.7.7 ELEMENT if om Path: tml>data_desc>transducers>transducer>sample>measure>ifom

Description:

This element contains the elements required to characterize the instantaneous field of measurement (IFOM) for a remote transducer (remote receiver/sensor or remote transmitter/emitter). If a 3 dimensional IFOM is required then the "fmod_dep_id_ref" attribute points to the dependency id that points to the 3D fjnodel. Otherwise the IFOM can be characterized by slicing the 3 dimensional ifom shape in the vertical (beta) and horizontal (alpha) directions using the <ifom_alpha> and <ifom_beta> elements. Figure 48 shows the characteristics which describe the IFOM. Child elements to the IFOM element describe these characteristics.

Figure 48 - IFOM Characterization Data type:

Float Attributes:

> "fmod_dep_id_ref " - (Optional) to be able to incorporate 3D fjnodels to characterize ifom. If this attribute is used then child elements <if om_alpha> and <if om_beta> are not used.

Child Elements:

> (l)ρwr_profile, element and

> (1) distjnult element and

> (O or 1 ) i f om_a lpha element

> (0 or 1 ) i f om_beta element

4.7.8 ELEMENT io_xf er_f en Path: tral>data_desc>transducers>transducer>sample>measure>io_xfer_fcn

Description:

This element maps the input vs. output transfer function. Data is captured form the input to a transmitter or the output from a receiver. If a function model is required to describe this function then the "fmod_dep_id_ref ' ' attribute is used to point to the dependency id that points to the function model. The properties of the transfer functions are show in the following diagram. The range (independent variable) is plotted on the x axis and the dependent variable (ordinate) is plotted on the y axis. The abscissa (y) values are contained in the <datapoints> element of the model. The <x_range> is divided up into n equal spaced points with the first at <x_min> and the last at <x_max> . The number of points n is given in the count attribute of the <datapoints> element of the transfer function model. The scale element describes how the ordinate (x) values for the data points are calculated. The gain and bias values will shift or expand these plots in the vertical direction respectively. Figure 49 shows the characteristics which describe the input-output transfer function. Child elements to the input-output transfer function element describe these characteristics.

Output Input (response) (stimulus)

-> Output

-x_range - (response)

x_min x_max (sensitivity) (saturation)

Figure 49 - Input-Output Transfer function Characterization

Data type:

UTF-8 (character) Attributes:

^ "dir" - (Required) This attribute describes what direction the IO transfer function applies to. This is to characterize the "lag" in the transfer function do to a hysteresis effect. The direction can either be forward, reverse, or both. If the direction is forward the direct of change is from xjmin to x_max. If no hystersis effects observed then both means that the transfer function is the same in both directions.

> "fmod_dep_αd_ref " - (Optional) This attribute points to the dependency id that points to the function model which characterizes the io transfer function.

Child Elements' (Note: refer to DTD for more detailed description of cardinality relationships)

> (1) x_scale element and

> (l) x min element and

> (l)(x_max element or > (1) x_range element

4.7.9 ELEMENT cal_ref

Path: tml>data_desc>transducers>transducer>sample>measure>cal_ref

Description:

This is the calibration reference for the measurement samples. Stimulus and response values are given in the stim_val and resp_val elements.

Data type: UTF-8 (character) Child Elements:

^ ( 1 or more) s t im_va 1 elements > (1 ormore) resp_val elements

4.7.10 ELEMENT meas_ref

Path: tml>data_desc>transducers>transducer>sample>measure>meas_ref

Description:

The element give the measurement reference if the measurement is referenced to another measurement, signal or surface. For example a phase measurement is the phase angle of a signal relative to another signal. Or the position of an aircraft in alpha, beta, r coordinates in the ECEF reference system r (range or radius) may be relative to the WGS-84 ellipsoid surface. The reference is provided in the value of this element unless the reference is a transducer. If the reference is provided by a transducer then the "dependency_id_ref" points to the dependency id that points to the transducer which provides the reference.

Data type: UTF-8 (character) Allowed values: > EMPTY

> WGS-84 ellipsoid

Attributes:

> "deρendency_id_ref" - (Optional) If the element value is EMPTY then this attribute points to the dependency id that points to the transducer that provides the reference for the measurement.

4.8 ELEMENT meas desc

Figure SO - meas desc element

DTD:

< ! ELEMENT meas_desc {nomenclature, meas_tyρe, sen_incidient_energy_source?, meas_duration?, direction?) >

< ! ELEMENT meas_type (#PCDATA) >

< ! — remote I insitu | emitter | actuator — >

< ! ELEMENT sen_incidient_energy_source (#PCDATA) >

< ! — natural ambient l artifical transmitter — >

< ! — if artifical then identify dependency — >

< !ATTLIST sen_incidient_energy_source dependency_id_ref IDREF #IMPLIED >

< ! ELEMENT meas_duration (time, abs_accy?, rel_accy_intertcf?) > < ! — e . g. shuttuer speed — > < ! ATTLIST meas_duration tcfmod_dep_id_ref IDREF IIMPLIED dependency_id_ref IDREF #IMPLIED >

< ! ELEMENT direction (#PCDATA) >

< ! — used for measurements such as polarization, acceleration, velocity, force, S torque — > <! —enumeration for direction: (x I y I z I +x | -x | +y | -y | +z | -z I alpha I beta | r | +alpha | -alpha | +beta | -beta | +r | -r | omega | phi kappa | +omega I -omega | +phi | -phi | +kappa | -kappa) (+ direction is always away from the orign or clockwize rotation looking at the origin) —> <!ATTLIST direction tcfmod_dep_id_ref IDREF #IMPLIED dependency_id_ref IDREF #IMPLIED >

4.8.1 ELEMENTnomenclature Path: tml>data_desOtransducers>transducer>sample>measure>meas_desc>nomenclature

Description:

The nomenclature is a short name given to the measurement. Example: "gain factor".

Data type:

UTF-8 (character)

4.8.2 ELEMENT meas_type Path: tml>data_desc>transducers>transducer>saπiple>ineasure>meas_desc>meas_type

Description:

The value for this property identifies the type of transducer. This value tells the processor whether the measurement is of the response or the stimulus for the transducer. This in turn signifies the direction in which the information is moving. If the transducer is a remote type then we would expect characterization of the IFOM and one or more coordinate TCFs. If the transducer is a receiver then we would expect a <sen_incident_energy_source> element.

Data type: UTF-8 (character) Allowable values:

> "in situ transmitter", > "remote transmitter", y "in situ receiver", and

> "remote receiver".

4.8.3 ELEMENT sen incident energy source Path: tml>data_desc>transducers>transducer>sample>measure>π\eas_desc>sen_incident_en ergy_source

Description:

If the <meas__type> is a receiver and the measurement is a value which is influenced by an artificial transmitter, then this element identifies the source of the incident energy. If measurement is not influenced by an external transmitter then this element is not required. The allowable values for this element are natural ambient or artificial transmitter. If the incident energy is provided by artificial means then the "dependency_id_ref " attribute points to the dependency that points to the remote transmitter which provides the incident energy. An active sensor such as synthetic aperture radar provides its own illumination. In this case the value of this property would be artificial transmitter, with the "dependency_id_ref " attribute pointing to the dependency that points to the transmitter which provides the illumination. There may be situations where a remote sensor measures emissive energy of the object space. In this case no reflected measurement is taken so no illuminations need to be given. In situ sensors may or may not have an incident energy which is required to be known. For example it may be useful to know the signal sent to a positioning motor (emitter) which provides the stimulus or incident energy for a positional sensor.

Data type: UTF-8 (character) Attributes:

> "dependency__id_ref " - (optional) This attribute points to a dependency id which points to the transducer (transmitter) which is providing the illumination or stimulus energy.

4.8.4 ELEMENT rαeas_duration

Path: tml>data_desc>transducers>transducer>sample>raeasure>meas_desc>meas_duration

Description: This element describes the time duration in seconds of the measurement. For a camera this time would relate to shutter speed. If the time duration is not constant, then the time duration can be measured by a sensor. The "dependency__id_ref " attribute points to the dependency that points to the sensor which measures the <meas_duration>. There may be situations when the measure duration is not consistent over the TCF. If this is the case then a measure duration TCP referenced by "tcfmod_dep_id_ref " attribute will define the individual durations of each of the measurements in the TCF. Likewise, measure duration may change over time as will as over the TCF. In this case the "tcfmod_dep_id_ref " attribute points to the dependency that points to the TCF model which describes the duration, and the "dependency_id_ref " attribute points to the dependency that points to the sensor which modifies the TCF values or the constant value of the <meas_duration>, The <meas_duration> contains two child elements: <time>, <abs_accy>, and <rel_accy__intertcf > . The time in seconds is in the <time> element and the accuracy (absolute & relative) are in the <abs_accy> and <rel_accy__intertcf > elements respectively.

Data type:

Float

Attributes:

> ^Xλtcf mod_dep__id_ref " - (Optional) This attribute points to the dependency id that points to the TCF model which describes the measurement duration over the TCF

> "dependency_id_ref " - (Optional) This attribute points (indirect pointer) to the dependency id that points to the sensor. The dependency element contains a function modifier which describes how the sensor value modifies (add, multiply, or replace) the TCF values or <meas_duration> value.

Child elements:

> (1) time element

> (0 or l) abs_accy element

> (0 or 1) rel accy intertcf element

4.8.5 ELEMENT time Path: tml>data_desc>transducers>transducer>sample>iπeasure>ineas_desc>meas_duration>t ime

Description: This element contains the time value in seconds for the <tcf_duration> and the <tcf_period> elements. The accuracy of this time is characterized in the parent element.

Data type: Float

4.8.6 ELEMENT abs accy

Path: tral>data_desc>transducers>transducer>samρle>measure>meas_desc>meas_duration>a bs_accy

Description:

This value contains the 2 sigma value of the deviation of the absolute measurement accuracy based on NIST standards. If the abs_accy varies as a function of TCF sample position then a TCF model will enumerate the accuracy for each sample. The "tcfmod_dep_id_ref " attribute will reference the dependency which points to the TCF model that describes the abs accy as a function of sample position within the TCF. If the accuracy varies and can be measured then a sensor will capture the absolute accuracy value. The sensor will be referenced by the "dependency_id_ref " attribute. If the measurement accuracy values vary as a position within the TCF then a TCF model will characterize the 2 sigma accuracy as a function of TCF position. The <dependency> element will contain the function modifier which identifies how the sensor value modifies either the tcf_model values or the <abs_accy> element value.

Data type:

Float

Attributes:

> "tcfmod_dep_id_ref" - (Optional) this attribute points (indirect pointer) to the dependency id which points to the TCF model of the absolute accuracy values for each of the corresponding TCF sample locations.

> "dependency_id_ref " - (Optional) this attribute (indirect pointer) points to the dependency id which points to the sensor measuring the absolute accuracy of the measurement and modifies either the <abs_accy> value or the values of the TCF model according to the < f cnjαodi f y > element.

4.8.7 ELEMENT rel_accy_intertcf Path: tml>data_desc>transducers>transducer>sample>measure>meas_desc>meas_duration>r el_accy_intertcf

Description:

This element identifies the relative accuracy of the measurement when the two measurements reside in different TCFs. The difference between two measurements is better the closer together they are. As the distance (time or distance) between the two measurements increases the larger the relative error becomes. The relative accuracy accumulates at the rate indicated by the value of this element. The inter-TCF (between different TCFs) accuracy is in terms of how many TCFs will accumulate one unit of error. For example a 1E-6 indicates 1 unit, 2 sigma, of error in 1E6 TCFs when measurements are taken between two corresponding samples from two different TCFs of the same transducer (i.e. error/TCF). The error between corresponding samples of different TCFs may be different than continually accumulating the intraTCF error rate between them.

Data type:

Float

Attributes: y "tcfmod_dep_id_ref " - (optional) This attribute describes any variation in accuracy across the TCF > "dependency" - (optional) This attribute points to the dependency id that points to the transducer (sensor) the measures the changing accuracy.

4.8.8 ELEMENT direction Path: tml>data_desc>transducers>transducer>sample>measure>meas_desc>direction

Description:

This element gives the direction of the measurement relative to the transducer reference system. This direction is relative to the transducer reference system. Measurement such as forces, velocities, and EM polarizations have directions associated with them. If the measurement requires a direction this element is used. The transducer reference system can be aligned such that the direction occurs on one on the cardinal axis. The + rotation direction is always a clockwise rotation when looking at the origin of the reference system.

Data type: UTF-8 (character) Allowable values: x, y, z, +x, +y, +z, -x, -y, -z, alpha, beta, range, +alpha, +beta, +range, -alpha, -beta, -range, omega, phi, kappa, +omega, +ρhi, +kappa, -omega, -phi, -kappa

Attributes:

> "tcfmod_dep_id_ref" - (optional) This attribute references (indirect pointer) the dependency id that points to the TCF model that describes the direction of each measurement within the TCF. This is the indirect pointer to the TCF model.

> "dependency_id__ref" - (optional) This attribute points (indirect pointer) to the dependency id that points to the sensor that measures the changing measurement direction. The sensor measurement will replace any value in the direction value or the TCF model.

4.9 ELEMENT encoding

Figure 51 - encoding element

DTP:

< ! ELEMENT encoding (bits_meas, signif_bits_meas?, datatype, units?, min?, max?, allow* ) >

< ! ELEMENT bits_meas (#PCDATA) >

< ! ELEMENT signif_bits_meas (#PCDATA) >

< ! ELEMENT datatype (#PCDATA) >

< ! — integer ) 2_comp | real | complex ] logical | binary | UTF-8 | BCD . . . — >

< !ELEMENT units (#PCDATA) >

< ! — candelas | Watts | degrees Kelvin | Kg | m sec I radians | Volts I

->

< ! ELEMENT min {# PCDATA) > <!ELEMENT max (#PCDATA)> <! ELEMENT allow (#PCDATA)>

4.9.1 ELEMENT bit s_jneas Path: tml>data_desc>transducers>transducer>saraple>measure>encoding>bits_meas

Description:

This element contains the number of bits of the particular measurement. If the bit/meas is anything other than a multiple of eight then the stream will be read in groups of eight and parsed afterwards. The following example explains the process. Each sample consists of one or more measurements. If the sensor provides a monochromatic image, then each sample is one measurement of a gray scale. If the image is color, then each sample is three measurements for red, green and blue. Multi-spectral analysis can actually create thousands of measurements for each sample. The previous fragment defines a sample of three measurements encoded as binary integer. (The example above does not include some mandatory elements so we can focus on the particulars.) The first measurement is 6 bits, the second is 8 bits, and the third is 6 bits. The total sample is 20 bits, which can be expressed with 5 hexadecimal characters.

Figure 52 - Encoding of the Binary Data Stream

Using the sample encoding, the hex string "55AC 1" would represent a first measurement value of 21, a second measurement value of 107 and a third measurement value of 17.

Data type: Integer

4.9.2 ELEMENT signif_bits_meas

Path: tml>data desc>transducers>transducer>sample>measure>encoding>signif bits meas Description:

This element contains the number of significant bits per measurement.

Data type:

Integer

4.9.3 ELEMENT datatype Path: tml>data_desc>transducers>transducer>sample>measure>encoding>data_type

Description:

This element contains the data type of the measurement.

Allowed Values:

> integer,

> signed integer (2's comp),

> BCD, binary, Float (BEE),

> complex (EEE), logical,

> UTF-8 (character) '

Note: This data type will supersede the data type description in the XML Schema for the cluster data.

4.9.4 ELEMENT units Path: tml>data_desc>transducers>transducer>sample>measure>encoding>units

Description:

This element contains the units of the measurement. The units also give the indication of the parameter being measured such as temperature, heat, velocity, light intensity, etc.

Data type: UTF-8 (character) Allowed Values:

> candelas,

> Watts,

> Volts,

> Amperes,

> Deg Kelvin,

> Kg,

> m,

> sec,

> radians,

(Note: Not an inclusive list)

4.9.5 ELEMENT min Path: tml>data_desc>transducers>transducer>sample>measure>encoding>min

Description:

This element contains the minimum value that can be expected for the measurement.

Data type:

Float

4.9.6 ELEMENT max

Path: tml>data_desc>transducers>transducer>sample>measure>encoding>max

Description:

This element contains the maximum value that can be expected for the measurement.

Data type:

Float 4.9.7 ELEMENT allow

Path: tml>data_desc>transducers>transducer>sample>measure>encoding>allow

Description:

This element contains the allowed values that can be used for the measurement. If more than one allowed value exist then multiple <allow> element may be used. If a range of values are allowed then <min> and <max> element should be used. The <allow> element may be used in conjunction with the <min> and <max> elements.

Data type: UTF-8 (character)

4.10 ELEMENT freq_resp

Frequency Response

<! ELEMENT freq_resp (x_range, x_range_ctr)>

Figure S3 - freq_resp element <! —Bandwidth and center freq in Hz respectively/ power spectrial density for emitters—>

<!ATTLIST freq_resp fmod_dep_id_ref IDREF #IMPLIED

>

<!ELEMENT x_range (#PCDATA)>

<!ATTLIST x_range tcfmod_dep_id_ref IDREF fIMPLIED dependency_id_ref IDREF fIMPLIED

>

<! ELEMENT x_range_ctr (#PCDATA)>

<!ATTLIST x_range_ctr tcfmod_dep_id_ref IDREF fIMPLIED dependency_id_ref IDREF fIMPLIED

>

4.10.1 ELEMENT x_range Path: tml>data_desc>transducers>transducer>sample>measure>freq_resp>x_range

Description:

Used primarily for defining the x axis attributes of fjnodels. <x_range> is the distance between <x_min> and <x_max> centered on <x_center>. For freq_resp and power spectral density (PSD) characteristics this element describes the bandwidth of the frequency response or PSD between 3dB power points. For the characterization of the IO transfer function the x_range value describes the range on the x axis of the independent variable. For the receiver it would be the stimulus

Normalized response

frequency

- x_range - x min x max

Figure 54 - Frequency Response Characterization Data type:

Float Attributes:

> "tcfmod_dep_id_ref" - (Optional) If the range in x varies with position within the TCF then this attribute points (indirect pointer) to the dependency id that points to the TCF model that characterizes the range for each sample in the TCF. If the "dependency_id_ref " attribute is present then the sensor value will modify the TCFs values depending on the value of the <f cnjnodif y> element which can be: add, multiply or replace.

> "dependency_ID_ref " - (Optional) If the range in x (e.g. bandwidth) is variable, then it can be measured with a sensor. This attribute points (indirect pointer) to a dependency id which points to the sensor which measures the range in x value. This sensor will modify either the TCF model values (the TCF referenced by the "mod_dep_id_ref " attribute in this element) or the element value according to the <fcn_modify> element value in the <dependency> element. The sensor can either multiply, add, or replace the constant values. 4.10.2 ELEMENT x_range_ctr Path: tml>data_desc>transducers>transducer>sample>measure>freq_resp>x_range_ctr

Description;

This element describes the center (i.e. center frequency) of the range (i.e. bandwidth). The center of the range can be positioned in the spectrum by the range center value. If this value is variable then it can be measured with a sensor. The "dependency_id_ref" attribute points to the dependency id that points to the sensor that measures the center. If the center varies as a function of sample position within the TCF, then a TCF model will be referenced using the "tcfmod_dep_id_ref " attribute to describe the values over the TCF.

Attributes:

> "tcfmod_dep_id_ref" - (Optional) If the range center varies with position within the TCF then this attribute points (indirect pointer) to the dependency id that points to the TCF model that characterizes the range center for each sample in the TCF. If the "dependency_id_ref " attribute is present then a sensor value will modify the TCFs values depending on the value of the <f cn_modif y> element which can be: add, multiply or replace.

> "dependency^ D_r ef " - (Optional) If the range center (i.e. center frequency) is variable, then it can be measured with a sensor. This attribute points (indirect pointer) to a dependency id which points to the sensor which measures the range center value. This sensor will modify either the TCF model values (the TCF referenced by the "tcf raod_dep_id_ref " attribute in this element) or the element value according to the <f cn_modif y> element value in the <dependency> element. The sensor can either multiply, add, or replace the constant values.

4.11 ELEMENT if om

Figure 55 - ifom element DTD;

<! ELEMENT ifom (pwrjprofile, distjnult, ifom_alpha, ifom_beta) > < ! ATTLIST ifom fmod_dep_id_ref IDREF ttIMPLIED >

< ! ELEMENT pwr_profile (#PCDATA) > < ! ELEMENT dist_jnult (#PCDATA) > < ! — gain (note : different from antenna gain) — > <! ATTLIST distjnult tcfmod_dep_id_ref IDREF #IMPLIED dependency_id_ref IDREF #IMPLIED >

< ! ELEMENT if omjalpha (alpha_range, abs_accy?) > < ! — if ov range in radians, ifoe for emitters — > < ! ATTLIST if omjalpha fmdd_dep_id_ref IDREF # IMPLIED >

< ! ELEMENT alphajrange (#PCDATA) >

< !^' — angular range for ifov model , number of ifov model data points spread evenly across this range identified in the fjnodel datapoints attribute — > < !ATTLIST alphajrange tcfmodjdep_id_ref IDREF # IMPLIED dependency_id_ref IDREF #IMPLIED >

< ! ELEMENT ifom_beta (betajrange, abs_accy?) > < ! — ifov range in radians, ifoe for emitters — > < !ATTLIST ifom_beta fmod_dep_id_ref IDREF IIMPLIED >

< ! ELEMENT betajrange <#PCDATA) > < ! — angular range — > < ! ATTLIST betajrange tcfmod_dep_id_ref IDREF # IMPLIED dependencyjldjref IDREF #IMPLIED >

4.11.1 ELEMENT pwrjprofile Path: tml>data_desc>transducers>transducer>sample>measure>ifom>pwr_profile

Description:

This attribute describes what level of power the ifom plots, For example the 3dB IFOM can be characterized by plotting the normalized locus of points in which the power level is 3dB below the level at the receiver or transmitter. Other power levels may be plotted as well. The same normalized IFOM plot may be used by more than one power profile if the shapes are similar. Data type: Integer

Allowed values: Any signed integer

4.11.2 ELEMENT distjnult Path: tml>data_desc>transducers>transducer>sample>measure>ifom_alpha>dist_mult

Description:

The IFOM plot is a normalized plot, a factor (<dist_mult>) must be multiplied by the normalized IFOM values to accurately represent the scale in meters relative to the transducer reference system.

Data type:

Float

Allowed values:

Any positive real number

Attributes:

> "tcfmod_dep_id_ref " - (Optional) IDREF

> "dependency ID_ref" - (Optional) DREF

4.11.3 ELEMENT if om_alpha Path: tml>data_desc>transducers>transducer>sample>measure>ifom>ifoiri_alpha

Description:

This element contains the element to characterize the IFOM in the alpha (spherical coordinates) plane (i.e. beta = 0). If required the "fmod_dep_id_ref " attribute points to the dependency id that points to the function model that characterizes the alpha ifom. Attributes:

> " fmod_dep_id_ref " - (Optional) this attribute points to the dependency that points to the function model that profiles the ifom.

Child Elements:

> (1) a lpha_range element

> (0 or 1) abs_accy element

4.11.4 ELEMENT alphajrange

Path: tml>data_desc>transducers>transducer>samρle>measure>ifon»ifom_alpha>alpha_ran ge

Description:

This element contains the range (angular extent) in radians of the IFOM in the alpha direction. This range is divided into a number of samples. The number of samples is given in the "count" attribute of the <datapoints> element within the <model element>. If the IFOM varies as a function of sample position within the TCF then the "tcfmod_dep_id_ref " attribute will point to the dependency id that points to the TCF model which enumerates the individual range for each sample in the TCF. If the <alpha range> is variable then it can be measured by a sensor. The "dependency_id_ref " attribute points to the dependency id that points to the sensor which measures the alpha range.

Data type:

Float

Attributes:

> "tcf mod_dep_id_ref " - (Optional) This attribute points to the dependency id that points the TCF model that describes how the alpha range varies with position within the TCF.

> "deρendency_id_ref " - (Optional) This attribute points to the dependency that points to the sensor which captures the changing alpha range value, and modifies the <alpha range> element and/or TCF values according to the <f en modi f y> element.

4.11.5 ELEMENT abs_accy Path: tml>data_desc>transducers>transducer>saraple>measure>ifom>ifom_alpha>abs_accy

Description:

This value contains the 2 sigma value of the deviation of the absolute measurement accuracy based on NIST standards. If the abs_accy varies as a function of TCF sample position then a TCF model will enumerate the accuracy for each sample. The "tcfmod_dep_id_ref" attribute will reference the dependency which points to the TCF model that describes the abs accy as a function of sample position within the TCF. If the accuracy varies and can be measured then a sensor will capture the absolute accuracy value. The sensor will be referenced by the ^Mdependency_id_ref " attribute. If the measurement accuracy values vary as a position within the TCF then a TCF model will characterize the 2 sigma accuracy as a function of TCF position. The <dependency> element will contain the function modifier which identifies how the sensor value modifies either the tcfjnodel values or the <abs_accy> element value.

Data type:

Float

Attributes:

> "tcfmod_dep_id_ref" - (Optional) this attribute points (indirect pointer) to the dependency id which points to the TCF model of the absolute accuracy values for each of the corresponding TCF sample locations.

> "dependency_id_ref" - (Optional) this attribute (indirect pointer) points to the dependency id which points to the sensor measuring the absolute accuracy of the measurement and modifies either the <abs_accy> value or the values of the TCF model according to the <f cn_modif y> element.

4.11.6 ELEMENT ifom beta Path: tml>data_desc>transducers>transducer>sample>measure>ifom>ifom_beta

Description:

This element contains the element to characterize the IFOM in the beta (spherical coordinates) plane (i.e. alpha = 0). If required, the "fmod_dep__id_ref" attribute points to the dependency id that points to the function model that characterizes the alpha ifom.

Attributes: > "fmod_dep_id_ref " - (Optional) This attribute points to the dependency that points to the function model that profiles the IFOM.

Child Elements:

> (1) beta_range element

> (0 or 1) abs_accy element

4.11.7 ELEMENT beta_jcange

Path: tml>data_desc>transducers>transducer>saπiple>ineasure>ifoin>ifoin_beta>beta_range

Description:

This element contains the range (angular extent) in radians of the ifom in the beta direction. This range is divided up into a number of samples. The number of samples is given in the "count" attribute of the <datapoints> element within the <model elements If the IFOM varies as a function of sample position within the TCF then the "tcfmod_dep_id_ref" attribute will point to the dependency id that points to the TCF model which enumerates the individual range for each sample in the TCF. If the <beta range> is variable then it can be measured by a sensor. The "dependency_id_ref " attribute points to the dependency id that points to the sensor which measures the alpha range.

Data type:

Float

Attributes:

> "tcf mod_dep_id_ref " - (Optional) This attribute points to the dependency id that points the TCF model that describes how the beta range varies with position within the TCF.

> "dependency_id_re f " - (Optional) This attribute points to the dependency that points to the sensor which captures the changing beta range value, and modifies the <beta_range> element and/or TCF values according to the <£ cnjnodif y> element.

4.11.8 ELEMENT abs accy

Path: tml>data_desc>transducers>transducer>sample>measure>ifom>ifom_beta>abs_accy Description:

This value contains the 2 sigma value of the deviation of the absolute measurement accuracy based on NIST standards. If the abs_accy varies as a function of TCF sample position then a TCF model will enumerate the accuracy for each sample. The "tcfmod_dep_id_ref " attribute will reference the dependency which points to the TCF model that describes the abs_accy as a function of sample position within the TCF. If the accuracy varies and can be measured then a sensor will capture the absolute accuracy value. The sensor will be referenced by the "dependency_id_ref " attribute. If the measurement accuracy values vary as a position within the TCF then a TCF model will characterize the 2 sigma accuracy as a function of TCF position. The <dependency> element will contain the function modifier which identifies how the sensor value modifies either the tcfjriodel values or the <abs_accy> element value.

Data type:

Float

Attributes:

> "tcfmod_dep_id_ref " - (Optional) this attribute points (indirect pointer) to the dependency id which points to the TCF model of the absolute accuracy values for each of the corresponding TCF sample locations.

> "dependency_id_ref" - (Optional) this attribute (indirect pointer) points to the dependency id which points to the sensor measuring the absolute accuracy of the measurement and modifies either the <abs__accy> value or the values of the TCF model according to the <f cnjnodif y> element.

4.12 ELEMENT io xfer fen

Figure 56 iojcfer fcn element

DTD: <! ELEMENT io_xfer_fcn (x_scale, x_min, (x_max | x_range) , gain?, bias?) > <! ATTLIST io_xfer_fcn dir (fwd I rev | both) # REQUIRED fmod_dep_id_ref IDREF IIMPLIED >

< ! ELEMENT x_scale ( #PCDATA) > < ! — x_scale units same as measurement units — > <! — log I linear — > <! ELEMENT x_min (#PCDATA) > < !ATTLIST xjnin tcfmod_dep_id_ref IDREF #IMPLIED dependency_id_ref IDREF tIMPLIED >

< ! ELEMENT x_max (#PCDATA) > < !ATTLIST xjnax tcfmod_dep_id_ref IDREF ^IMPLIED

'dependency_id_ref IDREF tIMPLIED >

<! ELEMENT gain (#PCDATA) > <! ATTLIST gain tcfmod_dep_id_ref IDREF HMPLIED dependency_id_ref IDREF iIMPLIED >

<! ELEMENT bias ( I PCDATA) > <!ATTLIST bias tcfmod_dep_id_ref IDREF tIMPLIED dependency_id_ref IDREF #IMPLIED >

4.12.1 ELEMENT x scale Path: tml>data_desc>transducers>transducer>sample>measure>io_xfer_fcn>x_scale

Description: x-scale describes the distribution of the abscissa (x) values for the ordinate (y) datapoints in the function models. The value of the x_scale element can either be linear or log. If the scale is linear then the equidistant spacing of the independent variable is calculated from i=(x_max- x_min)/(count-l), the -1 because the number of samples includes one at the start (i.e. zero). If the scale of the independent variable is logarithmic then the series of variables is calculated

Iog(jf _ max)— log(jr _min) using, kf=10'⁽ «Λ»»»-I _} where i = 1 to column. There are no units on the x axis. The x axis in the captured measurement value. The y axis has the same units as the measurement, however it may be normalized.

Data type: UTF-8 (character) 4.12.2 ELEMENT xjnin

Path: tml>data_desc>transducers>transducer>sample>measure>io_xfer_fcn>x_min

Description:

This element describe the minimum value to be recorded for the measurement. If this value is not constant then a sensor may be assigned to capture the <x_min> value. The "dependency_id_ref " attribute points to the dependency id that points to the sensor that tracks the <χ_min> value. If the <x_min> value is not uniform over the TCF then the "tcfmod_dep_id_ref " attribute shall point to the dependency that points to the TCF model that characterizes the variations of <x_min> over the TCF.

Data type: Float

Allowed values: Any real number Attributes:

> "tcfmod_dep_id_ref " - (Optional) This attribute points to the dependency id that points to the TCF model that describes the variations in the <x_min> value over the TCF.

> ^XΛdependency__id_ref " - (Optional) This attribute points to the dependency id that points to the sensor that tracks the <x_min> value. The sensor value will modify either the single <x_min> value or the set of TCF values by the operation specified in the <fcn_modif y> element in the referenced dependency.

4.12.3 ELEMENT xjnax Path: tml>data_desc>transducers>transducer>saitiple>measure>io_xfer_fcn>x_max

Description:

This element describe the maximum value to be recorded for the measurement. If this value is not constant then a sensor may be assigned to capture the <x_maχ> value. The "dependency_id_ref " attribute points to the dependency id that points to the sensor that tracks the <x_max> value. If the <x_max> value is not uniform over the TCF then the "tcf mod_dep_id_ref " attribute shall point to the dependency that points to the TCF model that characterizes the variations of <x_max> over the TCF.

Data type: Float

Allowed values: Any real number Attributes:

> "tcfmod_dep_id_ref " - (Optional) This attribute points to the dependency id that points to the TCF model that describes the variations in the <x_max> value over the TCF.

> "dependency_id_re f " - (Optional) This attribute points to the dependency id that points to the sensor that tracks the <x_max> value. The sensor value will modify either the single <x_max> value or the set of TCF values by the operation specified in the <f cnjmodif y> element in the referenced dependency.

4.12.4 ELEMENT x range Path: tml>data_desc>transducers>transducer>sample>measure>io_xfer_fcn>x_range

Description:

Used primarily for defining the x axis attributes of fjnodels. <x_range> is the distance between <x_min> and <x_max> centered on <x_center>. For freq_resp and power spectral density (PSD) characteristics this element describes the bandwidth of the frequency response or PSD between 3dB power points. For the characterization of the 10 transfer function the x_range value describes the range on the x axis of the independent variable. For the receiver it would be the stimulus

Normalized response

frequency

x mm x max

Figure 57 - Frequency Response Characterization Data type:

Float Attributes:

> "tcfmodjiep_id_ref " - (Optional) If th&jangejn x varies with position within

or replace.

> "dependency_ID_ref " - (Optional) If the range in x (e.g. bandwidth) is variable, then it can be measured with a sensor. This attribute points (indirect pointer) to a dependency id which points to the sensor which measures the range in x value. This sensor will modify either the TCF model values (the TCF referenced by the "mod_dep__id_ref " attribute in this element) or the element value according to the <fcn_raodify> element value in the <dependency> element. The sensor can either multiply, add, or replace the constant values.

4.12.5 ELEMENT gain

Path: tml>data_desc>transducers>transducer>sample>measure>oi_xfer_fcn>gain

Description:

This element describes the gain (multiplicative) applied to the captured measurement values and also modifies the IO transfer function by expanding it vertically. If the gain is not even over the TCF then a gain TCF can be used which equalizes the response over the TCF such that the IO transfer fen is the same for each sample in the TCF. This can be thought of as radiometrically balancing the responses of the frame. The TCF gain values will multiply the single gain value to derive the gain value for each sample in the TCF. The "tcfmod_dep_id_ref " attribute points to the dependency id that points to the gain TCF. If the gain is constantly being adjusted then it may be tracked with a gain sensor. The "dependency_id_ref" attribute points to the dependency id that points to the sensor that tracks the gain. The value from the sensor modifies the single gain value and or the gain TCF according to the <f cnjmodif y> element value in the <dependency> element for the gain sensor.

Data type: Float

Allowed values: Any real number Attributes:

^ "tcfmod_dep_id_ref " - (Optional) This attribute points to the dependency id that points to the TCF model that enumerates the various gain settings for each of the samples in the TCF.

> "dependency_I D_ref " - (Optional) This attribute points to the dependency id that points to the sensor that tracks the gain factor applies to the measurement data. The sensor value will modify the single gain value or the gain TCF according to the <fcn_modify> element (replace | add | multiply) in the <dependency> element for the gain sensor.

4.12.6 ELEMENT bias

Path: tml>data_desc>transducers>transducer>sample>measure>oi_xfer_fcn>bias

Description:

This element describes the bias (additive) applied to the captured measurement values and also modifies the io transfer function by sliding it vertically up and down. If the bias is not even over the TCF then a bias TCF can be used which equalizes the response over the TCF such that the 10 transfer fen is the same for each sample in the TCF. This can be thought of as radiometricly balancing the responses of the frame. The TCF bias values will add to the single bias value to derive the gain value for each sample in the TCF. The "tcfmod_dep_id_ref " attribute points to the dependency id that points to the bias TCF. If the bias is constantly being adjusted then it may be tracked with a bias sensor. The "dependency_id_ref " attribute points to the dependency id that points to the sensor that tracks the bias. The value from the sensor modifies the single bias value and or the bias TCF according to the <f cnjnodif y> element value in the <dependency> element for the bias sensor. Data type: Float

Allowed values: Any real number Attributes:

"tcfmod_dep__id_ref " - (Optional) This attribute points to the dependency id that points to the TCF model that enumerates the various bias settings for each of the samples in the TCF. "dependency_ID_ref " - (Optional) This attribute points to the dependency id that points to the sensor that tracks the bias value applied to the measurement data. The sensor value will modify the single bias value or the bias TCF according to the <fcn_modify> element (replace | add | multiply) in the <dependency> element for the bias sensor.

4.13 ELEMENT cal ref

Figure 58 - cal ref element DTP:

<!ELEMENT cal_ref (stim_val+, resρ_val+)>

<! —allowes to designate a variable cal response ref (i.e. sensor) which cam be used to adjust the gain on the sensor from which the cal sensor was pointed from the #PCDATA value allows a fixed calibrated response data, a referenced dependency_id_ref points to a sensor when as realtime updates of illumination values. —>

<!ELEMENT stim_val (#PCDATA)>

< !ATTLIST stim_val dependency_id_ref IDREF #IMPLIED >

<!ELEMENT resp_val EMPTY> < !ATTLIST resp_val dependency_id_ref IDREF #IMPLIED > ~

4.13.1 ELEMENT stim_val Path: tml>data_desc>transducers>transducer>sample>measure>cal_ref>stim_val

Description:

Sometimes it is necessary to incorporate a known reference source into a transducer system to adjust the gain and bias after during processing for a calibrated response. With a known source (stimulus) given by the value of the <stim_val> element the response should be a certain value determined by <resp_val> or by the IO transfer functions. If the value is not what it should be then adjustments can be made during the processing. If the stimulus is not constant the changing <stim_val> value can be tracked with a transmitter (actual or virtual). The "dependency_id_ref " attribute points to the dependency id that points to the sensor that tracks the <stim_val> value,

Data type: Float Allowed values:

> EMPTY

> Any real number for receivers

> One of the allowed measurement values for transmitters

Attributes:

> "dependency_id_ref "- (Optional) This attribute points to the dependency id that points to the transducer which provides the stimulus

4.13.2 ELEMENT resp_val

Path: tml>data_desc>transducers>transducer>sample>measure>cal_ref>resp>val

Description:

Sometimes it is necessary to incorporate a known reference source into a sensor system to adjust the gain and bias after during processing. With a known source (stimulus) given by the value of the <stim_val> element the response should be a certain value determined by <resp_val> or by the io transfer fens. If the <resp_val> is not what it should be, then adjustments can be made during the processing. The <resp_val> value can be tracked with a sensor. The "dependency_id_ref " attribute points to the dependency id that points to the sensor that tracks the <resp val> value. Data type: Float Allowed values:

> EMPTY for receivers

> EMPTY for transmitters

Attributes:

> "dependency_id_ref " - (Optional) This attribute points to the dependency id that points to the transducer which provides the measured response from the calibrated stimulus

<stim_val> .

4.14 ELEMENT dependency

O..00

- - dartgte

- -^position M

■^attitude S)

Figure 59 - dependency element

DTP:

<! ELEMENT dependency (mod_dep*, attached*, dangle*-, position?, attitude?) > <!ATTLIST dependency trans_ref IDREF #REQUIRED >

<! ELEMENT mod_dep EMPTY> <!ATTLIST mod_deρ dependency_id ID #REQ0IRED mod_ref IDREF IREQUIRED >

<!ELEMENT attached (attach_desc, sen meas_value?}> <!ATTLIST attached dependency_id ID #REQUIRED trans_ref IDREF #REQUIRED >

< ! — reference transducer as a whole or an individual measurement — > < ! ELEMENT attach_desc (nomenclature) > < ! ELEMENT sen_meas_value EMPTY>

< ! — constant value (hex) in #PCDATA or sensor measurement id using IDREF — > < ! ATTLIST sen_meas_value meas_ref IDREF fREQOIRED fcn_jnodify (repl | add | mult) #REQUIRED >

< ! ELEMENT dangle (dangle_desc) > <! ATTLIST dangle deρendency_id ID #REQUIRED trans_ref IDREF #REQUIRED >

< ! ELEMENT dangle_desc (nomenclature) > < ! — measurement id — >

<!ELEMENT position ( ( (x, y, z) | (alpha, beta, range) ) , ( (x_vel, y_vel, z_vel ) I (alpha_vel, beta_vel, range_vel) ) ?, ( (x_accl, y_accl, z_accl ) | (alpha_accl, beta_accl, range_accl ) ) ?) > < !ATTLIST position dependency_id ID IREQUIRED ref_sys (earth | transducer) #REQUIRED trans_ref IDREF #IMPLIED >

< ! ELEMENT attitude (omega, phi, kappa, (omega_vel, phi_vel, kappa_vel) ?, (omega_accl, phi_accl, kappa_accl) ?) > < ! ATTLIST attitude dependency_id ID ^REQUIRED ref_sys (earth I transducer) #REQUIRED transducer_ref IDREF #IMPLIED >

4.14.1 ELEMENT mod dep Path: tml>data_desc>relations>dependency>mod_dep

Description:

This element associates a model (TCF or function) to a parent transducer. The "dependency_id" attribute value (e.g. t003d002) is referenced by a transducer characteristic using a "dependency_id_ref" attribute from the parent transducer element. The "mod_ref " attribute points to the model using the "id" attribute value assigned from the <model> element.

Data type: LJTF-8 (character) Allowed values:

> EMPTY

Attributes:

> "dependency_id" - (Required) This attribute sets the dependency id the particular dependency. The convention for id numbers for dependencies shall be tnnndmmm where "tnnn" signifies a transducer id number of the parent transducer, and "dmmm" is the dependency sequence number for the particular transducer.

> "mod_ref" - (Required) This attribute point to the TCF or function model. The id number in the value of this attribute identifies the model to use.

4.14.2 ELEMENT attached Path: tml>data_desc>relations>dependency>attached

Description:

The <attached> dependency assigns a transducer measurement to a changing transducer characteristic element from a parent transducer. The dependency reference comes from a dependency reference from within the <transducers> element. The dependency will assign a measurement from an external (real or virtual) transducer to track a changing parameter from within a subscribing parent transducer. Attached relations are "attached at both ends the "from" and the "to" (e.g. from <gain> element of transducer #1, to gain sensor transducer #2, measurement #1)

Data type: UTF-8 (character) Attributes:

> "dependency_id" - (Required) This attribute sets the dependency id the particular dependency. The convention for id numbers for dependencies shall be tnnndmmm where "tnnn" signifies a transducer id number of the parent transducer, and "dmmm" is the dependency sequence number for the particular transducer.

> "trans_ref " - (Required) ) This attribute identifies (transducer id number) what the id number of the parent transducer is (e.g. t004). Relationships always start from the top or principal transducers as the parent.

Child Elements: > ( 1 ) attach_desc element

> (0 or 1 ) senjneas value element

4.14.3 ELEMENT attach_desc

Path: tml>data_desc>relations>dependency>attached>attch_desc

Description:

This element contains the <nomenclature> element which describes the attached transducer and its relation to the parent transducer.

Data type: UTF-8 (character) Child Elements:

> (1) nomenclature element

4.14.4 ELEMENT sen_meas_value Path: tml>data_desc>relations>dependency>attached>sen_meas__value

Description:

This attribute to this element contains the reference (or pointer) to the sensor measurement id which will be linked to the parent transducer characteristic. The sensor measurement will either replace, add to, or be multiplied by the single characteristic value or the TCF model values of the parent transducer element referencing this dependency.

Data type: UTF-8 (character) Allowed values:

> EMPTY

Attributes: > "meas_ref " - (Required) This attribute points to the measurement from the transducer (sensor) which measures the changing value that will replace or modify a characteristic from within the parent <transducer> element

> " f cn_modi f y " - (Required) The attached sensor measurement can either replace the single value characteristic, or add to it, or multiply by it (replace | + 1 x) depending on the setting of this attribute. The following describes how the TCF model and the attached sensor modify a single transducer characteristic. If no TCF or attached sensor are available for a characteristic then the characteristic is the single value found in the characteristic element. If a TCF model is available then the TCF model will modify the single value according to the "fcrwnodify" attribute. If only an attached sensor is present then the attached sensor value will modify the single value according the to the ^Mf cnjnodify" attribute in the attached sensor. If both a TCF model and an attached sensor are present for a single characteristic then the TCF model will modify the single value according the the " f cn_modi f y " attribute, and the attached sensor will modify the resultant value of the TCF model and the fixed value according to the ^vv f cn_modi f y " attribute of the attached sensor.

For a transducer characteristic:

> Each TCF sample = (single element value) or

> Each TCF sample = (single element value) (replace | + 1 x) (each TCF model sample) or

> Each TCF sample = (single element value) (replace | + ) x) (sen_meas_value value) or

> Each TCF sample = (single element value) (replace | + 1 x) (each TCF model sample) (replace I + 1 x) (sen_meas_value value)

4.14.5 ELEMENT nomenclature Path: tml>data_desc>relations>dependency>attached>attach_desc>noraenclature

Description:

Mod_desc - The nomenclature is a short name given to describe the model such as: "frequency response" or "alpha coordinate". Function models represent two dimensional functions (dependent and independent variables) and are used to describe transducer characteristics such as IFOV, frequency response, power spectral density, and input/output transfer functions. TCF models represent how transducer characteristics vary over the TCF such as relative locations of sample ambiguity spaces, sample timing relationships, and detector radiometric gain adjustments. trans_desc - a short name given to the transducer. Example: "Infrared Line Scanner" meas_desc - a short name given to the measurement. Example: "gain factor". attach_desc - a short name given to the attached relationship. Example: "diagnostic measurements" Data type: UTF-8 (character)

4.14.6 ELEMENT dangle Path: tml>data_desc>relations>dependency>dangle

Description:

The <dangle> dependency assigns a transducer to a parent transducer. The dangle dependency is to associate other types of measurements to a particular transducer. This can be used to communicate such measurements as mode settings or diagnostic or transducer system health data. The dangle dependency does not originate from within the transducer element (i.e. does not have a "from" point). The dangle dependency provides additional data about the parent transducer as a whole. It does not focus on a particular characteristic as the attached dependency does. The <dangle_desc> of the dangled transducer provides a specific description as to its relationship with the parent transducer. The "dependency_id" attribute identifies the id number of the dependency that describes the dangle relationship. The "trans_ref " attribute points to the parent transducer for where the dependency ( "deρendency_id_ref" ) reference exist. The "trans_ref " attribute points to the transducer that is dangling from the parent transducer. This transducer provides additional information about the parent transducer such as diagnostic data.

Data type: UTF-8 (character) Attributes:

> "dependency_id" - (Required) This attribute sets the dependency id the particular dependency. The convention for id numbers for dependencies shall be tnnndmmm where "tnnn" signifies a transducer id number of the parent transducer, and "dmmm" is the dependency sequence number for the particular transducer.

> "trans_ref " - (Required) ) This attribute identifies (transducer id number) what the id number of the parent transducer is (e.g. t004). Relationships always start from the top or principal transducers as the parent.

Child Elements:

> (1) dangle desc element 4.14.7 ELEMENT dangle_desc

Path: tml>data_desc>relations>dependency>dangle>dangle_desc

Description:

This element contains the <noraenclature> element which describes the dangle transducer and its relation to the parent transducer.

Data type: UTF-8 (character) Child Elements:

> (1) nomenclature element

4.14.8 ELEMENT nomenclature

Path: tml>data_desc>relations>dependency>dangle>dangle_desc>nomenclature

Description

Mod_desc - The nomenclature is a short name given to describe the model such as: "frequency response" or "alpha coordinate". Function models represent two dimensional functions (dependent and independent variables) and are used to describe transducer characteristics such as IFOV, frequency response, power spectral density, and input/output transfer functions. TCF models represent how transducer characteristics vary over the TCF such as relative locations of sample ambiguity spaces, sample timing relationships, and detector radiometric gain adjustments. trans_udes c - a short name given to the transducer. Example: "Infrared Line Scanner" meas_desc - a short name given to the measurement. Example: "gain factor". attach_desc - a short name given to the attached relationship. Example: "diagnostic measurements"

Data type: UTF-8 (character) 4.14.9 ELEMENT position Path: tml>data_desc>relations>dependency>position

Description:

This element provides positional, positional rate of change (velocity), and the positional rate of rate of change (acceleration) data about the subject transducer (i.e. "trans_ref"). This element is required for positionally variant transducers. This element contains the set of positional ,velocity, and acceleration elements for describing motion in both Cartesian and spherical coordinate systems. Attached or dangled transducers are assumes to be positioned with the parent transducer and do not require positional descriptions. Positional sensors measure their own position relative to earth or another transducer in the earth or other transducers' reference system. Linear displacement sensors may need a virtual attitudinal sensor to rotate the reference system frame in such a way as to align the linear motion with one of the cardinal axis of the reference system. The "dependency_id" attribute value is an index number assigned to the positional dependency. The "ref_sys" attribute identifies the reference system which the positional coordinates are described. Allowed values for the "ref__sys" attribute are: earth and transducer. If the "ref_sys" attribute is equal to transducer then the "trans_ref " attribute identifies which transducer reference system the transducer position is relative to.

Data type: UTF-8 (character) Attributes:

> Mependency_id" - (Required) This attribute sets the dependency id the particular dependency. The convention for id numbers for dependencies shall be tnnndmmrn where "tnnn" signifies a transducer id number of the parent transducer, and "dmmm" is the dependency sequence number for the particular transducer.

> "ref_sys" - (Required) This attribute identifies the reference system from which the subject transducer is placed relative to. The allowed values for this attribute are: earth or transducer.

> "trans__ref " - (optional) If the value of the "ref_sys" attribute is "transducer", then this attribute identifies the transducer id of the transducer which provides the reference position of the parent transducer identified in the <dependency> element "trans_ref " attribute.

Child Elements: > (l)x element and

> (1) y element and,

> (1) z element and

> (1) alpha element and

> (I) beta element and ^ (1) range element and

> (0 or l)x_vel element and

> (0 or l) y_vel element and,

> (0 or 1) z_vel element and

> (0 or 1) alpha_vel element and

> (0 or 1) bet a_vel element and ^ (0 or 1) range_vel element and

> (0 or l)x_accel element and

> (0 or 1) y_accel element and,

> (0 or l) z_accel element and

> (0 or 1) alpha_accel element and

> (0 or 1) beta_accel element and

> (0 or 1) range accel element

4.14.10ELEMENT attitude

Path: tml>data_desc>relations>dependency>attitude

Description:

This element provides attitude, attitude rate of change (rotational velocity), and the rotational rate of rate of change (rotational acceleration) data about the subject transducer (i.e. "trans_ref"). This element is required for attitudinally variant transducers. This element contains the set of attitude, rotational velocity, and rotational acceleration elements for describing motion in both Cartesian and spherical coordinate systems. Attached or dangled transducers are assumes to be oriented with respect to the parent transducer and do not require positional descriptions. Attitudinal sensors measure their own attitude relative to earth or another transducer in the earth or other transducers' reference system. Linear displacement sensors may need a virtual attitudinal sensor to rotate the reference system frame in such a way as to align the linear motion with one of the cardinal axis of the reference system. The "dependency_id" attribute value is an index number assigned to the positional dependency. The "ref_sys" attribute identifies the reference system which the attitudinal coordinates are described. Allowed values for the "ref_sys" attribute are: earth and transducer. If the "ref_sys" attribute is equal to transducer then the "trans_ref " attribute identifies which transducer reference system the transducer position is relative to.

Attributes: > "ref _sys " - (Required) (earth | transducer)

> "transducerjcef " - (Optional)

Child Elements:

> (1) omega element and

> (1) phi element and y (1) kappa element

Figure 60 - position element

DTD:

<! ELEMENT position ( ( (x, y, z) | (alpha, beta, range)), ( (x_vel, y_vel, z_vel) I (alpha_vel, beta_vel, range_vel) ) ?, ( (x_accl, y_accl, z_accl) (alpha_accl, beta_accl, range_accl) ) ?)> <!ATTLIST position dependency_id ID IREQUIRED ref_sys (earth | transducer) #REQUIRED trans_ref IDREF IIMPLIED >

<!ELEMENT X ((value, accy?) I sen_meas_value)>

<! ELEMENT value (#PCDATA)>

<!ELEMENT y ((value, accy?) sen_meas_value) >

<!ELEMENT z ((value, accy?) sen meas value) >

<!ELEMENT alpha ((value, accy?) I sen_meas_value) >

<! ELEMENT beta ((value, accy?) I sen meas value) >

<! ELEMENT range ((value, accy?) I sen_meas_value) >

<! ELEMENT x_vel ((value, accy?) I sen_meas_value) >

<! ELEMENT y_vel ((value, accy?) I sen meas value) >

<!ELEMENT z_vel ((value, accy?) I sen_meas_value)>

<!ELEMENT alpha_vel ({value, accy?) | sen_meas_value)>

< !ELEMENT bet a_vel ((value, accy?) | sen_meas_value)>

<! ELEMENT range_vel ((value, accy? I sen_meas_value) >

<! ELEMENT x_a ccl ((value, accy?) | sen_meas_value) >

<! ELEMENT y_a ccl ((value, accy?) | sen meas value) >

<!ELEMENT z_accl ((value, accy?) | sen_meas_value)> <!ELEMENT alpha_accl ((value, accy?) | sen_meas_value)> <!ELEMENT beta_accl ((value, accy?) | sen_meas_value) > <! ELEMENT range accl ((value, accy?) | sen meas_value)>

4.15.1 ELEMENTx

Path: tml>data_desc>relations>dependency>position>x

Description:

This element contains the elements which describe the x positional component for the subject transducer. If the positional component is fixed, then the fixed position value shall be found in the <value> element, with the associated accuracy or error term. If the positional component is variable, then the <sen__meas_value> element will contain pointers to the sensor which measures the positional component.

Child Elements:

> (1) sen_raeas_value element or

> (I) value element and

> (0 or 1 ) ab s_a ccy element 4.15.2 ELEMENT y Path: tml>data_desc>relations>dependency>position>y

Description:

This element contains the elements which describe the y positional component for the subject transducer. If the positional component is fixed, then the fixed position value shall be found in the <value> element, with the associated accuracy or error term. If the positional component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the positional component.

Child Elements:

^ ( 1 ) s en_me a s_va 1 ue element or

> (1) value element and

> (0 or l) abs accy element

4.15.3 ELEMENT z Path: tml>data_desc>relations>dependency>position>z

Description:

This element contains the elements which describe the z positional component for the subject transducer. If the positional component is fixed, then the fixed position value shall be found in the <value> element, with the associated accuracy or error term. If the positional component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the positional component.

Child Elements:

> (1) sen_meas_value element or

> (1) value element and

> (0 or 1) abs_accy element

4.15.4 ELEMENT alpha Path: tml>data_desc>relations>dependency>position>alpha

Description:

This element contains the elements which describe the alpha positional component for the subject transducer. If the positional component is fixed, then the fixed position value shall be found in the <value> element, with the associated accuracy or error term. If the positional component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the positional component.

Child Elements:

> (1) sen_meas_value element or

> (1) value element and

> (0 or 1) abs_accy element

4.15.5 ELEMENT beta

Path: tml>data_desc>relations>dependency>position>beta

Description:

This element contains the elements which describe the beta positional component for the subject transducer. If the positional component is fixed, then the fixed position value shall be found in the <value> element, with the associated accuracy or error term. If the positional component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the positional component.

Child Elements:

> (1) sen_meas_value element or

> (1) value element and

> (0 or 1) abs_accy element

4.15.6 ELEMENT range

Path: tml>data_desc>relations>dependency>position>range Description:

This element contains the elements which describe the range positional component for the subject transducer. If the positional component is fixed, then the fixed position value shall be found in the <value> element, with the associated accuracy or error term. If the positional component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the positional component.

Child Elements:

> (1) sen_meas_yalue element or

> ( 1 ) value element and

> (0 or 1 ) abs_accy element

4.15.7 ELEMENT x vel

Path: tml>data_desc>relations>dependency>position>x_vel

Description:

This element contains the elements which describe the x velocity component for the subject transducer. If the velocity component is fixed, then the fixed velocity value shall be found in the <value> element, with the associated accuracy or error term. If the velocity component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the velocity component.

Child Elements:

> ( 1 ) sen_meas_value element or

> (1) value element and

> (0 or 1) abs_accy element

4.15.8 ELEMENT y_vel

Path: tml>data_desc>relations>dependency>position>y vel

Description:

This element contains the elements which describe the y velocity component for the subject transducer. If the velocity component is fixed, then the fixed velocity value shall be found in the <value> element, with the associated accuracy or error term. If the velocity component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the velocity component.

Child Elements:

> (1) sen_meas_value element or

> (1) value element and

> (0 or 1) abs_accy element

4.15.9 ELEMENT z_vel

Path: tml>data_desc>relations>dependency>position>z_vel

Description:

This element contains the elements which describe the z velocity component for the subject transducer. If the velocity component is fixed, then the fixed velocity value shall be found in the <value> element, with the associated accuracy or error term. If the velocity component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the velocity component.

Child Elements:

> (1) sen_meas_value element or

> (1) value element and

> (0 or 1) abs_accy element

4.15.10ELEMENT alpha_vel Path: tml>data_desc>relations>dependency>position>alpha_vel

Description:

This element contains the elements which describe the alpha velocity component for the subject transducer. If the velocity component is fixed, then the fixed velocity value shall be found in the <value> element, with the associated accuracy or error term. If the velocity component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the velocity component. Child Elements:

> (1) sen_meas_value element or

> ( 1 ) value element and

> (0 or 1) abs_accy element

4.15.11ELEMENT beta_vel

Path: tml>data_desc>relations>dependency>position>beta_vel

Description:

This element contains the elements which describe the beta velocity component for the subject transducer. If the velocity component is fixed, then the fixed velocity value shall be found in the <value> element, with the associated accuracy or error term. If the velocity component is variable, then the <sen_meas__value> element will contain pointers to the sensor which measures the velocity component.

Child Elements:

> ( 1 ) sen_meas_value element or

> (1 ) value element and

> (0 or 1) abs_accy element

4.15.12ELEMENT range_vel

Path: tral>data_desc>relations>dependency>position>range_vel

Description:

This element contains the elements which describe the range velocity component for the subject transducer. If the velocity component is fixed, then the fixed velocity value shall be found in the <value> element, with the associated accuracy or error term. If the velocity component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the velocity component.

Child Elements:

> (1) sen_meas_value element or

> ( 1 ) value element and > (0 or 1) abs_accy element

4.15.13ELEMENT x_accel

Path: tml>data_desc>relations>dependency>position>x_accel

Description:

This element contains the elements which describe the x acceleration component for the subject transducer. If the acceleration component is fixed, then the fixed acceleration value shall be found in the <value> element, with the associated accuracy or error term. If the acceleration component is variable, then the <sen__meas_value> element will contain pointers to the sensor which measures the acceleration component.

Child Elements:

> ( 1 ) sen_meas_value element or

> ( 1 ) value element and

> (0 or 1) abs_accy element

4.15.14ELEMENT y_accel Path: tml>data_desc>relations>dependency>position>y_accel

Description:

This element contains the elements which describe the y acceleration component for the subject transducer. If the acceleration component is fixed, then the fixed acceleration value shall be found in the <value> element, with the associated accuracy or error term. If the acceleration component is variable, then the <sen_meas__value> element will contain pointers to the sensor which measures the acceleration component.

Child Elements:

> (1) sen_meas_value element or

> (1) value element and

> (0 or 1) abs_accy element

4.15.15ELEMENT z_accel Path: tml>data_desc>relations>dependency>position>z_accel

Description:

This element contains the elements which describe the z acceleration component for the subject transducer. If the acceleration component is fixed, then the fixed acceleration value shall be found in the <value> element, with the associated accuracy or error term. If the acceleration component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the acceleration component.

Child Elements:

> ( 1 ) sen_meas_value element or

> ( 1 ) value element and

> (0 or 1) abs_accy element

4.15.16ELEMENT alpha_accel

Path: tml>data_desc>relations>dependency>ρosition>alpha_accel

Description:

This element contains the elements which describe the alpha acceleration component for the subject transducer. If the acceleration component is fixed, then the fixed acceleration value shall be found in the <value> element, with the associated accuracy or error term. If the acceleration component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the acceleration component.

Child Elements:

> ( 1 ) sen_meas_value element or

> ( 1 ) value element and

> (0 or 1) abs_accy element

4.15.17ELEMENT beta_accel Path: tml>data desc>relations>deρendency>position>beta accel

© COPYRIGHT IRIS CORPORATION 2003 Description:

This element contains the elements which describe the beta acceleration component for the subject transducer. If the acceleration component is fixed, then the fixed acceleration value shall be found in the <value> element, with the associated accuracy or error term. If the acceleration component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the acceleration component.

Child Elements:

> ( 1 ) sen_meas_yalue element or

> (1) value element and

> (O or 1 ) abs_accy element

4.15.18ELEMENT range_accel Path: tml>data_desc>relations>dependency>position>range_accel

Description:

This element contains the elements which describe the range acceleration component for the subject transducer. If the acceleration component is fixed, then the fixed acceleration value shall be found in the <value> element, with the associated accuracy or error term. If the acceleration component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the acceleration component.

Child Elements:

> (1) senjmeasjvalue element or

> (1) value element and

> (0 or 1) abs accy element

4.16 ELEMENT attitude

© COPYRIGHT IRIS CORPORATION 2003

Figure 61 - attitude element

DTD:

<! ELEMENT attitude (omega, phi, kappa, (omega_vel, phi_vel, kappa_vel) ?, (omega_accl, phi_accl, kappa_accl) ?)> < !ATTLIST attitude dependency_id ID #REQUIRED ref_sys (earth | transducer) IREQUIRED transducer_ref IDREF iIMPLIED >

<!ELEMENT omega (sen_meas_value | (value, accy?))> <! ELEMENT phi (sen_raeas_value | (value, accy?))> <!ELEMENT kappa (sen meas_value | (value, accy?))> <!ELEMENT omega_vel (sen_raeas_value | (value, accy?))> <! ELEMENT phi_vel (sen_meas_value | (value, accy?))> <!ELEMENT kappa_vel (sen_meas_value I (value, accy?))> < [ELEMENT omega_accl (sen_meas_value | (value, accy?))> <!ELEMENT phi_accl (sen_meas_value | (value, accy?))> <!ELEMENT kappa_accl (sen_meas_value | (value, accy?))>

4.16.1 ELEMENT omega Path: tml>data_desc>relations>dependency>attitude>omega

Description: /

This element contains the elements which describe the omega attitudinal component for the subject transducer. If the attitudinal component is fixed, then the fixed attitudinal value shall be

© COPYRIGHT IRIS CORPORATION 2003 found in the <value> element, with the associated accuracy or error term. If the attitudinal component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the attitudinal component.

Child Elements:

> (1) sen_meas_value element or

> (1) value element and y (0 or 1) abs_accy element

4.16.2 ELEMENT phi

Path: tml>data_desc>relations>dependency>attitude>phi

■Description:

This element contains the elements which describe the phi attitudinal component for the subject transducer. If the attitudinal component is fixed, then the fixed attitudinal value shall be found in the <value> element, with the associated accuracy or error term. If the attitudinal component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the attitudinal component.

Child Elements:

> (1) sen_meas_value element or

> (1) value element and

> (0 or 1 ) abs_accy element

4.16.3 ELEMENT kappa

Path: tml>data_desc>relations>dependency>attitude>kappa

Description:

This element contains the elements which describe the kappa attitudinal component for the subject transducer. If the attitudinal component is fixed, then the fixed attitudinal value shall be found in the <value> element, with the associated accuracy or error term. If the attitudinal component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the attitudinal component.

©COPYRIGHT IRIS CORPORATION 2003 Child Elements:

> (1) sen_meas_value element or > (1) value element and

> (0 or 1 ) abs_accy element

4.16.4 ELEMENT omega vel Path: tml>data_desc>relations>dependency>attitude>omega_vel

Description:

This element contains the elements which describe the omega attitudinal velocity component for the subject transducer. If the attitudinal velocity component is fixed, then the fixed attitudinal velocity value shall be found in the <value> element, with the associated accuracy or error term. If the attitudinal velocity component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the attitudinal velocity component.

Child Elements:

> (1) sen_meas_value element or

> (1) value element and

> (0 or 1 ) abs_accy element

4.16.5 ELEMENT phi vel Path: tml>data_desc>relations>dependency>attitude>phi_vel

Description:

This element contains the elements which describe the phi attitudinal velocity component for the subject transducer. If the attitudinal velocity component is fixed, then the fixed attitudinal velocity value shall be found in the <value> element, with the associated accuracy or error term. If the attitudinal velocity component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the attitudinal velocity component.

Child Elements:

> ( 1 ) sen_meas_value element or

> (1) value element and

© COPYRIGHT IRIS CORPORATION 2003 > (O or 1) abs_accy element

4.16.6 ELEMENT kappa vel Path: tml>data_desc>relations>dependency>attitude>kappa_vel

Description:

This element contains the elements which describe the kappa attitudinal velocity component for the subject transducer. If the attitudinal velocity component is fixed, then the fixed attitudinal velocity value shall be found in the <value> element, with the associated accuracy or error term. If the attitudinal velocity component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the attitudinal velocity component.

Child Elements:

> ( 1 ) sen_meas_value element or

> (1) value element and

> (0 or 1) abs_accy element

4.16.7 ELEMENT omega_accel Path: tπιl>data_desc>relations>dependency>attitude>omega_accel

Description:

This element contains the elements which describe the omega attitudinal acceleration component for the subject transducer. If the attitudinal acceleration component is fixed, then the fixed attitudinal acceleration value shall be found in the <value> element, with the associated accuracy or error term. If the attitudinal acceleration component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the attitudinal acceleration component.

Child Elements:

> (1) sen_meas_value element or ^ (1) value element and

> (0 or 1) abs_accy element

© COPYRIGHT IRIS CORPORATION 2003 4.16.8 ELEMENT phi accel Path: tml>data_desc>relations>dependency>attitude>phi_accel

Description:

This element contains the elements which describe the phi attitudinal acceleration component for the subject transducer. If the attitudinal acceleration component is fixed, then the fixed attitudinal acceleration value shall be found in the <value> element, with the associated accuracy or error term. If the attitudinal acceleration component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the attitudinal acceleration component.

Child Elements:

> ( 1 ) sen_meas_value element or

> ( 1 ) value element and

> (0 or 1) abs_accy element

4.16.9 ELEMENT kappa_accel

Path: tml>data_desc>relations>dependency>attitude>kappa_accel

Description:

This element contains the elements which describe the kappa attitudinal acceleration component for the subject transducer. If the attitudinal acceleration component is fixed, then the fixed attitudinal acceleration value shall be found in the <value> element, with the associated accuracy or error term. If the attitudinal acceleration component is variable, then the <sen_meas_value> element will contain pointers to the sensor which measures the attitudinal acceleration component.

Child Elements:

> ( 1 ) sen_meas_value element or

> (I) value element and

> (0 or 1) abs_accy element

4.17 ELEMENT alpha The following elements have identical attributes and child elements. Only the alpha element is described here however the other elements listed have the same characteristics. Similar elements include: x, y, z, alpha, beta,r, x_vel, y_vel, z_vel, alpha_vel, beta_vel, r_vel, x_accel, y_accel, z_accel, alpha_accel, beta_accel, and r_accel

! ;

Figure 62 - coordinate element

DTD:

<! ELEMENT alpha ( (value, accy?) | sen_meas_value) >

< ! ELEMENT value (#PCDATA) >

< ! ELEMENT accy (abs_accy?, rel_accy?, rel_accy_intertcf ?, rel_accy_intratcf ?) >

< ! ELEMENT abs_accy (# PCDATA) >

< !ATTLIST abs~accy tcfinod_deρ_id__ref IDREF IIMPLIED <„ dependency_id~ref IDREF #IMPLIED >

< ! ELEMENT rel_accy (#PCDATA) > < ! ATTLIST rel_accy tcfmod_dep_id_ref IDREF ^IMPLIED dependency_id_ref IDREF #IMPLIED >

< ! ELEMENT rel_accy_intertcf ( #PCDATA) > < !ATTLIST rel accy_intertcf tcfmod_deρ_id__ref IDREF #IMPLIED dependency_id_ref IDREF #IMPLIED >

< ! ELEMENT rel_accy_intratcf (#PCDATA) > < ! ATTLI ST rel_accy_intratcf mod_dep_id_ref IDREF tIMPLIED dependency_id__ref IDREF #IMPLIED >

< ! ELEMENT sen_meas_value EMPTY>

<! — constant value (hex) in #PCDATA or sensor measurement id using IDREF — > < !ATTLIST sen_meas_value meas_ref IDREF #REQDIRED fcn modify (repl I add | mult) #REQUIRED

PYRIG IS C AT N 2003 4.17.1 ELEMENT value ^{' '} — — Path; tml>data_desc>relations>dependency>position>x>value tml>data_desc>relations>dependency>position>y> value tml>data_desc>relations>dependency>position>z>value tinl>data_desc>relations>dependency>position>alpha>value tml>data_desc>relations>dependency>position>beta>value tml>data_desOrelations>dependency>position>range>value tml>data_desc>relations>dependency>position>x_vel>value tml>data_desc>relations>dependency>position>y_vel>value tml>data_desc>relations>dependency>position>z_vel>value tml>data_desc>relations>dependency>position>alpha_vel>value tml>data_desc>relations>dependency>position>beta_vel>value tml>data_desc>relations>dependency>position>range_vel>value tml>data_desc>relations>dependency>position>x_accel>value tml>data_desc>relations>dependency>position>y_accel>value tml>data_desc>relations>dependency>position>z_accel>value tml>data_desc>relations>dependency>position>alpha_accel>value tml>data_desc>relations>dependency>position>beta_accel>value tml>data_desc>relations>dependency>position>range_accel>value tml>data_desc>relations>dependency>attitude>omega>value tml>data_desc>relations>deρendency>attitude>phi>value tml>data_desc>relations>dependency>attitude>kappa>value tml>data_desc>relations>dependency>attitude>omega_vel>value tml>data_desc>relations>dependency>attitude>phi_vel>value tml>data_desc>relations>dependency>attitude>kappa_vel>value tml>data_desc>relations>dependency>attitude>omega_accel>value tml>data_desc>relations>dependency>attitude>phi_accel>value tml>data_desc>relations>dependency>attitude>kappa_accel>value

Description:

This element contains the fixed value for the positional or attitudinal elements for the subject transducer. The accuracy of this measurement in contained in the parent element.

Data type: Float Allowed values:

> Any real number

4.17.2 ELEMENT accy Path: tml>data_desc>relations>dependency>position>x>accy tml>data_desc>relations>dependency>position>y>accy

© COPYRIGHT IRIS CORPORATION 2003 tml>data_desc>relations>dependency>position>z>accy tml>data_desc>relations>dependency>position>alpha>accy tml>data_desc>relations>dependency>position>beta>accy trnl>data_jdesc>relations>dependency>ρosition>r>accy tml>data_desc>relations>dependency>position>x_vel>accy tml>data_desc>relations>dependency>position>y_vel>accy tml>data_desc>relations>dependency>position>z_vel>accy tml>data_desc>relations>dependency>position>alpha_vel>accy tml>data_desc>relations>dependency>position>beta_vel>accy tml>data_desc>relations>dependency>position>r_vel>accy tml>data_desc>relations>dependency>position>x_accel>accy tml>data_desc>relations>deρendency>position>y_accel>accy tml>data_desc>relations>dependency>position>z_accel>accy tral>data_desc>relations>dependency>position>alpha_accel>accy tral>data_desc>relations>dependency>position>beta_accel>accy tral>data_desc>relations>dependency>position>r_accel>accy tral>data_desc>relations>dependency>attitude>oraega>accy tral>data_desc>relations>dependency>attitude>phi>accy tml>data_desc>relations>dependency>attitude>kappa>accy tml>data_desc>relations>dependency>attitude>omega_vel>accy tml>data_desc>relations>dependency>attitude>phi_vel>accy tml>data_desc>relations>dependency>attitude>kappa_vel>accy tml>data_desc>relations>dependency>attitude>omega_accel>accy tml>data_desc>relations>dependency>attitude>phi_accel>accy tml>data_desc>relations>dependency>attitude>kappa_accel>accy

Description:

This element contains the set of elements which are used to characterize the accuracy of the measurement.

Child Elements:

> (0 or 1) abs_accy elements and

> (0 or 1) rel_accy elements and

> (0 or 1) rel_accy_intertcf elements and

> (0 or 1) rel accy intratcf elements

4.17.3 ELEMENT abs_accy Path: tml>data_desc>relations>dependency>position>x>accy>abs_accy tml>data_desc>relations>dependency>position>y>accy>abs_accy tml>data_desc>relations>dependency>position>z>accy>abs_accy tml>data_desc>relations>dependency>position>alpha>accy>abs_accy tml>data_desc>relations>dependency>position>beta>accy>abs_accy tml>data_desc>relations>dependency>position>r>accy>abs_accy tml>data_desc>relations>dependency>position>x_vel>accy>abs_accy tml>data_desc>relations>dependency>position>y_vel>accy>abs_accy tml>data_desc>relations>dependency>position>z_vel>accy>abs_accy

© COPYRIGHT IRIS CORPORATION 20D3 tml>data_desc>relations>dependency>position>alpha_vel>accy>abs_accy tml>data_desc>relations>dependency>position>beta_vel>accy>abs_accy tml>data_desc>relations>dependency>position>r__vel>accy>abs__accy tml>data_desc>relations>dependency>position>x__accel>accy>abs_accy tml>data_desc>relations>dependency>position>y_accel>accy>abs_accy tml>data_desc>relations>de'pendency>position>z_accel>accy>abs_accy tml>data_desc>relations>dependency>position>alpha_accel>accy>abs__accy tml>data_desc>relations>dependency>position>beta_accel>accy>abs_accy tml>data_desc>relationa>dependency>position>r_accel>accy>abs_accy tml>data_desc>relations>dependency>attitude>omega>accy>abs_accy tml>data_desc>relations>dependency>attitude>phi>accy>abs_accy tml>data_desc>relations>dependency>attitude>kappa>accy>abs_accy tml>data_desc>relations>dependency>attitude>omega_vel>accy>abs_accy tml>data_desc>relations>dependency>attitude>phi_vel>accy>abs_accy tml>data_desc>relations>dependency>attitude>kappa_vel>accy>abs_accy tml>data_desc>relations>dependency>attitude>omega_accel>accy>abs_accy tml>data_desc>relations>dependency>attitude>phi_accel>accy>abs_accy tml>data_desc>relations>dependency>attitude>kappa_accel>accy>abs_accy

Description:

This value contains the 2 sigma value of the deviation of the absolute measurement accuracy based on NIST standards. If the abs_accy varies as a function of TCF sample position then a TCF model will enumerate the accuracy for each sample. The "tcfmod_dep_id_ref " attribute will reference the dependency which points to the TCF model that describes the abs_accy as a function of sample position within the TCF. If the accuracy varies and can be measured then a sensor will capture the absolute accuracy value. The sensor will be referenced by the "dependency_id_ref " attribute. If the measurement accuracy values vary as a position within the TCF then a TCF model will characterize the 2 sigma accuracy as a function of TCF position. The <dependency> element will contain the function modifier which identifies how the sensor value modifies either the tcfjnodel values or the <abs_accy> element value.

Data type:

Float

Attributes:

> "tcfmod_dep_id_ref" - (Optional) this attribute points (indirect pointer) to the dependency id which points to the TCF model of the absolute accuracy values for each of the corresponding TCF sample locations.

> "dependency_id_ref" - (Optional) this attribute (indirect pointer) points to the dependency id which points to the sensor measuring the absolute accuracy of the measurement and modifies either the <abs_accy> value or the values of the TCF model according to the <f cnjnodif y> element.

4.17.4 ELEMENT rel_aσcy

©COPYRIGHT IRIS CORPORATION 2003 Path: tml>data_desc>relations>dependency>position>x>accy>rel_accy tml>data_desc>relations>dependency>position>y>accy>rel_accy tml>data_desc>relations>dependency>position>z>accy>rel_accy tml>data_desc>relations>dependency>position>alpha>accy>rel_accy tml>data_desc>relations>dependency>position>beta>accy>rel_accy tml>data_desc>relations>dependency>position>r>accy>rel_accy trαl>data_desc>relations>dependency>position>x_vel>accy>rel_accy tml>data_desc>relations>deρendency>position>y_vel>accy>rel_accy tml>data_desc>relations>deρendency>position>z_vel>accy>rel_accy tml>data_desc>relations>deρendency>position>alρha_vel>accy>rel_accy tml>data_desc>relations>dependency>position>beta_vel>accy>rel_accy tml>data_desc>relations>deρendency>position>r_vel>accy>rel_aocy tml>data_desc>relations>dependency>position>x_accel>accy>rel_accy tml>data_desc>relations>deρendency>position>y_accel>accy>rel_accy tml>data_desc>relations>deρendency>position>z_accel>accy>rel_accy tml>data_desc>relations>dependency>position>alpha_accel>accy>rel_accy tml>data_desc>relations>dependency>position>beta_accel>accy>rel_accy tml>data_desc>relations>dependency>position>r_accel>accy>rel_accy tml>data_desc>relations>dependency>attitude>omega>accy>rel_accy tml>data_desc>relations>dependency>attitude>phi>accy>rel_accy tml>data_desc>relations>dependency>attitude>kappa>accy>rel_accy tml>data_desc>relations>dependency>attitude>omega_vel>accy>rel_accy tml>data desc>relations>dependency>attitude>phi_vel>accy>rel_accy tml>data desc>relations>dependency>attitude>kappa vel>accy>rel_accy tml>data_desc>relations>dependency>attitude>omega accel>accy>rel_accy tml>data_desc>relations>dependency>attitude>phi_accel>accy>rel_accy tinl>data_desc>relations>dependency>attitude>kappa_accel>accy>rel_accy

Description:

The rel_accy element is used in multiple locations within TML. The following describe how rel__accy is used in each of the locations. sys_clk - The <rel_accy> element describes the average drift in temporal accuracy over time. This value is unsigned. A value such as 1E-9 would indicate a one count error in 1E9 counts of the clock. The relative time accuracy needs to be taken into account when comparing data from different times. The temporal error may not be significant unless the time difference is large or the <rel_accy> is large. Temporal errors are a contributing error for the derivation of resultant positional and temporal error estimates. tcfjime - This value represents the relative accuracy of the frame period. This value shall be represented in the same fashion as the <rel_accy> of the <sys_clk> element. Knowing this is useful in determining the temporal accuracy of the start time of a TCF which is embedded within a large cluster.

Data type: Float Attributes:

> "tcfmod_dep_id_ref" - (optional) This attribute is used to reference a model dependency id which points to a TCF model that describes the relative accuracy as a function of sample position within the TCF.

> Mependency_ID_ref " - (Optional) This attribute is used if the relative accuracy of the parent element value varies with time and is measured by another sensor. The "dependency_id_ref" attribute is a reference to the dependency number which identifies the sensor that measures the <rel accy> value.

4.17.5 ELEMENT rel_accy_intertcf

Path: tml>data_desc>relations>dependency>position>x>accy>rel_accy_intertcf tml>data_desc>relations>dependency>position>y>accy>rel_accy_intertcf tml>data_desc>relations>dependency>position>z>accy>rel_accy_intertcf tml>data_desc>relations>dependency>position>alpha>accy>rel_accy_intertcf tml>data_desc>relations>dependency>position>beta>accy>rel_accy_intertcf tml>data_desc>relations>dependency>position>r>accy>rel_accy_intertcf tml>data_desc>relations>dependency>position>x_vel>accy>rel_accy_intertcf tml>data_desc>relations>dependency>position>y_vel>accy>rel_accy_intertcf trnl>data_desc>relations>dependency>position>z_vel>accy>rel_accy_intertcf tml>data_desc>relations>dependency>position>alpha_vel>accy>rel_accy_intertcf tml>data_desc>relatioπs>dependency>position>beta_vel>accy>rel_accy_intertcf tml>data_desc>relations>dependency>position>r_vel>accy>rel_accy_intertcf tml>data_desc>relations>dependency>position>x_accel>accy>rel_accy_intertcf tml>data_desc>relations>dependency>position>y_accel>accy>rel_accy_intertcf tml>data_desc>relations>dependency>position>E_accel>accy>rel_accy_intertcf tml>data_desc>relations>dependency>position>alpha_accel>accy>rel_accy_intertc f tml>data_desc>relations>dependency>position>beta_accel>accy>rel_accy_intertcf tml>data_desc>relations>dependency>position>r_accel>accy>rel_accy_intertcf tml>data_desc>relations>dependency>attitude>omega>accy>rel_accy_intertcf tml>data_desc>relations>dependency>attitude>phi>accy>rel_accy_intertcf tml>data_desc>relations>dependency>attitude>kappa>accy>rel_accy_intertcf tml>data_desc>relations>dependency>attitude>omega_vel>accy>rel_accy_intertcf tml>data_desc>relations>dependency>attitude>phi_vel>accy>rel_accy_inte^'rtcf tml>data_desc>relations>dependency>attitude>kappa_vel>accy>rel_accy_intertcf tml>data_desc>relations>deρendency>attitude>omega_accel>accy>rel_accy_intertc f tml>data_desc>relations>dependency>attitude>phi_accel>accy>rel_accy_intertcf tml>data_desc>relations>dependency>attitude>kappa_accel>accy>rel_accy_intertc f

Description:

This element identifies- the relative accuracy of the measurement when the two measurements reside in different TCFs. The difference between two measurements is better the closer together they are. As the distance (time or distance) between the two measurements increases the larger

© COPYRIGHT IRIS CORPORATION 2003 the relative error becomes. .The relative accuracy accumulates at the rate indicated by the value of this element. The inter-TCF (between different TCFs) accuracy is in terms of how many TCFs will accumulate one unit of error. For example a 1E-6 indicates 1 unit, 2 sigma, of error in 1E6 TCFs when measurements are taken between two corresponding samples from two different TCFs of the same transducer (i.e. error/TCF). The error between corresponding samples of different TCFs may be different than continually accumulating the intraTCF error rate between them.

Data type:

Float

Attributes:

> "tcfmod_dep_id_ref " - (optional) This attribute describes any variation in accuracy across the TCF

> "dependency" - (optional) This attribute points to the dependency id that points to the transducer (sensor) the measures the changing accuracy.

4.17.6 ELEMENT rel__acσy_intratσf NOT USED

4.17.7 ELEMENT sen__meas_value Path: tml>data_desc>relations>dependency>position>x>sen_meas_value tml>data_desc>relations>dependency>position>y>sen_meas_value tml>data_desc>relations>dependency>position>z>sen_meas_value tml>data_desc>relations>dependency>position>alpha>sen_meas_value tml>data_desc>relations>dependency>position>beta>sen_meas_value tml>data_desc>r.elations>dependency>position>range>sen_meas_value tml>data_desc>relations>dependency>position>x_vel>sen_meas_value tml>data_desc>relations>dependency>position>y_vel>sen_meas_value tml>data_desc>relations>dependency>position>z_vel>sen_meas_value tml>data_desc>relations>dependency>position>alpha_vel>sen_meas_value tml>data_desc>relations>dependency>position>beta_vel>sen_rαeas_value tml>data_desc>relations>dependency>position>range_vel>sen_meas_value tml>data_desc>relations>dependency>ρosition>x accel>sen_meas_value tml>data_desc>relations>dependency>position>y_accel>sen_meas_value tml>data_desc>relations>dependency>position>2_accel>sen_meas_value tml>data_desc>relations>dependency>position>alpha_accel>sen_meas_value tml>data_desc>relations>dependency>position>beta_accel>sen_meas_value tml>data_desc>relations>dependency>ρosition>range_accel>sen_meas_value tml>data_desc>relations>dependency>attitude>omega>sen_meas_value

© COPYRIGHT IRIS CORPORATION 2003 tral>data__Ldesc>relations>dependency>attitude>phi>sen_meas_value tml>data_desc>relations>dependency>attitude>kappa>sen_meas_value tml>data_desc>relations>deρendency>attitude>omega_vel>sen_meas_value tml>data_desc>relations>dependency>attitude>phi_vel>sen_meas_value tml>data_desc>relations>dependency>attitude>kappa_vel>sen_meas_value tml>data_desc>relations>dependency>attitude>omega_accel>sen_meas_value tml>data_desc>relations>dependency>attitude>phi_accel>sen_meas_value tml>data_desc>relations>dependency>attitude>kappa_accel>sen_meas_value

Description:

This attribute to this element contains the reference (or pointer) to the sensor measurement id which will be linked to the parent transducer characteristic. The sensor measurement will either replace, add to, or be multiplied by the single characteristic value or the TCF model values of the parent transducer element referencing this dependency.

Data type: UTF-8 (character) Allowed values:

> EMPTY

Attributes:

> "meas_ref" - (Required) This attribute points to the measurement from the transducer (sensor) which measures the changing value that will replace or modify a characteristic from within the parent <transducer> element

> "f cn_modif y" - (Required) The attached sensor measurement can either replace the single value characteristic, or add to it, or multiply by it (replace | + | x) depending on the setting of this attribute. The following describes how the TCF model and the attached sensor modify a single transducer characteristic. If no TCF or attached sensor are available for a characteristic then the characteristic is the single value found in the characteristic element. If a TCF model is available then the TCF model will modify the single value according to the "f cnjnodif y" attribute. If only an attached sensor is present then the attached sensor value will modify the single value according the to the "fcnjnodify" attribute in the attached sensor. If both a TCF model and an attached sensor are present for a single characteristic then the TCF model will modify the single value according the the "f cn_modif y" attribute, and the attached sensor will modify the resultant value of the TCF model and the fixed value according to the " f cnjnodi f y " attribute of the attached sensor.

For a transducer characteristic:

> Each TCF sample = (single element value) or

> Each TCF sample = (single element value) (replace | + 1 x) (each TCF model sample) or

© COPYRIGHT IRIS CORPORATION 2003 ' > Each TCF sample = (single element value) (replace | + 1 x) (sen_meas_value value) or > Each TCF sample = (single element value) (replace | + 1 x) (each TCF model sample) (replace

I + 1 x) (sen_meas_value value)

4.18 ELEMENT data

Figure 63 - data element DTP:

<! ELEMENT data (cluster+)> <! ELEMENT cluster (CDATA) > <! —hexidecimal data—> < !ATTLIST cluster ref IDREF #REQUIRED elk CDATA tREQUIRED

4.18.1 ELEMENT cluster

Path: tml>data>cluster

Description:

Clusters are used to carry measurement TCF data frames. When TCF data frames are very small they can be grouped into a cluster to make the exchange more efficient and reduce data overhead. When TCF frames are very large the TCF can be broken into smaller clusters and transported with a header to synchronize the data at closer intervals. The format, structure, and organization of the data contained in the cluster value id described in the <data_desc> element. The "ref" attribute describes what transducer the cluster data comes from, and the "elk" attribute give the sys_clk time for the first sample of the first TCF in the cluster. This enables all of the transducers within the TML stream to be aligned temporally. Measurements are given in bits. The character data within the data elements is in hexadecimal encoding. If the measurements do not map evenly over eight bits, then the character data is padded with zeroes at the very end of the cluster. The data elements within the TransducerML stream contains one or more cluster elements. A cluster may contain one TCF, multiple TCFs, or a fraction of a TCF. The number of TCFs within a cluster remains consistent for a particular transducer. The tcf_per_clust attribute indicates the number of TCFs per cluster. Some sensors such as audio sensors have very small frames. It is useful to bundle several small frames into a single data element (cluster) to reduce overhead. Dividing a frame that is especially large (more than 1MB?) may make it easier to parse and check for errors. If a cluster is a fraction of a frame, then the count attribute will be less than -1, as in "-4". A sequence of 4 clusters would comprise a single frame, cluster elements, that are of the same TCF would all have the same time stamp.

Attributes:

> "ref " - (Required) This attribute contains the id number of the transducer from when the transducer data came.

> "elk" - (Required) The "elk" attribute value is the value of the sys_clk at the instant the first sample (measurement) of the first TCF within the cluster. As a rale of thumb the sys_clk should run at least an order of magnitude faster than the highest sample rate of any of the transducers with in the transducer system suite.

© COPYRIGHT IRIS CORPORATION 2003 Table of Contents

SUMMARY 49

BACKGROUND 50

GENERAL DETAILS OFTHE SPECIFICATION 69

SPECIFIC DETAILS OF THE SPECIFICATION 94

-Li ELEMENT TMi₁ 94

42 ELEMENT DATA DESC 96

43 ELEMENT MODEL 104

AA ELEMENT TRANSDUCER. 108

4i ELEMENTTCF 114

4J3 ELEMENT TCF TlME . 121

4J ELEMENT MEASURE 128

M ELEMENT MEAS DESC 137

4j> ELEMENT ENCODING 143

4.10 ELEMENT FREO RESP 147

4.1 ) ELEMENT IFOM 149

4.12 ELEMENT ιo_XFER_fCN 155

4.13 ELEMENT CAL REF 161

4.14 ELEMENT DEPENDENCY 163

4.15 ELEMENT POSITION 172

4.16 ELEMENT ATTITUDE 181

4.17 ELEMENT ALPHA 186

4.18 ELEMENT DATA 195

List of Figures

Figure 1 - Simplified Reconnaissance Cycle 51

Figure 2 - Sensor Metadata 53

Figure 3 - Relative Time Sequence of Transducer Data Updates 54

Figure 4 - Simplified Multi-Sensor Reconnaissance system 57

Figure 5 - Using Sensors to Track Time Critical Metadata 58

Figure 6 - Classes of Transducers 59

Figure 7 - Remote Transducer Classes 60

Figure 8 -Scanning & Staring Transducers 61

Figure 9 - Common Coordinate Systems 63

Figure 10 - Common Reference Systems 63

Figure 1 1 - Convention for Coordinate System Transformations 64

Figure 12 - Camera Ambiguity Space 65

Figure 13 - Geo-positioning Error Contributors 69

Figure 14 - Rigorous Transducer Model 70

Figure 15 - TML data structure hierarchy 71

Figure 16 - Transducer Characteristic Frames 72

Figure 17 - range and angle (alpha) assigned to TCF dimensions - Processed SAR example 73

Figure 18 - angle (alpha) and angle (beta) assigned to TCF dimensions - Camera example 73

Figure 19 - coordinate TCF examples 75

Figure 20 - TCF Coordinates and Ambiguity Space Characterization 76

Figure 21 - Object Space to Image Space Correlation (Interior Orientation) 76

Figure 22 - Using ticks to measure coordinates 77

Figure 23 - Timing TCF 78

Figure 24 - one-to-one relation of mTCF with TCF model 78

Figure 25 - IFOM Characterization 79

Figure 26 - Frequency Response Characterization 80

Figure 27 - Input-Output Transfer function Characterization 81

Figure 28 - Sensor to Describe Dynamic Metadata 82

Figure 29 - Meta-sensors to Model Dynamic Metadata 83

Figure 30 - System Topology Diagram 83

Figure 31 - indirect target positioning through a chain of sensor measurements 85

Figure 32 - target location derivation from known interior & exterior orientations 86

Figure 33 - Capturing the Relative Time Sequence 87

Figure 34- Cluster/TCF/Sample hierarchal data structure 89

Figure 35 - Complete data stream structure 90

Figure 36 - Time sequence and duration of sensor events in data stream 91

Figure 37 - Time multiplexed serial data stream 91

Figure 38 - TML Data Capture Concept 92

Figure 39 - Sequence Order 93

Figure 40 - tml (root) element 94

Figure 41 - data desc element 97

Figure 42 - model element 105

Figure 43 - transducer element 109 Figure 44 - tcf element 1 14

Figure 45 - tcf time element 121

Figure 46 - measure element 128

Figure 47 - Frequency Response Characterization 133

Figure 48 - IFOM Characterization 134

Figure 49 - Input-Output Transfer function Characterization 135

Figure 50 - ineas desc element 137

Figure 51 - encoding element 143

Figure 52 - Encoding of the Binary Data Stream 144

Figure 54 - Frequency Response Characterization 148

Figure 55 - ifom element 150

Figure 56 io_xfer_fcn element 155

Figure 57 ■ Frequency Response Characterization 159

Figure 58 - cal ref element 161

Figure 59 - dependency element 163

Figure 60 - position element 173

Figure 61 - attitude element 182

Figure 62 - coordinate element 187

Figure 63 - data element 195

List of Tables

Table 1 - Examples of Transducers 59

Table 2 - Example Ambiguity Shapes 65

Claims

What Is Claimed Is:

1 ,. A method for correlating raw transducer data in a system of transducers comprising the steps of: . . communicating transducer data in a common format ; characterizing the transducer data and relationships between transducers in a common format; . defining interdependend.es -of transducers for modeling a system; and time correlating . . the data from the various transducers. . .

2. A method for correlating raw transducer data in a system of transducers comprising the steps of: communicating transducer data in. a common format; ^" . characterizing the transducer data and relationships between transducers in a common format; . defining interdependences of transducers for modeling a system; expressing arbitrary properties and characteristics of transducers in a transducer characteristic frame; and ; . ■ time correlating the data from the various transducers. ■

3.. . A method for capturing and processing data generated from first and second dissimilar ■transducers each of which normally transmit data in respectively unique formats, said, method comprising the steps of causing aid first transducer to transmit data in a standardized hieraτchal format; causing said-second transducer to transmit data in said standardized hierarchal format; receiving said data in the form of said standardized hierarchal format from saiά first transducer; . receiving said data in the form of said standardized hierarchal format from said first transducer; and processing said all of said received data. . -

42