PLC Monitoring & Control over internet


Thread Starter

M. Bhamani

I have connected my PLC at RS485 port to an Ethernet Module. I can see my PLC inputs/outputs through the module on web browser on my PC where I have physically connected the module/PLC through ADSL modem. I have done port forwarding as well and I can open the web page on a remote computer.

Although I am able to open the web page off the ethernet module on a remote computer, I am not able to see (monitor/control) any of my PLC input/outputs. Can I please have an expert advise on how do I configure the options on web page to monitor/control my PLC from a remote computer over a web browser?
Perhaps the "Ethernet module" you mention requires additional ports to be forwarded. For example, some Ethernet devices embed a Java applet on a web page as a UI. In this is your situation, you need to find out which port(s) the Java applet use, and setup appropriate port forwarding in your router.

Just keep pinging the PLC over the Ethernet port. (grin) If you do it enough times, it will crash. Somebody brought down the Hatch Nuclear Power Plant that way last year. Pinged the PLC controlling the cooling water feed...shut it right down, requiring a cold reboot. Unless you are using a Tofino device or the equivalent, you should never expose a control system to the Internet. People will pwn you almost instantly.

Walt Boyes
Editor in Chief
Control and

Mailto:wboyes [at]
Read my blog SoundOFF!! At
I would guess that your DSL router has the ports blocked. A lot of them have a built in firewall that only leaves open the ports for web browsing, e-mail, and a few other popular protocols. You have to find out what port or ports the module needs and change the configuration to open them. You might also need to do the same at your PC end of it as well. Some ISPs (your internet service provider) and corporate networks block ports as well.

Good luck on that though, because a lot of proprietary protocols don't document which ports they use. If your network provider is blocking ports, then getting them to admit it will be like pulling teeth.
Yes Paul it has Java applet and the port I was told were 502 and 20006 but I do not know how to configure. The applet tab shows RS232 as well as RS485 with Listening Port, Destination IP and Destination Port to be input on both of them. Thanks for your advise. I am sure I will get it through with your further expert advise. Hoping to hear from you.
All that should be required is setting up port forwarding to direct these ports to the IP address of the unit behind your router.

