SCADAPack Ethernet/IP Support

[Teaan]

The implementation and support of Ethernet/IP would be a great add on protocol for the SCADAPack 47x and 57x. This will allow for a great range of products supported where the client has an existing standard in place. This again ties in with DTM's where an EDS can easily be loaded and a DDT automatically created for integration. 

[MartinChartrand]

Hello Teaan,

Thank you for your comment!

Could you please elaborate on what you mean with the term "Ethernet/IP"?

Our SCADAPacks already have native support for Modbus/TCP, Modbus RTU in TCP, etc.

Regards,

Martin

[MartinChartrand]

Hello again,

A colleague of mine has provided this link to Ethernet/IP protocol:

https://literature.rockwellautomation.com/idc/groups/literature/documents/wp/enet-wp001_-en-p.pdf

...so I now know what is being referred to here. In any case, please elaborate on what you'd like to see and we will certainly consider your request!

And again, thank you for taking the time to contribute to the future development of our products, it's much appreciated.

Martin

[BevanWeiss]

Yes, the more correct term would be "Ethernet/IP CIP", to avoid confusion with "Ethernet, IP"

I would have to concede on the EDS / DTM for Ethernet/IP CIP devices unfortunately.  For the most part they are just not practical to hand create since they have lots of different property types / codes associated with them.  It's not a flat address map like Modbus has.

I think the idea would be similar to other Ethernet/IP CIP clients.  An EDS file would be imported into RemoteConnect, an instance of such a device could be created and given a 'friendly name', assigned an IP address, and configured for an update rate (RPI).

The EDS file has a number of device profiles, and objects within those device profiles that should be selectable (for each instance) based on what information is desired to be exchanged.

Ethernet/IP CIP is definitely not the simplest protocol around, but hopefully some of the development done with Geo SCADA Expert could be leveraged for the SCADAPack... (although perhaps the IP for these two product families are owned separately).

[Teaan]

Hi Martin,

As Bevan mentioned Ethernet/IP is a standard with CIP being the application layer protocol and is now supported by https://www.odva.org/technology-standards/key-technologies/ethernet-ip/. It is an object based. 

EDS (similiar to GSD ProfiBus files) files from the manufacturers will need to be imported and DTM's will need to be setup for these. 

After the DTM's have been created a completed DDT will be added to Unity from where you can use it to build your own function blocks and send/received data to SCADA via DNP3. 

ModbusTCP and Ethernet\IP is also the native protocols supported by the M580. 

As the Allen Bradley Ethernet\IP driver has already been created for GeoSCADA, the support of this protocol on the SCADAPack is definelty (in my opinion) a very good option. 

[MartinChartrand]

Hi Teaan, Thanks for the clarification. I will bring this idea up as a topic in our next development meeting, within the next couple of weeks.

Regards,

Martin

[MartinChartrand]

Hello,

Ethernet/IP CIP is certainly gaining momentum right now, as are OPC UA and PROFINET. Which of these three would be the highest priority for you and what types of devices/systems would you use your selection to connect to?

Anyone reading this post is invited to chime in!

Martin

[BevanWeiss]

Hi Martin,

I'd say that the priority order is probably best as:

1. Ethernet/IP CIP Client / Master
2. OPC UA Server
3. Profinet Client / Master
4. OPC UA Client / Master

Others might have alternative priorities however.

For Ethernet/IP CIP and Profinet, I don't believe it makes much sense to consider a SCADAPack as an Ethernet/IP CIP Server/Slave (i.e. just an IO device).  However for the OPC UA, it's the opposite.  It makes more sense in regards to OPC UA to have the SCADAPack be a device and not a scanner.  And Profinet isn't hugely popular (at least here in AU..), most devices which support Profinet also now support Ethernet/IP CIP.

[fcantrell]

I would agree with Bevan's priority order. Allen-Bradley devices are everywhere here in the USA and being able to talk to them in their native language would be a definite plus for the SCADAPack line.

[MartinChartrand]

Thank you all!

Your collective comments will be duly considered as we move forward. I will keep the community up-to-date with any news.

Regards,

Martin

[StevenE]

Hi Schneider Team,

Any update on this particular topic? 

There is a large install base of Rockwell Micrologix 1100, 1200 and 1400 PLCs (and even a few SLC500s) within the Water Industry here in NZ in remote type applications, communicating either over legacy serial links or more modern ethernet radio links.

The 1100 and 1200 are now obsolete, with the 1400 likely to end up on the chopping block within the next few years. Rockwell's Micro800 line which is meant to be the replacement for the 1100, is in my opinion at least, not nearly as physically robust or capable when it comes to ease of programming. To make it even less enticing as a replacement for existing 1100s, it does not support messaging to its Micrologix predecessors, i.e. reading and writing of "N" integer files using what I would call "CIP encapsulated PCCC/DF1 protocol". You have to use Modbus TCP, which only the 1400 supports.

The SCADAPack E series had DF1 protocol for serial ports I believe but I don't think it ever received this capability over the ethernet port.

If the SCADAPack Dev Team were able to implement Encapsulated PCCC/DF1 in a similar fashion to the MODBUS Scanner functionality in RemoteConnect for the x70 range, that would prove incredibly useful for staged migrations from old Rockwell gear to SCADAPack x70 RTUs.

The ability to act as a DF1 slave device would also be useful, i.e. map SCADAPack tags to a "N" or "B" type file addresses in Rockwell RS500 terminology, allowing a Micrologix, SLC500 or CompactLogix to read values from the SCADAPack without needing to use Modbus TCP (not available on the ML1100 over ethernet, and cumbersome to implement in a CompactLogix).

We are currently having to use the HMIs of migrated sites as a protocol converter and DF1 master, which isn't ideal... especially when some of these systems are getting migrated piecemeal over a number of years.

With a Water Services Reform here looming, I imagine there will be a lot of systems coming under renewed scrutiny around obsolescence, and having the SCADAPack x70 range able to easily integrate into these existing legacy systems would certainly make it much more appealing when it comes to selecting an RTU product.