What tools are used for industrial network analysis?

hi
I wonder if you could suggest what is your preferred software/hardware for industrial communication (understood in broad way) analysis.
Please correct me if i am wrong. The way i understand it:
Each industrial communication has got some underlaying physical layer.
  1. For high level ethernet and wifi - wireshark i believe is the king
  2. RS232/RS485 type of network i believe iftools have great hardware/software products (i am planning to buy their analysers) https://iftools.com/shop/index.en.php
  3. What shall be used for USB ?
  4. Can you please list any other physical layer types and their tools
Many thanks for any advice!
 
A protocol analyzer assumes that the bits it "sees" and then analyzes are what the sender sent and have not been corrupted by electrical factors:

- noise
- common mode
- excessive cable capacitance
- inadequate signal amplitude
- impedance loading
- ringing or reflected energy appearing as bits
- bit/word/packet timing

so a protocol analyzer is not the right tool for analyzing electrical problems or timing problems; those kinds of problems need a scope and preferably one with the ability to label bits in the bit stream.

For a discussion of the Fluke 125 Scopemeter (2008) and how it solved a timing problem, see

http://www.plctalk.net/qanda/showthread.php?t=35172&highlight=serial+protocol+analyzer

For a discussion of serial port sniffers and protocol analyzers, see
http://www.plctalk.net/qanda/showthread.php?t=24526&highlight=serial+protocol+analyzer

Although an older thread the products mentioned are still available.

Be aware that RS-232 is single ended so any scope can view the waveform, but RS-485 is differential with respect to signal ground, so a dual channel scope is needed with ch A minus Ch B functionality is needed. I personally hate decoding inverted bits from a waveform (how many ones or zeros are in that solid high or low stretch?), so the smart bus analyzers have a place.

Process industry fieldbuses
The Profibus spec defines both the hardware layer and the protocol. Profibus DP uses the RS-485 bus, whereas Profibus PA (the field instrument intrinsically safe network bus) uses Manchester Encoded Bus Powered (MBP). There are network analyzers specifically for Profibus. The Profibus has specified limitations on segment and spur cabling lengths and the bus analyzers use time domain reflectometry to analyze cabling length issues. Googling Profibus network analyzer will bring up the vendors. and their products.

Likewise Foundation Fieldbus (FF), used in the process industries with a high speed Ethernet bus (HSE) and a separate Manchester encoded, intrinsically safe field instrument bus (H1) use Emerson's 475 or Trex or Softing's MobiLink handheld. FF diagnostics appear to be intelligent scope based. FF commissioning tests require cabling capacitance checks, presumably a necessity when troubleshooting as well. I'm not aware of a commercial FF network analyzer but maybe someone else has run across one.
 
Wow thanks Dave what a reply! I hit follow button as well:)
I am in early stages of learning and trying to focus on something rather easy to monitor and troubleshoot.

Are you able to give me some tips on which order its best to learn the protocols? Does the order of learning matter?
1 i am focusing now on RS232 and RS485
2 next i am planning on MQTT
3 maybe CAN network
4 maybe allen bradley networks control net and devicenet

Regards
 
RS-232 and RS-485 are hardware layers, they are not protocols. Hardware buses just transfer bits. A Protocol is a set of rules that govern communications. Who talks to whom and when. How is communication iniated and terminated? What happens where there's an error?

There's lots of info on RS-485. A web search will bring up some tutorials on how to make RS-485 reliable. The biggest problem in implementing RS-485 with multiple vendor products is the inconsistency of the presence of a signal ground, because what is known as 2-wire RS-485 is really 2-wire with a 3rd wire, signal ground. The unpublished 'secret' of RS-485 is that some vendors label the driver lines A and B with A being negative respect to B, whereas the other set of vendors flips the polarity. Backwards polarity will not damage the drivers, but communications will never take place. Fix is easy, swap the driver lines on one end.

The beauty of Ethernet is that it is inherently, by design, isolated. Neither RS-485 nor RS-232 are isolated, creating a host of problems over distances, where ground potentials are not equipotential.

I'm too late in the game for MQTT - that's up to you. The industries I serviced did not do CAN, so I can't tell you anything about CAN. Others might pop up and offer some insight on those two.

A-B's controlnet and DeviceNet are becoming legacy with Ethernet/IP being the major player nowadays.
 
Top