Final Report
Deliverable #5
for
Army Total Asset Visibility Enhanced RFID Tracking
Contractor:
Millennium Integrated Services 2000
Address:
704 W. Nye Lane, Suite 201 Carson City, NV 89703
Contract Number:
[INSERT HERE]
Contract Amount:
Award Type:
FFP
TPOC:
U.S. Army RDECOM /ARL
Name:
Erik Syvrud
Contact info:
erik.syvrud@us.army.mil
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Executive Summary
This document is the final report for Army Total Asset Visibility Enhanced RFID Tracking.
Working with SOCOM (Erik Syvrud), Global has developed an application for the iPhone family
that interfaces with the Cursor on Target enabled systems. Currently our system (iCOTS)
implements a Rover capability where Blue Force Tracking, force protection and UAV feeds are
integrated onto a common smart phone (or tablet) as well as an image surveillance capability.
Plans are to port this native iOS implementation to Titanium1 to support all smart phone
platforms from a common code base and to enhance the map, chat, routing, and zeroize
capabilities in the coming months.
Conceptual Prototype
This Rover capability was preceded by the creation of a conceptual prototype of an ATAV
reader / system for tracking and managing assets in the field. The objectives of this effort were
to:
 Develop an intuitive system that
o Maintains asset visibility as assets move around the world
o Track who handled asset
o Show where the asset will be next
o Manage asset status
o Find asset on site
 Support integrated communications for anywhere connectivity and in-the field visibility
of asset location
 Maximize the use of COTS to reduce both recurring and engineering costs
 Be an extensible solution to incorporate later applications
 Support multiple servers / data formats with a common reader
As described in more detail in Section 2, a conceptual prototype of this design was implemented,
demonstrated, and video-recorded in December 2010.
1
http://www.appcelerator.com/products/
MIS/Global Defense Inc.
ii
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Alerts from RFIDs in area
Functional Prototype
To better serve SOCOM needs, the effort was redirected to create iCOTS. iCOTS is a universal
Cursor on Target (CoT) viewing and tasking application supported by a server that integrates and
distributes CoT information. CoT is used to provide real-time battlefield awareness of the
locations of personnel and assets (e.g., sensors and UAVs) and to support tasking of assets (e.g.,
requesting repositioning or aiming a camera) and can be broadly classified as providing
situational awareness. Hundreds of different devices provide data to a CoT network, and the goal
of iCoT is to integrate management / viewing of all of these (as limited by user access) into a
single application on a smart phone or tablet.
The iCoT software will be deployed on devices owned or distributed by the military either as
part of a toolkit included in initial distribution or downloaded on demand from a government or
MIS-2000 hosted application market-place. The server providing the iCoT feeds can either be an
existing US government COT server or a modified server developed by MIS-2000 to segment
feeds and manage downloads. The resulting integrated environment for viewing this information
on smart phones (beginning with the iPhone) and sending tasking requests to devices in the
network (tasking is in Phase II) has the following benefits.
 Significantly reduce cost to allow for radios given to foreign friendlies or supporting
responders in a disaster response to be treated as “disposable”
 Enhance spectrum access and improved spectrum management capabilities to allow the
solution to be deployed in a wide variety of locations with minimal manual intervention
 Achieve a minimal level of operation without infrastructure while identifying and
exploiting communications resources when available.
 Achieve significant operating range
 Be rapidly deployable and suitable for tactical urban environments
 LPI / LPD (Low Probability of Detection)
MIS/Global Defense Inc.
iii
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report



