Services · System integration
Interconnecting analog, digital, and IP radio networks with the customer’s SCADA, BMS, and management systems.
We connect analog VHF/UHF, DMR, TETRA, and P25 networks, along with PTT terminals on the cellular network, to a single control room console. Device status, alarms, and measurements are made available in the systems the customer already uses, over SNMP, REST, Syslog, and LoRaWAN, and our own engineers develop the integrations.
A control room almost always runs systems that entered service at different times: an analog VHF network still in use, a newer DMR or TETRA network, the SCADA that governs the tunnel plant, the management system staff use to open and close fault reports. While these systems stay separate, the work falls on the operator. The operator watches several screens and retypes the same information by hand, and a repeater alarm stays logged inside the device alone, unread until coverage fails. The same site also appears under two different names on the two systems, so linking one report to another means a manual comparison every time.
Our job is to connect those systems. We start from an inventory of what is already installed and of the interfaces each system exposes. We put in writing the data to be exchanged and the shared naming of sites and devices. We develop the integrations ourselves and verify them in interoperability tests with the customer’s engineers before go-live. Each integration follows the cybersecurity requirements of ISA/IEC 62443-3-3 Security Level 2 and of the NIS2 directive, with TLS 1.3 and AES-256 encryption on Respondr and Track-TP links.
The three levels we work on.
An integration project almost always covers all three, from radio voice to the status data of the equipment.
Radio voice on a single console
We connect analog VHF/UHF, DMR, TETRA, and P25 networks and PTT terminals on the cellular network to the same operator position. The control room operator talks to every team without switching equipment.
Status and alarms into the customer’s systems
We make device status, alarms, and measurements available in the platforms the customer already uses, over SNMP, REST, and Syslog. Where no supervisory platform exists, we collect the same data in Track-TP.
SCADA, BMS, and telecontrol
We connect the radio networks to the systems that govern the infrastructure, from tunnel SCADA to building BMS: an alarm detected by the plant reaches the radio room, and a report from the radio room reaches the people who watch over the plant.
What we integrate, and over which protocols.
The systems we connect, grouped by type, with the interface used for each one.
PMR radio networks
- Analog VHF/UHF networks still in service, connected without replacing the equipment
- DMR Tier II and Tier III networks, including same-frequency simulcast configurations
- TETRA networks, with inter-system interconnection (ISI) where the manufacturer makes it available
- P25 networks, aeronautical VHF, and PTT terminals on the cellular network (PoC)
Control rooms and dispatch consoles
- Channels from different radio networks gathered into a single list on the operator position
- Audio routing between control rooms, with echo and acoustic feedback cancellation between positions in the same room
- Recording of every channel, searchable by radio ID, time, channel, talkgroup, and message content
- Team positions on a map, from the Android and iOS apps, from LTE radios, and from in-vehicle GPS trackers
- Links between several control rooms and to the channels of the emergency services
Standard IT protocols
- SNMP v1, v2c, and v3, both polling and trap reception
- REST APIs, both those exposed by our platforms and those of the customer’s systems
- Syslog for centralized collection of device events
- Dry contacts and relay outputs, for devices with no network interface
IoT sensors and LoRaWAN networks
- LoRaWAN gateways at 868 MHz and sensor registration on the LoRaWAN server
- Environmental sensors: temperature, humidity, CO₂, radon, and light level
- Structural sensors: vibration, tilt, load, and strain
- Operational sensors: vehicle counting, fuel level, and parking occupancy
SCADA, BMS, and technical plant
- Tunnel and route SCADA systems, for the exchange of status and commands
- Building BMS: HVAC, electrical panels, and access control
- Video surveillance systems, calling up the camera at the point the alarm came from
- Telecontrol systems for power, water, and gas networks
Customer management and supervisory systems
- Ticketing systems: the alarm opens the ticket and its closure is reported back on the monitoring platform
- Supervisory platforms already in use, receiving status and alarms from our equipment
- Aligned site and device registries, with the same naming on both systems
- Corporate single sign-on (SSO) and role-based profiles, with actions traced per operator
- History export to CSV and Excel for the customer’s own analysis
Custom-built integrations
- Analysis of the protocol and of the documentation of the device to be connected
- Format conversion: units of measurement, fault codes, and site naming
- Integration development with tracked versions, documentation, and automated tests
- Integration updates when the firmware of the connected device changes
Security and compliance
- Link encryption with TLS 1.3 and AES-256 on our platforms
- ISA/IEC 62443-3-3 Security Level 2 requirements applied to the integration architecture
- Compliance with the NIS2 directive (EU 2022/2555) for operators of essential services
- Our platforms installed in the cloud, on premise, or as a hybrid; in the cloud version the data stays in the customer’s country
How an integration project runs.
The cycle we follow, from the first inventory of the existing systems to live operation across every site.
- Step 01
Inventory of the existing systems
We list the devices, networks, and platforms already installed, the interfaces they expose, the documentation that exists, and the network and security constraints set by the customer.
- Step 02
Interface specification
We put in writing which data is exchanged and in which direction, over which protocols, under which naming for sites and devices, and what must happen when a link goes down.
- Step 03
Integration development
We develop the integrations to the customer’s systems in-house, with tracked versions, technical documentation, and automated tests on every change.
- Step 04
Interoperability testing
We verify the integration together with the customer’s engineers on a pilot site. We test every planned case, including loss of the link and restarts of the equipment, and we put the outcome on record.
- Step 05
Go-live and hands-on support
We extend the integration to every site, train the administrators of the connected systems, and work alongside the staff through the first weeks of operation.
What you receive.
The documentation and the components that stay with the customer, useful at acceptance testing and at security reviews too.
- Integration specification document
The list of the data exchanged, of the protocols used, and of the shared naming, agreed with the customer before development starts.
- Integrations built and documented
The integrations built for your installation, with version number, configuration manual, and recovery procedure.
- Interoperability test report
The list of the cases tested with the customer and their outcome, signed by both parties: it serves at acceptance testing and stays as the reference for later changes.
- API documentation
The specifications of the interfaces exposed by our platforms: message format, authentication methods, and example calls.
- Architecture and data flow diagram
The diagram of the links between the systems, with the networks and the ports used, useful for the customer’s security reviews as well.
- Administrator training
Sessions for the people who will run the connected systems, at the customer’s premises or remotely, on the system as actually installed.
Which sectors use this service.
The sectors that turn to this service most often.
Public safety
We design, build, and maintain mission-critical radio networks and control rooms for law enforcement, emergency medical services, and Protezione Civile: TETRA, DMR, and P25 networks, powered by the Respondr dispatch platform and over twenty years of experience in communications where failure is not an option.
Utilities and industry
We design, install, and maintain professional radio networks, ATEX-certified PoC devices, and LoRaWAN sensor networks for energy operators, utilities, and high-risk industrial environments. For clients like Iren, we bring over twenty years of experience in mission-critical communications.
LoRaWAN
We design, install, and maintain complete LoRaWAN networks — 868 MHz gateways, long-life sensors, and the Track-TP supervision platform — to bring field data into the platform reliably, affordably, and independently of the mobile operator.
Products used.
The products developed in-house by Teleproject that we use in this service.
- mission-critical dispatching platform
Respondr
Respondr is the software platform developed by Teleproject for managing mission-critical radio communications. An IP platform that unifies analogue, digital, and PoC networks into a single operational interface. Available in cloud on AWS, on-premises, or in a hybrid configuration.
TETRA · DMR · P25 · VHF/UHF · PoCTLS 1.3 · AES-256ISA/IEC 62443-3-3 SL2 - Web platform for infrastructure supervision
Track-TP
Track-TP is the platform developed in-house by Teleproject for real-time supervision of network equipment, servers, Mission-Critical radio systems, and IoT/LoRaWAN sensors. A high-quality solution with configurable dashboards, multi-channel alarms, and exportable history, available in cloud or on-premises.
SNMP v1/v2c/v3RESTLoRaWAN 868 MHz
Learn more.
Frequently asked questions.
The questions we hear most often about this service.
What does an already installed device need in order to be connected?
It needs a reachable, documented interface: a network port with SNMP, a REST API, event forwarding over Syslog or, on devices with no network interface, a dry contact. When the protocol documentation is not available, we request it from the manufacturer before development of the integration starts. The device must also be reachable from the network where the link is built, so we agree the addresses to allow and the firewall rules with the customer’s IT engineers.
Can a system be integrated without shutting down the control room?
In most cases yes. The integration is tested on a pilot site while the systems stay in service, and data flows into the live system only after the tests pass. Short operating windows still have to be agreed for work that requires restarting a device or changing firewall rules.
Who updates the integrations when a connected system changes?
Updating them is our responsibility. We develop the integrations in-house and we keep their versions, their documentation, and their automated tests. We ask the customer to tell us in advance about firmware updates and version changes on the connected systems, so we can test the integration against the new version before the update reaches the live installation. If the data exchanged changes, we update the integration specification document as well.
What happens if an alarm does not reach the connected system?
The first step is to establish where the flow broke: at the device that generates the alarm, on the network link, in the integration, or in the system that should receive it. That is why our integrations log events on both sides of the link and also report the loss of the link itself. The specification document agreed at the start of the project states who answers for each segment, so every check already has an owner.
Request a quote for system integration.
One of our Project Managers analyzes your specific project requirements and prepares a dedicated technical and commercial proposal.