Data infrastructure is invisible when it works well. At a well-functioning site, the data layer stays out of sight, and a Cx team can focus on the building’s equipment and performance. Cx team members want to know whether the AHU is short-cycling, how the chiller plant is sequencing, and what to make of a flagged trend that could be either a real fault or just sensor drift. Cx team members are rightly less concerned about how the data they need is made available. They notice when the data they require are not where it needs to be. Getting that data where it needs to be is the work ACE IoT does for our partners.

Our partnership with BES Plus Tech provides a clear example of what becomes possible once a data layer–even an invisible one!–is reliable.

Read More

Every engineering discipline has a theory of reliability. For civil engineers, it lives in load calculations and redundancy specs. Aviation earned its safety record through obsessive incident review. In the software industry, reliability has become the practice of assuming things will eventually break: what happens when you stop treating failure as an anomaly, and start preparing for it as a certainty? The answer to this question has become known as Site Reliability Engineering, or SRE.

SRE originated at Google in 2003 when Ben Treynor Sloss founded the first site reliability engineering team. The discipline produced the Google SRE Handbook, which sought to answer one question above all others: how do you keep massive, complex technology infrastructure running reliably when the people operating it are human?

Read More

One of the most common and costly frustrations in facilities management is the revolving door of service calls. A facilities manager calls a service contractor because the AC isn’t keeping up. The contractor sends a technician, diagnoses the issue, performs the work, and closes the ticket. A week later, an occupant complains again. The FM calls the contractor again. The cycle repeats.

From ACE IoT’s perspective, this cycle is a function of how building service relationships are structured. Most service contracts are built around hours and visits, with outcomes left unverified. The contractor is paid for showing up and performing work. Whether that work actually solved the problem in any durable way is rarely something either party can verify with confidence, because the data infrastructure to do so simply has not been part of the picture.

Read More