Hey folks, Phil Zito here and welcome back. In this post, we are going to be discussing how to perform graphics and front-end setup.
I started getting into a little bit of a debate on Facebook. Someone posted a picture of a panel, and they're like, “Hey, I like the panel.” I mean, it looked nice, and I mentioned, “Hey, I just did a podcast episode that was basically arguing that panels looking nice is great, but it's just one small piece of things.”
In reality, a lot of folks will dump a lot of money into install and into graphics and they will neglect some of the other things, like some of the front-end setup. Do you just follow the spec and put trends on everything? Do you have your alarms not tied to the actual state of the equipment? Do you give every user access to everything or give no users access to anything? You know, what do you do behind the scenes?
I know I know, graphics and panels, they look nice. People are going to evaluate your installations and say, “Hey, your installations look good.” You're going to get people out there who are going to argue and say, “You know, if I'm doing good on the things people see, I'm going to be doing good on the things people don't see.” I can follow that logic to a point, but I will say, with limited bandwidth and limited labor out there, I don't know if that's necessarily true.
So, in this post, we're going to be going through:
- What are the common graphics types?
- How do you develop graphics?
- What are the best ways?
- When do you have graphic standard?
- Outsourcing graphics
Then we're going to switch gears and talk about front-end setup.
So, when it comes to graphics, there are three main graphics that you're going to have and those are going to be your home graphic, or your home graphic is going to be the landing page graphic. Ideally, the home graphic is going to allow the user, based on what they need to do, to access whatever they need to access. Typically, the home graphic will have an overview of the central systems, the air handlers, central utility plant, etc, the outside conditions, image of the building so you can know what building you're in, maybe some general data linked to the submittal set, link to maybe any documentation, and a link to floor plans and system graphics.
The next graphic is the Floor Plan graphic. The Floor Plan graphic is just that, it's a floor plan. Oftentimes, this will be divided into multiple floor plans, and maybe even multiple, multiple floor plans. So, you take a floor and you cut it in half, then you quadrant it out, depending on how wide the floor plan is. These can be anything from real simple lines all the way to three dimensional. We’ll dig deeper into that later.
I personally can see an argument for having complex three-dimensional graphics. I can also see an argument for having text-only graphics, I could see an argument for both. It really depends on what kind of customer you're dealing with. Usually, the fanciness should not be the driving factor behind that. What should be the driving factor behind that selection should be usability and use-case.
So as far as floor plans, they typically have the temperature within the space, a link to the unit serving that space, and the link to the unit that is serving that floor.
Then we come into system graphics. These are usually template graphics for our air handlers, VAV boxes, chilled water plants, etc. They will typically include a one-line schematic, or it could be a 3D photorealistic representation of the unit with a cutaway.
Usually, it will have on the main system graphic, the primary parameters, then you'll have a link to a secondary table or graphic with the actual tuning parameters for that system. These should normally be restricted from an access perspective. You'll usually also have a link to the sequence of operations, usually in text format. And you will have a link to any schedules, alarms, etc, that are specific to that system.
Those are the primary graphics. Now, there are other graphic types that definitely exist, and those graphic types can be test and balance graphics, functional test graphics, parameter graphics, graphics of integrations and API's, or campus graphics instead of floor plan graphics. There's a variety of different types, but those are add-ons to these base three graphics.
Now, I mentioned we have to decide between photorealistic and non-photorealistic, or simple, simple graphics. If you have a user who understands what a system is, and they understand like, “Okay, if I walk up to the air handler, I'm going to be able to find the filter, I'm going to be able to find the fan,” then oftentimes, you can get away with really simple graphics, basically simplicity is best. At that point, especially if they are a self-executer, you want to give them easy access to the data.
Now, if this is a person who has never seen a system before, and they have no idea where the filter might be, or they have no idea where the fan may be, then having a really photorealistic 3D cutaway can be very beneficial, especially if it's a younger maintenance team. This can really help you to create a graphic that basically instructs them where they need to go and what they need to do.
Now, you can add to that, hyperlinks to maintenance procedures below each individual device. You can have a link to its maintenance procedures and common troubleshooting procedures and processes that makes it really valuable and can make it very beneficial for the user. You can also have links to programming and all sorts of stuff depending on what your software provides.
Now, one of the things I have mentioned multiple times is the user type. Understanding your user type, understanding what that user should be able to do, is going to drive whether or not you give them access to points.
Now let's talk about the header and system flow. So, at the top of every graphic is what's called a header. If you've ever seen the menu on a website, it has the drop-down menu. That is what a header is. It should tell you what page you're on, how to get to account information, how to go back or forward, and any hyperlinks to really important parts of the graphics and the layout. That should all be available to you.
A really well-developed header, as well as well-developed graphics, should make it to where flow is seamless. If I need to get home, I click the home. If I need to get to a drop-down to floorplan, I can drop down to floorplan and get to wherever I need.
The general rule of user-based design is the 3-click rule. A user from any graphic should be able to get to any other part of the system they need within three clicks. So, if I'm on a floor plan, and I need to get to a schedule for my chiller, I should be able to, within three clicks, get to my chiller graphic and my schedule. That is a best practice as far as user development goes.
I don't really focus a lot on mobile, because I just don't feel like it's realistic to be using mobile devices. Now, mobile graphics have come very far, especially with newer mobile devices that are large. So, that is something to consider. I personally do not want to do programming or major troubleshooting over my mobile device. I will use a breakdown list and a drop-down list of text in order to do point-to-point or if I really want to troubleshoot stuff, I ideally want my laptop with the programming software so I can dig into the system and I can dig into the actual programming to see what it's doing.
Alright, outsourcing or insourcing graphics. Graphics are one of those things like electrical subcontractors that if you don't have a lot of templates, and it's something that you don't have in-house talent, it's perfectly fine to outsource. You're going to pay more, but you can buy libraries and especially if you drive your customers towards standards, you can create a list of standard graphics, standard colors, and standard types.
These are things you should be soliciting from your customers when you do a job:
- What font do you want?
- What color do you want?
- What's your primary color?
- What's your secondary color?
- What images do you want us to use?
You should be figuring out that information and putting it into your graphics design package.
Once you have that information, some tools will actually create baseline graphics as you create your submittal. So, you create your submittal, and it will create your baseline graphics for the building automation system at the same time.
Other tools are going to require you to create your graphics on your own or from a library of graphics. You can also use graphics from graphics providers by simply Googling “building automation graphics” and finding several graphics providers who will develop graphics packages for you that you can utilize and include in your job. This is really good when you're doing 3D graphics, photorealistic graphics, etc.
It's good if you don't have that talent in-house, to outsource it. Honestly, I don't feel like that's a very return on investment talent to have on staff. I feel like that's something that can be easily outsourced.
Now let's talk about front-end setups. We have this building automation system installed, we have a supervisory device installed, we install our building automation server, or we connect multiple supervisory devices to our building to one of the supervisory devices. We say, “This is going to be our head-end device, we're going to establish our user profiles, we're going to understand our user types.”
Typically, it's two to three user types. You'll have a managerial type, some sort of analyst/senior technician type, and then a maintenance type. Those are the three most common types that you will have when you are developing a front-end and setting up your building automation system. Once you understand those profiles and types, you can set up user roles and you can categorize objects. This is where it gets very vendor specific. Sometimes you can categorize objects, sometimes you can categorize devices, sometimes you can't do anything, and sometimes you can simply restrict actions that end users can take. It's all over the board, depending on who and what product you're using. So just be cognizant of that and approach it like, “I'm going to list out what the users are going to be able to do, what they're not going to be able to do, user profiles, user roles, etc.”
Ideally, this would be listed in the specification, under Section 3 of the specification execution, but it's not always there. If you're feeling squirrely, you can submit this as part of your submittal package, just realize you might be creating work for yourself, that's may not be necessary.
Personally, I would set up one general user type with base level access and then I would come back later for a change order and customize it down to what they want. I would get really specific in their user types, their access types, like really dial it in. I know that seems like you're ripping off the customer because you’d think they should have all of this upfront, but you don't know the customer. Oftentimes, the person executing the construction is not the ones that are operating the building, so you have no idea if this is outsourced maintenance or insourced. Just plan and customize accordingly.
Another thing with the front-end setup that you really want to dial in on is your alarms and your trends. Those should be specified. They should be specified in the spec but if they aren't, then you definitely are going to want to clarify:
- What am I trending?
- What am I not trending?
- What am I alarming?
- What am I not alarming?
You want to put in your triggering criteria for that. You don't want to run a trend when the system's not on, you don't want to run an alarm when the system's not on. If the building automation system isn't on, or if a space is unoccupied, you want different settings for the alarms. You don't want to trigger an alarm necessarily.
This is all stuff we talk about in our BAS Installation & Configuration course, formerly known as BAS Startup & Checkout. Thanks for taking the time to read and I look forward to giving you more info in the next post.
Thanks a ton and take care!
