Five questions to Arnaud JUDES, Sales Director and head of relations with equipment manufacturers for AREAL.
We are regularly approached by new entrants in the field of connected objects (IoT) or more traditional manufacturers who propose new sensors/communicating equipment for the instrumentation of drinking water networks and sewerage networks. Their objective is to be compatible with Topkapi because they know that many of their customers, local authorities or operators, are equipped with our solution. We talk less about communication networks (Sigfox, LoRa, NB-IoT, LTE-M, etc.) but more about communication protocols for integrating data into Topkapi: MQTT, OPC UA, Webservices or even flat file reading. It all depends on the strategy adopted by the manufacturer: direct link between the equipment and the supervision or data collected by a software platform hosted at the customer's premises or in the cloud with which Topkapi must be interfaced.
As early as 2017, we anticipated market developments by offering a communication protocol called scriptable from version 6.0 of Topkapi. It allows us to manage any data source for a flexible and scalable integration of the latter in our software platform. The term scriptable may be a bit daunting as it implies the need for computer programming skills (JavaScript language) to implement data acquisition. But this is a blessing in disguise! In reality, the scriptable protocol provides flexibility, adaptability and scalability to the needs encountered.
It should be noted that communication protocols such as Webservices or the MQTT messaging protocol are not standardised. For example, MQTT only standardises the transport layer but not the formatting of the data exchanged. It is therefore easy to understand why the acquisition protocol has to be adapted for almost every manufacturer. As the MQTT base is supplied with the scriptable protocol, all that remains to be done is to focus on decrypting the data.
The scripting can be done by the end customer himself if he has the skills, by a service provider of his choice or by us. We offer a skills transfer for the use of the scriptable protocol in order to understand the integration of the data in Topkapi. However, I would like to point out that we do not train in JavaScript: this is far removed from our job as a publisher. Note that these new modes of communication take into account security, HTTPS for Webservices, TLS or SSL (data encryption) for MQTT. As for OPC UA, the standard natively integrates authentication and data encryption. OPC UA is now native in Topkapi, either as a client or as a data server.
There have been many of these since 2017. For example, for the Gessian Water Authority, a Webservice has been scripted in Topkapi to interface with the Sigfox backend (web portal). It allows the acquisition of data from Ijinus equipment (instrumentation of the sewerage network) or Connit (for remote meter reading).
There are also many examples of Webservices: Vigicrue or Météo France type data platform, Link2Valves proprietary Web platform for CLA-VAL's communicating valves or interfacing with Orange's Live Object portal (LoRA operated for communication) which also offers an MQTT connector to make data available.
The communication of the very recent DeltaX IoT equipment from Perax is based on MQTT: the script was written by the manufacturer on the basis of the scriptable protocol and then packaged by us and made available for all licences (recent version) equipped with the Perax protocol.
We notice that our users tend to collect more and more data. As a result, there are more processing needs: we are on the wave of Big Data and Data analysis. With Topkapi - one of whose main functions is data collection - we try to meet all the customer needs:
*KPI = Key performance Indicator
