Transcript A Generic Platform for ITA Related Applications

A Generic Platform for
ITA Related Applications
Yan Luo, Ouri Wolfson, Bo Xu
02/11/2008
Outline
 Motivations and Objects
 Introductions and Related Projects
 Hybrid and Layered Architectures
 Data Models and Query Languages
 Case Studies and Future Plans
Motivations
 Why do we need this generic platform?
 Systematically develop ITA applications
 Easily apply IGERT research results
 Quickly compare different algorithms
 The purpose of this presentation:
 Present our current research and existing results
 RFC: request for comments (and suggestions)
 Complete the detailed design after the presentation
Objects
 Design and develop a generic platform for a
variety of ITA related applications
 The platform provides a set of services for
application designers with various interfaces
 The fundamental low-level primitives are
transparent to application designers.
 To design and implement these services, data
models, query languages, and related
algorithms will be defined and proposed.
Introduction
 ITA and Related Applications





Transportation safety and efficiency
Mobile E-commerce
Airport applications
Social networks
Emergency response
 What is a Platform?
 Think about the platform like an OS (Operating System)?
 But actually upon the traditional OS, e.g., Windows CE and Linux
 Characteristics of the running environment for ITA:




Variety of communication channels with different trans ranges
Variety of objects: high mobility, low mobility, and even static
Dynamic unstructured network topology for P2P communications
Bandwidth, memory, even power constraints for different cases
Some Example Applications
• User 1 is requesting a
ride-share via local
wireless peer-to-peer
communication;
• User 2 is requesting a
best route based on
current conditions;
• User 3 is notified of an
ice patch ahead by the
anti-lock brake sensor in
another vehicle.
• User 4 receives a
message from the
parking meter, parks,
and takes the train.
Related Projects

CarTalk2000
 Developed a cooperative driver assistance system based on inter-vehicle communication and
mobile peer-to-peer databases via self-organizing VANET.

Grassroots and TrafficView
 Developed an environment in which each vehicle contributes a small piece of traffic information
to the network via the P2P paradigm, and each vehicle aggregates pieces of the information into
a useful picture of the local traffic information.

FleetNet
 Developed a wireless multi-hop ad hoc network for inter-vehicle communication to improve
driver's and passenger's safety and comfort.
 Proposed A data dissemination method called "contention-based forwarding" (CBF).

VII (Vehicle Infrastructure Integration)
 Deploy advanced vehicle-to-vehicle (mobile peer-to-peer paradigm) and vehicle-to-infrastructure
communications that could keep vehicles from leaving the road and enhance their safe
movement through intersections.

TinyDB
 Focused on data-models and languages for sensors, but considers query processing in an
environment of static peers.

CarTel
 CarTel is a distributed, mobile sensor network and telemetric system. Applications built on top of
this system can collect, process, deliver, analyze, and visualize data from sensors located on
mobile units such as automobiles.
Different Views of Architecture
 Hybrid Communication Architectures
 Client-Server
 Hierarchical Servers (Region Server, Global Server)
 P2P (Peer-to-Peer): is an extension and supplement to Client-Server
 Wired and Wireless
 Static and Mobile
 Layered Architecture
---- Semantic View: for easily understanding and application design





Network layer
Data exchange layer
Database layer
Service layer
Application layer
 Component-based Architecture
---- Software Engineering View: for implementation, testing, and
integration
 Modules: e.g., Communication, Localization, Database modules
Application Layer
Upper Layers 
(accessible by
application
designers)
--------------------Lower Layers
Service Layer
Database Layer
(transparent to
application
designers)
Data Exchange
Layer
Hybrid
Communication
Architectures 
Wireless Network
Layer
Service Abstraction and Interface
 We will abstract a set of services in the service layer and
define various interfaces for application designers to easily
access these services to build different ITA applications.
 Define the detailed interface for existing services.
 For example, "Get Vehicle Diagnostic Info", we define:
 Input: mode (snapshot, continuous, trigger), sensors, conditions
 Output: values of sensors, alert (trigger mode)
 To get an alert when ABS engaged and outside temp is
below 32 degrees, we can call the service with:
 Input: trigger, ABS_Sensor, Out_Temp_Sensor,
ABS_Sensor.status=Engaged & Out_Temp_Sensor.value < 32
 Output: an alert when the conditions are satisfied
Other Services’ Interfaces
 Get GPS Data
 Input: mode (snapshot or continuous), frequency (if continuous)
 Output: timestamp, latitude, longitude, speed, moving direction
 Map Mapping
 Input: latitude, longitude, moving direction
 Output: the most possible point on a road segment on a map
 Navigation
 Input: origin, destination, mode (shortest, fastest, avoid HW, …)
 Output: a route from origin to destination based on mode
 A more complicated navigation is traffic condition based navigation
Other Services’ Interfaces
 Get Vehicle Density
 Input: expected location, direction, time period,
 Output: vehicle density, actual location, timestamp
 Get Traffic Information
 Input: a road segment, direction, time period
 Output: vehicle density, average travel time, other info
 Get Infrastructure Availability
 Input: mode (snapshot query or trigger)
 Output: infrastructure type, availability, alert (trigger mode)
 Broadcast Dissemination
 Input: mode (once, repeat), report, location, direction, spatial limit,
expiring time
 Output: broadcast the report in the direction from the location within
the spatial limit and before the expiring time
An Application Example Scenario

