Hello all,
I have poked around and performed all the normal searches, and I haven't seen discussion of any high availability work being done with Proview. I was wondering if any development effort has been pushed this direction?

Thanks,
Matt

Hi Matt,

Redundancy is a point in our development plan, but our automation engineers haven't put any pressure on this so we're still in the state of trying to figure out the best technique to use.

/Claes

Hi Matt,
I am also anxious waiting for EP redundancy. This will be a great qualitative leap for Proview.
There is a thread where the topic "Redundant process station" was mentioned, which you can see. But they are just ideas and one experience for Modbus I / O.
In my case Profibus has not been tested yet.
As Claes says hopefully as automation engineers put more pressure on this.
Meanwhile we have to wait.

Eduardo

Eduardo,
Thanks for chiming in!

I was thinking that it might be instructive for a group of us (possibly in this thread) to discuss and possibly rank those aspects of HA that might be useful. What do you think about that?

There are a pretty obvious laundry list of things to do, but if it was itemized and detailed, maybe the the engineers involved will see opportunities in the code they have to manipulate to put in the scaffolding for the HA work.

Even if not, a solid list of HA features, based on the user bases preferred method(s) of operation would be useful when development begins. No?

-Matt

Hi all,

I'm defintely interested in this thread even if I have learned how to do without it for years !

IMO one of the key driver to go to HA is really to distinguish what automation engineer do want to be redundant, I mean what are the critical element that need redundancy and what is the related scantime required.

In a previous programmer life, our R&D put lots of energy to develop a HA feature into our proprietary automation bench (basilcally by synchronising the whole DB between many station) which make everyone very enthousiast but a the end the result was a working synchronised system at approx 100ms which was definitely too slow for most of us (I do need ideally to reach 20 ms task syncrhonization or at minimum 50ms in order to have use of it.

But for sure this time requirement is very different depending on the process you work on. So to me, to make progress on such a very time consuming feature (for developper I mean), the base is to be able to provide to developper like Claes a rough idea of how many variable and at which frequency you need to synchronize. This will totally prevent or lead to some specific solution. Moreover have this relexion sometimes lead to the conclusion that you only need very few critical variables to be sycnrhonized and you can in most of the case do this by hand throught a specific inter machine communication bus like ethernet or whatsoever.

Hope this personnal opinion may help some of you

Snarf

So, based on your statement,Snarf77, it sounds like a good thing to do.

I have added a generalized DCS design to this thread. From that we should be able to work out the individual components that could or should be made HA. I realize that other people have different structures, and with luck we can discuss a few of them.

Also, my experience in DCS/SCADA work has made me look for standardizations, that I think the nomenclature is still haphazard going from one place to another so I would love to see like an equivalents table come out of this.

In the system we are implementing, we basically have 4 general types of systems.

1. Application Server - tasked with exchanging data with the the HMI systems and manipulating any data required to simplify or augment data for human consumption. This system will also provide any offloading of data to database or historian systems. In proview parlance, I see this as a process node with a specific job.
2. Automation Server - Tasked with gathering data from distributed I/O and dedicated PLCs, as well as anything real-world that needs more processing than a conventional plc can performe. These systems can also be used to serve as communications processors gathering data in one format and providing it in another, for example gathering data from a modbus network and providing it to a profibus network. In our system it is the closest general purpose computing device to the PLCs, but in smaller settings could be a PLC itself. In proview parlance, I see this as a process node with a specific set of jobs.
3. HMI system - Human Machine Interface - The hardware display device that provides the user with the software client and interface to interact with the larger DCS/SCADA environment. It has no other purpose and should not be encumbered to do many other tasks. In proview parlance, I see this as an operator station.
4. PLC - Programmable Logic Controller - A purpose built computer that has I/O dedicated to gathering real world physical data via inputs and either responding to that data with real-world physical outputs or sending that data to and automation server.

Between each of these lies a network. I'm thinking about a series of options for redundancy there. I think that this is easiest to deal with, as methods for path diversity are pretty straight forward in the networking world. I would like to discuss this, but I see this as being a discussion for another thread.

Here is the representation:


So, just looking at the 4 basic components above I see all but the PLCs as needing some level of redundancy.

In my case, using commodity devices and leveraging the network to send data to redundant hardware devices where there is a provision for a heartbeat and a method for determining which machine is in control seems least expensive after looking at HA hardware with redundant motherboards and synchronized memory.

I have no earthly idea where to begin to make preview generate a useful heartbeat, but I know that high availability clustering and its software are available.
This is one example: clusterlabs.org/

I realize that the timing involved makes this is an interesting proposition.

There is more I could type, but this is a start...