Improved interoperability among heterogeneous communications assets
Easy to use, intuitive interface that untrained, unsophisticated users can immediately
begin to use
Ability to disseminate text and limited image information and support for voice
communications
As described in more detail in Section 3, this prototype was implemented and demonstrated and
tested at the Camp Roberts TNT experiments in May 2011.
Picture of an iPod, iPhone, and iPad receiving Cursor on Target information at Camp
Roberts TNT experiments in May 2011 with an intermediate server hosted on the laptop
Nanotechnology
In parallel, a study was conducted into how nanotechnology could improve the performance and
reduce the costs and SWAP of wireless sensor systems. The study examined current trends,
impact on RF components and antennas, packaging, and sensor performance. The study also
examined ways to extend battery life and technologies suitable for energy scavenging. This is
discussed in more detail in Section 4.
Future Directions
In the immediate future, we plan on returning to Camp Roberts for further testing and user
interaction on the ICOTS application at the beginning of August, 2011.
In light of a likely later need to support deployment onto the GD300 and RATS, we have begun
initial discussions with General Dynamics and Raytheon. In particular we recently submitted a
SBIR proposal to the Army where MIS/Global Defense will team with Raytheon to extend the
design of ICOTS where there are plans to for a capability for interfacing with DCGS and lay the
foundation for creating an extensible API for “plugging-in” interfaces and data fusion from
additional ISR / SA standards and custom sensors and UAVs. All software will be ported to
Titanium to support additional smart phone platforms and we will continue to mature the security
and peer-to-peer communications technologies and tactical network interfaces. In parallel to that
effort, the COT interface would be matured, a SAHANA interface created, and various features
related to enhancing situational awareness (supporting additional video feeds, telestration, after
action reporting) and core services would be developed and integrated. This is discussed in more
detail in Section 5.
MIS/Global Defense Inc.
iv
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
MIS/Global Defense Inc.
v
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Table of Contents
Executive Summary ........................................................................................................................ ii
List of Tables ................................................................................................................................. ix
Acronyms ....................................................................................................................................... ix
1
Introduction ............................................................................................................................. 1
1.1.1
Smart Phones ............................................................................................................ 1
1.2 Programmatics .................................................................................................................. 2
1.3 Shift in Project Direction.................................................Error! Bookmark not defined.
1.4 Document Organization ................................................................................................... 3
2
Conceptual Prototype (ATAV System) .................................................................................. 4
2.1 Army Total Asset Visibility Program and Project Scope ................................................ 4
2.2 Solution Concept .............................................................................................................. 5
2.3 Conceptual Prototype Design ........................................................................................... 6
2.4 Initially Envisioned Functional Prototype ....................................................................... 7
2.5 Summary of Conceptual Prototype Demonstration ......................................................... 8
2.5.1
User Log-In ............................................................................................................... 8
2.5.2
Main View ................................................................................................................ 9
2.5.3
Alert View ................................................................................................................. 9
2.5.4
Asset View .............................................................................................................. 10
3
Functional Prototype ............................................................................................................. 12
3.1 Cursor on Target............................................................................................................. 12
3.1.1
System Objectives ................................................................................................... 13
3.1.2
System Design ........................................................................................................ 14
3.2 Design for May Camp Roberts Demonstration .............................................................. 18
3.2.1
iCoT OVerview ....................................................................................................... 18
3.2.2
General Requirements ............................................................................................. 19
3.2.3
General Capabilities ................................................................................................ 20
3.2.4
Views ...................................................................................................................... 21
3.3 Results from May Camp Roberts Test and Demonstration............................................ 24
3.3.1
Test Results ............................................................................................................. 25
3.3.2
User Feedback ......................................................................................................... 27
3.4 Summary of Major Updates for August Camp Roberts Test and Demonstration ......... 31
3.5 Functional Prototype References ................................................................................... 32
4
Summary of Study into Reducing SWAP for Asset Management RFIDs ............................ 33
4.1 Summary of SWAP Study Findings............................................................................... 33
4.1.1
Processor Trends and projections ........................................................................... 33
4.1.2
System on Chip, mixed signals, and RFICs ............................................................ 33
4.1.3
Antenna Miniaturization ......................................................................................... 35
4.1.4
Packaging ................................................................................................................ 35
4.1.5
Energy Scavenging ................................................................................................. 36
4.1.6
Nanotechnologies for Sensors................................................................................. 37
4.1.7
General System SWAP Considerations .................................................................. 38
4.2 Recommendations from SWAP Study ........................................................................... 38
MIS/Global Defense Inc.
vi
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
4.3
5
References from Miniaturization / SWAP study............................................................ 40
Future Plans for Situational Awareness Application ............................................................ 44
5.1 Position Within the Smart Phone and Situational Awareness Ecosystem ..................... 44
5.1.1
Other DoD Situational Awareness systems beyond COT and DCGS .................... 44
5.1.2
Programs ................................................................................................................. 44
5.1.3
Devices .................................................................................................................... 45
5.1.4
App Stores ............................................................................................................... 45
5.2 Collaboration Discussions .............................................................................................. 46
5.3 Development Roadmap .................................................................................................. 46
Appendix A Conceptual Prototype Design Document ............................................................ 49
A.1 OVERVIEW................................................................................................................... 49
A.2 USER INTERFACES / VIEWS ..................................................................................... 49
A.2.1 Main TabBar View ................................................................................................. 49
A.2.2 User Authentication ................................................................................................ 49
A.2.3 Connectivity View .................................................................................................. 50
A.2.4 Map View................................................................................................................ 51
A.2.5 History/log view...................................................................................................... 52
A.2.6 Asset management view ......................................................................................... 53
A.2.7 Add new asset view ................................................................................................ 54
A.2.8 Alert Views ............................................................................................................. 55
A.2.9 Asset Detail ............................................................................................................. 56
A.2.10
Asset List View ................................................................................................... 57
A.2.11
Web View ............................................................................................................ 58
A.3 DATA INTERFACES.................................................................................................... 59
A.3.1 MySQL server database .......................................................................................... 59
A.3.2 SQLlite interface ..................................................................................................... 61
A.3.3 RFID network API – ............................................................................................... 61
A.4 ATAV Location Detector ............................................................................................... 62
A.4.1 Supported APIs ....................................................................................................... 62
A.5 Database ......................................................................................................................... 63
MIS/Global Defense Inc.
vii
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
List of Figures
Figure
Page
Figure 1: Smartphone usage is exploding and will surpass PC sales this year. Left from RBC
Capital Markets. Right from
ftp://ftp.3gpp.org/workshop/2010_04_Rio_LTEseminar/Marketplace_update.pdf............... 1
Figure 2: Schedule of Activities for the ATAV project. ................................................................. 3
Figure 3: Original Envisioned Deployment Scenario ..................................................................... 2
Figure 4: Screen Captures from Recorded December Demonstration of Conceptual Prototype of
ATAV system. ...............................................................................Error! Bookmark not defined.
Figure 5: ATAV is an effort to provide visibility and information flow across many different
systems with many different user groups throughout the life cycle of tracked components. ......... 4
Figure 6: In the deployment scenario, Zigbee-based wireless sensors would interface provide a
local area network connected to long-haul wireless links (Tier 1) to provide remote and in-thefield monitoring. This would be supplemented with augmented smart phones for directly
interfacing with the ZigBee sensors. ............................................................................................... 5
Figure 7: Principle Components and Modules in Envisioned Design ............................................ 6
Figure 8: Major components and features of the Conceptual Prototype Design ............................ 7
Figure 9: Initial Functional Prototype Design ................................................................................ 8
Figure 10: Picture of User Log-In Screen ....................................................................................... 8
Figure 11: Conceptual and Implemented versions of the Main ATAV View on the Reader ......... 9
Figure 12: Conceptual and Implemented versions of the Alerts Viewed on the Reader .............. 10
Figure 13: Conceptual and Implemented versions of the View for Individual Assets on the
Reader ........................................................................................................................................... 11
Figure 14: FalconView: One of the more popular viewers for Situational Awareness Data
[Konstantopoulos_06] ................................................................................................................... 12
Figure 15: CoT XML Schema Base Schema [Kristan_09]. ......................................................... 15
Figure 16: Example type hierarchies [Kristan_09] ....................................................................... 16
Figure 17: Example subschema. From [Kristan_09] .................................................................... 17
Figure 18: Example Cot message reporting a hostile fixed wing air craft at the latitude and
longitude specified, but only valid at the time of reporting. From [Kristan_09]. ......................... 18
Figure 19: Picture of an iPod, iPhone, and iPad receiving Cursor on Target information at Camp
Roberts TNT experiments in May 2011 with an intermediate server hosted on the laptop. ........ 24
Figure 20: Connection between CMOS technology, digital performance, and RF performance.
From [Jiménez_05] ....................................................................................................................... 33
Figure 21: Scaling factor relationships ( is the same as S from the digital scaling discussion).
From [Vittoz_90] .......................................................................................................................... 34
Figure 22: Expected trends for mixed circuit chips in area and cost by fabrication technology.
From [Jiménez_05] ....................................................................................................................... 34
Figure 23: Expected relative performance levels following ITRS projections for LNAs, VCOs,
Pas, and ADCs. From [Jiménez_05]. ............................................................................................ 35
Figure 24: Example Packaging solutions. From [Pack_09].......................................................... 36
Figure 25: Energy Densities for Commonly Available Energy Scavenging Sources .................. 37
Figure 26: Typical Power Profile of a low-power Wireless Sensor. From [TI_LPRF] ................ 38
Figure 27: Battery Life: Energy Density over time for various battery technologies. From
[Xue_07] ....................................................................................................................................... 39
MIS/Global Defense Inc.
viii
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Figure 28: Screen Capture from pre-release version of the Army App Store: Army Marketplace
(http://www.wired.com/dangerroom/2011/04/armys-app-store-for-war/) ................................... 46
Figure 29: ICOT Roadmap assuming funding via this SBIR. ...................................................... 47
Figure 30: View of iNode integration ........................................................................................... 48
List of Tables
Table
Page
Table 1: ATAV Enhanced RFID Tracking Milestones .................................................................. 3
Acronyms
3GPP
3GPP2
ADTB-T
ANDVT
ANSI
AOR
API
ARQ
ATSC
AWGN
BLOS
BPSK
CogNeA
COTS
CP
CR
C-SDR
C-SDRTS
CTS
DFS
DHS
DMB-T
DoD
DoDISS
DSA
DTV
DVB-T2
EDGE
EDR
EFT
EIRP
EOC
EVDO
FCC
3rd Generation Partnership Project
3rd Generation Partnership Project 2
Advanced Digital Television Broadcast-Terrestrial
Advanced Narrowband Digital Voice Terminal
American National Standards Institute
Area of Responsibility
Application Programming Interface
Automatic Repeat reQuest
Advanced Television Systems Committee
Additive White Gaussian Noise
Beyond Line of Site
Binary Phase Shift Keying
Cognitive Networking Alliance
Commercial Off The Shelf
Cyclic Prefix
Cognitive Radio
Cognitive-Software Defined Radio
C-SDR Transmission System
Clear to Send
Dynamic Frequency Selection
Department of Homeland Security
Digital Multimedia Broadcast Terrestrial
Department of Defense
Department of Defense Index of Specifications and Standards
Dynamic Spectrum Access
Digital TV
Digital Video Broadcasting—Terrestrial2
Enhanced Data rates for GSM Evolution
Enhanced Data Rate (an option mode for Bluetooth)
Enhanced File Transfer
Equivalent isotropically radiated power
Emergency Operations Center
Evolution Data Optimized
Federal Communications Commission
MIS/Global Defense Inc.
ix
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
FEMA
FFT
FID
FHA
FIPS
FM
GIG
GPS
GMR
GSM
HAIPE
HF
HN
HSDPA
HSPA
IEEE
IP
IPC
ISDB-T
ISM
ITU-R
LOS
LPI
LRI
LTE
MBITR
NIST
NLOS
OFDM
OFDMA
OSPF
PC
PD
PFA+
PN
QAM
QPSK
RSSI
RTS
SDR
SNMP
SNR
SSH
STANAG
SWAP
TCP
Federal Emergency Management Agency
Fast Fourier Transform
Foreign Internal Defense
Foreign Humanitarian Assistance
Federal Information Processing Standard
Frequency Modulation
Global Information Grid
Global Positioning System
Ground Mobile Radio
Global System for Mobile communications
High Assurance Internet Protocol Encryptor
High Frequency
Host Nation
High Speed Downlink Packet Access
High Speed Packet Access
Institute of Electrical and Electronic Engineers
Internet Protocol
Inter-Process Communication
Integrated Services Digital Broadcasting-Terrestrial
Industrial, Scientific, Medical
International Telecommunications Union- Radio
Line-of-Sight
Low Probability of Intercept
Limited Range Intercept
Long Term Evolution
Multiband Inter/Intra Team Radio
National Institute of Standards and Technology
Non-Line of Sight
Orthogonal Frequency Division Multiplexing
Orthogonal Frequency Division Multiple Access
Open Shortest Path First
Personal Computer
Probability of Detection
Probability of False Alarm
Pseudo-Noise
Quadrature Amplitude Modulation
Quadrature Phase Shift Keying
Received Signal Strength Indicator
Request to Send
Software Defined Radio
Simple Network Management Protocol
Signal-to-Noise Ratio
Secure Shell
Standardization Agreement
Size Weight And Power
Transmission Control Protocol
MIS/Global Defense Inc.
x
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
TV
TVWS
UAV
UDP
UHF
UMTS
U.S.
USB
VHF
VSB
WLAN
WWAN
WNW
Television
TV White Space (spectrum allocated, but unassigned, for TV broadcast)
Unmanned Aerial Vehicle
User Datagram Protocol
Ultra High Frequency (300 MHz - 3 GHz)
Universal Mobile Telecommunications System
United States
Universal Serial Bus
Very High Frequency (30 MHz – 300 MHz)
Vestigal Side Band
Wireless Local Area network (e.g., WiFi)
Wireless Wide Area Network (e.g., cellular)
Wideband Networking Waveform
MIS/Global Defense Inc.
xi
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
1 Introduction
1.1.1 Smart Phones
As noted at (http://www.defenseindustrydaily.com/military-smartphones-dod-apps-06512/ ):
The US Army soldier is burdened with C4ISR technology. The soldier uses a handheld radio to
talk to other soldiers and commanders, Blue Force Tracker to track friendly and enemy forces, a
portable GPS receiver to determine location, a ROVER system to receive UAV video feeds, and,
if he or she is lucky enough, an Afghan interpreter to communicate with the locals.
But if all of these devices could be integrated on a single device, the burden could be greatly
reduced. At the same time, smartphone use has exploded, with recent year-over-year growth up
to 67% (http://www.fiercemobilecontent.com/press-releases/global-smart-phone-market-growthrises-67) and rapid increases in the number of app stores (growing from 9 to 38 in 2009 alone),
with over 3 billion apps downloaded daily from iTunes and over 100,000 Android based phones
activated every day (http://gigaom.com/2010/05/24/android-vs-chrome-os/).
Figure 1: Smartphone usage is exploding and will surpass PC sales this year. Left from RBC Capital Markets. Right
from ftp://ftp.3gpp.org/workshop/2010_04_Rio_LTEseminar/Marketplace_update.pdf
Conceptually, because smartphones are effectively pocket computers with high data rate
communications and intuitive interfaces and significant development tools, smartphones appear
to be an attractive platform for creating the universal C4ISR device to lessen the burden on the
warfighter. Further, because smartphones are mass market commercial products, a smartphone
would be a relatively low-cost solution to the problem. With this reduced cost, it is easily
conceivable that every soldier could be equipped with a smart phone. Then by using the existing
sensing and surveillance capabilities on smartphones, would lead to the much discussed concept
of “every soldier a sensor” whereby real-time information could be gathered across the network,
synthesized and distributed across the battlefield to significantly enhance situational awareness.
To quote Mark Bigham2:
“Some of the best data about what is going on is at the individual soldier level, so what we want
to do is make sure that data gets back into the bigger systems like the DCGS [ISR network] so
they can have the benefit of what the soldier is seeing…The soldier needs to understand what is
going on at the individual level. Who are the key people in the village, who are the decision
2
http://www.defenseindustrydaily.com/military-smartphones-dod-apps-06512/
MIS/Global Defense Inc.
1
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
makers…So every time a squad goes through that village, they don’t have to learn from scratch
who the good guys are, who the bad guys are, and who the people in the middle are.”
With the military beginning to make significant investments in bringing smartphones to the
battlefield (e.g., Army App Challenge, DARPA’s Transformative Apps), CSDA, and MACE,
what remains to be done is to develop an application that improves the situational awareness of
the dismounted warfighter. This edge enabled systems will provide dismounted warfighters with
access to ISR sensors, data products, and common operational pictures via mobile applications
designed for use on hand held devices. In keeping with the edge enabled design principles, the
systems must be customizable, support non-centralized resources, and provide for continuous
evolution. The candidate design must address issues related to security and information
assurance while emphasizing the use of commercially available software and mobile devices
1.2 Project Scope
This project began with a focus on developing an integrated smart-phone based system for
managing assets tracked by a system of wireless sensors and RFIDs with smartphone readers, HF
links for long-distance links and ZigBee for interfacing and networking with sensors.
Figure 2: Original Envisioned Deployment Scenario
After delivering the conceptual prototype in December, to better serve the needs of SOCOM, the
ATAV effort was refocused on providing a situational awareness capability on smart phones
using information from the Cursor on Target network. As part of that change in plans, the
hardware miniaturization report was moved up in schedule and expanded to also serve as a
planning document for the effort to integrate with the Cursor on Target network, which we call
iCoT. Demonstrations of and experiments with iCOTS occurred in May at Camp Roberts with
initial testing in Tampa in April.
1.3 Programmatics
The original schedule for this project and associated milestones are shown below.
MIS/Global Defense Inc.
2
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Figure 3: Schedule of Activities for the ATAV project.
Table 1: ATAV Enhanced RFID Tracking Milestones
Milestone
1. Kickoff
2. Conceptual Prototype
3. Functional Prototype
4. Hardware Miniaturization Report
5. Final Report
Date at Kickoff
July 1, 2010
Dec 6, 2010
April 7, 2011
May 21, 2011
July 8, 2011
Actual or Planned
July 1, 2010
Dec 6, 2010
May 7, 2011
March 14, 2011
July 8, 2011
The only changes from this original plan were the change in scope of the functional prototype to
support Cursor on Target instead of ATAV, and moving functional prototype demonstration
back to May to leverage the TNT experiments at Camp Roberts.
1.4 Document Organization
The remainder of this document is organized as follows.
 Section 2 reviews the work performed creating the initial ATAV Conceptual Prototype
 Section 3 presents the design, demonstration, and results from the Functional Prototype
of the Cursor on Target Situational Awareness Application
 Section 4 summarizes the results of the HW Miniaturization study
 Section 5 discusses future plans for the situational awareness application.
MIS/Global Defense Inc.
3
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
2 Conceptual Prototype (ATAV System)
The project began with a focus on creating a series of two smart-phone enabled prototypes for
supporting the Army Total Asset Visibility program. After delivering the first of these prototypes
(the Conceptual Prototype), to better serve the needs of SOCOM, the ATAV effort was
refocused on providing a situational awareness capability on smart phones using information
from the Cursor on Target network.
Because of the shift in focus away from an ATAV solution, this section is somewhat abbreviated
in its coverage of the design, though the design document for the Conceptual Prototype is
included in Appendix A for the interested reader.
2.1 Army Total Asset Visibility Program and Project Scope
The Army Total Asset Visibility (ATAV) program is developing solution to providing awareness
of asset location and status throughout the asset’s life cycle, especially tracking this when
moved. This is made more complicated due to variation in available communications networks
and systems needed to communicate information about the asset.
Figure 4: ATAV is an effort to provide visibility and information flow across many different systems with
many different user groups throughout the life cycle of tracked components.
The intention was not to create a complete ATAV solution, but rather a combination of smartphone based readers and ZigBee-based sensors that would interface with the ATAV
infrastructure. The ZigBee-based sensors would provide a low-cost COTS-based way of tracking
the location and fetching information about individual assets.
MIS/Global Defense Inc.
4
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
2.2 Solution Concept
In the deployment scenario, Zigbee-based wireless sensors would interface provide a local area
network connected to long-haul wireless links (Tier 1) to provide remote and in-the-field
monitoring. This would be supplemented with augmented smart phones for directly interfacing
with the ZigBee sensors.
Data Server
HF Long Distance Data Link
HF Long Distance
Data Link
Zigbee dense mesh provides:
Pallet
• Relative location of pallets
• Low power consumption
• Cheap
Mobile assets
Tier 1 provides:
• Absolute location (GPS)
• Long distance connectivity
• Data connection when available
Zigbee
Tier1 Radio
Wireless Link
Figure 5: In the deployment scenario, Zigbee-based wireless sensors would interface provide a local area
network connected to long-haul wireless links (Tier 1) to provide remote and in-the-field monitoring. This
would be supplemented with augmented smart phones for directly interfacing with the ZigBee sensors.
For in-the-field tracking, smart phones would be augmented with hardware for directly
interrogating wireless sensors and then leverage existing connectivity to synchronize data with
data storage and provide feedback to remote monitoring stations.
This shows the primary system components for the final design – a server, an asset reader, an
RFID for the asset, and a Tier 1 device. The Tier 1 device is intended to provide long-distance
backhaul communications when civilian networks, such as cellular and WiFi, are not available.
Currently the Tier 1 backhaul communications is envisioned as being performed over an HF
communications link, but could also be performed over existing networks such as via WAVE
RELAY nodes.
MIS/Global Defense Inc.
5
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
IP
Backbone
RFID Server
Config
Discovery
WWAN / WLAN
Asset Reader
(iPhone)
Our App
MapKit
Tier 1
Voice / Video /
Picture
IP
Gateway
Zigbee
GameKit APIs
Secondary
Network Layer
Asset RFID
Asset App
Our Layer (HW)
HF
HF
Zigbee
Zigbee
Figure 6: Principle Components and Modules in Envisioned Design
By implementing the asset reader on an iPhone, we are able to leverage Apple’s significant
investment into developing capabilities to
 communicate over cellular, WiFi, and Bluetooth networks
 Take and manage photos and record video and voice
 Make use of an intuitive user touch-screen interface
 Provide GPS-enabled device location and to manage information displayed on maps
Further, because of the open interfaces provided by Apple, we will be able to rapidly extend our
design to incorporate new capabilities as needed by evolving user needs.
Another key component is the RFID which will be implemented using ZigBee wireless sensor
networks. By adding custom application software, we will be able to continuously monitor the
health of assets in the field. To communicate with the asset, we place the custom hardware
behind existing APIs for Bluetooth communications so that later applications can be easily
integrated with the custom wireless hardware. In addition to supporting ZigBee communications,
we also plan to support HF communications for when long data needs to be transmitted over long
distances and no other infrastructure is available. However, when no connection is possible, the
Reader stores information locally until it comes back in contact with the network so that data can
be synchronized with the server.
2.3 Conceptual Prototype Design
To enable early feedback in the development process, a partial prototype was designed and
implemented – the so-called conceptual prototype. This conceptual prototype can track asset
locations, detect and report movement, and store and manage asset information as well as other
capabilities we will highlight later in this presentation.
MIS/Global Defense Inc.
6
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Many of the key features of the design This prototype has a functional server accessible over the
Internet that maintains a limited set of information about assets and a functional asset reader
implemented on an iPhone. But to reduce time to getting to something demonstratable, the asset
RFID was not the ZigBee-based sensors and was instead a mockup on another iPhone using the
limited sensors already available on the iPhone and communicating via the iPhone’s built-in
Bluetooth communications link. Also the Tier 1 HF backhaul link was not planned as part of this
prototype.
This was implemented and demonstrated in December 2010.
IP
Backbone
Config
Discovery
WWAN / WLAN
Asset Reader
(iPhone)
Our App
Our App
GameKit APIs
Built-in
Bluetooth
GameKit APIs
Built-in
Bluetooth
MapKit
Voice / Video /
Picture
Asset RFID
Mockup
Figure 7: Major components and features of the Conceptual Prototype Design
2.4 Initially Envisioned Functional Prototype
In the Spring, the intention was to replace the mocked-up RFID with ZigBee wireless sensors, to
add a ZigBee-iPhone HW interface, to further refine the server and application as needed, and to
address feedback from the Conceptual Prototype demonstrations. However, this was dropped
with the change in direction to focus on Cursor on Target applications.
MIS/Global Defense Inc.
7
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
IP
Backbone
Config
Discovery
WWAN / WLAN
Asset Reader
(iPhone)
Our App
MapKit
Voice / Video /
Picture
GameKit APIs
Custom Zigbee
Sublayer
Figure 8: Initial Functional Prototype Design
2.5 Summary of Conceptual Prototype Demonstration
A demonstration of the conceptual prototype was video-recorded with slide supplements for
context on the displays. The following summarizes the material in the recorded demonstration.
2.5.1 User Log-In
When a user first starts the new application, he is presented with a user login screen that requires
he input his credentials. Based on his credentials, the reader will grant the user different levels of
access. This controls access to reader, with the intention that different levels of access would be
given to different user classes.
Figure 9: Picture of User Log-In Screen
MIS/Global Defense Inc.
8
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
2.5.2 Main View
After successfully logging in to the reader, the user is taken to the main view. From here, the user
has five primary options on the bottom menu bar.
 He can update the configuration of the reader, e.g., to disable certain wireless networks or
to log out.
 He can view the location of assets and their movement history on a map.
 He can manage assets not immediately accessible and search for assets based on key
words and other identifiers.
 He can directly interface and manage assets within his communication range over the
RFID link.
 He can manage alerts or warnings generated by assets.
The bottom menu bar is dynamic and will highlight the RFID and Alert fields when they are
present and indicate the number of RFIDs within range as well as the number of alerts that need
his immediate attention.
Finally, the built-in capability of the iPhone allows the user to monitor his connection to the
backhaul network.
Wireless
Network
Availability
Manage user
login, wireless
connections
View location of assets
Movement history
(Default view)
Local asset
management
Asset warnings
that need
immediate
user attention
Figure 10: Conceptual and Implemented versions of the Main ATAV View on the Reader
The Map on the Main View also allows viewing of own location and desired asset with the list of
assets chosen from
 Search results
 RFIDs in the area
 View movement history of single device
2.5.3 Alert View
The system continually monitors the health of the assets and issue alerts when immediate
attention is needed. The sensors and conditions to generate these alerts will be configurable on an
asset-by-asset basis. For the purpose of the conceptual prototype, alerts were limited to the
MIS/Global Defense Inc.
9
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
sensors available on the iPhone, which report shaking, tilt, and position. The Functional
Prototype intended to implement a fuller complement of sensors.
Alerts are indicated by badges (numbered red circle) on the bottom bar while a similar list of
assets within immediate communication range and indicated by the badge on the RFID icon.
Alerts from RFIDs in area
Figure 11: Conceptual and Implemented versions of the Alerts Viewed on the Reader
2.5.4 Asset View
After fetching the relevant information from the server, each asset’s data can be viewed
individually. Note that in the conceptual prototype demonstration, we only dummied-up data.
When viewing an individual asset, the user has several options including updating the status of
the asset which allows the user to add comments about the status of the asset, to manually take a
new photo if the asset has been damaged, or to pull up help about the asset. Because of the
extensive amount of information that may be associated with each asset, the information list for
each asset is scrollable. This information would eventually being processed on the server to
detect anomalies and to further automate many asset management features.
MIS/Global Defense Inc.
10
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Figure 12: Conceptual and Implemented versions of the View for Individual Assets on the Reader
Online help and Maintenance information
Demonstrating the extensibility of the solution, we leveraged the existing network and browser
support on the iPhone to allow users to pull up online information about assets. While the
demonstration only showed a dummy webpage for proof-of-concept, this could be readily
applied to a maintenance program or just to provide users critical information in the field about
their equipment.
Edit Interface
To complete the reader design for asset management, the individual asset view also allows the
user to update information about the asset. This includes writing descriptions or taking photos (to
document status or damage). Each of which would be (in the Functional Prototype) location and
time-stamped.
MIS/Global Defense Inc.
11
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
3 Functional Prototype
After delivering the conceptual prototype in December, to better serve the needs of SOCOM, the
ATAV effort was refocused on providing a situational awareness capability on smart phones
using information from the Cursor on Target network. Also note that in addition to a
demonstration of iCOT in Tampa in April, experiments on the iCOT were conducted at Camp
Roberts in May with additional development experiments to be performed in August. The results
of and feedback from the May experiments are included in Section 3.3.
3.1 Cursor on Target
Cursor on Target (Cursor on Target) is a DoD XML-based standard electronic portable data
format to define location based data and to coordinate operation of equipment and personnel.
Developed by Mitre in 2002 in support of the U.S. Air Force Electronic Systems Center (ESC),
Mitre first demonstrated COT “during a combined joint task force exercise in 2003, during which
a Predator unmanned aircraft was able to operate (and) coordinate with manned aircraft.”
[Ucore_11] It has since grown to being used in more than 50 other CoT prototypes [Bryne_04]
and is implemented by more than 70 nations. [Neuman_06]
Figure 13: FalconView: One of the more popular viewers for Situational Awareness Data
[Konstantopoulos_06]
CoT is commonly used for situational awareness, command and control, image processing,
automated multi-asset management, airspace deconfliction, and weather information distribution
[Robbins_07], to report and distribute sensor and UAV information, and to send tasking requests
to individual or groups of objects in the CoT network (e.g., reposition a UAV or request new
imagery from a camera). It provides a common context within which disparate user groups and
situational awareness systems can communicate. Other uses include:
 “overlaying special ops targets, Army blue force positions, (Air Force) air situational
awareness, and the joint Common Operating Picture all onto one display” [Schaeffer_05]
 “a MITRE team fused target information from a laser range finder, a compass, and a GPS
receiver and then sent the data to an intelligence system to be refined for high-precision
resolution. From there the data was relayed over a Link 16 radio to an F15E jet fighter to
be automatically downloaded to onboard precision-guided munitions.” [Byrne_04]
MIS/Global Defense Inc.
12
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
It accomplishes this via a common protocol and conventions that build on commonly available
tools.
We studied CoT in this effort and report on it in this section because of CoT’s success in
facilitating communication between distinct user groups, its support for machine-to-machine
communications and automated operation, and the way that it exploits shared context to reduce
bandwidth usage.
3.1.1 System Objectives
A long-standing problem with military communications is voice communications over noisy
channels can lead to mis-interpretation and long transmission times, which can degrade mission
effectiveness. Along with other solutions such as the phonetic alphabet (e.g., Alpha, Bravo,
Charlie), Cursor on Target tries to solve this via a protocol appropriate for M2M
communications over lossy channels as emphasized in the following popular origin story for
CoT. [Schaeffer_05]
“In April 2002 at the C2ISR Summit, Gen John Jumper (Chief of Staff for the Air Force)
gave an impassioned plea to find ways to horizontally integrate machines directly talking to
other machines to eliminate time-consuming and error-prone human translations. His
“Sergeant Matt” story described a special ops warrior riding a donkey, laser designating
targets using a handful of non-integrated machines, and manually performing calculations
that ended with long voice transmissions over noisy radios3, epitomizing the current state of
warfare. What Jumper envisioned was machine-to-machine (M2M) automation that would
achieve his vision that “the sum of all wisdom is a cursor over the target.”
While equating CoT to “the sum of all wisdom” is a bit of hyperbole, CoT does distill vast
amounts of data into actionable and easily understood information (within its context) . This then
allows [Byrne_04]
“battle commanders to be able to mouse over an aerial view of enemy positions, point, click a
cursor, and watch as the target is eliminated. Cursor on Target provides real-time access to
secure and reliable information.”
CoT critically provides and conveys context so that the aforementioned battle commanders know
if they are eliminating an enemy target or protecting a friendly unit.
Rather than trying to address all possible types of communication, CoT focuses on a particular
set of commonly needed information that addresses the following three questions about objects
and events on the battlefield. [Konstantopoulos_06]]
 What is it? Is it a friend or foe? Is it a tank, a UAV, a sensor or an anticipated event (e.g.,
weather front)?
 Where is it? What is its location for targeting and for coordinating movements? What is
the uncertainty in the location?
3
“Noisy radios” is
MIS/Global Defense Inc.
13
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report

When is it? For what period of time is this information valid or when will it be valid (e.g.,
for coordinating movements)?
The communication of this information is constrained to be reliably conveyed with minimal
bandwidth to allow operation over as many different networks as possible.
3.1.2 System Design
CoT achieves its objectives via a terse XML-schema and various messaging conventions.
Because of its design, only a few thousand lines of code are required to implement [Neuman_06]
3.1.2.1 Architecture
Broadly, a COT system is implemented over a network that connects a server with multiple edge
devices (clients) through intermediate routers. The edge devices may be pure consumers of
information provided by the server, may be producers of information, or both. Both information
and requests (and replies) flow over the network, via TCP/IP messages. COT supports both push
and pull methods due to relative benefits of both approaches [Konstantopoulos_06]
Theoretically speaking, push models are more adapted to transmitting Battlespace awareness/
Common Operating Pictures (COP) information, since the server retains the knowledge of
when important data has changed in order to initiate a new transmission with clients.
…
In practice, clients are the final authority on which data is important (to them), and thus it is
ultimately better to leave it up to the clients to initiate a pull for new data rather than having
the server force-feeding them data that may be fresh but of marginal consequence. Moreover,
clients may fuse data from multiple servers, and fusing is easier when the client is in control
of data refresh activity.
3.1.2.2 CoT XML Schema
The base XML schema for CoT is shown in Figure 14. XML has the following advantages as an
implementation language: wide availability of commercially available tools for processing XML,
extensibility, and capability to be both machine and human readable. This means that all
information is natively sent as a sequence of strings, which is less efficient but does aid in human
readability and extensibility to additional platforms.
MIS/Global Defense Inc.
14
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Figure 14: CoT XML Schema Base Schema [Kristan_09].
There are three primary elements in a CoT message – Event, Point, and Detail.
3.1.2.2.1 Event
The Event element answers two of the three questions: What and When. What is addressed by
the type field, which is a hierarchical descriptor that can provide a detailed description of what is
being reported in this message, e.g., what type of tank is seen, what domain is it operating in and
its affiliation. This has been described as “Organized much like an object hierarchy used in
object-oriented programming.” [Konstantopoulos_06]
The type field is a hierarchical classification of the object of the message with symbols
drawn from a shared dictionary. A partial breakdown of the hierarchy is shown in Figure
15 for messages about “atoms” (physical things), which are successively classified by
MIS/Global Defense Inc.
15
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
affiliation (e.g., friend-or-foe), domain (land, sea, or air), and then more detailed classifiers.
For example, a tank might be described in the hierarchy as thing (atom) -> Friendly
(affiliation)- > Ground (domain) ->tank -> what type of tank-> … These classifications
follow the MIL-STD-25254 as much as possible, though COT specific classifications are also
sometimes necessary. To differentiate between what is a COT specific classification and a
2525 code, labels from 2525 are written in upper case, while labels from COT are in lower
case. [Konstantopoulos_06]
Figure 15: Example type hierarchies [Kristan_09]
The use of a hierarchical type field has the following implications.
1) Only a handful of classifications are possible at each level of the hierarchy, which means
that a single letter can be used to convey the relevant information at each level, which
reduces bandwidth usage.
2) Less capable devices or users only interested in information defined at higher levels need
only parse a part of the type description.
3) The information assumed to be the most relevant to the most users is placed first to
hasten processing.
The Event field also answers the When question, specifically addressing the start time at which
the information is valid and the stale time at which the information should no longer be
considered valid. Note that to aid human readability, time is specified in a year-date-time format
rather than a decimal format. Additional context is provided in the Event field to aid in
processing including:
 What version of schema is being used. In theory, this should simplify compatibility
