This pic should explain the spaghetti reference in the post title…

More Spaghetti than an Italian Restaurant

This may all look a very unsophisticated , but the systems behind this are industrial strength and pretty comlex.

Physical Access Management System

It’s kind of humbling to think of the millions of $’s worth of system and the size of the team that has toiled for well over a year putting the system together that is controlling my dinky boom-gate here.

My project at work at the moment is a large Physical Access Control System (PACS). We have automated some of the testing of physical devices with an I/O interface and API into the control devices.

As a bit of fun I built this to hang off the controller rather than watching events and status updates at a computer console. The code very accurately simulates the behaviour programmed into the PLCs of the actual boom-gates that are controlling access on several mine-sites and ports all across Queensland.

Model Boom-Gate

Implementation

Breadboard Wiring

The implementation of this project is very simple. (Though the application is a little novel, I think.)

Inputs

• Open Request: I have a push-button switch with a pull-down on the breadboard to test (play) with the application, but in reality this digital input is connected to a (normally-open) relay output of the PACS controller board that takes its direction from the overall system after assessing things like: driver ID (RFID); vehicle ID (RFID); qulaifications; fitness for work; fatigue (external systems).
• Reed Switch: This is to simulate the operation of an induction / safety loop as the vehicle passes over it. (This is a very noisy device and really should be debounced through code or hardware.)

Outputs

• Open State: The boom-gate is considered open the moment it starts to move upward and closed the moment it starts to move down. This is used in monitoring to know whether the gate is open without the “consent” of the control system, which will then raise an alert.
• Safety: This prevents the boom-gate (locally in its PLC / control) from closing while there is a vehicle under it. This is exposed as an output so the system can determine if the vehicle granted access actually drove through the gate or not.
• Servo Position: To open / close the boom arm.

Control

• State Machine: IMHO, this concept sits really well with embedded or control system software. In my application there are only four states and simple rules / actions on the transitions. There are *way* more complex implementations for this out there and, what appears to be, a pretty solid library available for Arduino. All of this seemed a huge overkill for my little application, so I managed my states and transitions via a simple Switch / Case control structure in my code.

UML Statechart

  // incredibly simple state machine
  // check for vslid transitions from the current state
  switch(_state)
  {
    case OPENING:
      // current state: Opening
      // transition to: Open
      // guard: Position >= Upper Limit
      // action: none
      if (_position >= INCREMENTS)
      {
        _state = OPEN;
      }
      // current state: Opening
      // transition to: Closing
      // guard: Open Request = false  AND Safety = false
      // action: set Closed
      else if (_openRequest == false && _safety == false)
      {
        _state = CLOSING;
        _openState = false;
      }
      // open boom-gate
      else
      {
        // increment position and set servo
        setServoPosition(++_position);
      }   
      break;
  
    case OPEN:
      // current state: Open
      // transition to: Closing
      // guard: Open Request = false AND Safety = false
      // action: set Closed
      if (_openRequest == false && _safety == false)
      {
        _state = CLOSING;
        _openState = false;
      }
      break;
  
    case CLOSING:
      // current state: Closing
      // transition to: Closed
      // guard: Position <= Lower Limit
      // action: none
      if(_position <= 0)
      {
        _state = CLOSED;
      }
      // current state: Closing
      // transition to: Opening
      // guard: Open Request = true OR Safety = true
      // action: set Open
      else if(_openRequest == true || _safety == true)
      {
        _state = OPENING;
        _openState = true;
      }
      // internal state activity: close boom-gate
      else
      {
        // decrement position and set servo
        setServoPosition(--_position);
      }
      break;
  
    default:
      // current state: Closed
      // transition to: Opening
      // guard: Open Request = true
      // action: set Open
      if (_openRequest)
      {
        _state = OPENING;
        _openState = true;
      }
  }

Construction

This was pretty simple.

• A small project case with a slot cutout to mount the servo motor
• A length of balsa bolted on to a servo horn for the boom
• Cutout in the wood base for the Reed Switch
• Fabricate a metal bracket for the Vehicle to mount the magnet

Boom-Gate

Truck

Links

• Fritzing Project: This is the host site for a great app for wiring up your breadboard circuit and moving through to PCB design. Fantastic piece of software too!
• Arduino Code

I am a simple creature! It made my morning this morning when I discovered a stencil download that added some of the UML 2.2 features to visio (which is floundering somewhere around UML 1.x out of the box…).

“The UML stencil for Microsoft Visio supports all symbols of the UML 2.2, specified in OMG UML Superstructure Specification, formal/2009-02-02, as well as all previous versions, UML 2.1, UML 2.0, UML 1.5, UML 1.4, UML 1.3 and UML 1.1.“