WDN Configuration Documentation

Selective Communications

1.7.13

Contents

  • Terminal Overview
  • Configuration


Terminal Overview

A data terminal is a communications device installed in a vehicle, or a fixed location for data capture, and display.

Data terminals are used for a number of different communications applications:


Features

Two way messaging
Job Processing
GPS Tracking
Timesheet tracking

Two way messaging

Freeform text messages can be sent and received from the data terminal. The terminal maintains a list of all received messages and allows the operator to reply to received messages, as well as to initiate messages to base.

Job Processing

The terminal has a structured job processing system. The logical order of processing is as follows:

  • Base despatches a job to the data terminal.
  • The operator begins processing the job, updating base with the job status (thereby allowing the measuring of KPI's).
  • The operator captures all relevant information pertaining to the job electronically (eliminating double handling of information).
  • The operator completes the job, and moves onto a new one.

GPS Tracking

As a standard option the terminal can be interfaced with an external GPS device. This enables positioning information to be recorded, and transmitted back to base. Additional job processing functionality is also present when a GPS device is attached.

Timesheet tracking

Before using the terminal it is necessary for the operator to 'logon'. This logon would normally be executed at the beginning of the operator's shift. The staffid, name, and optionally a odometer reading is captured at logon. By requiring operators to log on, and storing this information at base; time sheets can be automatically generated. Optionally, many operators may logon individually to one terminal, then log off at seperate times. This is useful when a number of operators work together, but keep different hours.


Screen layout

To understand the configuration of the terminal, which is the primary purpose of this document, it is necessary to understand the screen layout of the data terminal. The following flow diagram shows the screens of the terminal, and the available links between screens.

Figure 1.1: Screen flow diagram of data terminal

As can be seen from the diagram the terminal starts at the initial screen. After a single logon has been completed the terminal shows the main screen. Additional logons will return the terminal to the main screen. After all operators have logged off the terminal will return to the initial screen.

Freeform text messages can be accessed from the messages screen which allows selection, and display of received text messages and the new message screen which allows entry of a new freeform message which is sent back to base.

The jobs screen allows selection of a job to work on. Any indexed fields are displayed in the jobs screen in a columnar layout. A button is present to request a job. When pressed the operator is prompted for some information before sending the job request to base.

When a job is selected in the jobs screen the terminal displays the job details screen which shows all the jobs fields, and provides buttons to manipulate the job. The return fields screen allows the operator to enter structured information captured in the field about the job. The notes screen allows the entry of freeform text which is stored with the job, and later transmitted back to base. The status screen allows the operator to move the job to a next logical status.

The physical layout of these screens are not currently configurable, but their content is.


Configuration

Different customers require the data terminal to operate in different ways. To satisfy the differing requirements of customers the data terminal is extremely configurable. Many aspects of both the data terminal's appearance, and it's behaviour can be changed via this configuration. The WDN Config client (and other 3rd party software) are capable of configuring data terminals by sending information to them over the air. In order to effect 'change management' for the configuration the terminal reports a 'hash' of it's current configuration whenever an operator logs onto the terminal. If this hash differs to the client software's hash the terminal is updated. This system allows transparent replacement of terminals.

The configurable sections of the data terminal are as follows:


Job Fields

A job is composed of units of data known as fields. The job field configuration page sets what fields are displayed on the terminal in the job details screen.

Figure 2.1: Job Fields Configuration Example

The above example shows the job id on the first line of the job details screen. On the second line it shows from, and this continues onto the next line by using a field with no label. The to, and notes follow, then the datetime that the job was sent from base, then the current status of the job. On the jobs screen the fields job no, from, and to are displayed in columns. The column widths are as shown. The jobs are alphanumerically sorted by job id.

Using the Jobfield configuration screen
Jobfield types
Jobfield indexing
Job sorting
Constant fields
Varying fields

Using the Jobfield configuration screen

To add a jobfield
Press the new button at the left of the button bar in the top right of the screen.
To delete a jobfield
Put the cursor on any cell in the jobfield you wish to delete, and press the delete button in the button bar.
To reorder jobfields
Put the cursor on any cell in the target jobfield, and press the up or down buttons in the button bar to move the jobfield.

A jobfield is comprised of a type, a label, and indexed flag, a width, and a sort flag.

Jobfield types

JobId
This field shows the alphanumeric job identifier (unique for each job).
Job location
The GPS location of the job (this is not always available, and would be 0,0).
Time
The is the time (no date) that the job was despatched.
Date
The date the job was despatched.
DateTime
The time and date the job was despatched.
Status
The current job status, see status stack configuration.
String
This is a configurable field that is despatched with the job.
Hidden
This is the same as a string field, but it's not displayed on the terminal. Only useful when used as a sort key.

Jobfield indexing

When a jobfield is indexed it is displayed on the jobs screen. This is a tabular display (similar to the above diagram) with jobs as rows, and indexed fields as columns. The width of the columns is set by the width field. The sum of the widths of the indexed fields must be less than 38 to fit on the terminal's display.

Job sorting

The order of jobs in the jobs screen is set by the sort key. Currently only a primary sort key is supported. The one jobfield that is set as the sort key dictates the sort order of the jobs. A jobfield doesn't need to be indexed in order to effect the job sorting. Also, a hidden sort key can be used, just add a hidden field, and make it the sort key.

Constant fields

Some fields are always sent regardless of whether they are configured within this screen or not. These fields are referred to as constant fields. They must always be sent as the terminal uses them internally. The fields are the job id, job location, status, and datetime. They will not be displayed on the terminal unless they are configured here, however.

Varying fields

Some jobfields need to be sent only on some jobs. These should not be configured here, but sent with the job in the varying fields section of the job record. Only 'string' type fields can be sent in this way. The varying fields are displayed below the fields configured here on the terminal's job details screen.


Status Stack

Conceptually a job always has a current state. The data terminal refers to this as the job's status. To specify the allowable status transitions (and allowable statuses) the data terminal stores a 'status stack' which contains this information. It is stored as a tree-diagram that each job can traverse.

Figure 2.2: Example Status Stack

This example shows a simple job processing flow that is used in most mobile service industries. When a job is received it's considered to be 'waiting'. The operator must first either accept or decline the job. The decline status has no targets (no acceptable transitions) and therefore requires no further processing. If the job is accepted, however, it can then be moved to 'in progress' (i.e. when the operator begins the job), and then to 'completed' when the operator completes the job. The terminal can display the current status of a job on it's user interface. Also, whenever a job changes status the terminal records when, and where the status change took place, and communicates this information back to base. After a job is finished (i.e. completed or declined in the above example) the terminal deletes it's copy of the job, and removes it from the list of available jobs (for that terminal). Some customers require a different processing flow for different types of jobs. To accomplish this you can have multiple independent status trees within the status stack. The active status stack (for a job) is selected by the initial status specified when despatching the job.

Using the status stack configuration screen
The status properties

Using the status stack configuration screen

The second page in the config window is the status stack configuration page. You can create statuses, link them together and edit status properties.

To create a new status
Left click on any blank area, a new status will be created under the mouse cursor
To delete a status
Right click on the status box. You will be prompted to delete this status.
To connect two statuses
Drag with the right mouse button from one status to another.
To delete a connection
Right click on the arrow between the two statuses
To edit a status
Double click (left mouse) on the status node. This brings up the status properties window.

The status properties

Each status has properties that can be set. These properties affect the way the terminal behaves with this status.

The label field
This is the text displayed on the terminal for the current status, and when selecting the next status from a list.
The title field
This is the text that is displayed at the top of the screen in the terminal when this is the current status.
Send Return Fields
If this is selected the terminal will send it's current return fields when the job enters this status.
Clear Return fields
If this is selected the terminal will clear it's current return fields when the job enters this status (after optionally sending the information back to base).
Honour Return Field Requirements
If this is set the terminal will require the operator to meet the minimum return field requirements before this status can be entered.
Send Log
If this is selected the terminal will send it's current job log back with this status transition.
Clear Log
If this is selected the terminal will clear it's current job log when entering this status (after optionally sending the information back to base).


Return Fields

As a job is worked on information about that job often needs to be captured. This information is entered into the return fields section of the data terminal user interface.

Figure 2.3: Return Fields example

Each return field is composed of a type, label, and requirements.

Return field types
Return field requirements
Oneshot return fields

Return field types

Each return field can restrict the characters that can be typed into it. The following types are available:

String
Any alphanumeric characters can be entered into this field.
Number
Numeric characters [0-9] can be entered.
Float
Numeric characters, and decimal places can be entered.

Return field requirements

In addition to restricting the characters that can be entered, it's possible to require a minimum numbers of characters or restict to a maximum. The maximum value sets the size of the input box on the data terminal. The minimum value sets the minimum number of characters that must be entered before the field is considered valid. If the field is not yet valid, and the operator attempts to enter a status that has the 'honour return field requirements' flag set; the terminal will prompt the operator to enter more information. For finer grained control each return field can have a status set. This requires the operator to enter the minimum number of characters before transitioning to that status.

Oneshot return fields

If the 'one shot' flag is set on a return field that return field is not listed in the return fields screen, and is only shown when entering the status specified in the return field. The minimum number of characters must be entered before the operator can continue. This is useful when multiple independant status stacks are in use, and it's desireable to reduce the confusion for the operator by having all possible return fields in the return fields screen.


GPS Acquisition

The GPS Acquisition screen is used to configure the way the terminal acquires and sends GPS points back to base. This is primarily used for displaying the location of terminals on mapping software at base. The terminal differentiates between acquiring, and sending a point. The terminal continues to acquire points (using the specified criteria) until the send criteria is met, then it transmits the points back to base. There is an advantage both in network access time, and overall bandwidth used by grouping points together.

Acquisition configuration
Sending configuration
Time update

Acquisition configuration

If the Automatically acquire position flag is set the terminal will automatically acquire GPS points using the following criteria:
Time based acquisition
Acquire a point every x seconds.
Distance based acquisition
Acquire a point every x meters.
Geofence based acquisition
Acquire a point whenever the unit crosses a geofence if that geofence's boundary has been ticked (see geofences).

The criteria can be combined so that the unit will acquire either every x seconds or every x meters, whichever comes first. Acquisition based on geofences can be a very low bandwidth way of obtaining pertinent information. Often the exact location of a terminal is not relevant, it is only necessary to know which zone the terminal resides in. By measuring this at the terminal significant amounts of needless (and expensive) data transfer can be eliminated.

Acquire additional information causes the terminal to acquire the altitude, speed, and heading when it acquires the longitude, latitude, and time (which are always acquired).

A lockout period can be specified if it's not necessary to know where the terminal is during part of the day (e.g. when it's locked up at base). The start and end of the lockout period is set in 24 hour time to a precision of 1 minute. This method is unnecessary if acquisition is done purely on a distance basis.

