Beno or others…
I am just about to start on project for FLYSTL where I will be moving the 2 groov servers from rack mounted PC’s to 2 virtual PCs. The virtual pcs are the airports and I will simply be reinstalling the current strategy.
While this is going on, there is another problem that has long plagued the operation of this system, that is where one EB2 brain goes off-line briefly, and then comes back later but has since been dropped by the S1 as failed and the ROK has switched. The airport IT guys say that after everything is reset, the EB2 remains off line until they go in and force Pac Control to re-establish comms to that brain.
Now, where I am going with this is, it seems to me that I had IO_Enabler chart running in the beginning, but I remember that there was some kind of interaction between the ROK and the Enabler chart. So at that time I disabled the chart.
Now, this could be an EB2 problem, or a network problem, or something else, but I am interested to know how the developer of the ROK feels about this issue.
Here are the issues:
- There is no sense in switching to another controller if the problem is a brain not communicating.
- What are the specific triggers the ROK considers to be a switchover event?
- Can I use the enabler chart and if not, why not?
I have recommended that I remove the ROK and just use a solid state output to switch over to another S1 if the heartbeat relay timer times out, if I can’t resolve the temporary brain off-line issue.
That is not the best possible direction, since the tunnels might be in the middle of a fire event with some of the fans on, some not, and a whole bunch of other conditions not even imagined yet.
Currently this brain goes off line maybe as much as once a month to the extent it is failed by the s1, however, I just found out that the brain goes off line more often, just not long enough for a comms failure.