Reader and Remote Configuration Software

Software Design Document

Digital Angel

Reader and Remote Configuration Software

Logic Product Development

411 Washington Ave N

Minneapolis, MN 55401

Digital Angel Reader Software Design.docRevision A

Table of Contents

1.Scope

1.1Identification

1.2System Overview

1.3System Architecture

2.Reader Software

2.1Overview

2.2Software Drivers

2.3Application Software

2.3.1Main Module

2.3.2Data Store

2.3.3XML Parser

2.3.4Command Library

2.3.5XML Generator

2.4Communication Interface

3.Handheld Remote Management Software

3.1Overview

3.2Application Software

3.2.1User Interface

3.2.2Data Store

3.2.3Command Library

3.2.4XML Parser

3.2.5XML Generator

3.2.6Configuration Manager

3.3Communication Interface

4.Messaging Protocol

4.1Overview

4.2Basic Commands

4.3Implemented Commands

4.4Informational XML Tags

List of Figures

Figure 1 - System Software Architecture

Figure 2 - Reader Software Architecture

Figure 3 - Reader Main Module block diagram

Figure 4 - Unique Mode Flowchart

Figure 5 - Handheld Software Architecture

Figure 6 - ID and Channel Tab

Figure 7 - Data Configuration Tab

Figure 8 - Remote Control layout

Logic Confidential and Proprietary1

Digital Angel Reader Software Design.docRevision A

1.Scope

1.1Identification

The purpose of this document is to identify the software system design proposed for Digital Angel’s Reader project.

This document will show how the software system requirements will be met and will identify a preliminary architectural description for the reader system. The communication protocol needed for communication between the reader and external management devices (handheld PC, desktop PC) will also be identified.

1.2System Overview

The Digital Angel Reader software system contains several major components: the Reader system software, the Reader application software, the communication interface, and the handheld application used to configure the Reader hardware.

The software system provides the following basic functions:

• Provide system level drivers to interface with the tag reader hardware
• Identify and record ID tags
• Provide unique ID tag functionality
• Provide the ability to temporarily buffer and forward sets of tag records
• Communicate the tags to an external system for recording
• Remotely poll and configure the reader hardware

1.3System Architecture

Figure 1 - System Software Architecture

As tags are read from the Receiver, they are formatted into an XML message and broadcast to the configured recipient. The message and the transport are generic so any device that can receive XML data can act as a data consumer for the tag data. In normal operation, this will be a networked PC.

Tags stored on the Reader hardware can be dumped on request to any networked device by sending a properly formatted dump command. This is the desired mechanism for gathering stored tags from the buffer on the Reader.

Any networked device that can produce XML tags formatted in the proper messaging protocol can act as a configuration device for the Reader. This platform will initially be a Windows CE handheld computer.

The handheld computer used for configuration will contain the same command handling logic as the Reader. This will allow the handheld computer to look like a Reader to any other device. This will allow a networked PC the ability to query the handheld for stored tag information.

2.Reader Software

2.1Overview

Figure 2 - Reader Software Architecture

2.2Software Drivers

The following software drivers shall be provided:

• Ethernet 10/100 BaseT
• Ethernet 802.11
• Telemetry Reader USB Device Driver
• Telemetry Driver USB Device Driver
• Serial
• Miscellaneous UI drivers (light, external buttons, etc.)

Communication of tags and configuration information will be abstracted such that the physical method of transportation is not important to the reader. Drivers will be provided for Ethernet, serial, 802.11b and USB that will allow a PC or handheld to communicate with the Reader. Configuration options will be provided to allow the user to select the physical method of transport to be used for tag transmission.

Initially, the reader will be configured to use the serial port as it’s primary communication port for tag data and configuration commands. This port can be used to send the correct configuration commands to set it to use one of the other available transports. These settings will be stored on the device and will be used for all future communications.

USB is not currently implemented for this release but will remain in the design for the next release.

2.3Application Software

2.3.1Main Module

The main module is the application program running on the Reader hardware. It is responsible for the main program flow, initialization, handling messages, and housekeeping routines.

The main module can receive messages from other sub-modules. It is responsible for listening for these messages and reacting accordingly. The message would be routed to the state machine potentially causing a change in program state depending on the message. Some possible messages that could be handled by the state machine:

• Tag received
• XML command received
• Configuration message received
• Dump stored tags
• Get status
• Add listener

The main module also contains routines for handling housekeeping tasks. These housekeeping tasks include:

• Reader watchdog
• Configuration management
• Self-test
• UI control

This main module is also responsible for the initialization and setup of the reader software.

Figure 3 - Reader Main Module Block Diagram