Broadcast ABS alert to behind cars within 200 yards:
1. Get ABS alert by using "Get Vehicle Diagnostic Info" service (trigger
mode)
2. When receiving ABS alert, get current location and moving direction
by using "Get GPS Data" service (snapshot query mode) and "Map
Mapping" service
3. Generate the spatial-temporal ABS alert report (this service could
be in the database layer since the designer may want to store the
report into the database for future and other access)
4. Broadcast the report to behind cars on the same road within 200
yards by using "Broadcast Dissemination" service in the data
exchange layer
Another Application Example Scenario

What is the average speed one mile ahead?
1. Get current location and direction by using "Get GPS Data" and
2.
3.
4.
5.
6.
7.
"Map Mapping" services (snapshot query mode)
Generate the spatial-temporal query for the average speed one mile
ahead by using "Query Wizard" service
Try to process the query in the local database by using "Query
Processing" service (if get the result, then exit)
Get the nearby infrastructure access availability by using "Get
Infrastructure Availability" service
If the infrastructure is available, send the query to the central server
for processing by using "Infrastructure Dissemination" service
If the infrastructure is not available, disseminate the query to the
location one mile ahead on the same road by using "Broadcast
Dissemination" service
When the result is received, pass the result to the application layer
and display it to the user by the "Graphic User Interface" service
Data Dissemination in Data Exchange Layer
Database Layer
• Mobile P2P
Communication is
more effective and
efficient when
Infrastructures not
available
• An Example of Mobile
P2P Databases:
• Local Distributed
Databases
• Store-and-Forward
• Transitive Multi-Hop
Transmissions
Database Layer
 Data Models
 Temporal Data Model
 Spatial Data Model
 Spatial-Temporal Data Model
 Query Languages
 STQL: Spatial Temporal Query Language
 SQLST: Spatial Temporal Extensions to SQL
 Other data models and query languages used in other
projects (CarTel: ICEDB)
 Although we have defined our own data models and query
languages in the previous paper, it is better to use a
standard existing one and augment it when necessary
Temporal Data Model
 Discrete time model
 Integers, reality is a sequence of snapshots
 Continuous time model
 Reals, use formula or equation to represent movings
 Temporal predicates (operators?)







Overlap
Precede
Contain
Equal
Meet
Intersect
Duration
Spatial Data Model
 Spatial objects:
 Point: vehicle, person, or other no-area objects
 Line: road, route, or path
 Region: park, water, or other has-area objects
 Spatial predicates:
 equal, disjoint, overlap, meet, contain, adjacent,
common_border
 Spatial operators:
 intersect, area, perimeter, distance
STQL
 A relation scheme R(A1 : D1, … , An : Dn) where Ai are the
attributes and the Di are their respective value domains.
The domains can be standard types like integers, reals,
booleans, strings, or more complex spatial data types like
points, lines, regions, and graphs.
 A continuous time model, that is, time = IR.
 A temporal function of type τ(α) = time → α. For example,
a point that changes its location over time is an element of
type τ(point) and is called a moving point. τ(region) is a
region that can move and/or grow/shrink, called a evolving
region.
 Denote non-temporal types, entities, functions, and
predicates by lower case letters; while their temporal
counterparts start with capital letters.
STQL
 Temporal Lifting: non-temporal operation is lifted to work on temporal
objects
 Distance = ↑distance : τ(point) × τ(region) → τ(real)
 Temporal lifting is also applicable to spatial predicates:
 inside : point × region → bool
 Inside = ↑inside : Point × Region → Bool
 A Spatial-Temporal Predicate is a function of type τ(α) × τ(β) → IB
for α, β ∈ {point, region}
 Instant Predicates: equal, meet, covers, coveredBy.
 Period Predicates: disjoint, overlap, inside, contains. Spatial-temporal
predicates composition, written as "△". For examples:
 Disjoint △ Meet
 Disjoint △ meet △ Inside
SQLST
 A point-based time model and a polygon-oriented spatial
object model.
 SQLST views reality as a sequence of snapshots of
objects that are moving and or changing in shape.
 Temporal operators: overlap, precede, contain, equal,
meet, intersect.
 Spatial objects: point, line, region (which is represented
as a set of directed triangles).
 Spatial predicates: equal, disjoint, overlap, meet, contain,
adjacent, common_border.
 Spatial operators: intersect, area, perimeter, distance.
SQLST
 Spatial Predicates
SQLST
 Spatial Operators
Query Examples (STQL)
 Flight and weather conditions:
 flights ( id : string, Route : Point )
 weather ( kind : string, Extent : Region )
Query Examples (STQL)
Query Examples (STQL)
 Forest fire control management:
 forest ( forestname : string, Territory : Region )
 forest_fire ( firename : string, Extent : Region )
 fire_fighter ( fightername : string, Location : Point )
Query Examples (STQL)
Query Examples (SQLST)
 Forest Fire Control Management
Query Examples (SQLST)
 Forest Fire Control Management
Case Studies and Future Plans
 Apply SQLST and STQL to write our own query examples
example (how to use their elements?)
 Vehicle Status and Movement Monitoring
 Traffic Condition Monitoring and Dynamic Navigation
 Public Transportation Monitoring and Scheduling
 Parking Lot Status Monitoring, Ride Sharing Management
 File (Photos/Videos/Coupons) Sharing and Exchange
Questions and Discussions
Thank you