Sending configuration

If the Autosend flag is set the unit will automatically send points back to base. If it is not set the unit will have to be polled by base to retreive the stored points. Similar criteria is available to determine when to send points back. This may seem like duplication, but it makes it possible to e.g. acquire a point every 50 meters, and send points back every 10 minutes. Or one of many other combinations. If the send criteria is the same as the acquire criteria the terminal will send back each point as it acquires it.

Time update

The time that is captured when a terminal acquires a point, is the terminal's local time. This time is maintained by a real time clock. If Update time from GPS is set the unit will update it's time whenever it receives a GPS fix from the external GPS unit. The GPS time is received relative to UTC, but the terminal's time is in the local timezone. The timezone selector sets the offset applied to the GPS time before updating the terminal's time.


GEO Fences

GEO Fences are shapes drawn with GPS points to delineate zones of interest. They are used for gps acquisition, terminal display, and autostatuses. Each geofence is drawn with either a circle defined by a radius and a point, or a polygon defined by it's points.

Figure 2.4: GEO Fence example

The above example shows a circular zone around base, two polygons that define 'zone a', and 'zone b', and an 'ok' zone that could be used to trigger an alarm if a terminal moves out of it. The 'ok' zone has hot entry and exit fences which are used to trigger a gps acquire or send which in turn triggers an alarm at base to notify administrative personel that the operator has left the acceptable working area.

