Skip to content
FREN

Our method

Our method

Knowledge of the site lives in a model that can be reread and regenerated.

Building integration is still largely done by hand: discovering the buses, creating the equipment and points, setting up hierarchies, alarm and history extensions, and virtual meters. This long, repetitive work starts again on every site. Our method starts from the project documents: the owner's brief, the specification and the sequence of operations are built into our study. These three documents define the expected operation of the installation and serve as the reference for validating it. The building is then described in a model: its spaces, its equipment, its points, what links them and what is expected of each. Working from that model, our agentic tools discover the field networks, create the equipment and points, project the model onto the stations, deploy, run acceptance tests and produce the documentation. The operator approves each step and the station logs it. Operating rules then check the installation continuously. When the contract ends, the model stays with you.

Engineering

A tool-driven workflow from discovery to acceptance testing

Our own agentic tools carry out the integration from a model of the building and leave a verifiable record of every action.

    • Discover the field networks

      BACnet, Modbus, KNX, M-Bus and LON are discovered network by network.

    • Create equipment and points

      They are created in the model and then on the station with your naming conventions. Every item of equipment gets its network test as soon as it is commissioned.

    • Model and project onto the stations

      The model is projected onto the stations. Alarms, histories and schedules are set portfolio-wide through a projection that can be re-run.

    • Deploy and run acceptance tests

      Acceptance testing compares the installation with the specification and the sequence of operations.

    • Document

      Documentation comes out of the model.

The model

A single source from brief to operation

The building is described once, exhaustively, in a model that every phase of its life reads: spaces, uses, equipment, what serves what, metering, distribution and relationships. Built during design and construction, the model is used throughout operation. It is written in an open vocabulary and projected onto your stations. This model is the base of the B(I)OS on which our services rest.

Description

  • Spaces and uses
  • Equipment
  • What serves what, metering, distribution

The site model

Delivery

  • Agents find their way
  • Analytics build on it
  • Services plug into it
  • Documents come out of it

Description

Delivery

Spaces and usesEquipmentWhat serves what, metering, distributionAgents find their wayAnalytics build on itServices plug into itDocuments come out of it
The site model

Verification

From sampling to full coverage and from one-off to continuous

The model describes the building. The rules describe its expected operation and check it.

Today

a few points on handover day

Checks cover a sample chosen in the time allotted to acceptance testing. Whatever was not tested that day never will be. Whatever drifts afterwards only comes to light through a complaint or the bill.

With our tools

every point after every change

Every point is checked against your project documents each time the installation changes.

Ownership

The model stays with you

When the contract ends, your data, your histories and the configuration come with it. You regain knowledge of your buildings and of how the systems that run them work. That knowledge remains yours even when your installers change.

When the contract ends

The model

  • Your data
  • Your histories
  • The configuration

FAQ

No. Nothing is written without the operator: the operator approves every write and the station logs it. The agent handles the repetitive tasks and the documentation work. It does not control the installation.

Against the project documents: owner's brief, specification, sequence of operations, CCTP (the French technical specification) and points lists. In the model, their requirements are attached to the equipment, points and sequences they concern to allow a point-by-point comparison.

Field discovery covers BACnet, Modbus, KNX, M-Bus and LON network by network and reaches up to your IT systems.

It is regenerated from the model. The as-built documentation is revision-controlled: you know which version you hold and what has changed since.

No. The RD model is tagged in Haystack and exports to both Haystack and Brick. At the end of the contract it stays yours along with your data, your histories and your configuration.

A transition is the passing of responsibility between two phases, from planning to construction or from commissioning to operation, where someone has to prove something to someone else without having the evidence: that the sizing is right, that the installation complies, that the documentation is usable, that the reported performance is real, that an investment will pay off.

Because the requirements of the specification and the sequence of operations are attached in the model to every item of equipment and every point. The whole installation can then be checked against those requirements after every change.

See the workflow in action

In a demo: the workflow run on an installation, extracts from the documentation and the approval log.