"Verrrrrrry Interrrresting.... But, ______ !"
Sorry, couldn't help it! I really mean it when I say "very interesting". But, there really is a problem with the "question".
There is
NO WAY to accurately monitor and indicate the conditions as you describe. In fact, it is Logically Impossible !! And if you think about it for a few seconds, you might see that, that particular approach to alarm indicating is Locically Irrational!!
Logically Impossible because...
How do you handle 3 alarm conditions occurring on the same scan?
Logically Irrational because...
Why would you be more interested in the resulting alarm conditions than the casual alarm conditions?
I should (and do) think that the operators would be more interested in knowing why they were shut-down. Two flashing indicators associated with the last two modules of a process only tells me that those two modules are not running (or working, or whatever) as a result of some "causal factor".
ALARM SCHEMES:
There are five possible Alarm Schemes...
Case-1:
A fault condition at a particular place in the process causes the local-module and all up-line (Infeed**) modules to stop.
Case-2:
A fault condition at a particular place in the process causes the local-module and all down-line (Outfeed**) modules to stop.
Case-3:
A fault condition at a particular place in the process causes the local-module and all up-line (Infeed**) modules AND all down-line (outfeed*) modules to stop.
Case-4:
A fault condition at a particular place in the process causes the local-module and
some up-line (Infeed**) modules AND/OR
some down-line (Outfeed**) modules to stop.
Case-5:
A fault condition at a particular place in the process causes only the affected local-module to stop. Your code MUST be written so as to handle this condition... It wouldn't do to have an up-line module jamming product down the throat of a non-functioning module!
** INFEED & OUTFEED
In this context, the terms Infeed and Outfeed are Relative. That is, anything up-line from a particular module is considered INFEED to that particular module.
Likewise, anything down-line from a particular module is considered OUTFEED from that particular module.
The particular Alarm Scheme you use is entirely dependent upon the nature of the process! In some cases, a fault at one place does not necessarily constitute a fault at other places... or maybe it does... it depends on your process.
I develop and maintain code for a process that is 4-stories tall and 2-city-blocks long. In that code, I've used ALL of the above listed Alarm Schemes. The one that gets employed, at any particular time, depends on the nature of the fault and where, in the process, it occurs. In some cases, a particular fault requires that I execute a Controlled-Crash-Stop. The idea being, don't create more problems than you already have.
When a fault condition occurs, I should (and do) expect to see solid indications that "affected" modules have stopped.
At the same time, I expect to see a flashing indication showing the location of the CAUSE.
If the physical sequence (layout) of the indicators actually follows the physical & logical layout of the process, then, when an alarm (fault) condition occurs, I would expect to see a number of solid indications and a single flashing indication.
Depending on which "Alarm Scheme" you are using, you might see something like this...
S = Solid F = Flashing X = No Indication
PROCESS FLOW -->
Up-Line Down-Line
Case-1: Local and All Up-Line Modules Stop
S S S S S F X X X X X
-or-
Case-2: Local and All Down-Line Modules Stop
X X X X X F S S S S S
-or-
Case-3: ALL Modules Stop
S S S S S F S S S S S
-or-
Case-4: The Local and particular Up-Line and Down-Line Modules Stop
X X X S S F S S S X X
-or-
Case-5: Only the Local Module Stops
X X X X X F X X X X X
.
At last count I've got 85 steps of spaghetti code.
The very fact that you have spaghetti-code indicates that you have not planned this project before attempting to code it.
It drives me nuts to see "programmers" jump into code without a plan! The plan MUST be developed in terms of the process! Otherwise, as you have now, you end-up with useless spaghetti-code.
Designing-on-the-fly is Just Plain STUPID! (<<-- BTW, that word fits nicely into the blank at the top of this post).
Caveat:
Everything I've said is TRUE... for
the situation as you have described it.
If the situation is
not exactly as you have described... well...