# HMI design and balancing virtual vs hardwired componets



## jcaden (Oct 30, 2016)

Yes, use color to highlight similar buttons, for alerts, etc., not to fill up all the spaces. Keep it simple and informative. Don't use HMI buttons for functions that are actuated very often. It will put wear marks on the screen, which may impede operation or visibility. Don't use HMI buttons for functions that require quick intervention by the operator, such as parts feed shutoff, etc. If the HMI happens to be on a different screen when the operator needs to shut things down, it takes valuable time to change screens.


----------



## gpop (May 14, 2018)

Modern hmi have way more memory then the old ones so you can program as many screen as you like. 

If the screen is small forget about trends as they are to small to read. Also avoid alarm screens that are to small to read and if you are using them in the field some colors do worse in sunlight than others.

Our lift-stations all have hmi's installed. We have the main screen (mainly info), logbook screen, settings (so we do not need a plc to set up level sensors etc) and alarms (each alarm can be clicked on to open a help guide). We still have hoa switch's as its the easiest way to test a station. 

We have different types of lift stations (vfd/starter/etc) but only one hmi so everything has a familiar feeling. That also means we have a lot of on/off controls in settings to add or remove what is displayed on the main screen. e.g we can display vfd load or amps. simply select vfd available and it hides the amp readings and displays the vfd readings and vise-versa


----------



## splatz (May 23, 2015)

This is based on limited experience so take it for what it's worth. I love reliability and hate emergencies. It seems to me like HMI can reduce reliability because they concentrate a lot into a single component. Electronic components are often less reliable than the physical components they replace. On the other hand, I think sometimes for that same reason, virtualizing components makes it easier to achieve redundancy, where a single failure doesn't take you down, and easier to inventory spares.


----------



## just the cowboy (Sep 4, 2013)

mburtis said:


> I'm starting to work on building some HMIs for around the plant and thought it would be interesting to gather some input from those more experienced in regards to things to do when designing an HMI and things to avoid. I've been researching design lately and ran across ISA 101 and other resources making the case for very simple graphics with very limited animations while focusing more on showing trends and range gauges etc. Very limited use of color as well. This actually makes a lot of sense to me. I don't need pretty pictures I need to know what is going on.
> 
> The second topic I thought would be interesting is peoples opinions on balancing what you put into the HMI vs keep as a physical device. I always have debates with myself as to whether it is better to actually hardwire somethings or just give in to modern tech and just run everything to the plc/HMI and do every thing via programming. I am not talking about any sort of interlocks or safety features here, just regular input/output type of stuff. Personally I'm not a huge fan of HMI buttons but it's just so much cheaper and easier to use virtual buttons and indicators now than actual physical ones.


First part is what is called " High performance graphics" and I am going in that direction now with my upgrade. At first I was not a fan I am old school but after we did our first plant I like what I see.
















As for the second part, if it is used a lot or critical I use a button ( resets, jog, manual run).
I have seen a broken HMI screen from operators hitting a reset over and over, the old machines had PB and they just kept pushing it over and over fast till it reset saving milliseconds to prevent a jam.

My general rule is don't let money ever decide a choice, reliability is the main thing. I have work in places where it was $15,000 a minute for down time or tens of thousands to replace pipes.


----------



## Easy (Oct 18, 2017)

I'm not a big fan of touch screens. That's why the mouse and track ball were invented. I really have very limited experience in automation but do mess with programs designed for graphics and audio.
I would think there were ways to set up hot keys on a keyboard to control a processes. It looks all sexy having a nice control surface to work with but honestly wouldn't it be better to save the screen for viewing and use a keyboard to control stuff. Do they even make such an animal for industrial use. Here is one for editing audio as an example.


----------



## just the cowboy (Sep 4, 2013)

Easy said:


> I would think there were ways to set up hot keys on a keyboard to control a processes.


Keyboard for starting in automation don't work great due to the fact that if you drop something on it you don't want to change a process. Keyboard and mouse for central control, remote sites are touch screens. Touch screens are placed so you have to make the effort of touching them.


