Multiple protocols on a SCADA system?

[transporter_ii 0]

I'm stuck installing equipment in the field and trying to learn the ends and outs of a SCADA system from the wrong end. I came into this with an Ethernet networking background. My question is: Can multiple protocols work over a serial network, similar to the way they do over Ethernet? Example: Modbus RTU and serial BSAP? Radios are MDS and Freewave 900 Mhz. If it does work, any major downside to multiple protocols running at the same time? Thanks,

[BobLfoot 302]

I am not guru when it comes to Networks and Computer Hardware, but let me attemps what I think might be your answer and will certainly serve as a framework for others to build on. Let's establish some syntax or terminology first. 1. Physical Layer Standard - This refers to a set of rules for a certain hardware to operate under. Some Examples are 1a) Ethernet with IEEE802.3, IEEE802.3a and IEEE802.11a/b/g/n, 1b) Serial with RS232, RS432,RS485, SATA and SIP 1c) Canbus, 1d) Devicenet 1e) ControlNet 2. Logical Layer Standard - This refers to the set of rules for data structure on a network Some Examples are 2a) PC Ethernet 2b) Ethernet/IP 2c) Ethernet CIP 2d) Serial 2e) Modbus The problem is while most all Logical Ethernet Standards can operate on all Ethernet Physical standards. There is only 1 logical standard definition for serial that being that binary data progresses serially down the wire. What we often all see as one type of communication SERIAL is actually one of any number of physical hardware configurations. I doubt you will have a lot of luck getting differing serial physical layer standards to share a piece of harware.

[transporter_ii 0]

