Information Technology (IT) and Operations Technology (OT) are two distinct yet interconnected fields that play critical roles in modern organizations. IT deals with the use of technology to support business processes, while OT focuses on the use of technology to control and monitor industrial and commercial processes in facilities. By looking at IT vs OT systems, it’s easy to identify their major differences.
What are IT Systems?
IT systems are primarily used to support business processes, such as data storage, processing, and communication. These systems include things like enterprise resource planning (ERP) systems, customer relationship management (CRM) systems, and enterprise-wide networks. They are responsible for maintaining the flow of data within an organization, and provide important services such as email, file storage, and data analysis. IT systems are also responsible for maintaining the security of an organization’s data, including firewalls, intrusion detection systems, and encryption.
What are OT Systems?
OT systems, on the other hand, are used to control and monitor industrial processes. These systems include things like programmable logic controllers (PLCs), distributed control systems (DCSs), and supervisory control and data acquisition (SCADA) systems. They are responsible for controlling and monitoring the physical processes within an organization, such as manufacturing processes, power generation, and water treatment. OT systems are designed to operate in real-time and are often required to operate 24/7.
When we look at IT vs OT systems, trends show they are increasingly being integrated to improve the overall efficiency of companies and facilities. For example, a building owner might use data from an OT system to optimize their HVAC systems, or an energy company might use data from an IT system to identify and respond to potential power outages.
The difference between IT and OT system components. Note that IT and OT must interface with one another.
Network Security
One of the major differences between IT and OT is in the level of security required. IT systems are typically more connected to the internet; hence they are more exposed to cyber threats. These systems need to comply with industry-specific standards like the Payment Card Industry Data Security Standard (PCI-DSS), HIPAA and SOC2. Organizations need to maintain regular backups, have intrusion detection and prevention systems, as well as have strong and regularly updated access controls in place.
OT systems on the other hand, are typically more isolated from the internet and have fewer connections to external networks. These systems need to comply with standards like IEC 62443 which are specific to industrial environments. Because of the real-time nature of their operations, organizations need to have redundancy in place and maintain backups that can be restored within minutes, have detailed incident response plans, as well as maintain physical security of the systems.
Conclusion
IT and OT systems play critical roles in modern organizations, with IT systems primarily focused on supporting business processes and OT systems focused on controlling and monitoring industrial processes. The two fields are becoming increasingly integrated, with organizations leveraging data from both types of systems to improve overall efficiency. However, they are also vastly different in terms of the level of security required, with IT systems being more exposed to cyber threats, and OT systems being more isolated and needing to comply with industrial specific standards.
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.
Properties need effective cybersecurity measures. Cybercriminals don’t just attack high profile companies and governments; they target small to medium businesses too. Computer viruses range from annoying adware infiltrating your browser to costly ransomware attacks. In 2021 the world saw a 105% jump in ransomware attacks. Healthcare alone saw a 755% increase! Businesses are paying out billions each year to save their proprietary and/or customer data—and paying only makes things worse.
The sharp rise in ransomware has forced building owners to take a serious look at their IT infrastructure. This is alongside adapting to the challenges of the pandemic and managing a remote workforce. Interestingly, some security experts point to remote work as one cause for the increase in ransomware. Since employees are no longer behind corporate firewalls, their home-based laptops and mobile devices become “attack vectors” for gaining entry to company networks.
Remote entry points are also an issue for building control systems. As buildings become more connected and “smart”, the threat of data breaches increases. That’s because system integration, IoT devices, and building automation systems (BAS) increase connectivity and wireless operation. It’s a problem the U.S. government has known about since 2015 after the GAO warned of a 74% jump in cyber incidents involving government-owned industrial control systems.
Building control systems like BAS/BMS connect hundreds of devices and sensors that make up systems like fire, access, HVAC, electrical, and lift. Connectivity makes it easier for cybercriminals to make their way to more sensitive data because there are more paths to follow. Wireless and IoT devices make networks vulnerable to remote Wi-Fi exploits and password hacks. These potential data breaches and financial losses from malware are why property teams need to practice effective cybersecurity habits.
Setup Multiple User Accounts
One good security habit to adopt is proper account creation and assignment to your team. To save time and hassle, some building managers create and share one master admin account amount their team members. It’s tempting when someone needs to make a few quick changes to simply email your login and password. However, this puts your BAS at risk of cyberattack if those credentials are misplaced or abused. To be cyber safe, create both admin and user level accounts and assign them to each employee.
Almost all BAS software lets you create multiple accounts and at various levels of access. Individual account creation does three key things:
It ensures inexperienced members aren’t given access to critical controls.
It makes sure user actions are recorded by the system.
It helps users work more effectively.
Modern BAS systems track what users do, which is helpful when things in the system are improperly changed. If everyone signs into the system with the same account, then you can’t tell who did what and when. This can slow down repairs and troubleshooting because you must rely on faulty human memory instead of an accurate digital record. Also, when inexperienced or new users sign into an admin account, they may spend an inordinate about of time searching for the tool or feature they need. User-level account interfaces are simplified for this reason. Too many options can tank productivity by forcing workers to waste time navigating a complex interface looking for a single item.
Password Creation
Creating strong passwords is one of the most impactful cybersecurity habits you can adopt. Too often folks continue to use highly predictable pass codes (e.g., “123455” or “Qwerty”) to secure their most sensitive data. What’s worse, most of us also use these same flimsy passwords for all our accounts. It’s behavior that’s too predictable, and predictability is the Achille’s Hill of security.
Make sure your team knows password best practices. When it comes to password creation, length and complexity matter. Passwords should be at least 8 characters long, include special characters (e.g., @!&), and numbers. The longer the password the better; however, there’s a limit to how many characters a person can hold in long term memory. To combat the memorization problem, use passcodes instead.
Passcodes are acronyms made from random words or long sentences. To create a passcode, use the first letter of each word to form your password. For example: “My cat whiskers is 3 years old and likes to have her belly rubbed.” This sentence (which is personal and easy to remember) becomes the password: “mcwi3yoalthhbr”. Then, swap out a few special characters, and you’re good to go.
If passcodes seem too complex, make your life 100% easier by simply using a password manager. These cloud-based apps create and store complex passwords in the cloud for you. They will even fill in the form fields for you, saving you valuable time. Most apps have free or inexpensive annual plans, so investment is minimized, while time savings and security are maximized.
Suspicious Link Detection
A building’s devices aren’t its only weak spots. In fact, occupants are often the major sources of malware. Cybercriminals can use social engineering to trick employees into opening phishing emails and navigating to fake websites. The tactic is called a “pharming attack” and is a common way for hackers to steal an employee’s username and password. The fake website looks and feels like the authentic one, but it’s a duplicate. Employees unwittingly enter their username and password, which is recorded and used to gain entry to the account.
Hackers design phishing emails and fake websites to look like official corporate digital assets, often using the same branding, logos, language, etc. Most are convincing enough to fool an employee who’s under a bit of stress and/or not paying attention. However, there are a few tell-tale signs to look for:
Salesy Language. Cybercriminals often employ high-pressure sales language or scare tactics. Phishing emails may claim “suspicious activity” or fake “charges” to user accounts to entice holders to hastily move to fix “issues” without first confirming the source of the emails.
Grammar mistakes. Often cybercriminals don’t speak your native language, so look for any grammar mistakes or misspellings. These are extremely rare in authentic corporate emails and are a sure sign of a fake.
Pixelated logos. Hackers use official logos to trick email recipients, but often these logos are hastily copied and pasted from websites and may be incorrectly sized resulting in pixelated or strange looking images.
Strange URLs. URLs have two parts: the hypertext (e.g., “Contact Us”) and the address (e.g., https://7nox.com/). Never trust the hypertext to tell you where the link goes. Always check the URL address. To do this, hover your cursor over the text without clicking and read the URL displayed in the bottom left corner of your browser. The URL should contain the company’s address. If it’s simply a long string or strange characters, it may be a pharming attack.
BAS Backups
Make sure your BMS provider backs up your BAS/BMS system on a regular basis. Backups keep your system secure against ransomware attacks, which rely on businesses not having copies of their data. Plus, system backups ensure redundancies when your system goes down or when you shut your building down for changes. If controller settings aren’t “persistent” they may not be saved during a reboot of your BMS. It’s critical that you have backups to ensure these changes are saved.
Conclusion
While building automation and connectivity brings many wonderful things to the built environment, they do require owners and managers to make their IT and OT more resilient. However, without proper training of staff, these technical efforts may prove fruitless. In cybersecurity, humans are often the weakest link. That’s why cybersecurity shouldn’t be simply a training box to tick at the end of the year. It should be an ongoing attitude and effort by all employees. Focus your training on seasoned staff, who may be laxer in their habits, and on newcomers who may have few habits at all.
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.
