God help a man who's lost in the PLC world

Let me start by saying that I know *nothing* about PLCs. At all.

We would like to be able, outside Rockwell's RSView32 software, to monitor and intercept network traffic to and from our PLC controllers. When certain signals come from certain controllers, we would like to take specific action.

I have a small "packet sniffer" application, written in C#, which is allowing us to view the contents of the TCP packets coming to and from Rockwell's RSView32.

Problem is, the contents of these packets isn't exactly clear-text instructions that are easily decipherable to the untrained eye.

Call me naive, but I'd just hoped against hope that maybe these TCP packets would make sense on their own (much the way HTTP and other traffic does). I figured that a given controller telling RSView "I'm on" or "I'm off" might not be a very verbose message, and might just be human-readable. Who knows for sure until you've gotten in and tried?

Well, now I've tried, and the packet data is sure enough pretty cryptic.

Could anyone give me some pointers on how I might figure out the protocol or formatting involved, and begin picking my way down the path toward converting these TCP conversations into something meaningful? I have lots of URLs and protocol information, but nothing that's actionable so far. I think that the format of these packets is "PCCC" and/or "CIP". And I've been combing the internet for 2 days now, trying to find anything that I can really use to make sense of them.

By the way, we're fully licensed and legit Rockwell users. This isn't some ploy to avoid purchasing some legit software. We'd just like to passively listen to what our controllers are telling RSView.

The idea of writing new code in-process in VBA to do this, with the risk of possibly bringing down one of our production programs, well, that just doesn't appeal to us. Not like the idea of just passively listening to the controllers talk and occasionally updating a database does.

Can anyone give us a push toward making sense of these TCP packets? Toward taking the streams of bytes that I'm "sniffing" to/from RSView, and making heads or tails of them?

Thanks very, very much for any help.

Do you have a legitimate reason for doing what you want? Wouldn't it be far simpler to just modify the RSView application to

"take specific action when certain signals come from certain controllers"?

You can modify it through VBA. I really don't want to do anything in-process and possibly bring down a production line. I can try to be as cautious as possible and tiptoe into their VBA code, but the fact remains, if I can listen to the traffic without risking bringing down these all-important RSView sessions, that would be the "safest" approach.

And really, you never know how easy or difficult something is until you dive in and try.

For all I know--even now--someone could say, "here's the format: first 4 bytes represent this, and next 2 bytes represent such-and-such..."

You know what I mean?

I can think of any number of shady reasons for doing what you want to do, but I'm hard pressed to come up with any legitimate reasons.

Here's how I see it. You have in place a RSView application that is capable of monitoring several PLCs and passing data back and forth between the computer on which it is running and the PLCs that it is monitoring. In all liklihood, it is reasonably well documented as to what it does.

You want to add some undocumented code that monitors the traffic between the PLCs and the RSView application. This 'stealth' code will "take specific action when certain signals come from certain controllers".

Forgive me for my suspicious nature, but that sounds exactly like what some hacker or virus writer would do. We recently had a thread on this forum that dealt with the potential for viruses affecting PLCs. Did we give you some ideas?

Oh, God. No, I'm not the guy you think I am.

I work at a big food-manufacturing plant in the midwest. I've only been here a couple of months, so I don't necessarily want to give out my company's name. Nor do I see the need. I'm a .NET developer.

We're scared to death of bringing down these production lines, if even for 30 minutes. I'll say it again: as cautious as we (my boss and I) can try to be, the fact is, when we go to working in-process, we run the risk of some unhandled exception (or whatever) harming the currently-running program.

That's it, that's all. If we can benignly "sniff" the signals from our production lines (especially things like "recipe changing" or "downtime due to equipment failure"), then we can update our SQL Server database with the current state of things without bothering anyone or any application.

If you're going to think I'm a hacker, there's not much I can do to prove you wrong now.

This is not the only thread I'm working in. I'll be talking to our local Rockwell tech rep this afternoon to discuss the change-code-in-RSView route. This isn't the only rabbit I'm chasing, in other words.

RSView is capable of doing what you want to do. It is the correct tool for the task you've described. What I can't understand is why you're more afraid of crashing the system by using the correct tool than crashing it through the use of some some backdoor method.

If it's because you know VB.NET better than RSView, then I'd suggest you invest your time in learning RSView.

You are approaching the solution in the wrong direction. RSView is fairly easy to learn. PLC programming is not all that difficult either. Since you're afraid of them, you should hire someone who is good at both and give them a scope of work detailing exactly what you want to happen.

I modify PLC code on running machines every single day without any production stoppages. I have several machines running RSView32 and frequently make changes to it as well without affecting production.

