INTEGRATED ARCHITECTURE BEHAVIOR MODEL (IABM) REQUEST FOR INFORMATION BY JOINT SINGLE INTEGRATED AIR PICTURE (SIAP) SYSTEM ENGINEERING OFFICE (JSSEO)

Document Type: Request for Information Solicitation Number:N00024-04-R-5102 Posted Date:01 November 2003 Original Request Date: 01 November 2003 Original Archive Date: Current Archive Date: Classification code:A-Research and Development ************************************************************ Points of Contact JSSEO Technical: CDR James Stein +1 (555) 000-0000; contact@example.gov; NAVSEA Contracts: LCDR Kristin Acquavella +1 (555) 000-0000; contact@example.gov ************************************************************ A REQUEST FOR INFORMATION (RFI) RELEVANT TO RAPID INNOVATION ASSESSMENT, EVALUATION, INTEGRATION, AND FIELDING OF JOINT TACTICAL BATTLE MANAGEMENT AND COMMAND AND CONTROL (BMC2) FUNCTIONALITY FOR AEROSPACE WARFARE: Overview: The Joint Single Integrated Air Picture (SIAP) System Engineering Organization (JSSEO) announces it s process for fostering innovation in the development of the SIAP Integrated Architecture Behavior Model (IABM). The IABM is an automated specification, in the form of a computer program written in executable UML, using the Object Management Group's (OMG) Model Driven Architecture (MDA) . The IABM, when integrated in elements of the Department of Defense (DoD) joint tactical integrated air and missile defense portfolio, will improve critical combat capabilities by: - reducing the risk of fratricide; - opening up the battle space to employ weapons to their designed kinematic range; and - supporting the capability to counter emerging threats Application computer programs that develop a mutually consistent distributed database within a distributed, peer-to-peer network will improve tactical battle management and command and control for the aerospace warfare mission area. The Government has determined that the MDA approach produces a clear description of the behavior of individual peers in the peer-to-peer network, while facilitating effective communications with industry partners. Furthermore, the model-driven design of the IABM: - enables JSSEO to take adopt innovative concepts and algorithms, facilitated by a modular, open system design; - supports formal processes to evaluate the completeness and correctness of the iteratively developed IABM; and, - facilitates continuous and systematic testing of the IABM in the Joint Distributed Engineering Plant (JDEP) technical framework environment. To be successful, the IABM must take advantage of innovative concepts and algorithms that industry, academia, and government will share in a collaborative environment. The ability of the Government and industry partners to share and adapt in novative ideas provides a "best of breed" solution meeting near-term military needs and aligned with longer-term SIAP requirements and objectives. A collaborative approach further serves to enhance modular design, reduce time to field, and encourages early identification and adoption of the most innovative concepts and algorithms to improve joint warfighting capabilities. Process: Operational requirements for the SIAP capability are based on the Joint Requirements Oversight Council (JROC) validated Capstone Requirements Documents (i.e., Theater Air and Missile Defense (TAMD), Combat Identification (CID), and Global Information Grid (GIG)). Additional requirements sources include: - Operational Requirements Documents (ORD), Capability Development Documents (CDD), and Capability Production Documents (CPD) from the SIAP Partner Program Offices (e.g., AWACS, Patriot, E_2C, AEGIS); - Service Concepts of Link Employment (COLE); - The Operational Views of the TAMD Integrated Architecture; and, - DoD and Joint Staff directives and instructions. The JSSEO is working with the military services to develop operational threads (e.g., Targeting, Passive Defense/Early Warning, Integrated Combat Airspace Command and Control) that give the requirements an operational context within which to identify SIAP-relevant operational nodes, activities and data elements that can be traced back to the top-level operational requirements. These operational threads are used to update Operational Views (OV) constructed using the DoD Architecture Framework (DoD AF) as format guidance. The operational requirements are allocated to operational elements, such as operational nodes, activities, or data exchanges within these views. The OV's and the operational requireme nts trace will continue to be approved incrementally using established DoD processes. The IABM will be developed at two functional levels: a design for the distributed system and a design for the individual Peer Computing Program (PCP), the computer program that when implemented in Service systems provides the SIAP capability. System level requirements will be developed for the distributed system, and a correlation will be made between operational requirements and distributed system requirements. Distributed system requirements will be allocated to various system elements or functions. This will yield a requirements-based OV-to-System View (SV) mapping process. System requirements for the PCP will be derived to satisfy the set of distributed system requirements. There will also be several technical system requirements added to the IABM development process, including: - Joint Technical Architecture (see JTA, Version 5.0 dtd 4 Apr 03, at http://www-jta.itsi.disa.mil/); - Link-16 Single Link Interface Requirements Specification (SLIRS); - IABM functional baseline, functional architecture, and object model; - Global Information Grid (GIG) and Net-Centric Enterprise Services (NCES) Technical Standards; and, - SIAP Partner system requirements and specifications. The Government will use an automated toolset to maintain traceability between the architecture products and their allocated requirements, thus enabling export of system level requirements into the IABM computer program development environment for allocation to specific classes. The IABM will be developed using an iterative "spiral" type development process to enable the Government and industry partners to continuously develop and adapt the IABM to meet evolving military operatio nal and system needs. Incorporating lessons learned from the Navy's undersea warfare domain experience, four dominant management principles will guide development of the IABM: q Collaboration. To encourage innovation within a fair and objective framework, the JSSEO opens participation in the IABM development process to all potential contributors (with appropriate national security caveats). The JSSEO will fully disclose the emerging IABM baseline, enabling potential contributors to compare and contrast their ideas in the context of a complete, distributed system. q Peer Review. The JSSEO will use Government-led peer review groups composed of nationally recognized authorities with the most relevant technical expertise's. These groups actively seek the best algorithms and methods from industry, academia, and Government sources. The peer review groups will objectivel y evaluate potential contributions, providing information and recommendations to the Government lead to select the best alternatives. The peer review groups will assess products against near and longer-term SIAP and IABM requirements and development objectives. q Build-Test-Build/Operational Feedback. Warfighter/user review and feedback concerning the IABM is fundamental to development and fielding of an operationally suitable and operationally effective joint BMC2 capability. Operational feedback is established by several means, including analysis of Joint warfighter needs (e.g., TAMD CRD, CID CRD, GIG CRD, and Unified Joint Task List (UTJL)/Join Mission Essential Task Lists (JMETL)), after-action reports of military operations, training exercises and evaluations, and lessons-learned knowledge bases. Additionally, with the use of an operationally realistic test environm ent and a flexible computer model of the JTAMD Architecture, JSSEO JTAMD system performance can be benchmarked. To achieve and ensure consistency for each evaluation means, a Joint, community-approved, Defense Planning Guidance (DPG)-based operational context is required. Common Reference Scenarios (CRS's) provide this common operational environment and establish the baseline of system performance from the engineering level to the military utility level. The common operational context provides sufficient detail to support integrated air warfare M&S, Hardware In the Loops (HWIL) exercises, Operator In The Loop (OITL) exercises, and Live exercises. CRS development relies upon subject matter experts to represent the interests of individual service and agency initiatives and programs and an active process to authoritatively define operational architectures and requirements from the standpoint of joint operations. q Reduced Implementation Time. After initial deployment, the JSSEO will deliver to integrating system program managers an updated, improved-capability, configuration-controlled IABM every twenty-four (24) months. Rapid delivery of updated versions of the IABM ensures that the IABM will maintain technology currency and disciplined innovation insertion. Current Schedule: The current JSSEO schedule calls for design and engineering activities in FY04 to support a September 2005 release of IABM Configuration 05, with subsequent IABM releases approximately every 24 months. Key capabilities for Configuration 05 are the Track Management, Combat Identification, and Distributed Resource Management domains. Process Recommendation Submissions and Format: Process recommendations can be submitted in electronic mail or white paper format a nd shall be no longer than five (5) single sided pages (not including cover page), using minimum 10pt font with standard 1" margins and single line spacing. Electronic mail and white papers shall be identified as responses to Request for Information N00024-04-R-5102. Confirmation of receipt will be provided within seven (7) calendar days. Information submitted will be used by the Government for planning purposes only, and submitters shall not construe submission of information to the Government as a commitment by the Government to procure any items/services from the submitter, nor for the Government to pay the submitter for information submitted. The Government intends to follow this Request for Information with a formal BAA. , The BAA will include information concerning the Government's plans for potential contract award. During review of recommendations by the Government, submitters may be requested to provide for clarifying information. Unless otherwise notified in writing by the submitter, the Government will consider all information received in response to this Request for Information as non-proprietary. Any information received that the submitted asserts is proprietary shall be legibly and conspicuously marked with an appropriate legend. The Government may use all information submitted to the extent necessary to evaluate it. The Government will use properly marked proprietary information only for evaluation purposes and will not disclose, directly or indirectly, such information to any person, including potential evaluators, unless that person has been authorized by the submitter to receive such information. Recommendations to improve the process outlined in the Request for Information are welcome and l should be submitte d via electronic mail to both the technical and contractual points of contact (POCs) listed in this RFI nolater than Friday, 19 December 2003.