How rapid is rapid prototyping?

How rapid is rapid prototyping by Bob Madahar and Ian Alston

New methodologies engineering processes and support environments are beginning to emerge for embedded signal-processing systems The main objectives are to enable industry to field state-of-the-art products in less time and with lower costs including retrofits and upgrades based predominantly on commercial off-the-shelf (COTS) components and the model-year concept One of the cornerstones of the new methodologies is the concept of rapid prototyping This is the ability to rapidly and seamlessly move from functional design to architectural design to implementation through automatic code generation tools onto real-time COTS test beds This paper tries to quantify the term rapid and provides results-metrics-from two independent benchmarks a radar and sonar beamforming application subset The metrics show that the rapid prototyping process may be 16 times faster than a conventional process

1 Introduction

The trinalional European EUCLIDEurofinder delence project called ESPADON (Environment for Signal Processing Application Development and Prototying) was completed in September 2001 The primary objective of this three year project was to improve significantly (ie reduce the cost and timescales ol) the process by which complex military digital processing systems are designed developed and supported A new design methodology and supporting development environment has been developed to support this aim through reuse concurrent engineering rapid insertion of COTS technology and the key concepts of rapid and virtual prototyping The latter two concepts are an integral part of the model-year concept adopted by ESPADON and developed under the US RASSP programme2

A brief summary of these techniques and developments within ESPADON in the context of rapid prototyping (RP) is presented in the following two subsections

The methodology A risk-driven iterative development process has been

identified This is shown in abstract form in Fig 1 and is underpinned by the following five key processes

Specification refinement of the requirements into an

Model-year concept Given an inital system that has been developed using a model-based design methodology that Eully supports incremental refinement the next upgrade of the system such as for a technology refresh can be completed with one year

engineering specification

Functional design the lunctional parts of the component specifications are modelled and simulated and proven for correctness as a whole model The model is independent of the implementation Architectural design coslperformance trade-off studies are carried out and Ihe most eliective architecture is chosen Implementation the result of the current design iteration essentially the production and test of hardware and software integration of the software on the target COTS platlorm and validation of the component System review the final process which determines whether the particular phase oi the system development has met its requirements and ameliorated the major risks belore proceeding to the next phase or iterating around the same phase again

Each of the key processes above is itself composed of the generic abstract iterative process shown in Fig 2 This again is a risk-driven process where the risks are analysed and a plan euroormulated the work defined the developments undertaken the results validated and the complete outcomes reviewed by the EXIT or REFINE review

The overall aim of the methodology is to enable the developer to iterate rapidly to the final solution for the particular system development being undertaken In the case of rapid prototyping it is to move rapidly and seamlessly from lunctional design to architectural design to implementation through automatic code generation tools onto real-time COTS test beds This enablcs behavioural and periormance measurements to

ELECTRONICS amp COMMUNICATION ENGINEERING JOUIWAL AUGUST 2002 155

Fig 1 Iterative development process

key

to system development

development control

process flow ---+ information flow -------b

be made so as to refine the functional model and the architectural design solution to satisfy the system requirements

The overall environment An integrated software design environment the

ESPADON Design Environment (EDE) was developed to support the methodology and process described above It is based on a collection of COTS software tools that were selected as the most suitable after a detailed review and evaluation of many commercial EDA (electronic design automation) tools This environment is shown in Fig 3 Two of the tools Ptolemy and Gedae4 form the

Fig 2 Abstract iterative process

core of the environment as they fully support and are integral to the concept OP rapid prototyping

In this paper we try to quantify the term lsquorapidrsquo by providing results-metrics-from two independent benchmarks a radar and a sonar beamforming application subset which were performed using the environment and Ptolemy and Gedae respectively

2 The benchmarks

The choice of signal -processing application for the benchmark was arrived at by considering two factors

from previous process

to nextprevious processes

activity flow -+ information flow ----

156 ELECTRONICS amp COMMUNICATION ENGINEERING JOURNAL AUGUST 2002

One was that it must bc a common application for both the radar and sonar domains so that the conventional development process and its associated metrics would be known or could be confidently estimated The second was that a common processing function of the application should cxist lor both domains (for cross-comparison) and that this should be sufficiently small to enable the benchmark measurements to be made within the time and effort available yet of sufficient size (in terms of functionality and development effort) to be acceptable

