The Largest Security-Cleared Career Network for Defense and Intelligence Jobs - JOIN NOW


Statement of Work

Improved Space Architecture Concept (ISAC)

Solicitation Number F29601-96-R-0016

21 July 1997

Prepared by

Air Force Phillips Laboratory

Space Mission Technologies Division

Kirtland AFB, New Mexico

1. SCOPE. The Air Force seeks to identify and demonstrate a commercial-heritage computer architecture for the near-term and mid-term signal and data processing needs of advanced space systems including high performance and autonomous operations of communications and advanced radar and electro-optical surveillance satellites. In order to evaluate architecture trades, the Air Force also seeks a software- and hardware-based testbed for use by the Government and Government contractors to model, simulate, and evaluate various architectures and implementations against particular missions, and to evaluate various processing algorithms on particular architectures. The Air Force further seeks to design and produce example instantiations of that architecture using both commercial and space components and packaging. All of these objectives shall be accomplished by applying the tenets of Integrated Product and Process Development (IPPD) as described in Appendix A.


2.1. Architecture Testbed Initiative (ARTI) (Basic Effort)

2.1.1. Requirements Analysis. Using the ISCP Phase I Interim Reports prepared by Mission Research Corporation and Maxwell Technologies as a starting point, the contractor shall determine the payload signal and data processing requirements of stressing-case military satellites which might be deployed in the "near-term" (i.e., using 2002-2005 component technology) and in the "mid-term" (i.e., using 2005-2010 component technology) time frames. (R&D Equipment Information Report, CDRL A001, DI-S-30599)