----------



## Easy (Oct 18, 2017)

just the cowboy said:


> Keyboard for starting in automation don't work great due to the fact that if you drop something on it you don't want to change a process. Keyboard and mouse for central control, remote sites are touch screens. Touch screens are placed so you have to make the effort of touching them.


That seems logical. Especially from a safety stand point.


----------



## MoscaFibra (Apr 15, 2021)

Very few rules I try to keep too - simple is better. You can make some very fancy graphics now, but if they take away from the information they will hinder performance.

I hate nuisance alarms. Actually hate is an understatement. If an alarm can be ignored forever why even have it. The number of sites I’ve been on with 100+ active alarms is staggering. Pharma is the only site I’ve been on that doesn’t allow it.

accuracy in your layout will save time in your troubleshooting. If you can trust what and where your sensor / valve is in the depiction on the hmi it will save you time when things break down. We would literally disconnect our”fail” every component in an hmi once it was set up to verify that the right temp was in the right spot etc.

navigation is very important, if you can only get to one page by clicking through 5 other pages, you might as well save yourself time and not do it….

i feel like I could go on for too long about this


----------



## paulengr (Oct 8, 2017)

mburtis said:


> I'm starting to work on building some HMIs for around the plant and thought it would be interesting to gather some input from those more experienced in regards to things to do when designing an HMI and things to avoid. I've been researching design lately and ran across ISA 101 and other resources making the case for very simple graphics with very limited animations while focusing more on showing trends and range gauges etc. Very limited use of color as well. This actually makes a lot of sense to me. I don't need pretty pictures I need to know what is going on.
> 
> The second topic I thought would be interesting is peoples opinions on balancing what you put into the HMI vs keep as a physical device. I always have debates with myself as to whether it is better to actually hardwire somethings or just give in to modern tech and just run everything to the plc/HMI and do every thing via programming. I am not talking about any sort of interlocks or safety features here, just regular input/output type of stuff. Personally I'm not a huge fan of HMI buttons but it's just so much cheaper and easier to use virtual buttons and indicators now than actual physical ones.


Partly true. Here is the issue. In a process plant they usually have very few buttons if at all. And they use mice. But if the network/computers fail no matter how much redundancy you have, you at least need a way to shut things down safely. So even if it’s just one E-Stop you need that.

Beyond that ISA is mostly chemical plants, refineries, and paper mills making stuff not things. What they recommend is very narrowly focused. There are three problems to overcome. One is the stuck button syndrome. One of the worst HMI designs is where you hold down a button for say a crane movement. If the PLC misses a button press people naturally just tap it again, even on hard wired buttons. But in most HMIs if the PLC misses the “release” signal you’ve got major issues. So avoid that type of function in an HMI. No matter how clever you are you can’t fix this one. In fact I actually do all my programming on release, not on press. Why? This goes back to the data of the first Macs. If you press a button then change your mind you can slide off and let go and nothing happens. People often do this subconsciously because it’s built into Windows, MacOS, etc. So just a huge hint.

Second is consider environment. You need to keep that thing cool. Easier said than done. And clean. And don’t forget operators will wear gloves with grit, grease, oil, etc., and try to use the touch screen. Consider environment. Some places shouldn’t use them. Some are better than others. Red Lion is crazy expensive but holds up to a lot of abuse.

Third is if it’s a touch screen especially but even with mice (which are often worse) when it fails you didn’t lose one button and you don’t replace just one…the whole thing gets replaced. So if you get say 1 million presses and an operator presses a button on every machine cycle how fast will it wear out compared to hard wired buttons? And do you have to get a specialist to replace it? Hard wired buttons are good for machine operations. Touch screens are good for settings, reports…things you do once in a while.


----------



## SWDweller (Dec 9, 2020)

