XML or JSON: in what format do the data reach your site supervision system?

The specification is signed, the supervision system works, the alarms reach the control room. Then a device has to be replaced and the new one presents its data in a different format — while staying compliant with the same series of standards as the old one. From that moment the question is not technical. It is who pays for the piece in between.

On 10 April 2025 the part furthest upstream changed language

ETSI ES 202 336-1 V1.3.1, Generic Interface, was published on 10 April 2025. It is the part all the others cite normatively: it does not describe equipment, it describes how equipment speaks to the supervision system. On the Work Programme it is work item RES/EE-02105, status Publication at 10-04-2025, not harmonised, supported among others by Orange and Telecom Italia. The previous edition dated from July 2011. The ITU twin is Recommendation ITU-T L.1395 (07/25), in force since 29 July 2025.

The change history is a single line: “Added parameter definition and parameter accuracy. Delete references to XMLand give possibility to use different communication protocol” — the missing space is in the original. The work item record says why: “protocols instead of outdated ones (e.g. xml -> RESTful HTTP-based/YAML/JSON payload (or NetConf/YANG) etc.)”. The method has two stages: “protocol-independent information modelling”, then “protocol-specific data modelling e.g. in YAML/JSON”. What a device has to say does not change. The language it says it in does.

The obligation applies only to new interfaces

This is why nothing shows from inside a plant already running. In the normative body there is one requirement on the protocol, and it is narrow: TCP/IP “shall be used for new interfaces with REST mechanism to exchange formatted data at application layers through HTTP services and HTTP parameters” — for new interfaces. Nobody is obliged to touch what already runs.

For existing plant the way out is set out with a shall: “To keep the existing supervised power and cooling equipment without changing their output interfaces (i.e. old CU), adding a DGU that converts old CU protocols towards Ethernet XML.” A translator in the middle, to be bought, configured, tested and maintained. The document says it can be done, not who pays for it.

The old format has not been taken out of the text

Clause 10, which defines the data structure and lays down “some rules which shall be respected”, is still written in XML: the table datatypes are xs:string, xs:integer, xs:complexType, that is XML Schema types, and events work like this: “When an event happens on a site, a part of the full xml file, with the relevant information, is sent to the NMS, with an HTTP POST over TCP/IP.” Annex E is still entitled Overview of the XML format.

And here is the detail that matters most: in V1.3.1 no annex is normative. Annex A, on the REST mechanism over HTTP, is informative, and so is Annex G on the common API — “A secured RESTful HyperText Transfer Protocol (HTTP)-based communication is recommended”. The new format is recommended, not imposed; the old one is still in the body. A supplier can sit on either side and call itself compliant.

Two generations of format on the same site

Seventeen months on, the picture is checked by opening the PDFs one by one.

Parts 2 to 10 — from direct current to inverters, by way of UPS and standby generators — all nine carry a normative annex entitled “Mandatory XML structure and elements”. In part 3 it is Annex D: “Annex D standardizes XML coding structures for these data”. None has been withdrawn or amended: they stand as published, between 2009 and 2014.

The two parts revised in 2025 do not: part 11, of 26 September 2025, has no XML annex. Part 12 (RES/EE-02106, Publication at 11 September 2025) writes it into its own change history: “removed accuracy and sensor description as moved to part 1, delete reference to XML”, and declares its tables in “natural language”. Measurement accuracies went the same way, into part 1 — ±3 % between 25 % and 100 % of maximum load, ±5 % between 5 % and 25 %, voltage ±1 %, temperature ±1 °C — and anyone invoking them by citing part 12 now points at a document that no longer contains them.

The practical outcome: a UPS compliant with part 3 has a mandatory XML structure; an ICT device compliant with part 12 has no prescribed format at all. Two compliant supplies, two languages, one site. Where the UPS topology already decides what reaches the supervision system, it now decides the shape it arrives in too.

What to write into the specification, what to check at acceptance

The applicable part with version and date, not the series: ES 202 336-3 V1.1.1 says something, compliant with the ES 202 336 series says nothing.

The exchange format named: the XML structure of that part’s normative annex, or a JSON or YANG payload over HTTP, with the field schema handed over with the equipment. The clause is one the document asks for itself: “At a minimum, full details of the interface (data, protocol, format) shall be provided without any restriction.”

Who pays for the mediation: if the supplier changes format during the contract, or if a new device brings a different one, the conversion unit and the reconfiguration of the supervision system stay at its expense. It is the line almost no specification carries, and the one that decides whether you pay for the migration.

At acceptance you do not read the declaration: you pull a real data document off the delivered equipment and check that the format is contractual, that every mandatory field is there, and that the supervision system reads it with no adjustments made by hand. The same holds for an entry that part 11 does not make mandatory: if you asked for it, it has to arrive, and arrive readable.

What we do not know

We have read ES 202 336-1 V1.3.1 in full, 73 pages, downloaded on 21 September 2026, and opened the annexes of parts 2 to 12; number, title, version, date and status are checked on the ETSI Work Programme. Of the ITU twin L.1395 we have checked the catalogue record, not the text. We do not know when parts 2 to 10 will be revised: part 9 has a revision under way, at early draft on 12 June 2026. We do not know what format an individual product delivers today: that depends on the device and the contract, and we qualify it for nobody. The IEC standards cited are paid documents — including IEC 61557-12, which ETSI calls more accurate than its own requirement: we have not read them. An ETSI Standard binds where the contract invokes it: we have not checked whether any Italian provision makes it compulsory in network procurement.

The two axes, on a format that can change

First axis: in the specification we vet the exchange format stops being implicit — part with version, encoding named, schema handed over, the burden of mediation assigned — and at acceptance a real data document is pulled off the equipment and put in front of the supervision system, with the report and documentation handed over with the plant.

Second axis: a site with two generations of format is a site where half the data cannot be compared with the other half. With CSIDIA, the other company in the group, readings, alarms, events and logs from the various devices are normalised once and become a single map of the site, where an AI reads the series — the field that vanished after a replacement, the alarm the new device names differently — and the team steps in before the data you need goes missing. It runs on-premise or in a dedicated cloud with data centres in Italy, for a network exchange as much as for a public body’s data room.

A site visit, at no cost, produces the list of the devices feeding your supervision system: which part each is declared compliant with, in what format it delivers data, whether the field schema exists in writing, and who would pay for the translator. Talk to one of our engineers: a format makes no noise when it changes, only the first time you need a value and it does not arrive.