We are building complete versions of the RDE and ENTIRE every four months. Each of these "builds" is evaluated and used by the rest of the program to do real work. Each year we formally release the RDE for external use. Concurrently with the build/release process we begin the development of the next release. This lets all of our team, our users and our customers see where we expect to be in the next year.
The release being used at this conference is the fourth build of the RDE. The RDE development effort uses previously developed RDE utilities in conjunction with the RASSP process of software development. This release of the RDE contains a common set of infrastructure services for use in a wide range of applications: common desktop, automatic metrics collection, metrics analysis, reuse utility, technical review utility, problem reporting utility, log utility, and remote data access.
The RDE is being tailored for use on our Model Year 1 demonstration to include domain specific tools, translators, libraries, and process support. The fully populated and tailored design environment is described as the ENTIRE concept. Our plans and progress on the RDE are reported in detail in “ENTIRE,” a paper by Ong, Costantino, and Philips presented at this conference.
The Sanders team has embarked on an ambitious Demonstration plan to execute three model year builds of flight hardware using our RASSP process. These Demonstration Model Years will add functionality to two Infrared Search and Track (IRST) signal processing systems. The first of these Model Years is complete and has resulted in first-pass AIRMS flight hardware in 11 months and a cost of $3.5 Million. The next model year will result in replacing seven different boards from WRA-2 in the F-14D IRST processor with 2 identical boards while maintaining the current 2-D functionality. The third model year will use the 5 empty slots to add full 3-D capability to the F-14.
In addition to the Demonstration, Sanders is executing a series of Benchmarks which measure the process improvement of our approach in an incremental way that makes full use of metrics as a gauge of progress. The first of these benchmarks involves the virtual prototyping of a Synthetic Aperture Radar for application to an Unmanned Air Vehicle. The second set uses RASSP to upgrade the signal processing in the F-15 and F-18 radars.
The fourth part of our approach is to proliferate the process widely. Sanders is dedicated to the proliferation of RASSP. An example is that the original concept of a facilitator on the program came from Sanders. Proliferation to a range of users provides a way of verifying our process. Beta sites also give us a way to get feedback on the strengths and weaknesses of our process.
Because of the success which Sanders and the US Air Force have had on the F-22 program with the use of Integrated Product Teams, we chose to use a similar management technique on RASSP. Our program consists of four Integrated Process and Product Development Teams (IPPDTs). These four teams include Systems, Design Environment, Demonstration, and Proliferation. Sanders leads the Systems team as well as being the prime contractor on the program. Motorola has the lead responsibility on the Design Environment, while Hughes leads the Demonstration team. ISX has the responsibility for the Proliferation effort. All team companies share each of the team’s tasks. This leads to the concept of "single responsibility, shared execution." This has worked well on the RASSP program.
Typical of the innovative ways used to erase the geographical distances separating the team members is the extensive use of the Internet. By using T-1 lines throughout the team, we are able, for example, to carry on video conferences between desks separated by thousands of miles. At the same time engineers can share workstation screens, send encrypted files between fire-wall protected servers around the country, and can access our MOSAIC server with its homepage directions to current RASSP activities. Concurrently, tools sited at one team’s location can be used remotely, or can be transferred through various ftp protocols. The Sanders team has set up a tiered ftp site for document access. Various levels of security and access are available, ranging from “Sanders only” through “Sanders plus Team” to “Team plus ARPA/Triservice Steering committee" to "Unrestricted.” This ftp site uses a document data base system that allows the customer access to more than 5000 documents created in the first half of the program, including all deliverables. This allows timely and cost effective review and commenting by the customer. It lowers delivery costs to zero for these reviews, and allows "final" delivery to take place instantaneously. Having the USG on-board as part of the team (including DPRO and USN contract monitors) opens the program, prevents surprises, and reduces costs.
The last two parts of the methodology are closely linked. We use a virtual prototyping technique in which a complete VHDL model is developed to reduce integration risks. The last piece of our methodology involves delivery of a complete description of the system as a VHDL model. This includes source code for all programmable processors in the design. All source code is written in Ada.
The emphasis on virtual prototyping improves the quality of design, documentation, and error checking. This reduces mistakes that can have costly consequences which do not appear until late in the development cycle. Our objective in RASSP is to produce a top-down design methodology in which a design is successively refined as a growing, verifiably consistent data package over the course of its development. The initial functional requirements are captured and ported into a simulation environment supported by a VHDL simulator.
This “executable requirement” is refined until it becomes a complete “executable specification.” This acts as a test bench and also provides the requirements for the next lower level of the design. This top-down development process is used over the life cycle of a signal processor in an iterative way. These iterations allow for continuous improvement, i.e., RASSP Model Year Upgrades, of the signal processing system throughout its development and deployment. Upgrades can include functional improvements, repackaging for reduced power, cost, weight, or volume, or to replace parts out of production with those more readily available. The functional and performance specifications from one model year become the executable specification for the next. The hierarchical VHDL description provides for easy reuse of any downward chain, and redevelopment starting from any upward intact chain. The corresponding Ada code provides for software reuse in a similar manner.
The RDE provides technologies or services that fully support geographically distributed concurrent design, development and the electronic exchange of product information. The RDE commercially available high-speed communication services allow for linking to geographically diverse sites. Since team members represent different companies, organizations and product development disciplines, the RDE must be able to support whatever tools are used in a heterogeneous computing environment.
The ENTIRE concept is defined as RDE software which is comprised of a RASSP-supplied domain-independent set of infrastructure services coupled with a user supplied set of domain dependent design automation tools. Installations of the RDE will be tailored to include integrated tools and libraries which will exchange data via standard/common formats or through translators.
Another significant aspect of the RDE is a distributed database containing all of the product life-cycle data (product and management data) for both current and previous RASSP designs, as well as modular building blocks for design reuse. Each project has a different set of requirements for product development and therefore a unique set of CAD tools are needed to support the project. Recently initiated projects may utilize existing tool sets, current versions of tools, or the best possible tool solutions from multiple CAD vendors. A major advantage of this approach is that the integrated database produces, in one location, all of the relevant program documentation. This has a major positive impact in reducing the life cycle costs of a program. It also saves both the contractor and the government money in the development cycle. In order to adapt to different or changing tool sets the RDE must have the flexibility to be tailorable. The RDE will be delivered with a set of core RDE utilities plus an integrated set of CAD tools. Each site configuration of an RDE will probably contain a different set of CAD tools which have been determined by product development requirements. The CAD tools in the RDE will be integrated together along with component and model libraries. The information that is exchanged between tools will be in a manner such that tools can be substituted with different tools of at least the same functionality and still allow the data to automatically flow from one process step to another.
This ENTIRE tailoring will contribute to 4X improvement by allowing new and improved design automation tools to be utilized in conjunction with the core utilities. All of the components in the RASSP Engineering Database (REDB) are designed to allow remote team members to work together on the same project as if they were in the same room. The utilities and tools will be integrated in a manner which allows information to be exchanged securely between team members that work in remote locations (illustrated in Figure 4). One of the RDE features that supports this is the database communications. Each RDE connects to a RASSP Engineering Database server. The server can be hosted either on the local computer, or a computer in a remote network. Each RDE server has the ability to communicate with other servers. If data is requested from a database, if the data resides in a remote database, the data will be requested from the remote server. Secure data sharing and conferencing will be achieved with commercial encryption and decryption products. Additional security is being addressed with firewall boxes. The combination will provide authentication (no IP spoofing) and privacy (encryption).
The development of a real-time infrared search and track (IRST) processing system serves as a real-world application of the on-going development of methodologies and processes intended to achieve a four time improvement of cycle time at the end of the four year program. This development is an integral part of RASSP program. Real world applications are used to validate and provide metrics on the effectivity of the methodology and processes.
The specific demonstration in the Sanders RASSP program involved upgrading the Infrared Search and Track signal processor on the ARPA AIRMS aircraft for Model Year 0. This Model Year demonstration has been successfully completed. Model Year 1 upgrades the IRST processor on the F-14D aircraft. Much of the work from Model Year 0 is being reused. In the demonstration Model Years we build Virtual Prototypes using multi-leaf VHDL models and software whose source code is written in Ada. This prototype is used to support three Model Year Upgrades (0, 1, and 2). Model Year 2, featuring full 3-D capability IRST inside the original 2-D physical, weight, power, and connection constraints will fly on an F-14 in 1997. Model Year 0 is flying in 1995 on an ARPA special mission testbed aircraft. Model Year 1 (F-14 flight hardware) will be operational in early 1996.
The Sanders, Motorola, Hughes and ISX RASSP Team is developing a balanced set of approaches to address each of the factors that contribute to improvement and the barriers that impede improvement. This balanced approach involves developing new engineering and business processes and new technology as well as improving access to resources and information.
The RASSP Process, being developed by the Sanders Team, applies rapid and virtual prototyping using state-of-the-art design, development and simulation tools, and DOD standards, including VHDL and Ada, to derive early insight into product performance and risk, and to project affordability, manufacturability and sustainability. Early application of subsets of this process, such as in Benchmark efforts, have demonstrated the possibility of applying VHDL and Ada for Virtual Prototyping of design in order to identify and rectify problems before processing the actual hardware. This approach also enhances risk analysis and mitigation by providing for generation and analysis of alternate design solutions in the virtual prototype phase rather than after “metal is bent and circuits fabricated.”
Virtual prototyping in our process will eventually allow each contemplated design alternative to be captured in executable requirements and in an executable specification; this will also provide a concurrent construct of design documentation, along with executable design-to-baseline for the next level of design.
Early in the Sanders proposal effort, the goal of establishing and operating as an integrated Virtual Corporation was set. Since that time, the team has worked continuously to identify and refine the infrastructure necessary to reach this end. The Virtual Corporation infrastructure borrows heavily from the successful experiences, methodologies, and tools used and developed by each team member over many projects and many years. These components have been melded together with additional services and utilities identified by the RASSP team to provide the support necessary for managing, running, and succeeding within a Virtual Corporation. This effort has been extremely successful to date. The methodologies, tools, and standards that enable a Virtual Corporation span the areas of Program Organization and Management, Advanced Concept Engineering, and Data and Information Management. The Virtual Corporation infrastructure is being captured and refined within the RDE and Process Development efforts themselves so that, ultimately, the RDE may be used by the team to manage and support its continuing RDE development.
The notion of a virtual company is a fairly recent development that appeared with the advent of global networks such as the Internet. The RASSP program uses this concept to conduct business that requires a design team for the development of a complex digital processor. The technical domain is challenging because of the amount of detailed information exchange required by the design team. The proper level and degree of information exchange is the design aspect that poses the biggest problem for a virtual company because of the intangibles involved in creative tasks. The technical domain also has demanding resource requirements for creating and exchanging associated data in terms of workstation and network capacity. The RASSP Program challenges technology limits and explores the development of complex multi-processor digital systems with a distributed design team.
Integrated Product Development teams have all of the disciplines needed to accomplish product development from concept to field support working as a single integrated team to efficiently and concurrently create new innovative products. The team approach enables tight linkages between hardware, software, product design, manufacturing, procurement, reliability, maintainability and supportability to be established and maintained. IPD can be made significantly more powerful with the addition of tools and processes to enhance situational awareness.
Virtual corporation technology extends the concept of IPD to encompass multiple companies, geographically separated to perform as if they were a single company located in a single location. Virtual corporation technology allows the flexible creation of teams comprised of electronically co-located workers and addresses both engineering and management issues.
The Sanders Team employs a variety of techniques and tools to enable an integrated program management approach. None of these is more fundamental to our virtual enterprise than that of the Integrated Product and Process Development Team. This methodology focuses on the use of interdisciplinary teams throughout the process and product development cycle. This philosophy provides for a broad range of expertise from a range of disciplines when conducting each step in the development process. In the Sanders virtual enterprise, these teams are further diversified by ensuring that each IPPDT has membership from each corporate enterprise member.
The RASSP team has employed the concept of a “Visionary Demonstration” (Visdem) to help satisfy these needs. A visdem is a multimedia application developed and refined in a rapid prototyped manner. This visdem typically captures program organization, technical approach, and most importantly, the operational concept. This operational concept constitutes a visual contract between development team members and the target user community, showing how the system under development is to look, feel, function, and be utilized.
The conceptual prototype varies significantly from the visdem. First, the conceptual prototype is built on the development/delivery platform. It is developed using the language and standards identified by the core development team. It uses and provides reusable code synergistically with the core development team. It provides some very limited functionality. Its major focus again is the illustration of functionality rather than the robust provision of that functionality.
RASSP uses the characteristics of HDL languages and Virtual Prototyping as the basis for a methodology that produces a top down design approach that includes a totally portable VHDL description. This also includes modeling methods for discrete levels of abstraction that facilitate interoperability. These features are ideal for a multi-company design project that must accomplish virtual system integration and maintain a design data base.The methodology requires a system of procedures for data management across the virtual company. A data promotion scheme was developed that allowed incremental levels of dependency and maturity for source code.
Application-specific systems benefit from reuse of design information and functional block libraries from past designs. Algorithms can be rapidly designed using reuse libraries of commonly used functional blocks. Architectures can be quickly synthesized from reuse components of past designs. Use/reuse of the library of primitives allows the engineer to rapidly and confidently capture system functionality in terms of behavior, variables and communication channels for data/information flow among system elements. Critical paths for control and data flows can be identified, captured and analyzed, and requirements can be associated to, and linked with, functions. And the biggest payoff is that there are no irrevocable decisions, so it is not necessary to get it “perfect” the first time -- one just has to improve it each time through. Thus the inevitable “misstated requirement” or misunderstood operational environment is no longer the largest cost driver in the design and fielding process.
At the start of 1995, we presented a model for reaching 4X. This model is based on the results of a task analysis of the design process from very early system concept development and feasibility through development, test, production, and field support. Approximately 70 specific tasks were identified, and the associated duration, based on current practice, for each task was determined. The baseline development timeline resulting from the assignment of duration to tasks was compared with the current practice model proposed by Vijay Madisetti and Jack Corley of the RASSP Education and Facilitation team and found to fit easily within their minimum and maximum timelines. This favorable comparison helped increase our confidence that we had accurately captured the basic product development process.
The Sanders Team has been defining and documenting its common description of the “RASSP Process” for the purpose of achieving both commonality of understanding and “process configuration management.” Further, they recognize that at contract end the legacy process definition must be sufficiently robust to provide for its continued successful use by industry and government engineering design teams.
The Sanders RASSP Process is intended as a combination of “top-down” hierarchical and “spiral development” engineering sequences, applied in Model Year progressions. It has been developed using the preliminary version of the new IEEE 1220 standard for systems engineering to assist in definition and description. Our overall process description extends through the six phases of the system life-cycle of engineering effort related to product development, down six levels of product decomposition, and includes three recursive steps within our “Process Engine” for analysis: “develop and validate requirements baseline,” “develop and verify functional architecture,” and “synthesize and verify hardware, software, and physical design.”
Sanders’ process uses a “finish-to-finish” engine rather than a “finish-to-start” sequencing. Rather than require each activity to finish before the succeeding one starts, they only require that all previous activities be complete before succeeding activities can terminate. The result is encouragement to evaluate details and mitigate risks early in the design. The Sanders RASSP Process also encourages rapid prototyping activities, including early prototypes of user and other interfaces and of partial and end-to-end threads through the design to permit independent evaluation, optimization and validation. The Process structure is tailorable to the specific needs of customers and projects, so the specific steps within any particular iteration of its application can be different from all others. However, the overall methodological approach should be consistent.
How well is all this working? First Criterion: Has the Sanders RASSP Process been used? Answer: Yes, multiple new weapon system upgrades have been and are being started. Second Criterion: Are the team’s parent companies incorporating the RASSP Process? Answer: Yes, each of the three major industrial members are internally instantiating the RASSP Process.
The RASSP Design Environment (RDE) facilitates Integrated Product Development (IPD) by providing a collaborative work environment. The RDE provides support for automating the product development process. The RDE enables the IPD philosophy with its support of rapid iterations, incremental promotion, and scalable configuration management controls. A fundamental thread in supporting IPD is communication between individuals within and across teams of people, especially when the teams are not co-located. The RDE provides technologies or services that fully support geographically distributed concurrent design, development and the electronic exchange of product information. The RDE supports whatever tools are needed in heterogeneous computing environments. The ENTIRE concept is defined as RDE software which is comprised of a RASSP-supplied domain independent set of infrastructure services coupled with a user-supplied set of domain dependent design automation tools. Installations of the RDE will be tailored to include integrated tools and libraries which will exchange data via standard/common formats or through translators. Another significant aspect of the RDE is a distributed database containing all of the product life-cycle data (product and management data) for both current and previous RASSP designs, as well as modular building blocks for design reuse.
ENTIRE Uses SHORE/EXODUS (A University Developed and ARPA Contracted Database). The RDE stores and retrieves project and product information from the RASSP Engineering Database (REDB). This heterogeneous database contains all the information required by the project, from lists of users to design schematics. The REDB is distributed for team members to be able to securely access project and product data from remote locations. Information is placed into the REDB through a programming interface. This interface allows utilities or tools to access the repository independent of the underlying database. There may be only one, or multiple databases beneath the interface. Each database must implement the functions in the interface to work with the RDE. The programming interface allows access to object-oriented databases, relational databases, or CAD framework databases. The REDB is the repository for the design information that is commonly shared between the tools. The information is stored in a common format for each type of design data. Any tool that requires the data as input can then acquire and use the data.
We created a complete VHDL virtual prototype of processing hardware and Ada software before the design was fabricated. The rapid laboratory checkout that ensued is an indicator that virtual prototyping has great value. The virtual prototype was used to simulate processing modules, custom interface modules and the Ada software. The RASSP IRST project was performed by a virtually co-located team with Team members from Hughes in El Segundo, California; Motorola in Scottsdale, Arizona; and Sanders in Nashua, New Hampshire. Using the Internet for file sharing, e-mail, and video teleconferencing, the entire hardware and software design was performed without requiring travel for design reviews or coordination. VHDL descriptions done at each location were integrated to form the virtual prototype. The virtual prototype facilitated distributed design checkout since the designer and reviewer could check their own portion of the design from their own office.
Infrared Search and Track processing detects unresolved (sub-pixel) moving objects in an infrared image. Performance is limited by scene clutter (clouds and terrestrial background). Algorithms are applied to register multiple frames of data, filter out clutter, boost target signatures, and thereby detect and track targets. The detected targets are displayed with graphic symbology overlays on top of the original scene data.
The design can handle either a standard video input stream or a custom 135 Mbyte/second digital data sensor stream. The video output displays sensor imagery with graphic symbology overlays. Four custom modules were designed for interfaces. COTS modules were used for the signal processing and host controller. The IRST processing system virtual prototype totals over 39,000 lines of VHDL. An additional 18,000 lines of software implement the algorithms and control software.
The Data Input/Distribution module is a card with 35 ICs, including 4 FPGAs. We used two daughter cards to adapt to sensor-specific electrical and timing interfaces. A custom interface is used for control and status. A Mercury RACEWAY interface permits high-speed video transfer to the processor modules. A video output displays one of the two sensor inputs with symbology. A video crossbar connects the two daughter cards, the video output, and the RACEWAY interfaces. Routing logic under software control passes the image to selected processing elements in the multiprocessor system. The IRST processing system soft ware contains 18,000 lines of code.
All hardware designs checked in the virtual prototype worked in the laboratory the first time (Figure 6). Some analog portions could not be checked, and these required minor tuning. The virtual prototype provided a forum for hardware and software engineers to discuss details sooner and change early system concepts when performance simulation or early VHDL modeling showed timeline problems. Many software errors were fixed before the laboratory checkout. Running the actual software on the ISA model identified hardware design problems not discovered in standard VHDL simulation. Simulation run times were so slow that we could explore only those activities near the beginning of the hardware initialization cycle (the first 150 milliseconds). We could test only a limited portion of the software because of the slow simulation times and because the operating system could not be run on the virtual prototype; only software that did not use operating system calls or the run time system could be executed. There is a clear need for better simulation run times. Executing the operating system and run time software is essential to fully check out the software and refine the hardware/software design.
The virtual prototype changed the development schedule such that although the design stage lasted longer than in conventional development, the hardware checkout and system integration went much faster.
Our RASSP Benchmark 1 is phase one of a two-phased development of a synthetic aperture radar (SAR) processor. The Benchmarks are another set of means by which the government assesses the progress the contractor is making toward program goals. RASSP chose the SAR processor as the initial benchmark because it is a computationally challenging system that is a good test vehicle for architectural modeling and virtual prototyping. The intent of RASSP Benchmark 1 was to obtain metrics on the developer's initial design process, and to start developing the metrics for comparing the usefulness of design processes and changes to those processes.
The first step in the virtual prototype design process was to evaluate several different designs with different hardware/software configurations. There were four options evaluated for the implementation of the SAR processor before detailed modeling began. Three estimation programs were used to evaluate the top level trade-offs. A spread sheet model was developed to quickly evaluate weight and power as board count varied. Another spreadsheet model was used to estimate the development and unit costs based on typical tasks durations, lines of code, types of boards, and kinds of enclosures. Finally, the life cycle costs (LCC), including development costs, were estimated using the much more complex PRICE-H and PRICE-HL parametric cost estimation models. This methodology is significant because it allows the designer to understand all aspects of partitioning functions into various hardware/software combinations.
The level of simulation which we wanted to achieve was that the virtual prototype should be identical, from a software perspective, to the physical prototype. We modeled the interfaces and functions of the key elements so that they could be controlled by the same application code being created for the hardware. This approach provided the co-design between software and hardware which was desired.
MIT Lincoln Lab created a VHDL Executable Requirement. This provided an input data set, a VHDL model of the input and output source and sink, and a simple VHDL behavioral model of the SAR processor. The virtual prototype developed during the benchmark was to be tested by substituting for the behavioral model of the executable specification.
To summarize the VHDL modelling effort, models for a number of interfaces, components, and algorithms were developed. Many of these models are of industry standard components. Capturing the functionality of the various portions of the SAR processor in a virtual prototype will foster use for future designs, enabling a very quick turn around on model year upgrades. Key to our methodology was the ability to execute application software on the virtual prototype. This allowed the VHDL model and software to be integrated, tested, and corrected before hardware fabrication. As a result, physical hardware and software integration will be greatly simplified and less costly. The application software was required to be in Ada. A total of 2,301 lines of executable code were written. The average productivity was 33 LOC/day.
Some phases of the product development process are accelerated a great deal while others remain nearly the same in duration. Preliminary Design Phase takes nearly as long with RASSP as without. This is because the use of RASSP Top Down Design methods and Virtual Prototyping demand more work prior to PDR than the traditional methodology. Detail Design Phase is substantially reduced because the Virtual Prototype has matured the design significantly. The discipline and simulate-before-build philosophy of RASSP make the E&MD Phase much shorter. This differs from a more traditional approach that allocates very large blocks of time to system integration and the correction of errors carried from the beginning of the design process. Rework time is reduced or eliminated.
The largest contributor was Top Down Design using VHDL which also includes Structured Software Development (we use Ada) for programmable processing elements. Reuse was an important contributor. Finally, situation awareness was cited nearly as often as reuse and significantly more often than improved design automation tools.
The Model Year 0 IRST Image Signal Processor development undertaken as part of the Demonstration portion of the program provides a measure of how we are progressing toward the 4X goal. A comparison with the achieved schedule and cost of the IRST Demonstration with a similar programs and standard models reveals a range of between 2.2X and 2.7X improvement in both. Everything that was simulated using the Virtual Prototype worked the first time. In this case rework time was eliminated. However, integration time was impacted by the need to correct errors in portions of the design that had not been simulated. Integration time was less than that typically associated with a design of this complexity. While quality, measured as fitness for use, was high when the hardware was delivered to the Aircraft, there is clearly room for the additional improvements in quality that will lead to near zero integration time.
Design Reuse -- Our success in the AIRMS IRST Model Year 0 demonstration in achieving a significant speed up in the design process was driven primarily by the use of a HDL-based design process and facilitated by capabilities for remote collaboration. In determining the factors which will lead to reaching our goal of 4X the use of an HDL-based design process was key. However, an important factor in reaching the 4X goal which we have not exercised yet is design reuse. We are now entering a portion of the program in which we will be able to take advantage of design reuse and tools to support it. We are building design reuse utilities into our RASSP Design Environment and we have identified opportunities on both the upcoming demonstration and benchmark work to reuse past designs.
RASSP Design Environment -- The RASSP Design Environment has completed four builds and our first external release. During the next year we will be performing three more builds of the RDE, culminating in our second external release. Key to our efforts in this area in the next year will be completion of a vendor-independent database interface for the RDE. This will allow tools to store data in their own natural data format and for data translators to be invoked automatically if a different data format is required. This approach will speed the integration of tools into the environment and also will allow some access to tool-dependent libraries even without invocation of the tool.
F-14 IRST Demonstration Model Year 1 -- Our objective is to complete Model Year 1 of the F-14 IRST Demonstration in nine months (Figure 7). During this work we will replace seven boards in the current F-14 WRA-2 box which implement two dimensional IRST processing. We will replace these eight boards with two boards to implement the same functionality. One board will be an interface board and the second will implement the current two dimensional processing algorithm. In the process we will capture a complete system interface description and new hardware description in VHDL. We will also define a new system bus based on a standard open systems bus for use in Model Year 2.
F-14 IRST Demonstration Model Year 2 -- During the next year we will begin work on Model Year 2 of the F-14 IRST demonstration (Figure 8). Model Year 2 will implement three dimensional IRST processing in the WRA-2. We will use the interface board and the standard system bus from Model Year 1 and will implement the three dimensional IRST processing in general-purpose processor boards which will fit in the seven remaining slots. The end result of Model Year 2 will be a processor with a peak processing capability at least twenty times higher than the current IRST processor. The Model Year 2 IRST demonstration hardware will be made available to the Navy as a potential upgrade the existing F-14 capability.
SAR Image Processor Benchmark -- Within the next two months we will complete the SAR processor hardware and will have a complete system that processes the full data stream using only four slots of a VME chassis. This system will be compared to the virtual prototype which we have completed to verify the design process and the hardware.
F-15 Radar Benchmark -- During the next year we will execute our next benchmark, a radar processor upgrade for the F-15. This benchmark will replace the current front end portion of the radar with an improved system which both enhances performance and reduces cost. If successful, this hardware will have the potential to be used in over a thousand planned radar systems with potential cost savings to the government of over one hundred million dollars.
[1] Mark Richards, “The Rapid Prototyping of Application Specific Signal Processors (RASSP) Program: Overview and Accomplishments,” Proceedings of the First Annual RASSP Conference, August 1994.
[2] Jim Summers, “Rapid Prototyping and the RASSP Design Environment,” Proceedings of the First Annual RASSP Conference, August 1994.
[3] Mike Vahey, “Lockheed's Image Signal Processor RASSP Demonstration,” Proceedings of the First Annual RASSP Conference, August 1994.
[4] Ray Dreiling, “Processes and Experiences in VHDL Top Down Design,” Proceedings of the First Annual RASSP Conference, August 1994.
[5] Cory Myers, Paul Fiore, and J.P. Letellier, “Rapid Development of Signal Processors and the RASSP Program,” Proceedings of the 1994 IEEE International Workshop on Rapid System Prototyping, June 1994.
[6] Fred Shirley, “Rapid Prototyping of Application-Specific Signal Processors Architectural Issues,” SPIE, July 1994.
[7] Sanders RASSP Team, “RASSP Process Document,, Sanders RASSP Team Document Number AVY-L-S-00078-101-A, June 1994.
[8] Sanders RASSP Team, “RASSP Architecture Metrics,” Sanders RASSP Team Document Number AVY-L-S-00076-101-A, June 1994.
[9] Sanders RASSP Team, “RASSP Architecture Issues,” Lockheed RASSP Team Document Number AVY-L-S-00080-101-H, June 1994.
[10] S. Famorzadeh, T.W. Egolf, V.K. Madisetti, “Rapid Systems Prototyping Models &Views,” Georgia Tech, June 10, 1994.
[11] Sanders RASSP Team, “RASSP Process Document,” AVY-L-S-00078-101-B.
[12] Jim Summers, Motorola, “Rapid Prototyping and the RASSP Design Environment (RDE)."
[13] “Reengineering and Beyond,” Boston Consulting Group, 1993.
[14] M. Hammer, J. Champy, “Reengineering the Corporation: a Manifesto for Business Revolution,” Harper Business, 1993.
[15] Hughes Aircraft Company Radar Systems, McDonnell Douglas Aerospace, “Advanced Design for Quality Avionic Systems.” March 1993.
[16] Advanced Avionics Architecture and Technology Review Final Report, Volume 1: Avionics Technology, 6 August 1993, Naval Air Systems Command, Arlington, VA.
[17] Architecture Specification for Pave Pillar Avionics, Air Force document number SPA90099001A, January 1987.
[18] JIAWG Advanced Avionics Architecture (A3) Standard, JIAWG document number J87-01, 1 December 1991.
[19] Dechant, Jagodnik and Wood, The Advanced Onboard Signal Processor: Brassboard Development and Space Qualification Plans, part of RADC-TR-87-268, January 1988, Rome Air Development Center, Griffis Air Force Base, NY.
[20] SAFENET Tutorial, NGCR Users Conference, 16-18 February 1993, Space and Naval Warfare Command, Arlington, VA.
[21] Swartzlander and Yang, AOSP Macro Function Signal Processor VHSIC Insertion, part of RADC-TR-87-268, January 1988, Rome Air Development Center, Griffis Air Force Base, NY.
[22] Department of Defense Trusted Computer Systems Evaluation Criteria (“Orange Book”), DOD 5200.28-STD, December 1985.
[23] Larry Scanlan, “The Road to 4X,” in the Proceedings of the Second Annual RASSP Conference, July 1995.
[24] B. Hood, C. Myers, “RASSP: Viewpoint from a Prime Developer,” Proceedings on the First Annual RASSP Conference, August 1994.
[25] Honeywell, “Graphics Processor Description VHDL Methodology: Working Document,” 1991.
[26] W. Lee, M. McCollough, M. Vahey, “Classification of VHDL Models,” Proceedings of the Spring 1995 VIUF Conference, April 1995.
[27] R. Dreiling, P. Kalutkiewicz, M. McCollough “Model Development within the RASSP Virtual Company Environment,” Proceedings of the Spring 1995 VIUF Conference, April 1995.
[28] Vahey et al, “A Virtual Prototype VHDL Development Methodology.” VIUF Spring 95.
[29] Dreiling et all, “Model Development within the RASSP Virtual Company Environment,” VIUF Spring 95.
[30] R. Dreiling, “Processes and Experiences in VHDL TopDown Design,” First Annual Conference on the Rapid Prototyping of Application Specific Signal Processors, August 15-18, 1994.
[31] S. Famorzadeh, R. Dreiling, M. Falco, et al., “Rapid Prototyping of DSP Algorithms on COTS Systems, " First Annual Conference on the Rapid Prototyping of Application Specific Signal Processors, August 15-18, 1994.
[32] “Hughes to gather IR data on theater missiles,” Aviation Week and Space Technology, vol. 140, num. 21, P 20,21, May 23, 1994.
[33] CUSeeMe Advanced technology Group in network resources, Cornell University, Information Technology Department.