Security Integrations with Intelligence

Overview

One of the major value propositions that Telaeris brings to our clients is our ability to integrate to most access control systems. This broad capability ensures security integrators can rely on the XPressEntry interface remaining consistent, regardless of the deployed PACS. To manage our 40+ integrations, we’ve built a flexible framework to support each system. In this blog, we discuss some of the technical nitty-gritty details of how we build these integrations. Even more exciting, you’ll see how Artificial Intelligence (AI) is now accelerating our integration workflows. Be forewarned – this blog contains a ton of lingo. If you get lost, there is a glossary at the end of the article!

Why build an Integration?

Let’s look at the top 3 use cases of XPressEntry to understand the purpose of building an integration and what data is really needed. These are:

Entry/Exit: The handheld operates like an entry and exit door reader connected to a panel to validate the user’s permissions. This is true for bus usage, temporary gate, or manned validation. 

Events/Ticketing/Trainings: The credential/employee permissions should be validated prior to entry or to track their attendance.

Emergency Mustering: The handheld works like a reader connected to a panel in a remote and safe parking lot, with information available so that a paper roster doesn’t need to be filled.

From a high level, all of these use cases look like one (or more) reader connected to an access panel, which will send its activity back to the PACS or store if offline. This means from a simple level, the handhelds only need a limited amount of access control data to operate, including:

1. Badges/Biometrics
2. Door/Portal/Gate readers
3. Areas/Zones
4. Access Panels
5. Badge Permissions

For simple entry/exit or events applications, the PACS integration needs to be able to validate whether a specific badge has access. A red light or a green light could be sufficient. However, because our handheld badge readers have beautiful screens, we are able to display significantly more data from the PACS which allows improved verification by the guard:

1. Badge holder text data (name, phone, certifications, phone number, etc. – as needed)
2. Photos

When we look at emergency mustering solutions, we have more information we need from the PACS – namely facility occupancy. There are two ways to get occupancy information:

1. Request this from the PACS system or
2. Monitor every entry/exit point to track who is in the building.

Lastly, while having all of the information on our handhelds is beneficial, companies want the PACS to be the system of record for both entry/exit and employee accountability. To do this XPressEntry needs to push handheld validations and door activities back into the PACS system.

What is needed for a handheld Integration

Integrating into an access control system simply means being able to pull the data above from the PACS database and to push activity back to the handheld. As one might imagine, every PACS has its own method. These are generically called SDKs or APIs and include the word salad terms of COM/DCOM, DLLs, REST, SOAP, WCF, and CSV. Most PACS integrations are continuously improving and adding new features.

To ensure we get the latest updates from the PACS, most importantly to badges and permissions, we are often provided with a way to subscribe to event changes. This will use technologies such as SignalR or MQTT, often operating over a WebSocket

On occasion, the SDK/API will be updated to a more modern framework. For example, our very first handheld integration back in 2008 was with Lenel OnGuard. This was a pure SQL database integration, which then evolved into a certified integration through Lenel’s DataConduit connector and COM interfaces. DataConduit itself was superseded in 2018 by OpenAccess.

From a high level, each of these technologies provided the same data to our handheld, but the updated integrations were faster, more stable, and easier to work with. 

Bringing it together

When we started building integrations seventeen years ago, we were focused on pulling data from external databases using SQL. Very quickly, it became apparent that this approach was severely limited. To address this, our engineering team focused on building a framework for data import and export which we call the XPressEntry DataManager. This framework can support a wide range of integration methods in a consistent manner. These support any flavor of APIs, SDKs, database connections using SQL, or combination thereof. It can even multiple integrations simultaneously.

To get started with a new PACS integration, we generally request the following information from the manufacturer, to allow us to fully test and vet the solution:

1. Sign any NDAs as required
2. PACS software installer to be setup on our local virtual machine infrastructure
3. A sample database (DB) for initial testing
4. Information to update DB with 10K user + badge + picture records for scale testing
5. API documentation, SDK downloads, and libraries as needed
6. A compatible access control panel and door reader
7. Contacts to support development, because there are always questions!

With the above in place, it generally takes 3 to 4 man-weeks to build and test any integration. But this is changing!

Building Faster, Smarter, Better with AI

For our latest DataManager integration, we tried something new using Artificial Intelligence. For this project, our engineers locally trained the AI engine on our local code to understand how we built our DataManagers and our code structure. We then provided this engine the PDF of the PACS integration documentation along with a mapping of information from the PACS naming conventions to XPressEntry conventions (eg. badges → cards). After this, we directed an AI pipeline to build the integration.

The result of this was pretty impressive. With no additional prompting, the AI engine created a project with more than 1000 lines of code. AI correctly handled the heavy lifting of API documentation parsing and code generation including:

• Building the entire PACS DataManager project
• Creating a setup project and installer for the PACS DataManager

This generated project presented a few issues including:

• Missing Imports: Needed to be added
• Hallucination: Imagined functions for data not provided by API 
• Errors Found With: Timestamps, endpoints, parameters, and capitalization

Cleaning the project up and updating the PACS software to have valid data to test with took approximately 2 hours. After this, it successfully ran a basic working version of the PACS integration connected to XPressEntry. That capability is super powerful. We still have our work left to do to optimize the system, test edge cases, and educate ourselves on the generated code to allow us to support the PACS integration. My engineers are not worried (yet) about AI replacing the jobs, but they love the acceleration in the dev process. AI has effectively cut our development time in half for building our integrations!

So if you have a handheld badge or biometric project needed for a client with a new access control system, BRING IT ON!  We are ready to help you.

Lingo

To discuss this intelligently, it is important to clarify the terms used in these sorts of integrations.

API – Application Programming Interface – how a program speaks to a PACS

COM – Component Object Model – enables apps to use data from other programs

Cookie – small file stored in your browser to remember information and provide access

CSV – Comma Separated Values – a plain-text file format to store spreadsheet type data

DCOM – Distributed Component Object Model – like COM, but between computers

DLL – Dynamic Link Library – a file containing reusable code often used to provide API 

HTTP – Hypertext Transfer Protocol – the foundation of data communication on the web

JSON – JavaScript Object Notation – a lightweight data format for data exchange

MQTT – Message Queuing Telemetry Transport – publisher-subscriber protocol for machine-to-machine communication

PACS – Physical Access Control System – software connecting people, badges, permissions,++ 

REST – REpresentational State Transfer – a web service API communication standard

Secure access tokens – a short-lived, encrypted string to gain access to APIs

SignalR – open-source library to subscribe clients to changes

SDK – Software Development Kit – generally installed software which provides an API

SOAP – Simple Object Access Protocol – a web service API based on XML

SQL – Structured Query Language – a native way to speak to databases

WCF – Windows Communication Foundation

WebSocket – two way communication protocol over a persistent web connection

XML – EXtensible Markup Language – a set of rules to encode data and documents