printer friendly version

Real system integration

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.

Share this article:

Further reading: