Savant for AutoID system

1
Savant for Auto-ID system

• (2004. 2. 4)
• Kyung-Lang Park
• Yonsei Univ. Supercomputing Lab.

2
Reference

• Technology Guide
• Auto-ID Savant Specification 1.0
• Technical Manual The Savant
• Technical Report Savant Guide
• All documents are from Auto-ID center

3
Contents

• Definition of Savant
• Overview
• Auto-Id system architecture
• Components
• Savant Specification
• Savant overview
• Reader Interface
• Processing Module
• Standard Processing Module
• Application Interface
• An Implementation of Savant
• Savant networks
• EMS, TMS, REID
• Conclusion

4
Definition of Savant

• Savant is a software that sits between tag
  readers and enterprise applications
• Providing a variety of computational functions on
  behalf of applications
• Savant is a unique name used in Auto-ID Center

5
System architecture
6
Components

• Readers
• Devices responsible for detecting when tags enter
  their read range
• Savant
• A Software to process the streams of tag coming
  from one or more reader devices
• Filtering, aggregation, counting, reducing
• EPC information Service
• Makes EPC Network related data available in PML
  format to requesting services
• ONS (Object Name Service)
• Translate an EPC into one or more URLs where
  further information on the object may be found

7
Savant Overview

• Savant itself is a container for Process Module
• There are two Standard Processing Modules defined

8
Reader Interface

• Specifies interaction between savant and reader
  devices
• Reader interface must support for the Auto-ID
  Reader Protocol 1.0
• RI may support for other reader protocols
• RI must provide means for savant modules to
  invoke vendor-specific extension to Reader
  Protocols 1.0
• An implementation of Savant Must permit
  interaction with at least one Reader

9
Processing Modules

• Definition
• Savant contains one or more Processing Modules
• Savant may provide a means to create
  application-specific Processing Modules
• Access to Standard External Interfaces
• With Readers
• Receive and respond to command via the Control
  Channel
• Send notifications via the Notification Channel
• Interaction among PMs
• Interaction with Other External Service
• Savant May permit PMs to establish connection and
  interact with other external services
• Registration of Capabilities
• Pm Must register their capabilities with the
  autoid.core Processing Module
• Support for Standard Processing Modules
• Processing Module Naming Convention
• component.component.component
• Com.sample.inventory

10
Standard Processing Module

• autoid.core
• Provide a minimal set of Application Interface
  commands that allow application to learn identity
  information from a Savant
• autoid.readerproxy
• Provide a means for applications to issue
  commands directly to readers through the
  Application Interface

11
Application Interface

• Content Layer
• Specify the abstract content of messages
  exchanged between the Savant and Applications
• Message Layer
• Specify how abstract messages defined in the
  Content Layer are encoded, framed, transformed,
  and carried on a specific network transport
• Transport Layer
• This layer corresponds to the networking
  facilities

12
Application Interface

• Command structure
• An Enterprise application sends a request message
  to Savant on a previously established Control
  Channel
• The Savant dispatches the received command name
  and arguments to the named Processing Module
• The Processing Module performs some function
  according to the received command name and
  arguments
• The Savant sends the result back to the
  Enterprise Application in a response message
  carried on the same Control Channel

13
An Implementation of Savant

• The SavantTM
• Is a reference implementation of Savant
  Specification
• Has 3 main components
• RIED (Real-tiem in-memory event database)
• TMS (Task Management System)
• EMS (Event Management System)

14
Savant Network

• The Savants are organized in a hierarchical tree
  structure

15
Edge Savants

• Collects real-time EPC data

16
Internal Savants

• Collects EPC data from the Edge Savants that are
  its descendants

17
Event Management System

• EMS is implemented on ES to collect tag read
  events
• Allowing adapters to be written for various types
  of readers
• Collecting EPC data from readers in a standard
  format
• Allowing filters to be written to smooth or clean
  EPC data
• Allowing various loggers to be written
• Buffering events to enable loggers, filters and
  adapters to operate without blocking each other

18
Requirements for EMS

• Should be a high-performance system
• Should Support EPC readers that communicate with
  different Auto-ID Center protocols
• Should support event filters that has one in
  stream and one or more output event streams
• Smoothing, Coordination, forwarding
• Should support multiple event loggers
• Should launch its processing units in different
  threads and should be capable of buffering the
  event streams between these units
• Should be able to instantiate the processing
  units based on any configuration of these units
• Should also allow remote machines to register and
  deregister to events streams dynamically

19
Components for EMS

• Reader Interface
• Allows readers and adapters to communicate events
  detected by the Auto-ID readers

20
Components for EMS

• Reader Adapters
• Communicate with readers to capture EPC events
• Event loggers (Event consumers)
• Allow for varied processing of events
• Store the information in the database
• Store events in a memory data structure
• Broadcast the events to a remote servers

21
Components for EMS

• Event Queues (Event forwarders)
• Handles multiple reader event loggers with
  synchronous implementations

22
Components for EMS

• Event Filters
• Handle on incoming event stream and post the
  events to one or more output streams
• Smoothing, coordination or forwarding

23
Realtime In-memory Event Database

• REID is an in-memory database that can be used to
  store event information by Edge Savants
• The loggers can log events in a database.
• But, databases cannot handle more than a few
  hundred transactions a second
• RIED provides the same interface as a database,
  but offers much better performance

24
Requirements for RIED

• Should be a high-performance in-memory database
• Should be a multi-versioned database

25
System architecture

• Features
• Reducing DML complexity
• Reducing DDL Complexity
• Efficient support only for simple joins
• Simple query optimization
• No constraint maintenance and triggers

26
The Task Management System

• TMS manages tasks, just as the operating system
  managers processes
• Task examples
• Data gathering
• PML lookup
• Remote task scheduling
• Personnel Alerts
• Remote upload
• Special features
• An external interface to schedule tasks
• A platform-independent virtual machine
• A robust scheduler

27
Requirements for TMS

• Should be a platform-independent system requiring
  little memory processing power
• Should automatically upgrade the tasks it
  executes
• Should present a well-defined, interoperable
  external interface to schedule, monitor, and
  remove tasks
• Tasks should be written in a platform-independent
  language using a simple well defined SDK

28
System architecture

• Task manager
• Responsible for running and maintaining tasks
  running on a savant
• SOAP interface
• Class Server
• Expose the functionality and interface of the
  Task Manager as a SOAP service
• Database
• Provides a persistent store for the Task Manager

29
Conclusion

• A middleware must be required to construct any
  smart-ID system
• Filtering, Smoothing, Coordination
• Special functionalities
• Savant is a kind of middleware for the Auto-Id
  system
• Provide a general specification
• Introduce a reference implementation
• Including EMS, RIED, and TMS