You are here

Common Software Foundation


OBJECTIVE: Design and development of a single software foundation that can be utilized in mobile/handheld, mounted, and command post environments. Software should be flexible enough to support a wide variety of mission needs and be extensible such that new capabilities can be added later by any development team. Intent is to develop a government owned solution, as a result preference will be placed on those solutions that do not use any proprietary or 3rd party licensed products. DESCRIPTION: Under the Common Operating Environment (COE) the Army is executing a number of efforts targeting collapse of solutions from dozens of hardware and software foundations to a handful of Computing Environments (CEs). This is being done in order to realize cost savings through reduced redundancy and increase interoperability. Three of those CEs are the Mobile/Handheld, Mounted, and Command Post. Currently those CE's are being developed somewhat independently. It is the intent of this SBIR to design (and ultimately build) a single foundation that could be utilized across those 3 environments. This effort is different from the current execution plan of the COE because we are seeking a single software foundation that can be leveraged across all 3 domains, not 3 different foundations. The foundation should be flexible enough so that while a common core is utilized across the 3 domains, different user interface components, varying screen sizes, and various states of connectivity (large, limited, no bandwidth) are supported. Additionally, the solution must have an associated Software Development Kit (SDK) that 3rd party groups can leverage to develop solutions. PHASE I: Research and design potential infrastructure solutions that could meet the objectives. The team will need to gather information regarding the capabilities and mission needs of systems in each domain to ensure that the proposed solution(s) can meet those requirements. Work with Subject Matter Experts (SMEs) from both the technical/development side as well as the tactical side to develop the concept designs. A prototype is not required during this Phase. PHASE II: After a selection is made on the approach, the team will implement the solution. By the end of year 1, the team will be expected to have a prototype solution in place that can work in all 3 environments and provides a limited set of capabilities. During year 2, the team will be expected to execute multiple experiments both in the lab and in operationally relevant environments to prove out the concept. The tests will not only be used to gather feedback from users, but also comments from developers with respect to the SDK. The Phase II final report must include major issues, risks, and problems associated with the solution as well as recommended approaches to fix those items. PHASE III: Take the product from a TRL 5 to a mature state such that it can be fielded or sold commercially. This means fixing all critical elements that were identified in Phase II, standing up a support infrastructure that can provide a mechanism for users to submit bugs and track new releases, and facilitating change requests/enhancements. The solution developed under this topic has direct applicability to the commercial world. This product could be licensed to 3rd party developers who wish to create software applications and maximize their potential user base. Rather than develop solutions specifically for a single handheld or desktop environment, they could utilize this product to write their application once and run it in multiple commercial operating environments. This would present them with a large cost savings for development and test as well as get their product to multiple markets faster. REFERENCES: 1. 2.
US Flag An Official Website of the United States Government