Skip Headers
Oracle® Sensor Edge Server Guide
10g Release 3 (10.1.3)
B25142-01
  Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

2 Introducing Oracle Sensor Edge Server

Oracle Sensor Edge Server is a middle tier component that integrates sensors and other types of command or response indication equipment with applications. Oracle Sensor Edge Server enables enterprises to incorporate information received from sensor devices into their I.T. infrastructure and business applications.

Oracle Sensor Edge Server receives event data from sensor devices and then normalizes this data by putting it in a common data format and filtering out excess information. The event data, which is now a normalized event message, is then sent to database applications.

This chapter provides an overview of Oracle Sensor Edge Server. It contains the following sections:

What's New in Release 10.1.3

This section summarizes the new and enhanced features for Oracle Sensor Edge Server for Release 10.1.3.

Release 10.1.3 includes the following new features and enhancements:

Oracle Sensor Edge Server Console

You perform Oracle Sensor Edge Server administration, monitoring, and configuration using a new Sensor Edge Server Console, as shown in Figure 2-1. The tools provided by the console help to decrease deployment and maintenance costs. Using the console, you can:

  • configure general server settings

  • monitor server event statistics

  • view and manage extensions such as dispatchers, filters, and drivers

  • manage groups (logical collections of devices)

  • configure new devices

  • change server instance parameters

    Figure 2-1 Oracle Sensor Edge Server Console

    Oracle Sensor Edge Server console
    Description of "Figure 2-1 Oracle Sensor Edge Server Console"

Some of the common tasks you can perform include:

  • renaming a server instance

  • changing the site name of the server

  • changing instance parameters such as internal queue type, log level, and shutdown timeout

  • configuring or changing the dispatcher

  • performing group management such as creating a new group, renaming or deleting a group, adding a filter to a group, configuring a new group filter, and adding a device to a group

  • configuring a new device

  • adding or configuring a filter for a device

Oracle Sensor Edge Mobile

Designed for mobile workers in warehouses and on factory floors, Oracle Sensor Edge Mobile runs on handheld RFID readers that run on Pocket PC 2003 and later platforms. Sensor Edge Mobile ships with Intermec and Symbol device support, and can be controlled through an ActiveX component. Sensor Edge Mobile interfaces with different types of sensors and devices, and feeds observation events to applications.

Enhanced Management Through Oracle Application Server Control

In this release, Java Management Extensions (JMX) interface has been integrated into the Application Server management console to increase accessibility and ease of management. The administrative tasks that are integrated into Application Server include startup, shutdown, process management, and recovery. These enhancements will help to decrease deployment and maintenance costs.

Improved Performance

Scalability and latency are crucial components for the real time performance required by many sensor-enabled applications. For this release, Oracle Sensor Edge Server provides improvements in scalability and latency through optimizations in the Database layer and the application server layer.

Enhanced Sensor Data Repository

In this release, the Sensor Data Repository (SDR) is specifically designed to store EPC and sensor data. The database schema stores status and diagnostic information from Sensor Edge Server, and serves as the single repository for sensor data.

The SDR is a database schema where the sensor events (RFID, temperature, location, etc.) obtained from Oracle Sensor Edge Server are archived. The events are normalized on their way into the SDR to facilitate business intelligence, such as reporting. The SDR can be enabled and configured so that Oracle Sensor Edge server can use it for storing event data and querying the event archive. Typically, multiple Sensor Edge Servers can share one SDR.

The SDR provides a set of database tables, views, and PL/SQL packages to facilitate the storage and retrieval of sensor events data.

Sensor Data Streams

Oracle Sensor Edge Server relies on plug-ins, called dispatchers, to communicate with applications and event distribution systems. The StreamsDispatcher is a plug-in that sends and receives events using Oracle Streams technology.

EPC Compliance Integration

This release includes EPC compliance features that were previously provided separately. This functionality allows customers to easily comply with the minimum EPC requirements and also provides a fully scalable infrastructure that can be applied to an entire enterprise.

Transport Layer