issues, though the event schema has been stable at 2.0 for some time.
 A unique identifier about the event (not the sender!) which facilitates information fusion
from multiple sources.
4
See http://www.mapsymbs.com/ms2525b_ch1_full.pdf
MIS/Global Defense Inc.
16
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report

A note about how the information was generated (e.g., manually or by machine) so the
recipient of the information can consider this in weighting the quality of the reported
information.
3.1.2.2.2 Point
The Point field answers the Where question. The Point field specifies where the event is located
in terms of geographic location and height (e.g., on the ground or in the air). Additionally, an
uncertainty in the location is also conveyed in terms of height and radius, thereby defining a
cylinder of location uncertainty. Height is measured as “height above ellipsoid” based on WGS84 ellipsoid, the same convention used with GPS. [Konstantopoulos_06]
3.1.2.2.3 Detail
The Detail field is optional and included to allow the use of sub-schema to communicate
additional information beyond the base schema, e.g., requests for actions or very specific
language such as weather information. By segmenting out the sub-schema, more capable and
more specialized systems or user groups can inter-operate with more limited or generalized
systems wherein all systems maintain a common high-level of battlefield awareness, while still
facilitating more detailed communications. Examples of sub-schema are shown below. The
Details field is also used to link together multiple UIDs to express relationships between the
UIDs, e.g., a group of objects or that one object should perform some function on another object.
[Konstantopoulos_06]
Figure 16: Example subschema. From [Kristan_09]
3.1.2.2.4 Sample Message
A sample CoT message is shown below, which reads as an atom (a, i.e., a thing) hostile (h) in the
Air (A) aircraft (M) fixed wing (F) was spotted at 11:43 (Zulu) on April 5, 2005. The aircraft has
been assigned the identifier “J-01334” for later processing and was at latitude 30.090027.
MIS/Global Defense Inc.
17
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Figure 17: Example Cot message reporting a hostile fixed wing air craft at the latitude and longitude
specified, but only valid at the time of reporting. From [Kristan_09].
3.1.2.3 CoT Conventions and Functions
In addition to the overt information transfer in a COT message, there are a number of
conventions that help processing and reduce bandwidth by creating a shared context. One of the
foremost examples of this is how required bandwidth is reduced by accounting for the time
validity of a message as described in [Konstantopoulos_06].
“Any geolocalized point can thus be considered “valid” and constitutes actionable
information until the current time & date overtakes the time and date identified in the stale
sub-element. In this way, DoD systems need not be constantly exchanging WWW
information in order to keep their Common Operating Picture (COP) synchronized at all
times.
…
In other words, what is really transmitted between systems sharing WWW information
consists of “diffgrams”, or “deltas” which are relative to changed data.”
CoT also supports the definition of tests or subscriptions that allows an end-client to limit how
much data is streamed to it. In a fairly expressive manner, a client can request that the server or
router limit the stream to any subclass defined by any part of the message, from type to UID to
location to messages within a certain time frame to affiliations. Because of the hierarchy, this is
a relatively simple parsing activity for the server.
3.2 Design for May Camp Roberts Demonstration
To better serve the needs of SOCOM, the ATAV effort was refocused on providing a situational
awareness capability on smart phones using information from the Cursor on Target network.
This section describes the planned design of the system with initial prototypes demonstrated in
Tampa and at Camp Roberts.
3.2.1 iCoT OVerview
Cursor on Target (Cursor on Target) is a DoD XML-based standard electronic portable data
format to define location based data and to coordinate operation of equipment. It is commonly
used to report locations of sensors and UAVs, to report sensor information, and to send tasking
requests to objects in the CoT network.
MIS/Global Defense Inc.
18
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
iCOT is intended to be an integrated environment for viewing this information on a smart phone
(beginning with the iPhone) and sending tasking requests to devices in the network (tasking is in
Phase II).
 Significantly reduce cost to allow for radios given to foreign friendlies or supporting