Beamforming the processing

I c = Q 0 W P U I n L gt W 3 2 G

Algorithm prototyping I d 7 1 Implementation

target-porting kit (rapid prototyping)

I Y a x 1 L uliij 0ldquo

Functional design Architectural design

of sensor signals into directional Fig 3 ESPADON Design Environment beams was selected as the application that would be benchmarked It is a generic processing function for both domains and satisfies the selection criteria The functional processing chain for the radar and sonar beamformer benchmarking applications is described in the next two subsections

Radar The application subset is hom a ship-based X-band air

surveillance radar with a vertical array of for example 8 transmit and receive elements Each element is a horizontal linear stripline array of dipoles Elevation beams are formed by the digital beamformer which performs an point fast Fourier transeuroorm (FFT) algorithm on the outputs of the 8 receiver channels In this way a multibeam receive system is formed Fig 4 The benchmark concerns only the receiver beamforming function the transmit beamforming function is implemented by an analogue system

The beamformer is adaptive with respect to the shiprsquos course and speed and the shiprsquos roll and pitch movements This results in a phase correction that is applied to thc complex data stream prior to the beamforming together with windowing and calibration correction The functional processing chain is shown in Fig 5 The boxes shown as lsquoCalibrationrsquo and lsquoBeam calculationrsquo were developed as part of the rapid prototyping process using Irsquotolemy The other functions except euroor the functions in the dashed boxes which were not used were primarily for inputloutput were resident on the host machine and were part of the stimuli generator andor display

The target platform was an embedded VME (Versa Module Eurocard) system from Mercury Computer Systemsrdquo This comprised three Mercury motherboards each connected via interlink modules through two ports to the high-speed IzACEway interconnect between the

plane wave impinging

1

Fig 4 Multibeam receive system

ELECTRONICS amp COMMUNICATION ENGINEERING JOUKNAL AUGUST 2002 157

Beamformer (BF) functional diagram

Fig 5 Radar functional processing chain

boards One motherboard was equipped with two daughter boards with two Motorola PowerPC Altivec processors each and the two other motherboards with one daughter card with two Altivecs and one daughter card with 512 Mbyte memory each This resulted in a machine with eight processing nodes and bulk memory that was used for real-time data play-back of the (stored) stimuli generator data and for logging of the intermediateoutput results of the application

A target porting kit (see Fig 3) had to be developed to support the Mercury platform irom Ptolemy In addition other specific enhancements had to be carried out to support the RP process and the benchmark with this target These were enhancements to the software support (libraries etc) for the Synchronous Data Flow (SDF) and the Code Generation C (CGC) computation domains in Ptolemy which are core to the RP process

Some of the key features of the final Mercury RP

conventional adaprive data display beamformer oeamformer processing 3 processing

St hydrophone

data store -

beamforming coefficients conventional beams out

n +H-JampLi$jijFH-ZptG+ beamformer and reverberation

base bander selecrion canceller

baseband hydrophone conventional beams and coefficients adapted beams out samples into adaptive beamformer

Conventional beamformer Adaptive beamformer

Fig 6 Sonar overall functional processing chain (a) and beamformer functions (b)


environment used for the benchmark were

additional library components Radar Library-5 components VSIPL Core Light library7- 11 components and Support Library (eg components for parallel operation) - 19 components

0 synchronised communications and data transfer between

machine SuniPC

FPGA 2xDBV66 SPARC CPU50 TCPIP board 2x6 Sharc DSPs SCS12 disk

processors 0 support for standard VSIPL

library and Mercury trace tools

0 multi- and complex-interleave functions needed for the Fig 7 Sonar hardware configuration corner-turn process extension to the CGC domain to handle a multiprocessor architecture-functions lo generate C code compile load and run for each processor explicit control flow in the data-flow graphs colour discrimination of functions between standard Ptolemy functions that use only the standard C library VSIPI functions that use the VSIPL Core Light library as well and application-specific functions for the benchmark

Sonar The application subset is from a generic ship submarine

based active sonar system It covers the core functionality oE a conventional beamformer and an adaptive beamformer where the reverberation due to the propagation environment is estimated and cancelled For a given sonar array heading and speed the reverberant returns from any particular direction have an induced Doppler which depends only on the directions of transmission and reception non-zero intrinsic Doppler being ignored This means that all beams receive their reverberant noise in a given Doppler bin from the same direction This includes the few beams whose directions align with the direction of arrival of the reverberant returns being considered which of course will have their zero Doppler ridges at the Doppler bin being considered In fact it is these few beams which are used in the adaptive algorithm as reference beams lo sense the reverberation at the Doppler bin in question and cancel it from all other beams

The overall functional processing chain and the beamformer functions are shown in Figs 6a and 6 respectively The latter were developed for the W benchmark and interfaced to other eurounctions primarily for inputoutput such as the scenario generator and andor display resident on the host machine

The sonar benchmarking application was developed within the RP process using Gedae with initial and final target embedded VME systems each connected to a Sun workstation The initial embedded system was from SKY Computers and was used to develop the benchmark application functions This platform consists ol a Force

SPARC CPUSO host machine and two quad PowerPC Allivec processor (Merlin) processing boards connected together by the backplane SKY channel interfacex The final system was a subset developed on the EUROPKO project and was used to complete all the sonar benchmark measurements This platlorm was chosen because it is based on dillerent processors to the other ESPADON target platforms and would demonstrate the hardware independence of the RP process It has a number of DBV66 boards each with six Analog Devices SHARC DSP processors In the basic configuration Fig 7 there are two DRV66 cards connected via the VME to the host board lor code load All further communication between SHARC processors is performed using point-to- point SHARC links which are capable of 40Mbytes Multiple DUV66 boards are connected using the internal SHARC links to support larger SHAKC networks

A target porting was developed euroor this platlorm for Gedae It is built on underlying support software for the platrorm such as the Blue Wave IDE6000 - V4012 the operating system Virtuoso 41-R204 for Solaris and the Analog Devices Compile~V33 for Solaris The overall ESPADON design environment enabled the Gedae data flow graphs to be developed lor the benchmarking functions across a number of platforms including the host by different users and simply imported andor ported to the benchmarking platform

The key functions developed lor the benchmark were

Data generator Data is read in from a file that has been generated from the scenario simulator The simulator provides hydrophone data (128 hydrophones) 01 complex baseband reverberant lime series data across an array ol specified elements Control interface A control box responsible for defining parameters that would possibly be controlled through the operator MMI (man-machine interface) Examples are Dolph Chebyshev coefficients beam- shaping coefficient I T T size minimum number of Doppler bins energy lhrcsholding lactor and integration period

ELECTRONICS amp COMMUNICATION ENGINEERING JOURNAL AUGUST 2002 159

Table 1 Measurements from sonar benchmark

Conventional beamforming This comprises components that are to be used within the adaptive beamiorming functionality The current function box has three outputs

beam samples (for each beam) steering vectors ( for each hydrophonebeam)

0 weighting vectors (for each hydrophonebeam)

The last two output parameters are not essentially part of a conventional beamformer but are formed as they are required parameters for the adaptive part of the benchmark functionality Reference beam selection -algorithms to select the beams whose directions align with the direction of arrival of the reverberant returns being considered Adaptive reverberation cancelling-adaptive algorithms that use the reference beams to sense the reverberation at the Doppler bin in question and cancel it from all other beams

For the benchmark the conventional beamformer being fully understood and developed many times previously could be implemented in its entirety within the Gedae environment using the lsquoembedded functionsrsquo available within the tool at both the host and optimised target level The adaptive beamformer however required significant algorithm investigation and the development of specialist sonar library components-ten in total-to satisfy the needs of the specification These components were all generated in high-level C code and were not optimised for target execution

3 The metrics

The objective of the benchmarks was to measure the performance of the ESPADON rapid-prototyping signal- processing design environment with respect to the project goals namely reduction in the product lifecycle cost and lifecycle time and improvement of the product quality

The measurements were through small design exercises developing the benchmark applications described earlier in order to capture basic metrics regarding the process and the product The lundamental performance process metrics include design cycle time non-recurring cost ease of use and supportability Performance product includes cost to manufacture cost to maintain conformance to requirements and dependability

