Skip to main content
Software Engineering

Return to Question

spelling
Source Link
kevin cline
kevin cline
  • 33.7k
  • 3
  • 72
  • 142

Background

Recently, I have been fascinated about the possibilities of dataflow-based programming approaches - in particular, signal/event-based concepts as realized by functional reactive programming, Boost::Dataflow::Signals, and the like.

Sample scenario:

Consider a car that has four speed sensors, one at each of its tires. Let's simplify things and say that these sensors are analog sensors providing the measured speed at that tire. The car further has individual breaksbrakes on the four tires (the actuators) that one can program to break more or less strongly.

There is no concrete task, but imagine having to realize things like detecting tires not turning due to aqua-planing, or ABS-support, or or or... In short: you have to evaluate the speed sensor data and control the actuators according to some logic.

From a programming point of view, one could think of realizing this via a signal-network of the following sort:

timer ------------\
sensor1/2/3/4 -> logic -> brakes1/2/3/4

(That is, the timer triggers the logic, which takes the latest analog values of the sensors)

Like this, the timer can be programmed to trigger in fixed intervals (especially important to ensure the real-time constraints).

The advantage of the dataflow-approach here is that the above diagram is directly realized in the code, i.e. you have a logical wiring of signals and just need to provide an implementation that turns your actual hardward sensor's data into a signal (of the corresponding library you are using).

When it comes to real-time requirements, the maximal signal path length can also be computed (or at least more easily derived from the source).

The question

Of course, all of this is just an application idea and I am sure several brilliant people have come up with this before. What I am looking for is the follow-up. Are there any hard problems with this scenario which make it unrealizable in practice? Are there experiences from real-world projects on following such a line of thought? Is there even existing literature on this?

To make things clearer and more objective, I am looking for an answer that either shows an inherent fault in my line of thinking or provides reference to existing work/literature along with evaluations. Bonus points if real-time constraints are taken into account.

Background

Recently, I have been fascinated about the possibilities of dataflow-based programming approaches - in particular, signal/event-based concepts as realized by functional reactive programming, Boost::Dataflow::Signals, and the like.

Sample scenario:

Consider a car that has four speed sensors, one at each of its tires. Let's simplify things and say that these sensors are analog sensors providing the measured speed at that tire. The car further has individual breaks on the four tires (the actuators) that one can program to break more or less strongly.

There is no concrete task, but imagine having to realize things like detecting tires not turning due to aqua-planing, or ABS-support, or or or... In short: you have to evaluate the speed sensor data and control the actuators according to some logic.

From a programming point of view, one could think of realizing this via a signal-network of the following sort:

timer ------------\
sensor1/2/3/4 -> logic -> brakes1/2/3/4

(That is, the timer triggers the logic, which takes the latest analog values of the sensors)

Like this, the timer can be programmed to trigger in fixed intervals (especially important to ensure the real-time constraints).

The advantage of the dataflow-approach here is that the above diagram is directly realized in the code, i.e. you have a logical wiring of signals and just need to provide an implementation that turns your actual hardward sensor's data into a signal (of the corresponding library you are using).

When it comes to real-time requirements, the maximal signal path length can also be computed (or at least more easily derived from the source).

The question

Of course, all of this is just an application idea and I am sure several brilliant people have come up with this before. What I am looking for is the follow-up. Are there any hard problems with this scenario which make it unrealizable in practice? Are there experiences from real-world projects on following such a line of thought? Is there even existing literature on this?

To make things clearer and more objective, I am looking for an answer that either shows an inherent fault in my line of thinking or provides reference to existing work/literature along with evaluations. Bonus points if real-time constraints are taken into account.

Background

Recently, I have been fascinated about the possibilities of dataflow-based programming approaches - in particular, signal/event-based concepts as realized by functional reactive programming, Boost::Dataflow::Signals, and the like.

Sample scenario:

Consider a car that has four speed sensors, one at each of its tires. Let's simplify things and say that these sensors are analog sensors providing the measured speed at that tire. The car further has individual brakes on the four tires (the actuators) that one can program to break more or less strongly.

There is no concrete task, but imagine having to realize things like detecting tires not turning due to aqua-planing, or ABS-support, or or or... In short: you have to evaluate the speed sensor data and control the actuators according to some logic.

From a programming point of view, one could think of realizing this via a signal-network of the following sort:

timer ------------\
sensor1/2/3/4 -> logic -> brakes1/2/3/4

(That is, the timer triggers the logic, which takes the latest analog values of the sensors)

Like this, the timer can be programmed to trigger in fixed intervals (especially important to ensure the real-time constraints).

The advantage of the dataflow-approach here is that the above diagram is directly realized in the code, i.e. you have a logical wiring of signals and just need to provide an implementation that turns your actual hardward sensor's data into a signal (of the corresponding library you are using).

When it comes to real-time requirements, the maximal signal path length can also be computed (or at least more easily derived from the source).

The question

Of course, all of this is just an application idea and I am sure several brilliant people have come up with this before. What I am looking for is the follow-up. Are there any hard problems with this scenario which make it unrealizable in practice? Are there experiences from real-world projects on following such a line of thought? Is there even existing literature on this?

To make things clearer and more objective, I am looking for an answer that either shows an inherent fault in my line of thinking or provides reference to existing work/literature along with evaluations. Bonus points if real-time constraints are taken into account.

Source Link
Frank
Frank
  • 14.4k
  • 3
  • 42
  • 67

Real-time Dataflow Programming

Background

Recently, I have been fascinated about the possibilities of dataflow-based programming approaches - in particular, signal/event-based concepts as realized by functional reactive programming, Boost::Dataflow::Signals, and the like.

Sample scenario:

Consider a car that has four speed sensors, one at each of its tires. Let's simplify things and say that these sensors are analog sensors providing the measured speed at that tire. The car further has individual breaks on the four tires (the actuators) that one can program to break more or less strongly.

There is no concrete task, but imagine having to realize things like detecting tires not turning due to aqua-planing, or ABS-support, or or or... In short: you have to evaluate the speed sensor data and control the actuators according to some logic.

From a programming point of view, one could think of realizing this via a signal-network of the following sort:

timer ------------\
sensor1/2/3/4 -> logic -> brakes1/2/3/4

(That is, the timer triggers the logic, which takes the latest analog values of the sensors)

Like this, the timer can be programmed to trigger in fixed intervals (especially important to ensure the real-time constraints).

The advantage of the dataflow-approach here is that the above diagram is directly realized in the code, i.e. you have a logical wiring of signals and just need to provide an implementation that turns your actual hardward sensor's data into a signal (of the corresponding library you are using).

When it comes to real-time requirements, the maximal signal path length can also be computed (or at least more easily derived from the source).

The question

Of course, all of this is just an application idea and I am sure several brilliant people have come up with this before. What I am looking for is the follow-up. Are there any hard problems with this scenario which make it unrealizable in practice? Are there experiences from real-world projects on following such a line of thought? Is there even existing literature on this?

To make things clearer and more objective, I am looking for an answer that either shows an inherent fault in my line of thinking or provides reference to existing work/literature along with evaluations. Bonus points if real-time constraints are taken into account.