2.1.2. Software Simulator Testbed. The contractor shall design, assemble, and integrate a testbed for the simulation of space-borne high-performance mission data processing. The testbed shall be based on commercially available software and shall allow simulation at the box, board, and part level, including faults in order to perform architecture tradeoff studies and evaluate technology development tradeoffs. The contractor shall develop or adapt system software including a real-time operating system, software development tools, performance instrumentation, and tools to facilitate parallel programming. (Computer Software Product End Item, CDRL B001, DI-MCCR-80700; Software User's Manual, CDRL B002, DI-MCCR-80019A) The contractor shall design, implement, and integrate into the testbed a hardware or software sensor data simulator for generating input data from a representative set of surveillance sensors such as infrared, multispectral, or synthetic aperture radar systems. The testbed shall permit quantitative evaluations as described in ¶2.1.3. The contractor shall document the design and operation of the testbed to permit maintenance and operation by Government users. The contractor shall describe details of file formats for importing and exporting simulation data. (CDRL A001) The contractor shall train at least three (3) government personnel in the operation of all aspects of the testbed.

2.1.3. Architecture Evaluation. Using the software simulation testbed in ¶2.1.2 and the Phase I reports, the contractor shall perform quantitative analyses of processing architectures capable of performing the most stressing cases, as determined in ¶2.1.1. The contractor shall demonstrate both low-end and high-end payload processing applications on the testbed for a range of architectures to determine processing, communication, and memory utilization and bottlenecks. The contractor shall evaluate the scalability of the architectures and the behavior of the architectures during and following both transient and permanent faults. (CDRL A001) The contractor shall acquire, adapt, and integrate algorithms representing both low-end and high-end payload processing applications. (CDRL B001) The contractor shall estimate the weight and power required by low-end instantiations of the architectures using near-term technology, and by high-end instantiations using mid-term technology. The contractor shall combine this information with an evaluation of the architectures against other requirements from the IPPD process and select a single best architecture.

2.1.4. Technology Analysis. The contractor shall study and prioritize the advances needed in radiation hard or tolerant microelectronics, packaging, interconnects, and other areas to enable an instantiation of the architecture for the most stressing DoD application to be achieved under a constraint of reasonable weight and power, to be specifically defined during the contract period through the IPPD process. (CDRL A001)

2.1.5. Demonstration Model Preliminary Design. The contractor shall develop a preliminary design for a demonstration model of the processing architecture developed under ¶ incorporating hardware and software components which will support a representative subset of the requirements given in Appendix B. The design shall use commercially established chassis and circuit board formats, commercially available integrated circuits, and system design techniques to minimize vulnerability to nuclear weapon effects. The design shall have the facilities for the injection or simulation of a representative set of transient and permanent faults. The design should consider the eventual need to map the demonstration design to a flight experiment design using radiation-hardened space-qualifiable components and packaging. (CDRL A001)

2.1.6. Hardware Testbed. The contractor shall design, fabricate, and integrate a hardware testbed to serve as the chassis, backpanel, and external connector interface of the demonstration model outlined through the work of ¶2.1.5, and which provides a facility for testing and demonstrating third-party-developed processing, input/output, power conditioning, and other boards. The hardware testbed shall include any required user interface, testbed instrumentation, external power interface, and sensor interface hardware and software. (CDRL A001) The contractor shall verify and document hardware testbed integrity and operation. The contractor shall populate the hardware testbed with sufficient instrumentation or application boards to demonstrate operation. (Test/Inspection Reports, CDRL A002, DI-NDTI-80809A) (CDRL A002) The contractor shall document open interface standards describing: the physical, electrical, and functional characteristics of the boards or other subassemblies; signaling conventions, protocols, and data formats for inter-card and inter-node communication links; and software specifications for interface with operating system services and with software-implemented performance instrumentation. (CDRL A001)

2.1.7. Special Studies. The contractor shall conduct special studies which may be required to support the ARTI effort. Such studies may include, but not be limited to, low-voltage effects, radiation hardness issues of devices and components, fault detection and mitigation, opto-electronics, other emerging technologies, and processor-in-memory variations.

2.2. Space Architecture Demonstration and Integration (SADI) (Option 1)

2.2.1. Demonstration Model Development. The contractor shall complete the detail design of an demonstration model based upon the results of ¶2.1.5 and ¶2.1.6. The contractor shall design any required changes to the sensor data simulator, user interface, and/or hardware performance instrumentation developed for the testbed allowing demonstration model interface. (CDRL A001) The contractor shall fabricate and integrate the demonstration model. The contractor shall adapt and integrate system software including a real-time operating system, fault management software, start-up routines, host interface software, and performance monitoring software. (CDRL B001, CDRL B002)

2.2.2. Performance Evaluation. The contractor shall develop and execute on the demonstration model both low-end and a representative subset of high-end payload processing applications. The contractor shall determine processing, communication, and memory utilization and bottlenecks. The contractor shall evaluate the behavior of the demonstration model during and following either the injection or simulation of a representative set of both transient and permanent faults. The contractor shall determine the effectiveness and utility of hardware fault detection mechanisms, availability management software, hardware isolation circuits, critical state storage, and power management. The contractor shall compare results with those expected from testbed simulations. The contractor shall refine architecture simulation models, testbed simulation tools and libraries, and testbed user interface based upon experience with the demonstration model.

2.2.3. Special Studies. The contractor shall conduct special studies which may be required to support the SADI effort. Such studies may include, but not be limited to, low-power options, radiation effects on boards and systems, and system-level fault tolerance.

2.3. Flight Electronics Experiment (FELEX) (Option 2)

2.3.1. Mission Definition and Modeling. The contractor shall determine specific mechanical, electrical, and functional requirements for a flight demonstration experiment based on the demonstration model developed in ¶2.2. The contractor shall model the flight experiment hardware, sensor inputs, executive software, and mission algorithms. The contractor shall simulate both typical and abnormal mission profiles to validate the flight hardware and software designs.

2.3.2. Element Qualification. The contractor shall develop and execute a flight qualification plan for all elements of the flight experiment not otherwise qualified through QML, flight heritage, or other methods. (Management Plan, CDRL A004, DI-MGMT-80004)

2.3.3. Flight Experiment Design and Build. The contractor shall complete the detailed design of the flight experiment, special test equipment, and upgrades to the sensor data simulator, user interface, and performance instrumentation. (CDRL A001) The contractor shall fabricate and integrate the flight experiment and associated interface and test equipment.

2.3.4. Flight Software Development. The contractor shall upgrade the operating system, user interface, and other executive software from the demonstration model. (CDRL B002) The contractor shall develop and integrate payload processing software to implement the sensor data processing algorithms, output data formatting, and other mission processing requirements. (CDRL B001, CDRL B002) The contractor shall develop software test plans. The contractor shall validate the flight software package in accordance with the test plan. (Test Plans / Procedures, CDRL A003, DI-NDTI-80808)

2.3.5. Environmental Testing. The contractor shall coordinate with the space system user to develop vibration, shock, thermal, and EMI/EMC qualification criteria compatible with the mission on which FELEX will be flown. The contractor shall develop test plans and procedures to qualify the flight experiment design against those criteria. (CDRL A003) The contractor shall execute the test procedures developed in ¶ on the flight experiment and document the results. (CDRL A002)


3.1. Management. The Contractor shall designate a Program Manager who shall be the point of contact for all interactions between the Government and the Contractor regarding the technical and programmatic tasks outlined in this Statement of Work. The Contractor shall hold a kick-off meeting approximately one month after contract award followed by Technical Interchange Meetings (TIMs) and design reviews to cover the status of the technical progress, cost, and schedule. The contractor shall provide interface and insight to program matters involving cost, schedule, risk, and technical performance. (CDRL A005, Cost/Schedule Status Report (C/SSR), DI-MGMT-81467; CDRL A006, Contract Funds Status Report (CFSR), DI-MGMT-81468)

3.2. Integrated Product and Process Development (IPPD). The contractor shall execute ISAC using the principles of IPPD as described in Appendix A.

3.2.1. Integrated Master Plan (IMP). The contractor shall implement, manage to, update, and maintain the contract IMP. The IMP shall be used throughout the contract as a management tool to assess the progress and determine success in achieving program requirements. The contractor shall be required to report work in progress in accordance with the IMP at each review and at government discretion. (CDRL A004)

3.2.2. Integrated Master Schedule (IMS). The contractor shall develop, implement, manage to, update, and maintain the contract IMS. All contractor schedule information delivered or presented at reviews shall originate from the IMS. It shall be traceable to the IMP and shall contain all critical events, accomplishments, and criteria, predecessors and successors, and their dependencies. The IMS shall address ISAC activities for the prime contractor and major subcontractors. The contractor shall conduct critical path analyses of the tasks and report problem areas and corrective actions required to eliminate/reduce schedule impact. (CDRL A007, DI-MISC-81183A)

3.2.3. Systems Engineering. The contractor shall use a systems engineering process in managing the ISAC effort.

3.3. Coordination With Other Programs. The contractor shall work with the government to identify cooperation and coordination opportunities with other high-performance computing programs, including but not limited to the NASA/JPL Remote Experimentation and Exploration (REE) program, the ACP program, and the DARPA High-performance Computing program.

3.4. Environmental, Safety, and Health. The contractor shall implement a management and engineering process to ensure that all safety environmental, and health hazards associated with the system and tests are identified and controlled within the constraints of program cost, schedule, and performance. This process shall be documented in the IMP. (CDRL A004)

3.5. Contract Work Breakdown Structure (CWBS). The contractor shall prepare the CWBS using this SOW. The CWBS shall be reflected in all cost reporting data to Level 3. The contractor shall use the CWBS as a guide for all reporting elements in the Integrated Master Schedule. (Contract Work Breakdown Structure, CDRL A008, DI-MGMT-81334)

3.6. Reporting. The contractor shall document all technical work and findings gained during the performance of the project to permit a full understanding of the techniques and procedures used in evolving and applying this technology. This shall include pertinent observations, nature of problems, design criteria established, lessons learned, procedures followed, etc. A final technical report shall be developed and submitted at the end of the technical effort. (Scientific and Technical Report, CDRL A009, DI-MISC-80711)


Appendix A

Integrated Product and Process Development (IPPD) Information

1.0 The Integrated Master Plan (IMP)

The IMP is an Offeror generated document describing the critical functions, tasks, key events and milestones, and success criteria necessary to implement the tasking in the Statement of Work (SOW). The IMP is an events driven plan delineating the work effort by establishing significant accomplishments that must be complete prior to an event and the criteria that support successful completion of each accomplishment. The IMP shall be written to align with the Integrated Product and Process Development (IPPD) philosophy. The IMP may contain references to several Contract Work Breakdown Structure (CWBS) elements. The IMP is designed to displace functional plans (e.g. System Engineering Master Plan, Safety Plan, Reliability and Maintainability Plan, Software Development Plan, etc.). The IMP shall contain concise narratives to aid the government in using it as a planning and management tool. The IMP will be placed on contract as an attachment or an exhibit.

1.1 IMP Elements

The IMP shall reflect the IPPD approach and include associate and/pr major subcontractor activities. Each section of the IMP shall contain the following: Critical Functions, Events/Milestones, Significant Tasks, Success Criteria, and brief Narratives.

1.1.1 Critical Functions

The Offeror shall describe his processes for critical functions and integrate those functional descriptions deemed necessary (see CDRL A004 for details). Only the key functions/objectives should be discussed in the IMP. The Offeror shall include the results, or output, of the proposed processes as well as a brief description of the function/process. These descriptions shall be a summary of accepted corporate plans/processes. The intent of these functional descriptions is to proved the government essential information in order to assess the offeror's process. References to corporate documents may be cited; these references, however, do not replace the descriptions required for the IMP. If additional information is required, the government will request the contractor to furnish the information.

1.1.2 Event/Milestone

An event/milestone is the initiation/conclusion of a significant program task. It shall represent a decision point related to the continued system development.

1.1.3 Significant Task

A significant task is one which will produces a specified result substantiating an event that indicates the level of progress or maturity directly related to each product/process. Tasks shall be measurable. The tasks shall be sequenced in a manner that ensures a logical, critical path is maintained throughout the effort and tracks against key events. Each identified task shall be a required step to complete an event and not just time coincidental with that event.

1.1.4 Success Criteria

Success criteria are definitive measures/indicators for judging task completion. It is the completion of specified work that ensures closure of a task and its defining event. The IMP shall also contain criteria to be used to demonstrate that each task and associated event has been successfully achieved. The criteria shall be tied to the completion of key activities. The criteria shall be definitive and measurable, shall avoid the use of percent completed, and shall avoid citing data item report numbers rather than reporting results. References to calendar dates in the IMP are not permitted.

1.1.5 Narratives

Narratives are a collection of concise statements describing the tasks , events, and success criteria. The following contract milestones shall be included, in addition to other contractor proposed events/milestones: Requirements Review, Preliminary Design Review, Critical Design Review, Test Plan Review, and Demonstration. The use of other names for these events is acceptable as long as the scope and purpose of the event is clearly communicated. If the contractor proposes to comply with a standard for events, define the standard document. The Offeror is encouraged to identify incremental reviews and milestones and add additional events as deemed necessary.

2.0 Integrated Master Schedule (IMS)

2.1 The IMS illustrates the detailed task and timing of work effort in the IMP. It is used by government and contractor management as the primary tracking tool for technical and schedule status. The IMS is a supplement to the IMP and is an integrated and networked multi-layered schedule of program/project tasks. The IMS is an networked schedule that identifies all IMP events, accomplishments and criteria and the expected dates of each based on the calendar dates provided as the starting point and the logical flow of dates provided by calculating the addition of duration of all tasks using typical schedule networking tools. The IMS tasks will be directly traceable to the IMP and the CWBS. Tasks/activities in the IMS are logically linked together showing predecessor/successor relationships. The IMS network schedule shows the critical path. All network schedule information should be consistent with the IMP significant tasks and events.

2.2 The IMS Network schedule should contain a sufficient number of tasks and activities to provide a detailed understanding of the program. Tasks and activities include such efforts as:

  1. Work to be completed,
  2. Activities that determine or confirm the value of the technical parameters,
  3. Development of internal documents providing results of in-process verification (successfully completed analysis or other testing activities),
  4. Completion of critical activities required by the Offeror's internal program plans/operating instructions,
  5. Simulations, prototypes , and product engineering release, hardware fabrication, and functional or environmental testing.

2.3 Key elements of the IMS Network schedule include:

a. Milestone/Event - a specific definable accomplishment in the program/project network, recognizable at a particular point in time.

b. Activity or Task - a time consuming element , e.g. work in progress between interdependent events, represented in an activity box. The left side represents the beginning of the activity and the right side is the completion of the activity.

c. Duration - the length of time estimated to accomplish an activity.

d. Constraint - a line that defines how two activities or events are logically linked.

1. Finish to Start (FS) - an activity must finish before another can start.

2. Start to Start (SS) - an activity depends on the start of another activity.

3. Finish to Finish (FF) - one activity cannot finish until another activity finishes.

4. Start to Finish (SF) - an activity cannot finish until another activity starts.

5. % Complete or Lead Lag.

e. Total Slack or Float - extra time available on an activity before it will impact another activity on the critical path.

f. Free Slack or Float - extra time available on an activity before it will impact an activity on another successor activity.

g. Lead - the amount of time of the overlap between where a successor task begins and a predecessor task completes.

h. Lag - the amount of time between the end of a predecessor task and the beginning of a successor task.

i. Critical Path - A sequence of activities in the network that has the longest total duration through the program/project. Activities along the critical path have zero or negative slack/float. It should be easily distinguished on the report formats.

j. Target Start (TS) - date when an activity should start.

k. Target Complete (TC) - date when an activity should finish.

l. Actual Start (AS) - actual start date of an activity.

m. Actual Finish (AF) - Actual finish date of an activity.

n. Early Start (ES) - the earliest date an activity can start.

o. Early Finish (EF) - the earliest date an activity can end.

p. Late Start (LS) - the latest date an activity can start without delaying the program/project target completion date.

q. Late Finish (LF) - the latest finish date an activity can have without affecting the program/project target completion date.

r. Gantt Chart - a graphical display of program activities and key milestones that depict work activities in an integrated fashion. Activities are represented by bars showing length of time for each activity. Gantt charts should be supported by and consistent with the IMS or supportive of the IMS when it is descriptive of lower levels of detail than depicted in the IMS.

3.0 Integrated Product and Process Development (IPPD)

3.1 Within the framework of the Integrated Product and Process Development (IPPD) approach is the use of government/contractor Integrated Product Teams (IPTs) in implementing the event-driven plan described above. This involves a teaming of functional disciplines to integrate and concurrently apply all necessary processes to produce effective and efficient products that satisfy program/project requirements.

3.2 Under the IPPD approach, the system is subdivided into its products. The program is then organized into government/contractor IPTs that are empowered and held responsible for the performance of their specific product. Each IPT is given the authority to manage their product and allocate resources within the team. The IPT members represent all functions that a role in the performance of the product, i.e. engineers, manufacturing specialists, test specialists, buyers, contracts, inspection, etc. The work tasking for each product is defined in the SOW and reflects the product oriented CWBS.

Appendix B

An Example of High-Performance Computing Requirements in Space

Mission Description: Hyperspectral Imaging

Sensor Characteristics: 2K x 2K pixels per scene per waveband

210 wavebands

12 bits per pixel

Frame Rate: 50 processed images per day

Latency: Processed image available for downlink within four hours of data collection

Medium-Bandwidth Output: Three processed images based upon pre-programmed (uplinked) local-region processing and multiple band combining.

Low-Bandwidth Output: Automatic detection, discrimination, and classification within each waveband (and optionally combinations of wavebands) aided by uplinked guidance based upon expected scene and target characteristics, leading to a single annotated image.

This page intentionally left blank.

This page intentionally left blank.

Join the mailing list