The transport layer simplifies development and maintenance for Oracle Sensor Edge Server applications. The transport layer provides an extensible development platform that simplifies device implementation and upgrading. The transport layer also resolves platform dependencies so that your Device Drivers can work with multiple operating systems.

Enhanced Security

By using Java Naming and Directory Interface (JNDI), Oracle Sensor Edge Server provides enhanced security. JNDI allows applications to work in conjunction with directory-specific security systems.

Deprecation of the Device Controller

The Device Controller is no longer necessary and has been removed from Oracle Sensor Edge Server for this release. The following devices that previously used the Device Controller can now operate without it:

  • Patlite

  • Intermec

Oracle Sensor Edge Server Overview

Oracle Sensor Edge Server manages and monitors the performance of the sensors that are integrated with your Information Infrastructure. Sensor Edge Server collects sensor information, filters it, and performs local sensor event processing. Oracle Sensor Edge Server then securely and reliably dispatches event data back to the central applications and databases.

For example, RFID readers use small transponders with embedded Electronic Serial Numbers (ESN) or memory, which transmit identifiers across one or more frequencies. A transponder can carry other information in its memory, and can be read or written to at a distance, without the need for line-of-sight contact. Oracle Sensor Edge Server interfaces with all the readers and sends normalized data back to the application server.

Oracle Sensor Edge Server provides the following features:

Sensor Data Collection

Oracle Sensor Edge Server provides an extensible driver architecture that integrates with any sensor source such as Radio Frequency Identification (RFID) readers, printers, temperature, motion, pressure, or location, and any response devices such as light stacks, message boards, and sound systems. You can also implement custom components to plug in to the Sensor Edge Server architecture. You can implement the standard driver interface to Sensor Edge Server, or expose custom functionality of the sensor hardware through the Sensor Edge Server configuration interface.

Sensor Data Filtering

Data streaming in from sensors connected to Sensor Edge Server arrives in a wide range of formats, and includes unnecessary or redundant information. Before the sensor data is passed on to enterprise applications, Sensor Edge Server performs data cleansing by filtering the data from individual sensors and groups of sensors. This process normalizes the sensor data into a consistent format. Groups of sensors can be treated as single logical entities for filtering purposes.

Sensor Data Dispatching

Dispatchers are plug-ins that enable two-way communication with applications. The main output of Oracle Sensor Edge Server is filtered data events. These data events are provided already minimized and normalized. They can be delivered in one of the out-of-the-box supported methods:

  • Streams/AQ: Dispatching through Oracle Streams provides the most robust and flexible method of forwarding data. This is the only dispatching method that fully supports rule-based processes and agents-based technologies.

  • Java Messaging Services (JMS): JMS is a standard messaging API that J2EE components use to communicate. The Oracle Sensor Edge Server provides a JMS Dispatcher to enable users to relay events to JMS topics.

  • Web Services

  • HTTP Post

  • Other forwarding methods can be supported by writing a Custom Event Dispatcher.

  • EPC PML (Phyiscal Markup Language)

  • Application Level Events (ALE)

Sensor Data Archive and Rules

Once the data has been filtered and dispatched, Oracle Sensor Edge Server uses the Oracle 10g database to provide sensor data archiving. You can use sensor data schemas tailored for storing sensor data captured through Sensor Edge Server. This archive provides uniform storage for sensor data for the entire enterprise, and provides a repository for data analysis.

Sensor Server and Device Management

To reduce maintenance costs for sensor infrastructure, Oracle Sensor Edge Server provides device management and monitoring from a single centralized location.

Sensor Edge Mobile

Oracle Sensor Edge Mobile is a Pocket PC application that runs on handheld devices such as RFID and barcode readers. Sensor Edge Mobile interfaces with different types of sensors and devices, and feeds observation events to applications. For more information see "Oracle Sensor Edge Mobile Architecture".

SES Console

You perform Oracle Sensor Edge Server administration, configuration, and monitoring using the SES console. For more information, see "Oracle Sensor Edge Server Console".

