Real system integration

May 2010 Integrated Solutions

For a few years now, certain security and fire in­stallation contractors have been branding themselves system integrators. What is behind this term system integrator and what is involved in true system integration?

At the outset it is stated that many equipment manufacturers are interested in developing software interfaces to a centralised software platform, hereinafter the integration platform.

These manufacturers sometimes manage to develop interfaces based on an API (application programming interfaces) made available by the manufacturer/developer of the integration platform. This information could allow the system integrator high-level access to the information stored in the database.

Sometimes this documentation is made available publicly. However, in most instances the API for the integration platform is protected for strategic or commercial reasons. In these cases – without the API for the integration platform – the system integrator often cannot access the integration platform. In these circumstances the traditional route open to the system integrator is to hard wire voltage free inputs and outputs – which are programmed on a what if (event and then action) basis. Fortunately, more recently certain integration platforms allow for the use of socket connection. These ports can facilitate the sending and receiving of transactions and commands and allow for real-time exchange of information between separate systems.

Other recent advancements now offered by certain local manufacturers of the integration platform include soft inputs and outputs, which allow multiple network-based systems to communicate and execute specific commands and events, for example linking access control and a third party IP based intercom system. These two third-party integration options allow for real-time sharing of information.

Other initiatives by the suppliers of the integration platform include generating custom HTML-based reports, where the reporting protocol is published for use by developers to produce any number of reports for use by the third-party system.

Finally, the integration platform often uses a SQL Server database, which through ODBC driver support can synchronise with various third-party databases.

These measures often provide the desired result but what is truly behind interfacing with an application program to allow for system integration. At the outset, an API is made available by a reputable manufacturer of the integration platform and who then certifies any resultant interfaces to validate that system integrators have developed legitimate, supportable interfaces which do not in any way degrade the functionality of the integration platform. At this level, it is important that relatively demanding software programming is required and many of the companies that hold out to be system integrators do not staff a single resource in this regard.

In fact it is usually the third-party manufacturers that develop these programs and only do so where customers insist in their choice of best of class technology.

By using these APIs, the manufacturer can provide a direct interface to their system that is developed, maintained and supported by that manufacturer, and not even necessarily the developer of the integration platform. Whenever the developer of the integration platform releases a new version of software, the third-party is welcome to revise their interface for quality testing. Unfortunately, the financial reality is that these interfaces are then marketed to other users seeking the same underlying technologies in their overall solution.

It is most often the manufacturer of the third-party solutions that assists the end user in realising the combined value of the different hardware/software applications by using the API to get their technology onto the integration platform of choice. Even with publicly available APIs, the system integrator still relies on the supplier’s program engineers for delivering the integrated solution.

These program engineers then make use of various API groups, such as OpenDevice, to communicate with the integration platform. In order to interface with OpenDevice, program engineers need to develop a Translator DLL that implements a set of predefined COM interfaces that is specific to the third-party product type.

Each individual piece of hardware would have its own driver that would understand how to communicate with the hardware. These drivers have been named device translators because they translate a set of generic commands into specific device commands.

The device translators will be implemented as COM (component object model) objects so that they can be loaded and unloaded as needed. Each device translator will support certain interfaces that support a specific set of commands or methods.

A main application is then required to control the various device translators, something like a communications server that manages the device translators and sends the commands to them. Other applications like alarm monitoring or system administration communicate with the hardware devices by sending commands to the communications server, which then sends the commands on to the correct device(s).

Each device translator must in turn support the ITranslate interface as well as the IComConfig Interface. This is the main interface to device translators. In addition to the ITranslate Interface, they can support device type specific interfaces. Each device translator will also use the IDistributeEvent interface to communicate back to the communications server.