For each benchmark cycle the benchmarks were structured to

(a) Evaluate the RP process Comparison with current practice develop current

Performance metrics employ metrics to measure

Improvement identify weaknesses in the design

practice base-line costs and schedule

and substantiate improvements

process (b) Evaluate the tool integration

Integration verify the degree of tool integration

Ease of use provide qualitative ease of use

Improvement identify weaknesses or missing

including libraries and databases

evaluation for the tools and processes

elements in the tool set (c) Evaluate the signal-processing system (products)

the hardware and software architectures

and software to supplied requirements

Architecture assess the suitability and scalability of

Compliance measure the compliance of hardware

Cost provide current practice cost comparison

Hence the metrics that need to be measured are of different types They can be summarised as belonging to one of the following metric sets

0 principal and supporting metrics tool-oriented process metrics

0 application complexity metrics 0 product complexity metrics 0 product performance metrics

The measured metrics and a summary of the benchmark results are presented in the next section

4 The measurements

There are distinct differences in the benchmark measurements of the sonar and radar applications These are attributable to the maturity of the two tools used in the rapid-prototyping process as is evident in the graphs presented in this section

Sonar Table 1 shows the measurements from the first


benchmark the development of a conventional beamformer implemented on the initial target platform The beamformer functions are shown in Fig 6b up to and including the Doppler binner Two overall design iterations were required before arriving at a compliant solution The baseline estimate is Crom conventional developments lor the same functions by Thales Underwater Systems who undertook the sonar benchmark activity We attribute the significant productivity improvement to two factors One is that the conventional beamformer is a fully understood and specified capability implemented many

I 180 r

20 0 I I I I I I I I I I I

Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec

2000

Fig 8 Sonar benchmark primitive count

times within the company on a variety of different target architectures The second is that the RP process enabled the application to be implemented in its entirety within the Gedae environment using the lsquoembedded functionsrsquo available within the tool at both the host and optimised target level No specific Sonar Library components had to be generated for this application resulting in a high level ol reuse and productivity

In the case of the adaptive beamformer the improvement lactor is less because a number of new embedded functions had to be developed as shown by Fig 8 Ten library components were developed with approximately 1000 lines of code in total across all components These components were all generated in high-level C code and were not optimised for target execution As can be seen in the midclle oi the graph it was sometimes necessary to remove boxes during redesign This redesign usually required the development of new user-generated primitives to provide the required capability

Once a level of understanding ol a tool had been achieved by the developers a significant reduction in faults was identified whilst implementing the adaptive beamformer as well as reduced time to locate and remedy such faults (Fig 9) This meant that execution of the capability on the target machine resulted in no functional errors and allowed the developer time to concentrate on elficient partitioning of the capability rather than its algorithmic performance

Another important metric measurement was the number ot iterations of the design as shown in Table 2 Though more than planned the rapidity with which designs could be iterated within the RP process enabled high productivity factors to be maintained In fact there were many more very short iterations that were not reported simply because they were too short but nevertheless important in converging to an acceptable solution

The actual measurements ol the adaptive beamformer benchmarks showed that the total time for development was 1113 hours compared to 2737 hours using

14 r 12

10 - 2 8

s 6 4

2 n


2000

Fig 9 Sonar benchmark fault count


Table 2 Number of iterations for the sonar design

Planning Specification Data generator Conventional beamformer Adaptive reverberation canceller Time-varying gain Reference beam selection Control interface Conventional beamformer

Total iterations

Planning Specification Functional design Functional design Functional design Functional design Functional design Functional design Architecture design

1 1 1 1

15 5 7 1 2

34

Table 3 Results for 4 design iterations of the radar benchmark (DMA = direct memory access TBD = to be determined DX MCS = high-speed transfers Mercury Computer Systems)

No of channels 8 8 8 8 No of sweeps No of processors Input data Output data Corner-turn RACE++TM peak load Latency Performance

17 4 (+ 2) DMA (DMA) 4+4 TBD 1 burst 25 ms

Support variable burst length Yes Desian time 72 h

