Executing more than one Finate State machines

You can't have multiple concurrently changing FSM.

But you can have a loop that constantly performs:

for (;;) {
    eval_fsm1();
    eval_fsm2();
    eval_fsm3();.
    ...
    eval_fsmn();
}

Just make sure that you really do need n FSM that each depends on one or more other FSM, since the number of possible state combinations will be very high. Exactly how do you plan to prove the correctnes of the full system? You must prove every single state combination - that it leads to a correct state, and that you don't get any unexpected state loops.

An extra challenge is that changes will ripple through your state machines depending on where the loop currently is. This must be taken into account when you prove the soundnes of the FSM state changes. One solution to this can be that you let all FSM compute their new state based on the previous state of all FSM. then you step the state of all FSM before performing the next evaluation:

for (;;) {
    eval_fsm1();
    eval_fsm2();
    eval_fsm3();
    ...
    eval_fsmn();
    step_fsm_states();
}

Of course, there is no specific 8051 reason why you shouldn't make your state variables public so that everything can see them.

However, it sounds very much like you have a fundamentally flawed design here: if all the inputs and all the outputs and all the states are really shared, then you don't have separate state machines - you just have one big state machine!

I think you should probably revisit you system analysis and/or design...

Perhaps you should try googling for Hierarchical State Machines...

eg, www.state-machine.com/.../glossary.htm

one FSM should be able to see the state of other FSM....that is one FSM state will be input of other FSM.
Here be dragons e.g. what happens if one state machine 'jumps' two states. This is very dangerous and will be a nightmare to maintain/code, every - even minuscule - change to state machine a may make state machine b burp.

is it possible in 8051 programming....
has no bnearing on processor architecture.

Erik

.....and one FSM should be able to see the state of other FSM....

That sounds like an ugly hack at best, and a recipe for splitting headaches and excessively nasty bugs at worst.

If a system with multiple state machines is designed well, then the need for communication between the state machines is minimized (this means, in turn, that two separate state machines that constantly need to know about each others state should be combined into one). The communication between them can then be done using less hack-ish ways than peeking at each others internal variables.

Thanks for your valuable suggestion........

but I am need to design FSM for Points and Routes....In a Railway station there may be many points and many routes...To set a route, several points need to be in particular position....that is Route FSM sees the state of Point FSM...and to set a route conflicting routes states also to be verified...that is route FSM verifies other route FSM......This is the Idea of the design...and whether its is improper design??? if yes kindly justify me......and any other solution other than FSM for these types of system....

with regards,
G. Karthik Ragunath

There many different techniques for routing. I suggest that you google routing algorithms.
It appears to me that your task is very similiar to routing algorithms for telephone or PCB routing.
Bradford

Hai,

But routing algorithms is mainly to achieve shortest path in network...but my main intention is to achieve Fail safe Railway Interlocking.......
Concept:
Consider a route with two points....Points are one which connects one route to another route...point can be normal or reverse.... say if Point normal means the point can be connected to route1 and Point Reverse means can be connected to route2....

I hope u can understand my concept.....
to achieve this I am in need to need to see the status of point that is point FSM....to set the route that is route FSM.........

To set Route 1 point status should be normal and to set the route 2 point status should be reverse.....So route FSM depends on the Point FSM....there may be n number of points and n number of routes......

This is the concept......
with regards,

G. Karthik Ragunath

Surely, there must be well-established techniques to do this?!

If a switch only has two states, I woud nt treat it as a FSM. But in reality it has more.
- It has a state where it is in neither way - either because it is currently changing or you don't have contact with it.
- It may also have a state "broken", where you are in contact with the switch but the switch can't confirm either setting and have beeen like that longer than the time it takes to make a switch.
- In reality, you may also have a switch controlled manually or electrically. This could potentially mean that it can have an "override" attribute to.

Anyway - for a route, you would normally only care if a switch is correct or not. Incorrect because it is broken or incorrect because of a manual override or because you don't have contact with it or because you haven't changed the state yet.

But whatever you do - if you model each point with a FSM, this would represent a hierarchical system and not a system where any FSM takes the input of other FSM.