Results 27 to 34 of 34
Thread: For Osiyo on HMI Design
03-01-2011, 06:40 PM #27
Either the "thinking people" are significant or they aren't.
Make up your mind.
03-01-2011, 07:34 PM #28Permanently Removed
- Join Date
- May 2002
Three people do not make up an international wave of acceptance with Obix. Echelon and IBM apparently bailing doesn't help either, don't you think?
If you want I can send you a paper crown and we can call you King of Obix. Might as well because nothing really serious is happening with it from an international standpoint.
03-02-2011, 06:37 AM #29Professional Member
- Join Date
- Oct 2003
Keep in mind that sensor drift, as versus sensor failure, typically occurs slowly over time.
And the occurrence of a variance, doesn't necessarily mean something is wrong with the sensor. Other factors could be at play.
The basic idea here is to have some method employed which can alert an operator/maintenance person to "check it out". As versus pestering them with nuisance alarms that use arbitrary numbers, or expecting them to be staring at graphs trying to decipher whether or not they really have a problem.
Something like sensor drift, can be easily overlooked and go unnoticed. In my experience, something like the drift in a CO2 sensor is usually noted when an operator mentally notes that THIS sensor seems to be varying significantly from those installed in similar places under similar conditions.
But sometimes that doesn't happen. Operator isn't all that motivated or caring. Or person simply has so many other duties he or she hasn't the time to be staring at and flipping through screens, especially if its a LOT of screens.
I'm not faulting building maintenance techs. I've had more experience being an in-house guy than I've had being an outside contracted services guy. So I'm well aware of the fact that they've got a lot more to do than just sit there looking at pretty screens, or going through long lists of historical data trying to decipher if they have a problem or not. Typically, phone is ringing off the hook or emails are pouring in about stuff folks are complaining about NOW, demanding their attention. And then there are the regular, routine duties they need to get done, that special project needing to get completed, etc.
They over look stuff, don't notice stuff, aren't there watching when an abnormality occurs, haven't time to switch to similar whatevers and compare what they see on THIS one to THAT one, and so forth.
So stuff gets missed. Or goes unnoticed because its not a failure, its just an indicator that something is not working as well as it should.
03-02-2011, 06:48 AM #30Professional Member
- Join Date
- Oct 2003
Some things we've been discussing come under the heading of long term care and feeding of a facility. And are probably better handled as a later, separate job/contract, as versus something to be fully implemented during the initial install.
Many a facility ... is not working nearly as well nor efficiently two years (or 5) down the line from the install as the installers/designers might assume. And there are many reasons for that.
I have a friend who works for an energy management firm which makes a living doing just that sort of thing. They come along AFTER, do audits and studies, suggest changes and adding additional items to HMIs, or programs that'll sift through raw numbers and produce useful results, or altering sequences of operation that don't work as well as thought at first blush by the original designer(s), etc.
03-02-2011, 07:52 AM #31Permanently Removed
- Join Date
- May 2002
"Didn't really think you could."
What's happening is that the controllers are getting significantly more powerful. Problem is our programming for sequences go back years and took into account less processing power.
So, it seems to me you can run your normal HVAC sequencing and then have another program(s) doing localized analytics.
03-02-2011, 11:04 AM #32Professional Member
- Join Date
- Oct 2003
03-02-2011, 11:09 AM #33Permanently Removed
- Join Date
- May 2002
I thought about this when I looked at a project they did in Vienna. They had somewhere between 7-11 individual programs running in the device controlling complete rooms (lights, blinds, access, hvac). Since the controller also had local AST it would be nice to access this directly to analyze this information with a program and make some qualified notifications.
03-03-2011, 05:57 AM #34Professional Member
- Join Date
- Oct 2003
I did not pick up on the idea that when you mentioned "localized analytics" that you specifically meant programs buried with the local controller.
<Shrug> I suppose you could do that, at least to some extent. If that seems to be the appropriate approach in a given situation. Field controllers capable of running multiple programs have been around for years.
I'm rather fond of them myself. Just because of the old KISS principle as much as any other reason. i.e. Instead of one possibly long and convoluted program with subroutines that might be doing particular functions unrelated to other major activities, break the darn thing up into smaller, simpler apps. That's a lot easier to troubleshoot and debug. More clear and straightforward. Etc. Or you get a situation like one I worked on where a single controller was handling a pair of HW pumps, their VFD's, etc with need for system error checking, lead/lag control, automatic switch to backup when/if required, plus periodic switch of lead based upon any of 4 user selectable methods. Plus individual control routines for each of four boilers. Plus master boiler control which monitored all 4 boilers for faults, would lock out faulty boiler from the firing sequence, kept track of overall system demand and call for boilers in stepped sequence, kept track of sequencing and would rotate sequence order based upon any one of 4 user selectable methods (manual switch, weekly, monthly, run hours). Was just easier to do such a thing with 6 separate programs in the one controller. Programs were smaller, simpler, less convoluted, easier to debug. Then I tossed in a 7th app which monitors the other 6 and if any faults, locks up, aborts or whatever, it restarts the app and signals the front end about the problem.
I also, as a matter of principle, like to offload as much of the work to be done off any front end. Again, primarily a KISS thing.
i.e. Was just working with a controller yesterday that controls a number of different items. For whatever reason, whoever originally did that job, and it was probably several different hands/minds over a period of years as things got revised, the controller had a couple embedded programs; and the front end ran several other apps which manipulated other of the controller I/O besides those controlled by the 2 apps in the controller. Who knows why, I don't. Anyway, I revised things so as to move as much programming into the controller as possible.
Now all the front end needs to do is feed the controller some global data, a few pieces of info, and of course, fetch data as required to fill in the blocks of the pretty pictures on the front end display, collect trend data, etc.
In and of itself, a small thing. But decreases overall network traffic. And decreases overall workload and resource usage at the front end. Just a little bit. But each little bit helps. That front end was running not only the stuff it needed to do, front end stuff, but it was also running over 100 apps that could just as well have been moved into the controllers on the system. Front end screen updating is now snappier, there are fewer retries at data collection due to fewer timeouts caused by busy network, etc. And, if front end dies, network dies, or whatever, that controller I mentioned keeps chugging and doing its thing and the equipment attached keeps operating.
No particular need to remind me of the advantages of field controllers which can run multiple programs internally. I'm a fan of this.
But back to the original thread.
Someone, and I forget whom ... sorry, posted a link to an article which discussed the subject briefly. Mentioning that the new "in thing" has been the so-called dashboards. Which aren't such a bad idea, but in fact do little to quickly, easily alert an operator of a possible issue.
I agree with this thought.
Not that I'm in favor of presenting less data at the HMI. One of the issues I run into regularly and often is a customer having problems related to his/her NOT being able to see or adjust this, that or the other thing because its not shown on the front end screens, or shown but not as an adjustable piece of data/control.
i.e. A few weeks to a couple months ago I responded to a list of complaints from a customer. Original controls and front end was done by someone else. Several of the issues were caused by just the sort of thing I've mentioned. On various items customer was seeing set points, not the calculated set points, which caused confusion and assumption that things just weren't working right. Also, for a number of control loops, customer could not see, much less adjust what measure variable was used, what reset measured variable, reset amounts allowed, when reset started, when reset max was to be in effect, and so forth. Also could not see nor adjust certain time delays. Which SHOULD have been on those screens.
Etc, etc. Yadda, yadda.
I see this routinely. Where controls tech/engineer decides he or she knows better than the operator who has to live with the system day in and day out, and/or for whatever other reason decides owner/operator doesn't need to know or adjust whatever. Maybe just lazy or cheap, and doesn't want to spend the time revealing the extra control points. Or wants customer to HAVE to call them to make changes.
Who knows? I don't. Just know I resolved many of their issues by putting that stuff in logical order, in logical places on the GUI. And then explaining how stuff works. Just in case, also gave em a button to click, a "Help" button in the reasonable/logical places, that'd pop up a written explanation of sequence of operation and/or description of how control loop in question worked. What did what, why, and how. Knowing that people forget the info I give them by tomorrow, or the week after next at the latest.
Customer's in my experience LOVE those pop up explanations.
But one should also avoid TMI.
Crowded screens, very busy screens, screens with too much info, too many pretty pictures, too many colors, etc just distract or confuse, or cause the important info relative to the particular task and purpose at hand can make the operator's job more difficult.
It can be as simple as one case I saw. Air handler screen with graphic of air handler showing, complete with moving dampers, spinning fans, coils that turned red or blue, etc, etc. AND all sensors shown along with values. AND with bunches of other stuff shown beneath, as in with some dashboards.
In regular whole screen view, operator had to squint and stare and put nose close to the screen to read the little text/numbers. Other things he had trouble making out because like 1 of 4 males, he's partially color blind. Whoever made the screen used too many colors and shades thereof. To this guy's eyes it made some stuff hard to discern.
So one of his solutions was to magnify screen. Which then meant he had to scroll stuff back and forth, up and down, to look over the screen.
Really? All that stuff needed to be on one screen? Why?
He was just wanting to, on most occasions, do a fast look as see if things appeared to be okay with that air handler. And the other couple dozen.
And he had other chores to do to earn his paycheck. Didn't have time to be spending long periods looking over all that stuff. Especially since much of the data on the one screen was routine and not really important to see all the friggin time.
So I cleaned things up for him. Got rid of the excess color usage. Made basic AHU graphic larger. as well as the text/numbers. Moved the stuff that he did NOT need to see for purpose of simple system check to other logical screens. Buttons on screen let him jump to those other if needed. And back to same screen, or to summary page, or to home page, etc.
Giving him summary screens helped him a lot.
i.e. AHU summary page.
Actually, pages. His facility has enough AHUs so that showing all on one page was problematical.
So they're broken down by major areas of the building.
Just lists AHUs serving the area, shows if running or not; schedule occupancy status; high, low, and average temps of spaces served by particular air handler, block which states whether air handler "Okay" or has an alarm or warning condition. That's it. If he sees something or has questions, click on name of air handler which is actually a navigation button and he goes immediately to main air handler screen for that air handler. Click on Alarm or Warning text, actually a navigation button and he gets pop up telling him precisely the nature. Can close that or click and go to air handler main screen.
Main GUI screen, Home, also shows if any alarms or warnings are present anywhere. Same deal, click, details are shown. Click again to go to screen for equipment generating alert.
I think all the numbers and details should be available to the operator. On the appropriate screens in the appropriate places.
But he or she should not have to wade through all of it all the time, and have to spend an hour just trying to figure out if he or she has a problem needing attention.
Summarizing, or analyzing data, can be helpful. Especially to the busy building engineer/operator.
And that often does not mean showing a pretty graph being updated live on his/her screen. What's with that?
Okay, at first blush, and until the "new and nifty" wears off, it looks neat and helpful. But is it really?
Does a guy, an operator, need to see a running trend chart of energy used by a supply fan? What's it tell him that is helpful? Especially when its gonna vary all over the place based up ambient, demand, TOD, occupancy, whatever.
Maybe a better approach would be collecting the data to show VAV measured usage in CFM against motor energy currently being expended. Could be like those miles per gallon indicators on some cars.
You could also show current performance versus historical performance. Make it better, also account for variations in air temp, humidity being moved by fan, and current duct pressure maintained. The idea being to try to compare apples to apples, and oranges to oranges.
Once you've collected enough data to have a base knowledge to work with, add a routine which looks for and warns you when CFM used by VAVs versus energy required to provide the air seems to be going out of bounds compared with known previous performance.
NOW ... you've got something that tells the operator something useful.
And you're detecting possible waste of energy. Maybe an impending equipment failure. Etc.