Loren Data's FBO Daily™

fbodaily.com
Home Today's FBO Search Archives Numbered Notes CBD Archives Subscribe
FBO DAILY ISSUE OF SEPTEMBER 25, 2002 FBO #0297
MODIFICATION

A -- ADAPTIVE AND REFLECTIVE MIDDLEWARE SYSTEMS (ARMS) (Part 1 of 2)

Notice Date
9/23/2002
 
Notice Type
Modification
 
Contracting Office
Other Defense Agencies, Defense Advanced Research Projects Agency, Contracts Management Office, 3701 North Fairfax Drive, Arlington, VA, 22203-1714
 
ZIP Code
22203-1714
 
Solicitation Number
BAA02-24
 
Response Due
10/31/2002
 
Point of Contact
Douglas Schmidt, DARPA Program Manager, Phone 000-000-0000, Fax 703-696-4534, - Alan Frederick, Contracting Officer, Phone (703) 696-0047, Fax (703) 696-2208,
 
E-Mail Address
none, afrederick@darpa.mil
 
Description
This revised version of BAA02-24 supercedes the version posted on September 13, 2002. ADAPTIVE AND REFLECTIVE MIDDLEWARE SYSTEMS (ARMS), SOL BAA 02-24, DUE: 10/31/02; POC: DR. DOUGLAS C. SCHMIDT, DARPA/IXO; FAX: (703) 522-7161 PROGRAM SCOPE The objective of the ARMS program is to create technologies and tools that will dramatically simplify distributed real-time and embedded (DRE) middleware development, optimization, validation, and DoD combat systems. The middleware technologies and tools created in the ARMS program will focus on the challenging problems and risks associated with the development of a Total Ship Computing Environment (TSCE) in the DD(X) Future Surface Combatant Family of Ships. The TSCE will be a fully integrated open system computing and information architecture that executes all tasks and mission applications optimized at the platform level, rather than the sub-system level, thus breaking down the traditional C4ISR, Combat Systems, and Ship Control System boundaries. ARMS technologies and tools will allow researchers and DD(X) system integrators to develop and evolve complex DRE combat systems assuredly, adaptively, and affordably by: ? Supporting dynamic allocation and migration of DRE applications with their associated security level across a wide array of general-purpose computing resources to maximize survivability and mission availability in the face of equipment failure, battle damage, software failures, and information warfare attacks ? Standardizing COTS at the middleware level (rather than just at lower hardware/networks/OS levels) ? Devising meta-programmable DRE framework techniques and optimizations, as well as secure multi-level distributed dynamic resource management protocols/services for adaptive and reflective middleware that will enable DoD DRE systems to customize standard COTS interfaces, without the performance and flexibility penalties incurred by conventional COTS implementations and ? Building middleware services that enable applications to be independent of the particular resource management protocols, security policies, and fault tolerant mechanisms required. For this BAA, there are two proposal categories, "Technology Developer" and "OEP Developer". An organization may submit multiple proposals in each proposal category, however an organization's eligibility for funding is restricted to one of these categories. OEP Developer The OEP Developer supplies the ARMS program with specific challenge problems that describe the current operational state in the TSCE domain and describe quantifiable performance-oriented goals that will enable significant increases in overall domain performance, but also require significant technological innovation to realize. The OEP Developer will integrate ARMS technologies into the TSCE testbed as an objective evaluator, conduct formal experiments, analyze results, and feed recommendations back to the Technology Developers (TDs). The OEP Developer will be the liaison between the TDs and the DD(X) Design Agent, and is responsible for conveying the DD(X) requirements, risks, complex computing system problems and other development needs to the TDs and for ensuring the TDs are addressing these needs. The OEP Developer will establish an Integrated Data Environment (IDE). This IDE will allow DARPA, the DD(X) Program Office, DD(X) Design Agent, and other DARPA approved Government laboratories remote digital access to ARMS Program documentation, software, and other developed technologies to facilitate the open communication and transition of information and technologies to the DD(X) Design Agent. A primary emphasis of the OEP Developer experimental evaluation is the Quality of Service (QoS) of the ARMS DRE middleware. In that capacity, the ARMS OEP Developer will devise and validate methods and tools for evaluating the aggregate QoS of the ARMS DRE middleware and representative TSCE applications in terms of their latency/jitter, throughput, scalability, adaptability, stability, dependability, security, and static/dynamic reflective optimization capabilities. The OEP Developer will make the challenge problems, applications, and the integrated testbed itself accessible for all the TDs in the ARMS program. Proposers in the OEP Developer category must propose a software test platform consistent with the TSCE concept described in the ARMS Program Background section, as well as specific challenge problems on which objective evaluation will be based. Offerors for OEP Developer should demonstrate an ability to integrate ARMS tools into integrated end-to-end development scenarios and perform rigorous testing and evaluation of the resulting design frameworks. Proposals in the OEP Developer area must delineate the constraints and performance drivers and must suggest test and evaluation methodologies for ARMS experiments based on their OEP. It is anticipated that at most two OEP proposals will be selected for possible funding. Technology Developer Proposals are also solicited in two topical areas in the "Technology Developer" (TD) research category in the context of the testbed provided by the OEP Developer described above. The two TD topical areas are described below: Topic 1. Meta-programmable DRE Middleware Frameworks DARPA is seeking proposals that will develop new theory, framework technologies, and tools for applying meta-programming techniques to DRE middleware and applications. Meta-programming involves policies and mechanisms that systematically decouple the functional path of an application from its various cross-cutting QoS properties and resources by decomposing the system into: ? Base-components, which implement certain application functionality (such as sensor processing, tracking, and weapons release/control) and ? Meta-components, which abstract key QoS properties (such as persistence, concurrency, scheduling priorities, atomicity, ordering, state, replication, and change notifications) from base-objects and control many aspects of their behavior adaptively and reflectively at run-time. Proposers of new meta-programmable DRE frameworks should demonstrate expertise in one or more areas of interest to DoD combat system developers, such as time/space constraints, real-time QoS goals, cross-cutting aspects (such as security, predictability, and dependability), and open middleware standards. Proposers should focus on demonstrating their expertise in the context of concrete DRE middleware for DoD combat systems. Proposers must show how they can interface their frameworks with other ARMS components through common interface languages and knowledge representations, such as those based on UML/OCL, XML, Rational Rose, CORBA IDL, and others (such as those developed on the DARPA MoBIES project). The interfaces and functional semantics of all meta-programmable DRE frameworks must be provided in open, extensible, well-documented formats, compliant with the middleware standards ARMS is developing and leveraging. Frameworks developed for ARMS will be evaluated heavily on the ease with which they can be integrated with other frameworks and with standards-based meta-programmable middleware environments, such as the OMG Model Driven Architecture (MDA) efforts. Proposals for meta-programmable DRE middleware frameworks should contain a description of their candidate middleware architecture, identify policies (explicitly or implicitly) on how data and resources it owns are used, document external and internal dependencies/constraints imposed, as well as rational of proposed middleware architecture and the process via which other ARMS Technology and OEP Developers will integrate their technologies with it. The product of projects in this area should be capable of being transitioned to the middleware software market in the form of open protocols and interface standards. Proposers in this area should also be able to work with and participate in standards bodies, such as the OMG or The Open Group, that are defining the protocols and interfaces necessary for DRE middleware interoperability. It is anticipated that no more than four proposals will be selected in this area for possible funding and teaming is encouraged. Topic 2. Secure Multi-level Distributed Resource Management DARPA is seeking proposals that will develop and evaluate a new generation of DRE middleware that can manage system resources adaptively and reflectively across multiple security levels of distributed systems in real-time. The goal of this task is to substantially improve the ability of middleware to enable applications and users to reason about and manage resources dynamically and dependably within multiple levels (i.e., networks, operating systems, and several layers of middleware) of complex DRE systems. The results will allow applications and users better control over these complex systems by (1) deferring the commitment of many resources from design-time until run-time, without sacrificing overall system predictability and dependability and (2) allowing higher-level mission doctrine to determine tradeoffs between resource allocation and reallocation strategies, thereby enhancing overall system effectiveness, verifiability, and lethality. Proposals for secure multi-level distributed resource management should contain a description of their candidate middleware architecture, identify policies (explicitly or implicitly) on how data and resources it owns are used, document external and internal dependencies/constraints imposed, as well as rational of proposed middleware architecture and the process via which ARMS will integrate technologies with it. Proposers in this area should demonstrate expertise in integrating meta-programmable DRE middleware frameworks with secure multi-level distributed resource management capabilities to form a coherent development tool suite suitable for the needs of the TSCE. The product of projects in this area should be capable of being transitioned to the middleware software market in the form of open protocols and interface standards. Proposers in this area should also be able to work with and participate in standards bodies, such as the OMG or The Open Group, that are defining the protocols and interfaces necessary for DRE middleware interoperability. It is anticipated that no more than four proposals will be selected in this area for possible funding and teaming is encouraged. For each Category: Proposed research should investigate innovative approaches and techniques that lead to or enable revolutionary advances in the state-of-the-art. Proposals are not limited to the specific strategies listed above, and alternative visions will be considered. However, proposals should be for research that substantially contributes towards the goals stated. Research should result in prototype DRE middleware software demonstrating integrated concepts and approaches. Specifically excluded is research that primarily results in evolutionary improvement to the existing state of practice or focuses purely on non-empirical methods. Integrated solution sets embodying significant technological advances are strongly encouraged over narrowly defined research endeavors. The period of performance for proposed research efforts should be no longer than three years in duration, with demonstrable goals that can be evaluated empirically at the midway point (18 months). Offerors in both categories, OEP and TD, must specify metrics associated with performance-based milestones that will enable DARPA management to systematically gauge the technical progress of the proposed effort. Teaming is encouraged and proposals may involve multiple research groups and/or industrial cooperation and cost sharing.
 
Record
SN00174016-W 20020925/020924065608 (fbodaily.com)
 
Source
FedBizOpps.gov Link to This Notice
(may not be valid after Archive Date)

FSG Index  |  This Issue's Index  |  Today's FBO Daily Index Page |
ECGrid: EDI VAN Interconnect ECGridOS: EDI Web Services Interconnect API Government Data Publications CBDDisk Subscribers
 Privacy Policy  © 1994-2013, Loren Data Corp.