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  Service Layer  Database Layer  Data Exchange Layer  Wireless Network Layer Upper Layers  (accessible by application designers) Lower Layers  (transparent to application designers) Hybrid Communication Architectures 

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 "Map Mapping" services (snapshot query mode) 2. Generate the spatial-temporal query for the average speed one mile ahead by using "Query Wizard" service 3. Try to process the query in the local database by using "Query Processing" service (if get the result, then exit) 4. Get the nearby infrastructure access availability by using "Get Infrastructure Availability" service 5. If the infrastructure is available, send the query to the central server for processing by using "Infrastructure Dissemination" service 6. If the infrastructure is not available, disseminate the query to the location one mile ahead on the same road by using "Broadcast Dissemination" service 7. 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  SQL ST : 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(A 1 : D 1, …, A n : D n ) where A i are the attributes and the D i 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

SQL ST  A point-based time model and a polygon-oriented spatial object model.  SQL ST 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.

SQL ST  Spatial Predicates

SQL ST  Spatial Operators

Query Examples (STQL)  Flight and weather conditions:  flights ( id : string, Route : Point )  weather ( kind : string, Extent : Region )

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 (SQL ST )  Forest Fire Control Management

Query Examples (SQL ST )  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