17 5 (+ 2) DMA ( D M 4 no TED 1 burst 21 ms Yes 16h

17 4 t 4 preload MA) 4+4 TB D 2 bursts 95 ms Yes 12 h

17 8 preload (DX MCS) 8 - 4 53 1 burst 9 ms Yes 16h

conventional methods This gives a productivity improvement o l x24 In terms of the reduction of coding errors the comparison for the adaptive beamformer shows a factor of 8 (conservative) reduction compared to conventional methods This is attributable to the RP process providing algorithm developerssystem analysts and software developers with the benefit of using a common development environment

Radar In this case a significant part of the benchmark work

was tightly coupled to enhancing the Ptolemy support

environment euroor the target multiprocessor architecture and to integrating it within the overall ESPADON design environment Hence the metrics covered more aspects of the RP process than the sonar benchmark In particular metrics were measured related to the application complexity to the methodology and tool support to the performance of the application and the libraries to the validation process and to the overall RP process In total the benchmark application required completion of 8 design iterations before converging to a performance-compliant solution Results for four of the design iterations are shown in Table 3 Note that the

loo r 1 400

Definition Bare beamformer 0 Full beamformer Total

Fig 10 Duration of radar design and development work

design time is without extensive functional testingvalidation and the performance is an average measurement for one burst

Figs 10 11 and 12 summarise the measurements for the overall design test and validation and application complexity respectively The vertical axis on the right presents cumulative totals

The overall time measured to implement (coding) and test integrate the application was 3545 hours Thales Naval Systems who undertook the radar benchmark have calculated a baseline figure of 481 hours for a conventional process Hence this gives an improvement factor of 14 The lower figure is attributable to the inany more enhancements that had to be

162 ELECTRONICS Rr COMMUNICATION ENGINEERING JOURNAL AUGUST 2002

200 60

50 Z 40 150 $

c - 2 30 100 +j

I

20

10 50

n n

0 Test bare beamformer 0 Test full beamformer Review Total

carried out with Ptolemy (see Fig 12) thereby reducing the level of (re)-use of existing functions for the benchmark Future radar developments would show a higher factor with a better supported Kp process In euroact an independent radar benchmark shows an improvement factor oi 2615

5 Conclusions

An adaptive beamformer application for a radar and a sonar has been successfully designed implemented tested and benchmarked using the ESPADON design environment and the ESPADON rapid-prototyping process Productivity improvement factors of 14 and 24 were demonstrated for the radar and sonar beamformer applications respectively Hence we can be confident that a halving of the embedded signal-processing system development lifecycle can be achieved using the rapid-

50 000

45 000

40 000

35 000

$ 30000

5 25000 8

_ E 20000 (I)

- 15 000

10 000

5000

0

Fig 11 Duration of radar test and validation work

prototyping methodology and support environment A much higher factor of x16 was achieved for a conventional sonar beamrormer This implies that significantly higher factors are possible through the use of a common RP process and environment and the development of application domain libraries to maximise future (re)-use ol signal-processing functions

An important finding and a factor in achieving these productivity gains is that the functional architectural and implementation designs are done simultaneously instead of sequentially simply because it is so easy and fast to do these with the KP environment This demands a different process one that allows for more rapid iterations of higher frequency Also many feedback loops are performed in the redesign of the environment This allows for very rapid iterations to be made in arriving at the correct design and reduces error propagation The latter also benefited from a common RP environment and

BF= beamformer generated lines of code number of Ptolemy functions

Matlab bare BF bare BF bare BF bare BF bare BF full BF step 0 step 1 step 2 step 3 step4

160

140

Vl 120 5 -

0

100 2

80 - s 60 g c

n 40 5 20

0

Fig 12 Radar design complexity


the exchange of information in the form ol graphical designs that can be quickly integrated into t h e overall functional design

Signal-processing functions are only one pa r t of an embedded sensor system Further work needs to be done to extend the RFrsquo process to include other functions such as system control front-end interfacing and processing back-end data processing and the HCI (human computer interface) for commensurate productivity improvements at the system level These topics require fur ther research and development

Acknowledgments

