System integrator
System integrator
Your work is judged after you have left
You are asked to prove two things: delivery to specification and usable documentation. What happens to the installation afterwards is no longer your responsibility, unless a point cannot be written to, an alarm has not been configured or a drawing no longer matches. In the meantime, acceptance testing covered a sample chosen in the time allotted to handover and the documentation was frozen on the day it was delivered. These two pieces of evidence are the only ones you leave behind and neither can be re-run.
System integrators, installers, engineering and controls firms: you build, you run acceptance tests and you deliver the documentation. Then you leave when operation starts.
The model
The building described once, exhaustively, in a model that every phase of its life reads.
Situations
Our answers to four tasks that are costing you
- Proving what you delivered
Check point by point what should have been installed according to the project documents and produce a time-stamped report that can be re-run.
See our solutions
- Producing documentation that will be used
Produce from a building model documentation that can be regenerated after every change.
See our solutions
- Starting again by hand on every site
Describe once, project the model across the portfolio and re-run it: discover a Modbus network without entering it by hand, set alarms and histories from a single workstation, reach stations behind a firewall.
See our solutions
- Putting your agents to work on your projects
Put your own agents to work on your own projects with our MCP servers, our knowledge base and our procedures.
Learn more
Our approach
The agent on your projects
Our rdCoPilot MCP servers open a Niagara station or a SkySpark project to the assistant of your choice. During integration, they support engineering, assisted discovery, assisted commissioning and compliance checking. In operation, they support diagnosis and tuning. Every action that writes is approved by an operator and logged by the station. Signed procedures are first executed as a dry run and leave an audit trail.
Benefits
The gain on the next project
You start from work already done
The description and classification work done on one project becomes the starting point for the next. Time spent understanding a building is paid for only once.
You sign off acceptance tests you can defend
The report is time-stamped and names, for each point, the document it was checked against. If the installation changes, the report is run again.
The documentation does not come back to you six months later
It comes out of the building model. It keeps pace with the installation after the day it is delivered.
The standards
The RD model, Haystack and Brick
Our building model combines two open standards and exports to each of them.
The RD model
The best of Haystack and Brick extended to exhaustive coverage. It takes operational productivity from Haystack and formal rigour on relationships from Brick. Where each covers part of the building, it describes all of it.
Project Haystack
The open vocabulary of operations: tags, types and an exchange format. Niagara and SkySpark speak it natively. Tagged in Haystack, the RD model is read by these platforms without translation.
Brick Schema
The formal ontology of relationships: what feeds what and what serves which space. The RD model adopts its rigour and exports to Brick for the tools that require it.
rdModel, rdOntology, rdConverge
Our modules assign a type to each item of equipment (a type is declared once and applies across the portfolio) and project the model onto the stations, declaratively and repeatably: re-running the projection on a station that already complies changes nothing.
Projection
From the model to the station
The model is projected onto each station.
The model speaks neither Niagara nor SkySpark
It contains no prefix, no supervisor name and no tool convention. On that condition it describes your building and stays with you when the tool changes.
Translation happens in one place only
A single crossing point per platform. Translating in two places would create two vocabularies that would drift apart with nothing to flag it.
Each station receives its share of the model and the set-up is checked
The station that talks to the field, the one that federates the portfolio and the analytics engine do not expect the same thing. After set-up, what is on the station is compared with what the model asked for. The projection is re-run each time the installation changes.
Whatever the station contradicts goes back upstream
Let's talk about a project in progress
Tell us which platform and what stage you are at. The demo will start from there.