Robust NEST Systems Minitask Report. Lockheed Martin MIT Mitre OSU UC Berkeley University of Virginia Vanderbilt Santosh Kumar @ OSU. December 2003. Robustness Questions. Given all NEST demos fielded this year, we are in a position to consider:
University of Virginia
Santosh Kumar @ OSU
Given all NEST demos fielded this year, we are in a position to consider:
Kenneth W. Parker, Ph.D.
December 17, 2003
Our task was to searching out robustness problems.
We focused on transition and deployment impact.
The program’s success metric is transition.
Did not design an anti-netted-sensor systems.
We did think thought about counter-measures.
Don’t think this is the top problem.
Maybe 2 years from now.Our Job
One (of many) taxonomies:
UCB timer module can exhibit up to 10% error.
May have been fixed ???
UCB clock is dead-on.
VU timer changes the semantics; less general.
VU clock is finer grained than UCB clock (a rare problem).
UO timer not yet available.
Timers are blocked by tasks.
Almost impossible to be sure no task will be running when the timer event occurs.
Monopole antenna with no ground plane.
Antenna connectors require special tools (easily broken).
We think there’s also an impedance mismatch.
MICA2 MAC layer (8):
Abstracts away needed timing control.
Have retry bugs been fixed ???
Anti-Aliasing Filter (8):
Acoustic sensor can’t be used without an anti-aliasing filter.Flaws and Bugs
SRAM is about the right size for stack and local variables.
Everything else should go in non-volatile memory.
Non-volatile memory uses negligible power when sleeping.
Can be 100 or 10k times bigger for same power level.
Assuming low duty cycle.
External flash is too slow.
There exists a “fast” write method; but not used.
External flash is also too small.
Test Suit (7):
Some better than others.
Few showed up with adequate test suits.
Fault Identification (6):
Need better methods of identifying faults.
Hardware and software faults.Flaws and Bugs (cont.)
Even the single-hop version corrupts the memory, too often.
No wireless recovery possible.
GenericBase chokes on high volume of data.
Does not support the 38.4 kbps transfer rate of MICA2.
Wind guard on the microphone.
General maintenance rate.
5% per day?
Battery management (4):
I have a drawer full of batters that are about 15% used.
Don’t work in motes, but do work in most other devices.
Mote battery death occurs when voltage drops.
Software measurement of remaining capacity (not useful).
Programming Boards (3):
Burn motes if turned on and external power is connected.
Old board often fails to reprogram.Flaws and Bugs (cont.)
Sensor Range (9):
Concealment needs limit node size per coverage area.
Mica2 ~20 sq cm.
One every 15 m might be “lost” in the environment.
One every meter easily found.
Useful area ratios 1e5 to 1e6.
Sensor range must be greater than average density (~ 1.3x).Engineering Challenges (cont.)
Density requirement stemming from concealment criteria.
30 sec to achieve 8 μs sync.
Drifts 30 μs every sec.
Good for ~1/4 sec.
Assuming ±8 μs drift.
i.e., total error ±16 μs.
For many synchronization models, accuracy is proportional to synchronization rate.
i.e., over some region.
Desirable metrics are:
Accuracy per duty cycle.
Range of applicability.
Alternative metrics. e.g. if common model doesn’t apply:
Accuracy at 0.5% duty cycle.
Duty cycle at 1 ms accuracy.Engineering Challenges (cont.)
Flash-Based Data Store (8):
Developed and demonstrated in isolation can’t be combined.
Key problem is timing conflicts.
Timing knowledge is implicit.
May have herd a viable standard:
Use pseudo-random timing.
Low duty cycle service.
Timing collisions result in clean event loss.
All servers can handle occasional event loss.
If this is “the” composition method it’s underused.
LPI and LPD (7):
All active signals must be below the noise floor (at receiver).
Must track noise level.
SNR determines the ratio of signal range to discovery range.
Typically need coding gain plus SNR to be about +6 dB.
Detestability 1 spot in 1000 might need 36 dB coding gain.
1 s interval; 17 min. per node.Engineering Challenges (cont.)
Better Non-Volatile Memory (6):
Several new non-volatile memory technologies.
Ovonic unified memories.
Ideal for low-duty cycle designs.
Debugging Harness (4):
Useful for development; not used in deployment.
Distributed debugging may require far higher comm. rate than the actual application.
Development cycles use far more power than deployment.Engineering Challenges (cont.)
Efficient reliable multi-cast.
An errant program should not be able to prevent loading.
Dynamic linking and loading.
Make incremental structure explicit rather than trying to discover it after the fact.
Extra finer grained.
Multiple levels of security:
Factory approved loads.
Platforms (third party code).
Over-the-air Programming (cont).
Platform grade security:
Protection from live-lock.
Protection from dead-lock.
Protection from corruption.
May require preemption?
Issue will be around for years.
Good enough for FY04.
We’re far from commercial.Technology Challenges
Tends to violate traditional comm. assumptions.
Complex trade space.
Higher power routs may be lower latency.
Wakeup rate vs. latency.
Different tasks may require different walkup rates.
Emergent scheduling vs. centralized scheduled.
Combining multiple services yields complex schedules.
Different states will require different wake up rates.
Node Localization (8):
Must be very robust.
Multipart is key problem.
Not sure it’s really this hard.Technology Challenges (cont.)
What is the best way to detect people?
Nature suggests not sound.
Really want electronic olfactory.
Are there any senor mode for identifying combatants.
Which environments require or benefit from proximal sensing.
What quantities are mot useful in more congested environments.
Chem., bio., speech, power usage, civilian flight, …
Tragedy of the Commons (6):
No incentive to be a responsible user of shared resources.
Not even a widely agreed upon definition of what is fair use.
Want better wealth distribution, but not communism.Technology Challenges (cont.)
Some nodes jabber continuously.
Some sensors, “See ‘reds’ under their beds”
In a real deployment a few nodes may be compromised.
Need mixed probabilistic and worst case analysis framework.
e.g., detection and tracking.
Also need robustness with respect to event loss.
Would greatly improve the viability of security.Technology Challenges (cont.)
Small Antennas (5):
Small Antennas (5):
For a technology family a joules-per-bit-op are nearly constant over a wide range of node size.
Key the vision of small nodes.
Given a fixed energy supply, not much incentive to use a more powerful node.
Mica2 gets ~3GbOPJ.
State of the art ~20GbOPJ.
Not ~300 GbOPJ.
Moore’s law helps this metric slowly (comported to intuition).
Doubles ~4 to 6 years.
Signal Processing Power (cont):
Big wins can be had.
ASICS are typically 400x more efficient.
Fully custom designs may be 1000x more efficient.
Requires use of non-GPP.
DSPs 4 to 12x.
The alternative is to use complex signal processing algorithms.
Clearly part of the vision.
May not be enough.Fundamental Scientific Issues
Taxonomy of scaling:
O(sqrt(N)) or O(cbrt(N)); non-scalable.
O(N Ln(N)); quasi-scalable.
O(N); absolutely scalable.
Not going to build 13 different sized motes.
But we could built configurable motes.
SDR allows you to vary the comm. range.
You can vary the clock rate.
You may even be able to reconfigure the CPU.
Use a sentry-like service to vary the power rate.
Still need 2 or 3 types of hardware, but not 10 to 20.Fundamental Scientific Issues (cont.)
Negligible power, wakeup-triggers can be build for most
Allow lower duty cycles.
Simply software; no polling of environment.
However, such triggers would have to be configurable in-situ.
Need the analog counterpart to FPGAs.
Signal Processing Methods (7):
Legacy signal processing methods assume:
Essence of problem is extracting signal in low SNR.
Next generation of signal processing will need to assume:
Special structure of signals are observable and useful.
Essence of problem is finding the few high SNR signals.
Computation is battery.Fundamental Scientific Issues (cont.)
This may be why technologists fail;
it’s not why (properly managed) technology companies fail.
Driving force is that Moore’s law outruns any sensible growth in demand.