Oracle Sensor Edge Server Architecture

This section describes the highlights of Oracle Sensor Edge Server architecture. Figure 2-2 provides an overview of Oracle Sensor Edge Server architecture.

Figure 2-2 Oracle Sensor Edge Server Architecture

Oracle Sensor Edge Server architecture
Description of "Figure 2-2 Oracle Sensor Edge Server Architecture"

Device Drivers

Device Drivers communicate with sensors, and normalize incoming data into standard format. Device Drivers can be customized or built to suit your needs.

Device Groups

Device Groups are used by administrators to group devices logically, and manage them more efficiently. An Oracle Sensor Edge Server can have one or many Device Groups instantiated. Each Device Group is responsible for the Device Drivers that it manages.

Local Processing

Local processing (filters and rules) removes unwanted or low-level events. Filters and rules can be used to sort incoming data. They can be applied to individual Devices, or to Device Groups.

Event Processor

Event Processor is the central processing engine for event delivery. It loads the rest of the components, which include the Driver Manager and (on start up) the Event Dispatcher. Internally, it reads the configuration to find out which Event Dispatcher to load. The process is started on startup.

Driver Manager

Driver Manager loads and manages the life cycle of the Device Groups and Device Drivers. There is only one instance of a Driver Manager for each Oracle Sensor Edge Server.Driver Manager provides an accessible context to Device Drivers so they can retrieve configuration information. It then loads the Device Groups, and binds them to the Device Drivers. The Driver Manager does not hold any thread internally, but an instance of it is held by the Event Processor instance as long as the server is up and running.

There is one Event Processor and one Driver Manager in each Oracle Sensor Edge Server. Each Driver Manager loads a number of Device Groups. In turn, each Device Group can have any number of Device Drivers. However, only one Device Driver can belong to one Device Group.

Oracle Sensor Edge Mobile Architecture

Oracle Sensor Edge Mobile is a platform that manages mobile sensor data collection on the device and communicates with the application running on the device or remotely through the device's browser. The communication is bi-directional, with events passing from devices, through the platform, to the application, and instructions passing from the application, through the platform, to the hardware Device Driver.

Figure 2-3 provides an architectural overview of Oracle Sensor Edge Mobile. Sensor Edge Mobile runs entirely on a handheld device, and communicates with other applications or services external to it, or operates entirely offline, collecting data that can be synchronized with an application at a later time.

Figure 2-3 Overview of Sensor Edge Mobile Architecture

Overview of Sensor Edge Mobile architecture
Description of "Figure 2-3 Overview of Sensor Edge Mobile Architecture"

Taking a closer look at the Oracle Sensor Edge Mobile platform reveals that observations collected by Device Drivers are put in an internal queue until the Dispatcher can process them. Figure 2-4 illustrates Sensor Edge Mobile components.

Figure 2-4 Sensor Edge Mobile Components

Sensor Edge Mobile components
Description of "Figure 2-4 Sensor Edge Mobile Components"

The Dispatcher communicates with the application using a local ActiveX control, by sending characters to the keyboard buffer, or through almost any other communication method. Only one Dispatcher can be active at a time, but that Dispatcher may be communicating with multiple client devices and corresponding drivers.

The Sensor Edge Mobile core components include the Driver Manager, Event Manager, and the Configuration Manager. Once these components are started, the main service calls on the Configuration Manager to read the configuration file. The service then starts the Dispatcher that has been configured, passing in any configuration parameters that have been specified.

The Driver Manager is responsible for loading and managing the lifecycle of the drivers. The Driver Manager calls on the Configuration Manager to determine which drivers need to be loaded, and what parameters to make available to them on instantiation, and then loads and initializes them.

There is only one Event Manager and one Driver Manager in Oracle Sensor Edge Mobile. The Driver Manager may load a number of drivers.

Device Driver Support

Oracle Sensor Edge Mobile supports Symbol 9000-G devices for the following operations:

  • RFID Read

  • RFID Write

  • RFID Kill

  • Barcode Read

