CCTS Development Proudly Presents

1
CCTS Development Proudly Presents

• The Cargo Container Tracking
• System
• http//koala.ece.stevens-tech.edu/sd2k01/grp6

2
The Cargo Container Tracking System

• Project Members
• Andrew D. Nikow
• Project Leader
• Michal Kosinski
• Parminder Singh
• Michael Stabile
• Project Advisor
• Prof Y.Yao

3
Client Information

• Interpool Inc.
• Founded in 1968, Interpool is one of the world's
  leading lessors of intermodal dry containers, and
  the largest lessor of intermodal container
  chassis in the U.S
• Primary Services
• The Company leases its equipment to its
  customers primarily on long term leases in order
  to achieve high utilization of its equipment and
  generate stable and predictable earnings.
• Company Information
• Incorporated 1968
• Headquartered in Princeton New Jersey

4
What is Cargo Container Tracking About?

• Cargo Containers (Intermodal Container Chassis)
  Transport more goods than any other mean of
  shipping in the world.
• In 1997 the Commodity Flow Survey estimated
  that 11 billion tons of goods worth 7 Trillion
  Dollars was transported via intermodal
  containers.
• With such a reliance by industry and government
  on this method of transportation there is little
  ability to automatically check locations and
  status of various containers.
• Ability for customers/companies to keep track of
  containers and contents is greatly desired.
• Expansion of world-wide wireless infrastructures
  allows for successful integration of these ideas.
  

5
Overall Project Requirements

• Our primary goal was to construct a prototype
  transponder and gate reader system by Spring of
  2002
• Additionally with the prototype be able to
  exchange information from transponders to gate
  while in motion
• Ideally we would like to develop a standardized
  system that can be developed to new and(or)
  retrofit applications
• Ideally prototype systems can be constructed
  using off-the-shelve components and development
  kits

6
Technical Problems Addressed

• Necessity to develop a finalized Wireless
  Communications Interface
• Finalize Bluetooth Hardware Component Decisions
• Implement and design software necessary for
  direct communications with Bluetooth Hardware
• Develop a Graphical User Interface to provide a
  control and monitor interface for users
• Initiate Automatic Data Transfers of between two
  stations (Base and Host)
• Test and Refine System to Maximize Reliability
  and Accuracy.

7
CCTSystem Version 1.0
Introducing
8
CCTSystem Version 1.0 Background

• Operational Information
• Microsoft Win32 Based Program
• Developed Using Microsoft Visual C .NET
• Hardware Components
• Standard PC running Windows 98 Second Edition,
  ME, XP
• Widcomm Class II Bluetooth Point-to-Multipoint
  Interface Modules
• USB Smart Media Card Reader/Writer
• Smart Media Card (32 Mb)

9
What will CCTSystem be Able to Do?

• Autonomous Search and Detection of New Host
  Bluetooth Modules
• Automatic Initiation of a Data Transfer between
  Host and Base Station.
• GUI Interface for Control and Monitoring
  Functions
• Complete Event Log Generation and Storage
• Implement a Generic Transfer Mechanism based on
  the FTP model
• Allows Integration with various External
  Components (Databases, Web components, Email, etc)

10
CCTSystem Specifications

• The application created should not detect every
  single Bluetooth device
• The application created detects the Bluetooth
  device that is either on the mobile or base
  station
• The created application will automatically
  transfer data files
• The application stores the data files on to the
  smart card
• The application displays the log, when the
  transfer is complete
• The file transfer can also be completed using the
  cable wire instead of wireless, during the time
  when the container is at a full stop (Not
  Implemented in Prototype)

11
System Operation Base Mode

• Base Mode is utilized when the System is
  required to perform as the central base station
• Operations requires continual detection of remote
  Hosts.
• Base Position Serves as a control and monitor
  point for operation
• System is fully automated and require no
  intervention on the part of the user. Controls
  are provided for manual intervention if required.
• External Connectivity to Networks for External
  Components

12
System Operation Base Mode

• Base Station Configuration In implementing the
  final design prototype for the base station, the
  following configuration was implemented.