The work reported in this paper has been carried out on the ESPADON EUCLIDEurofinder programme Project RTP229 with support Irom the UK French and Dutch ministries of defence and participating companies The authors are grateful for this support and would like to acknowledge the contributions of all the ESPADON team members especially those from Thales Naval Neclerland and Thales Underwater Systems who carried ou t the benchmarks

Th i s paper was first presented at the internal BAE SYSTEMS Signal and Data Processing Conference 5th-7th March 2002 Dunchurch Park Conierence Centre UK (Conference Proceedings pages 1-21) The work has also been presented at the Embedded Systems Show Rapid and Virtual Prototyping Technical Seminar Excel Exhibition Centre London 17th May 2001

References

1 lsquoESPADON final reportrsquo ESPADON Programme Deliverable Project EUCLID-CEPA 2-Eurofinder Contract No 97 34 391 00 470 75 65 Report No Dex 45990 Thales Airborne Systems September 2001

2 PRIDMORE J et aZ lsquoModel-year architectures euroor rapid prototypingrsquoJ VLSZSignaZ Prucess January 199715 (1-2)

3 Ptolemy See httpptoleniyeecsberkeleyeclu (University

4 Gedae See httpwwwgedaecom (Blue Horizon

5 Mercury Computer Systems Inc See httpwwwmccom 6 Motorola Inc See httpe-wwumotorolacom 7 VSIPL See httpwwwvsiplorg 8 SKY Computers Inc See httpwwwskycomputerscom 9 EUROPRO Consortium EUROPRO Final Report Project

P21040-HPCNEUROPRO V11 Thomson Marconi Sonar Sophia Antipolis France May 1999

10 lsquoBlue Wave Systems DBV66 ADSP-2106x Carrier Board Technical Reference Manualrsquo See htlpwwwbluewscom (Bluewave Systems Inc)

11 Analog Devices Inc See httpwwwanalogdevicescom technologydsp

12 Blue Wave IDE6000 Bluewave Systems Inc See httpwwwbluewscom

13 Virtuoso RTOperating System See httpwwwwindrivercom (formally owned amp distributed by httpwwweoniccom)

14 SCHURER H and HUNINK J J lsquoRapid prolotyping oilsquo radar signal processing algorithmsrsquo ProRISC99 IEEE Workshop on Processing Integrated Systems and Circuits

pp83-96

oi California Berkeley USA)

Development Software USA)

25th-26th November 1999 Mierlo The Netherlands I5 PURDIE B A lsquoAn assessment of rapid prototyping using

Locltheed Marlinrsquos GEDAE software toolsetrsquo SBMS-16296- A-TNl-ROO3 SMART Project July 2000 Alenia Marconi Systems Limited

OIEE 2002 Received 11th April 2002


Fig 1 Iterative development process

key

to system development

development control

process flow ---+ information flow -------b

be made so as to refine the functional model and the architectural design solution to satisfy the system requirements

The overall environment An integrated software design environment the

ESPADON Design Environment (EDE) was developed to support the methodology and process described above It is based on a collection of COTS software tools that were selected as the most suitable after a detailed review and evaluation of many commercial EDA (electronic design automation) tools This environment is shown in Fig 3 Two of the tools Ptolemy and Gedae4 form the

Fig 2 Abstract iterative process

core of the environment as they fully support and are integral to the concept OP rapid prototyping

In this paper we try to quantify the term lsquorapidrsquo by providing results-metrics-from two independent benchmarks a radar and a sonar beamforming application subset which were performed using the environment and Ptolemy and Gedae respectively

2 The benchmarks

The choice of signal -processing application for the benchmark was arrived at by considering two factors

from previous process

to nextprevious processes

activity flow -+ information flow ----















1









St hydrophone

data store -











machine SuniPC




















3 The metrics

























4 The measurements





I 180 r



2000







14 r 12

10 - 2 8

s 6 4

2 n


2000





Total iterations


1 1 1 1

15 5 7 1 2

34












loo r 1 400







200 60

50 Z 40 150 $

c - 2 30 100 +j

I

20

10 50

n n



5 Conclusions


50 000

45 000

40 000

35 000

$ 30000

5 25000 8

_ E 20000 (I)

- 15 000

10 000

5000

0






160

140

Vl 120 5 -

0

100 2

80 - s 60 g c

