What is

This post is also available in: English French

Share on linkedin
LinkedIn
Share on twitter
Twitter

For many years, the physical security field remained proprietary. Each manufacturer developed and used its own software and protocol which had the ability to manage only the hardware from their own range. So when you visited a control room in the 1990s, one thing was obvious: a multitude of screens and software dedicated to each system. It was impossible for this diversity of equipment installed on a site to exchange data between each other due to a lack of interface. It was only in the mid-2000s that the notion of openness and interfacing began to appear. In the same way that IP technology began to replace the analogue one, this new way of conceiving security management then spread until it became a necessity. A large number of stakeholders now claim to offer open platforms.

But what is really an open platform?

The purpose of this publication is not to provide an absolute answer to this question, nor to argue about the relevance of the views already expressed on this subject, but rather to give our vision that guides our policy and in particular the development of our platform AppVision™.

OPENNESS & INTEROPERABILITY: DEFINITIONS

This transition from a world split into silos to an interconnected ecosystem has a simple origin: the end customer, through the need to simplify his control room and the necessity to value the investments made.
These end users were facing with two situations:

In the first case, for each technology (CCTV, access control, intrusion), end-users had heterogeneous systems that could not communicate with each other. An example: a smoke detector triggers an alarm and transmits it to the fire monitoring software. The operator receives the information, but does not have a visual to confirm it. He must look on another screen, the one dedicated to video, find the camera closest to the detector on alarm and check it. This configuration generated operating difficulties and additional costs associated with the need to have operators trained with all systems.
In the other case, the client would choose a single brand to facilitate operations. However, when he wanted to upgrade his installation by adding a new technology, he was facing a dilemma: keep on purchasing from this manufacturer even if he did not have all the desired feature or choose a third-party application, losing interoperability within his installation.

These new challenges in the security market have forced stakeholders to move in this direction. All of them have now integrated this need for openness into their products.

To the point where, after these years of transition, a large majority of them claim to have an open platform.

Below are the definitions of an open system or application that is commonly found:

« A system that has an API or SDK type entry point to develop interfaces called drivers to connect and communicate with third party systems
and
«A system that works natively with standard protocols »

We can see that the notion of openness is deeply linked to interoperability. If you connect two systems together, it is to have them interact, i.e. retrieve and/or transmit data or commands.
The level of interoperability between two connected systems therefore depends on the possibilities offered by the interface of each system.
To assess the level of openness of a system, one must look at the interoperability possibilities it offers: does it allow access to a majority of features and information? Or just to a very limited number of functionnalities?

OUR VISION OF OPENNESS

As an open platform software editor, creating interoperability is our raison d’être. From our point of view, openness means first of all maximizing the possibilities of our SDK*. As an input, it retrieves from a third-party system all available events. As an output, it also allows us to expose all the capabilities of our platform to another system. The opening of an SDK is the ability to interface with any system or application that has a protocol.
Our vision of openness goes far beyond that: it means ensuring that our platform, AppVision™, is 100% customizable and that our partners are 100% autonomous.
This is why we share with our partners all the tools needed to customize our platform and extend it both on the client side and on the server side to:

  • Create the most user-friendly GUIs for operators
  • Develop the communication drivers they need
  • Develop the necessary functionalities to meet project specifications without requiring access to and modification of the source code
  • Develop specific extensions adapted to our partners’ businesses or sectors of activity

*A Software Development Kit (SDK)

HOW DOES THIS WORK IN APPVISION™?

At Prysm Software, we focus on the development of AppVision™, associated training, ad hoc technical support and driver development. The projects are carried out by our partners.

Openness means encouraging our partners to adapt AppVision™ to create maximum added value and return on investment for their customers.

It also means providing them with all the tools, including the configurator, the scripts, the links engine and the SDK, to develop their own OEM version of AppVision™ at no extra cost, thus ensuring the success of their projects or the development of business in a targeted market.

The openness is also a guarantee to the end customer that he does not have a specific version that can only be maintained and modified by the partner who supplied it. Indeed, customizations are never done with the source code. They are realized thanks to tools that are accessible to everyone.

Openness means choosing a business model that reassures our partners: we will never compete with them on projects.

Openness also means simplifying the implementation of the software as much as possible and ensuring that its configuration can be handled by a very large number of people and not just by few experts.
It is a commitment to our partners and their end customers that they can rely on a community of users to support them in their projects and, if necessary, to provide specific developments. All this, in total independence from Prysm Software.

Finally, openness means promoting and encouraging the emergence of a technical community within which each partner can promote its developments in AppVision™ and find the information and resources needed to achieve its projects.

As you have certainly understood, the notion of openness for us is much more than a necessity to respond to a market challenge of interconnecting and interoperating systems. It is a philosophy, at the root of Prysm Software’s fondation, which has been perpetuated until today and will continue tomorrow.