• Windows Based PC running Windows XP
• Network Interface to WAN
• User I/O components Keyboard, Mouse, Monitor
• 1 USB Widcomm point-to-multipoint Bluetooth
  Modules for Windows PC
• CCTSystem Version 1.0 Installed running in Base
  Mode

13
System Operation Base Mode
14
System Operation Base Mode
CCTSystem Running in Base Mode
15
System Operation Host Mode

• Host Mode is utilized when the System is
  required to perform as the remote station. (For
  example on a Cargo Container
• Operations requires continual detection of remote
  Bases.
• Host Position Requires no user intervention and
  operates completely autonomously.
• A GUI was implemented for the Host for purposes
  of testing and development. Actual applications
  need no GUI because no control and monitoring
  functions occur at this station.
• External Connectivity to Smart Card
• Data is read and written to the smart card when
  remote stations are detected

16
System Operation Host Mode

• Host Configuration In implementing the final
  design prototype for the host, the following
  configuration was implemented.
• Windows Based PC running Windows XP
• Network Interface to WAN
• User I/O components Keyboard, Mouse, Monitor
• 1 USB Widcomm point-to-multipoint Bluetooth
  Modules for Windows PC
• 1 USB Smart Media Reader/Writer
• Smart Media Card
• CCTSystem Version 1.0 Installed running in Host
  Mode

17
System Operation Host Mode
18
System Operation Host Mode
CCTSystem Running in Base Mode
19
CCTSystem Additional Items

• Generic Transfer Medium
• Allows for the transfer of any type data.
• No proprietary storage requirement
• Allows for more User-Defined implementations
• Allows for easier integration with external
  components
• Only limiting factor is Size
• As Data size increases, the required time to
  initiate a transfer increase correspondingly.
• What About Interference from Other Non-CCTSystem
  Bluetooth Devices
• Built into CCTSystem is a Specific Service
  Identifier. Those modules which do not have that
  service running appear on the device list,
  however they do not initiate transfers of data.

20
CCTSystem Additional Items

• The Possibility of Re-Reading Hosts
• This Potential Problem Exists when the physical
  location of storage containers is within range of
  the Base Station.
• Ordinarily Re-Reading Containers will not have a
  detrimental affect on the system, however could
  tie up resources at the base station.
• Two Part Solution
• First Separate the Base Station and Container
  Storage area, so that respective Bluetooth
  Modules range do not overlap.
• Second, Introduce a Suspend Directive to the
  host, once a successful transfer has occurred.
• Doing this disables the host for a given period
  of time.
• However it introduces possible Security Holes in
  which Container Tracking does not become uniform

21
Testing and Simulation
CCTSystem Lab Setup
22
Testing and Simulation (I)

• Testing Procedures
• Significant Testing of Both Software and Hardware
  Components in a Lab Environment
• Field Testing, while in motion, was prohibitive
  given time considerations and portability issues.
• Multi-Faceted Testing Approach
• Examined Operating Environment Issues
• Hardware and Software Reliability
• Extensive Debugging of CCTSystem to eliminate
  software glitches and problematic issues.
• Repeated Multiple Simulations of CCTSystem
  Performance given various configuration and
  operating conditions
• Essentially a Trial and Error Based approach to
  examine what factors caused the system not to
  function according the specification and remedy
  it.
• Performance Criteria Measured
• Connection Speed and Data Bandwidth analyzed and
  Measured

23
Testing and Simulation (II)

• Successful System Operation
• The application created should not detect every
  single Bluetooth device
• Our analysis showed that base system detects all
  Bluetooth based devices within a given range,
  regardless of whether they are involved with
  CCTSystem. However, devices, which do not have
  the specific custom Bluetooth services enabled
  under CCTSystem, were simply ignored by the base
  or the host in terms of transferring data.
• The application created detects the Bluetooth
  device that is either on the mobile or base
  station
• Testing indicated that 100 percent of the time
  CCTSystem was able to identify mobile hosts and /
  or base stations.
• The created application will automatically
  transfer data files
• Testing indicated that this occurred in the vast
  majority of trials. Failure occurred under
  instances in which human error was involved, or
  there were incompatibilities associated with
  operating systems, particularly Windows NT /
  2000. This is described further in the failures
  discussion.

24
Testing and Simulation (III)

• Successful System Operation
• The application stores the data files on to the
  smart card
• Our analysis showed that when data was
  transferred successfully it, transfer or updating
  of the contents on the smart card occurred.
• The application displays the log, when the
  transfer is complete
• Testing results yielded that under all
  circumstances, success or failure, a log was
  generated of the event. This log included vital
  information about the data exchange between host
  and base.
• The file transfer can also be completed using the
  cable wire instead of wireless, during the time
  when the container is at a full stop
• This feature was not tested due to time
  constraints, as well as the recognition of this
  features relative unimportance in developing a
  wireless data exchange medium.

25
Testing and Simulation (IV)

• Unsuccessful System Operation
• Human Error
• Our analysis showed that a majority of failures
  occurred because of human error. Factors such as
  letting a test machine enter power save mode were
  examples of this
• System Incompatibility
• Testing results yielded that when CCTSystem ran
  under Windows NT/2000 certain security features
  which limited direct access to hardware prevented
  successful operation of the system
• Solution was to not deploy on system utilizing
  Windows NT/XP
• Hardware and Development Kit Problems
• Development Kits and hardware utilized was
  Pre-Release equipment.
• Many Bugs had not yet been worked out of the
  hardware drivers and corresponding development
  APIs

26
Testing and Simulation (V)

• It is important to note that because the
  Bluetooth module components implemented in the
  design were Class II as opposed to Class I
• Class I module range is almost double that of
  Class II module range
• Minor recalculations in terms of the specific
  timings of transfers needed to occur.
• Based on this recalculation, our tests indicated
  that transfers operations (from detection to
  transfer completion) occurred in the span of
  12-17 seconds

27
Scheduling and Task Assignment (Spring 2002)
28
Scheduling and Task Assignment (Spring 2002)

• Scheduling followed very closely to what was
  proposed at the end of the design stage.
• Alterations to this schedule came with developing
  finalizing CCTSystem
• Minor Technical glitches pushed back completion
  dates and as a result limited the Testing
  Schedule

29
Scheduling and Task Assignment (Spring 2002)
30
Budgetary Issues (I)
31
Budgetary Issues (II)

• The development of this project was budgeted
  2000.
• Our expenses for materials, parts, and
  administrative costs totaled approximately
  1339.44.
• Our initial estimations at the design phase of
  project cost ranged from 1400 to 1600.
• The primary difference in overall costs was due
  to our ability to procure academic discounts on
  the vast majority of items purchased.
• Savings on average of 10 per item purchased
  significantly reduced the overall capital
  required to bring this project to completion.

32
Conclusions (I)

• Created a foundation for the development of
  future wireless Based Tracking and Tracing System
• Created functional prototype system which is
  capable of exchanging data and information under
  realistic conditions
• Implemented Design using Bluetooth based wireless
  technologies
• CCTSystem meets Specifications in requiring an
  automated and autonomous system for transferring
  data wirelessly
• Implement a dual-mode system (Base and Host) to
  provide connectivity between stations.
• Implemented logging and accountability features
• Implemented Flexible Generic Transfer Medium to
  facilitate custom user-defined external
  components
• Thoroughly Tested and Simulated CCTSystem for
  Stability and Reliability
• Completed Prototype On Time and Under Budget

33
Conclusions (II)

• CCTSystem is Just The Beginning
• Infinite Possibilities in Building upon this
  Foundation
• Integrating CCTSystem into external components.
• Take the Process and apply it to an application
• Linking the System to Databases, and Web
  Components
• Refining The Host
• Compact the Host into a rugged and
  cost-effective module to be mounted within actual
  containers
• Design issues include power supplies, antennas,
  and reliability
• High-Speed Systems
• Initially proposed, but deemed to complex and
  time consuming given tasks at hand.
• Design issues include FCC Regulation, and
  realistic simulation

34
QUESTIONS?

• Pictures courtesy Interpool Inc.
  http//www.interpool.com
• http//koala.ece.stevens-tech.edu/sd2k01/grp6

CCTS Project Andrew D. Nikow Project
Leader Michal Kosinski Parminder Singh Michael
Stabile