PROCEEDINGS OF SPIE

SPIEDigitalLibrary.org/conference-proceedings-of-spie

GBU-X bounding requirements for

highly flexible munitions

Patrick T. Bagby, Jonathan Shaver, Reed White, Sergio

Cafarelli, Anthony J. Hébert

Patrick T. Bagby, Jonathan Shaver, Reed White, Sergio Cafarelli, Anthony J.

Hébert, "GBU-X bounding requirements for highly flexible munitions," Proc.
SPIE 10205, Open Architecture/Open Business Model Net-Centric Systems
and Defense Transformation 2017, 1020503 (25 April 2017); doi:
10.1117/12.2265842

Event: SPIE Defense + Security, 2017, Anaheim, California, United States

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 2/18/2018 Terms of Use: https://www.spiedigitallibrary.org/terms-of-use

 Invited Paper

GBU-X Bounding Requirements for Highly Flexible Munitions

Patrick T. Bagbyb, Jonathan Shavera, Reed Whiteb, Sergio Cafarellic, Anthony J. Hébertb,
a
Air Force Research Laboratory, 101 W. Eglin Blvd., Eglin AFB, FL, USA 32547; bEngility Corporation,
51 3rd Street, Building 9, Shalimar, FL, USA 32579; cMacAulay-Brown, Inc., 4021 Executive Dr.,
Dayton, OH, 45430

ABSTRACT
This paper will present the results of an investigation into requirements for existing software and hardware solutions for open
digital communication architectures that support weapon subsystem integration. The underlying requirements of such a
communication architecture would be to achieve the lowest latency possible at a reasonable cost point with respect to the mission
objective of the weapon. The determination of the latency requirements of the open architecture software and hardware were
derived through the use of control system and stability margins analyses. Studies were performed on the throughput and latency
of different existing communication transport methods. The two architectures that were tested in this study include Data
Distribution Service (DDS) and Modular Open Network Architecture (MONARCH). This paper defines what levels of latency
can be achieved with current technology and how this capability may translate to future weapons. The requirements moving
forward within communications solutions are discussed.
Keywords: Open Architecture, Systems Analysis, Stability, Latency Analysis

INTRODUCTION
The techniques documented herein outline the methods implemented in order to test the throughput and latency of multiple
existing open architecture communication software. In order to assess the latency imposed on the communication path due to the
architecture, a study was performed using different packet sizes transferred at different throughput. The measured throughput
was then calculated in order to determine the overall system throughput and latency measurements of the architecture under test.
The latency effects on the stability of a weapon can be analyzed through the use of control system and stability analyses.
Additionally, these methods can be applied to a myriad of subsystems of any weapon. Prior to the study performed on these two
communication architectures, an investigation into the tolerable delays within a missile simulation was performed in order to set
a baseline requirement for system communication latency. This was accomplished through the use of frequency and time domain
methods which were used to perform stability analyses for a 3-DOF missile simulation with communication latency injected
artificially between missile subsystems. Figure 1 depicts the overall simulation and closed loop control system scheme
implemented in the simulation used for analysis. After implementing the control system methods described, Table 1 provides a
reference to the preliminary requirements derived from these analyses for a produce-and-consume plug-and-play communication
architecture for an Air-to-Ground type weapon. These efforts will evolve into the capability of testing potential future
communication architectures in conjunction with performing stability analyses on systems in a hardware in the loop (HWIL)
configurations utilizing a communication architecture such as Data Distribution Service (DDS) or Modular Open Network
Architecture (MONARCH).

Figure 1: Block diagram of closed loop simulation with communication architecture latencies

DISTRIBUTION A. Approved for public release, distribution unlimited (96TW-2017-0082)

Open Architecture/Open Business Model Net-Centric Systems and Defense Transformation 2017, edited by Raja Suresh,
Proc. of SPIE Vol. 10205, 1020503 · © 2017 SPIE · CCC code: 0277-786X/17/$18 · doi: 10.1117/12.2265842

Proc. of SPIE Vol. 10205 1020503-1

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 2/18/2018 Terms of Use: https://www.spiedigitallibrary.org/terms-of-use

 RESULTS OF INITIAL REQUIREMENTS STUDY

