hierarchical component system states and dependencies

[PaulL]

We designed our system components with five states: Off, Standby, Disabled, Enabled, Fault. (We didn't base this off a standard, but we did have some examples.)

A given component may have one or more subcomponents. A subcomponent never cares about the state of a supercomponent, but a component may care about the state of a subcomponent. We are actively debating how much so, though. In particular, if one of component A's subcomponents is in FaultState, does that mean that A is also in FaultState? We have to date answered that question one way (successfully) but now we are revisiting this.

I have searched without any real success the last couple days for a great paper, book, example, or standard that will help here, but I haven't found much. Maybe I don't know the right keywords. Does anyone here know of a good reference?

[Daklu]

No help on the references, but I don't think you can answer that question for the general case. It depends on your system.

For example, in a Car component if the Radio component faults (stops working) should the Car fault too? Conversely, if the Car's Accelerator component faults (sticks on), it might be a good idea to stop the Car as well.

[Edit - Curious, why are you revisiting the question?]

[PaulL]

Well, I know (at least at the detailed state level) we may have to make system-dependent choices.

On the other hand, I think there can be a consistent approach (at least by having consistent criteria for distinguishing between cases) to high-level states for certain types of systems.

One example:

Component A supervises components B and C. C reports a fault. Does A report that it is in fault state (even if C's state is always visible to the user.) What, if anything, do we do with B in this case?

We are revisiting this because, while we have something that works in one large subsystem, another subsystem presents a different set of issues that we could solve the same way but for which we also can make a strong argument for choosing a different solution. We are looking for a firmer basis on which to discern which is the better solution.

[Daklu]

I doubt this will be much help...

Component A supervises components B and C. C reports a fault. Does A report that it is in fault state (even if C's state is always visible to the user.) What, if anything, do we do with B in this case?

I can tell you what I do, but my apps are designed to be event-driven and heavily message based rather than state driven. It sounds like you have designed Component A to respond directly to state transitions in B or C, and my patterns may not work well in that paradigm.

Typically in my app a component will only enter an error state if it has an internal error. In C's error state I do whatever I need to do to manage the error. If I can self-recover I'll do that. If not I'll report the error and return to some other predefined state, such as 'standby.' Using your example, A doesn't have an internal error, so it doesn't report that it has faulted.

Component A does have message handlers to respond to error messages from sub components. Different error messages will trigger different responses. Sometimes it will shut down the entire system. Other times it will just notify the user and continue.

We are revisiting this because, while we have something that works in one large subsystem, another subsystem presents a different set of issues that we could solve the same way but for which we also can make a strong argument for choosing a different solution. We are looking for a firmer basis on which to discern which is the better solution.

Wow... that's vague enough to make a CIA censor smile.

Are the two solutions you're considering 1) propogating the fault state up through the component hierarchy, and 2) not propogating the fault state up through the component hierarchy?

[ShaunR]

Are the two solutions you're considering 1) propogating the fault state up through the component hierarchy, and 2) not propogating the fault state up through the component hierarchy?

If it is..... I would choose No3. Each module is configurable to do No1 or No2 to it's immediate owner.

[PaulL]

Thanks for the responses, gentlemen.