The device translators also need a method of communicating to the hardware. Each device translator could have its own code to handle this, but instead communication transporters will be used. Communication transporters function similar to device translators. They are also implemented as COM objects. All the communication transporters must support the ITransport interface but they can also support additional interfaces. One commonly used communication transporter is the one that is used for RS232 communications. This object contains the ITransport interface that contains one method for reading and another for writing to the port. It also contains an IRs232 interface that supports additional methods that are used to open and close the port as well as perform other functions on the serial port. Since different types of hardware may use the same mode of communication, creating a common communication transporter saves from having to duplicate code in each device translator.

The diagram illustrates how the various objects communicate between each other. The clients represent applications that interact with the communications server. They can send commands to the communications server as well as receive messages. The communication server can communicate to more than one device translator and therefore more than one device, but only one has been shown to keep the diagram simple. Another commonly used communication transporter is the one that is used for TCP/IP communication. Some APIs do not support communication transporter for UDP/IP communication.

This is clearly not the domain of the system integrator as we have come to know him in the security space. Typically, all that the system integrator does is configure the system to make use of the already existing interfaces. The programming itself is most often done by the third-party manufacturer of the hardware or software application using the existing APIs.

In summary, a word of caution. When your security contractor mentions the term integration, you may wish to test precisely what they mean. If the integration has not been done already, it may pay to ask who needs to be involved and will take responsibility for the required result.

For more information contact IDtek, +27 (0)11 706 0101,,

Share this article:
Share via emailShare via LinkedInPrint this page

Further reading:

Innovation and service, 37 years and counting
Technews Publishing Impro Technologies Access Control & Identity Management Integrated Solutions
Innovation, simplicity and trust underpin the nearly 40 years of success of local access control brand, Impro Technologies, which is still run as an independent entity despite being acquired by ASSA ABLOY in 2016.

Improving safety and security
Gallagher Education (Industry) Access Control & Identity Management Integrated Solutions
Education facilities have more than enough to deal with when it comes to allocating budget. Security often seems to be the last item on the agenda but is more important than ever.

Software is South Africa’s most promising business opportunity
Integrated Solutions IT infrastructure
When we talk about software as a business opportunity, we are not just talking about software or IT as a standalone product; deploying computer and network-related solutions to augment traditional processes represents an evolutionary shift in how the world works.

Finding balance in a world of shifting supply chains
Logistics (Industry) Integrated Solutions Products
Retailers and consumer goods manufacturers need precise demand planning now more than ever. With help from the AI-powered SAS Intelligent Planning Cloud, companies can anticipate and address shopper needs and shipping disruptions more effectively.

SA banking sector chooses enterprise-grade ID verification
Financial (Industry) Access Control & Identity Management Integrated Solutions
In terms of the secure digital onboarding of customers, South Africa’s major banks have made massive inroads by using remote facial authentication.

The state of the biometrics market
neaMetrics Technews Publishing Suprema Hikvision South Africa IDEMIA Access Control & Identity Management Integrated Solutions
Now that the pandemic is over (hopefully), will we see the same confidence in biometrics for access and identification or will the world be reverting to touch-based systems, including cards and fobs (or mobiles).

Suprema development tools
Suprema Access Control & Identity Management Integrated Solutions
With integrating systems from different companies a critical part of an effective security solution, Suprema highlights its development tools aimed at making integration with its products simpler.

The future of touchless biometrics
Technews Publishing Fulcrum Biometrics Access Control & Identity Management Integrated Solutions
Facial biometrics is the main talking point today, helped along by COVID, but is it the best touchless solution available? Rob Griggs from Fulcrum Biometrics Southern Africa recommends other touchless alternatives.

The problem with biometrics
Technews Publishing Editor's Choice Access Control & Identity Management Integrated Solutions
We have come to rely heavily on biometrics for many aspects of access and identity management, especially in identity management where selfie authentication is accepted with confidence. Are we doing it right? Roger Grimes has his own take on the matter.

SuperVision biometric access control
Fourier IT Innovation Integrated Solutions
SuperVision is a time & attendance (T&A) biometric access control system Fourier IT has been developing and enhancing for 18 years.