In this article I am going to explore a lot of the different IT questions I've been asked by my IT for BAS Students. As you may or may not know, I run an online training program called Information Technology for Building Automation System Professionals.
I've had a lot of good questions from folks in this program. And while I've been going through this program I've had tons of conversations about all sorts of things.
As I start to think about the topics that I've talked about, I can break them down. Into four main areas:
- Network
- Remote access
- Integration
- Databases
Network Questions
First, let's dive though the network questions that I've been getting.
The night before I wrote this article I had my first IT Training webinar, actually, technically it was my second webinar.
This is too funny.
So I go to host a webinar on Wednesday to train folks on how to communicate with IT.
This is a webinar I'm going to be doing every week going forward, and I think I'm gonna do it on Wednesdays.
Essentially I'm teaching the three secret strategies that I've come up with to effectively communicate with IT, and know what you need to know about information technology.
So, here I am I'm on this webinar and I'm talking for an hour and a half. I can see everyone in the webinar but no one's responding, and I'm like, "What the heck is going on?"
Apparently, there is some sort of glitch with the webinar software. Once I got out of the webinar after an hour and a half of speaking, because I get in my zone and talk, that's just kind of my personality.
I get out of this webinar and everyone's like, "Where's Phil? I can't see his screen?" The one guy who could hear me is like, "I can hear him, it's pretty interesting." So, that was funny, especially considering it was a webinar on IT.
So finally on Friday, July 7, 2017, I went and was able to do the webinar.
I hung around for a long time after the webinar with a couple folks who I know and who have been long-term BAM subscribers.
We talked about all sorts of things.
Finally, we got to talking about networking, and we started talking about IP controls, and what are the things that you have to be aware of?
How do you deal with things on a production network?
There were some pretty interesting questions, and whether you know it or not, this IT thing, it's gonna come and it's gonna smack the BAS industry like a frickin' two-by-four. There are a lot of people who are just gonna get smacked upside the head because they refuse to learn information technology.
It's like back when you had the pneumatics to DDC shift and all the pneumatics guys were left looking for jobs, or having to learn DDC, and all these new DDC folks were going and getting the big salaries.
It's basically going to be like that but on steroids, because you have a bunch of different things. It's not just a shift from a different control system to a new control system.
It's actually a shift in network architecture, it's a shift in how servers are done, it's a shift in all of this different integration stuff. There' are several major categories of shifts happening at the same time, and they're all falling on the BAS folks.
Whether you want to accept it or not, these things are coming your way, the manufacturers are going to continue to release IP enabled controls, wifi enabled controls, and more robust APIs.
Like I said, we're talking last night.
One of the guys, Kai, he says to me ...
"Hey, I've got fifty IP controls and they're on the production network. How do I make sure that they don't interfere with my customer's network?"
So, what's going on there, when you hear production network, that's just another way of saying the customer network. The production network is the customer network. That's a term IT likes to use.
That's why it's so important for you to understand this lingo, so that when you're in a conversation with IT when you're having these conversations across the table, you're talking at the same level.
One of the big problems I see is that folks aren't talking at the same level with IT. This creates tension that doesn't need to be there. There are these problems of communication that don't need to be there.
So Kai asks about that, and I said, "Well, here's the thing. You can be on the production network. You can physically be on the production network, but logically be on your own network". Now for some of you who understand IT, you get what I just said. It makes complete sense to you.
For the rest of you, and this isn't a dig on you, so don't take this as me being like, "Ha ha, you don't know IT".
No, it's not that at all.
Rather it's just me saying, "Hey, if you don't understand this, that's totally cool. I'm about to explain it to you".
When I say physically you're on the production network, but logically you're on a different network, what I mean is that physically your devices are plugged into a switch that is on the production network.
However, logically, you use a thing called a subnet and a VLAN, right?
A subnet is a sub portion of a network. A VLAN is a Virtual LAN. A local area network is a physical construct. It's a switch with a bunch of network connections that go to host devices. That would be your physical, local area network.
Within that physical, local area network, you can have a bunch of VLANs.
Now the really cool thing about VLANs is they can stretch across multiple, physical LANs, and while I'm not here to give you a lecture on network technologies, the important thing is I sat and I said,
"Hey, Kai, you know what? Just put them in a VLAN, and then they are logically segmented from all the traffic. None of the traffic on the other VLANs or on the production network will be able to see that unless you want it to see that. Then you will be essentially, logically isolated".
I also said,
"You know, if you're worried about any quality of service issues, that's essentially where you have limited bandwidth that can go through what's call a trunk. A trunk is a physical network connection that connects to switches or switch to a router. It basically connects network devices".
I said, "Well, you know what? If you're worried about the quality of service, like maybe IP cameras being on the same trunk, because multiple VLANs can be on the same trunk. While you're logically isolated, you're not physically isolated".
That's not a big deal, because logically isolating stuff is how the majority of the industry works.
If everyone physically isolated every different type of traffic, you would have these huge networks, and it wouldn't be scalable or doable. It'd pretty much shut down the internet.
What I said is, "What you do is you just work with IT to route your traffic to a trunk that is not heavily congested".
What do I mean by that?
Well, essentially, there are these things called routes. Routes can tell your IP traffic where to go. Essentially, when you're telling your IP traffic where to go, you're telling it the path to take.
It's like GPS for network communications. This GPS, you can do one of two things.
You can have a routing protocol that automatically detects traffic and shortest path and stuff like that, and automatically detects routes for you, or you can just automatically know that there's no heavy traffic across this route, so I'm gonna go and statically map this route for my BAS traffic. So that's how I answered that question.
Then we got into some other questions.
We started talking about some network connectivity things.
Specifically, we were talking about VPNs and DMZs and proxies. For those of you who all these concepts are new to you, don't worry, I'm gonna break it down for you.
Like I mentioned, you have a physical and logical network, but in most cases that network is internal for the business.
In reality, you have really two types of networks supported by two types of IP addresses. You have internal networks with private IP addresses, and these are not routable to the external network, meaning they can't be seen by some random person on the internet.
Then you have external networks with public IP addresses. The reason you use private IP addresses is two-fold. You don't want people outside of your network to be able to see all your devices, but there's also, at least with IPv4, there's a two billion IP address limit for the entire world. Folks use subnetting to create these private networking classes that can be duplicated again and again and again.
All of this is supported by a technology called network address translation (NAT), which basically, is like a data map.
It's like whenever you go and you say, "Well, SFF or SF-S means supply fan status."
You are creating a data map. Well, NAT essentially is creating that data map between your public IP address and your private IP address. I go into this a lot more in my course, but essentially that's what NAT is.
Remote Access
Next, we start VPNs, proxies, DMZs, all that remote access stuff.
Now some of you may wonder what a VPN is. A VPN is a virtual private network.
Think of your private network. When you have an internal network, that's a private network. That network is a subnet(s) within a private IP range. If you want to extend that network outside of your business, but you don't want to physically extend it, then what you're doing is you're using VPN technologies and then you are essentially creating a virtual network segment outside of your physical network.
What this looks like is that you take your VPN and essentially the person outside your network connects to that VPN. That VPN wraps all their data traffic in something like HTTPS/TLS, also known as Hyper Text Transport Protocol Secure with Transport Layer Security.
TLS is essentially the newer version of SSL. Basically, TLS is a form of primary symmetric encryption, not asymmetric encryption, but symmetric encryption.
Essentially symmetric encryption works by using is you're using a public and a private key to basically encrypt your data, and if you have access to the key you can unlock the encrypted data. That's how it all works.
I'm not gonna get much deeper than that right here because that would just start to overwhelm you with cyber security techy stuff. Essentially, what happens is you extend this network, the person logs in with their credentials, and then they become part of the network. All their traffic is wrapped in this HTTPS wrapper, so it's all encrypted as it travels across the interweb, the internet.
There's really two ways you could do this.
The first way is called IPSEC tunneling, which is you basically create an unbroken tunnel of HTTPS that goes from end point to end point. What I mean by that is it goes from your host to the switch, to the router, to the next router, to the next router, to the VPN switch and then to the private network.
Then there's point to point encryption, and that's essentially where you decrypt and re-encrypt the data at each network device. Neither one is necessarily better than the other, it just depends on what you're trying to do, whether you have control and whether you trust the network devices that you're doing that encryption and decryption on.important thing here is that it extends the network.
Contrast this to what's called a VNC. That is a virtual network connection. Common VNCs are Teamviewer, GoToMyPC. VNC software works through an agent, which is a snippet of software, that's sitting on your BAS server.
A VNC basically punches a hole out thru the network. This sounds much more insecure than it actually is, when I say it punches a hole, it's not some super insecure big hole. Basically, it creates an outbound connection.
Interestingly enough, this is the same way a lot of hackers work. They get into a network and they create an outbound connection that then they can dial back into once they have access to the network. Essentially what a VNC does is it creates this outbound connection that you can then use along with a meeting number and a password that is randomly generated.
This allows you to remotely connect to that signal device. It's very similar to RDP, which is a remote desktop protocol.
Anyways, what I was getting at is they were asking questions about, the Fox protocol, which is a Tridium protocol.
If you're on a VPN should you use HTTPS, Fox, or should you use HTTP Fox."
Basically, what was going on was they were on a VPN and they were RDPing into the BAS, and then the BAS had the Fox protocol data from the server to the different JACEs. They were trying to figure out if they should use HTTPS or not.
My answer was, well, it depends on the environment. If you're on a VLAN ,you're segmented from all other traffic, this isn't a super secure site, and you're not writing over public wifi, then you probably don't need HTTPS for your Fox protocol. You're probably good with HTTP, because if someone's inside your internal network and then they are on your BAS network you've got bigger issues than them sniffing your Fox protocol and being like, "Oh, look what I see".
You've got issues that they're on your frickin' network!
This always makes me chuckle when folks are like, "Well, if I could physically access your BAS I could plug into the USB port and hack your BAS, so you need to shut down your USB port so you're secure". I'm like, "Yeah, that's true. Sure, that is true. If you can get physical access to a machine, you can pretty much hack any machine. But isn't the bigger issue that they're in your data closet?
You would think that that would be the bigger issue! There's a lot of security controls that have failed for them to be in your data closet.
You know, it's funny to me how people focus in on these little, minute details and miss the bigger scenario. "Oh, you know what? You left your safe in your house unlocked and that's pretty insecure". Well, the bigger issue is that they're in your frickin' house going through your safe, right? It's not that you left
Well, the bigger issue is that they're in your frickin' house going through your safe, right? It's not that you left
It's not that you left your safe unlocked. That's not the big issue. The big issue's that they're in your house and you don't even know that they're in your house. That is the bigger issue.
Back to what I was saying, you've got this VPN, and then you use what's called a demilitarized zone. A demilitarized zone is basically a VLAN segment that is separated from the production network. You allow people to connect to a DMZ via a proxy server.
I go through the several different types of proxy servers but essentially a proxy server is going to filter traffic. I'm sure you've experienced this if you've ever been at work and your company uses a Barracuda proxy server for web surfing.
An example of a web filter would be if you go to Weather.com and it blocks ads, or it just doesn't let you go to sites because "The site is insecure". Well, basically what's going on is that there's a white list or a black list. A white list is when you keep a list of all the sites people can go to, and then you block everything else. A black list is where you keep a list of all the sites that people can't go to and you let them go to anything else. It depends on your security posture as to which one you take.
As I was saying, to remotely access a BAS you log into a VPN, which logs you into a DMZ. You then connect to the proxy server, and RDP into the building automation server. You've got multiple different security controls taking place. When I say security controls, I don't mean BAS field controllers. I've had folks in the past, when I was writing my book on BAS and they were like, "Phil, don't call them security controls".
Well, what do you want me to call them?
They're like, "Well, call them security mechanisms or security safeguards". No one in the IT industry says that. You'd look like a frickin' goober, so that's the thing. You don't want to be the guy who walks in there and is like, "I need five subnets". The IT guy's like, "What? What do you mean you need five subnets?" They're like, "I need five subnets for my supervisory devices". They're like, "First off, I have no idea what a supervisory device is. Second off, I can obviously tell you don't know what a subnet
The IT guy's like, "What? What do you mean you need five subnets?" They're like, "I need five subnets for my supervisory devices". They're like, "First off, I have no idea what a supervisory device is. Second off, I can obviously tell you don't know what a subnet is because you don't do a subnet per device".
That's where you gotta understand the lingo and use the proper lingo.
Like I said, controls ... Basically, cyber security's all about risk. It's all about going and reducing risk, mitigating risk. You basically look at what's going on. You look at vulnerabilities, and if these vulnerabilities are exploitable. If they are, you ask yourself what is the potential for them to get exploited and then what is the damage that could happen?
Then that becomes your risk profile. Then you go and decide on your acceptable risk threshold. What is an acceptable level of risk for you? Then once you know that, then you put these controls in place.
There's are three types of controls:
- Logical Controls
- Administrative Controls
- Physical controls
Physical controls are things like, I'm gonna barricade the door. I'm going to glue my USB ports shut.
Logical controls are things like, I'm gonna put in a firewall. I'm gonna use antivirus.
Administrative controls are things like, hey, the BAS guys are not gonna all use the same username and password. You're going to log out of the BAS when you're done using it and not leave it logged on. You're going to change your passwords every 60 days.
Bringing this all back to the beginning, like I said, you connect to this VPN, you connect to the DMZ, you connect to the BAS, and that is how you remotely access a BAS securely.
Integration
Another question I have received is what are the differences between APIs and protocol integrations?
This is a really important point to grasp, because when you think about it, all the rage, all the marketing out there is saying stuff like, "We've got an open API!"
It's like, "Woohoo! You've got an open API. You could save the world now".
The thing is that an open API doesn't do diddly squat for you, there it is I said it, add your hate comments to the bottom of the article.
Actually, honestly, open APIs can actually cause more problems than protocol integrations. Here's why. With a protocol integration, as long as everything's conforming to the protocol, for example interfacing a BACnet IP lighting and a BACnet IP BAS system, I can pretty much guarantee that the data sets are gonna match up.
For example, with BACnet, an analog value's gonna be an analog value.
Yeah, the name's may be different, and I may need to go and do some space versus zone normalization, but I'm not gonna have my AV value from my lighting show up as an Int32 and then my AV from my BAS is a float. You see if that happened then I've gotta do some casting of different data types.
Now for those of you who aren't programmers, casting is programming speak for I need to take one data type that has certain constraints and I need to convert it to a different data type, so the two things can talk.
If I don't do this the two systems won't be able to connect, because there's a data type mismatch. This is a common problem when you're dealing with integrations, specifically, integrations that use an application programming interface.
An API is an interface to the programming within the application.
What do I mean by that?
Within an application, you have a series of code.
When you write code, you'll have a class, properties, and functions. Basically, functions tell the program to do certain things. You expose these functions via an API, and then another person can, as long as they understand your data model, they can do what's called parsing the API.
This is where they go into the API, they pull data, and they get a return set of data. Then they parse through that, meaning their computer program reads through that and essentially goes and pulls in data and assigns it to the right property. But then what you have to do is you have to look at that data set. You have to look at those points and you've gotta understand the data model, and then you've to implement what's called a data adapter pattern.
Basically, this is code that you write that then is going to say, "Okay, well you're a string and I need you to be an Int16". Since both of these data types are different you are going to have to cast the string to an int or the int to a string. Essentially what is happening there is now you are manually doing data conversions. That's where creating integrations between APIs becomes really difficult, whereas you don't have that with protocol integration.
When everyone's like, "Ooh, internet of things, and everything is an API", I'm like, "Yeah, that's great. Have you ever seen folks out there in the field writing a ton of code?" I would say 5% of the folks in the field can actually get out there, write backend languages like C# or write Java, or write front end languages like HTML, Java Script, or jQuery.
Of course, you've got things like If This Then That IFTTT, or Node Red JS, which essentially are visualization layers on top of scripting code. Scripting code is where you write little code snippets that aren't full blown programs, they just run on demand. They're little snippets of code. You'll see this all the time whenever you're loading up a website where it runs a snippet of code. You may not see it, but it's actually happening behind the scene.
For example, if you go to my blog and you go to scroll off the page, what is happening is there's some jQuery running behind the scenes that are watching the cursor location of your mouse. If your mouse leaves the web browser, then what it does is it does ...
Essentially it says this, "On alert! Mouse leave area", and then basically it opens up a window. It creates a pop-up that opens up a window and then that window displays some text saying, "Hey! Sure you want to leave? You should take advantage of this free training, 'cause it's free and it's a good training".
The problem is that there's not a lot of people who know how to do that stuff. Now, I don't think every BAS person should know how to do that. I mean, it'd be pretty cool if they knew how to do that, but the pay versus skill difference there kinda prohibits it...
An average technician is making 30k to 50k a year depending on where they live ( I'm talking U.S. I'm not talking overseas where you maybe make more, maybe make less.) The average technician, if they understand all those coding principles, they're gonna go find a coding job and be making 80, 90,000 a year starting off. Here's my point with this, is that you get all these people
The average technician, if they understand all those coding principles, they're could go find a coding job and be making 80, 90,000 a year starting off. Here's my point with this, is that you get all these people
Here's my point with this, is that you get all these people talking about IoT, analytics, and APIs. The reality is it's just a bunch of frickin' buzz word bingo. Because the thing is, that while all of that stuff's awesome, there's just not a lot of people out there who can actually write the code to make this stuff happen.
Sure, there's system integrator outfits out there, but the reality is that those folks are the exception to the rule. Don't get me started on system integrators and how everyone calls themselves systems integrator now even though some of them are just doing basic installation and basic construction....
Now I get it, systems integration definitely sounds sexier and sells more, but there's a difference between true systems integrators who actually have coding backgrounds and are able to then go and actually make things happen, versus folks who just carry a lot of different product lines and do protocol integrations.
Those are two totally different skill sets. I'm not saying any one is necessarily better than the other, but they are two totally different skill sets.
Databases
The last thing I'm gonna cover is databases. I'm sure most of you know what databases are. If you've been in the BAS industry for more than two years and you don't know what a database is, um, yeah. You should probably go pick up Databases for Dummies, because not saying you're a Dummy. That's not at all what I'm saying.
Literally, the book is called Databases for Dummies. The thing is databases are pretty much how every BAS is built and what each BAS is dependent on. It can be a bit overwhelming if you think about all of the parts of your BAS data that needs to be stored.
Your properties, your point structure, your controller structure, all of that information needs to be stored.
Essentially here's how programs work on the back end. This is probably way more detail than you want to know, but what happens is one of my favorite design patterns is called the Model View Controller Design Pattern.
Basically what it is is you have a data model. That data model tells you what all the data types are. Then you have a controller. A controller essentially is going to handle all of the function calls. Then you have a view. A view is going to dynamically create your webpages.
This is something that is used largely for web applications, hence why I like it so much because I do a lot of web applications. Your controller will call a function and that function utilizes the data model. It's gonna pull data from the database, for historical data, or it's gonna know the fully qualified reference, the FQR, to go and seek the real-time data. Once again, that FQR's gonna be stored in the database. Then the program is going to dynamically generate that data on a view.
Essentially that's what's happening on a lot of building automation systems behind the scenes. That is the control architecture.
Not the controls architecture. That "s" makes all the difference
That is the software architecture that is being utilized for a lot of these, especially these new micro service based applications. A micro service is basically where you break out all the different pieces of the BAS. You run them as independent services so that if you upgrade one service it doesn't break everything else. That's what's going on.
All of these solutions are dependent on databases. This is why should at least understand:
- What a relational database is?
- What a database is?
- What SQL is?
- What queries are?
I'm not saying you need to know how to write queries and do all of this stuff, but you should at least understand what that stuff is, because that's gonna make a huge, massive difference just in how you deal with IT.how you deal with your building automation system, whether you use a local or remote database, whether you use a cloud store database, or an on-prem database, which means it's on site. These are all determining factors.
It's also going to make a big difference on how you deal with your building automation system, whether you use a local or remote database, whether you use a cloud store database, or an on-prem database, which means it's on site. These are all determining factors.
Conclusion
So there you have it. Those are my explanations behind some of my most common IT questions. These are the kind of questions I get from my IT for BAS Professionals students every day. If you want to make your conversations with IT effortless, future-proof your BAS career against the coming IT onslaught, and learn everything you need to know about IT in the shortest time possible, then you should sign up for my course using the link below.
