SIMPL Framework for Access Control (opndrs)


Access control and building/home automation systems share many characteristics in common.

Typically such systems can be viewed as black box of software/hardware between sensors interfaced to the real world on one side and a human interface on the other side.

One can think of actions against such a system as events which propogate through the system from one side to the other.   The software "terrain" that these events traverse can be thought of as a stack.      At the lowest end of this stack are elements of software which deal with the raw sensor data.     At the highest end of this stack are the software elements which deal with logical constructs which mirror real world elements such as doors,  rooms,  windows etc.

The human interface can connect into this stack at either layer but typically would interface with the highest end.

Similarly the sensor/actuator side can interface with the stack at either layer but typically would interface at the lowest end.

As events make their way through this stack actions can be taken on the event which include:

Within the SIMPL paradigm it is possible to create such a stack out of a couple of highly reusable components:
  1. agency
  2. agents (SM in the diagram below)
This modular separation facilitates both testability and extendability of the system.     The tokenized message definitions describe the interfaces between layers in the stack.


By way of an example

Lets see if we can describe things by way of a simple example.

Take an access controlled door.

Such a door may contain the following sensor/actuators:

In operation this door may be described by the following finite states:
Perhaps this door is equiped with a keypad or smart card sensor which interfaces directly with the lock.    If a resident with a valid code engages the lock an UNLOCK event will be emitted into the system.

The lowest layer in our stack might be a some logic for raw devices.    This UNLOCK event will make its way into the lock device area in that logic.    If all is well this lock logic will forward this event up the stack to the door layer because this lock is part of a door.

The door layer logic will then enter this UNLOCK event into the finite statemachine associated with the door.    Normally this will result in the state moving from the closed-locked (CL) state to the closed-unlocked (CU) state.

At this point the door logic may spawn a new event. destined for the human interface layer to enunciate (or log) the fact that the door was unlocked.       Depending on the degree of security surrounding this lock,  events may go out to a validation module and back down the stack to the lock logic and out to the hardware before the lock is actually unlocked.

Presumably at this point the resident grasps the door handle a procedes to open the unlocked door.     This causes the door contact sensor to change state and an event is emitted into the device logic layer destined for the contact logic element.     As before this event is then forwarded up the stack to the door logic for consumption.     Once the DOOR OPEN event is cranked into the finite state machine the door state moves to OPEN in our diagram above.

At this point the door logic may spawn a couple of new events:

If the resident procedes through the door and it closes automatically behind them,  the contact will once again change state and the contact event will make its way into the stack as before,  up to the door logic and cause the door state to revert to the closed-locked starting state.

However, if the delayed event arrives before the contact event,  this indicates that the door is being held open beyond the allowable window for entrance.      This event will enter the door layer in the stack and cause the door state to move to held open (H).    At this point the door logic would likely emit an event towards the device layer in the stack destined for the alarm element.    When the device layer logic associated with the alarm receives this event it will emit some signals toward the sensor/actuator end of the system to sound an alarm.      The door logic may also spawn a new event destined toward the human interface to visually sound this same door held open alarm.
Hopefully by way of this simple example you can begin to appreciate the modular construction of our framework and how complexity can be incrementally added to such a framework in methodical and testable fashion.

First significant project milestone

The seed code for this project already does the logic described above,  with the notable absense of a real sensor interface plugin or a real human interface.

The sensor interface plugin will have to wait for some vendor input into this project.     All we can do at this stage in the project is work at tidying up and defining the plugin interface requirements for that vendor plugin.       To substitute for real hardware the seed code supplies a plugin which operates directly out of a text file,  parsing and emitting a series of events as if they originated from real hardware.

This hardware simulator plugin will be polished up somewhat for the first milestone release.

The human interface will utimately also be application specific and we can't anticipate all variations at this time.     What I propose be constructed for the first milestone release is a simple interface which consists of a series of JPEGs of a real door in each of the states noted in the statemachine diagram above.       As the human interface messages arrive they will be timestamped and logged and the appropriate door image will be displayed.

There is configuration data built in to linked lists associated with the SM elements in the seed code.      This seed code is currently driven by a simple

tag:  value
text file which supplies all the configuration elements.     I propose for the first milestone that we create a graphical special editor which can read in and/or create these text files in a more friendly way than a straight general purpose text editor could.      This editor should be SIMPL enabled enough to initiate the messages associated with UPDATE on these distributed datastores.

The Knoppix selfhosted (live) CD concept is a powerful one.     I propose that for our first milestone release that we create a customized version of the Knoppix CD which will contain a fully operational door simulator.

back to main opndrs page

This project is being coordinated by  iCanProgram Inc.