responders in a disaster response to be treated as “disposable”
 Enhance spectrum access and improved spectrum management capabilities to allow the
solution to be deployed in a wide variety of locations with minimal manual intervention
 Achieve a minimal level of operation without infrastructure while identifying and
exploiting communications resources when available.
 Achieve significant operating range
 Be rapidly deployable and suitable for tactical urban environments
 LPI / LPD (Low Probability of Detection)
 Improved interoperability among heterogeneous communications assets
 Easy to use, intuitive interface that untrained, unsophisticated users can immediately
begin to use
 Ability to disseminate text and limited image information and support for voice
communications
For a CoT network, there is a common server that all devices communicate with. The IP address
for the server and the iPhone will be specified as part of network configuration. At initialization,
a device registers with the server, requests a service and then begins participating in the network.
Typically, a mobile / portable device will update its position every 30 seconds 5 via a short UDP
message and receives an ongoing stream of CoT data via an open TCP connection registered
with the server from the other devices in the network. To support use with FID users, the server
will need to support multiple data streams bearing different data by level of user / device access,
authenticate the identity of the users, and encrypt the delivery of the data.
A typical data message consists of the following information:
 Location: lat, long and uncertainty
 Unique ID
 Message type
 Object type (ignored in this phase)
 Object friendliness: friend, foe, neutral, unknown
 Timing information: when message was created, period for which data is valid
3.2.2 General Requirements
3.2.2.1 OS Support
 The application should support iOS 4 and Android 3
3.2.2.2 Platform Support
 iPhone - The application should work properly on iPhone 4
 iPad – The application should work properly on the iPad2
5
Position is specified in terms of latitude and longitude and is sometimes augmented by a cylinder (radius and
height) of position uncertainty.
MIS/Global Defense Inc.
19
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report


iPod – The iPod is not a target platform for this application
Android phones and Tablets - The application should work properly on Android devices
3.2.2.3 Application Guidelines
 The application should be developed based on Apple's user interface guidelines6
 There should no memory leaks or excess memory allocation issue during the application
running state
 Processes that require a perceptible amount of time to execute should run in the
background
3.2.3 General Capabilities
3.2.3.1 Network Communications
 IP v4/6
 The application will only communicate over WiFi7
 Static IP will be used
 When WiFi network connectivity or server connectivity is not available, messages should
be queued until the connections are re-established.
 Reconnection with the server should be automatic if the correct WiFi SSID is available
 Some icon should indicate when a connection to the server is active
3.2.3.2 Method of Encryption
The system shall be interoperable with any of the following crypto algorithm options:
Threshold:
 Wideband
o Vinson (KY – 57/58)
o Bulk Encryption (KG-84)PFA = 0.01%
 Narrowband
o Advanced Narrowband Digital Voice Terminal (ANDVT)
 Network
o High Assurance Internet Protocol Encryptor (HAIPE)
o AES 256 under Federal Information Processing Standard (FIPS197)
Objective. Upgradable to future DoD approved encryption standards.
3.2.3.3 CoT message handling
Low level communications of COT messages should be handled as a background process.
 An XML parser is necessary to handle CoT data.
 Outgoing messages should conform to the CoT standard
 Each received CoT message should be stored over the duration of a session and sorted by
UID and history
 Outgoing location messages and status updates should be sent as UDP messages
 Outgoing images should be sent as TCP messages
6
http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/MobileHIG/Introduction/Intr
oduction.html
7
The iCoT application will be used in many locations where cellular coverage is not available. Further, the available
WiFi network will be secure
MIS/Global Defense Inc.
20
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
3.2.3.4 Voice Support
 Voice over WiFi will be supported.
 Launching any existing iPhone App for Voice over WiFi (e.g., Skype, Cisco Voice over
WiFi) is an acceptable solution
3.2.3.5 Photos
 The application will be able to view photos received over the CoT network
 The application will be able to take, annotate, and transmit photos received over the CoT
network
 Files should be saved as .jpg
3.2.3.6 Location Updating
If enabled, location updating will be a background process
where every 30 seconds the application reports its location to
the server if the connection to the server is active.
3.2.4 Views
3.2.4.1 General
 On the iPhone, each new view should default to
appearing over preceding views.
 On the iPad, the Map View should be most prominent,
filling the screen, with other views defaulting to
appearing on the right half of the screen.
3.2.4.2 Bottom Bar
The bottom bar should allow switching between primary
views. Specifically to launch the following views:
 Log-in view
 Configuration view
 Map view
 Alert view (includes badge that increments as alert
events are received and not viewed, and brightens
when an unprocessed alert is present)
 Photo View
X
3
3.2.4.3 Top Bar
The top bar should be the standard network connectivity bar with an indicator for an active
server connection. This then includes:
 Cell network bars8
 WiFi connection status
 GPS reporting (based on Configuration View setting for reporting)
 Server connection status
8
The application will not use the cellular network. But if the user wants to separately place a call over a cellular
network, this should be allowed.
MIS/Global Defense Inc.
21
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
3.2.4.4 Map View
The map view is the primary view of the application capable of showing the current location of
all devices in the network (depending on map zoom) and will be updated on receipt of each CoT
message from the server.
 Toggle between street view and satellite (Google Earth) views
 Display icons at the location of each reported object
(differentiable by the Unique Identifier – UID - field)
from the server stream and own location
 Friendlies are blue squares
 Hostiles are red circles
 Neutrals are green triangles
UID: Type X
 Unknown are orange pentagons
 If the UID icon’s time has timed out (current time >
timeout of last message), it should be filled grey
 Once a data field has shown up, the icon should blink
until clicked on
 Double clicking on an icon launches its Detailed
Asset View (Section 3.2.4.7)
 Single clicking spawns an annotation beside the asset
CoT Info
that displays the most recently received CoT data for
the object
CoT Info
 When a data file is received (e.g., an image), an alert
3
badge should be shown next to the icon and the
updated
3.2.4.5 Log-in View
The log-in screen should be the first screen seen when
starting the application. Access to the application only occurs after successful log-in. Functions
include
 Prompt user for name and password.
 This will be sent to the server for authentication.
 The name will be used to update the details field of the transmitted CoT messages
 Log out
3.2.4.6 Configuration View
The configuration view is used to:
 Specify server static IP address
 Specify iPhone static IP address
 Specify WiFi SSID
 Enable / disable status updates to the server (e.g., disable reporting location)
 Enable / disable status updates from the server (upload only)
 Enable / disable image annotation
 Enable / disable auto-send image
 Enable / disable alerts on new data (flashing icons)
 Clear session history
 Save session history (local)
MIS/Global Defense Inc.
22
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
3.2.4.7 Detailed UID View
The detailed asset view is used to view current and past CoT messages associated by a UID and
to contact users as needed.
 A scrollable list displaying past CoT messages for the UID from newest message (top) to
oldest message (bottom)
 Default view on newest message
 Expands to fill space as available
 A small view of the most recent image (if any) has been received
 Clicking on the image should make it display full-screen
 Clicking the full-size image should restore back to a mini-view
 Clicking on a minus sign hides the image (a plus sign takes it place to restore the
image)
 A small view of its position on the map (mini-map)
 Clicking on the mini-map should pull up the map view and circle the selected
UID with a yellow circle
 Mini-map should maintain primary map focus point, but zoom out enough to
encompass the UID location
 Clicking on a minus sign hides the map (a plus sign takes it place to restore the
mini-map)
 A button to initiate a voice session (if device type is “iCoT”)
 An indicator if there is current information for the UID (if current time < valid time of
last CoT message)
 The self-UID is one of the UIDs that will be tracked (for reviewing past locations and
images)
3.2.4.8 Photo View
The photo view is used to take, annotate and send pictures.
 After taking a photo (use default iPhone capability)
 if image annotation is enabled, a mini-window should open to allow the user to
add text (no text is acceptable)
 else, no annotation is kept
 After optional annotation
 if auto-send image is disabled, the user should be prompted to send, save, or
delete the image
 If saved, store locally
 If sent, send to CoT server
 if auto-send is enabled, then send the image
 Only display the image after taking if auto-send is not enabled
 When a photo is sent, the CoT transmission takes the following form
 the data field is occupied by the jpg for the image.
 The location is the current location reported by the GPS
 The UID is the ID assigned by the server
 The annotation is located in the details field
3.2.4.9 Alert View
The alert view is used to manage when important messages have arrived (primarily data files)
and tracks when there are alerts that have not been viewed yet
MIS/Global Defense Inc.
23
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report






The view should consist of a scrollable list of CoT messages that contained data in
reverse chronological order
Each entry in the list should list the location, UID, UID type, and data type
Double clicking on an entry should spawn the Detailed UID View for that UID
Clicking on the alert view will clear the alert state (flashing) of all UIDs
A thick line should separate UIDs in the list that have previously been viewed from those
that have not
On the iPad, as each entry in the list is selected, a yellow circle should highlight the
associated UID on the map
3.3 Results from May Camp Roberts Test and Demonstration
From Sunday, May 8 through Tuesday, May 10 iCOTS Kurt Badertscher, James Neel, and Mark
Phillips traveled to Camp Roberts to
 conduct performance and interoperability tests with a live Cursor on Target network
 gather feedback from users and PEOs on features and modifications to be make to iCOTS
 Fulfill Milestone 3.
Figure 18: Picture of an iPod, iPhone, and iPad receiving Cursor on Target information at Camp Roberts
TNT experiments in May 2011 with an intermediate server hosted on the laptop.
Interoperability testing revealed no issues as we successfully exchanged position and image data
with the main COT network and among devices without message drops or any reported issues
caused to the primary COT network. However, testing also revealed that the design needs to be
modified to reduce (eliminate) interactions with the internet. While this would also work towards
the goal of realizing a closed system, based on bandwidth availability, using internet based
services (map, Skype voice, Skype chat) yielded unacceptable levels of performance.
Additionally, it was revealed that a limited number of devices on the COT network (specifically
radars) generate an extraordinary number of messages with new UIDs (~2000 / minute) which
overloads the current icon rendering and alert systems. However, when the radar was not
flooding the network (Tuesday morning), we saw excellent performance for the main COT
routines (map displays, image uploads), though Skype voice and Skype chat were still
unacceptably bad over the WiFi network. Network reliability was identified as a particular issue
with the COT network repeatedly going up and down on Sunday during initial tests, often
staying up for only 30 seconds at a time. To address this issue, Sunday night, we coded our own
message router that acted as a repeater and access point to the iCOTS devices. By Monday
MIS/Global Defense Inc.
24
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
afternoon, this intermediate server was operational and included in demonstrations Monday
afternoon and Tuesday morning.
On Monday morning and (to a lesser extent) Tuesday morning, many different special forces
operators provided feedback on:
 Ways we could improve the interface
 How they envisioned using the device (applications)
 What should be assumed about network availability
Overwhelmingly, the response was positive, though a couple signals users on Tuesday expressed
doubt on the utility of smartphones in general. Even on Tuesday (after official experiments were
over), operators were seeking us out to try out the application. In particular, operators from Fort
Bragg expressed interest in continuing to help us test and evaluate iCOTS even between
Monday morning, Erik Syvrud attended initial demonstrations where we had two iPod Touches
tethered to our own COT server and network (via a WiFi access point purchased on Sunday).
Feedback was positive and milestone 3 was satisfied.
3.3.1 Test Results
3.3.1.1 Interoperability
We received no reports of poorly formed COT messages interfering with the COT network and
were able to receive and monitor feeds from numerous devices both via an intermediate Position
information and imagery were correctly sent and received without issue (ignoring the radar
issue). The COT server did indeed relay back messages sent from a device back to the device.
We also downloaded our application onto two iPhones brought by other participants at TNT –
one a special forces user (Tuesday) and one a professor at CMU (Monday). These successfully
participated in our locally hosted COT network
3.3.1.2 Radar Issue
Radars on the CoT network were sending out a message with a new UID with every ping. This
completely overwhelmed our devices. We will need to develop a routine on the devices to detect
this condition and filter out the messages when they occur. A log of COT messages from Sunday
and Monday has been requested to aid in creating this filter. This could also be accomplished by
ensuring the primary COT server implements a similar filter, so this should be viewed as a failsafe mechanism.
3.3.1.3 Performance
Network Reliability – On Sunday, this was a significant issue as the COT network would stay up
only intermittently, sometimes for only 30 seconds. This was addressed on-site by developing a
message router that would allow us to host our own local COT network where our message
router relayed COT messages between the local network and the primary COT network. This
largely solved the ancillary issues that resulted from the WiFi connection having to be constantly
re-established.
MIS/Global Defense Inc.
25
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
3.3.1.4 Skype Voice and Chat
On Tuesday, voice and chat capabilities were tested over the WaveRelay WiFi connections and
found wanting. Specifically no voice calls were successfully completed9 either from calling or
when trying the Skype recorded message setup. Further only ~50% of Skype chat messages were
successful.
Proposed resolution – users repeatedly emphasized their preference for using cellular networks
instead of WiFi. Over cellular, for voice Skype is not needed. COT also supports its own chat
protocol, which should be implemented in lieu of Skype.
3.3.1.5 Map Interface
Map tiles for the iPhone MapKit are designed to make use of Google’s online map tiles for both
satellite and street views. However, with spotty internet connectivity (particularly on Sunday),
this led to long periods of time where the icons would be displayed over an empty map due to an
inability to reliably and consistently reach Google’s servers.
This should be addressed by locally caching map tiles relevant to the mission. Based on user
feedback, this should support tile generation from many different map sources and the
application should support dynamic overlays of these map tiles.
3.3.1.6 Battery Life
On Monday afternoon, an iPod, an iPhone, and an iPad were left connected to our own COT
network from a fully charged state and allowed to discharge until off. The devices took the
following amounts of time to fully discharge:
 iPod ~ 2.5 hours; iPhone ~ 4 hours; iPad ~ 4 hours
