A -- DISTRIBUTED COLLABORATIVE ENGINEERING ENVIRONMENT The Advanced Information Technology branch of the Naval Research Laboratory is interested in soliciting white papers for the development of a distributed collaborative engineering environment (CEE) for Navy systems aggregated to the level of a Battle Group or Battle Force. The speed and complexity of modern warfare requires that Battle Groups no longer be considered an aggregation of discrete systems (ships and aircraft). To be effective the Battle Group as a whole must be treated as a "System of Systems (SoS)" with all the parts (ships and aircraft) fully integrated and mutually supportive of the whole. The CEE envisioned would be a major element in a Navy pilot effort to implement a Distributed Engineering Plant (DEP) to address interoperability issues across the acquisition cycle for Navy Battle Groups and the participation of those Battle Groups in Joint (Army, Navy and Air Force) and Allied operations. Currently, complex combat and communications systems are developed and tested in the context of a specific ship class or aircraft type. The support for the different ship and aircraft types that constitute a battle group occurs at several government and commercial facilities across the US. Each of these facilities have the capabilities for developing and testing their individual respective systems; however, the first time these ships and aircraft are brought together for interoperability testing as a "System of Systems (SoS)" is when the Battle Group is constituted at sea. Testing in live Battle Groups at sea detracts from other training and operational requirements as well as being costly and not very efficient. Integration and testing of discrete systems before introduction into the Battle Group as a top level SoS is difficult in view of the significant investment in and distributed nature of the facilities across the US where the ships, aircraft and their components are developed and built. The concept of a Distributed Engineering Plant (DEP) is to take advantage of newly emerging network technology and link together major Navy ship, aircraft and commercial facilities across the US to allow Battle Group level development and testing of actual hardware in the loop before that equipment is actually introduced into ships or the ships are brought together at sea. The intent of the DEP is to bring together all of the actual components and intended software loads for a given Battle Group, build a virtual replication of the Battle Group across the network with existing facilities, then test and address interoperability issues a year or more before the Battle Group deploys for operational duty. Battle Group and Battle Force (BG/BF) interoperability must be "engineered-in". The current fiscal environment allows for little flexibility in coping with interoperability issues identified late in the development cycle. The DEP is intended for the conduct of Battle Group systems engineering which over-arches individual system design efforts and ensures that full scale, collaborative, distributed "force level interoperability engineering" occurs in every phase of the development process for a new or modified capability. The DEP consists of three architectural layers. They are the Common (Simulation/Stimulation) Environment (SEE) Layer, the Tactical Communications Environment (TCE) Layer, and the Collaborative Engineering Environment (CEE) Layer. The Collaborative Engineering Environment (CEE), as an element of the DEP, is the tool set for the developers and engineers at the geographically dispersed DEP sites to work efficiently together to achieve effective SoS Battle Group capabilities. The first steps in implementing a pilot DEP were completed 15 November 1998 with the integration of Navy facilities at San Diego, CA; Dam Neck, VA; Wallops Island, VA; and Dahlgren, VA across a high speed Asynchronous Transfer Mode (ATM) network. Initial use of the DEP will be for interoperability testing of near term deploying Battle Groups. Extending the DEP to address issues across the full acquisition cycle will require far more comprehensive CEE capabilities than are readily available today. The intent of this BAA is to solicit prospective approaches for both near and long term CEE needs. A Navy task force was assembled in April 1998 to assess Fleet interoperability issues and the feasibility of a DEP for addressing those issues. The task force report was completed in June 1998. The result of the task force effort, Distributed Engineering Plant (DEP) Final Report (Book I and II) should be used as a reference and can be accessed at: http://enterprise.csci-va.com/root/detf.htm the user id is "deplant", and the password is "interop101". As described above, the CEE is one of three layers envisioned in the DEP. The scope of this BAA is limited to that tasking which will result in implementing and sustaining the CEE as an integrated element of the DEP. This tasking is inclusive of all efforts to enable the operating processes, infrastructure and technical requirements for the CEE. As a part of the overall DEP Concept of Operation, the CEE is to provide a collaborative environment for the government and it's industrial partners to conduct system engineering in all phases of the system acquisition lifecycle. This includes requirements generation, design, development, test and evaluation and fleet support. Notionally, the CEE should possess the following types of functional attributes as part of the DEP Concept of Operation: Allow all or selectable members to have access (as authorized) to a shared view of the program/system/system of system status Support maintaining documentation and software under configuration control with traceability and archiving of changes. Notification of updates to be automatically forwarded to members. Shared databases and files to allow check out of documents, computer software or information by authorized members from any site using their personal computers Electronic document versions including proposals, reviews, calendars specifications, requirements, schedules, meeting minutes, e-mail, action items, CAD drawings,visualizations, data bases, reports, briefings, etc. to be available to authorized members on a "demand-pull" basis. Accommodate remotely activated applications (e.g. simulation model, remote compiling/patching of software and data extraction) Allow members to view, discuss and generate documents with each other using desktop VTC capabilities. The goal of the DEP is not solely to find problems, the goal is to create an environment which enables requirements generation and iterative design and development of each system and "System of Systems" in such a manner that there are minimal problems once the systems are developed and deployed, i.e., "engineered-in" interoperability. Because today's warfighting systems are so complex and so software intensive, the benefits of a DEP are greatest in the early stage of the acquisition cycle. The DEP enables: " Distributed design and development of software, " Verification, validation and accreditation " Integration of elements with the overall system " Networking of geographically dispersed combat systems, and " Bringing together the appropriate elements of the "Talent Base" without moving the people An enabler of "Collaborative Engineering" can be defined as: the performance of engineering functions and activities through "sharing" of information, databases, tools and analytical models by geographically dispersed engineering teams. During the Requirement Phase of the Acquisition Cycle, the DEP can be used to develop Concepts of Operations and notional prototypes. Operational requirements can be demonstrated via the use of modeling and simulation tools. In the Design Phase, the DEP continues to support collaboration. During system design, top level software and system design issues are addressed. Inter-system and inter-function communication methods among different combat systems can be defined to ensure the Navy Battle Group or Battle Force interoperability requirements are implemented. In the Development Phase, the DEP continues to support collaboration and provides a common environment as outlined in the previous phases. In the development stage, the functionality of the combat system previously represented by models transitions to the developed software units and hardware elements. In the T&E Phase, the DEP supports collaboration and provides a common Virtual Enterprise environment as discussed in the previous phases. Integrated T&E from system stand-alone tests to multi-system Battle Group/ Battle Force tests are needed to ensure Battle Force Interoperability of critical combat and communication element. In the T&E phase a virtual "Battle Group in the Sand" is instantiated across the wide area networks to identify and correct most interoperability issues before the individual systems go to sea The DEP in the Fleet Support phase provides the CEE with the virtual enterprise services as discussed previously. The CEE is able to capture the experience data from the fleet in terms of Trouble Reports (TRs), casualty reports (CASREPs) and other experience reporting from operations and training functions that occur in the fleet support phase. The 'Plant' has the significant capability to configure the exact BG/BF baselines and replicate reported interoperability problems. Conceptually, the CEE can be thought of as providing the following notional functions: unified workspace, Authentication agent, Database engine, Presence Factory, Context Factory, Notification agent, transformation and transportation mechanisms. The concept of unified workspace allows for a seamless management of shared data resources located throughout the enterprise along with an intuitive, cohesive and context-sensitive view whereby people and components can interact, communicate and collaborate. The authentication agent confirms the identity of system users or agents and generates a unique session key which can be used for database access, document downloads, etc. Database engines provide a means for incorporating distributed relational and object databases. A Presence Factory generates and delivers a personalized interface to remote users. A context factor centrally maintains context specific information. A notification agent routes messages between participants. The transformation mechanism is responsible for translating documents between different formats, while the transportation subsystem is responsible for distributing the necessary data over the collaborative enterprise. Embedded within these aforementioned concepts are the capabilities to communicate (notifications, real time discussions including audio, video, white boards or other shared resources), create and generate documents (e.g. requirement specification, interface specification, test plan, test report, etc.) with people at distributed sites; manage and control documents (proposals & reviews, meeting minutes, engineering documents, multimedia documents, financial documents, project management documents, configuration management) with different privileges; collaborate (distributed workspace, annotation), access data repositories(transparency, distributed, tracking), and provide a feeling of location independence, round the clock access, and on-line help. Potential offerors are encouraged to submit white papers. Each white paper shall include no more than 50 pages of technical information to include: 1. Description of project including expected deliverables, product goals, etc. 2. Evidence of proven technology 3. Technical approach including risk mitigation 4. Planned schedule, milestone, deliverables 5. Proposed cost estimate 6. Experience of key personnel and submitting organization, related experience, capability, facilities, etc. White paper responses should include but not be limited to: (1) a definition of technologies being proposed for the CEE along with their associated cost and an estimation of cost and performance uncertainty/risk; (2) a description of the proposed CEE should address force level interoperability engineering objectives occurring in every phase (Requirement, Design, Development, Test & Evaluation, and Fleet Support) of the acquisition process; (3) an assessment discussion of critical issues that must be overcome to achieve the interoperability engineering objectives; and (4) a discussion of government and DEP Collaborative Engineering Environment Layer (CEE) industry team's accessibility to the technology . Potential offerors should address all areas listed in this BAA. If several approaches are proposed, they should be costed separately. White paper shall contain a Table of Contents and it shall be prepared in the following format: 8.5 x 11 inches, 1.5 or double spaced margins not less than one inch at least 12 point type numbered pages one sided printing no foldout pages are permitted Submitters of white papers found to have technical merit in accordance with the technical evaluation criteria will be invited to submit full technical and cost proposals. NRL will respond in writing indicating whether a full proposal is requested and the date due. Format of full proposals will be provided at that time. Such invitation does not assure that the submitting organization will be awarded a subsequent contract, cooperative agreement or other transaction. Address white paper written in MS Word (2 hard copies with 1 electronic copy in disk) to Mr. Henry Ng (e-mail: ng@ait.nrl.navy.mil), Naval Research Lab, Code 5585, 4555 Overlook Ave., SW. Washington DC 20375 . Allow one month before requesting confirmation of receipt of white paper, if confirmation is desired. For clarification of requirements concerning this BAA contact Mr. Ng at 202-767-6023. Substantive contact should not take place prior to evaluation of the white paper by NRL. NRL will initiate substantive contact. This notice constitutes NRL's Broad Agency Announcement as contemplated in FAR 6.102 (d)(2). No Request For Proposal (RFP), solicitation or other announcement of this opportunity will be made. Awards may take the form of contracts, grants or cooperative agreements. For awards made as contracts the socio-economic merits of each proposal willbe evaluated based on the commitment to provide meaningful subcontracting opportunities for small business, small disadvantaged business, women-owned business concerns, historically black colleges and universities, and minority institutions. This competition is considered full and open. RESTRICTION ON DISCLOSURE AND USE OF DATA Offerors will apply the restrictive notice prescription of FAR 52.215-12, Restriction on Disclosure and Use of Data, to trade secrets or privileged commercial and financial information contained in their proposals. It is the Navy's intention to procure data rights in connection with contracts awarded under this BAA. COLLABORATIVE ENGINEERING ENVIRONMENT (CEE) AWARD CONSIDERATIONS The selection of proposals for contract award will be based on a technical review of white papers and proposals submitted in response to the BAA. The major purpose of the evaluation will be to determine the relative merit of the technical approach of each proposal. Business and contractual aspects, includingproposed cost and cost realism, will also be considered as part of the evaluation. Selection of proposals for award shall be based upon the potential benefits to the Government weighed against the cost of the proposals, in view of the availability of funds. Specific evaluation criteria are as follows: (1) The quality and technical merit of the offeror's CEE technical solution, including: (a) the feasibility and soundness of the proposed technical approach; (b) the degree of innovation of the proposed technical approach and potential for revolutionary advance; and (c) awareness of the state-of-the-art and an understanding of the scope of the CEE problem and the technical effort needed to address it. (2) The offeror's ability to implement the proposed approach as demonstrated by: (a) specific accomplishments in the technical field to be studied; (b) the quality and quantity of technical personnel proposed and their availability for the duration of the contract, and (c) adequacy of the proposed hardware and software infrastructure. (3) The degree to which technical data and/or computer software developed under the proposed contract are to be delivered to the NRL with rights compatible with NRL and NAVSEA research and development objectives. (4) Proposed cost and cost realism. THE GOVERNMENT RESERVES THE RIGHT TO SELECT FOR AWARD ANY, ALL, PART, OR NONE OF THE RESPONSES RECEIVED. Certain proposals are not appropriate under this BAA and are not desired. Engineering and technical services proposals are not appropriate. These usually involve applying effort toward a broadly identified task, often on a level-of-effort basis, rather than delivery of an end item (such as a final research report). Some projects are too mature to be performed under BAA authority; as a general rule, efforts subsequent to proof of concept and validation of technology are too mature. For example, it would not be appropriate under this BAA to modify existing products to fulfill specific requirements or to test products to determine their suitability for a specific application. Deliverables should demonstrate the results of scientific study and experimentation, rather than focus on a specific system or hardware solution. NRL is not interested, under its Broad Agency Announcement program, in concepts that have already been developed or proven (even if they have never been sold before), nor are proposals for evolutionary engineering of improvements appropriate under BAA authority. These cautions apply to all BAA topics. Please note that some efforts prior to proof of concept and validation of technology may also be too mature. A determination of appropriateness will be made on a case-by-case basis. The following notice applies to institutions of higher education that are prospective recipients of grants or cooperative agreements under this BAA: "This is to notify potential proposers that each grant or cooperative agreement that is awarded under this announcement or solicitation to an institution of higher education must include the following clause: "As a condition for receipt of funds available to the Department of Defense (DoD) under this award, the recipient agrees that it is not an institution that has a policy of denying, and that it is not an institution that effectively prevents the Secretary of Defense from obtaining for military recruiting purposes: (A) entry to campuses or access to students on campuses; or (B) access to directory information pertaining to students. If the recipient is determined, using procedures established by the Secretary of Defense to implement section 558 of Public Law 103-337 (1994), to be such an institution during the period of performance of this agreement, and therefore to be in breach of this clause, the Government will cease all payments of DoD funds under this agreement and all other DoD grants and cooperative agreements, and it may suspend or terminate such grants and agreements unilaterally for material failure to comply with the terms and conditions of award." "If your institution has been identified under the procedures established by the Secretary of Defense to implement section 558, then: (1) no funds available to DoD may be provided to your institution through any grant, including any existing grant; (2) as a matter of policy, this restriction also applies to any cooperative agreement; and (3) your institution is not eli E-MAIL: Click here to contact the Contracting Officer via, synopsis@contracts.nrl.navy.mil. Posted 12/18/98 (W-SN281707).

Loren Data Corp. http://www.ld.com (SYN# 0307 19981222\SP-0014.MSC)