The Topkapi object structure as seen by IP France

In what context did you start using Topkapi’s object structure?

After following AREAL’s initial training course on Topkapi and implementing our first “flat” applications, i.e. without any object configuration, we were asked to work on a Topkapi application created by a colleague. That application was carried out entirely in structured logic and highlighted the benefits of this type of approach in terms of time savings, both in the development of the application and in its deployment. When assessing the scale of the work involved in adopting this approach - there’s a fairly substantial initial investment but real time savings later on - we took advantage of the slowdown in activity during the COVID period to create a library of structured and graphical objects that we would use for all our future applications. 
 

What elements does this library of structured and graphical objects contain?

Our library of structured objects includes a complete inventory of the basic equipment found in water treatment (pumps, valves, sensors of all kinds, etc.). We have even gone so far as to develop nested objects, enabling us to offer more complex objects composed of basic objects.
 

In your experience, what are the benefits of standardisation with Topkapi’s object structure? 

The benefits of standardisation are numerous:

• Time is clearly saved in application development and deployment. The second component is not to be neglected, even if it is less spectacular than the first, in the sense that the models have to be adjusted regularly to meet the needs of the field.
• Insofar as the objects are already tested and proven beforehand, this avoids input errors when instantiating the objects and linking them to the communicating equipment - and when generating synoptics and alarm sequences.
• Standardisation obliges automation technicians to adopt a certain rigour in the rules for naming and addressing variables in order to obtain a consistent database. It also helps to create habits for electrical engineers carrying out repairs.
• Applications belonging to public operators evolve as work is carried out in their area (creation of a pumping station, deployment of a sectorisation system, etc.). These are entrusted to a variety of service providers in accordance with public procurement rules. Standardising supervision applications avoids ending up with a patchwork of different approaches to things that would be difficult to maintain.
   

What are the advantages of this object structure, particularly for integrators?

As an integrator, we develop an average of two to three new Topkapi applications per year: our business layer allows us to be competitive on these new projects from the outset. What’s more, the benefits of object logic really come into their own when you consider the notion of the installed asset base. Once the applications are up and running, it is rare for an operator to be completely autonomous when it comes to managing changes due to the addition or removal of facilities, whether in the drinking water or wastewater sectors, not to mention changes in regulations. As a result, we are very regularly called upon to develop new applications. In this scenario, and with an ever-expanding fleet of licences, all time optimisation factors are welcome: Topkapi’s object-based configuration makes this possible.