To confirm required ports, you can install and run Wireshark ( on your PC connected to the local LAN, and monitor connections. You will want to look for destination ports numbers here, to see if they match what you were told. Of course you will need port 80 open for web browser access.

A better approach would be to use a VPN connection, provided that your router supports this. In addition to eliminating the need do port forwarding, you will be able to protect the unit from potential hacking.

Walt Boyes:
> Just keep pinging the PLC over the Ethernet port. (grin) If you do it enough times, it will crash. <

Why would pinging a PLC make it's OS crash? I can see how pinging a PLC aggressively enough could get it to loose communications or experience late responses from other devices on the same LAN, but if it crashes, there is a bug in the PLC's OS.

>Somebody brought down the Hatch Nuclear Power Plant that way last year. <

Do you have a link to this specific shutdown incident? I ask because the links I have found explain the problem much differently. Here's the original story from the Washington Post:

>Unless you are using a Tofino device or the equivalent, you should never expose a control system to the Internet. People will pwn you almost instantly. <

The Hatch power plant control system was not exposed to the Internet, or at least that was not the reported cause of the malfunction. The computer that was updated and rebooted was located on the business lan which was connected in some way or another to the control lan. The computer seemed to be involved in a monitoring only application, but somehow ended up with write access to the control system and decided to use this capability.

It seems to me that the shutdown would have also happened if the monitoring computer was located on the control lan, isolated from outside world, for use by control system operators only. This does not strike me as a strictly security related malfunction.

There is a common bug in OIT and SCADA software applications. It is caused by the programmer of the application software thinking that his application should be the only, or the default, repository of the correct setpoints. So when the integrator or technician downloads a new OIT application with this bug he gets a big surprise when he sees that the initial values or zeros stored in the OIT's application database are written into the PLC's setpoint memory locations rather that having the OIT read from this data from the PLC first.

I don't want to minimize the importance of security, but I'll bet dollars to donuts that that is what happened here.
In reply to KirkC: I can't speak for any particular PLC, but most of them use a third party proprietary embedded OS or executive. Proprietary embedded systems have a lot of bugs which don't ever get fixed. Usually the customer decides to just live with the problem. It's a narrow market with thin margins, and the 32 bit part of the market is getting gobbled up rapidly by embedded Linux, so the proprietary vendors are having a hard time keeping up with their hardware support, let alone fixing what are probably very difficult bugs.

I wouldn't at all be surprised if too many pings too rapidly would overflow a buffer and crash a PLC. I would expect that someone with one of the common hacker toolkits could have a field day on a network with most PLCs.

On a related note, there was an announcement in the news a couple of days ago that Intel has just bought Wind River. The general consensus of most observers is that this isn't good new for most users of VxWorks, which I would expect to include a number of automation vendors. Most people seem to believe that Intel will wind down support for any non-Intel architectures (MIPS, Power, ARM, etc.) in favour of their own Atom processor. Anyone with a product line that depends on VxWorks probably needs to be thinking about how to bail out and port their product to another OS.
When I open the Java console, I see the following string:

Exception in thread "AWT-EventQueue-4" access denied ( (DEVICE IP):502 connect,resolve)

When I run wireshark I see the following strings:

Router Broadcast ARP who has DEVICE IP to COMPUTER IP....... then halts for some time?

When I refresh my Java page on the Device IP URL the wireshark page shows:

COMPUTER IP to DEVICE IP - source port: XXXXXX destination port 20006
DEVICE IP to COMPUTER IP - source port: 20006 destination port XXXXXX

Is above detail good enough to suggest what ports should I assign in my configuration Java applet on a remote computer. RS232 or RS485?

I also have a facility on the device propriatery software to create a virtual COMM port to capture one of the communication port above. Does this help?

If I use ASCII Mode, do I need to input Fix length (Bytes), Start Item (Bytes), Start Character (Hex), Stop Item (Bytes), Stop Character (Hex). Or are these are only for RTU Mode?

Curt Wuollet

This Wind River Intel thing is getting a lot of notice. People are speculating that this is the end of the duopoly since Wind River is a Linux outfit now. MS can't be too pleased about Intel buying into Linux in the hot low power embedded (think netbooks, etc.) market. Not too long ago, I would have suspected this was to make Wind River and it's Linux go away. But the impression I get now is that Intel is finally looking out for Intel and low power netbooks, phones, etc. are not the place for MS only thinking and Intel wants a better OS for it's Atom procs. I would think existing WR customers can easily morph to running Linux, as that is what WR has been concentrating on. So, the transition path should be there. Maybe we will see Linux PLCs in the foreseeable future. At this point it makes a lot more sense than the alternatives. It will be most interesting to see what develops.

In reply to Curt Wuollet: The Wind River purchase would likely be to support Intel's plans for x86 (Atom and new smaller Atom derivatives) in the embedded market. For the netbook market, Intel is the company behind Moblin Linux. That's the distro that was doing 2 second boot times earlier this year. They've been lining up traditional Linux distributors to support it, and at a recent trade show Canonical, Linpus, and others demoed spins of their netbook distros based on Moblin.

Wind River had two main product lines. The first is their traditional VxWorks OS. For a long time Wind River was going around telling anyone who would listen that Linux was no good, Linux would never succeed in the market, etc., etc. This FUD was all about trying to protect their market share from embedded Linux distros. Eventually however, Wind River was forced to admit that Linux was going to take over the market and so they turned completely around and came out with their own Linux distro - Wind River Linux.

What most observers seem to expect Intel to do is to continue to offer both VxWorks and Wind River Linux, but to put the emphasis on Atom support. Support for other architectures (MIPS, PPC, ARM, etc.) will probably be a lower priority. Also, the other hardware vendors will be reluctant to release the specs for their latest chip designs to Intel in advance of them being ready for market. This is why things don't look good for VxWorks.

For customers using Wind River Linux, there really isn't much of a problem. They can always switch to another distributor (such as Montevista) and still get the same thing. Or, they can decide to do their own support in house and not be dependent on outside partners. If VxWorks customers get nervous and decide to jump ship, the obvious place for them to go is to Linux. Certain markets such as aerospace will be a problem though, because you have to get your software certified (which is a slow and expensive process) and there isn't as much choice there.

While we are talking about company news, the bankruptcy judge in the SCO case is going to be deciding very soon whether to put SCO into liquidation. SCO has objected to that, but the statutory limits for "chapter 11" bankruptcy have run out without SCO coming up with a viable reorganization plan.

Now, either someone is going to have to step in and pick up their assets at the bankruptcy sale (Novel would be a good candidate), or else the remaining OpenServer customers are going to be out of luck so far as support goes. If OpenServer is using a license activation system these days, the customers might also have a problem if they ever have to do a re-install because of a hardware problem.

We get questions on this list now and again from people who are using OpenServer, so this is definitely going to affect people in the automation industry directly. This shouldn't be a surprise to anyone who has been following the news though. This end was pretty much inevitable given the business strategy of present idiots in charge of the company.

Curt Wuollet

That's right, I'd forgotten about Moblin. I was a fan of SCO at one time and did several hospital systems on it. We parted ways when they went from being a UNIX company to a lawsuit company and falsely
attacked Linux. Fortunately, they also attacked IBM, who had the resources to cope until the farce was uncovered. With recognition to Novell, who isn't short on lawyers either. Without the big guns, SCO
might have been able to prevail, regardless of the lack of merit in their claims. Linux might have been destroyed by treachery and having no Linux Inc. entity to defend it.

It is becoming a very strange world with Linux and IBM and Novell and MS and Suse and Cray and Wind River and Intel and Google and........ Linux is the hottest non-commercial property on the planet. I hope that all who play the legal game with software end this way. And that the crazy chaotic world of real competition multiplies after decades of monopoly.


Abbas Turkaman


I'm studying Industrial Networking course now and would love to know how would it be possible to control/monitor a PLC on a remote PC over internet. I'll be grateful if you send me a tutorial in this regard if possible to my e-mail:

[email protected]

Thanks for your time and kind attention,
Abbas Turkaman
Most o all modern age PLC uses Ethernet based modbus communication. it is possible to transfer this control to the world wide web and access it from a particular IP. But not recommended. (Security issue).

If you are just referring to the Ethernet, then you just need to connect the Ethernet cable from the PLC to the control PC (However far it may be, with the help of routers to boost the signal). Use the corresponding PLC program / use OPC servers to map these signals to your corresponding control inputs.