OPNDRS Demo

The OPNDRS project aims to create an access control framework.

This demo will exercise the latest version of this code running on the Linode. The workstation can be running Linux, Windows or Mac with Tcl/Tk installed. The SIMPL toolkit is not required on the workstation side.

In a real system the inputMgr would be wired to the data acquisition module handling digital inputs. In our demo those messages are originating from the GUI buttons described below.

The inputMgr acts as a smart message router. In this demo it can route messages to the doorStatemachine module using the SIMPL toolkit Relay function. The inputMgr can parse the configuration file to extract relevant data for its internal tables.

The doorStatemachine contains the internal tables for the doors as well as the finite state machine logic for the door business logic. These internal tables are configured by parsing the common configuration file for the system (see below). There are 3 ways events can present themselves at the state machine:

• when an input is toggled
• when an action on the GUI is initiated (other than toggling inputs)
• when the internal scheduler kicks off an event

In a real system the outputMgr would be wired to the data acquisition system module handling digital outputs. In our demo those messages are simply relayed to the GUI for display purposes.

Any module can post an event message to the eventLogger. These events are all timestamped. In a real system those events would be logged to a file. In the demo this feature is not enabled. The GUI registers to be a relay client to the eventLogger. This means that once connected the GUI will see all the events as well. These events activate the door icons and/or the message box on the gui screen.

Getting started

You'll first want to grab these pieces of code:

• config file
• generic simpl code
• opndrs demo

Download these into a common folder.

NOTE: If you have a particularly secure firewall which blocks both incoming and outgoing packets, you'll want to have the system admin give you outgoing access for packets destined to icanprogram.ca:port 8000.

You can use these pieces of code to run the OPNDRS demo by typing:

wish gui2.tcl

A screen similar to this should pop up on your workstation.

This demo utilizes up to 8 digital inputs and 8 digital outputs. These are illustrated on the GUI screenshot above.

The inputs are buttons which toggle the value between 0 (Low-red) and 1 (High-green). The rhs of the door icon is also a button controlling the respective door lock output. Inputs are fed into the inputMgr module. The door icon button feeds directly to the doorStatemachine module. The Reload data button allows for on the fly configuration changes.

Configuration file

Blank lines and lines beginning with the # symbol are ignored by the parser. The config file is divided into paragraphs each beginning with the word ADD and ending with the word Z. The first item inside a config paragraph should be the record block type. This can be:

• DOOR - for the door record block
• INPUT - for the input record
• OUTPUT - for the output record
• SCHEDULE - for the schedule record

All the rest of the items inside the paragraph are in the form of

tag: value

Door record description

• ID - must be a unique ID for the door. Serves as the entry index into the doorStatemachine table containing this record.
• label - up to 32 characters describing the door object.
• lock - the objectID for the output record connected to the door lock.
• contact - the objectID for the input record connected to the door contact.
• alarm - the objectID for the output record connected to the door alarm.
• button - the objectID for the input record connected to the door unlock button.
• opentime - the number of seconds to be used for timing door operations such as door held or unlock time. Timing accuracy is determined by the clock rate in the statemachine which defaults to a tic every 10 seconds.
• scheduledUnlock - the objectID for the scheduler record associated with the scheduled unlocking of the door.

Input record description

• ID - must be a unique ID for the input. Serves as the entry index into the inputMgr table containing this record. For this demo it should be 1-8.
• label - up to 32 characters describing the input object.
• relayTo - the only implemented routing destination is the doorStatemachine indicated by the DOOR value.
• High - the message token to be used for routing a input high value. This indicates the action to be taken by the doorStatemachine.
• Low - the message token to be used for routing a input low value.

Output record description

• ID - must be a unique ID for the output. Serves as the entry index into the outputMgr table containing this record. For this demo it should be 1-8.
• label - up to 32 characters describing the output object.
• objID - the objectID for the record this output is imbedded in. eg. 5 indicates door 5.

Scheduler record description

• ID - must be a unique ID for the record. Serves as the entry index into the scheduler table containing this record. For this demo it should be 1-16.
• begin - mark indicating to parser the beginning of the scheduler events. There can be up to 16 of these in each scheduler record.
• Oneshot - begins the block for a one shot timer event.
• on - timestamp for asserting the oneshot output.
• off - timestamp for deasserting the oneshot output.
Daily - begins the block for a daily timer event. MTWtFSs are the weekdays.
• on - timestamp for asserting the daily output.
• off - timestamp for deasserting the daily output.
• end - mark indicating to parser the end of the scheduler events. There can be up to 16 of these in each scheduler record.

Have fun. Hope you enjoy programming the SIMPL way.