2.3.2Data Store

The data store manages two important reader functions: tag buffering and unique delay mode.

Since a tag may pass by a reader multiple times, the reader may need to filter out repetitive tag reads. There are three different unique tag modes:

• Fully Unique
• Unique within a certain time limit
• Off

Mode 1, Fully Unique mode will never read a tag that has already been read. This feature is implemented in the hardware. It is not currently implemented. The second mode is less strict, and only implements uniqueness during a certain window of time. This time window is user selectable.

Tag buffering is the functionality where the software keeps track of the last N tags read. This is contingent on the uniqueness mode used and redundant tags will not be stored if a unique mode is selected.

To implement this functionality, a database must be used to store the tag data. A database gives the ability to index and lookup tags in a very rapid fashion. This becomes important in unique mode since the reader needs to quickly determine if a tag has already been read during the unique time window.

The following functions must be provided by the data store to support the data handling needs:

• Store tag & timestamp
• Lookup tag & timestamp
• Return all tags
• Purge all tags

The wrapper around the database would provide the unique mode functionality. When a tag is stored, the following sequence of events will take place:

Figure 4 - Unique Mode Flowchart

2.3.3XML Parser

The XML parser is used to interpret XML commands that are received from a PC or handheld. After commands are parsed, the parser is responsible for calling the routine that corresponds to the received command.

The simplest method to achieve this functionality is to use the expat XML parser. Expat is an XML parser library that is freely available and forms the basis of the XML support included in many commercial products. It is a stream-oriented parser in which an application registers handlers for things the parser might find in an XML document (like start tags).

Expat is a non-validating parser. The term “non-validating” means that the parser does not make any assumptions as to the format of the tag structure. It does expect that the data is well-formed, referring to the requirement that the data has the correct start and end tags, quotes, and other XML syntactical details.

To include the parser into the Reader software, two tasks are necessary. The first is to write a C++ wrapper for the C-based library to make it easier to integrate. The second task is to implement the event handlers that are called when an XML tag is received. This will be itemized in section 2.3.4 (Command Library).

The XML parser would be implemented such that it could be cleanly reused in the handheld software and any potential PC software.

Expat typically expects complete documents to be transmitted and to parse it in one swipe. To emulate this, a variety of approaches can be employed. The first is to override the error generated when a tag is received before a start of document tag. The second, and recommended approach is to send a start of document tag at connection time. Additional tags look like continuations of the same document. If a link goes down and is restarted, the end-of-document will be assumed.

2.3.4Command Library

The command library is a collection of routines that implement the actions that are called when an XML tag is received by the parser. These routines are called on an event-driven basis. For example, some of the routines would include:

• Set – This would be called when a <SET> tag is received by the parser. It would be responsible for setting a configuration parameter in the reader.
• Get – The Get routine would be called by the parser when a <GET> tag is received. It would handle looking up a parameter and returning the result.
• Dump – When the <DUMP> tag is sent to the parser, the Dump function would cause all stored records in the buffer to be streamed back to the requester.
• Purge – The <PURGE> tag would cause the parser to call the Purge routine. The Purge routine would clear the tag buffer.
• Status – The <STATUS> tag would be handled by a Status routine. The Status routine would return status information in the status buffer.

The command library would be written such that it could be reused in the handheld and PC software.

2.3.5XML Generator

The XML Generator would be a library of routines that cause correctly formatted XML tags to be generated. These tags would form the messages sent from the Reader to external listeners.

This would be a reusable C++ module that will be reused in the handheld software and any potential PC software.

Some of the tags generated would include:

• <TAG> - This would be the tag data just read by the reader
• <VAL> - A requested parameter
• <STATUS> - Status information

Full documentation on the proposed messaging protocol is included in Section 4.

2.4Communication Interface

The communication interface would be abstracted so that the Reader software is isolated from the method of physical transport. This wrapper would allow messages to be carried in a neutral fashion over a variety of transport methods. A small plug-in to the communication interface would be created to implement the particulars of each medium. Initially, communications plug-ins would be created for the following physical transport methods:

• Ethernet
• Serial

3.Handheld Remote Management Software

3.1Overview

Since the handheld software is a superset of the Reader software, much of the code can be reused between the two platforms. Specifically, the following modules can be reused after they are adapted and recompiled for PocketPC:

• XML Parser
• Command Library
• XML Generator
• Communication Drivers
• Data Store

A major benefit of designing the handheld software to share much of the code with the Reader is that the handheld can act as a virtual Reader. This is beneficial when the physical link from a Reader to a backend PC is either down or non-existent.

