Controllogix tag security

Paul351W · Jan 24, 2012

I am working with a test control system that is going to interface with a National Instruments data collection system. Our instrumentation group has informed me that the NI system can communicate with Controllogix over Ethernet.

My question is, can tags be accessed from Ethernet connections if the tags are not Produced tags?

I ran across a PDF file from Rockwell called "Integration with Controllogix Programmable Automation Controllers Using Ethernet/IP" and the following paragraph from it confused/concerned me:

If the device can open a connection using a CIP Extended ANSI Symbolic Segment ithe connection path, it can request that the Logix controller produce a tag . Only tags configured as “Produced” – a selection made during tag creation – can be connected to. The device does not need to be in the I/O tree of the Logix controller.

That paragraph starts off by saying the device can connect using CIP, it can request that the controller produce a tag, but then says only Produced tags can be connected to. Is that saying that the remote device cannot request non-Produced tags?

Ken Roach · Jan 24, 2012

Produced/Consumed Tags are the cyclic data exchange mechanism that's most similar to remote I/O scanning. The paragraph that you're reading is describing part of the process for establishing a Produced/Consumed Connection.

What is far more common is for a software client to simply request the value of a Tag using an explicit message request.

Does NI have a native ControlLogix driver these days, or do they use OPC ?

Are you talking about using LabView, or some other NI product ?

Or were you really planning to do cyclic data exchange with the controller, like CompactRIO <-> ControlLogix ?

Paul351W · Jan 24, 2012

According to the NI website, they have a driver/software package for communicating over Ethernet/IP directly from Lab View.

I believe that a NI-DAQ system is going to be installed, but I haven't been given any specifics about the system yet.

In our application we receive signals from the instrumentation system to shut down the test stand, and also send data recording triggers from the PLC to the instrumentation system, so data would be bi-directional.

What I am worried about is someone changing some settings on the NI system and being able to write to PLC addresses that are not part of the configured interface, which could potentially cause a lot of problems.

Paul351W · Jan 24, 2012

Here's the overview from the NI website on the LabView to Ethernet/IP driver:

The NI LabVIEW Driver for EtherNet/IP provides an interface based on LabVIEW to directly communicate over an Ethernet network with compatible EtherNet/IP devices. The driver features mechanisms for both explicit messaging and I/O data communication. These mechanisms offer communication and data sharing with a wide range of programmable logic controllers (PLCs) and EtherNet/IP I/O devices.

The LabVIEW driver includes both an explicit messaging API and an implicit I/O data API. You can use the explicit messaging VIs to read and write Logix tag names or PCCC communication to register files. Rockwell SLC 500, MicroLogix, ControlLogix, and CompactLogix series devices support explicit messaging.

You can use the implicit I/O data VI to create an I/O assembly and function as an adapter for a remote PLC. This type of communication is referred to as Class 1, or I/O server communication. The NI device appears as remote I/O to an EtherNet/IP-enabled PLC and can be addressed within ladder logic as though it were local I/O. Class 1 communication establishes an implicit I/O data connection between the LabVIEW system and the PLC to repeatedly exchange assembly data at a specified rate.

dmargineau · Jan 24, 2012

Logix explicit data transfer (Read/Write unconnected buffers) could be programmed exclusively within the RSLogix 5000 application, thus eliminating the risk of a NI system user intrusion.

Visit http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm012_-en-p.pdf

for detailed information on the matter.

For "connected" data transfer (Produce/Consume connected buffers), like stated within your post, you cannot "consume" a tag which is not "produced". Since both the Produced Tag and the Consumed Tag have to be IDENTICAL (mnemonics, Data Type) the chances of any NI user "mistakenly" "producing" a NI System tag AND simultaneously configuring an IDENTICAL Logix Consumed tag are pretty slim...

Logix connected data transfer in-detail info could be found at:

http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm011_-en-p.pdf

Paul351W · Jan 24, 2012

like stated within your post, you cannot "consume" a tag which is not "produced".

Is there any documentation from Rockwell stating this clearly? The PDF file that I quoted earlier in the thread is pretty ambiguous I felt.

dmargineau · Jan 24, 2012

Paul351W said:
Is there any documentation from Rockwell stating this clearly? The PDF file that I quoted earlier in the thread is pretty ambiguous I felt.

Well...I don't believe so...Or at least none that I am aware of...

IMHO, after thousands of Produced/Consumed tags implementations over the years, one thing I am pretty sure of is that it's "complicated" enough to successfully implement it when you are intending and knowing how to do it; the random chance percentage of "something" happening (without any "programming human intervention") is asymptotically close to zero...

Paul351W · Jan 24, 2012

I just thought I'd check, because our instrumentation group likes to modify things that interface with the PLC system without notifying the PLC group, and we have some inexperienced people running around that just do what people tell them instead of doing the right thing sometimes.

It looks like if I set up the interface with a Generic Ethernet module for I/O messaging, that will greatly reduce the likelihood of someone writing data where they shouldn't.

daba · Jan 24, 2012

Paul351W said:
.....It looks like if I set up the interface with a Generic Ethernet module for I/O messaging, that will greatly reduce the likelihood of someone writing data where they shouldn't.

Not true - all tags in a controllogix system, by default, can be accessed via a suitably configured external system.

However, in versions 18 and above, new control over tag access has been added that can inhibit external access to tags - see the pic.

The default selection is Read/Write, you must remember to change it for any tags you don't want external access to.

You can also declare tags as "Constant", which means that the user code cannot change the tag value.

Paul351W · Jan 25, 2012

We're running v16 with Function Block here at the moment so I cannot take advantage of the external access control, but its good to know that newer versions added that functionality.

What I meant in my previous comment was if I use a generic ethernet module style connection, the NI system, and its operators, will not have any of the routing information that would be required to get into the PLC tag database. Someone would have to go through a lot more trouble to get the required information than if we used Produced/Consumed tag interfacing between the PLC and the NI system and the routing information was in the NI system. I am more concerned with someone accidently typing in the wrong tag address into the NI system and sending data to the wrong tag in the PLC.

Controllogix tag security

Paul351W

Member

Ken Roach

Lifetime Supporting Member + Moderator

Paul351W

Member

Paul351W

Member

dmargineau

Lifetime Supporting Member

Paul351W

Member

dmargineau

Lifetime Supporting Member

Paul351W

Member

daba

Lifetime Supporting Member

Paul351W

Member

Similar Topics