SIMPL Framework for Access Control (opndrs)

Vision

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:

• consuming the event
• modifying the event and/or passing it to an adjacent layer in the stack
• spawning secondary events for immediate or delayed action

1. agency
2. agents (SM in the diagram below)

By way of an example

Take an access controlled door.

Such a door may contain the following sensor/actuators:

• lock
• contact sensor
• alarm

• closed-locked (CL)
• closed-unlocked(CU)
• opened (O)
• held open (H)

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:

• one destined for the human interface (or logger) to indicate the opening of the door
• a delayed event timed to be re-emitted at a some future moment to check if the door was held open

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 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

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.