April 2022 |
[an error occurred while processing this directive] |
What is an Independent Data Layer? How does it work? And why the heck should you care? |
Andy Frank Founder & Principal Novant |
Articles |
Interviews |
Releases |
New Products |
Reviews |
[an error occurred while processing this directive] |
Editorial |
Events |
Sponsors |
Site Search |
Newsletters |
[an error occurred while processing this directive] |
Archives |
Past Issues |
Home |
Editors |
eDucation |
[an error occurred while processing this directive] |
Links |
Software |
[an error occurred while processing this directive] |
Maybe
you've heard of this new thing: the “independent data layer.” But what is it?
How does it work? And why the heck should you care?
Think
of all the things you do today in buildings. Or maybe all the stuff you wish
you could do. What is the first requirement in almost every case?
Data.
We
increasingly depend on data to make our buildings better, safer, and smarter.
It's the foundation for much of the technological advancement in our spaces.
Now
think about how data is acquired and maintained in your buildings today. Where
is it stored? How would you access it? Can you get a live feed from your
sensors? What about trend logs to see those values over time? Can you write
back into your controls? Any kind of semantic tagging to identify points?
If
that seems like an awful lot of questions for such an essential layer in our
buildings, you're not alone.
We've
generally been left to cobble together data solutions on our own. And those
solutions run the gamut from repurposing expensive enterprise software down to
hacking together data loggers from Raspberry Pis.
Enter the IDL
This is where the
Independent Data Layer (IDL) comes in.
The IDL has emerged to
solve these exact challenges. Purpose-built to provide a reliable and
straightforward solution for not just extracting data from buildings systems.
But also for managing storage and access.
This is a bit of a new
concept for this space. The IDL is infrastructure. It does not provide end-user
value on its own. Instead, it enables value. If a building invests in a proper IDL, it can reap substantial
benefits for every new application added. Not to mention significantly
improving how it maintains the systems it already has.
Consider an existing
building with controls but no FDD. The owner wishes to add analytics via an
outside consultant. What would this process look like if there is no IDL in
place?
First, they would work
with the controls contractor to (hopefully) get some level of access to the
existing BMS. Then, not knowing much about the building, they pour over all the
point data to decipher what is what. Then they discover trending was never set
up, so there is no history. In the best cases, weeks have passed. More
typically, months.
Notice what hasn't
happened? Any analytics. No value has been created — just busywork. Now imagine
the owner wants to add another application. The whole process repeats. Again.
Contrast this with a building
that has an IDL. The owner logs into his web browser and grants a new unique
API key for the FDD consultant. In this case, it's a read-only key and
restricted to just the HVAC system.
The consultant starts
pulling and exploring data over the API using a well-known format such as JSON.
Or even better, they have IDL support already built-in to their tool of choice.
Now they are generating
actionable data on day one.
This is the power of an
Independent Data Layer. It substantially reduces the cost of integrating new
technology into buildings.
It's also the first
step in knocking down silos in buildings. Freeing the data allows us to create
a single storage layer for all applications to build from.
So what else can an IDL
provide?
Protocol Normalization
Most
IDLs will present data using a normalized format — typically JSON. There is no
need to worry about the underlying protocol, such as Bacnet or Modbus. Even
when multiple protocols are used in a building, from an IDL user's standpoint,
it doesn't matter. All points are accessed the same way. This normalization
alone can significantly simplify how anyone integrates into their building
systems.
Protocol
integration becomes the IDL vendor's problem to solve. And as time goes on,
they will continue to broaden what kinds of devices they can communicate with.
Managed Storage
Another
benefit of IDLs is managed storage. If you've ever grappled with trying to
store gigabytes of historical trend data, you'll appreciate this. Think DropBox
for building data. An infinitely scalable storage space that is highly
available and automatically backed up.
While
some applications may still require importing this data into their system, you
can expect a transition to requesting data on-demand directly from the IDL over
time. This reduction in storage requirements further simplifies the
responsibilities of downstream value-added tools.
Semantic Modeling
The
IDL provides a logical place for standardizing semantic meta-data, such as
Haystack or Brick. Once we have a single place to store all our data, it only
makes sense we model it in one place too.
How
much modeling an IDL supports will range across vendors based on how much
information they have access to. Basic systems may only model individual
points. But if structural or spatial data is present, relationships and full
digital twins are possible.
By
making these models readable by their API, downstream apps can pull in
ready-to-use designs for their building. Imagine if firing up your FDD software
was as simple as opening an Excel document.
Extend the Life of Existing Systems
An
interesting thing happens when you expose the functionality of a building
system to the cloud from your IDL API. You gain the ability to program things
externally. More sophtiscited analytics and optimization. More predictive
control. AI/ML intelligence. These services can run anywhere, and only the
results need to be written back to the system.
By
leveraging cloud services to improve our buildings, we are less dependent on
updates to the on-premise systems, which can be expensive and time-consuming to
upgrade.
Maybe
you don't need to upgrade that BMS? What solutions can we provide to complement
existing systems and extend their lives well into the future?
Future Proof your Buildings
The
flip side of extending legacy systems is we also future-proof anything
installed today. Remove the indecision of picking the right technology or
trying to anticipate where the advancements will be.
The
IDL abstraction layer protects your building from future choices. Anything is
possible once you have data, history, and two-way communication.
Rest
easy that you'll be ready for what's next.
—
The
benefits to an IDL continue, but hopefully, this article has shed some light on
the core value it can bring to your buildings.
Learn
more at novant.io and see how Novant can help future-proof your
buildings for what comes next.
[an error occurred while processing this directive]
[an error occurred while processing this directive]
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]