The requirements for architectural latency were determined through the use of both time domain and frequency domain analyses.
In order to understand these requirements, it is necessary to describe the setup and a few of the defining variables behind the
experiment. Initial assessments were performed for weapons intended for ground engagements. The airframes were linearly
modeled using techniques from Missile Configuration Design by S.S. Chin[3]. The selection of airframes under study had
aerodynamic responsiveness ranges indicative of a variety of air-to-ground weapons. The study concentrated on a 3DOF
elevation channel as this is where the primary maneuvers in endgame of the engagement occur with respect to ground targets. A
variety of seekers, actuators, and other weapon components were modeled and used within the analyses to represent state-of-the-
art performance characteristics. The control loops where configured as shown in Figure 1 for analyses and the latency for each
node were derived and are listed in Table 1.

Breakpoint Node Requirements (msec)

Actuator Node 0.5
Gyro Node 0.5
Accelerometer Node 0.6
Autopilot Node 1.6
Guidance Node 1.6
Table 1: Architectural Latency Requirements

PHYSICAL LAYER ANALYSIS

The physical layer used to transfer data between components is an important aspect of the problem at hand. In some cases that
layer will be moving deterministic data at high rates (600 Hz) and are determining factors of the success of the weapon. In the
case of the study performed above, an example of this would be the IMU sending body rates and accelerations to the internal
autopilot unit. Potential physical layer communications could make use of the following protocols based upon the requirements
for total latency and message size requirements[2]:
Ethernet
o Ethernet is ubiquitous and relatively low cost in its most basic form. Common bused Ethernet implementations,
however, use a Carrier Sense Multiple Access/Collision Detection (CSMA/CD) technique for bus access that
is non-deterministic from a timing standpoint and does not necessarily result in guaranteed delivery of any
particular data transmission attempt. There are deterministic Ethernet variants, but some are not based on truly
open standards (e.g., Avionics Full-Duplex Switched Ethernet, or AFDX) and additionally the very low
implementation cost of traditional CSMA/CD Ethernet approaches may not hold for these variants. Switched
Ethernet variants may in general help to mitigate the timing deficiencies, but need further investigation versus
the relevant requirements to establish their viability.
Fibre Channel
o The Fibre Channel family of protocols provides both high performance from an information bandwidth
standpoint and deterministic timing characteristics. The basic underlying Fibre Channel (FC) protocol is a
transport level protocol, but works in conjunction with various specified Upper Layer Protocols (ULPs) to
provide the overall protocol characteristics for particular applications. FC/ULP combinations have been used
in the avionics systems of recent generation combat platforms, including the F-18 Super Hornet and F-35. An
FC/ULP combination using the FC-AE-1553 ULP (which is designed to provide very deterministic
command/response operation analogous to the legacy MIL-STD-1553 data bus standard but at much higher
throughput rates) is documented in SAE AS5653 and is the basis for an enhanced data communication
capability added to the MIL-STD-1760E revision (but not yet implemented on any inventory platforms). Use
of FC-AE-1553 in the weapon could facilitate much more integrated platform/carriage system/weapon
networks in the future with a number of envisioned operational benefits, though the MIL-STD-1553 bottleneck
at the platform interface would limit this possibility for the near term (and maybe for the long term on some
platforms of interest). Interface into the weapon via an AS5653 link from the carriage system could set the
stage for later transition to the enhanced capability in the future, however.

DISTRIBUTION A. Approved for public release, distribution unlimited (96TW-2017-0082)

Proc. of SPIE Vol. 10205 1020503-2

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 2/18/2018 Terms of Use: https://www.spiedigitallibrary.org/terms-of-use

 Fibre Channel over Ethernet
