A -- Combat Convoy Mission Rehearsal Tool (CCMRT)

*** Updated Information*** Added 29 January 2008 It has been brought to our attention here at NAWCTSD that access to the www.gcss-af.com webpage is problematic in some instances. As such, the following documents have been attached to this posting: - RSOHeavy_MigrationGuide.doc - GCSS VDD 28Jan08.xls These documents provide the necessary background to fulfill the purposes of this request for information. Note: The government would ideally desire that the only software running outside the browser would be on the server side. However, the government is interested in other approaches as long as they do not require installation of software on the client machine that requires accreditation through AF SDC. Also, it has been brought to our attention that we abbreviated Megabyte as mb (which would be megabit) when it should have shown as MB. That happens only twice in the document--in paragraph A.3. *** End Update The Naval Air Warfare Center Training Systems Division (NAWCTSD), in support of the Air Force and the Navy, is considering development of a competitive acquisition strategy to provide United States armed forces personnel the capability to participate in massive multi-user, first-person perspective mission rehearsal for combat convoy missions over the web, using Internet Explorer as the client software. The target implementation environment is Global Combat Support System (GCSS) and will be initially deployed on GCSS-Air Force (GCSS-AF). The United States armed forces is interested in acquiring CCMRT to provide skills retention/enhancement training of all mission critical tasks/tactics, techniques, & procedures (TTP)/doctrine related to convoy operations, available to all military personnel over the services' portals (using GCSS). The Air Staff plans to establish a 24/7 server cluster within the Air Force network, which will host the system and provide interoperability and connectivity with other simulations and training systems. The software must be modular and provide tools for user community modification of scenarios, heuristics, evaluation criteria, and asset data (art, behavior, and physics/ballistics data for maps, terrain, structures, avatars, vehicles, equipment, weapons, etc). The goal is to build upon the framework used for this system to provide mission rehearsal or simulation capability for any Agile Combat Support role performed in the first-person, starting with a prototype combat convoy mission rehearsal tool as the initial application on the framework, with full GCSS-AF integration (Level IV), and with complete editing and intelligent tutoring capabilities. This begins with producing a proof of concept that can utilize a current standard Air Force computer as a web-server within a base's enclave (domain) to run the simulation for a limited number of clients within the enclave and include limited editing tools. The proof of concept must also be used on the GCSS-AF test range to assess GCSS-AF and typical Air Force NIPERNET lag/latency/bandwidth constraints and demonstrate the concept through the Air Force Portal. This approach is designed to build full capability while delivering interim capabilities to users parallel to the development of advanced capabilities and for the certification and accreditation process. The four individual elements of the CCMRT are as follows: a. Web client user application: a.1. Functionally, the client will provide the user a full-screen, first-person perspective simulation of dismounted and mounted operations for mission execution (similar to a first-person shooter game), yet also have capability to use simulated maps, briefing aids, and other mission planning and after action review tools in the third-person. It will allow users to control simulated equipment ranging from vehicles, weapons, computers, communications/radios, blue force trackers, and ISR feeds. It will allow users to perform any role in a convoy teole in a convoy team and switch roles on the fly, if necessary, and also allow users to perform roles of neutral civilians and enemy forces. Ideally, it will allow users to communicate with each other by voice, realistically simulating physical proximity, intercoms, and radios. Initially an alternate, simplified communication method will be required to capture graded events, until the software can assess user performance by interpreting the speech recognition data. The client will be scalable all the way from a single human participant operating with, against, and being evaluated by the computer, up to large teams operating with each other and training against human-controlled entities, and evaluated by humans. It must produce an engaging experience; the user-interface must allow real-time completion of required tasks. The default sequence of events will be mission planning, mission execution, and after action review. a.2. Technically, the client user application must operate in a military enterprise computing environment and be executable by users with minimal or no support required from Information Technology support staffs (personnel with admin rights on the local machine). It must meet DoD and service requirements for accreditation and certification, as well as be compatible with restraints such as Air Force Standard Desktop Configuration compliance. The client will provide an interface between the user, the server, and other users. It will render 3-D graphics and stereo audio, perform physics modeling for moving entities, collect user inputs from the keyboard, mouse, and microphone, and relay to the server. A mixture of 2-D and 3-D graphics can be used (i.e., vehicle interiors can be represented in a 2-D 360 degree panorama (with a different vantage point for each position in the vehicle), while exteriors are viewed through the vehicle windows in 3-D. Client will store simulation engine coding, physics models, and terrain/entity artwork and characteristics on the local machine. A modular approach will be used so that this data may be updated automatically each log-in or as required. Essentially, this node will serve as a graphics engine and communications interface. It will rely on the server to relay state data on the other entities, and will render the appropriate graphics according to the user's perspective (i.e., display entities within visual line-of sight of the user). It should take no longer than 30 minutes to perform initial execution of mobile code and data, assuming a 100kb/s or better connection. Code and data should persist on local machine and be accessible to all users so subsequent execution should take no more than 5 minutes for any user on that machine. a.3. Client user application minimum computer requirements: Client software will be Air Force Standard Desktop Configuration (SDC)-compliant and ideally will require minimal or no administrator support for initial setup and no administrator support for content updates. Graphics will run at a minimum resolution of 800 x 600 (extrapolated to full screen mode) with at least a 20 FPS refresh rate. Minimum client software/hardware requirements are Windows XP SP2, DirectX 9, Internet Explorer 6 (but forward compatible to Vista, DirectX 10, and Internet Explorer 7) running on at least a Pentium iii 1.0ghz with on board 3-D graphics, 16MB dedicated or shared video RAM and 256MB system RAM. A low-cost headset may be required if the client machine lacks adequate built-in 2-way audio. Client will require broadband connection. Users will authenticate with their DoD Common Access Cards (CAC) using the Air Force Portal/GCSS-AF's Reduced Sign On (RSO) function. Further digital encryption only required for transfer of user metrics. b. Web client instructor/editor application. b.1. Functionally, the client instructor/editor application will allow a human instructor to track the execution of a scenario and monitor activities through a scalable perspective ranging from a 2-D bird's eye view of everything happening, down to the actions of any particular user. It will also allow him to assemble an after action review and present it to the users online. The instructor/editor application will also provide a highly intuitive, powerful suite of editing tools. These tools must empower trusted Air Force military, civilian, and/or contracted personnel with intermediate computer skills to modify existing (or produce new) scenarios, terrain/entities artwork and characteristics (including physics, AI behaviors, etc.). It will also allow them to modify heuristics, training criteria, doctrine/TTP models, the Intelligent Tutor model (assessment criteria), and import multimedia. It will have direct read access to static databases and have the ability to push limited edits directly to selected users on a per-session basis, and/or push edits to a holding area on the server for possible global release by the CCMRT program office. The program office would also use this application for initial creation of scenarios and assets. b.2. Technically, the client instructor/editor application will mirror the constraints of the user application (see paragraph a.2). b.3. Client instructor/editor application minimum computer requirements will mirror the constraints of the user application (see paragraph a.3). c. Dynamic Server cluster. c.1. Functionally, the dynamic server cluster will require the following capabilities: Execute multiple simultaneous simulation sessions (control the simulation for the clients and perform the resource-intensive operations). Ability to provide Scenario Control, Behavior Control, Data Collection (user training/performance metrics), Speech Recognition, Assessment (intelligent tutoring/coaching), Feedback (robust automated after action review with team and individual performance assessment), VOIP Hub, Communications (DIS/HLA/SCORM) to allow interoperability with other simulations and learning management systems. The server will include a website on the Air Force Portal to serve as a "lobby" to schedule sessions, for trainers and supervisors to access detailed user metrics, and to post a "scoreboard" so users can see where they stand with an aggregated, cumulative "score". c.2. Technically, the dynamic server cluster will reside within the GCSS-AF server farm. It must work around challenges such as lag and latency within the Air Force NIPRNET. All communications will travel through this hub and spoke topography, there will be no peer-to-peer communications. System must have capability for constant 2-way data transmission without incurring lags caused by starting and stopping connections. User training/performance metrics will require a managed access control scheme to allow only the appropriate supervisors and trainers to view (and export to Excel) users' metrics. This data must be protected with 128-bit encryption. c.3. Dynamic server cluster computer requirements. Server-side software and hardware must comply with all GCSS-AF level-4 compliance requirements, to include architecture, information assurance accreditation, etc. See www.gcss-af.com for details. d. Static data servers. Data that stays relatively static will be distributed geographically on the ?Edge? using GCSS-AF Akamai edge server technology to speed downloads. d.2. Technically, the static data servers will reside on GCSS-AF Akamai edge servers distributed throughout the Air Force Enterprise. They will synchronize new content at least daily. d.3. Static server cluster computer requirements. Server-side software and hardware must comply with all GCSS-AF level-4 compliance requirements, to include architecture, information assurance accreditation, etc. See www.gcss-af.com for details. Air Staff is interested in several categories of possible solutions for client-side delivery: a. Browser plug-ins already included in Standard Desktop Configuration (SDC) image, e.g., Flash Player 9.0.45.0, Shockwave Player 10.2.0.023, Windows Presentation Framework. b. ActiveX controls (packaged for SMS installation) to execute DirectX (may be written in XNA, if technically possible). c. Java (not java script). d. Browser plug-ins not already included in Standard Desktop Configuration (SDC) image. Air Staff may direct that the software emulate specific functionality of existing simulations and editing tools for inclusion in the prototype and production development. Additionally, Air Staff may direct the re-use of existing government-owned asset data. If so, these requirements will be identified in the statement of work and be contingent on government access to the code. Once identified, these requirements should not change. Air Staff prefers to purchase an open source solution, maximizing use of open source licensing models. A mixture of open source and proprietary modules may be necessary, but licensing for the proprietary modules must not be cost-prohibitive against providing web-based access to all users across the Air Force enterprise. Air Staff will provide access to combat convoy subject matter experts. Interested parties should provide a written statement of capability, using the prescribed format (font size 11, Times New Roman); not to exceed ten (10) pages (including cover page), addressing the following: a. General capabilities and experience in providing similar simulation systems. b. Identification of projected delivery date for proof of concept phase, to include alpha, beta, and code complete versions. c. Specific capabilities and experience with thin client/mobile code 3-D graphics, physics modeling (human, vehicles, ballistics, flight), entity artificial intelligence, speech recognition/evaluation, instructor operator stations, machinima, scenario generation, after action review, collective training and concurrency, intelligent tutoring/coaching. d. Subcontract management experience and potential teaming arrangements, if any. e. Licensing options. f. Include the company name, cage code, large or small business and primary point of contact including email address and telephone number. g. It is most critical to provide an alpha release demo within 60 days after contract award and final release of the proof of concept at the earliest possible date. Please address your capability to author software in the most expeditious manner possible and include projected/estimated production time from contract award to first delivery. Written statement of capabilities should be received by this office NLT COB 30 Jan 08. RESPONSE FORMAT Page 1: Cover Sheet - Company Name, Address, Cage Code, and Point of Contract including Phone Number and email Page 2: Capabilities and experience in providing similar services of this magnitude in a secure environment requiring clearances up to Secret level and projected delivery schedule (Not to exceed eight [8] pages); Page 3: Methodology for providing anticipated numbers of personnel; subcontracting management experience: (Not to exceed one [1] page) NAWCTSD is neither negotiating nor calling for proposals during this process. This RFI does not constitute a commitment on the part of the government to purchase or acquire services. All responses to this request for information are voluntary and the government will not reimburse travel or preparation expenses for this RFI.