Not that I'm disagreeing with you, but isn't there normally some different protocols that work over serial at the same time in a Scada system? What I don't know is the degree to which they are different and if that really even matters? For example, we have one Enron Modbus device among numerous Modbus RTU devices, all using RS485. Also, Doesn't the Fisher Roc 503/407 etc., have its own proprietary protocol (which I think is a version of Modbus, if I'm not mistaken)? I know we have the proprietary Fisher protocol and normal Modbus RTU running over the same Scada system with no problems. What I don't know is when you throw something like the serial BSAP protocol into the mix. If all else fails, I did find a serial BASP to Modbus RTU gateway. It just seemed to me to be an extra layer and another expense if it wasn't needed. On the other hand, why make the gateway if multiple protocols will work over a serial network? Will research it some more and let you know what I find out. Thanks for the input!

[TimWilborne 108]

Look forward to hearing your solution

[paulengr 44]

You are mixing and matching terms way too much here. Ethernet is a link layer protocol. It supports multiple higher level protocols via the "Ethertype" word. However, the vast majority of the Ethernet traffic these days consists of either IP protocol or a small number of auxiliary protocols (ARP or IGMP for instance). It also supports a half dozen different physical media but virtually the only widely used media is CAT 5E. Most traffic is encapsulated inside IP packets. An example of another link layer protocol that uses the exact same physical media is Arcnet. You cannot mix Arcnet and Ethernet protocols on the same physical media. For those keeping score, Controlnet uses Arcnet as the underlying link layer protocol. In fact, you can carry IP packets over Arcnet and during the early days of Ethernet, Arcnet was the dominant player. In terms of the OSI model though, so far we're only talking about the first 3 layers or so. When you say "serial", this is an extremely broad term. Technically, 10 Mbps Ethernet is also "serial". All fiber Ethernet protocols are serial as well. A "serial" protocol just means that the symbols are converted into individual bits and transmitted one bit at a time, then reconstructed back into words at the other end, as opposed to having multiple parallel connections or a phase/amplitude modulated wave which can carry multiple bits simultaneously. For this reason, 100 Mbps and 1 Gbps copper Ethernet protocols are actually parallel, not serial, although they are a good deal more complicated than the venerable Centronics printer interface or any of it's newer variants. If protocols share packet framing protocols somewhere along the way in the OSI model of things, chances are that they can share the wire or at least be bridged at that level. This is the case with IP packets for instance. PPP, SLFP, and SLIP are serial protocols that carry IP packets. They are used for dial-up "internet" type services. Arcnet and Ethernet don't have the same link layer protocol, so they cannot share the same wire. Arcnet, Ethernet, PPP, SLFP, SLIP, and even 802.11 CAN however share packets because they can all carry IP packets. A protocol gateway can convert IP packets from one network to another, allowing them all to "interoperate". This is different from a bridge device such as an Ethernet switch that doesn't really translate anything...it just passes the exact same physical packet format from one network to another. Modbus (see www.modbus.org) is not broken down very well by the OSI model. It significantly predates the OSI model. It really encapsulates all 7 layers in it's definition. So when you were describing different devices using Modbus, they all share the exact same application layer protocol and so they will interoperate with each other. BASP is another application-layer protocol. It doesn't share any of the other layers, not even the link layer, with Modbus. So it is not going to interoperate with Modbus except with a gateway in place. One thing that makes the term "serial" confusing is that in the PC world, it is almost always synonymous with RS-232. RS-232 was invented for communication between Teletype machines and modems or terminals over short distances (less than 30 feet) at relatively slow speeds (about 10 kbps). RS-422 and the party line version, RS-485 improved on the electrical characteristics of RS-232 and allow serial communication up to several kilometers. RS-485 also has a "transmitter idle" state that allows for multiple transmitters on the same wire. All 3 protocols allow multiple receivers depending on impedances. Most RS-232 equipment uses exactly the same format for framing symbols. Only the speed (bps) is left as an open choice. The format is 1 space bit, 7 or 8 bits of data, 1 parity bit (even or odd), then one or two "mark" bits as "stop bits". The most common format is 8-N-1, or 8 data bits, no parity, and one stop bit, for a total of 10 bits per 8 bit symbol transmitted. Idle transmitters transmit mark bits continuously. RS-485 usually adopts the exact same symbol format as RS-232 except that the idle transmitter has a third ("high Z") state which can be overridden by any other transmitter attached to the same bus. Because RS-485 is so versatile, it is the physical media format of choice for dozens of industrial protocols including Modbus, BASP, BACnet, DF-1, and CAN. Most protocols also share the same symbol framing and electrical format as RS-232, CAN and V.42 being notable exceptions. The closest thing in the PLC world also happens to be Modbus. It's hard to see why this would ever happen but for some strange reason, every PLC brand I've ever encountered can either speak Modbus natively or else has some sort of optional module that allows it to do so. So in short, there's no way that BASP and Modbus are going to interoperate. In fact it is actually the exception rather than the rule that protocols will interoperate with each other sans gateways. Part of the whole point of the IP (Internet Protocol) was just that...to provide for a standard packet format that could easily be passed across gateways from one network to another, forming an internetwork. It's just that we've all become so accustomed to and spoiled by the ubiquitous internet protocol that it is hard to fathom anything else.

[DanW 41]

Assuming you mean RS-485 as a multidrop physical layer: What won't work is when the serial parameters, word size (7 or 8 bit), baud rate, or parity, are different for different devices on a multipdrop RS-485 line. For instance, mixing Modbus ASCII with its 7 bit data word and Modbus RTU with its 8 bit data word will cause comm errors. The Modbus RTU spec calls for two stop bits for no parity, but many implementations ignore that and offer only a single stop bit. (Nowadays more slave implementations offer a choice of one or two stop bits). But having a device with 2 stop bits on the same drop as devices running 1 stop bit will cause problems. I'm not familiar with BSAP, one poster inferred that it was a derivative of Modbus, another that it can't co-exist on the same layer. I don't know. The alternative is to use multiple serial ports, one for each protocol. The drawing below shows a multiple port adapter with Honeywell FlameSafeguard running Modbus ASCII on one port, Honeywell Modbus RTU devices on a 2nd port, and former L&N devices running whatever protocol they had on a 3rd port. I can't recall enough details of the L&N devices to remember why they were segregated onto their own multi-drop line. Dan