Hi There,

I am involved in an offshore pumping project that requires recording of pumping parameters eg rate pressure etc. The normal setup is to collect the sensor signals (both 4-20mA and 12V pulses from prox. switches) via data concentrators, and via the concentrators RS232 port, send the data to a PC. My present requirement is to have a redundant PC running. Is there a way to "split" the RS232 signal out of the concentrator without messing up the interrogation command out of the PC? Do I need to convert to RS485 or 422?

Mervyn R. Stewart
Process Safety Systems

 

Assuming you're using Modbus or some such protocol that permits multidrop communications, you could do it, but you won't be happy with the results. I've done it on the bench, but it didn't work on the factory floor. Go with RS485.

 

It's not a matter of splitting the signal -- but monitoring the signal.

The hardware aspect is quite simple - just monitor the data side of the conversation. Do not connect to the PC Transmit side.

Now the hard part.

The serial conversation between your concentrator and the PC may or may not use some sort of protocol to facilitate the transfer. When monitoring the data transmissions from the concentrator to the PC use a 'terminal emulator'
program to 'see' the data received. Enable the program to display RAW ASCII. If you see embedded characters 'before' and 'after' the transmission
[several characters after the transmission usually contains either a checksum or crc value]. Chances are there is some sort of protocol being
used. You will need some translation program to strip out the protocol.

Another problem with monitoring data with a third party PC is the issue of time stamping the event as it occurs.

I'm sure someone has run across this and written a program to address this.

Dave Gunderson Hoover Dam Comm and Control Gp
Web Site: http://www.river.f2s.com

 

This presents a number of interesting questions.

Why a redundant PC?

I assume that you want a warm or hot standby. In which case, what sort of failure are you protecting yourself from? The only failure this is really good against is a hardware failure on the master, or a break in the serial line between the primary and the split. But duplicating the hardware and running it in parallel increases the likelihood of failure, which may just as easily occur on the backup.

If the software on the primary fails, it's likeliest to be caused by incoming data. If the backup is running identical software, it is just as susceptible to the failure as the primary.

One respondent suggested that line needn't be split, but monitored with an RS-232 connection that has no transmit signal. If the redundant PC is to serve as a backup, then the serial connection to the redundant PC cannot be disabled for transmit.

If the query from the primary PC is not passed to the redundant PC, then the redundant must be able to figure out from the response what data was requested. Does your protocol define responses that unambiguously identify the data content?

Also, the I/O driver on the redundant must be aware that it is redundant and listen but not query. How does the redundant take over the primary role? How does the I/O driver get informed that it must switch from passive monitoring to active querying?

If the failover to the standby is automatic, which machine decides? If the responsibility lies with the master, and its software fails, then the failover may not occur.

If the backup decides, then based on what? Unless it is also monitoring the health of the master, the only information available to it is the presence of data at the communications port. And a lack of data may indicate a failure on the master, a failure at the data concentrator, or a failure of the backup's own serial port.

The approach we took with a client who had a redundancy requirement was to have the two PC's running serial I/O drivers that communicated with one another via ethernet. Each driver knew its role and could monitor the health of the other driver. (Of course, we had to have a separate program monitor the health of the ethernet.) The drivers talked to the field through a commandable serial port switch. This device was basically an A/B switch, passing signal from only one of the two PCs, but back to both of them. The switch could be commanded from either port to change which PC could write.

I must say I wasn't very happy with this "solution". It added much more complexity (and increased potential for failure) than I felt was justified by the protection it offered. (And the serial switch represented an additional single point of failure.)

- greg

 

The hardware aspect is probably the easiest to solve. Use of a switch or EIA-485 conversion will allow all three to be connected. However, the protocol used to collect the data is critical and may indicate other hardware solutions.

Most simple protocols will not tollerate multiple master devices. This is because they are based on masters spontaneously polling slaves. If there were multiple masters then there would be a need
to avoid or resolve collisions (CD/CSMA or token passing or something similar).

If your protocol uses unsoliticed messaging from the slave devices with no data requests or acknowledgements from the masters, you could simply connect them so that both PCs can "listen" to the data stream.

Assuming you need to do poll/response as most protocols do, the next consideration is how you want your PC to be redundant. As you've seen on the automation list, there are lots of opinions on
what the best redundancy strategy is. Perhaps a simple, manual switch will that you can place in the right position when you use the redundant machine will work.

There are also more sophisticated serial data processing devices that are often called communications processors. These devices have many ports that can be either master or slave ports and allow you to collect data from one source, copy or manipulate it, and make it available for two independent masters. You can even coordinate incoming controls. A communications processor would allow you to have both PCs running simultaneously.

While some might reason that the communications processor is a single point of failure, to get true reduncancy you would actually need backup instruments in the field which it didn't sound like you were interested in doing. I can give you more information on sources of communications processors if you're interested.

Darold Woodward PE
Schweitzer Engineering Laboratories
[email protected]

 

You raise many interesting questions. I can say from experience that trying to implement server redundancy with software that wasn't created and thoroughly tested for redundancy is a nightmare. The complexity of the redundancy makes the system far less reliable than it would have been without redundancy not to mention the greatly increased complexity of maintaining the system.

 

Even when your create a system to achieve redundancy, transferring control from one PC cpu to another PC cpu requires that not only the bus interface to the I/O be switched in a time
element that does not cause loss of the digital and analog devices but also that the configuration information be current in the back-up machine. We developed and patented the hardware for controlling the Pmux bus, and subsequently developed robust software for
bumpless Hot Shadowing Back-up Systems using PC's and Pmux based I/O systems that control our chemical processes. Today we take the performance of the system as a given, but the road to
robust performance was filled with many unexpected challenges.