MODIFICATION
A -- PROGRAM COMPOSITION OF EMBEDDED SYSTEMS (PCES)
- 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-25
- Response Due
- 10/30/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-25 replaces the version posted on September 13, 2002. PROGRAM COMPOSITION OF EMBEDDED SYSTEMS (PCES), SOL BAA 02-25, DUE: 10/30/02; POC: DR. DOUGLAS C. SCHMIDT, DARPA/IXO; FAX: (703) 522-7161 PROGRAM SCOPE The objective of the Program Composition for Embedded Systems (PCES) is to create new language and compiler technology for developing distributed real-time and embedded (DRE) middleware and applications that reduces complexity by separating application functional concerns (such as exploitation algorithms, rules of engagement processing, or weapons targeting) from cross-cutting systemic concerns (such as synchronization of concurrent operations, processor fault isolation, sensor input and actuator output timing constraints, distribution, and safe/efficient cache, register, and memory management). The Sensor-to-Decision Maker-Shooter/Weapons (SDMS/W) kill chain used to prosecute Time Critical Targets (TCTs) is an excellent example of DRE systems and their need for highly flexible, dependable, and efficient software. The kill chain refers to the Find, Fix, Track, Target, Engage, and Assess (F2T2EA) process used by an Air Operations Center (AOC) to commit strike resources against a TCT. All of these operations must be accomplished within a short time window to destroy elusive mobile targets. Since attack maneuvering and the weapon alignment and fly out consume most of the time interval, the actual strike decision must be made by the legal authorities and relayed to the pilot and/or weapon within seconds of combat identification of the target. The PCES program addresses the following factors that have historically increased software fragility and total ownership costs and imperiled the success of numerous new and planned DoD programs: 1. Multiple platform and varying operational contexts. DoD systems must invest an ever-increasing proportion of functionality in DRE software to retain technological dominance. Rapidly emerging technologies and flexibility required for diverse operational contexts force deployment of multiple versions of software on various platform architectures, while preserving key properties, such as secure, dependable, and real-time response. 2. Total ownership costs. Software development and evolution is labor-intensive and error-prone for complex DoD DRE systems and can represent over 50% of the total ownership costs of these systems. 3. Obsolescence trends. Incommensurate lifetimes between DoD systems (20 years or more) and computational platform (2-5 years) lead to pervasive software obsolescence and multiply the total ownership costs by requiring periodic software re-development and commercial off-the-shelf (COTS) refresh. This BAA solicits proposals in two research categories, "Open Experimentation Platform (OEP) Developer" and "Technology Developer." Offerors in both categories must specify metrics associated with performance-based milestones that enable DARPA management to systematically gauge the technical progress of the proposed effort. The period of performance for proposed research efforts should be no longer than two years in duration. OEP Developer The OEP Developer supplies the PCES program with specific challenge problems that must describe the current operational state in the domain of Sensor-to-Decision Maker-Shooter (SDMS/W) systems, and describe quantifiable performance-oriented goals that would enable significant increases in overall domain performance, but also require significant technological innovation to realize. The OEP developer will also integrate PCES technologies into the SDMS/W testbed as an objective evaluator, conduct formal experiments, analyze results, and feed recommendations back to the Technology Developers (TDs). The primary emphasis of this experimental evaluation is the quality (both at design time and at run-time) of the PCES DRE middleware. In that capacity, the OEP developer will devise and validate methods and tools for evaluating the aggregate QoS of the PCES DRE middleware and representative SDMS/W applications in terms of their flexibility, correctness, latency/jitter, throughput, scalability, adaptability, stability, dependability, and optimization capabilities. The OEP Developer will make the challenge problems, SDMS/W applications, and the integrated SDMS/W testbed itself accessible for all the TDs in the PCES program. Proposers in the OEP Developer category should propose a SDMS/W software test platform of interest to the Armed Services, as well as specific challenge problems on which objective evaluation will be based. Offerors for OEP Developer should demonstrate an ability to integrate PCES 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 SDMS/W constraints and performance drivers and must suggest test and evaluation methodologies for PCES experiments based on their OEP. It is anticipated that no more than one proposal will be selected in this area 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 SDMS/W testbed provided by the OEP Developer described above. The two TD topical areas are described below: Topic 1. DRE Middleware Generation and Optimization Tools DARPA is seeking proposals that will develop languages, algorithms, patterns, and code bases to support the generation and optimization of DRE middleware that can be customized for specific mission requirements and constraints of DoD SDMS/W systems and applications. The middleware will be generated automatically and optimized via algorithms that can be tailored declaratively to adapt to key DRE platform characteristics, e.g., interconnection mechanisms, event demultiplexing mechanisms, I/O mechanisms, synchronization and concurrency mechanisms, failure detection and recovery mechanisms, configuration mechanisms, and power levels. Automating the configuration and optimization of DRE middleware is essential since the need for stringent behavioral assurance makes verification and empirical validation of the customized middleware components necessary. Moreover, these capabilities will ensure that DoD systems can leverage standards-based COTS while simultaneously ensuring that key protocol, implementation, and QoS properties can remain unique in order to retain superiority over adversaries who have access to the same standards-based COTS middleware. Proposers of new DRE middleware generation and optimization tools should demonstrate expertise in one or more areas of interest to DRE developers, such as time/space constraints, real-time performance goals, cross-cutting aspects, and/or open middleware standards. Proposals should discuss the importance and prevalence of these features in the context of DRE middleware and SDMS/W systems. Proposers should also be able to interface to other PCES 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 DRE middleware generation and optimization tools will be required to be provided in open, extensible, well-documented formats, compliant with the middleware standards PCES is developing and leveraging. Tools developed for PCES will be evaluated heavily on the ease with which they can be integrated with other tools and with standards-based middleware environments, such as the OMG Model Driven Architecture (MDA) efforts. Any number of different tools may be proposed in a given proposal, though each proposal must comply with all submission requirements including page limits given in this PIP. Each DRE middleware generation and optimization tool proposed should be structured as a unique, separately priced task option so that a subset of those tools proposed might be targeted for funding. One or more tool options may be targeted for funding from a given proposal, though it is anticipated that no more than four DRE middleware generation and optimization proposals will be selected for possible funding and teaming is encouraged. Topic 2. Distributed Quality Aspects DARPA is seeking proposals that will develop new theory, technology, and tools for applying aspect-oriented techniques to DRE middleware and applications. In particular, DARPA is seeking innovative techniques that can collect, organize, and disseminate QoS-related meta-information needed to (1) monitor and manage how well the functional interactions occur in SDMS/W systems and (2) enable the decision-making needed to support systemic QoS properties robustly in the face of rapidly changing SDMS/W mission requirements and environmental conditions. These middleware capabilities are crucial to ensure that the aggregate behavior of complex network-centric SDMS/W systems is dependable, despite local failures, transient overloads, and dynamic functional or QoS reconfigurations. Proposals for distributed quality aspects should contain a description of their candidate middleware architecture and the process via which PCES will integrate technologies with it. To promote a common technology base, the interfaces and (where appropriate) the protocols used by PCES middleware should be based on (or should guide) established or emerging industry or DoD standards that are relevant for DoD DRE systems. However, the aspect-oriented technologies developed in the PCES program should also be customizable?statically and dynamically?for specific DoD DRE application and mission requirements. Proposers in this area should also be able to work with and participate in standards bodies, such as the OMG and The Open Group, that are defining the protocols and interfaces necessary for PCES middleware interoperability. It is anticipated that no more than four proposals will be selected in this area for possible funding and teaming is encouraged. 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. Teaming is encouraged and proposals may involve multiple research groups and/or industrial cooperation and cost sharing. The period of performance for proposed research efforts should be no longer than two years in duration. This BAA shall remain open and proposals received up to one year following this BAA?s release. GENERAL INFORMATION The Defense Advanced Research Projects Agency/Information Exploitation Office (DARPA/IXO) requires completion of a Broad Agency Announcement (BAA) Cover Sheet Submission for each Abstract/Proposal, by accessing the URL below: http://www.dyncorp-is.com/ixo/index.asp?BAAid=02-25 After finalizing the BAA Cover Sheet Submission, the proposer must print the BAA Confirmation Sheet that will automatically appear on the web page. Each proposer is responsible for printing the BAA Confirmation Sheet and attaching it to the "original" and each designated number of copies. The Confirmation Sheet should be the first page of your Abstract/Proposal. If a proposer intends to submit more than one Abstract/Proposal, a unique UserId and password should be used in creating each BAA Cover Sheet. Failure to comply with these submission procedures may result in the submission not being evaluated. Proposers are advised that the Award Document for each proposal selected and funded will contain a mandatory requirement for submission of DARPA/IXO Quarterly Status Reports and an Annual Project Summary Report. These reports will be electronically submitted via the DARPA/IXO Technical ? Financial Information Management System (T-FIMS), utilizing the government furnished Uniform Resource Locator (URL) on the World Wide Web (WWW). Further details may be found in the Proposer Information Pamphlet (PIP). PROPOSAL FORMAT Proposers must submit an original and 4 copies of the full proposal and 2 electronic copies (i.e., 2 separate disks) of the full proposal (in Microsoft Word ?97 for IBM-compatible, PDF, Postscript, or ASCII format on one 3.5-inch floppy disk or one 100 MB Iomega Zip disk). Each disk must be clearly labeled with BAA 02-25, proposer organization, proposal title (short title recommended) and Copy ___ of 2. The full proposal (original and designated number of hard and electronic copies) must be submitted in time to reach DARPA by 12:00 NOON Local Time, Wednesday, 10/30/02, in order to be considered during the initial evaluation phase. However, BAA 02-25, Program Composition of Embedded Systems (PCES), will remain open until 12:00 NOON Local Time, Thursday, 10/30/03. Thus, proposals may be submitted at any time from issuance of this BAA through Thursday, 10/30/03. While the proposals submitted after Wednesday, 10/30/02, deadline will be evaluated by the Government, proposers should keep in mind that the likelihood of funding such proposals is less than for those proposals submitted in connection with the initial evaluation and award schedule. Proposers must obtain the BAA 02-25 Proposer Information Pamphlet (PIP), which provides further information on the areas of interest, submission, evaluation, funding processes, proposal abstracts, and full proposal formats. This Pamphlet will be posted directly to FedBizOpps.gov and may also be obtained by fax, electronic mail, mail request to the administrative contact address given below, or at URL address http://dtsn.darpa.mil/ixo/solicitations/pces/index.htm. Proposals not meeting the format described in the Pamphlet may not be reviewed. This Announcement, in conjunction with the BAA 02-25 PIP and all references, constitutes the total BAA. No additional information is available, nor will a formal RFP or other solicitation regarding this announcement be issued. Requests for same will be disregarded. All responsible sources capable of satisfying the Government's needs may submit a proposal that shall be considered by DARPA. Historically Black Colleges and Universities (HBCUs) and Minority Institutions (MIs) are encouraged to submit proposals and join others in submitting proposals. However, no portion of this BAA will be set aside for HBCU and MI participation due to the impracticality of reserving discrete or severable areas of this research for exclusive competition among these entities. 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 only. Evaluation Criteria for proposals received in the "Technology Developer" category will be evaluated according to the following criteria: TD Criterion 1. Innovation and Payoff: Quality of discussion presented that indicates proposed technology to be developed is innovative. Quality of discussion that conveys expected design-time and/or run-time improvements relative to current capabilities available commercially or in DoD. Quality of discussion that describes analytical and/or practical limitations of proposed technology in the context of SDMS/Ws. Quality of discussion that elucidates DARPA's critical role in sponsoring proposed technology. TD Criterion 2. Technology Development, and Experimentation Approach: Quality of analysis presented that elucidates the risks and benefits of proposed technology development approach in the context of SDMS/Ws. Depth and breadth of understanding of tradeoffs considered in the choice of alternate approaches. Degree to which presented measures of proposed technology are quantified, sound, and complete. Quality of discussion that describes feasible experimentation approaches for the technology under development. Quality of discussion that describes offeror's technical and management approach that will support SDMS/W integration activities with the select OEP Developer. TD Criterion 3. Project Plan and Schedule: Quality of the statement of work (SOW). Quality of plan presented to synchronize development and facilitate the integration and testing of proposed technology with select PCES OEP Developer. Soundness of plan to coordinate with OEP Developer and Technology Developer performers in the PCES program. Degree to which plan and schedule include precise, measurable, performance-based milestones at intervals of no more than six months. Overall soundness of proposed schedule. Quality of discussion that identifies major schedule risks and specific techniques proposed to manage risk. TD Criterion 4. Experience and Qualifications: Level of experience and qualification of key personnel. Level of experience and qualification of non-key personnel. Experience of proposed personnel in efforts of comparable approach and complexity. TD Criterion 5. Cost: The overall estimated cost to accomplish the effort should be clearly shown, as well as the substantiation of the costs for the technical complexity described. Evaluation will consider the value to Government of the research and the extent to which the proposed management plan will effectively allocate resources to achieve the capabilities proposed. Evaluation Criteria for proposals received in the "OEP Developer (OEPD)" category will be evaluated according to the following criteria: OEPD Criterion 1. Challenge Problem Formulation: Degree to which qualitative and quantitative goals of initial formulation of SDMS/W challenge problem(s) are precise and compelling. Quality of discussion that characterizes the application and system QoS characteristics in the SDMS/W domain. Quality of discussion that elucidates DARPA's critical role in sponsoring solutions to challenge problem(s). OEPD Criterion 2. Integration Approach: Quality of discussion that elaborates the proposed technical approach, system engineering and configuration management practices that will enable controlled integration of potentially disparate DRE middleware technologies and tools into coherent open tool suites capable of managing the resources of DRE systems efficiently, scalably, dependably, predictably, and securely. Quality of discussion that elaborates a specific roadmap that a Technology Developer might follow in order to integrate component(s) into proposed OEP. Quality of discussion that details proposed management approach that will permit demonstrably more functionally complex builds approximately every six months that are synchronized to DARPA program milestones. Quality of discussion that identifies the roles and responsibilities of the Technology Developer and OEP Developer/Integrator in support of integration activities. OEPD Criterion 3. Experimentation and Analysis Approach: Quality of discussion that elaborates proposed approach for the systematic conduct of experiments on aggregates of PCES technology development components. Quality of discussion that identifies the roles and responsibilities of the Technology Developer and OEP Developer/Integrator in support of experimentation activities. Quality of discussion that elaborates the goals, techniques and deliverables associated with analysis of experimental results. OEPD Criterion 4. OEP Infrastructure: Suitability and quality of proposed OEP facilities, hardware and software that will be used to implement the OEP experimental testbed. Quality of discussion that elaborates approach(es) for leveraging OEP infrastructure and PCES technologies in order to demonstrate solutions to identified SDMS/W challenge problems. OEPD Criterion 5. Project Plan and Schedule: Quality of the statement of work (SOW). Soundness of plan to coordinate with OEP Developers and Technology Developer performers in the PCES program Degree to which plan and schedule include precise, measurable, performance-based milestones. Overall soundness of proposed schedule. Quality of discussion that identifies major schedule risks and specific techniques proposed to manage risk. OEPD Criterion 6. Experience and Qualifications: Experience and Qualifications: Level of experience and quality of key personnel. Level of experience and quality of non-key personnel. Degree to which proficiency to manage and perform complex software development and integration has been successfully demonstrated. Degree to which proficiency to design, plan, conduct and analyze the results of controlled experimentation on complex systems, particularly shipboard combat systems, has been successfully demonstrated. OEPD Criterion 7. Technology Transition Plans and Capabilities: The offeror should provide a clear explanation of how the technologies to be developed will be transitioned to capabilities for existing or planned DoD SDMS/W programs. Technology transition should be a major consideration in the design of experiments, particularly considering the potential for involving potential transition organizations in the experimentation process. OEPD Criterion 8. Cost: The overall estimated cost to accomplish the effort should be clearly shown as well as the substantiation of the costs for the technical complexity described. Evaluation will consider the value to Government of the research and the extent to which the proposed management plan will effectively allocate resources to achieve the capabilities proposed. All administrative correspondence and questions on this solicitation, including requests for information on how to submit a proposal abstract or proposal to this BAA, must be received at one of the administrative addresses below by 12:00 NOON Local Time Wednesday, 10/30/02; e-mail or fax is preferred. DARPA intends to use electronic mail and fax for some of the correspondence regarding BAA 02-25. Proposals and proposal abstracts MUST NOT be submitted by fax or e-mail; any so sent will be disregarded. The administrative addresses for this BAA are: Fax: 703-522-7161 Addressed to: DARPA/IXO, BAA 02-25 Electronic Mail: baa02-25@darpa.mil Electronic File Retrieval: http://dtsn.darpa.mil/ixo/solicitations/pces/index.htm Mail to: DARPA/IXO ATTN: BAA 02-25 3701 N. Fairfax Drive Arlington, VA 22203-1714
- Record
- SN00174018-W 20020925/020924065609 (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 |