Edge server and architecture

01A separate machine in the building

CX2 can in principle run on a virtual machine in the customer's own environment. We still prefer a separate, physical machine in the building, for four reasons.

• It can sit in the right place. The edge server has to reach the technical network, where the building management system and the meters are. That is rarely the same network the operations team's office computers sit on.
• The responsibility is clear. A physical machine can be sold, handed over and owned. It can be taken out and put back, and it is obvious who looks after it.
• It does not depend on someone else's platform. If CX2 runs as a guest in the customer's virtualisation, it follows along when the platform is upgraded, moved or replaced, and that is rarely planned together with operations.
• Faults stay contained. A machine that does only one thing can be restarted and debugged without touching anything else.

It is not a requirement. If the building owner would rather supply the hardware or run CX2 virtually, it is an ordinary Linux installation, and it works. The recommendation is a recommendation.

02The local software stack

Three things run on the edge server, each with its own job. They are deliberately separate, so that one can be replaced without dragging the others along.

The collection

The part that talks to the building's technical systems is called Bricklogger. It reads the building's semantic model, works out which points to fetch, and fetches them at fixed intervals. The first protocol is BACnet/IP, with Modbus and others to follow. See Protocols.

It runs as a background service with its own configuration in ordinary text files, so an operations manager can see what is being collected without going into a user interface.

The storage

The measurements are written to a time-series database on the machine's own disk. That is the only place the primary operational data exists. See section 07.

The model and the access

The semantic model sits as a file on the machine and describes what the points mean. See Semantic modelling with Brick Schema. On top of the database and the model sit the documented interfaces that dashboards, reports, analyses and other tools use.

The same local installation collects, stores, describes and hands over. There is no hidden step in the cloud in between.

03The hardware requirements are modest

An edge server does not do heavy work very often. It fetches a number of measurements at fixed intervals, writes them to a database, and answers queries when someone asks.

Even a building with many thousands of points produces a volume of data that an ordinary small computer handles without getting warm. Compared with video calls and heavy Windows software, the Linux stack is in the lightweight class.

The heavy part is not the collection. It is the database when someone asks a question that reaches a year back, and the analyses if they run locally. Those are what the sizing has to account for, not the number of sensors.

04What we recommend

If the choice is ours, we choose a fanless mini PC rated for round-the-clock operation. We use light machines with at least four processor cores, 16 GB of RAM, an SSD and two network ports.

Fanless

A machine without a fan has no moving parts at all. It makes no noise, it does not pull dust in, and it has no filter for someone to remember.

At least four cores

The collection runs all the time, including while someone puts a heavy question to the database or runs an analysis. With four cores those three things can run at once without waiting for each other. One goal for an edge server is that the data collection never misses an interval because something else was working.

16 GB of RAM

Memory is where the database notices the difference. It uses it for indexes and for keeping frequently requested data ready. 8 GB can be enough, but the difference in price is small, and the difference in how long the machine copes with being used more is large.

SSD

A time-series database writes small amounts often. That is exactly the work an SSD is good at, and a spinning hard disk is bad at.

05The two network ports

The recommendation that matters most for security is the one that looks smallest: the machine should have two physical network ports.

One port sits on the technical network, where the building management system, the controller cabinets and the meters are. The other sits on the network that connects onwards, either the building's administrative network or a connection set up for the purpose.

The benefit is that the edge server can reach the technical network without the technical network thereby being reachable from outside. Traffic does not pass through the machine by itself. One side fetches data, the other side passes it on, and the machine decides what may go between them.

The alternative, a single port and a VLAN, is also possible and is often what already exists. But two physical ports make the separation visible to anyone looking at the installation, and it cannot disappear through a misconfiguration. See Technical network.

06Linux and operation

The edge server runs Linux.

• A Linux server runs without a screen, a keyboard or a logged-in user, and it restarts by itself after a power cut.
• Security updates arrive for a long time and predictably, and they can be installed without anyone sitting in front of the machine, and without the machine having to restart.
• There is no licence to renew and no activation that can expire on a machine in a plant room.
• The tools for seeing what is running are the same as on any other server, so an IT department can look for itself.

The components run as ordinary services on the system, start in the right order and come back up after a restart. Configuration sits in text files and data in fixed directories, so a backup can be taken without knowing the system from the inside.

If the building owner chooses CX2 Care, CX2 handles the updates. Without Care the owner's own IT department can do the same, because it is an entirely ordinary Linux server.

07The database

The measurements live in TimescaleDB, a time-series database built on PostgreSQL.

It is an entirely ordinary SQL database. The building owner can connect with the tools already used for databases and pull data out with SQL. There is no proprietary format in between, and no licence has to be bought to read your own numbers.

It is built for the kind of data a building produces. Many small measurements in time order, which have to be summarised over a day, a week or a year without reading everything through each time.

The database sits locally on the edge server. It is the source, not a copy.

Access to your history does not depend on you continuing to pay anyone.

08Remote access and backup

Two things have to be able to get in and out of the building: CX2 has to be able to service the installation, and the data has to be secured. Both go through the same kind of connection, and the principle is the same.

The connection is established from the inside

The edge server itself opens an encrypted connection outwards, through a VPN tunnel. No ports are opened into the building, and there is no service on the edge server that can be reached from the internet.

The tunnel is also limited: it allows the communication that is necessary, and no more. A connection that can be used to service an edge server should not be usable to reach the building's technical network.

Backup

Over the same connection, an encrypted backup of both data and configuration is synchronised. The purpose is not only to survive a disk failure but also theft, fire and water, which is why a copy sitting next to the machine offers little protection.

Where the copy lands is agreed specifically. It can be with CX2 as part of CX2 Care, and it can be somewhere the building owner chooses.

CX2 Care covers monitoring of edge devices, integrations and data logging, backup of data and configuration, ongoing updates and technical support. See CX2 Care.