container shipping breakout group l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Container Shipping Breakout Group PowerPoint Presentation
Download Presentation
Container Shipping Breakout Group

Loading in 2 Seconds...

play fullscreen
1 / 8

Container Shipping Breakout Group - PowerPoint PPT Presentation


  • 425 Views
  • Uploaded on

Container Shipping Breakout Group Participants: Cory Sharp [scribe] – UC Berkeley Thomas Sereno – SAIC Ken Traub – Connecterra Ron Kyker – Sandia National Labs Malena Mesarina – Hewlett Packard Labs Robert Szewczyk – UC Berkeley Phil Buonadonna – Intel Mike Manzo – UC Berkeley

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Container Shipping Breakout Group' - arleen


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
container shipping breakout group

Container ShippingBreakout Group

Participants:

Cory Sharp [scribe] – UC Berkeley

Thomas Sereno – SAIC

Ken Traub – Connecterra

Ron Kyker – Sandia National Labs

Malena Mesarina – Hewlett Packard Labs

Robert Szewczyk – UC Berkeley

Phil Buonadonna – Intel

Mike Manzo – UC Berkeley

Jae-Hyuk Oh – United Technologies

NEST Retreat, June 2004, Santa Cruz, CA

deployments
Deployments
  • Shipping container security
    • Intrusion detection
    • Adversarial, networking
  • Container monitoring
    • Report if environment out of tolerance
    • Take immediate action
    • Non-adversarial, networking
  • Radioactive detection
    • Adversarial monitoring
  • Pedigree
    • Log environment data
    • Report once at end, or at least infrequently
    • Non-adversarial, networking
value add over a simple cheap one shot sensor
Value AddOver a Simple, Cheap, One-shot Sensor
  • Data processing
    • Simple, cheap sensors can only detect exceeded tolerances
  • Data collection
    • More data available
    • Manual collection consumes resources
  • Latency
    • Human-inspected detectors significantly increase latency
sensing modes
Sensing Modes
  • Monitoring
    • Adversarial (security) vs. non-adverserial (environmental)
    • Mesh networking, low latency reports
  • Pedigree
    • Less significant networking
  • What kinds of sensing?
installation options
Installation Options
  • Permanent fixture of container
  • Vendor product
  • Consumer devices
core issues
Core Issues
  • Lifetime
    • 5 years is the far upper bound (upgrades)
  • Cost
    • $50/container/port total cost
  • Localization
    • Where is container 1172? (global vs. local)
    • Audience Note: Shipping companies know precisely what and where about every container, needed for balancing
  • RF Connectivity
    • RF leaks through non-water-tight containers
  • Data Logging
  • Interoperability between multiple vendors
core issues 2
Core Issues 2
  • Security
    • Compromised network (authentication, encryption, …)
    • Denial of service, network – spamming packets toward energy exhaustion
    • Denial of service, sensing – bananas and kitty litter excite radioactive detectors
  • Detecting events in variable environments
    • On a ship, temperature, pressure, and vibration changes
    • How do you detect normal variance versus exceptional variance?
  • Calibration
    • Logged/reported data must be meaningful
problems
Problems
  • Validation – how do you know you get data from all the containers?
  • Robustness, Reliability
    • What happens if you lose 10% of the nodes?
    • Do losses generate false positives?
    • Add redundancy? Cost?
  • Latency of data
    • Certain modes may want to spend a lot of energy to guarantee reports (“fire alarm”)
  • Data glut/trunk, energy exhaustion
    • 10,000 nodes reporting
    • Address with multiple gateways / base-stations