o There has been a fairly recent emergence of Fibre Channel over Ethernet (FCoE) protocols, which support
operation of Fibre Channel type application protocols over underlying Ethernet networks. This is currently
being considered within SAE working groups as a possible additional protocol for selected use on the MIL-
STD-1760 high speed data connection that is currently limited to FC/FC-AE-1553 based operation. Specific
interest in this approach has been expressed by the Special Projects System Program Office (SPO) at Wright-
Patterson AFB for potential use on future platforms. Personnel from that SPO had a letter sent from their
management to SAE leadership requesting further development and standardization of an FCoE approach for
future versions of MIL-STD-1760. This activity, if undertaken, could potentially be leveraged for GBU-X
application.
TIA – 422/485
o The Telecommunications Industry Association TIA-422 and TIA-485 standards (formerly known as RS-422
and RS-485) could potentially be applicable for straightforward point-to-point data links, if such links are part
of the defined network topology (though TIA-485 also has a multi-drop capability). These are balanced
differential electrical signaling protocols which are well-supported with low cost commercial off-the-shelf
(COTS) transceiver devices. Since these standards only cover the electrical signaling characteristics, they must
be combined with a suitable transport protocol for data transfer. There are simple character- or frame-based
protocols that are typically used for this purpose which are also well supported with low cost COTS devices.
Universal Serial Bus (USB)
o USB is a combined serial data and power interface with several increasingly capable versions that is typically
used for connecting personal computers with peripheral or storage devices. It has data rates up to 10 Gbits/sec
and can be used to communicate bi-directionally between a host computer and up to a total of 127 endpoint
devices through active hubs, which can be in series with each other. Each bus segment (between source and
destination) can be up to several meters in length. USB is widely used commercially and is relatively low in
cost, with extensive off-the-shelf software support available. The power transfer capabilities are likely not
appropriate for the GBU-X application, but the serial bus capability through a different and more rugged (than
commercial USB) style connector is a potentially viable candidate.
RapidIO
o RapidIO is a serial communication protocol intended primarily for localized data transfer connections on or
between circuit boards in embedded systems, but can also be used for chassis to chassis links over distances of
up to approximately 1 meter with data rates up to 6.25 GBaud per link. Multiple parallel lanes can be
implemented, though it is envisioned that a single lane would likely be appropriate for the GBU-X application.
Like USB, RapidIO can have several levels of in-line switches which could be used to extend the total distance
somewhat. (Conceivably, there could be a switch in each in-line GBU-X module which would re-generate the
signal for transfer to adjacent modules.) RapidIO is also widely used commercially and is well supported with
a range of readily available low cost network devices and support software.
IEEE 1394
o IEEE 1394, or Firewire as it is commonly referred to, is a high speed serial data bus standard that was originally
initiated by Apple, and developed by an industry consortium under IEEE auspices. It is particularly well suited
for isochronous real-time data transfers such as those required for digitized video transfer. Current versions
have transfer rates up to 3.2 Gbits/sec. Though Firewire data links can be implemented by anyone, it is not
totally non-proprietary by virtue of the fact that there is a very nominal per-device licensing fee. This fee is
paid by the equipment manufacturers and not the users.

DISTRIBUTION A. Approved for public release, distribution unlimited (96TW-2017-0082)

Proc. of SPIE Vol. 10205 1020503-3

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 2/18/2018 Terms of Use: https://www.spiedigitallibrary.org/terms-of-use

 ANALYSIS PROCEDURE FOR COMMUNICATION ARCHITECTURES
Testing was performed in order to determine the throughput, latency, scalability, and consistency of each architectural solution.
This was accomplished by setting up programs that use the architectures as a framework to communicate between computers
operating on a shared network. Through the use of nine Dell 960 workstations, the testing team was able to load each network
with messages of increasing sizes by creating an array of bytes (UINT8) sent at increasing rates in order to tax the architecture
under test. After 30,000 messages were sent per test, a post processing analysis occurred which calculated the following data:
The average latency of all the messages received
The rate the messages were sent at
The throughput that the producer sent the messages at (sent throughput)
The throughput the messages were received at (received throughput)
The number of samples received
The number of valid samples received (samples whose latency was less than 10 ms)
The throughput of valid messages
The percent of the messages lost (undelivered or invalid).