n 40 5 20

0





Acknowledgments



References












pp83-96




















1









St hydrophone

data store -











machine SuniPC




















3 The metrics

























4 The measurements





I 180 r



2000







14 r 12

10 - 2 8

s 6 4

2 n


2000





Total iterations


1 1 1 1

15 5 7 1 2

34












loo r 1 400







200 60

50 Z 40 150 $

c - 2 30 100 +j

I

20

10 50

n n



5 Conclusions


50 000

45 000

40 000

35 000

$ 30000

5 25000 8

_ E 20000 (I)

- 15 000

10 000

5000

0






160

140

Vl 120 5 -

0

100 2

80 - s 60 g c

n 40 5 20

0





Acknowledgments



References












pp83-96













St hydrophone

data store -











machine SuniPC




















3 The metrics

























4 The measurements





I 180 r



2000







14 r 12

10 - 2 8

s 6 4

2 n


2000





Total iterations


1 1 1 1

15 5 7 1 2

34












loo r 1 400







200 60

50 Z 40 150 $

c - 2 30 100 +j

I

20

10 50

n n



5 Conclusions


50 000

45 000

40 000

35 000

$ 30000

5 25000 8

_ E 20000 (I)

- 15 000

10 000

5000

0






160

140

Vl 120 5 -

0

100 2

80 - s 60 g c

n 40 5 20

0





Acknowledgments



References












pp83-96










machine SuniPC




















3 The metrics

























4 The measurements





I 180 r



2000







14 r 12

10 - 2 8

s 6 4

2 n


2000





Total iterations


1 1 1 1

15 5 7 1 2

34












loo r 1 400







200 60

50 Z 40 150 $

c - 2 30 100 +j

I

20

10 50

n n



5 Conclusions


50 000

45 000

40 000

35 000

$ 30000

5 25000 8

_ E 20000 (I)

- 15 000

10 000

5000

0






160

140

Vl 120 5 -

0

100 2

80 - s 60 g c

n 40 5 20

0





Acknowledgments



References












pp83-96













3 The metrics

























4 The measurements





I 180 r



2000







14 r 12

10 - 2 8

s 6 4

2 n


2000





Total iterations


1 1 1 1

15 5 7 1 2

34












loo r 1 400







200 60

50 Z 40 150 $

c - 2 30 100 +j

I

20

10 50

n n



5 Conclusions


50 000

45 000

40 000

35 000

$ 30000

5 25000 8

_ E 20000 (I)

- 15 000

10 000

5000

0






160

140

Vl 120 5 -

0

100 2

80 - s 60 g c

n 40 5 20

0





Acknowledgments



References












pp83-96








I 180 r



2000







14 r 12

10 - 2 8

s 6 4

2 n


2000





Total iterations


1 1 1 1

15 5 7 1 2

34












loo r 1 400







200 60

50 Z 40 150 $

c - 2 30 100 +j

I

20

10 50

n n



5 Conclusions


50 000

45 000

40 000

35 000

$ 30000

5 25000 8

_ E 20000 (I)

- 15 000

10 000

5000

0






160

140

Vl 120 5 -

0

100 2

80 - s 60 g c

n 40 5 20

0





Acknowledgments



References












pp83-96









Total iterations


1 1 1 1

15 5 7 1 2

34












loo r 1 400







200 60

50 Z 40 150 $

c - 2 30 100 +j

I

20

10 50

n n



5 Conclusions


50 000

45 000

40 000

35 000

$ 30000

5 25000 8

_ E 20000 (I)

- 15 000

10 000

5000

0






160

140

Vl 120 5 -

0

100 2

80 - s 60 g c

n 40 5 20

0





Acknowledgments



References












pp83-96







200 60

50 Z 40 150 $

c - 2 30 100 +j

I

20

10 50

n n



5 Conclusions


50 000

45 000

40 000

35 000

$ 30000

5 25000 8

_ E 20000 (I)

- 15 000

10 000

5000

0






160

140

Vl 120 5 -

0

100 2

80 - s 60 g c

n 40 5 20

0





Acknowledgments



References












pp83-96









Acknowledgments



References












pp83-96







Documents

How rapid is rapid prototyping?