AI and machine learning (ML) are often used interchangeable, but they’re not technically the same thing. However, the difference is smaller than you think, and once you understand it, you’ll never mistake the two again. The following is a very basic explanation and omits many technical aspects of AI and ML which go beyond the scope of the intended audience. The definitions and examples attempt to lay a foundation for further exploration around these topics.
Artificial Intelligence: The Entire Robot
Artificial intelligence (AI) is a broad term that refers to creating machines that can perform tasks that normally require human intelligence. Examples of such tasks include visual perception, speech recognition, decision-making, and language translation. There are many subsets and subfields of AI, each of which tries to solve a specific problem and/or takes a different approach to creating “intelligence”. Here are the five most recognized subsets of AI:
Natural Language Processing(NLP) focuses on enabling machines to understand, interpret, and generate human language. NLP is used in applications such as chatbots, voice assistants, and language translation. ChatGPT is an NLP.
Computer Vision is concerned with enabling machines to interpret and understand visual data from the world around them. Computer vision is used in applications such as object detection or facial recognition. Autonomous vehicles, like some Tesla models, use computer vision.
Robotics develops machines that can physically and autonomously interact with the world around them to perform tasks like assembly line work or rescue operations. Boston Dynamics focuses on robotics.
Expert Systems are designed to mimic the reason-based decision-making ability of an expert in a particular field, such as medical diagnosis or financial analysis. Expert systems are why you keep hearing about AI lawyers defending people in court.
Machine Learning involves feeding data into a machine learning algorithm and allowing it to learn from that data in order to make accurate predictions or classifications about new data.
So, ML is a subset of AI. That’s the first big difference to note. While AI is a term that encompasses a wide range of technologies and techniques, ML is a specificapproach to building AI systems.
It’s helpful to think of AI as the “entire robot”—a fully autonomous machine capable of thinking and acting like a human. However, each subset is only one part of the entire robot. Robotics attempts to develop the “body” for interacting with the environment. Computer vision gives the robot the ability to make visual sense of its world. NLP arms it with the power to communicate. ML bestows the faculty of learning. And expert systems send it to university. It’s a true Frankenstein’s monster of disparate parts, but when brought together will finally realize the goal of AI.
What’s Machine Learning?
You hear a lot about ML because it’s a critical step in creating the entire robot. Almost everything we consider to be alive must be able to learn. Birds do it. Bees to it. Heck, even amoebas do it. But despite its ubiquity in the world of the living, learning is incredibly complex. Therefore, ML is taking on one of the biggest challenges, but it’s a triumph that offers the biggest ROI. Once we create a machine that learns, we can train it to make better decisions. So how do you create a machine to learn?
ML uses statistical algorithms to enable machines to learn from data and improve their performance on specific tasks over time. ML algorithms analyze large amounts of data to identify patterns, which it uses to make predictions or decisions on new data. Like humans, ML is a process that requires that machines be “taught” by exposing them to information.
ML Example: House Price Estimator
Suppose you wanted to create a ML learning algorithm that predicts the price of a house based on its size and location. You would need two sets of data: a training set and a test set. First, we create a training set of data composed of recently sold houses with their sale price and location.
The ML then processes the training data to look for patterns. After some processing, let’s say it “learned” the following “rules”:
Houses larger than 2,000 sq ft sell for > $200K
Houses less than 2,000 sq ft sell for < $200K
Houses within 5 miles of the airport sell for < $100K
Homes within 5 miles of the lake sell for > $300K
The algorithm could then use this knowledge to predict the price of a house outside the training dataset (i.e., the test set). For example, a house that is:
2,500 sq ft and 3 miles from airport.
Since the new house is more than 2,000 sq ft, the algorithm would then apply the “> $200K” rule, but since the it’s also less than 5 miles of the airport, it would apply the “<$100K” rule. Therefore, the algorithm’s prediction would likely be “$150K”.
Next, the ML algorithm checks its guess against the actual price, which is $170K. It now has a $20,000 discrepancy it needs to resolve. It checks for more patterns and learns that, as houses of equal size get closer to the airport, they decrease in price. Through some calculations, the program can determine the changes in price by proximity and apply the data as a weighted value in its next prediction. For example, maybe each mile closer to the airport equates to a 10% decrease in price.
The machine uses this constant process of guessing and checking (called backpropagation) to improve its predictions. The more iterations and inputs, the “smarter” the algorithm gets.
“So what?”, you might ask, “Isn’t this simple logic? Why do we need a machine to do this?” Well, for one, ML can sift through data, find patterns, and test its guesses against real world data at an astonishing rate. In short, it can “learn” much quicker than humans. For another, it can juggle many more parameters than we ever could, so its guesses will inevitably we more accurate over time.
Think about all the factors that go into the price of a house besides size and location. There’s the house’s age, condition, number of rooms, the market conditions, and seller motivation just to name a few. But there are other less typical considerations like current interest rates, lot locations, or roof type. When you drill down further, you find that the real number of factors is enormous. Few sellers place a critical role on the color of a house when calculating an asking price, but what if it mattered more than we thought? What about the history of the house or the future of the neighborhood where it resides? The better our predictive capabilities, the more important these “lesser” considerations become.
ML can iterate much faster and with greater detail than we can, making it more efficient at locating “hidden” patterns. What if dark-colored houses sold for higher prices than light-colored ones? Maybe houses with more east-facing windows were cheaper than more west-facing ones. Machine learning can consider all these factors and then some—and do it in real time.
Finally, imaging adding to this learning algorithm the ability to search for, monitor, and collect house price information for a large region of the country. It would be a fully autonomous learning and predicting machine that would only get smarter the longer it worked. That’s where ML is at today.
Conclusion
It’s easy to see how ML learning algorithms are a game changer for humanity. Their application to knowledge-based work of every kind is almost limitless. What’s AI developers are attempted is the automation of thinking itself. Translate these advantages to building automation, and it’s easy to see how ML will transform the built environment. Imagine AI that could plan your building’s HVAC setpoints a week in advance based on a weekly weather forecast and price predictions for energy costs. What about a FDD system that could predict chiller failure with 98% accuracy?
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.
In this article in our BACnet Basics Series, we look at Device Profiles, why they’re important and how they’re created. We’ve also included a real world example that illustrates how to use device profiles to accurately specify your own projects.
What are Device Profiles?
As we saw in BACnet Basics: What are BIBBs?, device functions come in five basic categories, each containing specific capabilities. For example, the category Data Sharing (DS) includes capabilities like Read Properties (RP), Write Properties (WP) or Change of Value (COV). If we combined all these services into a minimum collection of capabilities, we would be creating a device profile.
As an analogy, think of the profile “Automobile”. Every machine that claims to be an “automobile” needs the functions of Acceleration (A), Deceleration (D) and Maneuverability (M). Of course, there can be automobiles that do much more, but every “automobile” must, at minimum, perform these three functions (A,D,M).
Definition: BACnet device profiles define the minimum set of BACnet Interoperability Building Blocks (BIBBs) supported by a device claiming that profile. When a device claims a specific profile, you know that it contains a preset of specified functions and services. Profiles are handy because they provide a short-hand method for describing a device and its interoperability capabilities. Device profiles are organized into Groups and Families
Device Groups
Device Groups are general categories of device functions. There are four Group types:
Operator Interface—Covers the minimum capabilities for workstations and other user interface devices. Devices normally support A-side (Client) functionality.
Controller Device—Covers anything from programmable building controllers to smart sensors. Devices normally support B-side (Server) functionality, but more advanced supervisory controllers also include A-side (Client) functionality.
Control Station—Covers lighting control stations that are smaller client devices that support specific user controls such as manual light switches.
Basic Device—Covers all “miscellaneous” family functionality. Usually included alongside other device profiles.
Device Families
Each Profile Group contains various Families within it. Families cover profiles for various, supported building systems like Lighting, Life Safety, and General Purpose. For example, the Controller Device Group contains profiles for the following Family types:
(Example) Controller Family
General Purpose—General purpose controllers usually for HVAC and lighting.
Access Control—Access control controllers such as an access control panel
Lighting—Lighting controllers such as supervisory lighting controller
Life Safety—Life safety controllers such as a fire detection panel.
Elevator—Elevator controllers
Let’s zoom into the General Purpose profile family within the Controller Device Group and see what BIBBs it contains.
Building Controller (B-BC) —Field programmable and configurable supervisory controllers in HVAC and general purpose application.
Advanced Application Controller (B-AAC)—Controllers that run advanced HVAC or general purpose control applications.
Application Specific Controller (B-ASC)—Controllers that run specific HVAC or general purpose control applications.
Smart Sensor (B-SS)—Small sensors that provide sensor values to other devices.
BACnet device profile Families are organized in a container hierarchy. As you move up in complexity, you increase the minimum amount of BIBBS required. Like nesting dolls, each profile contains all the minimum profiles from the previous ones.
For example, the above General Purpose BACnet profiles increase in complexity as you move up from Smart Sensor to Building Controller. All BIBBS included in a Smart Sensor profile are always included in a Smart Actuator profile, and all the BIBBs included in those two profiles are always included in an Application Specific Controller, and so on.
Although higher level BACnet profiles contain more BIBBs, it’s not the number of profiles that matters. Each profile requires a minimum number and type of profiles. So, even if a device contains or exceeds the minimum number of BIBBs, it doesn’t guarantee it will meet the standard. It must contain the minimum number of the correct BIBBs to meet the profile standard.
Specifying Device Profiles: Boardroom Example
Let’s use the Device Profile Quick Reference Guide to see an example of how to choose the device profiles for a real-world project. Read the following scenario:
You want to outfit a medium-sized boardroom equipped with a control panel with a built-in controller. The panel will control the room’s temperature and lighting. You also need manual lighting controls near the door.
To determine the device profiles needed for the project, we can start by listing the functionality we need. We will need HVAC controls for temperature. For lighting, we will need controls for both the panel and a manual user control switch on the wall. Therefore, we will need functionality from the Controller Group and Control Station Group.
Next, we can determine what Families we need within each group.
For the Controller Group, we need:
General PurposeFamily for HVAC
Lighting Family for panel control lighting
Access ControlFamily for access
For the Control Station Group, we need:
Lighting Family for manual switch lighting control
Finally, we can choose specific profiles to fulfill our HVAC and lighting functionality.
HVAC Profiles
In the Reference Guide, we see the following profiles for the General Purpose Controller Family:
B-BC: The building controller is intended for field programmable and configurable supervisory controllers in HVAC and general purpose applications.
B-AAC: The advanced application controller is intended for controllers that run advanced HVAC or general purpose control applications. It does not require being configurable through BACnet.
B-ASC: The application specific controller is intended for controllers that run specific HVAC or general purpose control applications. It does not require being configurable through BACnet.
B-SA: The smart actuator is intended for small actuator devices that allow being commanded.
B-SS: The smart sensor is intended for small sensor devices that provide sensor values to other devices.
We can ignore the last two profiles, because we need neither actuators (B-SA) or sensors (B-SS) for the project. We can also eliminate the Building Controller (B-BC) profile because it does not require supervisory control. Depending on our HVAC needs, we could choose either the Advanced Application (B-AAC) or the Application Specific (B-ASC) profile.
Lighting Profiles
In the Reference Guide, we see the following profiles for the Lighting Controller Family:
B-LS: The lighting supervisory controller is intended for controllers in lighting applications that can command and operate subordinate lighting controllers, in particular through group write commanding.
B-LD: The lighting device is intended for lighting controllers that control individual lights or groups of lights. Normally used as leaf nodes in lighting group setups.
We would choose the B-LD profile if the panel only controls one group of lights. However, if the lighting is more complex, we might opt for the B-LS with supervisory controls.
Control Station Profiles
Because the room also requires manual user lighting controls, we need a profile from the Control Station Family. In the Reference Guide, we see the following profiles:
B-ALCS: The advanced lighting control station is intended for sophisticated control stations that support user view, control and limited configuration of lighting functionality. Provides full commanding support of lighting objects and group operations for them.
B-LCS: The lighting control station is intended for control stations that support simple control of lighting functionality and limited status indication. Provides limited support of commanding lighting objects.
The simpler B-LCS would work for this project. But, again, depending on the complexity of the room’s lighting, we might choose the more complex profile.
Conclusion
Through the Boardroom Example above, we can see how BACnet profiles make project specifications easier and more accurate. Standards and profiles support an accurate procurement process, requiring less change orders and adjustments. Defining capabilities also creates an outcomes-based workflow so that buildings function the way owners and tenants need them to.
Every complex topic or field needs a helpful naming system. Scientists name flora and fauna by genus and species. Even astronomers have their own planetary nomenclature. Standard naming conventions do just that—they standardize how we talk about things. They’re also a convenient way to condense large amounts of information into a short form. Hence, they function like acronyms. We needn’t sound out “self-contained underwater breathing apparatus” when we can simply utter S.C.U.B.A. right?
In building automation, the same need for standards and compression applies, and BACnet gives us a convenient way to describe the functionality of devices using something called BIBBs.
What are BIBBs?
Definition: BIBBs stands for “BACnet Interoperability Building Blocks” and is a standard naming convention for representing specific device capabilities using simple acronyms. That is, it creates simple categories to describe how one device works with another.
Without short-form descriptions, listing all the capabilities and services that a device offers would turn functional descriptions into a messy scrawl of technical jargon. By condensing these functions into acronyms, BIBBs makes it easier for FMs, system integrators, and building engineers to talk about the same things. BIBBs help buyers get the minimum number of services for the job without over-engineering and spending for extraneous functionality.
BIBB Categories
The BIBB naming system starts with five broad categories that list interoperability functions. These are high level functions that host specific capabilities within them. Categories include:
Data Sharing (DS)
The data sharing function describes how devices exchange data. Data sharing is essential for reading and writing data from one device to another. For example. If you wanted to regularly check the water temp of your boiler to monitor its performance, you would need the DS functionality.
Alarm & Event Management (AE)
The alarm and event management functionality is for detecting and notifying alarms and events. For example, if your boiler temps exceeded a specified setpoint, the AE function would allow you to receive an alert.
Scheduling (SCHED)
The scheduling functionality is for scheduling values based on date, time, and calendar. For example, if you wanted to schedule your boiler to provide after-hours heating for tenants.
Trending (T)
The trending functionality is for trend logging and historical data support. For example, if you wanted to store your boiler’s temp data to create a history for your engineer.
Device Management/Network Management (DM/NM)
The DM/NM is for setting up device and network management. It allows devices to discover each other, to synchronize clocks, and to reset a device to factory settings (reinitialize). For example, if you wanted to discover a newly installed boiler temp sensor.
Specific Capabilities
Specific capabilities, or sometimes called services, are distinct functions that exist within a BIBBs category. Capabilities also have acronyms. For example, the Read Property (RP) service is under the data sharing (DS) category. The service must exist for data sharing to occur. That is, a device (e.g., controller) must be able to read data, while another device (e.g., thermostat) must be able to send it. Many devices have both capabilities. Here are some examples of services for different BIBBs categories:
Data Sharing (DS)
Read Property Multiple (RPM)
Write Property (WP)
Change of Value (COV)
Alarm & Event Management (AE)
Notification (N)
Alarm Summary (ASUM)
View Notifications (VN)
Device and Network Management
Dynamic Device Binding (DDB)
Text Message (TM)
Reinitialize Device (RD)
Find a more extensive list of device capabilities here.
Clients and Servers
BIBBs also distinguishes between clients and servers, assigning and A and B category to each respectively. Client devices (A) can initiate or call for data or service from a device that can respond to that request (B). An example of this would be a controller (A) requesting temp data from a thermostat (B), which responds with the requested data. You can remember this order by recalling that the letter “A” comes before “B” in the alphabet, just as a request must precede a response.
Putting It All Together
Now that we have all three parts of BIBBs, let’s look at a full interoperability description. The BIBBs naming syntax places the category first, specific capability second, and server/client designation third. Each acronym is separated by a dash. Consider a BACnet controller that has data sharing (DS), a read property service (RP), and client capability (A). It would be designated as DS-RP-A. Can you guess what functionality a thermostat would require to send temp data back to the controller? If you answered DS-RP-B, you’re correct!
Conclusion
As we’ve seen, BIBBs are the “building blocks” of the standardized system of naming devices and their interoperability functions. Devices can have many different functions, so there’s also a need to group them. For example, controllers, sensors, and actuators must all have a minimum number of specific functions to work. These groups of functions are called BACnet device profiles. Like BIBBs acronyms, profiles give us a shorthand way of quickly designating and describing a device. Read BACnet Basics: What are Device Profiles? to learn more or visit The BACnet Institute for free training.
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.
