Figure 2-1 JASA Reference Model
| Previous | TOC | Next |
The JASA Reference Model (JRM) (See Figure 2-1) combines elements of the DoD Technical Reference Model (TRM) (software reference model) with the JASA FRM (hardware model) (See Figure 2-2). The DoD TRM is a general model representing the information processing entities (application software entity and application platform entity) and interfaces (application platform interfaces and external environment interfaces). The JASA FRM (See Figure 2-2) identifies the fundamental interfaces, modules and nodes to provide for flexibility and dynamic modularity. It is primarily a hardware system model which is further discussed in Appendix D.
Figure 2-1 JASA Reference Model
Figure 2-2 JASA Functional Reference Model
The JRM identifies three major areas: Front End Processing, Information Processing, and the Human Computer Interface. Front End Processing is not currently covered by the DoD TRM except as an External Environment Interface (EEI). Information Processing maps directly to the DoD TRM although some extensions are required. The Human Computer Interface is represented as an external environment entity on the DoD TRM.
The JRM also identifies three cross area services (cross area services effect one or more major areas): Information Transfer Services (e.g., networks), Security Services (e.g., multilevel guards), and Physical Services (e.g., backplanes). Information Transfer Services and Security Services map to the DoD TRM and JASA FRM. Physical Services are not included in the DoD TRM at this time.
In the JRM EEIs provide interfaces between Information Processing (represented as the application platform in the DoD TRM) and Front End Processing and the Human Computer Interface (represented as the external environment in the DoD TRM).
Front End Processing identifies the standards necessary for data capture, special preprocessing, digitization, wideband recording and distribution. It also identifies the standards necessary to deliver precision time and navigation data from the platform to the SIGINT sensor. It includes the RF and IF distribution, low band and high band tuners, digitizers, recorders, and processors for data capture and interface to Inertial Navigation System (INS), Global Positioning System (GPS), and atomic clock reference for precision time and navigation data. It also includes embedded information processing which has extreme real time/high bandwidth requirements. (See Chapter 3). Front End Processing is represented as Front End Processing and Navigation and Timing in the JASA FRM and is represented as the external environment in the DoD TRM.
Information Processing identifies the standards necessary for software and data interoperability, modularity and reuse. It includes software engineering services, user interface services, data management services, data interchange services, graphics services, communications services and operating system services. Information Processing also includes airborne SIGINT specific data formats and may include real time operating systems not currently addressed in the JTA (See Chapter 4). Information Processing maps directly to the DoD TRM.
The Human Computer Interface (HCI) identifies the standards and guidelines necessary to provide the operator a common "look and feel". A standard HCI with a common "look and feel" increases operator effectiveness and reduces operator training. (See Chapter 5)
Information Transfer Services are cross-area services with the identified standards, protocols, and interfaces necessary for seamless communications and data transfer. These services provide the interoperability and connectivity within and among airborne SIGINT platforms. These services include digital network services, data link interfaces and Reach Back, Reach Forward and Reach Between interfaces. The JASA FRM represents Information Transfer Services as the Data Flow Network, Command, Control, and Information (C2I) network, Multimedia networks, the data link/bridge and the reporting blocks. (See Chapter 6)
Security Services are cross-area services with the identified standards necessary to provide a seamless flow of information while protecting SIGINT-derived information. These services include multilevel trust, encrypted storage and data link encryption as well as authentication access control, etc. The TRM represents the Security Services as Information Systems Security. The JASA FRM only explicitly identifies Multilevel Guards (MLG) and encrypted storage for system security, although the other aspects addressed by the TRM are assumed. (See Chapter 7)
Physical Services are cross-area services with the identified standards necessary to integrate SIGINT sensors into an airborne environment. These services address environmental conditions and size, weight and power (SWAP) considerations unique to airborne SIGINT. These services include chassis, backplanes, circuit cards, power quality and environmental standards. Physical Services as defined here are unique to airborne SIGINT and do not map to the DoD TRM or the JASA FRM. (See Chapter 8)
The philosophy behind JASA is to develop a flexible, open architecture, which will support easy technology insertion to facilitate a responsive SIGINT system. Another tenet of JASA is to focus on a software implementation of a services based system, utilizing a hardware core based on commercial products, where possible. To be a cost effective modernization approach, software modules or hardware modules must be replaceable or insertable without substantial redevelopment. JASA Interface PointS (JIPS) provide access to resources, data, and functions, and provide standardized hardware and software insertion points. This provides for seamless insertion and permits use of organic resources and processing capabilities (e.g., control of beamforming, energy detection, tuning, etc.). The "modules" or functional blocks identified in the FRM, define an initial set of JIPS (See Figure 2-2). JIPS provides the capability to follow technology evolution and to accommodate custom developments when necessary. In the future there may be a need for high speed data transfer independent of the networks, shown in the FRM, that will require additional JIPS to be identified. There are three categories of JIPS: hardware, software and data exchange.
System designers, in keeping with the philosophy of maximizing interoperability, should make provisions for as many interface points as possible. The interface points should be designed to minimize degradation on system performance.
The initially identified hardware JIPS (e.g., RF, Analog and Digital IF, High Speed Data Network, LAN etc.) are the functional blocks and interchange points (networks, distribution blocks) identified in the FRM. Additionally, due to the board level COTS products available, JIPS need to be identified for modular growth within the functional blocks. For example, in the Digital Signal Processing (DSP) block, it is not unreasonable to expect that additional VME DSP boards may be added at some point within the chassis. Since future JSAF implementations will likely require auxiliary high speed data busses (rather than trying to pass high speed data streams over the VME bus), digital JIPS would be utilized. An example of a possible auxiliary high speed data bus is the ANSI/VITA standard RACEway Interlink (ANSI/VITA-5 1994).
Efforts on establishing a JASA COE for the real time (hard) processing are only beginning (See Chapter 4). The JASA COE will define software interface points to allow software instantiations of Quick Reaction Capabilities (QRCs). Software interface points are also referred to as Application Program Interfaces (APIs). These APIs allow new software functions or application programs to be added to the system without requiring major changes to the system software. As the service based system matures, software function/application insertion will be the preferred solution for QRCs and planned upgrades.
Technology is moving to an information based world, where interoperability of systems is essential. In order for data to be collected at one point and processed by various modules in parallel, and the information gleaned to be considered in total by other modules, data exchange JIPS (which may be ICDs) need to be identified. Common data formats for modules must be established at the JIPS to allow the addition/replacement of functions/modules. This needs to be established for not only reports and databases, but also for signal processing modules. This will permit access to intermediate processing results, raw data, resource management, system control set, etc. For instance, for modules to access the digitized pre-D data, the protocols, timing and data formats for the data flow network and any high speed data busses need to be established, controlled and made available to future developers.
To better illustrate the JIPS intent, this section discusses two methods of implementing a particular capability, call it "D". This is not intended to be definitive or restrictive, but simply one specific example to help convey the concept.
The first method focuses on the traditional hardware oriented approach. Figure 2-3shows the signal data flow and the operator software flow from a FRM perspective while Figure 2-4 shows them from a JRM perspective. Illustrated is the RF distribution as it flows through the tuners and down to the data flow network (dotted trace). The software flow is shown as the operator initiates the collection from the workstation (dashed trace). This allocates the assets, passing the application software and parameter values from the servers, databases, and encrypted storage to the allocated System Processing and Control (SPC) asset. The SPC controls the allocated DSP assets, interfaces with the rest of the system, and returns status and signal related information to the operator's workstation. In this particular case, the processing complexity is such that it is sequentially routed through multiple DSP assets (beamformer function, demodulation function, parameter measurement function, etc.). The information is then passed over the multimedia network and data link/bridge to the operator at the workstation.
Figure 2-3 FRM View of Implementing "D", First Method
The first method requires detailed knowledge of the Resource Management structure (control set), Resource Allocation, and System Architecture therefore complicating the interface process.
In the second method, the same capability "D" is implemented utilizing existing hardware assets and software functions. Instead of requesting the hardware assets (tuner channel, DSP, etc.) and controlling them directly, the "D" application program generates software calls to existing software modules, requesting the data from frequency F1 at time T1, processed through the beamformer and the demodulator to be provided to its own process.
Figure 2-4 JRM View of Implementing "D", First Method
The second method relies upon software calls to the SPC module (See Figure 2-5). For example, the "D" operator may tune a receiver by simply using a 'tune call'. The SPC module interprets this call and commands the tuner to tune to frequency F1 and time T1. The intermediate command sequence is transparent to the "D" operator.
Thus, instead of needing intimate knowledge of the asset allocation technique, the tuners, etc., the developer only needs the CALL parameters and rules, simplifying development of the new function "D" and reusing existing code. By having standardized data formats, multiple independent services (functions) may be linked together to quickly and cleanly implement complex processing chains.
Figure 2-5 FRM View of Implementing "D", Second Method
| Previous | TOC | Next |