The EDE file: the points
list you can check

Your installation can write the list of everything it contains, by itself. The file has existed since 2004, it fits in a spreadsheet, and almost nobody asks for it.

A file the installation can write on its own

EDE, for Engineering Data Exchange, is a spreadsheet listing every BACnet object in an installation: one row per data point, four sheets in all. There is nothing mysterious about it, and that is exactly what makes it useful.

The BACnet recommendation issued by KBOB — the coordination conference of the construction and property services of Swiss public clients, which includes the Federal Office for Buildings and Logistics, armasuisse and the ETH Domain — places it in a single sentence, in its July 2021 edition: the EDE list “is not defined at standard level, but corresponds to a recommendation published in 2004 by BIG-EU”. And it adds the essential part: these lists “can be produced by automatically reading the BACnet functionality of a planned BACnet device”.

Automatic reading. That is the whole point.

The points list attached to a tender is a statement of intent: what somebody intends to deliver. The EDE generated from the installation is a survey: what actually exists, under the names actually written into the controllers. Two documents that look alike and are opposite in nature. Comparing one with the other takes half a day and requires no site visit.

Seventeen columns, five of them mandatory

The official template is published by the BACnet Interest Group Europe. Its layout version — the field reads Version_Of_Layout in the file header — is 2.3, dated 16 January 2017. KBOB recommends not going below it: “It is recommended to use at least version 2.3 of the BIG-EU EDE files.”

That template provides seventeen columns. Only five are mandatory.

The consequence is direct, and it is the one to remember: a perfectly compliant EDE file may contain nothing but numbers. Five columns filled, twelve empty, and the document is valid. It then says neither what the point measures, nor in which unit, nor between which limits, nor whether it is alarmed.

Demanding “an EDE export” is therefore pointless. What works is demanding the optional columns. That is one line in a specification, not a negotiation.

What EDE does not do

Better said straight away, because it is sometimes presented as a universal exchange format, which it is not.

It is not normative. It is an interest group's recommendation, not a chapter of the BACnet standard. Its latest version dates from 2017 and has not moved since.

It is incomplete by design. KBOB is explicit: EDE lists “contain simplified and incomplete information” and “are useful when more complete information is not available”. It is a survey, not documentation.

It describes no logic. Not the programs, not the interlocks, not the schedules, not the curves. It says what exists and what it is called — never what it does. A building entirely described in EDE is still a building whose control strategy is unknown.

It holds no values. It is not a historian, and it does not replace a data export.

Finally, the template itself carries its authors' warning: the EDE file “was never intended to provide a machine-to-machine data-exchange format” — and it is used for exactly that everywhere. In other words: it works, but it promised nothing.

Three moments where it changes something

At tender stage, it turns an appendix into a template. Instead of describing the points list in prose, the client issues it in EDE format, with the columns it requires filled in. Bids come back comparable, row by row, with nothing left to interpretation.

At integration, it avoids re-keying. Common head-end systems import an EDE file to create their points. On an installation of a few thousand objects, the difference between an import and manual entry is not up for discussion — and what is imported contains no typing errors.

At handover, it becomes the only document that can be checked against another. You read back the EDE exported from the installation and compare it with the one from the tender: missing points show up, added points too, and so do non-compliant names. That check is mechanical. No other document in the BMS file allows it.

That is where the real time saving sits. Not in the file itself, but in the back-and-forth it removes between commissioning and the first year of operation.

The gap EDE does not fill: the names

An unpleasant detail, better known before signature than after.

The KBOB recommendation explicitly excludes from its scope “the designation of data points and the numbering concept”. And its chapter on object names says it plainly: “No rule is prescribed for assigning object names.”

In other words: the Swiss reference recommendation organises the protocol, the device profiles and the string lengths — Object_Name at 64 characters minimum, Description at 128 for a management and operating unit, UTF-8 character set mandatory — but it deliberately leaves the choice of names to the project.

If the client does not impose its own naming convention, every integrator will apply its own. The building will then speak two or three languages, with a faultless EDE file documenting all three.

The seven checks to run on an EDE file you receive

1. All four sheets are present: EDE, State-Texts, Unit-Texts, Object-Types. A single sheet delivered is a truncated file.
2. The header is filled in: project name, version of the reference file, date and author of the last change, and Version_Of_Layout at 2.3 or above.
3. The optional columns required by contract are actually filled in — not merely present. An empty column across 4,000 rows is spotted in a second in a spreadsheet.
4. Every referenced unit and state text exists: every unit-code used in the EDE sheet appears in Unit-Texts, and every state-text-reference in State-Texts. Otherwise the import into the head-end will produce points with no unit and no text.
5. Object names follow the client's naming convention, throughout, with no exception tolerated “for the subcontractor's few points”.
6. Descriptions are written out, beyond the abbreviation stage. That is the text the operator will read for twenty years.
7. The number of rows matches the contractual points list. Any discrepancy, either way, is justified in writing.

What we do before the checking starts

A checker is worth nothing without a rule to enforce. So that is where we start: we write our clients' own data point naming directive, based on the KBOB BACnet recommendation — precisely where it stops.

It is not a template copied from one project to the next. A client owning forty buildings already has thirty-eight of them named, often in three different ways, and its operator has been working with its own markings for fifteen years. A naming convention that required renaming everything retroactively will never be applied: it will end up as an appendix nobody opens. The directive is therefore built on the existing estate — what is already in place, what can be carried over, what is left behind, and what applies to new installations only.

Once written, we make it hold, and that is where the real work lies:

• we build the tools that check it — the EDE checker below is one of them;
• we advise the client on what its choices commit it to, before they end up in a tender;
• we support the integrator during the project, so that what is delivered matches what was written — the point is not to catch an integrator out at handover, it is that it has no reason to be caught out.