Note that this is shorter than advertised operational life of the devices, but the GPS and WiFi
were in continuous heavy use over this period of time. In the future we could improve battery life
by adjusting the design to consider which network data is being sent over and adjusting phone
operation mode. Indeed, many interface design decisions will strongly influence power
consumption as illustrated by the Android statistics below. While these statistics assume the use
of commercial cellular networks, we expect similar tradeoffs to exist for tactical cellular
networks and for using services of various smartphone components. Thus, as much as possible
the interface should be designed to communicate in a way that minimizes power consumption.
9
No radars were operational at the time.
MIS/Global Defense Inc.
26
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
3.3.1.7 Configuration Time
We configured several devices to run on the primary COT network (our own and a couple
others) and our own COT network. The following are estimates of times required to join a
network for a provisioned device with the iCOTS application.
 Set WiFi (network) settings: 1 minute
 Configure COT server settings: 1 minute
 Time from clicking “connect” to data reception: < 1 second
3.3.1.8 Usability
Users had little trouble understanding how to make use of the application and very little
explanation was required for an unexperienced user to begin to be effective with the application.
However, it was important to at least give a short briefing of what the application was intended
for and what features it supported. An estimate training time of 1-5 minutes is recommended for
using iCOT in its current form.
3.3.1.9 Alerts
 This feature was much appreciated, though user and mission configuration is desired.
 Audio chimes were preferred (feeling a vibration was judged to be impractical through
body armor), but this should be integrated into their existing headsets.
 Cleared alerts should be indicated by cell color instead of font color
 The alert badge should go away when 0 new alerts are present (easier visual indication)
3.3.1.10 Configuration
Most users were either not interested or knowledgeable enough of network protocols to
configure the settings for talking to the COT server from the iCOTS devices. These settings
should be input prior to deployment by comm. specialists along with other relevant information
for the mission.
3.3.1.11 Device Detail Confusions
 Clicking on image should expand the image and allow manipulation
 Clicking on the mini-map should bring the user back to a zoomed in view of the map
3.3.1.12 Memory management
One of the more positive feedbacks we got about iCOT was that it was much smoother and
responsive than I2W (a competitor product focused on generating after-action reports, but
without a COT tie-in). However (unseen by the users), after 30+ minutes of operation the devices
became noticeably less responsive. It is speculated that this is due to RAM filling up and
repeated dynamic allocations of memory. This should be resolved by pre-allocating fixed (but
large) size arrays when new UIDs are encountered (to store messages) and implementing a
routine to regularly save messages in RAM to the harddrive.
3.3.2 User Feedback
3.3.2.1 Form Factor
The iPad was seen as too big for individuals to use, but useful as a controller or for management
in a vehicle (iNode) or as part of an airkit after crash-landing. The iPod and iPhone was seen as a
more useful form factor for use by individuals in the field.
MIS/Global Defense Inc.
27
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
3.3.2.2 Practical Considerations
 Gloves - In all cases, we need a good solution for how to interface with the devices when
wearing gloves.
 Devices need to be water-proofed.
 Support for voice activation / input is desired
 Default to Dim light level as it might get pulled out at night and a bright light can give
away their location. Having to brighten the device in daylight was not seen as
burdensome, though ideally the device would auto-detect ambient light conditions and
adjust accordingly.
3.3.2.3 Networking
 WiFi was not as popular as expected. The rationale is due to its limited coverage range as
users could easily shout 100 meters if needed. Bluetooth was spoken of *very* poorly
and should be avoided due to interference susceptibility.
 Cellular was expected to be well represented in Iraq, though is reportedly quite spotty in
the middle of Libya.
 The preferred solution appears to be to support cellular and WiFi in permissive
environments (as they’re already on the phones) but to also provide an Ethernet
connection to the phone to support communication over additional existing military
networks. This would also address potential security concerns
 Direct messaging without the COT server was also desired, both for messages that don’t
need to distribute to everyone and for when the connection to the server is lost.
3.3.2.4 Major Apps
 Liked it as a redundant Blueforce tracker
 Liked transmission of imagery
 Wanted support for report generation
 Surveillance – want video and audio record and upload / share in addition to imagery.
3.3.2.5 Search Function
An ability to search for a specific UID or related UIDs that match some search string related to
CoT fields and time. This is desired to a) allow the user to quickly zoom in on a desired UID and
b) to look for patterns of behavior over time.
3.3.2.6 UTM (MGRS)
users requested an ability to switch back and forth and to display simultaneously UTM with
lat/long data. Lat-long is reportedly used when communicating with aircraft, while UTM is used
for their own internal communications.
3.3.2.7 Velocity / Heading
When conveyed by the COT network, users would like to see direction and speed included in the
UID annotation field.
3.3.2.8 Zeroize / Remote Device management
Users expressed a desire to remotely clear a device and/or to remotely control a device that fell
into an enemy’s hands. However, there is perhaps multiple levels of wiping required as for the
MIS/Global Defense Inc.
28
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
car tracking capability, the phone should continue reporting its information, but all stored data
and imagery should be wiped.
3.3.2.9 Transmission management
Users requested a capability to manage who got different messages. Suggested levels include
 within team
 to everyone
 Selectable
 To commander
Surveillance data has greatest need for run-time selection. Probably support as lists defined in
configuration to define where surveillance and position info defaults to and a user screen when
uploading surveillance data.
3.3.2.10 Visibility
Users suggested that glare may be an issue on the device in bright sunlight. This implies that
matting on the screen may be desirable to reduce glare.
3.3.2.11 Bearing
Users expressed a desire for an optional compass displayed on the map. This bearing should be
included in any tags attached to submitted imagery.
Icons – As a bit of a surprise, very few users were familiar with the 2525B iconography. There
was some feedback that suggested that more “video-game” like icons would be easier to
understand (e.g., a tank for a tank, a UAV for a UAV…)
3.3.2.12 Imagery
 Auto-save uploaded images.
 Append orientation information. Distance would be nice, but this is a difficult feature to
add.
 Clicking on image should bring up image manipulation routines (zoom in / out…)
 Users should get an alert when an image does not successfully get to its intended
destination.
 Want to be able to draw on images and write notes directly on images. Described as like
how John Madden telestrates.
3.3.2.13 Iconography
 2525B was not well known (“maybe the old guys like it”).
 Users would like to be able to
o define their own icons and select from different icon sets (2525B, video-game
icons, or something customizable)
o Define their own relationship rules between types and icons
o Add their own labels for UIDs
o Possibly use their own icon sets
 Display part of UID on icon
 Affiliation and type were universally the most important things to show
 Delete icons of stale icons (suggest moving to another optionally displayed layer)
MIS/Global Defense Inc.
29
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report



Possibly indicate speed and heading
Need to be updating icon locations in pseudo-real-time.
Add some visual indicator when a UID has an image
3.3.2.14 COT / UID XML Dump
 No awareness of meaning of COT fields, e.g., what does “hae” mean? Should map
known fields to English descriptors
 Didn’t like “XML Dump” as didn’t know what that meant
3.3.2.15 Annotation
 Add support for UTM (already identified)
 Add speed and heading (likely want to make what is displayed on the configuration user
definable)
3.3.2.16 Routing
 Support for routing was greatly desired, but what routing meant varied by user.
 Some thought this meant being able to coordinate on a position to meet at, at a specified
time (our original interpretation)
 Others thought this meant the preceding with Tom-Tom like turn-by-turn navigation
which would optionally auto-route around bad terrain and known problem areas
3.3.2.17 Maps
 Add a compass overlay to the map
 Support distance estimates (pick two spots on the map and have the screen tell you the
distance)
 Support user-definable saved views. Perhaps page these in from the side of the screen.
 Returning to the map should return to the last map view (not the current fit-all icons
view)
 Clicking on mini-map should take users to that spot on the map
 Extend mini-map range to encompass a larger view
 Support dynamic (transparent / partial opacity) overlays of map tiles from a variety of
sources. These should be locally cached due to network and security issues.
 Want to be able to do screen captures of maps which could then be drawn on like with
images
3.3.2.18 Reporting
 Support for generating after-action reports was repeatedly voiced. This should support
voice-to-text reports and attaching images to the reports.
 Reporting can take over an hour of their time after a mission and anything that can cut
this down is desirable.
 Should support “breadcrumbing” to recreate where entities were during the action.
3.3.2.19 Unexpected applications / features requested
 Tracking device – the scenario given was to attach the device to a car of interest and then
see where it goes. Other users noted that cheaper, more disposable devices already exist
explicitly for this purpose. However, this is effectively a “free” application that iCOTS
MIS/Global Defense Inc.
30
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report




already supports. But this should only be used once the zeroize server is also
implemented.
Surveillance by Border Patrol10 – A representative from DHS noted that iCOTS image
uploading capability would be particularly useful for their covert missions in border
towns as it would be much easier to conceal and would not draw attention.
A 3-D auto-rendering map display was requested by one user so that users / commanders
would better account for terrain. This was said to be “far cooler” than just a topo map.
Directly integrate into mission planning and executing with recognition of phase lines.
Generate alerts when phase lines are crossed.
Use for survival information in crash landing (from pilot Erik Hesko)
 Videos of medical, local fora informational
 Canned messages for chat, hijack message (ejected but ok)
 Canned message for crossing phase line
 Emergency survival information that has comm.
o 1-4 hours; generally up to 24 hours
 Medical info
 iPad maybe too big (maybe under seat); iPod in pocket; Needs to eject with the
pilot.
 Waterproof
3.3.2.20 Security
 (Not from users) Imagery should not be loaded onto the main phone camera roll as this
poses a security risk as those without access to the iCOTS application, but with access to
the phone can too easily pull up imagery from missions.
 Encryption is desired when not in a permissive environment, but this could be
accomplished by communicating over a more secure network.
3.4 Summary of Major Updates for August Camp Roberts Test and
Demonstration
The following additional features are planned for further testing and demonstration at Camp
Roberts in August.
 Routing to coordinate movements from the Map Interface
 A change in map tile access to local storage and multiple tile overlay to reduce network
bandwidth requirements and improve responsiveness
 Remote device wiping
 A compass overlay
 A distance measuring tool on the map
 UTM coordinate display on the UID annotation
 A local COT filter to address the radar issue
 Updates to imagery management
 Improved memory management to store older messages on the phone hard drive and limit
table size displays to maintain application responsiveness
10
Surveillance is one of the primary apps intended for iCOTS, but the use by DHS was unexpected.
MIS/Global Defense Inc.
31
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
3.5 Functional Prototype References
[Byrne_04] R. Byrne, “‘Cursor on Target’” Improves Efficiency” The Edge, MITRE, Fall 2004.
Available online: http://www.mitre.org/news/the_edge/fall_04/edge_fall_04.pdf
[Konstantopoulos_06] D. Konstantopoulos, J. Johnston, “Data Schemas for Net-Centric
Situational
Awareness,”
CCRTS
2006,
Available
online:
http://www.dodccrp.org/events/2006_CCRTS/html/papers/073.pdf
[Kristan_09] M. Kristan, J. Hamalainen, D. Robbins, P. Newell, “Cursor on Target Message
Router User’s Guide,” MITRE PRODUCT MP090284, November 2009. Available online:
http://www.mitre.org/work/tech_papers/2010/09_4937/09_4937.pdf
[Neuman_06] T. Neuman, “Cursor on Target (CoT): The Future of Network Centric Warfare,”
http://www.angelfire.com/planet/gb3020_cursor_on_tgt/index.html, 2006.
[Robbins_07] D. Robbins, “Unmanned Aircraft Operational Integration Using MITRE’s Cursor
on Target,” The EDGE, Summer 2007, vol. 10, no 2. Available online:
http://www.mitre.org/news/the_edge/summer_07/edge_summer_07.pdf
[Schaeffer_05] K. Schaeffer, T. Gibbons, Jr., “Enhancing the Extended Awareness Capability of
the ESG: Integrating Shotspotter and Cursor on Target Technologies with Unmanned Aerial
Vehicles to Enhance the Mission Capability of the ESG,” Masters Thesis, Naval Post Graduate
School,
June
2005.
Available
online:
http://edocs.nps.edu/npspubs/scholarly/theses/2005/Jun/05Jun_Schaeffer.pdf
[Ucore_11] “Ucore”, Wikipedia. Retrieved 4/29/11. http://en.wikipedia.org/wiki/UCore
MIS/Global Defense Inc.
32
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
4 Summary of Study into Reducing SWAP for Asset Management
RFIDs
4.1 Summary of SWAP Study Findings
4.1.1 Processor Trends and projections
For the same functionality and clock speeds, we can expect power to reduce by 19% each year
and die size reductions of 30% per year ( 1 1/ 2 ). Note that reductions in die size do not
immediately translate to reductions in area as packaging must also be taken into consideration.
Thus without investing new monies, it can be expected that the SWAP for the same capability
will improve year over year. Also, while each generation of fabrication technologies is more
expensive, older generations of processors are typically much cheaper. So if price is the driving
factor, relying on older generation processors can be used, at a tradeoff of reduced performance
and power and increased area.
4.1.2 System on Chip, mixed signals, and RFICs
As feature sizes reduce, not only will digital components improve, but analog components on RF
Integrated Circuits and Mixed Signal chips will also improve, albeit more slowly. The expected
performance improvements (and decreases) are covered extensively in [Jiménez_05] from which
the following extracts key information. Broadly, improvements in CMOS technology are related
to digital performance and RF performance as shown in Figure 19 where only IP3 (3rd order
intercepts) are degraded by CMOS technology trends.
Figure 19: Connection between CMOS technology, digital performance, and RF performance. From
[Jiménez_05]
More specific relationships with scaling parameters are shown in Figure 20. From this table, we
can notice the following:
 Conventional (digital) CMOS technology scaling does not improve any analog / mixed
