SecurityAlarm

Central Security Stations – Business Awareness Engine

knowventBanner

~The Scenario


I was recently approached by a client of mine with an small inquiry to a rather big problem. Initially, I was asked if they could have some kind of alarm/flashing light or siren to be tripped in the office when they receive a high priority alarm from one of their customers. They do receive notifications from their Central Station software platform but it is a discreet, red text marquee at the bottom of their screen, easily missed.

The problem: Due to the time-sensitive nature of these alarms, the current small text marquee was not sufficient to override the staff’s current tasks or distractions that could cause the acknowledgment to be delayed.

The Solution: Iteedee created a process to monitor their central station management platform for data-driven events and forward that information to their staff via their choice of alarm (which as a very loud tone alarm).

~Where to Start


Many organizations run very proprietary software systems. My client wasn’t any different. They are running a central station signal management platform called Manitou. Theren lies the key to the solution. I needed to find out when a signal is received by their Manitou system that is a high priority and hasn’t yet been acknowledged by the staff.

It is necessary to look at multiple attributes of a signal. My client required the solution to only trip the audible alarm when it is high priority and unacknowledged. Once the signal was acknowledged the alarm would automatically disable.

Without going into too much technical detail, it was decided that monitoring the system repository for these records with the appropriate attributes was indeed the best approach. This gave me the key needed to determine when to start and stop such an audible alarm.

~Tripping an Alarm, the Software to Hardware Threshold.


Many professionals in the security industry deal with hardware systems almost exclusively. So, it would make sense that implementing a solution using a physical, audible alarm to notification people of a problem would be the best solutions and I would agree. However, from a software perspective this probably seems like a problem. Taking data from one place, doing something to it and then outputting it elsewhere is what we do. Interfacing to anything hardware related could be a deal-breaker.

alt text

Enter the WebRelay

Most electrical devices can be controlled directly or indirectly through the use of an electrical relays. ControlByWeb offers many different devices that can be controlled using HTTP Requests. The beauty here is the simplicity. Interacting with resource via web is a well known and reliable protocol. With the rise of the Internet of Things (IoT) space, creating a simple interface between software and hardware is paramount and ControlByWeb has accomplished just that with their products.

The programmers job just got a lot easier.

So, equipped with a device that can accept relay state changes through HTTP requests I only need to concern myself with the software end. The solution also required analysis of proprietary, semi-closed system. However, there was an accessible database. This wasn’t ideal but we didn’t need to write or push data to the platform, only read. Performing Insert/Update task directly against a database that you don’t control is a very bad idea.

After careful analysis and validation the appropriate data tables to monitor were found. We will call this the Trigger. So, we have identified the trigger as the input and the WebRelay/Alarm as the output. The next step is mending it together to get a workable solution.

~The Durable Business Awareness Engine


alt text

Alarm systems need to be fault tolerant, redundant and durable. The solution here is no different. Before anything work was done the following was required:

  • Monitor Process Durability: I needed to ensure the nature of the process would not stop just because a step failed.
  • Logging History: It is necessary to maintain a log of all notable events. We need to know when a event was triggered, a failure occurred, when the system performed a heartbeat check and the running/stop events.
  • Fault Tolerant: This may be obvious but many software packages are written to work and not written to handle errors. We had to ensure the process continues to run through its workflow regardless of problems. If problems arises the issue is logged and forwarded to the appropriate party.
  • Alternative Notification Methods: For redundancy, it is necessary to alert person via email, text message or mobile push notification of an issue arises with a process. This is important since the process is silent until a trigger is handled. If there is a problem at any point, perhaps a network communication failure, people need to be notified so they are aware of the failure. This in turn sets an expectation that the process cannot be relayed on until the issue is addressed.

The software solution was built to perform a set of tasks in order to monitor the specified event occurred. This employed using Iteedee’s durable Business Awareness Engine to manage, execute and log the custom built process. The process is configurable and was setup to run every 10 seconds to check communications between the related systems and query Manitou’s system of relevant data. The Business Awareness Engine allows for the process to perform self checks and heartbeat monitoring to ensure all related system are running as expected. If a problem was found a notification would be sent out via email, text message or any other notification vehicle requested.

One common failure point is network communication failure. This solution relies on their network for communication across system. It is also a point of failure that is outside the control of the solution. We needed ensure the accessibility of the remote system existed every time the job ran, sending out notifications when failures occurred. Other failure points were addressed in this same manor.

~The Conclusion

Simple, to the point, remedy was created for redundancy to a line of business failure point. If a dispatcher misses a small text notification while handling another work item then the higher priority task will not get escalated, failing to meet the required response time.

With the Business Awareness Engine implemented, many other plugin processes can be used to keep a keen eye on their line of business systems. A problem shouldn’t have the potential to go unnoticed. Being proactive, rather than reactive, is always the cheaper route.

Posted in Business Process Management, Central Station Alarm, Security and tagged , , .