In this scenario, the stored tag data from the Reader can be dumped to the handheld wirelessly and stored until a backend PC is available. At that time, the backend PC can connect wirelessly to the handheld as if it were a Reader and the stored data can be dumped to the backend PC.

A block diagram of the reader software is shown below in Figure 5.

Figure 5 - Handheld Software Architecture

3.2Application Software

3.2.1User Interface

The user interface will be implemented using MFC and the PocketPC 2002 SDK. This combination of tools will allow a user interface to be built that is consistent with accepted handheld interface standards for the PocketPC.

A tabbed folder property sheet metaphor will be utilized for screen layout. This layout is the most appropriate for tools that are used to configure a device. Obvious and appropriate GUI widgets will be used that will allow for easy operation and clear visibility in a variety of light and weather conditions.

In the screens shown below, two of the setup screens have been prototyped to show a proposed layout for the configuration screens. The actual user interface will take several screens to display all of the information and settings needed for the remote interface.

Figure 6 - ID and Channel Tab

In this diagram, the Reader and Channel selection tab is shown. The user would use this tab to select the specific reader to configure. Additional additions to this tab may include:

• User-editable text name for each reader
• Query button to retrieve information for a specific IP address

Figure 7 - Data Configuration Tab

Figure 7 shows the data configuration tab for the Reader. This tab allows the user to set up all of the data collection parameters. This tab shows a variety of user interface controls that could be used in the final user interface design.

An alternative design for the user interface uses a remote-control paradigm. This has the advantage of being easier to read and use due to larger controls and a familiar layout. This may be especially important when a user is trying to operate the handheld with a pair of gloves.

Both layouts could be included in the final product. The user would select the ‘skin’ that they prefer by going to a preferences page and selecting the layout to use.

Figure 8 - Remote Control layout

3.2.2Data Store

The handheld software will contain a simplified version of the data store used in the Reader. The handheld needs a data store so that it can buffer data that it downloads from the Reader until it can be forwarded to the remote PC.

Though no user interface is specified for the local data store, a tab showing the following information should be created:

• Number of stored records
• Date downloaded
• Reader ID

Additionally, data management controls will have to be created to perform housekeeping tasks on the stored data sets. These controls would be needed to perform the following tasks:

• Display stored tag sets
• Clear tag set

The data store functionality has not been implemented for this release.

3.2.3Command Library

The command library would be the same one used in the Reader. Reuse of the reader commands would allow full compatibility with the reader and quick development due to reuse. Full details on the command library are in section 2.3.4.

3.2.4XML Parser

The XML parser used in the handheld software will be the Expat parser. Again, this implementation will be reused from the Reader implementation. Full details are available in section 2.3.3.

3.2.5XML Generator

The XML generator will share much of its code with the Reader. The XML generator used in the handheld software will be a superset of the generator used in the reader due to the need to support a larger number of commands.

In the handheld software, the generator needs to be able to do the following tasks that the Reader will not need to do:

• Create XML tags that can set configurable parameters
• Reset a remote data store
• Dump a remote data store
• Get network ID

Additional details are available in section 2.3.5.

3.2.6Configuration Manager

The configuration manager is a module that exists only in the handheld software. The purpose of the configuration manager is to store several unique reader configurations. This will allow the user to recall all of the settings for a particular reader and retransmit them or review them if needed.

This would function as a virtual ‘learn’ mode. ‘Learn’ mode should also be implemented to allow a handheld to ‘learn’ and store all of the configuration settings for a Reader. This would allow the user to clone a reader easily.

The configuration settings would be stored in an XML-based database on the handheld. This file could be transmitted or saved to an external computer. Since it is XML, a user with an XML editor could easily modify any of the settings in the configuration file.

The expat parser would be used to read this configuration file and the XML generator would know how to save settings to the XML database.

3.3Communication Interface

The communication interface would be abstracted so that the Reader software is isolated from the method of physical transport. This wrapper would allow messages to be carried in a neutral fashion over a variety of transport methods. A small plug-in to the communication interface would be created to implement the particulars of each medium. Initially, communications plug-ins would be created for the following physical transport methods:

• Ethernet
• Serial

This communication interface would be reused from the Reader implementation.

4.Messaging Protocol

4.1Overview

The messaging protocol used between the components of the Reader system will be based on XML. This gives a plain-text method of messaging that is easy to parse with off-the-shelf libraries. It is also easy to extend if additional messages are needed.

Normally, XML tags can be expressed in a very verbose fashion to make them self-documenting. In the Reader implementation, the tags will be kept terse to reduce bandwidth requirements. Additionally, all values will be specified as parameters to the tag to eliminate the need for end tags and simplify parsing.