My company utilizes HMIs in our OEM systems. The HMI is a large touchscreen attached to an Industrial PC with Ignition installed. We want to be able to deploy Ignition quickly on these HMIs. My thoughts are this:
Either
Windows 10 VM with everything installed and configured the way we want it.
Win 10 VM is installed onto Industrial PC running Win 10 Pro w/ Hyper-V.
Reasoning - VM can be modified without affecting underlying Win10 Hyper-V manager. No need to install programs, configure settings, etc. If the VM gets trashed, we can roll-back to prior versions.
We can remote connect to the base OS and make changes to the VM without affecting their run-time (much).
Cons - Windows on Windows…
Or
Powershell scripts that install all programs (Ignition etc.) and configurations onto the Win 10 based Industrial PC.
Doable, but we have quite a few programs/configurations that this would be complicated.
Also, if the customer ends up trashing the base OS, then we would probably have to send them a new hard drive (easier than flying someone out to India, China, Azerbaijan, etc.) and that downtime would be horrid.
What we used to do
Clone the drive from a “golden image” and update Windows licensing. However, industrial PCs would be problematic to get hard drives in/out to clone and add more headaches.
I have also looked into Docker, Linux VMs, and other things, but most of our customers use Windows (not by choice but by lowest common denominator). Why I’m thinking about doing the former Win10 VM in Win10 Pro, is that we can control our VM and iteratively develop it and simply copy/paste that VM on the Industrial PC without much problem. Also, when we eventually get to a cloud-based solution, then simply hosting/porting these Win10 VMs will be fairly straightforward.
I am sure there are lot of questions that you may have like, “Why are you doing it that way?”, so I will attempt to answer those if you do ask them. I’m just trying to get a feel for other OEM’s as to how they are deploying fairly complicated HMI’s without a server attached.
Making a small change to the Vagrantfile in that setup will also expose the underlying Ignition port to other NIC’s on the host system, allowing other folks to connect to it as though Ignition were hosted on Windows 10 itself.
Removing the host_ip definition against localhost for port 8088 is all that you’d need. There might also be some interesting possibilities with using the “package box” feature of Vagrant to make restoring from a cloud image very easy on a new box…
Some rambling thoughts. These and a dollar might be worth about 98¢:
If USB is available on the PC (and it’s rare to see one without), I use Hiren’s Boot CD bootable from a thumb drive, with drive images all on the same stick. No need to remove the drive to clone.
I think you can do the same thing with something like Acronis or Ghost and make a bootable restore.
Does it have to be a Windows base OS? A Linux OS would eliminate licensing needs. I get that there may be other software requiring windows to run. Heck, if Rockwell and Solidworks ever came out with Linux versions, I’d be dropping Windows in a heartbeat.
What about Windows IoT Enterprise? The licensing ma be a bit more flexible.
Not necessarily offering these up as solutions, but as other things you might not have considered.
I do all my daily computing on Linux. I keep a Win7 VM around for Rockwell Software and Quickbooks. Been doing things this way for six or seven years, now.
Another vote for Linux here. We’ve been running the company on it for over 7 years. We have a Windows box and Windows in a VM but they rarely get used. We’ve transferred most of our customers’ Ignition servers to Linux and remote support (and reinstalling on new hardware) is much easier.
Thank you for all of your responses. I personally use Linux at home, and love it. However, the following thoughts apply to our company (and I believe to how the Automation Industry as a whole used to act):
I think the adage, “If it ain’t broke, don’t fix it” would apply to why we utilize Windows in our SCADA servers.
Our use of Windows SCADA “servers” (NT, Win2000, Server 2003, Server 2008 R2, etc.) dates back several decades.
There would be quite a bit of training involved to get our technical support personnel up to speed on Linux. Everyone uses and understands (to some degree) the Windows-based OS.
Although I am not in a position to mandate the use of Linux in our company, I am most certainly going to be running Linux in our research SCADA systems to attain data that Linux is just as robust, practical, and VM friendly as our current Windows-based offerings.
If Linux is chosen, what would be a good method of getting a distro and applicable programs installed onto an industrial PC (SSD) with all of our configurations already built-in? I don’t think that we will be using USB flash drives, but it would be very interesting to be simply running off of one of these slim flash drives. I’m very worn out and weary from Windows volume license issues that Linux would be a breath of fresh air. Let’s hope I garner support as I do so.
Our company is currently using Windows for about all servers, but I'd at least like the option to have decent support for Linux in the future (I've been running Linux for personal purposes for about 10 years).
On Windows, we normally install a TeamViewer host on it. This allows to take over the screen, and TV also offers a VPN to the server, allowing to connect to the Ignition web interface or some SQL server.
Sadly, I haven't come across a Linux solution yet that does the NAT hole punching, easy VPN setup and good stream compression for lower bandwidth. TeamViewer is also available for Linux, but it's only a basic version and doesn't offer VPN there.
ngrok is a good solution for this and allows you to specify what local port things will forward to (such as SSH or VNC, perhaps even the Ignition port).
I, too, run Linux as much as possible, and I require my customers to use it for servers they want me to set up and support directly. Given Linux on the server, it is almost trivial to run OpenVPN on it, pointing at my own customer support VPN server in the cloud. That OpenVPN server is configured to only pass traffic to/from each customer and my systems – dropping any attempt at cross-customer traffic.
My biggest customers are appropriately paranoid and take care of their own servers, so I just use whatever remote access solution they already have.
In my experience, remote support with Windows tends to mean viewing the remote interface and taking over control of the mouse and keyboard. This has most utility when giving support to a remote user. Remote support with Linux tends to mean connecting to a remote server and interacting with the services running on the server. We find being able to connect to a remote Linux server and configure Ignition and the database without interfering with what anyone else may be doing on the server very useful. It seems a better fit than taking over the screen and means that it also works better on low bandwidth connections.
To do this we use SSH. This does mean forwarding a port to the server, but I prefer this over using third party tools like TeamViewer, where you're just having to take in on trust that they're not doing anything malevolent (remembering also TeamViewer's security problems last year).
If you need to access any other machines on the remote LAN you can just use remote port forwarding - anything you can do as a user on the server you can do from a remote location as well. If we have to have access to the remote screen we just tunnel VNC over SSH - It's not great but good enough for occasional use. For more involved access to a local LAN we would set up a VPN using OpenVPN.
As a side note we recently carried out a comparison between TeamViewer and all the other leading remote control packages for Linux including AnyDesk, NoMachine, RealVNC, TigerVNC and Chrome Remote Desktop and none of them came close to TeamViewer for ease of use, speed, reliability and (importantly for us) handling of multiple monitors. Pretty impressive when you think TeamViewer is running in WINE! The only problem is TeamViewer's cost of nearly $1,000 per year when we rarely need to use it.
We’re not all software guys here. Sometimes the hardware team also wants to connect to the server to the server or some client to consult our SCADA remotely.
So ease of use is very important to us, we can’t reduce the ease of use in favour of the ease of installing.
I would have no issues with SSH (certainly not on standardised envirionments), but I don’t think I’d be able to recommend a console-only solution here.
This motivator is a significant contributing cause of virtually every security breach ever documented. I currently draw the line at the public IP boundary. If your hardware team can get to your SCADA systems without a VPN, you're living too dangerously for me.
First, is there a technical difference between a VPN and different remote control packages? I’d guess not. They both can have bugs in the security, and passwords of users can leak for both connection methods. To me it’s just a matter of which tool you know best, so you know where the options are to secure the tool.
I agree that you can’t sacrifice safety for easiness. But to me, “ease of installing” and “ease of use” are quite orthogonal, so you can sacrifice one form of easiness for another IMO.
And apart from how complicated the tool is, for a hacker, it just boils down to either finding a bug in the software or getting hold of the credentials.
Do you have some articles or posts about the security breaches you’ve come across? I’d be interested to read about it.
It's basically that anything listening on a public IP address is going to be attacked regularly, and even if not immediately breached, will be analyzed for future attempts. Establishing VPN tunnels allows sites to have remote control and other remote access technologies listening for connections but not exposed to the public. VPNs I've experience with have many options for tight security far beyond simple credentials, and that high security protects everything you run through them.
As a side benefit, making direct connections to servers -- designers, clients, consoles, web interfaces, PLC suites, whatever -- tend to require less bandwidth than screen painting remote control solutions.