Latency Tests
In order to measure the latency and throughput of the architectures, 120 tests were performed in which different message sizes
were sent at different attempted rates in order to load the architecture. The following rates and message sizes were used in the
study:
Payload size (Bytes): 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, and 63,000
Message Rate: 250, 500, 750, 1000, 1500, 2000, 2500, 3000, 4000, 5000, 7500, and 10,000
The latency was then computed by measuring the total time between the attached send time and capturing the receive time.
Therefore, the latency measurements include the time it takes to both create and send the message from the test machine, the
time of transmission to the receiving machine, and the time to process the message on the receiving end.

ARCHITECTURES UNDER TEST

DDS (Results Shown in Figures 2 - 7 below)[1]

Data Distribution Service (DDS) has been under development since 2001 as a collaborative initiative by Real-Time Innovations
and Thales Group. This communication networking middleware uses a publish-subscribe system to send and receive data to
different components within a networked system. The DDS selected for the investigation was Connext DDS Professional,
released by the American vendor Real-Time Innovations (RTI). Unlike most messaging frameworks, DDS does not use a message
broker service to handle routing messages, but rather communicates peer-to-peer from services discovering each other on the
network.
DDS functions very differently than MONARCH in several ways. Firstly, DDS does not include native support for message
serialization and de-serialization. The messages contain binary content delivered as is to subscribers. Another difference between
DDS and MONARCH is the method DDS uses to allow subscribers to pick the data they will receive and ignore. DDS achieves
this by the use of publish domains and topics. In DDS, a publisher is first created by a domain participant, which then creates a
data writer that will send data on a specific topic over the network, on a specified domain. Subscribers are created in a similar
manner, with the participant creating a subscriber, which in turn creates a data reader with an attached listener, which listens on
a specified domain for any messages from the desired topic.

DISTRIBUTION A. Approved for public release, distribution unlimited (96TW-2017-0082)

Proc. of SPIE Vol. 10205 1020503-4

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 2/18/2018 Terms of Use: https://www.spiedigitallibrary.org/terms-of-use

 DDS Test Results

Figure 2: Throughput results for the DDS configuration

DDS’s measured throughput was equal to the attempted throughput nearly 100% of the time, whereas MONARCH on average
had a measured throughput equal to the attempted throughput only 75% of the time. This is mainly due to undelivered messages
when sending messages at 300 Mbps and above. Although DDS requires the user to configure the throughput rate using the
nanosleep function, the testing team was able to reach a near 1:1 ratio of attempted throughput and measured throughput.

Figure 3: Message loss calculation as a function of throughput for DDS

For DDS, message loss was very uncommon as the testing team only made note of approximately 3.3% of tests losing messages
during the experiments. When messages were lost, they were at most 0.07% of the messages sent during the test phase. This will
be compared to the results for MONARCH in a later section.

DISTRIBUTION A. Approved for public release, distribution unlimited (96TW-2017-0082)

Proc. of SPIE Vol. 10205 1020503-5

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 2/18/2018 Terms of Use: https://www.spiedigitallibrary.org/terms-of-use

 Figure 4: Latency of DDS configuration as a function of message size

DDS delivers messages with latencies less than 10 milliseconds in every test case, as is shown in Figure 7. Just like MONARCH,
there is a clear correlation between message size/throughput and the latency. DDS’s latency is also quite close to the transmission
latency, yet not completely. With respect to weaponry and the use of open architectures, this bodes well for DDS as a potential
solution. Over the 120 test cases, DDS demonstrated a lower latency time 97% of the time. DDS also was superior in terms of
not losing samples over the entire test, DDS delivered 99.992% of its samples, with all of its messages being delivered in under
10 milliseconds.

Figure 5: Latency frequencies of the DDS configuration

To find how consistent the frameworks’ latencies were, the log outputs of the 1000 messages/sec 1024 byte test were analyzed.
This test was selected since each framework had very accurate send rate for the case, no samples were lost. DDS demonstrates a
fairly consistent latency, with very few samples appearing outside the 80-120 us range. It was found that for that test, the average
latency for DDS was 105.2 microseconds with a standard deviation of 6.47 microseconds.

DISTRIBUTION A. Approved for public release, distribution unlimited (96TW-2017-0082)

Proc. of SPIE Vol. 10205 1020503-6

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 2/18/2018 Terms of Use: https://www.spiedigitallibrary.org/terms-of-use

 Figure 6: Analysis of time to publish the message and the size of the message for DDS