Oracle Sensor Edge Mobile supports Intermec IP3 with Color 700 PocketPC attached for the following operations:

  • RFID Read

  • Barcode Read

Administering Oracle Sensor Edge Mobile

Oracle Sensor Edge Mobile can be administered through the Oracle Sensor Edge Server Web interface. You can perform the following administrative tasks:

  • monitor overall service status

  • monitor administrative logs

  • review driver statistics

  • shutdown the service

Sample Code and Demo Applications

Oracle Sensor Edge Mobile includes sample HTML and JavaScript code that shows examples of the following:

  • reading and writing RFID tags

  • reading Barcodes

  • system status page

  • service administration page

The sample code illustrates how to use the APIs and also demonstrates how Oracle Sensor Edge Mobile can be run immediately after installation and configuration.

Deployment Considerations

The Oracle Sensor Services architecture addresses the challenges faced in industrial supply chain environments as well as in specialized multi-sensor environments for commercial and government applications. To meet these diverse needs, Oracle offers dual Edge deployment configurations, each with it's own unique footprint and the built-in flexibility to support both centralized and federated site deployment scenarios.

The following considerations can help you determine which configuration to choose for your deployment or pilot.

Review Network Characteristics

In planning a deployment, first identify network bandwidth within the facility as well as intranet connectivity to other distribution centers and the Data Center. Typical considerations include the following:

  • In-warehouse connectivity: typically either provided by direct Ethernet or Wireless 802.xx. Connectivity outages are to be expected.

  • Warehouse to Warehouse or Data Center connectivity: In most cases, this connection is no more than a single ISDN line.

Identify Data Center Environment

Typical data center considerations include the following:

  • Environment: In-warehouse hardware is typically ruggedized (bar code readers, system controllers, etc.) and, in some cases, environmental control is limited by operational requirements (for example, open dock doors).

  • Support staff: Is IT support staff available on site or remotely, or not available?

Review Reader and Sensor Locations

For example, in locating RFID devices, there is typically a trade-off between customer constraints (pick and pack locations, conveyor lines, etc.) and where the RF survey indicates that the RFID hardware would work most efficiently and with minimal interference.

You should also identify the connectivity requirements for the reader and sensor devices (for example, Serial, Wireless, direct Ethernet, etc.).

Choose Edge Server Locations

Once the previous items are identified, design and document the location of Oracle Sensor Edge Servers for each data center. The number and location of Edge servers is typically determined by the following:

  • The number of devices in each location and their interface requirements.

  • Access to power and network connectivity for the Edge server.

  • Environmental considerations (for example, exposure to weather and industrial equipment).

Oracle Sensor Edge Server and Sensor Data Repository Considerations

If the warehouse or distribution center has a server room and support staff, consider making the Sensor Data Repository (SDR) infrastructure available locally. Having the SDR infrastructure available locally can help minimize response times if complex business decisions need to be made locally and acted upon in real time. Oracle Sensor Edge Server offers a small footprint in warehouses or distribution centers while providing full data capture and filtering functionality. For more information on the SDR, see Chapter 4, "Using the Sensor Data Repository".

Having the SDR infrastructure available locally may also be necessary if network connectivity from the warehouse back to the central Data Center is minimal and latency would prevent actionable alerts or decisions on the scanned data.

Replication is typically implemented at the database level to synchronize transactions with other Data Centers or the central Data Center.

Most customers host their database and application servers at a central data center. This scenario uses minimal or no support staff at the warehouses or distribution centers. Only the Sensor Edge Server resides at the warehouse with connectivity back to the central data center for database and application server features.

Network bandwidth is critical in a centralized configuration and must be weighed against the processing to be performed on the filtered data. Data filtering, exceptions, and basic triggers can be performed locally. Complex rule-sets, product correlation, and cross-type queries can all be done against the remote instance and decisions returned to the local warehouse system.

If Control System integration is required, local processing filters or the SDR should be hosted locally to provide the features and performance required for automated warehouse operations.