signal parameter.
 Constant current (and area) scaling improves transconductance and dynamic range, but
does not improve maximum max. transconductance and reduces max. dynamic range.
MIS/Global Defense Inc.
33
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report



Constant power (and area) scaling allows increasing biasing current, and therefore
maximum transconductance is increased and maximum dynamic range is not reduced (it
stays constant with scaling).
Both 1/f noise and mismatching worsen with conventional CMOS digitally driven
scaling.
Area must be kept constant with scaling to maintain the same mismatching effects and
reduce 1/f noise.
Figure 20: Scaling factor relationships ( is the same as S from the digital scaling discussion). From
[Vittoz_90]
Since maintaining a constant area is important for maximizing analog circuit performance, this
has the effect of making the analog portion of the area of an integrated IC consume an
increasingly larger fraction of the chip as technology scales and in turn limits cost savings (per
transistor) that come from improved technologies.
Figure 21: Expected trends for mixed circuit chips in area and cost by fabrication technology. From
[Jiménez_05]
MIS/Global Defense Inc.
34
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Similar limitations apply to scaling down voltages where decreasing voltages applied to analog
components greatly reduces dynamic range. This is discussed in more depth in [Larson_03] and
[Hanson_06]. Thus reductions in power consumption for analog integrated components is
normally much less.
After defining some general figures of merit for critical analog components, [Jiménez_05]
calculates the expected values for different generations of CMOS technologies as shown below.
Note that for all four classes, significant improvements can be expected (though less for VCOs),
but this will come with limited reductions in area and power.
Figure 22: Expected relative performance levels following ITRS projections for LNAs, VCOs, Pas, and ADCs.
From [Jiménez_05].
4.1.3 Antenna Miniaturization
In general, the larger the antenna, the better the performance of a communications link.
However, this runs counter to the goal of smaller, less intrusive emplacement of a wireless
sensor. To counter this trend, many different developers have taken different approaches to
reducing the apparent size of antennas by embedding them on the circuit boards on which the
chips are boarded, within the chips themselves, and as part of the packaging of the device. To
Note that these techniques to reduce the size of an antenna often induce directionality to the
antenna and can reduce radiative effectiveness which has the effect of increasing transmit power.
Integrating an antenna into another component also tends to reduce maintenance costs as
antennas do not protrude limiting damage. Conversely, because of the modified radiative
patterns, more time can be required to optimally site the device based on its environment.11
4.1.4 Packaging
Ideally transparent, packaging determines the connection between the chip and the board. Any
deviation from an ideal package causes mismatches increasing insertion loss (increasing power)
and causing reflections (degrading signal quality). Care needs to be taken in the design /
selection of packaging for the intended signals as insertion losses can grow quite high.
A great many different packaging types exist including those listed in Figure 23. In general the
choice is determined by the die size, operating frequency/speed, pin count requirements, size and
cost (variations of a few orders of magnitude, e.g., from pennies to tens of dollars are possible).
11
A great example of this is the iPhone 4 antenna which is integrated into the case of the iPhone. But holding the
phone the “wrong” way can significantly decrease antenna performance.
MIS/Global Defense Inc.
35
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Figure 23: Example Packaging solutions. From [Pack_09]
4.1.5 Energy Scavenging
For sensors intended to be left in place for long period of time, power minimization is frequently
driven by a desire to minimize the effort and cost associated with replacing batteries and
servicing sensors. In addition to reducing power consumption, it is also possible to generate
enough power from ambient conditions to support low power devices. For example, the Seiko
Kinetic wrist watch is primarily powered from the motion of your arm. Such a capability is
known as energy scavenging and has also been the focus of much research, and is in fact the
focus of a current Zigbee standardization effort.12
Almost any power source in the environment can be used. In addition to significant variation in
power availability, the suitability of any given energy scavenging technique depends on the
environment, i.e., the forms of available ambient energy. Thus no one-size fits all energy
scavenging technique can be applied to all possible sensors. Also note that energy scavenging
techniques typically have to be exploited opportunistically and stored as power sources come and
go (e.g., night and day).
12
www.zigbee.org/imwp/download.asp?ContentID=16107
MIS/Global Defense Inc.
36
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Figure 24: Energy Densities for Commonly Available Energy Scavenging Sources
4.1.6 Nanotechnologies for Sensors
[NSET] writes that nanotechnology is “the understanding and control of matter at dimension
between 1 nanometer (nm) and 100 nm, where unique phenomena enable novel applications.
Encompassing nanoscale science, engineering, and technology, nanotechnology involves
imaging, measuring, modeling, and manipulating matter at this length scale.” In general,
nanotechnology can also be applied directly to make ultra-small self-contained sensors. Further,
nanotechnology also allows for direct measurement of much smaller phenomena which allows
things to be detected that might not otherwise be possible or be extremely expensive to detect. In
fact [NSET_09] writes that
The most transformative opportunity for nanotechnology lies in the discovery and
application of transducers based on unique material properties and unusual phenomena
that emerge at the nanoscale….
The use of nanoscale materials in sensing applications is growing quickly, with
encouraging early results. Carbon nanotubes, nanostructured metal oxides, polymers, and
many other materials are being functionalized with chemical and biological species to
selectively identify specific analytes. These technologies are leading to smaller, more
capable environmental monitors for sensing ammonia, nitrogen oxides, hydrogen
peroxide, hydrocarbons, volatile organic compounds, and other potentially hazardous
gases. Early commercial examples include sensors that use carbon nanotubes to detect
ozone in water and air, and hotplate transducer arrays coated with nanostructured tin
oxide that are used for automotive cabin climate control. Metal and dielectric films
patterned at the nanoscale, able to control and amplify electromagnetic signals, are
another example of nanotechnology-enabled sensing capability.
So nanotechnology can be applied to detect minute traces of gasses or particles as described in
[Stonybrook] and [EPA], as well as chemical constituent concentration, separation, and
transduction, energy harvesting and storage, computing systems to analyze transducer response,
and opto-electriconic systems for communications. Additional examples of nanotechnology
sensors include enhanced spectroscopy and artificial pores to detect single molecules [Lucas],
and the use of self-assembled quantum dots for IR detector application [Amirtharaj_02].
MIS/Global Defense Inc.
37
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
In general, this is another area where millions, if not billions, of dollars are being invested right
now to make smaller and more effective sensors. The system design should be open to
accommodating new sensor designs as they become available. However, the possibility of sensor
degradation should be accounted for in the design and maintenance of any system.
4.1.7 General System SWAP Considerations
Additionally, SWAP can be managed via system and design considerations including the
following general principles:
 Minimize duty cycle to only transmit when needed, and only transmit the minimum
needed, including protocol overhead
 Likewise aggressive sleep-modes should be used for all processors
 Minimize voltage use as much as possible, and possibly by component but take care as
lower voltages reduce RF performance
 A switch-mode regulator with low quiescent current can increase battery lifetime
 Use power control to limit transmit power
 Faster crystals and PLLs can reduce active processing time (see Figure 25).
 Use carrier-sense recognition to start a receiver to limit the number of active circuits
