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, 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 and egress point and consolidate who is in the building.

 

Lastly, while having all of the information on our handhelds is beneficial, the goal is to make the PACS the system of record for both entry/exit and employee accountability. To do this we need to push handheld badge and biometric activity 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 newer and 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 their DataConduit connector and COM interfaces. DataConduit was superseded in 2018 by the OpenAccess API.

 

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 that now allows us to work with a wide variety of API/SDKs in a consistent manner.

 

Our framework now, which we call our XPressEntry DataManagers, can support a mix of integration methods. These support any flavor of API, SQL, or combination thereof or even multiple integrations simultaneously.

 

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

 

1. Get the PACS software set up on one of our local virtual machines
2. Get a sample database installed
3. Create 10K user+badge records to work.
4. Ensure we have the documentation, SDK, and libraries for the PACS API
5. Set up a compatible panel and reader
6. Map names from PACS to XPressEntry (eg. badges → cards) 
7. PACS contacts to support our development, because there are always questions!

 

With the above in place, it has generally taken us about 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 decided to try something new by using Artificial Intelligence. For this project, we provided AI a PDF of the PACS integration documentation.

Our engineer locally trained the AI engine on our local code to understand how we built our DataManagers, our code structure, and mapping information from the PACS naming conventions to XPressEntry conventions. After this, he then created an AI pipeline to build the integration with no additional information.

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 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: Timestamp, endpoint, parameter names and capitalization.

Cleaning this up took approximately 2 hours to make it run a basic working version of the PACS integration. This included updating the PACS software to have data to check this functionality. That is super powerful. We still have our work to do to optimize the system, test edge cases, and educate ourselves to be able to support the PACS integration. But 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