How to handle initial state in an event-driven architecture?

Question

In an event-driven architecture each component only acts when an event is sent through the system.

Imagine a hypothetical car with a brake pedal and a brake light.

• The brake light turns on when it receives a brake_on event, and off when it receives a brake_off event.
• The brake pedal sends a brake_on event when it is pressed down, and a brake_off event when it is released.

This is all well and good, until you have the situation where the car is turned on with the brake pedal already pressed down. Since the brake light never received a brake_on event, it will stay off - clearly an undesirable situation. Turning the brake light on by default only reverses the situation.

What could be done to resolve this 'initial state problem'?

EDIT: Thank you for all the responses. My question was not about an actual car. In cars they solved this problem by continuously sending the state - therefore there is no startup issue in that domain. In my software domain, that solution would use many unnecessary CPU cycles.

EDIT 2: In addition to @gbjbaanb's answer, I'm going for a system in which:

• the hypothetical brake pedal, after initialization, sends an event with its state, and
• the hypothetical brake light, after initialization, sends an event requesting a state event from the brake pedal.

With this solution, there are no dependencies between components, no race conditions, no message queues to go stale, and no 'master' components.

Answer 1

There are many ways to do this, but I prefer to keep a message-based system as decoupled as possible. This means the overall system cannot read the state of any component, nor any component read the state of any other (as that way lies spaghetti ties of dependancies).

So, while the running system will look after itself, we need a way to tell each component to start itself up, and we already have such a thing in the component registration, ie at startup the core system has to inform each component that it is now registered (or will ask each component to return its details so it can be registered). This is the stage at which the component can perform its startup tasks, and can send messages as it would do in normal operation.

So the brake pedal, when the ignition is started, would receive a registration/check message from the car management and it would return not only a "I'm here and working" message, but it would then check its own state and send the messages for that state (eg a pedal depressed message).

The problem then becomes one of startup dependancies, as if the brake light is not yet registered then it will not receive the message, but this is easily resolved by queuing all of these messages until the core system has completed its startup, registration and check routine.

The biggest benefit is that there is no special code required to handle initialisation except that you already have to write (ok, if your message-sending for brake pedal events is in a brake-pedal handler you will have to call that in your initialisation too, but that's usually not a problem unless you've written that code tied heavily to the handler logic) and no interaction between components except those that they already send to each other as normal. Message passing architectures are very good because of this!

Answer 2

You can have an initialize event which sets states appropriately upon load/startup. This can be desirable for simple systems or programs not including multiple hardware pieces, however for more complicated systems with multiple physical components as you run the same risk as not initializing at all - if a "brake on" event is missed or lost along your communication system (for example, a CAN based system) you may inadvertently set your system backwards as if you started it with the brake depressed. The more controllers you might have, such as with a car, the higher likelihood something is missed.

To account for this, you can have the "brake on" logic repeatedly send out "brake on" events. Perhaps every 1/100 second or something. Your code containing the brain can listen for these events and trigger "brake on" while it is receiving the them. After 1/10sec of not receiving "brake on" signals it triggers an internal "brake_off" event.

Different events will have considerably different timing requirements. In a car, your brake light needs to be much faster than say your check fuel light (where a multisecond delay is probably acceptable) or other less important systems.

Complexity of your physical system will dictate which of these approaches is more appropriate. Given your example is a vehicle, you probably would want something similar to the latter.

Either way, with a physical system, you do NOT want to rely on a single event being received/processed correctly. Connected microcontrollers on a networked system often have a "I'm alive" timeout for this reason.

Answer 3

In this case, I would not model the brake as a simple on/off. Rather, I would send "brake pressure" events. For example, a pressure of 0 would indicate off and a pressure of 100 would be fully depressed. The system (node) would constantly send break pressure events (at a certain interval) to the controller(s) as needed.

When the system was started it would start to recieve pressure events until it was turned off.

Answer 4

If your only means of passing state information is through events, then you are in trouble. Instead, you need to be able to both:

1. query the current state of the brake pedal, and
2. register for "state changed" events from the brake pedal.

The brake light can be seen as an observer of the brake pedal. In other words, the brake pedal does not know anything about the brake light, and can operate without it. (This means that any notion of the brake pedal proactively sending an "initial state" event to the brake light is ill-conceived.)

Upon instantiation of the system, the brake light registers with the brake pedal to receive braking notifications, and also reads the current state of the brake pedal and turns itself on or off.

Then, the braking notifications can be implemented in one of three ways:

1. as parameterless "braking pedal state changed" events
2. as a pair of "braking pedal is now depressed" and "braking pedal is now released" events
3. as a "new breaking pedal state" event with a "depressed" or "released" parameter.

I prefer the first approach, which means that upon receiving the notification, the brake light will simply do what it already knows how to do: read the current state of the brake pedal and turn itself on or off.

Answer 5

In an event-driven system (which I currently use and love), I find it important to keep things as decoupled as possible. So with that idea in mind, let's delve right in.

It's important to have some default state. Your brake light would take the default state of 'off' and your brake pedal would take the default state of 'up'. Any changes after that would be an event.

Now to address your question. Imagine your brake pedal being initialized and pressed down, the event fires, but there's no brake lights yet to receive the event. I have found it easiest to separate the creation of the objects (where the event listeners would get initialized) as a separate step before initializing any logic. That will prevent any race conditions as you've described.

I also find it awkward to use two different events for what is effectively the same thing. brake_off and brake_on could be simplified into e_brake with a parameter bool on. You can simplify your events this way by adding supporting data.

Answer 6

What you need is a broadcast event and message inboxes. A broadcast is a message that is published to an unspecified number of listeners. A component can subscribe for broadcast events so it only receive events that it is interested in. This provides decoupling, as the sender doesn't need to know who the receivers are. The subscription table needs to be statically configured during component installation (instead of when the is initialized). The inbox is a part of the message router that acts as a buffer to hold messages when the destination component is offline.

Using invoices brings one problem, which is inbox size. You don't want the system to have to retain a growing number of messages for components that will never be online anymore. This is important especially with embedded system with strict memory constraints. To overcome inbox size limit, all broadcasted messages need to follow a few rule. The rules are:

1. every broadcast events requires a name
2. at any given time, the sender of a broadcast event can only have one active broadcast with a specified name
3. the effect caused by the event must be idempotent

The broadcast name needs to be declared during component installation time. If a component sends a second broadcast with the same name before the receiver processes the previous one, the new broadcast overwrites the previous one. Now you can have a static inbox size limit, which can be guaranteed to never exceed a certain size and can be precalculated based on the subscription tables.

Finally, you also need a broadcast archive. The broadcast archive is a table that holds the last event from each broadcast name. New components that are just installed will have its inbox prepopulated with messages from the broadcast archive. Like the message inbox, the broadcast archive can also have static size.

Additionally, to deal with situation where the message router itself is offline, you also need message outboxes. The message outbox is part of the component that holds outgoing message temporarily.