The throughput of a framework is limited by two factors: available bandwidth and message rate. Because we knew the bandwidth
was limited to 1 Gbps, the other limiting factor was tested which was message rate. This test measured exactly how long each
framework took to create a message at varying sizes and send it, which we refer to as the publish time. The publish time was
used to compute the maximum theoretical send rate and the maximum theoretical throughput the publisher could send data at the
specified byte size. The publish time for DDS was observed to be roughly 50 microseconds until the message size reached 10,000
bytes. From this point it was observed that the publish time increased.

Figure 7: Maximum send rate as a function of message size for DDS

As expected, Figure 7 shows that as the message size increases, the maximum send rate decreases. Ultimately this will dictate
the amount of data that is pushed across each architecture.

DISTRIBUTION A. Approved for public release, distribution unlimited (96TW-2017-0082)

Proc. of SPIE Vol. 10205 1020503-7

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 2/18/2018 Terms of Use: https://www.spiedigitallibrary.org/terms-of-use

 MONARCH (Results Shown in Figures 8 - 13 below)[1]
This communication architecture had its beginnings within AFRL under the name of Space Plug-and-Play Architecture (SPA)
and transitioned to Modular Open Network Architecture (MONARCH) in 2011. SPA included support for USB, I2C, and
SpaceWire initially. The original intent for the architecture was for use in space applications, particularly cubesats and nanosats.
One major benefit of this middleware communication solution is the inherent ability for it to incorporate multiple physical layers
into one cohesive network. The networking technology has been used in prior AFRL programs and was first developed and built
by Science Applications International Corporation (SAIC) on the suborbital Re-Entry Structures Experiment (RESE). An
impressive feat to note is the integration time for 5 separate components was accomplished within a 9 month window. This rapid
development time proves that plug-and-play technology will assist in future development of weaponry and aircraft systems.
SPA middleware layer includes the API as well as the core libraries and core services, which include the Lookup Service (LS)
and Central Address Service (CAS). The LS and CAS are responsible for the system management in terms of collecting
component information, responding to queries, and assigning unique address blocks to facilitate component discovery and
connection.
The tests conducted utilized MONARCH’s publish-subscribe capabilities, as this form of communication best mimics that of a
missile system. MONARCH’s publish-subscribe method uses a specialized XML schema in conjunction with extensible
Transducer Electronic Data Sheets (xTEDS), which provide an interface definition to the system such variable names and data
types, message names, etc. Subscribers issue requests containing the name or other message parameters of the message to which
they wish to subscribe, along with the variables contained in that message. xTEDS configure MONARCH message topics,
including data values and types. The lets MONARCH perform data marshalling and un-marshalling during the sending and
receiving of data. The marshaling process eliminates the effects of byte ordering from different systems, and lets publishers send
structured data that subscribers will receive as structured data.

MONARCH Test Results

Figure 8: Throughput results for the MONARCH configuration

MONARCH’s apparent throughput limit of 300 Mbps is apparent in this test. Other aspects of the framework were detrimentally
effected when we pushed it to a throughput greater than ~250 Mbps, such as large latencies, dropped messages, messages
delivered out of order, etc. This is demonstrated in Figure 9, which shows the percent of samples considered invalid due to not
being delivered or arriving with latency greater than 10 milliseconds compared to the send time. We chose to regard messages
delivered with latency greater than 10ms as lost because some GBU-X subsystems need message latency to be at the microsecond
level (or less), so messages delivered with 10ms latency are useless to the subscriber.

DISTRIBUTION A. Approved for public release, distribution unlimited (96TW-2017-0082)

Proc. of SPIE Vol. 10205 1020503-8

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 2/18/2018 Terms of Use: https://www.spiedigitallibrary.org/terms-of-use

 Figure 9: Message loss calculation as a function of throughput for MONARCH