Figure 25: Typical Power Profile of a low-power Wireless Sensor. From [TI_LPRF]
4.2 Recommendations from SWAP Study
Billions of dollars is being spent by the public and private sectors to reduce the size, weight,
power, and cost of wireless components and sensors. It seems unlikely that additional research
funds will do much to broadly change the direction of these trends. However, the design should
capitalize on the principles and trends outlined in this Section.
If the direct manufacture of chipsets is envisioned, then the aspects discussed in this report need
to be studied further and put into practice to minimize SWAP and cost, e.g., using integrated
MIS/Global Defense Inc.
38
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
antennas, maximizing the amount of functionality implemented digitally, making systems
considerations on how to reduce power, and integrating as many components into a single chip
as possible to reduce I/O losses. But if the end design is the integration of existing components,
then continued monitoring of products and related technologies is likely sufficient. Regardless of
the approach, using an antenna fabricated into the chip or board can significantly decrease
effective area, but will likely reduce performance somewhat.
As an example of a related technology, energy scavenging is an effective technique for reducing
the amount of time required to service batteries and can be used to reduce battery requirements in
general (typically reducing size, weight, and power). Thus energy scavenging should be included
as part of any persistent wireless sensor network. However, the design will need to support
multiple types of energy scavenging sources for different emplacements, e.g., vibrational or
electromagnetic for motor sensors, solar for sensors on outdoor pallets, and kinetic for personal
sensors.
The adoption of nanotechnology will generally decrease the SWAP and cost of all components
except for analog RFIC components which require constant area and near-constant voltage
scaling to maximize performance. Further nanotechnology enabled sensors open up the
possibilities of new and more powerful sensors as surface and molecular level physics are able to
be exploited. However, as with all sensors, their performance will be expected to degrade over
time, so incorporating automated calibration may be desirable.
Though not the particular focus of this portion of the report, it is important to note that the type
of battery used has a significant impact on the usable lifetime of a device as all batteries decay in
energy storage capability over time and some much more quickly than others. Thus even if a
wireless sensor has greatly reduced power consumption and is able to scavenge for all of its
needs,
Figure 26: Battery Life: Energy Density over time for various battery technologies. From [Xue_07]
Additionally, though not a different technology, code optimization can have a significant impact
on performance reducing execution cycles by 50-70%. However, this only has a particularly
MIS/Global Defense Inc.
39
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
noticeable impact on power consumption when used in conjunction with processors that can
aggressively manage their sleep modes as clocks continue to execute.
4.3 References from Miniaturization / SWAP study
[Altera_03] Altera, “An Analytical Review of FPGA Logic Efficiency in Stratix, Virtex-II, &
Virtex-II Pro Devices,” Altera White Paper, May 2003, Available online:
http://www.altera.com/literature/wp/wp_stx_logic_efficiency.pdf
[Altera_05] Altera, “Stratix II and Virtex IV Power Comparison & Estimation Accuracy,” Altera
White Paper, August, 2005, Available online:
http://www.altera.com/literature/wp/wp_s2v4_pwr_acc.pdf
[Amirtharaj_02] P. Amirtharaj, et al., “The Army Pushes the Boundaries of Sensor Performance
through Nanotechnology,” AMPRIAC Quarterly, Volume 6, No 1, Spring 2002, pp 49-56.
[BDTI_06] “BDTI Pocket Guide,” BDTI, http://www.bdti.com/pocket/pocket.htm
[Brodkin_08] J. Brodkin, “Shift to multicore processors inevitable, but enterprises face
challenges,” LinuxWorld, February 2008. Available online:
http://www.linuxworld.com/news/2008/022708-multicore-processors.html
[Chen_11] G. Chen, H. Ghaed, R. U. Haque, M. Wieckowski, Y. Kim, G. Kim, D. A. Fick, D.
Kim, M. Seok, K. D. Wise, D. Blaauw, and D. Sylvester, "A Cubic-Millimeter EnergyAutonomous Wireless Intraocular Pressure Monitor," IEEE International Solid-State Circuits
Conference (ISSCC), San Francisco, California, pp. 310-311, February 2011.
[Commstack_03] “Why License Commstacks OFDM Modem IP Cores,” CommStack white
paper, 2003. Available online:
http://www.commstack.com/WhyLicenseCommStacksOFDMModemIPCoresv2.pdf
[Crocket_98] J. Crocket, “DSP Architectures for Wireless Communications,” 1998 International
Symposium on Advanced Radio Technologies.
[Enea_04] “Enea Supports TI’s OMAP with Bundled Multi-Core RTOS Platform,” ENEA Press
Release, March 31, 2004. Available online:
http://www.embeddedstar.com/press/content/2004/3/embedded13813.html
[EPA] http://www.epa.gov/ncer/nano/research/nano_sensors.html
[Evans_07] J. Evans, “Analog Spectral Processors,” MTO Symposium 2007, Available online:
http://www.mtosymposium.org/2007/posters/Communication/52_Evans_ASP.pdf
[Gardiner_07] B. Gardiner, “IDF: Gordon Moore Predicts End of Moore's Law (Again)” Wired,
Sep 2007, http://blog.wired.com/business/2007/09/idf-gordon-mo-1.html
[Gardiner_08] B. Gardiner, “Tick-Tock: Researcher Says Silicon Chips Have Four Years of
Improvement Left,” Wired, March 2008, Available online:
http://blog.wired.com/business/2008/03/researcher-says.html
[Gargini_04] P. Gargini, “Sailing with the ITRS into Nanotechnology,” Semicon West, July 12,
2004.
MIS/Global Defense Inc.
40
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
[Gargini_08] P. Gargini, “Overcoming the Red Brick Walls,” Industry Strategy Symposium, Jan
2008. Available online: http://download.intel.com/technology/silicon/orbw.pdf
[Grochowski_06] E. Grochowski and M. Annavaram, “Energy per Instruction Trends in Intel
Microprocessors,” Technology @ Intel Magazine, March 2006. Available online:
ftp://download.intel.com/pressroom/kits/press/core2/epi-trends-final2.pdf
[Hanson_06] S. Hanson, D. Sylvester, and D. Blaauw, "A New Technique for Jointly Optimizing
Gate Sizing and Supply Voltage in Ultra-low Energy Circuits," IEEE/ACM International
Symposium on Low-Power Electronics Design, Tegernsee, Germany, pp. 338-341, October 2006.
[Ireton_06] M. Ireton and M. Kardonik, “Using a multicore RTOS for DSP applications,”
DSPDesignLine, July 17, 2006. Available online:
http://www.embedded.com/columns/showArticle.jhtml?articleID=190500287
[ITRS_07] “Executive Summary,” The International Technology Roadmap for Semiconductors:
2007, Available online: http://www.itrs.net/Links/2007ITRS/ExecSum2007.pdf
[IWPC] “IWPC Trends in RF Integrated Packaging,” IEEE MTT-S, June 2004
Ft. Worth, TX USA. Available online:
http://www.iwpc.org/TempDocs/IWPC_Trends_in_RF_Integrated_Packaging5.pdf
[Jalan] V. Jalan “Energy Scavenging For Wireless Sensor Networks,” Available online:
http://intranet.daiict.org/~ranjan/sn/presentations/Energy_Scavenging_For_Wireless_Sensor_Networks.pdf
[Jiménez_05]
J. Jiménez, “AMS and RF technology roadmap,” Available online:
http://petrus.upc.es/limits/roadmap_AMS_RF_qt05.pdf
[Jones_04] M. Jones, “Energy Scavenging for Wireless Sensor Networks,” Available online:
http://www.howelljones.ca/tech/energyscavengefull.pdf
[Larson_03] L. Larson, “Silicon Technology Tradeoffs for Radio-Frequency/Mixed-Signal
“Systems-on-a-Chip,” IEEE Transactions on Electron Devices, Vol. 50, No. 3, March 2003.
[Lee_05] K. Lee, et al., “The impact of semiconductor technology scaling on CMOS RF and
digital circuits for wireless application,” Electron Devices, July 2005 vol 52, issu3 7, pp. 14151422.
[Leopold_07] G. Leopold et al., “High-k push brings anxiety as 32 nm looms,” EE Times,
December
17,
2007.
Available
online:
http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=204803606
[Linux_07] “The Core of the Issue: Multicore and You,” Linux Magazine, November 13, 2007.
Available online: http://www.linux-mag.com/id/4311
[Lucas] D. Lucas et al., “Nanotechnology-Based Environmental Sensing,” Available online:
http://superfund.berkeley.edu/research-projects/project-5-nanotechnology-based-environmentalsensing/
[Matthew_04] S. Matthew, et al., “A 4GHz 300mW 64b Integer Execution ALU with Dual
Supply Voltages in 90nm CMOS,” ISSCC 04.
[Maxfield_08] C. Maxfield, “Xilinx Responds to Altera’s Benchmarks,” Programmable Logic
Design Line, May 30, 2008. Available online: http://www.pldesignline.com/blogs/208401153
MIS/Global Defense Inc.
41
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
[McKenney_07] P. McKenney, “SMP and Embedded Real Time,” Linux Journal, January 1,
2007. Available online: http://www.linuxjournal.com/article/9361
[Moore_03] G. Moore, “No Exponential is Forever,” International Solid State Circuits
Conference 2003, Available online:
http://download.intel.com/research/silicon/Gordon_Moore_ISSCC_021003.pdf
[Neel_02] J. Neel, “Simulation of an Implementation and Evaluation of the Layered Radio
Architecture,” MS Thesis, Virginia Tech December 2002.
[Neel_04] J. Neel, S. Srikanteswara, J. Reed, P. Athanas, “A Comparative Study of the
Suitability of a Custom Computing Machine and a VLIW DSP for Use in 3G Applications,”
IEEE Workshop on Signal Processing Systems SiPS2004, Oct 13-15, 2004, pp. 188-193.
[Neel_05] J. Neel, P. Robert, J. Reed, “A formal methodology for estimating the feasible
Processor solution space for a software radio”, SDR Forum Technical Conference 2005, Orange
County, CA, Nov. 14-18, 2005, #1.2-03.
[NSET_09] NSET, “Nanotechnology-Enabled Sensing, Report of the National Nanotechnology
Workshop,” May 2009.
[Pack_09] “Developments in Packaging: RFIC, MMIC, LTCC, SiP, SoC,” High Frequency
Electronics, June 2009. Available online:
http://www.highfrequencyelectronics.com/Archives/Jun09/HFE0609_TechReport.pdf
[Patel_05] C. Patel, “Lecture 11: Scaling,” UMBC, October 2005. Available online:
http://www.csee.umbc.edu/~cpatel2/links/640/lectures/lect11_scaling.pdf
[PC_04] “PC102 Product Brief,” PicoChip, March 2004.
[Rivoallon _02] F. Rivoallon, “Comparing Virtex-II and Stratix Logic Utilization,” Xilinx White
Paper 161, June 2002, Available online:
http://www.xilinx.com/support/documentation/white_papers/wp161.pdf
[SDRF_08] SDR Forum “Cognitive Radio Definitions and Nomenclature,” Working Document
SDRF-06-P-0009-V0.5.0, May 30, 2008.
[Silva_06] M. Silva, J. Ferreira, “Support for partial run-time reconfiguration of platform
FPGAs,” Journal of Systems Architecture: the EUROMICRO Journal, vol 52 issue 12, pp. 709726, December 2006.
[Soni_01] M. Soni, “VLSI Implementation of a Wormhole Run-time Reconfigurable Processor.”
MS Thesis, Virginia Tech, 2001.
[Stonybrook]
http://commcgi.cc.stonybrook.edu/am2/publish/General_University_News_2/New_Sensor_Nano
technology_Developed_by_Stony_Brook_University_Researchers_Simplifies_Disease_Detectio
n.shtml
[TI_07] “Texas Instruments Goes Beyond 3G with New LTE Offering for Wireless
Infrastructure,” Texas Instruments Press Release, April 2007, Available online:
http://focus.ti.com/pr/docs/preldetail.tsp?sectionId=594&prelId=sc07077
[TI_08] Texas Instruments, “TMS320C6414T, TMS320C6414T, TMS320C6414T Fixed-Point
Signal Digital Signal Processors,” Texas Instruments Datasheet SPRS226L, February 2008.
MIS/Global Defense Inc.
42
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
[TI_LPRF] Texas Instruments, “Designer’s Guide to LPRF,” Available online:
http://focus.ti.com.cn/cn/lit/sg/slya020a/slya020a.pdf
[West_07] J. West, “Intel Ships New Hafnium Assisted Transistors,” Inside HPC, November
2007, http://insidehpc.com/2007/11/12/intel-ships-new-hafnium-assisted-transistors/
[Vittoz_90] E. Vittoz, “Future of analog in the VLSI environment,“ IEEE International
Symposium on Circuits and Systems, 1990., pp. 1372 -1375 vol.2.
[Wiki_08] “Transistor Count,” Wikipedia, http://en.wikipedia.org/wiki/Transistor_count
[Xilinx_07] Xilinx, “Virtex-II Platform FPGAs: Complete Data Sheet,” DS031 (v3.5),
November 2007, Available online:
http://www.xilinx.com/support/documentation/data_sheets/ds031.pdf
[Xue_07] X. Xue, L. Gonzalez-Argueta, V. Sundararajan, “Energy Scavenging Methods for
Wireless Sensor Networks,” IDETC 2007 September 4-7, 2007, Las Vegas, Nevada, US
MIS/Global Defense Inc.
43
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
5 Future Plans for Situational Awareness Application
Broadly, the intention is to create an app deployable across all smartphone platforms that
supports the fusion of data from all known ISR and SA systems (this effort will extend beyond
Phase II). This app would support interfacing with tactical radio networks, customizable views,
customizable information distribution, multiple map sources, tools for reporting, Blue-Force
tracking, tasking sensors and unattended vehicles, routing, and surveillance capabilities.
In the immediate future, we plan on returning to Camp Roberts for further testing and user
interaction on the ICOTS application at the beginning of August, 2011. A wider view of our
plans to further enhance ICOTS is described in the following.
5.1 Position Within the Smart Phone and Situational Awareness Ecosystem
The following briefly describe many of the systems, programs, envisioned app stores, and
devices that the iCOTS application should support.
5.1.1 Other DoD Situational Awareness systems beyond COT and DCGS
Integrated Information Management System (IIMS) – a USAF and USA sponsored; scalable
system that supports a common operational picture for commanders and geographically
separated unit control centers addressing conventional and Chemical, Biological, Radiological
and Nuclear (CBRN) events
Joint Environment Toolkit (JET): a USAF net-enabled weather service provider to facilitate
strategies in support of operational decisions.
Cross Domain Collaborative Information Environment (CDCIE): Developing out of United
States Joint Forces Command (USJFCOM) CDIE enables joint forces to share information in
the form of chat/whiteboarding (with language translation interface) and web services between
DoD and non-DoD networks of various security classifications with coalition partners, other
government agencies, and Non Governmental Organizations (NGO).
Event Management Framework (EMF): The EMF Advanced Concept Technology
Demonstration (ACTD) enables users to efficiently and effectively search, correlate, assess, and
present actionable information from disparate sources across the Air, Land, Maritime, Cyber, and
Space and Missile Defense domains.
Next Generation Wireless Communications for Logistics Applications (NGWC): An advanced
wireless mesh capability for global logistics visibility, supports today’s tactical and strategic
logisticians, operates in unimproved locations, and does not require a fixed ground infrastructure.
5.1.2 Programs
Connecting Soldiers to Digital Applications (CSDA): an initiative sponsored by the Army
Capabilities Integration Center and the Army CIO with support from the Army Training and
Doctrine Command and other Army organizations, according to an Army news release. While
Phase 1 considered several training- and office-oriented pilot projects using a variety of smart
phones, Phase 2 is more on point in its assessment of the value of smart-phone apps for tactical
operations (which applies to ICOT).
MIS/Global Defense Inc.
44
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Multi-Access Communications Extender (MACE) – a CERDEC program to develop a tactical
communications architecture that can support smartphone devices on the tactical battlefield, with
intended support for commercial smartphones.
Transformative Apps – a DARPA program to develop apps and an ecosystem for military
smartphones
5.1.3 Devices
While many smartphone devices from many different vendors are anticipated to be eventually
deployed, the GD-300 and RATS are the two leading existing solutions on which ICOT could be
deployed. Note that both are Android based and no Android phone has started going through the
process of having the National Institute of Standards and Technology certify it as secure-enough
to host government data.13 As the iPhone has started the process, this motivates our initial
targeting of the iOS family.
Android-based GD300 (General Dynamics)
Android based RATS (Raytheon)
5.1.4 App Stores
Despite statements that there is a desire to provide a common store front for all military apps,
there will likely be multiple app stores. Based on what documentation currently exists, it appears
that these will allow more interactions between users and developers than traditional app stores
and will require security approvals.
Transformative Apps Store – An app store being created by the Corporation for National
Research Initiatives (CNRI) under the Transformative Apps program.
Army Marketplace – The app store developed by the Army as an outgrowth from the Army Apps
challenge, with possible formal roll-out later this year.
13
http://www.wired.com/dangerroom/2011/04/armys-app-store-for-war/
MIS/Global Defense Inc.
45
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Figure 27: Screen Capture from pre-release version of the Army App Store: Army Marketplace
(http://www.wired.com/dangerroom/2011/04/armys-app-store-for-war/)
5.2 Collaboration Discussions
In light of a likely later need to support deployment onto the GD300 and RATS, we have begun
initial discussions with General Dynamics and Raytheon. In particular we recently submitted a
SBIR proposal to the Army where MIS/Global Defense will team with Raytheon to extend the
design of ICOTS to address the following issues:
 Supporting P2P data distribution
 User customization of distribution, views, and data sources
 An evolvable framework to support additional systems and application “mashing”
 Interfacing with Distributed Common Ground System (a Raytheon supported Situational
Awareness system used by the Air Force and Army)
 Interfacing smart phones with tactical radios via Ethernet or USB
 Securing communications appropriate for SBU, Secret and above, with a particular focus
on security ramifications of combining data from multiple sources.
5.3 Development Roadmap
Our near-term roadmap assuming funding from the SBIR is shown below. In particular there are
plans to for a capability for interfacing with DCGS and lay the foundation for creating an
extensible API for “plugging-in” interfaces and data fusion from additional ISR / SA standards
and custom sensors and UAVs. From mid 2012 on, our software will be ported to Titanium to
support additional smart phone platforms, the security and peer-to-peer communications
technologies and tactical network interfaces would be matured. In parallel to that effort, the COT
interface would be matured, a SAHANA interface created, and various features related to
enhancing situational awareness (supporting additional video feeds, telestration, after action
reporting) and core services would be developed and integrated.
MIS/Global Defense Inc.
46
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Figure 28: ICOT Roadmap assuming additional funding
Some of the planned steps include the following
 Create generalized interfaces for interfacing with most prevalent sensors and UAVs
 Develop packages for 3rd parties to develop plug-in interfaces for other sensors currently
under development.
 Stand up the server for multiple-level authentication and access and CoT data distribution
 Create a secure interface for adding the iCoT capability to authenticated smartphone
users
 Perform extensive field tests and demonstrations to ensure readiness for field deployment
and to make final revisions to the design based on user feedback
To better integrate the system (iCOT or ATAV) with vehicles, an integrated connection server
and local data cacher, which we refer to as the iNode, will be developed as shown in Figure 29.
The iNode supports a variety of interfaces and wireless connections and is responsible for
integrating data from local devices, local distribution, and interfacing with the broader CoT
network. Supported wireless interfaces include WiFi and ZigBee for interfacing smartphones,
tablets, and sensors. Supported wired interfaces include Ethernet, USB, and serial ports. By
connecting other communications assets to the iNode via the Ethernet port, the iNode will be
able to communicate over additional networks.
MIS/Global Defense Inc.
47
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Figure 29: View of iNode integration
MIS/Global Defense Inc.
48
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Appendix A
Conceptual Prototype Design Document
A.1 OVERVIEW
The RFID iPhone Reader app will offer
 asset management,
 asset tracking,
 wireless communication with RFID tagged assets,
 wireless communications with server over IP cloud with cellular, WiFi (later) HF
connections
 asset maintenance support
 search capabilities
 map view of assets by location (later directions and relative location display)
 Local storage of data for off-line management
 User authentication
This native iPhone app is coded in Objective C using Xcode. The user interface for the reader
app is designed using XCode and Interface Builder.
A.2
USER INTERFACES / VIEWS
A.2.1 Main TabBar View
The main navigation controller for reader app with the following buttons
 Connectivity button – displays connectivity view.
 Map button - displays the map view.
 Asset Manager Button – displays the asset manager view.
 RFID button – displays asset list view of nearby assets.
 Alert button – displays asset list view of all nearby asset alerts messages.
A.2.2 User Authentication
First screen shown at Reader start-up. Collects badge ID and password from user. “Login”
returns ATAV main screen or authorization failure message. UITabbar options at bottom of
screen are disabled until successful authentication is complete. Once authentication is complete,
badge ID number is shown at the top of all subsequent views except history/list views. Calls the
“user authentication” external database function.
MIS/Global Defense Inc.
49
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
A.2.3 Connectivity View
Displays connectivity options. Allows user to select connection types by toggling UISwitch for
each connection method. Displays signal strength indicators. Interfaces with iPhone reader
RFID Bluetooth using the “check connectivity” and “update connectivity” functions.
MIS/Global Defense Inc.
50
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
A.2.4 Map View
Shows user’s current location and asset(s) on UIMapView. Allows user to select pinned map
item for Asset Detail View. List button allows user to toggle assets list/type shown on map.
Search button allows user to search for a particular RFID or class of RFIDs by type, location.
Calls “asset list”, “asset detail” external database functions. When map is unavailable, displays
“NETWORK ERROR” UIAlertView message.
MIS/Global Defense Inc.
51
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
A.2.5 History/log view
Display asset history in UITableView. Shows date, time, location and event description for each
event in history. Allows user to sort table data by column.
Calls “asset history” external database function. When no data found displays “No Data Found”
or “NETWORK ERROR” in UIAlertView message.
MIS/Global Defense Inc.
52
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
A.2.6 Asset management view
Gives user option to search for assets or add a new asset. “Add asset” returns the add asset view.
Logout returns user to main login view, Info button brings up help view.
MIS/Global Defense Inc.
53
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
A.2.7 Add new asset view
Enter relevant information and add new asset to database. (UITextFields) including: capture
asset picture using UIImagePickerController, ID, Tags, manifest, comments. “Take photo”
allows user to take photo with iPhone using UIImagePickerView. “Done” submits the
transaction to the Sqllite database and the external database using the “add asset” function.
Returns “SUCCESS” or “NETWORK ERROR” in UIAlertView message.
MIS/Global Defense Inc.
54
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
A.2.8 Alert Views
Displays a list of asset alerts detected using RFID network API interface. Updates tab-bar badge
number with alert count. When data is unavailable, displays “NETWORK ERROR”
UIAlertView message.
MIS/Global Defense Inc.
55
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
A.2.9 Asset Detail
Displays detailed information about a particular asset including: a picture (if available), ID, Tags,
manifest, comments, more info link, parent ID, child IDs, time in container, time in current
location. Calls the “asset detail” external database function. When data is unavailable, displays
“NETWORK ERROR” UIAlertView message. Pressing edit button allows editing of the tags,
comments, manifest fields.
MIS/Global Defense Inc.
56
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
A.2.10 Asset List View
Shows list of assets based on location, ID, or type. Displays ID, tag, and most recent event in
UITableView. Can select asset detail for items displayed. Calls the “asset search” external
database function. Uses “detect RFID” network API function when called by RFID tabBar
button. Touching list item will bring up Asset Detail View. When list is unavailable displays
“NETWORK ERROR” UIAlertView message.
MIS/Global Defense Inc.
57
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
A.2.11 Web View
Displays UIWebView with URL provided in “asset detail” function. When URL is unavailable,
displays “NETWORK ERROR” UIAlertView message.
MIS/Global Defense Inc.
58
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
A.3 DATA INTERFACES
The iPhone reader application utilizes several data interfaces.
A.3.1 MySQL server database
Using WiFi, Cellular 3G, TCP/IP sockets and ASP.NET web services. All data is returned as a
JSON object. Database objects are parsed using an Objective C JSON data parser. The
following data interactions are used:
Asset detail – used to retrieve detailed information about an asset based on asset ID.
MIS/Global Defense Inc.
59
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
IN
ASSET RFID
OUT
TAGS
MANIFEST
REF. URL
COMMENTS
LOCATION
PARENT
CHILDREN
LAST EVENT TYPE
LAST EVENT DATE
LOCATION DATE
ARRIVAL DATE
Asset update– stores updated events or database fields for an asset, based on ID
IN
ASSET RFID
EVENT
TAGS
REF. URL
LOCATION
IMAGE
MANIFEST
COMMENTS
OUT
RESPONSE CODE
Asset search– retrieves list of assets by type or location, parent or child.
IN
OUT
TYPE/TAG
ASSET RFID
LOCATION
MANIFEST
PARENT RFID
LOCATION
CHILD RFID
IMAGE
(partial) ASSET RFID
Add asset – used to insert a new asset record into the database
IN
OUT
(ASSET RFID) server?
RESPONSE CODE
TAGS
REF. URL
LOCATION
IMAGE
MANIFEST
COMMENTS
MIS/Global Defense Inc.
60
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Asset history – retrieve management and event information for a given asset based on ID. (30
rows at a time, starting with most recent)
IN
OUT
ASSET RFID
(Start ROW, End ROW) ||
(Start DATE, End DATE)
EVENT TYPE
EVENT DATE
IMAGE OR IMAGE URL
BADGE ID
COMMENTS
IMAGE
User Authentication – authenticates iPhone RFID Reader app user login credentials against user
database. Returns a validation or failure message.
IN
OUT
BADGE ID
PASSWORD
Opt: (PICTURE)
RESPONSE CODE
ROLES
Opt: (PICTURE)
Synchronization – upload new RFID information (events) to the server. Append to end
IN
OUT
ASSET RFID
EVENT LIST
RESPONSE CODE
A.3.2 SQLlite interface
SQLLite Provides local temp storage of asset / event / management data on iPhone device when
server communication is unavailable. When server communication becomes available again,
system will upload stored data. Keeps log of all reader transactions.
A.3.3 RFID network API –
Objective C library that uses Bluetooth to detect / communicate with RFID tags. Retrieves ID
and any stored events. Provides the following functions:
 Detect RFID – returns a list of all RFID’s nearby
 RFID Change notification – notifies reader app of RFID composition changes.
 Check RFID – returns RFID ID, and stored data
 Check Connectivity – returns connectivity status and strength
 Update Connectivity – modify connection type – Bluetooth, HF, 2G, 3G, WiFi.
MIS/Global Defense Inc.
61
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
A.4
ATAV Location Detector
A.4.1 Supported APIs
Detect RFID()
Returns a list of all RFIDs nearby
Begins search for local RFIDs within range. Found RFIDs are added to a list which is returned. It
will return an empty list if no RFIDs are found.
IN
OUT
NSARRAY
Register as delegate for listenerRFID
RFIDDetect checkforRFID method invoked
Listener method returns the RFID and the GPS coordinates for each device in an NSARRAY
object:
 RFID
 LONGITUDE
 LATITUDE
 NSDICTIONARY: DESCRIPTION, EVENTID,
 DATE/TIME
Update RFID
Clears alarms, updates RFID object status.
Search detected RFIDs and checks for major alarm event. Items that have an alarm event are
added to a returned list. It will return an empty list if no alarms are found.
IN
OUT
RFID
STATUS CODE
Register as delegate for updateRFID
clearHistoryRFID
Send RFID - return status code 0=success -1= failure
clearAlarmRFID
Send RFID, alarm ID - return status 0=success -1= failure
updateStatusRFID
Send RFID, status message - return status 0=success -1= failure
Check RFID
Returns specific RFID ID, and stored data
Searches for a specific RFID and, if found, returns all data received or NIL if the requested RFID
is not found.
IN
OUT
RFID
RFID Data
MIS/Global Defense Inc.
62
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
Register as delegate for checkRFID
RFIDcheck checkRFID method invoked
Listener method returns the RFID and the GPS coordinates for each device in an NSARRAY
object:
 RFID
 LONGITUDE
 LATITUDE
 NSDICTIONARY: EVENTS/ ALARMS
 DATE/TIME
Check Connectivity – returns connectivity status and indicates signal strength
To save power network connectivity is minimal so indicated power for a given RFID refers to
the most recent connection.
.
IN
OUT
Updates
status
connectivity
Call checkConnectivy delegate function
Returns NSARRAY of TYPE and BOOLEAN for status
Update Connectivity – modify connection type (Bluetooth/WIFI)
The user is allowed to choose which method to use to connect to RFIDS.
IN
OUT
BT/WIF
RESULT CODE
BOOLEAN
Call updateConnectivy delegate function
Send TYPE and BOOLEAN value, returns TYPE and BOOLEAN for status.
A.5 Database
Database: MySQL is the DBMS for the project. There are two reasons for selecting MySQL
for the DBMS. First, iPhone actively supports connectivity to the MySQL server should the
project take a different turn and the iPhone needs direct access to data as opposed to gathering
data through a web service. Second, MySQL – natively – supports OpenGIS data structures,
which can be utilized to store asset positions in the database.
Database Terminology: When describing the database and its functions; it is important to
understand the terminology and their relationships.
1. Asset: The asset is the pallet. The pallet contains a collection of items; it is a grouping of
items. When a transaction occurs on an asset, it occurs on all items in the asset. For
MIS/Global Defense Inc.
63
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
example, if an asset is moved to a new location, all items in the asset are moved to that
location.
2. Item: The item is a single entity that is located on a pallet. This may be a box of
ammunition or other single entity. An item can be added or removed from an asset.
3. Transaction: A transaction is a specific event or action that is performed on an item or
asset. This may include moving the asset or retiring – or deleting – an item.
Database Schema: The following sections are descriptions of the tables and the relationships
between them.
1. UserInfo: The UserInfo table stores all information for authenticating users and contains
their respective flags. It also includes information regarding the user.
a. PK: The primary key of the user. It is used to uniquely identify the user.
b. strName: The name of the user.
c. strLogin: The login name of the user. This is the login string the user uses to
authenticate against the server.
d. strPassword: This is the encrypted password for the user. When authenticating
against the server, the password will be decrypted and compared against the
passed value.
e. nFlags: This is a 64-bit integer identifying the flags the user possess. The flags
identify the roles for the authenticated user, allowing or denying various features
of the system.
f. bActive: This is a boolean value, indicating if the user is active or inactive. If the
user is inactive, all authentication for this user will be disabled.
2. Asset: The Asset table contains an entire list of assets that were created for the entire
system. It also contains a description and short description of the asset.
a. PK: The primary key of the asset. It is used to uniquely identify the asset.
b. strShortDescription: A short description of the asset.
c. strDescription: A longer description of the asset. This is a more detailed
description of the asset than the strShortDescription.
3. AssetImage: The AssetImage table is a collection of images that associate with a specific
asset.
a. PK: The primary key of the asset image. It is used to uniquely identify the asset
image.
b. Asset_FK: A foreign key associating the asset image to a specific asset.
c. UserInfo_FK_EnteredBy: A foreign key associating the asset image to the user
who created the image.
d. imgAsset: The raw byte stream of the image. This is the image in binary format.
e. dtEntered: A timestamp indicating the time the image was added to the table.
f. bActive: A boolean value indicating if the image is active or inactive in the table.
4. Item: The Item table contains the entire list of items that were added to assets. It also
contains a description and short description of the item.
a. PK: The primary key of the item. It is used to uniquely identify the item.
b. strShortDescription: A short description of the item.
c. strDescription: A longer description of the item. This is a more detailed
description of the item than the strShortDescription.
MIS/Global Defense Inc.
64
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
5. ItemImage: The ItemImage table is a collection of images that associate with a specific
item.
a. PK: The primary key of the item image. It is used to uniquely identify the item
image.
b. Item_FK: A foreign key associating the item image to a specific item.
c. UserInfo_FK_EnteredBy: A foreign key associating the item image to the user
who created the image.
d. imgItem: The raw byte stream of the image. This is the image in binary format.
e. dtEntered: A timestamp indicating the time the image was added to the table.
f. bActive: A boolean value indicating if the image is active or inactive in the table.
6. AssetTransaction: The AssetTransaction table identifies all transactions for a specific
asset. It includes all movements, splits, and merges of assets. It also logs all transactions
on the item level of the asset.
a. PK: The primary key of the transaction. It is used to uniquely identify the
transaction.
b. dtTransaction: The timestamp that indicates when the transaction occurred.
c. Asset_FK: A foreign key associating this entry with a specific asset.
d. AssetTransactionType_FK: A foreign key indicating the type of transaction that
occurred. See AssetTransactionType table.
e. ptLocation: A point data type indicating the latitude and longitude for the specific
transaction. If it is null, the location where the transaction occurred is assumed to
occur at the last non-null ptLocation.
f. mTilt: The tilt value, in radians, for the specific transaction. If it is null, the tilt
where the transaction occurred is assumed to have the last non-null mTilt.
g. UserInfo_FK_ActionBy: A foreign key that indicates the user who performed the
action. If null, no user “acted on” the asset; this may include when an asset is
moved.
h. Asset_FK_MergeInto: A foreign key to an asset; it indicates that the asset
indentified by Asset_FK has been merged, or joined, into the asset identified by
Asset_FK_MergeInto.
i. Asset_FK_SplitFrom: A foreign key to an asset; it indicates that the parent asset
has been split, creating a new asset, the asset identified by the Asset_FK.
Initially, when split, no items are added to the new asset. They must be transacted
there.
j. ItemTransaction_FK: A foreign key to an ItemTransaction. If the
AssetTransaction_FK indicates that the transaction is an ItemTransaction, this
foreign key identifies this ItemTransaction.
k. bUndo: A boolean value indicating if the transaction should be undone, or
nullified. The default value for all records is false; it must be manually set to true
to nullify the transaction.
7. AssetTransactionType: This table identifies all types of asset transactions; they include
Create, Movement, Retire, Revive, Merge, Split, and Item Transaction.
a. PK: A primary key uniquely indentifying the record.
b. strDescription: A description of the transaction.
c. bActive: A boolean value indicating if the transaction type is active or inactive.
8. ItemTransaction: This table logs all transactions that are invoked on items.
MIS/Global Defense Inc.
65
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
a. PK: A primary key that uniquely identifies the record.
b. Item_FK: A foreign key to an item that this transaction was acted upon.
c. ItemTransactionType_FK: A foreign key to an ItemTransactionType that
indicates the type of transaction that occurred. See the ItemTransactionType
table.
d. Item_FK_MergeInto: A foreign key to an item; it indicates that the item –
identified by Item_FK – has been merged into another item, which is identified by
the Item_FK_MergeInto. Once merged, the item is no longer considered active.
e. Item_FK_SplitChild: A foreign key to an item; it indicates that the parent item
has been split, creating a new item, the item identified by the Item_FK.
Database Diagram:
MIS/Global Defense Inc.
66
Army Total Asset Visibility Enhanced RFID Tracking
Deliverable 5: Final Report
MIS/Global Defense Inc.
67