I have not done HMI for a long time. I considered them a nuisance and a way for workers to get lazy. A machine HMI with 1-2 screens for trouble shooting sensors is a different animal. It used to be that Estops could not be in software. So what is the point of providing a screen that you can not use to shut down the machine in a hurry? 
We used Panel Mate, WonderWare and Iconics for HMI's with the computers. 
The only ones that made sense to me were the customers that were watching their peak demand/load shedding. Where breaking the monthly number cost 10's of thousands of dollars or sometimes your job. Complicated screens with lots of information will not be used quickly. Mimic bus of switch gear with red and green buttons was some of the more stupid screens I worked around. If a 1000 amp breaker trips there will be enough alarms that it opened you do not need a screen. Unless of course your 10 miles away. Then you have the network delay time. .
I tend not to trust anything unless it is wired. 
I did a job in Vegas for a casino using Carbon Copy to the bosses laptop. When he was up at his cabin on a 14400 baud telco line. Took for ever to refresh. He paid us for it and I got it to work.

Today world most people can not use a computer with out the gui. I was pretty much forced to learn DOS so I can still go to a command line and type commands.


----------



## mburtis (Sep 1, 2018)

Some really good input, that I appreciate a lot. For further clarification this is for a surface water treatment plant (drinking water) so the environment could be almost considered clean room ish compared to a plant or shop floor environment. I spent part of today building a screen on the automation direct software and actually really like what I came up with. I'm just barely learning how to use the software so still have to figure out how to make everything act and look how I want. We have an existing SCADA system but honestly it sucks and is basically an excellent example of lots of pretty pictures and very little data. Our screens literally have drawings of pipe couplers and elbows and stuff yet when an alarm goes off you have to navigate from the overview screen to the alarm screen and see which alarm is going off, then you navigate to the trend list and then select the trend you need just so you can see if the sensor just caught a random spike or if something is actually going wrong. 

This is a slight tangent but goes along with the wire vs virtual. We have a valve that is common to all our filters. There is a open/close switch for manual control on both of our control stations. Back in the 90s they went through a lot of effort installing a bunch of relays and wiring to get this to work outside of the plc. With the modern reliability of PLCs I can't help but think any more it makes more sense (even from a troubleshooting standpoint) for a set up like this to just be input into the plc and then have the plc control the valve. Bear in mind that if the PLC goes down this valve is going to be the least of our worries. 

I'm fairly young, at least around this crowd, but I'm still highly biased towards hardwired physical components. However I'm trying to evolve to embrace the benefits of the modern tech where it makes sense. I'm sure in a few years traditional HMIs will be a thing of the past and wireless connected tablets will be the norm.


----------



## gpop (May 14, 2018)

Don't get Hmi and plc's confused. We use the hmi to interface with a plc and avoid programming in the background of the hmi at all cost.

If you have programmed the plc with a little pre-thought there is no reason a hmi should be able to do damage to the system. Yes you can enter 150% as a set point for a tank level but the plc should have logic to prevent this from happening. Unfortunately that also means the code can become bloated with a bunch of logic simply being used because of the display. 
If the plc crashes which should be a very rare experience everything should be programmed and wired to fail safe which is a advantage over switch's and buttons. 

The hardest thing to program always seem to be the alarms. I wish i had some advice when it comes to this but it always seems to be a work in progress. Just when you think you have made it idiot proof someone comes up with a better idiot.


----------



## mburtis (Sep 1, 2018)

The reason I bring up the valve control being hardwired vs moving it into the plc is that I have another very similar valve. Originally it was controlled by a rate controller even in manual, which are now failing and obsolete. What I want to do is set it up like the other valve that has an open/close switch and the operator can just open the valve while watching the flow meter to set the desired rate in manual mode. I have been debating whether to hardwire the entire thing like the other valve, use physical buttons as inputs to the plc and use the plc to open and close the valve, or put buttons on the hmi in place of physical buttons.


----------



## gpop (May 14, 2018)

mburtis said:


> The reason I bring up the valve control being hardwired vs moving it into the plc is that I have another very similar valve. Originally it was controlled by a rate controller even in manual, which are now failing and obsolete. What I want to do is set it up like the other valve that has an open/close switch and the operator can just open the valve while watching the flow meter to set the desired rate in manual mode. I have been debating whether to hardwire the entire thing like the other valve, use physical buttons as inputs to the plc and use the plc to open and close the valve, or put buttons on the hmi in place of physical buttons.


If i was doing that i would have a hand/close/auto set-up on the screen.
Hand would give you 2 buttons.
closed (if that's default fail safe) would drive the valve closed
auto would have a box with required flow rate (min and max limited in plc). The plc would step or use a pid to match the required flow to the feed back from the flow meter.

I would also use a little code so transition between auto/hand was a seamless transfer (e.g if auto was 50% then manual would start at 50%)


----------



## mburtis (Sep 1, 2018)

gpop said:


> If i was doing that i would have a hand/close/auto set-up on the screen.
> Hand would give you 2 buttons.
> closed (if that's default fail safe) would drive the valve closed
> auto would have a box with required flow rate (min and max limited in plc). The plc would step or use a pid to match the required flow to the feed back from the flow meter.
> ...


Thanks for the input, I have pretty limited experience so I always question if my ideas are good. Given this is an existing console there is already a manual/off/auto switch for the filter so I don't really need one for the valve itself. Other than that your suggestion is basically what I was planning.


----------



## SWDweller (Dec 9, 2020)

Have you passworded your application?


----------



## mburtis (Sep 1, 2018)

SWDweller said:


> Have you passworded your application?


At this point I'm mostly just playing in the software trying to figure out how to use it. I haven't even started looking at passwords or other security stuff. Our SCADA system has a log in. The screens I'm going to be building are not going to have remote access and the plants are behind locked gates. Mostly going to be data display, very few controls on the screens. Plus somebody could mess a lot more stuff up a lot faster by flipping the existing hardwired switches on the existing console. Unless your talking about protecting the programming. Also not worried about that, I'm the only one with the guts to mess with this sort of stuff. Everyone else is scared they are going to break it.


----------



## just the cowboy (Sep 4, 2013)

mburtis said:


> At this point I'm mostly just playing in the software trying to figure out how to use it. I haven't even started looking at passwords or other security stuff. Our SCADA system has a log in. The screens I'm going to be building are not going to have remote access and the plants are behind locked gates. Mostly going to be data display, very few controls on the screens. Plus somebody could mess a lot more stuff up a lot faster by flipping the existing hardwired switches on the existing console. Unless your talking about protecting the programming. Also not worried about that, I'm the only one with the guts to mess with this sort of stuff. Everyone else is scared they are going to break it.


Set time up to come down and see my systems.


----------



## mburtis (Sep 1, 2018)

I'll keep that in mind, I would love to see an actually legitimate set up. I have high ambitions for our podunk system, just not sure I'm smart enough to learn the skills needed on my own. Was actually down that way a couple months ago to take the kids to the zoo in Colorado Springs. I'm sure I could talk them into going again.


----------



## paulengr (Oct 8, 2017)

Usually I have a "HMI" ladder somewhere in the system. It mostly does "hand shaking". Alarms are a great example of where this is useful. For instance a typical alarm sequence is that first a bit turns on indicating an alarm. The HMI starts flashing or puts it on an alarm list. Now in some systems the alarm stays up there until the operator acknowledges the alarm. That way if they are doing rounds and something "blinked" they can still see that it happened. So when the operator acknowledges the alarm, the HMI sets another bit indicating that it is acknowledged/reset. At that point the PLC clears the alarm. Another example is clock setting/synchronizing code. Or "queueing" code where the PLC loads events into a log that can store say up to several hours worth of events and the HMI unloads and stores them into a database where losing records is a bad thing and we want to survive communication problems. Another example is "mode code". Sometimes it is useful for the PLC to force the HMI to go to certain screens. As an example in a foundry we had a radiation detector. If it went off the PLC locked down all the controls and forced the HMI screen onto a special "blank" screen where it took away all the control buttons until the operators cleared he radioactive material out of the system. Another typical "mode" control is when there is a separate maintenance mode which does different things and often eliminates any or all interlocks but it is important to make it impossible for operators to be able to "run" the system in this mode.

I have no problem with "programming" in HMI's but this should be doing things best done on a PC. For instance in one plant the recipes were stored in a large database. Updating the PLC with the entire database and doing searches was fairly complicated to do at the time (AB PLC-5). So instead the PLC simply stored a "recipe name" and the HMI system looked up the corresponding recipe and loaded everything in. Producing "QC records" and storing them into a database is also something best done by a PC and again, some handshaking code and buried logic in the HMI is often done. As far as "number validation", it's so easy to program an HMI with an allowable number range in many of them that you don't need any error checking code. In others you really need this code because there is no way to do it on the HMI side. Also PC clocks are vastly more accurate than PLC clocks, and they have access to NTP so it's generally better to sync the PLC clock to the PC, not the other way around, and this often requires some code on both sides.

I'm OK with PC-based control EXCEPT that I would only do this in an embedded controller situation where I have 100% control over every aspect of the system. In cases where there is a lot of heavy duty number crunching such as curve fitting to scientific data this is a place where it is best done outside the PLC and at that point maybe even controlling the process.

As far as hardwiring vs. software, PLC's greatly simplify things. Think about troubleshooting a burner safety system. Typically it has sensors to verify that all fans and pumps are running, air flow, air pressure, fuel flow, fuel pressure, damper positions, and so forth. Typically you will have 5-10 sensors all in series and troubleshooting a faulty one can be very challenging. In contrast with a PLC system typically everything is very simple. There are 2 wires to each output, 2 wires to every input. You troubleshoot every device separately. It goes MUCH faster. And if you have access to it, the PLC actually helps you if you know how to use it as a troubleshooting tool. And I agree with the statement made earlier. Historically with automotive companies they had huge 6 foot wide by 8 foot tall relay cabinets that controlled the entire production line. When a new model came out they would tear out and throw away the entire panel and replace it with the one for the new model. This cost them a lot of money and time. They came up with programmable relay controllers so that they could simply load a new software program into the system to save on the cost of relay panel replacement. What immediately happened is that because so many of the relay functions were done in software in the PLC they saw a huge increase in reliability and a huge decrease in troubleshooting time. So they quickly began using PLC's everywhere strictly for the decrease in downtime.

When it comes to HMI's it's a mixed bag. PC-based HMI's are running on horrendously unreliable hardware. So in a lot of plants it works best if reliability is important to have at least 2 or more HMI's. If it is a large control room, you will end up going with servers and multiple PC's that are basically nothing more than graphics terminals connected to the servers (which should be redundant). With standalone HMI's the vast majority are only slightly worse than PLC's in terms of reliability. It usually pays to have a backup/spare but it's not as bad as PC's. Plus PC's tend to crash for all kinds of reasons you can't anticipate like when the operator figures out some way to get out on the internet and downloads all kinds of crapware and viruses on it.


----------



## mburtis (Sep 1, 2018)

Your thoughts on PC vs plc/hmi is interesting. One of the reasons I'm starting to work on setting up some standalone screens is because our PC based SCADA system keeps having problems. I'm hoping to add some sort of redundancy by having some simple screens with our important data displayed and possibly set up some data logging. That way we can avoid any losses in data when the IT guy shows up at 3:00 in the morning and starts unplugging network cables because his software picked up some security threat in our computer.


----------



## mburtis (Sep 1, 2018)

Thought I would share a picture of a simple overview screen I've been playing with this week. This was just a learning project using an automation direct headless hmi hooked to a TV. Did learn how to hook in and read data from our allen bradley plcs and started to figure out some of the hmi software. I've been messing with it and changing color schemes etc but everyone seemed to like this high contrast dark theme. Not exactly following the rules of high performance hmi. Probably wouldn't be the best if you were going to stare at it all day or if you were green color blind but as a stripped down plant operation screen it's plenty functional. 










A screen of basically the same function in our existing SCADA system which I don't really care for.


----------



## paulengr (Oct 8, 2017)

mburtis said:


> Thought I would share a picture of a simple overview screen I've been playing with this week. This was just a learning project using an automation direct headless hmi hooked to a TV. Did learn how to hook in and read data from our allen bradley plcs and started to figure out some of the hmi software. I've been messing with it and changing color schemes etc but everyone seemed to like this high contrast dark theme. Not exactly following the rules of high performance hmi. Probably wouldn't be the best if you were going to stare at it all day or if you were green color blind but as a stripped down plant operation screen it's plenty functional.
> 
> View attachment 158033
> 
> ...


The pictures are there to help new operators feel more comfortable with what they are looking at. If done correctly you can also tell at a glance if something isn’t right where on all data screens you can’t. Trend charts are even better.

I always go through this cycle with operators where we start out with a decent functional screen. Then we jam more and more on the same screen until it becomes a jumbled mess. Invariably this is when the HUGE monitors and 5 screens per PC start showing up. Then we go back to something in between the first time there is an incident and part of the root cause is nobody is able to focus on what is important. This is also when alarms get fixed.

You can see this with PCs too. First we had limited functions. Then sub menus on sub menus. Then this was replaced with the most ugly OS ever, Windows 8. Then it’s back to the old XP days except Microsoft continues to play hide the button.

So I hear you but trust me, those all button or all number screens are trouble. They are attractive to the guy that just records data off the screen, which I have a serious problem with. I mean it’s on a computer, why are you logging it?


----------



## SWDweller (Dec 9, 2020)

I never cared for the screens. On critical processes the screens were so far behind like seconds that it was inevitable that an operator would say ya I can hear the alarms, nothing on my screen,,,, yet. 
I built most of my stuff on NT and refused to go any farther. Long before 8 came the ME edition was was just crap. Nothing worked and nothing would share. 
I will admit that state of the art was Carbon Copy. 
I had a graphics package done for a power plant, then the sales person told me I had to connect the bosses new laptop ME via the phone line. Thank fully the job was in Vegas and there were lots of distractions when I was not preforming the surgery to get it to work. Almost went out bought a new laptop for him without Me


----------



## paulengr (Oct 8, 2017)

SWDweller said:


> I never cared for the screens. On critical processes the screens were so far behind like seconds that it was inevitable that an operator would say ya I can hear the alarms, nothing on my screen,,,, yet.
> I built most of my stuff on NT and refused to go any farther. Long before 8 came the ME edition was was just crap. Nothing worked and nothing would share.
> I will admit that state of the art was Carbon Copy.
> I had a graphics package done for a power plant, then the sales person told me I had to connect the bosses new laptop ME via the phone line. Thank fully the job was in Vegas and there were lots of distractions when I was not preforming the surgery to get it to work. Almost went out bought a new laptop for him without Me


You need to look into better software and hardware.

Ok can you tell me if there is a stable version of Windows OS out there? Crickets. XP was pretty good and 7 is not bad. But let’s open your mind a bit. Have you considered say Ignition as the HMI software? If you use a stable underlying OS like Linux and put it on a disk less fanless Celeron type industrial PC, you have a box that will last for YEARS with no moving parts. That’s if you need nice trend charts, networking, PDF reports, all the high end features. One of the best things is you can right click on ANY number on the screen and select trend chart and right there it makes a chart from scratch, no programming needed.

But if all you need is a display panel look at say an Automation Direct C-More. Again…disklesz, fanless. You can get it as a “headless” version (bring your own screen/keyboard/mouse) or with your choice of screen sizes. It can also act as a web server so you can view it from your phone, ANY phone. These will outlast all that PC stuff and with little or no OS, no crashes.

If operators want to browse web sites, do reports, or watch Netflix they need to do that on an office PC, not the control system. I have no problems locking down “desktop access” every time.

Wonderware is hands down the most heavily advertised HMI but also the crappiest. It can’t even handle multiple monitors or screen resolutions and everything is the same since the 1990s. It is heavily entrenched in a Windows 95 style architecture. So you need to get away from this one as an example.


----------



## mburtis (Sep 1, 2018)

That's one of the reasons I'm working towards learning basic stuff on the automation direct stuff. Our existing SCADA system is a deck of cards just waiting to fall down. I don't want to touch it and get involved in that bsd contest. A 400 dollar hmi isn't going to replace 30k worth of SCADA software and computers but it can do enough that if SCADA crashes the plants aren't running blind and we can log enough data to maintain compliance. Plus it's good learning.


----------



## paulengr (Oct 8, 2017)

mburtis said:


> That's one of the reasons I'm working towards learning basic stuff on the automation direct stuff. Our existing SCADA system is a deck of cards just waiting to fall down. I don't want to touch it and get involved in that bsd contest. A 400 dollar hmi isn't going to replace 30k worth of SCADA software and computers but it can do enough that if SCADA crashes the plants aren't running blind and we can log enough data to maintain compliance. Plus it's good learning.


Ignition is about $10-15k with two server licenses for redundancy and unlimited client licenses, reporting and database, trending, etc. You can run it on disk less fanless PCs that cost around the same price as C-More. Client installs are a dream. You point your PC at the server website and it self installs. That’s it. You can give out “view only” privileges to managers too. Think about it…unlimited licenses. If things died in the middle of the night and there is a 24 hour Walmart nearby, there is your “backup strategy”.

Speaking specifically to water plants though you can run into network problems. So a basic C-More or just regular old buttons and switches keeps you going. I mean the days of $5k PLCs and $3k for a display at a booster/lift station should be gone when you can get a PLC and display for $1000 that does everything you need locally. That’s cheap enough you can buy a couple spares and have them ready to go. Also look into Ubiquiti network equipment. As an example on my first install I put one radio on each station around a wastewater plant. There are two redundant paths (it’s all mesh based) from every radio in the plant. Radios were under $250 each. Ubiquitous has stuff that can do this over miles of distance. Speeds in the tens to hundreds of megabits. This is way beyond UHF or cellular speeds. With this stuff server-SCADA with terminals in every station makes sense. Without it if you lose radios or are waiting on SLOW response times can be very frustrating.


----------



## mburtis (Sep 1, 2018)

For our main SCADA system we are currently running a windows based factory talk system along with SQL and virtual machines and a bunch of other crap I don't understand nor want to. Add in that the main guy that programmed it a few years ago is a pita and now our corporate IT guy who is tight with the big boss is sticking his fingers in the pie. 

Perfect example just this week. The computer at the satellite plant randomly decided to switch its setting from a work network to a public network. This prevented factory talk from loading. Called the IT guy, never heard back. Finally had to call the programmer guy 3 days later and he was able to fix it. BUT this meant that plant was essentially blind for 3 days and our remote laptop for the on call person was out too. 

I'm no where near smart enough to build full blown SCADA but if I can make it so we can run the plant from the plant with SCADA down, I'll be happy. I could technically turn remote access on to a c more hmi, but remote security is an area I'm not touching with a 10 ft pole.


----------



## SWDweller (Dec 9, 2020)

I have a friend that went to school for network security. First job was for Boeing, lasted 3 years there got his Masters degree. Now works for Microsoft, cloud security, the stuff the military uses for sharing data on the battle field. Working on his PHD.
Can't ask about work any more. Most of it is over my head and he would probably have to kill me if he did tell me. 
Security is a fleeting thing if you have a connection to the world. I have only done closed systems, not on the internet and have refused to work on the others. It is a personal choice, based on the type of business the system was supporting. Anything with life/medical attached is not going to have my hands involved. :Loosing money is one thing, loosing a life; not happening on my watch.


----------

