ESC/DIA; 45 Arnold Street, Bldg. 1600; Hanscom AFB, MA 01731-2102

58 -- LINK-16 LOW COST INTEGRATION APPROACHES, REQUEST FOR INFORMATION SOL F19628-99-T-0001 DUE 031599 POC POC: Jewel A. Lee,Contract Specialist (781) 377-3993; Kent Kinal, Contracting Officer, (781) 377-7061 WEB: n/a, n/a. E-MAIL: Click Here to E-mail the POC, leeje@hanscom.af.mil. 1. The U.S. Air Force Electronics System Center, Global Awareness Product Area Directorate, is issuing this RFI to industry to identify cost effective common software approaches to integrate Link 16 capability onto future Air Force systems. Primary systems being considered include bombers ( B-1B, B-2, B-52) and the F-117. Other potential systems include Special Operation Forces (SOF) and future C2 aircraft and ground systems. The main purpose of this RFI is the exploration of common Link 16 software approaches and the tradeoffs associated with placing such software and associated hardware outside of the host platform's Operational Flight Program (OFP). 2. Previous integration of Link 16 into host platforms has incurred significant impacts to host platform computers. Experience has shown that there is a common set of functions that must be performed by every host platform in which Link 16 is integrated. These typical functions are identified as follows: (a) The host must control the interface between itself and the terminal, using the protocols of the particular data bus involved; (b) The host must initialize the terminal, control operating modes of the terminal, monitor terminal status, run BIT and extract data from the terminal; (c) The data obtained from the terminal in the form of TADIL J messages, must be checked for validity, the messages parsed, and the data entered into appropriate databases for further processing and display; (d) Additional message/data filtering beyond that performed by the terminal is usually needed to reduce the data to an amount that can be reasonably displayed; (e) The host must also read the terminal initialization data provided by the Air Force JTIDS Network Design Facility, provide a means for altering and adding parameters, and convert the data to a format accepted by the terminal. 3. The Air Force believes that significant Link 16 development and life cycle cost savings can be realized by encouraging experienced Link 16 software developers to team with experienced system integrators to develop low cost integration approaches. To achieve that end, the Air Force is seeking sources that have developed or are developing common Link 16 software that could be candidates for meeting the Air Force's Link 16 Low Cost Integration objectives. 4. The objective of this planned program is to identify common processing and associated hardware to provide an interface between the Link 16 terminal and the existing data busses, computers, and displays of Link 16 equipped Air Force platforms. In addition, this approach should be capable of standalone operation to provide situational awareness (with the addition of suitable hardware, displays, disk drives, keyboard, etc.) for platforms that do not currently have suitable display and data entry capabilities. The objective is to make this common software as configurable, extensible and re-usable as possible so that it can be used on multiple platforms with minimal change and cost impact. Common software objectives are as follows: (a) Software should be compliant with the relevant requirements of the Joint Technical Architecture (JTA). The current version of the JTA, Version 2.0, is available at the DISA Web site at http://www-jta.itsi.disa.mil/. If the proposed approach is not planned to be JTA compliant, deviations should be justified based upon the cost, schedule, or performance impact that compliance would impose; (b) Software should be at least Level 5 compliant with the Defense Information Infrastructure (DII) Common Operating Environment (COE) Integration and Run-time Specification (I&RTS). Information on the DII COE is available at DISA's homepage at http://spider.osfl.disa.mil/dii/. It is recognized that the Link 16 common software may require real-time processing and diagnostics capabilities not yet in the DII COE. A real-time DII COE working group has been established to address those issues and contractors are encouraged to work with that working group to ensure that their products will be compliant as the RT DII COE matures. LtCol Robillard, ESC/AWW, Chairs the DII/COE Real Time IPT and information on related meetings and available briefings may be found at the following WEB Site: http://www.dii-af.hanscom.af.mil/infrastructure/coe/rtipt/rtipt_hm.htm; (c) An open interface design language should be used for software interfaces to support the addition of software modules; (d) An open data communications technology and standardized protocols should be employed where applicable; (e) An open interface for the exchange of messages between applications and between applications and services should be provided; (f) An open standard, DII COE compliant, windowing system should be used as a user service; (g) The use of legacy software, commercial off-the-shelf software (COTS), and government off-the-shelf software (GOTS) is encouraged. This software may have to be wrapped in a layer of software to provide an open interface that is interoperable and complies with the common software architecture; (h) To overcome the risk of design obsolescence, the common software architecture should be independent of both hardware and operating system; (i) The common software should be compatible with standard processors, e.g. Intel Pentium, Motorola Power PC, and DEC Alpha. Use of standard processors and a bus architecture enhances compatibility with future processors, memory devices, I/O cards, etc. 5. The Air Force is seeking a strategy that provides for both commonality and minimal impact to host computer/processing systems. It is requested that interested parties respond to this RFI by 15 March 99, 2:00 PM EST; submittal via E-Mail may be addressed to 'leeje@hanscom.af.mil'. Your response should focus on the above listed guidelines and objectives. Your response will be held confidential and will not bind you in any way. If a Request for Proposal (RFP) results, Best Value Source Selection procedures will be utilized for evaluation purposes. All proposals will be required to demonstrate a complete understanding of the requirements and provide a detailed plan of execution. 6. Responses to this RFI shall not exceed twenty-five (25) pages. Responses to this RFI shall include the following information: (a) Description of proposed approach including how the approach can be tailored to accommodate a variety of host platform architectures, e.g., single or multiple buses, MIL- STD-1553, TCP/IP, and Ethernet; (b) Description of existing products that would support proposed approach; (c) Brief description of capabilities that are included in the proposed products and how they work (including any performance specifications on track load, data latency, response times, etc); (d) Description of how proposed approach would meet the design objectives for common software listed above; (e) Description of proposed work plan for working with up to three host platform prime contractors and the Link 16 Generic Integration Working Group to develop Link 16 integration design(s) using proposed common software approach. This work plan shall include a Rough Order of Magnitude (ROM) estimate of the cost and schedule for this activity; (f) Summary of respondent's Link 16 software development experience. 6. In addition to the above information, respondents are invited to describe any other approaches that could reduce the cost of Link 16 integration. 7. Respondents may be invited to schedule a briefing with ESC/DIAJ at some future, mutually agreeable upon date to provide further information on their approach. The briefing and discussions should not exceed 4 hours. Posted 02/02/99 (D-SN293856). (0033)

Loren Data Corp. http://www.ld.com (SYN# 0280 19990204\58-0001.SOL)