Just like message delivery, message latency with MONARCH is affected by the throughput limit. When the throughput limit was
reached (300 Mbps), a large spike in average latency was observed. Figure 10 shows the relationship between the payload size
and throughput to the latency. It is worth noting that the 4000 byte message was the first message size to achieve a throughput
greater than 250 Mbps. Another important aspect of the graph is that the highest latency data point typically relates to a higher
message rate, as that correlates to an increased throughput which also has an effect on the latency. Included in the graph is also
the transmission latency time, which is how long a message of the specified byte size takes to travel from one machine to the
other at 1 Gbps. The latency being measured includes the time it takes to create and send the message off the computer, the
transmission latency, and the time it takes for the subscriber to process the incoming message.

Figure 10: Latency of MONARCH configuration as a function of message size

When the throughput was kept below 250 Mbps, MONARCH averaged latencies 3.5 times longer than the equivalent DDS
latencies. Above the apparent threshold of 350 Mbps for MONARCH, the performance showed a clear degradation with respect
to latency which reached well over 1 second on some messages over 1000 bytes.

DISTRIBUTION A. Approved for public release, distribution unlimited (96TW-2017-0082)

Proc. of SPIE Vol. 10205 1020503-9

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 2/18/2018 Terms of Use: https://www.spiedigitallibrary.org/terms-of-use

 Figure 11: Latency frequencies of the MONARCH configuration

This test was selected since each framework had very accurate send rate for the case, no samples were lost, and it was within
MONARCH’s throughput range. It was found that for that test, the average latency for MONARCH was 211.5 microseconds
with a standard deviation of 19.2 microseconds. This is well within the threshold for the architectural requirements as defined in
Table 1.

Figure 12: Analysis of time to publish the message and the size of the message for MONARCH

MONARCH has a publish time half that of DDS for messages less than 750 bytes. However, when the message size is greater
than 1000 bytes MONARCH’s publish time exceeds DDS’s.

DISTRIBUTION A. Approved for public release, distribution unlimited (96TW-2017-0082)

Proc. of SPIE Vol. 10205 1020503-10

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 2/18/2018 Terms of Use: https://www.spiedigitallibrary.org/terms-of-use

 Figure 13: Maximum send rate as a function of message size for MONARCH

As expected, Figure 13 shows that as the message size increases, the maximum send rate decreases. Ultimately this will dictate
the amount of data that is pushed across each architecture. This decrease in send rate is much steeper than the send rate for DDS
based upon message size from Figure 7.

RESULTS AND RECOMMENDATIONS

Within the realm of open architecture communication, there are a few key factors behind the selection of not only the physical
layer used to transfer the data between components but also the architecture used to perform the traffic direction of the data itself.
This comes down to the rates at which the subsystem produces data, the amount of data being pushed in a message, and the
overall amount of tolerable latency from this component to the next component within the closed loop control system With that
being said, there are still more things to be defined as far as the rates at which data is produced by components and how much
data is produced by each component as defined in the ICD under development. With these two factors combined with a full
analysis of the system in question, one can determine the most appropriate method for transmitting the data from point A to point
B. Based upon the current capabilities and these two architectures, it is possible for open architectures to facilitate Air to Ground
weapons with message sizes under 10,000 bytes for DDS and 1,000 bytes for MONARCH. In order to extend this capability to
Air to Air weaponry, the performance of the architectures will need to increase by roughly ten-fold due to the maneuverability
of the target. This in turn drives a much higher engagement closure rates that will then require even more stringent latency
requirements.

DISTRIBUTION A. Approved for public release, distribution unlimited (96TW-2017-0082)

Proc. of SPIE Vol. 10205 1020503-11

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 2/18/2018 Terms of Use: https://www.spiedigitallibrary.org/terms-of-use

 REFERENCES

[1] Agassounon, William, MONARCH vs. DDS Comparative Performance Evaluation, Textron Systems, Massachusetts,
(2016)
[2] Benedick, Fred, Plug and Play for Architecture for Modular Weapons, WINTEC, Inc., Florida, (2015)
[3] Chin, S.S., Missile Configuration Design, University Microfilms, Xerox Co., Michigan, (1971)
[4] Richard C. Dorf, Robert H. Bishop, Modern Control Systems, Pearson Education, Inc., New Jersey (2011)

Proc. of SPIE Vol. 10205 1020503-12

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 2/18/2018 Terms of Use: https://www.spiedigitallibrary.org/terms-of-use