Although often overlooked by building managers and engineers, data schemas are essential to the efficient building management, data analysis and system automation. That’s because schemas are the building blocks of effective database management. Without them, you foreclose your property’s potential to save energy, adopt tech, and compile valuable operational data that make your buildings run at more efficiently and at lower costs. But what are schemas and how do they work?
Database Schema Basics
Databases of all kinds must be organized in pre-determined ways. Otherwise, it’s impossible to store and retrieve data in any workable sense. Think of a schema as a naming standard “language” for how you write, store, and retrieve the information about your building—from the status of its assets to the historical data around energy use.
Just like any language, schemas have rules and conventions. Language has rules around naming things (e.g., noun, verb, etc.) and grammar (subject + verb + director object). If we don’t follow the rules, communication turns into confusion or completely breaks down. In the same way, database schema standards outline how things are stored, what they’re called, and how they’re related (i.e., relational database).
Schemas deal in metadata or “data about data”. For example, books have metadata in the form of their title, author, publisher, or call number. In the same way, buildings have data about their assets, such as asset name, location, site, or type.
For managers and engineers, schemas make recording and managing your asset database easier by ensuring your library is mapped, tagged and organized in a way that’s easily understood by machines and software. So, these standards are intended for both building owners and developers, ensuring both parties are speaking the same language.
Too often, managers and engineers use schemas customized to their site or ad hoc naming conventions that get lost when buildings change and people move on. Such informality creates confusion over time, but maintaining a standard schema ensures your software, BMS and assets can always communicate effectively.
Like advanced schemas, pictures are worth a thousand words.
Basic vs Advanced Schema
Some schemas are basic, recording only a few pieces of metadata (e.g., asset name, location, serial number). Other schemas are complex, recording many pieces of data. The more complex your schema, the more descriptive it is, and a more description means a “deeper” more powerful database, just as a long sentence is more descriptive than a short one. For example, consider the following two sentences:
“The dog fetched.”
“The black Labrador fetched the yellow tennis ball from its toy box.”
What are the major differences between these two sentences, and (more important) what can we do with the second sentence that we can’t do with the first?
For one, Sentence 2 contains more descriptive words (“black Labrador” “yellow” “toy box”), so we have a better understanding of the context. Second, the shorter sentence lacks an object. We know the dog fetched, but we don’t know what it fetched. The second sentence tells us—it’s the ball. In the longer sentence, we’re even given information about the situation (i.e., the Lab has a toy box). More importantly, Sentence 2 creates a relationship between the subject and the object. We can say, therefore, that the longer sentence is “relational” in that it describes how one thing (the dog) is related to another (the ball), which is related to another thing (the toy box).
These same differences exist between informal and standardised schemas. Longer, more descriptive schemas provide more context and meaning around a building asset. They’re also relational, in that they describe how one asset (e.g., temperature sensor) is related to another (e.g., AHU). Consider these two naming schemas for a temperature sensor housed on Level 9 of a hospital.
Examples of basic and advanced standard schemas
While the basic schema lists only the location (LV09) and asset name (TempS), the advanced schema extends the description to include the building, system, asset type, point type, specific location, and the device class. With these added details, we now have a relational description of the sensor. For example, we know it is part of the mechanical (M) system and part of an AHU. Therefore, we can say Schema 2 is part of a relational database, and that it gives us a greater understanding of the asset and its place in the system.
Overall, Schema 2 gives us more context and meaning than Schema 1, and we can use this information to learn more about how our buildings operate. Once we extend this schema strategy to our entire building, we have a powerful way to analyze its contents and functional efficiency.
Schema Benefits
There are many benefits to adopting and maintaining a standard database schema. Here are a few of the most important.
Software Deployment
Standard schemas create a common lexicon and database structure for software developers to use. Adopting a standard naming schema makes software deployment and management much simpler. Developers and building systems benefit from a common, predictable set of rules and naming conventions. Such standards make software development and deployment easier and cheaper because both stakeholders are working from a shared data structure. The developer can simply bolt their software package to your system, and everything works out-of-the-box.
Advanced Queries and Dynamic Lists
Conventional BMS pages are static. Their queries are hard-baked, with pre-built graphics that deliver data around points such as fault detection, temperatures, run speeds and statuses. They are “static” in that their queries never change. Your BMS will only “ask” specific questions about your system. They may be important questions, but they are, to be sure, limited. Contrary to their appearances, however, buildings aren’t static with respect to the data they produce, and managers and engineers often need to run queries and generate dynamic lists that exist outside the BMS purview. Using a relational, standardised schema allows this limitless flexibility.
For example, say you suspected one of your AHUs was starting to fail. You could run a query that identified all room temperature sensors that have been reading above 21 degrees for the last 24-hours for that specific AHU. If your schema is relational, it understands which specific sensors to target. You could then upload the data to a dynamic page to help troubleshoot performance issues. Dynamic lists like these can improve predictive failure and shorten downtimes.
Boilers in a mechanical room.
Asset Replacement
With a standard relational schema, you can identify an asset’s effect on the system and impact to service. For example, a standard schema can show you the effects to other systems when you plan to replace a failed actuator. Before work begins, you can ask questions like: “Will replacing the actuator stop chilled water to the whole building or just the data center?” or “How will the replacement affect Tenant X, Y and Z?” Such insights give you and your service engineers the right information for estimating costs, cutting downtime, and ensuring better tenant outcomes.
Updating Building Data
Buildings go through many evolutions in their life cycle, and these changes affect your asset database. Standard relational schemas make updating metadata much easier and more accurate. Recording changes only requires updating one specific piece of data, like a room number or new part. After that, your system automatically adjusts names and relationships, both upstream and downstream. Standard schemas cut the time and costs of updating asset databases.
Popular Schema Standards
Today’s most popular standard schemas differ in their approach, but all attempt to standardise asset description and storage to aid interoperability and software deployment. Project Haystack is a tag-based schema focusing on streamlining operation between smart devices within buildings, homes, factories, and cities. The Brick Ontology standardises both asset labels and connections, allowing the user to create a relational database.
Conclusion
It’s difficult to make big data work for you without first putting it into a standard structure. Schemas are that structure—they’re the digital architecture of your building systems. By building your asset database with standard schema, you’re ensuring your building, tenants and occupants benefit from future invocations such as advanced analytics, AI, machine learning, and cloud computing. These are the future of building operations and facilities management. Once all buildings graduate to smart status, they’ll be connected to everything, and proptech will help managers do everything from calculating asset depreciation to managing carbon emissions.
The Niagara Framework (NF) is developed by Tridium, and if you visit the company’s website, you will learn Niagara is a “comprehensive software platform for the development and deployment of connected products and device-to-enterprise applications.” If you’re like most FMs and property owners, that description sounds pretty technical and dense, as if it were written in a different language. Ironically, the notion of miscommunication within different languages illustrates perfectly what the Niagara Framework is and, more accurately, what it attempts to solve.
Let’s try to clarify Tridium’s definition by breaking it down into parts, so that by the end of this article you should have a better idea of what Niagara does. We’ll start with a simple thought experiment, then take a deeper dive into how Niagara helps buildings and devices communicate.
Niagara: The Ultimate Travel Adapter
Imagine you’re going on an overseas vacation and need a travel adapter. While at the airport waiting to take off, you spot an adapter in a retail store window. However, it’s not just any old travel adapter, it’s the Ultimate Travel Adapter, equipped with hundreds of outlets for every country, region and plug type imaginable. What’s more, the adapter has older plugs styles, so now you can charge that ancient iPod you brought along. Imagine you bought such a product. What could it do for you?
For one, it would give you the flexibility to buy and use any device you wanted. It would free you from having to use one brand. It would eliminate compatibility issues. Plus, it would let you plug all your devices into one place, simplifying the management of all your electronics.
The Niagara Framework functions like the Ultimate Travel Adapter, connect all of your devices and platforms together into one architecture. You can find a Tridium explainer video here.
Next, imagine your adapter has controls for managing each device. It also comes equipped with a dashboard that shows power consumption, current status, and security alarms. Even better, you’re able to access all of this valuable information online. With such a digital tool, you could save energy by unplugging unneeded components, quickly identify failed devices and better predict outages. In short, you could save time and money by increasing your efficiency.
Finally, image your travel adapter itself adapts to the changing technological landscape. After all, plug styles come and go, and so your adapter must also adapt or risk becoming antiquated. Such an adaptation feature could help extend the life of your equipment, letting you bring your favorite devices into the future. It would give you considerable freedom and centralised control over your travel itinerary.
This, in a nutshell, is what the Niagara Framework platform does: it works as a “architecture” for connecting systems and devices for building operation and automation. Now let’s take a deeper dive into how devices and systems communicate to better understand Niagara’s role.
Protocols: The “Language” of Machines
Dozens of systems and hundreds of pieces of hardware make up modern buildings, and each of these components must communicate with one another. To accomplish this, building devices must share a common “language” or what engineers call a protocol. The result is “interoperability” of devices, which is the main goal of platforms like Niagara. This is what Tridium means by “development and deployment of connected products” within their description.
The two dominant standard protocols for building devices are BACnet and LonWorks. These protocols are why your smart meter can transmit energy data to your BMS, even though two different companies made them. The two companies have agreed to design their products using these standard protocols so that you could integrate them easily. Another benefit of standard protocols is that you get to pick and choose which devices you want to use, as opposed to being locked into using propriety hardware from a single vendor (think Apple products).
Standard vs Open Protocols
There are two basic approaches to achieving interoperability of devices: standard and open protocols. Open protocols are when hardware designers use a propriety language for their devices, but “open” their protocol for public use. Access to the protocol gives other developers the “dictionary” for building gateways and interfaces, which “interpret” from one machine language to another. Essentially, the company is saying: Take our protocol and design something that will let other devices work with it. Developers use these open protocols to ensure interoperability between their products and others.
Standard protocols work by building consensus among many different developers to adhere to a standard machine language. So, a standard protocol isn’t proprietary but shared among the members. The upside to a standard protocol is that it requires no interpreter or gateway. Devices speak directly to one another right out of the box.
The Niagara Framework adopts a standard protocol stance towards development of building automation devices. That is, it attempts to wrangle the long list of standard device protocols under one umbrella platform—a type of protocol for protocols. But more than devices make up buildings. What’s this “device-to-enterprise application” all about?
Buildings: A Polyglot of Digital Voices
In addition to device languages, there are also standards and protocols for almost everything that helps your building and business function. For example, there are computing standard languages for the internet (IP or internet protocols). Then there’s programming languages for software, operating systems (Windows vs Mac) and computer networks. When you add it all up, buildings are a cacophony of digital voices singing ones and zeros to each other (#ITjokes).
To ensure these voices sing in unison, enterprise standards like CORBA, XML and DCOM were created. These standards attempt to translate between different operating systems, programming languages and computing hardware. They ensure interoperability of platforms. Without them, companies would be inundated with service calls and services would grind to a halt.
The Niagara Framework, again, connects devices to any enterprise applications within your buildings. Say you wanted to pass energy usage data through to your accounting software. Because it’s a flexible platform that facilitates interoperability, you can use Niagara to easily build these types of connections. This is what Tridium means by “device-to-enterprise application.”
The Internet Connection
One big advantage the Niagara platform brings to building automation systems and devices is wireless connections. It achieves this by using the internet to connect all your devices and controllers. Thus, it sits firmly within the market of platforms that utilise the Internet of Things (IoT) to give building owners and managers granular access to every component of their systems.
In hardwired connections, your BMS would communicate to, say, your HVAC controller through a wired connection. Hardwired connections limit your access. But Niagara wireless internet connection gives you access through web browsers from anywhere. Connection via internet opens up possibilities. For example, it makes connecting new devices much easier. Management is easier too. Check the status of your fire safety systems while at home or on vacation.
Now, give Tritium’s definition another read: “Niagara Framework is a comprehensive software platform for the development and deployment of connected products and device-to-enterprise applications.” Hopefully, you understand it a bit better now.
Summary
Many systems make up today’s buildings. Fire alarms systems, HVAC systems, access systems and security systems to name a few. Today, most modern buildings have automated the management and operation of these systems. The Internet of things has streamlined management of systems, with sensors, devices, and equipment sending streams of data back for collelction and display to stakeholders.
The Niagara Framework is essentially a system of systems, a software architecture designed to integrate multi-vendor building automation systems (BAS) under one umbrella platform. It improves flexibility in managing, connecting, and visualising of your properties and data.
In every act of communication, we strive to influence others. Even when our communication is simply to inform, we seek to align someone else’s view of reality to ours. While we can influence others’ behaviors, the higher aim is often to change their minds as well. However, it’s this sense of “mind control” that burdens the term with negative connotations today.
It’s often thought that to influence someone is to hold a hypnotic power over them, usually for nefarious reasons or personal gain. Someone or something is a “bad influence.” We often ascribe the act to politicians, cult leaders, or Rock-and-Roll lyrics. Social media “influencers” are opportunistic marketers. Irresponsible folks drive “under the influence.” You get the idea.
Even though the term has gotten a bad rap recently, the premise of influencing as a part of communication isn’t nefarious at all; in fact, it’s a basic component (and outcome) of any effective communication. And savvy communicators understand how to use influencing strategies to get their message across more effectively. Here are some tips on how to communicate better by influencing your audience.
Soft Landings Approach
Influence requires an understanding that most people fear and resist change. Even when your audience knows change will be beneficial, some push back is inevitable. At these points, communication can become strained or breakdown. When possible, you can influence a successful outcome by easing folks into change rather than “ripping off the bandaid.”
“I do a lot of organisation transition and change management,” says Phoenix Lavin, a veteran FM who’s worked in the industry since 2003. “Sometimes that change is painful, and there’s a bit of grief and disruption.” Lavin suggests meeting resistance to change by taking elements of a “soft landings” approach:
“A soft landings approach incorporates taking the time to introduce people to change. Rather than leaving people feeling like change is being forced on them.”
Phoenix Lavin
“A soft landings approach incorporates taking the time to introduce people to change. Rather than leaving people feeling like change is being forced on them.”
People fear change primarily because they feel a lack of control. In these moments, fear tends to consume our focus, making it tough to communicate. Engage in active listening and let your clients vent their frustrations. Allowing your audience to express their anxiety, lets you identify and focus on the source(s) of that anxiety. You may not think their “problems” are a priority, but by refocusing and being empathetic, you make your audience more receptive to your own ideas.
Also, invite your audience to contribute to the project. It will give them a sense of control. “It’s about how they can see themselves in this new building/facilities,” Lavin explains, “and how they feel engaged and part of the build and operation process.”
By engaging your audience in the problem solving process, you also give them stock in the solution, and they come away from the conversation confident they’ve contributed. You will know your soft landing was successful, if your audience comes away not knowing they’ve even “landed.”
“I’ve got to gently move you around here so you barely realise you’re going around the corner,” Lavin explains. “Then voila! All of sudden now it’s your idea not mine. That’s the influencing component of good communication.”
Avoid Language that Creates Hierarchies
As is often said of words: they matter. The wrong words can alienate your audience by putting others at a lower level and/or yourself within a higher one. We often interpret these linguistic positions on an unconscious level, but they impact our audience’s reaction nevertheless. To level the field, choose language that communicates equality. Lavin provides a relevant example for facilities management:
“In our industry, we are often shackled with the term ‘service’ (which is linked to the term ‘servitude’). What we hear in that word is: You are here to do something for me, and, therefore, I am greater than you. When we look at communication, we’ve got to understand our audience and adjust our language so we’re not in a position of servitude, but in a position of competency and credibility.”
Instead of “customer,” Lavin suggests using terms like “stakeholder” or “end-users” to refer to the people benefiting from your input and expertise. This is especially important in relation to in-house management.
Another loaded term to avoid is “discussion.” Within it, Lavin says, lurks aggression and an imbalance of power. “It’s a one-way exercise,” she says. “It says I’m pounding something into you. I’m going to say what I have to. Instead, I tell people to use open terms like ‘dialogue’ or ‘conversation’ or ‘chat’.”
Some words and phrases may create or reflect frustration as well. As tensions rise in our conversations, our language often becomes more formal sounding or even legalistic. Try to maintain the same level of formality and tone as when you began the conversation, otherwise, your audience will immediately detect such changes, become defensive and make your influence less effective. “These are subtleties,” states Lavin, “but they’re how you change the dynamic of a conversation for the better or worse.”
Include Yourself in the Conversation
In the spirit of equality, speakers and writers should also include themselves in their arguments and narratives. Say “we” rather than “you.” Self-inclusive language helps eliminate hierarchies and signals that you have a stake in the outcome too, that you’re acting in good faith. It also forces you to empathise. If your message is “we’re all in this together” then the implication is that everyone must appreciate one another’s perspective.
“Anyone who is an effective communicator puts themselves into the narrative,” explains Lavin, “not in an arrogant way, but in an understanding, empathetic way. We can take a lesson from Te Reo Māori. In Te Reo Māori, we could start a meeting by saying tēnā koutou which is Greetings to everybody in the room (3 or more) or we can say tēnā koutou katoa which is greetings to everybody, and I’m including myself in the statements going forward.”
“Anyone who is an effective communicator puts themselves into the narrative.”
Phoenix Lavin
Inclusive language is also a prime launching point for bolstering your own credibility and experience. Politicians often use unifying language to great effect. Most never pass up a chance to point out their “working class roots” or “humble beginnings” to connect with their constituents. There’s a simple reason for the ubiquity of this approach: it works. If you’re sincere about your connection, your audience will (and should) respond positively.
“If you’re part of the organisation,” Lavin explains, “then communicate that these decisions are affecting you too. Let’s say you’re at the top table for an expensive capital replacement, and the stakeholders say, The business can’t sustain this. Your response should be: We understand the hesitancy, and we understand the drivers of the business. As a part of the workforce, I understand this. That type of language creates an unconscious connection. So, suddenly you’re not just a person saying I want something from you. You’re saying We need to do this together.
Got an Expert? Bring them Along
Credibility is such a key part of influencing that it’s foolish to omit someone with expertise in the arguments and ideas you’re presenting. Too often, we feel overly confident or too prideful to admit our ignorance of a topic, opting instead to “fake it ‘til we make it.” It’s a dangerous gamble that can tank your influence if you’re outed by a technical question. Lavin advises that if you think your credibility may be questioned, to bring someone else into the room:
We always think we have to do difficult conversations on our own, but we don’t. There’s nothing wrong with saying, ‘Oh, I’ve brought Ms. X along with me today because she’s currently working with X systems and she’s got a better overview and understanding of this.”
The need for expertise requires FMs to build and maintain professional relationships. Find people who can provide you with answers and guidance when you’re stuck. “I still need to bounce things off people,” Lavin admits. “I’ll ring people and say, I’ve got to bounce this off you. This is where I’m going, and I can see it’s not going to work but I can’t quite see my way out of it. When you’ve got a great network of people who have skillsets different from yourself, you can do that.”
Conclusion
At its most complex level, the art of influencing is about abiding by simple courtesies of communications. It doesn’t take an advanced degree in communications or being a master orator to be empathetic, inclusive and thoughtful about the words you use. There’s no “political correctness” to abide by. For most managers, these “strategies” are basic mores of professional conversation. Often the real art of influencing is not in the execution of these simple courtesies, but in the remembering to do so.