To make changes to RSview, the project has to be restarted, but it is quite rare for a production line to be halted just because the HMI PC stops for a few seconds. In most cases, you just can't make any adjustments while the HMI is off line.

Chances are very good that the PLCs and RSView already contains the functions you need to do exactly what you want without any "stealth" code or special hardware.

Paul C.

I think I know where you are coming from. Because you don't have a firm grasp on PLC's or HMI (RSView) you would feel more comfortable to use a method you understand.

I have to agree with these guys, you would be much better off spending some time to learn about PLC's and RSView and how they interact. Your idea will definately head you down the wrong path and you may incur greter risk then if you just used RSView to begin with. You mention you are scared to take down production, this is a natural feeling with only a short time on the job and little exposure to the PLC/HMI platforms. Attend an RSView class, read the manuals and set up a simple test application with a PLC off the plant network to get some hands on experience.

Thanks, DKH. I appreciate your empathy--and I appreciate your not thinking I'm a hacker.

I might start to dig into RSView with a little more optimism, then. You know, it's probably four parts fear (if my developer-boss is deathly afraid of bringing down the line too, then I--the new guy--should share that fear) and one part pride (I probably feel a little "too good" for VBA coding nowadays). Dumb, probably, I know.

But you know, there are more sensible ways. Even if I'd set up a file watcher on the DBF files that RSView writes to, that would've been lower-hanging-fruit than sniffing the network traffic.

I wouldn't do that, mind you, out of fear of ending up with a file-lock on that DBF file when RSView needs it. I'm just saying, even something along those lines would have probably been an easier choice.

Forget your 'Sniffing' entirely. Unless you really want to reinvent not only a wheel, but transmission, engine, and starting system as well.

Get another box, set up RSView on that, and experiment without touching your existing application.
Or, get another box, put on RSSQL, and use that to extract data.
Or, get another box, put on RSLinx, and use Excel to read data from the PLC's and use that for your needs.

Or, if you really need to take real-world action based on the state of a PLC, well, that is WHAT THEY DO. Modify the PLC program.

Using a PLC to take inputs to a second system to process and provide outputs to a third system just sounds inherently complex and undesirable.

Hey, does RSView offer an API? I don't care if it's COM or .NET.

If I could get the RSView runtime component (and probably an accompanying license file), which we should be licensed for, then perhaps I could code my own RSView-enabled listener app and leave the "real" RSView instance alone.

Hmmm...

Jarbar1026,

I'm still not 100% clear on what it is you're trying to accomplish.

If it's moving data to a SQL server, the appropriate interface is already available in RSView. You can access any data via OPC. There is no reason to expect that this would disrupt operations at all if you are passively collecting data. That is what OPC is for and people do this all the time.

The comment "When certain signals come from certain controllers, we would like to take specific action." Is probably causing me and others here to be concerned. If that action is logging data, sure but there are a lot better ways to do it. If it's opening a valve or starting a motor... yikes! That's not a good idea at all.

Basically, it sounds like you are trying to reinvent the wheel. Re-read what rdrast had to say. I think he was right on target. Spend a little time learning how the system works before attempting to circumvent it.

Also, the concept that interfering in the communications between RSView and the controllers is somehow benign is about as far wrong as you can get. There is a reason that we try to keep these networks isolated. Incorrectly addressed and malformed packets can really cause havoc. I think if I was responsible for production, the idea that some .net guy was snooping my control network would definitely make me nervous.

Just my 2 cents...

I will state I do not know RSView besides playing with a demo copy, actually I think its the real CD but will only run for 30 days or so before requiring activation...therefore it may be possible to obtain or use the company CD to play with a demo to determine what can be done.

I do know HMI/SCADA in general though, if you are just collecting data for a database then using RSView would make the most sense, technically that is what it is designed for....ie the DA stands for data acquisition.

That is why everyone says use the program because its unlikely you will stop the process if just taking data from RSView.
I am slow so not sure what you are wanting to do precisely but I am just about willing to bet its already available. Go here and obtain the info on the version of RSView you have. http://www.software.rockwell.com/navigation/products/index.cfm

NOTE: IF at any point you are going to do ANYTHING that WRITES to a PLC then get someone that is familiar with the PLC's and RSView...a $400 consultant fee would be priceless if it prevents a shutdown, think of it as a training exercise, and have AB (or the original designer) come in.

>If that action is logging data

That's exactly what it is. No starting motors, no opening valves. No way! All we want to do is listen and log certain events or notify a web service via SOAP.

>Incorrectly addressed and malformed packets can really cause havoc

Not an issue unless you're sending packets. Which I'm not.