Wednesday, April 20, 2011

An interesting approach to why do EBR…

I recently attended a good presentation on EBR systems [ok full disclosure, it was a system that we installed and a fellow colleague was presenting].  Naturally, a Q&A session followed the presentation; during the Q&A somebody asked a question about the payback. 
The interesting thing about the question was the frame of reference of the asker; paraphrasing the exchange…
Asker:  “How much reduction in cycle time did the EBR system provide to the operators”?
Presenter:  “None really… it was a wash.”
Asker: “Then why do it?”
I believe that the asker was from a CPG background and thusly so, was of the mindset that EBR/Work ticket systems should let to a direct labor time savings.  Of course the EBR system will lead to time savings, but where is the question.  [As the presenters, did answer]Some of the savings is in OPERATOR direct labor (transcription time, manual logging time, etc.) however, it is in QA REVIEW time that is dramatically reduced.  Naturally there are some other reasons supporting a system like this:
  • •Better Data
    • •Improved accuracy and consistency of the batch record
    • •Increased speed of product introductions and process changes
  • •Production
    • •Reduced cost of compliance
    • •(Some) Increased productivity – i.e. verified by
The major point here is there are a wide variety of reasons that systems are put in place, MESA has defined these as Strategic Initiatives, some of which are Lean Manufacturing, Quality and Regulatory Compliance, Product Lifecycle Management, Real Time Enterprise, Asset Performance and etc.  When considering implementing those, make sure to look up and down stream to fully recognize impacts and capture all benefits.

Saturday, April 2, 2011

Industrial Ethernet Reliability and Performance: Multicasting


Industrial Ethernet works on the same principles and protocols as any other Ethernet network.  In a nutshell, devices place units of data on the wire called packets.  Packets generally have a source and a destination.  When one device sends a packet directly to a second device, the process is called unicasting.  When a device sends a packet to all other devices on the network, the process is called broadcasting.  Finally, when a device sends a packet to specific group of other devices on the network, the process is called multicasting.
You might be asking yourself:  “where would multicasting be used?” One example that is often used in the IT world is a live camera feed.  If twenty people want to view a live camera feed, the camera shouldn’t have to manage twenty individual conversations, so instead, the twenty devices that will be showing the feed subscribe to a multicast group associated with the camera.  The camera sends packets to a multicast group destination address and the devices subscribed to that group receive and process those packets.
So, where does this apply in an industrial controls network? The first example that comes to mind is the use of producer and consumer tags on Rockwell Automation’s Controllogix platform.  One processor is a producer while one or more are consumers.  The consumers subscribe to a multicast group served by the producer.
The potential problem with all of this is that many switches handlemulticasts as broadcasts which creates a large volume of traffic on the network and can cause performance problems due to the packets being forwarded to every port on the network.  The simplest solution to this is to implement IGMP (Internet Group Messaging Protocol) snooping.  This is a feature that is available on some managed industrial Ethernet switches and on many standard duty managed switches.  Once IGMP snooping is enabled, the switch will remember which ports have devices that are members of a particular multicast group and will forward multicast packets only to the devices that should be receiving them.  This will greatly reduce network traffic especially if you have a large number of devices utilizing multicasting on your network.

[ Original Post by Jed Leviner]