Protocol fragmentation is something that many vendors of Alarm Management System (AMS) or Alarm Receiving Centre (ARC) platforms are facing today. Across the alarm and security industry numerous different protocols are used for alarm communication between devices and AMS or ARC platforms. For the vendors of such platforms, developing support for these protocols can be a significant challenge.
In social care for example, platforms need to handle SCAIP, NOW-IP as well as legacy analog protocols like BS 8521:2009 and many more. Step into the lift industry, and you encounter protocols such as CPC and P100. Fire systems have yet other protocols, as do various security systems.
Each protocol represents not just a format, but a domain-specific logic, certification requirements, testing and verification, potential vendor-specific protocol interpretations, and ongoing maintenance burden. It takes deep expertise in each of these protocols to understand how they work.
Many modern AMS/ARC platforms standardize around the SIA-DCS protocol. It provides a reliable, structured way to receive and process alarms. But the reality is that the devices generating alarms rarely speak the same language.
This makes it hard for vendors of alarm management or alarm receiving platforms, or even operators of alarm response centers, to expand their business beyond the alarm or security use case they were initially built for.
To expand into a new vertical, or just a new use cases within the existing segment, platform vendors must continuously develop support for new protocols. That means development effort, testing, compliance work, and long-term upkeep. This approach becomes resource-heavy and requires deep domain knowledge. Instead of focusing on innovation and service quality, vendors are pulled into an ongoing protocol support demand, which is not their core competence.
A faster, and more cost-efficient approach is to use a cloud-based service between devices and the alarm platform to act as a protocol translator and converter. It can receive alarms from a wide range of devices – across verticals and protocols – convert and forward them in a format the AMS/ARC platform understands. If native protocol support isn’t available in the platform, alarms can be delivered via API integrations instead.
In practice, this means that:
As the number of connected devices continues to grow across many sectors, decoupling protocol support from the AMS/ARC platform itself can be the way forward for vendors wanting to reduce the burden on their in-house development team.
This kind of architectural shift significantly frees time and resources that can be used for service innovation and increasing customer experience instead.
At iotcomms.io we’re offering the Alarmbridge Service which has exactly the task to bridge between different protocols, as described above. It is a cloud services that has a number of protocol interfaces already built in and can immediately enable protocol interoperability.
The service is built with an event receiver and event sender design making it easy to customize the protocol-in and protocol-out combination needed for a specific customer’s use case. Numerous protocols as well as API integration are supported.
Curious of which protocols are currently supported?
Take a look at the list of event receivers and senders here!