Fence types
Layers
Points format
Closed Polygons
Overlapping fences, and historesis

Fence types

There are currently two fence types
Polygon
These are closed polygons defined by points giving the vertices. The points text should be entered as a list of points in the format (x1,y1),(x2,y2). It is not necessary to re-enter the first vertex.
Circle
These are circles defined by a radius (in metres), and a center point. The points text should be in the format (x,y),r where x,y is the center of the circle, and r is the radius.

Layers

GPS Zones are not always mutually exclusive. e.g. it may be advantageous to have a zone that specifies an entire city, and also zones within that city for the suburbs. The terminal must make a decision about which zone it should be in in order to process zone change events. To have zones within zones you must use layers. The terminal determines which zone it should be in for every layer. e.g. It could determine which city, and which suburb it's in. This information can be displayed on the user interface, and can be used for out of bounds alarms. i.e. the terminal could display which suburb it's in, and also have a large geofence around the entire city which is used to trigger an alarm at base if the terminal leaves it.

Points format

All points must be entered as decimal degrees. If you are only able to retreive points in a degrees, and decimal minutes format they can be converted as below. All points retreived from the terminals are also in decimal degrees.

Degrees and decimal minutes to decimal degrees The degrees quantity is the same for both measurements. If the decimal minutes value is divided by 60 and added to the degrees value the result is decimal degrees.

e.g. 157deg 45.45" = 157.7575deg

Decimal degrees to degrees and decimal minutes The degrees quantity is the same for both measurements. Multiply the fractional part of the decimal degrees by 60 to retreive the decimal minutes.

e.g. 157.7575deg = 157deg 45.45"

Closed Polygons

All polygons must be closed regular polygons.

Figure 2.5: Example polygons

The above figure shows three polygons, A, B, and C. Polygons A + B are acceptable as they are both closed and regular. Polygon C, however, is not acceptable as it's sides cross each other. If Polygon C is truly what's desired it can be simulated with a polygon like D. If you look closely you will see that although it has many vertices (nine) none of it's sides overlap or cross.

Overlapping fences, and historesis

When multiple zones are in use at the same layer it is advised to overlap zones with a distance exceeding the GPS distance error. When the terminal evaluates which zone it should be in for a particular layer it will favour it's current zone. By overlapping zones you reduce/eliminate the chance of a terminal hopping between zones when it is on a zone boundary. This provides a level of historesis which can reduce the 'noise' caused by GPS error.


Auto Statuses

The terminal is capable of monitoring external events to automate some status processing. e.g. when a terminal arrives onsite it can automatically change a job to the onsite status, assuming it knows the location of the job.

Figure 2.6: Example Autostatus configuration

The above configuration will complete any job when the terminal returns to base, move any accepted job to in progress when the terminal arrives at the job location, decline any waiting job when the terminal detects a low input on IO1, and accept any waiting job when the terminal detects a low input on IO2.

AutoStatus from location
AutoStatus from IO

AutoStatus from location

This is used to update a job's status based on the reported GPS location.

Change Status To
Here you select what the status of the job should become.
When
This is the criteria for the zone, ie enter, leave, or either (which means enter or leave).
Zone
This is the zone to trigger from. Note there is an additional zone 'Job Location' which is the GPS location sent with the job.
If status is
You can restrict this autostatus to only trigger if the job is at a specific status, or at any status.

AutoStatus from IO

This is used to update a job's status based on the status of the IO lines from the terminal (only available with a version 2/12-pin terminal).

Change Status To
Here you select what the status of the job should become.
When IO1 is
Select low or high to make this an active trigger. When any is selected this IO line is ignored.
When IO2 is
Select low or high to make this an active trigger. When any is selected this IO line is ignored.
If status is
You can restrict this autostatus to only trigger if the job is at a specific status, or at any status.

Note, the inputs are debounced. After a transition (low-high, or high-low) the input must remain constant for 3 seconds before it will be acted upon.


Other Configuration

This page contains some miscellaneous configuration options that don't fit anywhere else.

Figure 2.7: Example other configuration

Customer Name
This is the name displayed at the top of the initial, and main screens.
Job Location Tolerance
If an autostatus triggers from the location sent with a job this value is used to determine how close to the job the terminal must become before it considers it to be onsite.
Allow multiple logons
When selected the terminal allows multiple individual logons.
Show GeoZone on terminal
When selected the terminal displays the current (highest layer) active geofence name.
Show zone at each layer
This will cause the terminal to show the active geofence name for each layer (lowest to highest).
Allow terminal job requests
This enables a button on the jobs screen labelled 'new' which will send a job request to base with fixed return field information.