Execution engine design discussion (Was Re: [notes about] What's going on... ?)

On Mon, 26 May 2003 [email protected] wrote:

> Herman Bruyninckx
> | 
> | [... genom, execution engine ...]
> | We have also been discussing on and off about what exactly should be
> | the responsibility of the execution engine. We arrive at three
> | different aspects:
> | - logic control: i.e., some outputs are Boolean functions of some
> |   inputs. This is the basic "PLC" functionality. I don't know where
> |   you would put such kind of logic in the Genom framework.
> 
> I don't really see what you mean here. Maybe an example?

Okay! Assume you want to signal an "emergency stop" event if one of
several inputs exceed are logically high. This would be the Boolean OR
of these inputs, driven to a hardware output line.
Another example, before starting the motors of a robot, the brakes
must have been switched off; this is also "relay logic".

[...]
> | - configuration control, i.e., make sure that an application can only
> |   start if all components in the application are properly installed
> |   and configured.
> 
> I would rather see this as an external functionality (outside functional
> modules and execution engines). 

I agree. To a certain extent: the "external level" you are talking
about is again a control level, but not a "continuous-time" (or
certainly not real-time) level. The conceptual structure of that
higher control level, however, will look much the same as the
continuous-time level, so an "execution engine" would be needed there
too.

[...]
> | So, this means (implicitly) that you let the execution engine use
> | "threads" as its basic elements. And what does it do with these basic
> | elements? Scheduling, I guess?  If so, that means that you only see
> | the above-mentioned "sequencing control" as part of the execution
> | engine?
> 
> Yes, sequencing and event handling as well as inter-component
> communication (data exchange). 

Ok, I understand.

> I think that when the OS provides
> scheduling we should use it: there's no need to stack redundant layers on
> top of the OS's ones.

Unless you can gain a lot by this extra layer. For example, our
real-time core schedules the control components' activities _much_
better than the scheduler of the (RT)OS, because it _knows_ the
structural dependencies of the various control components.


> However, for a module that would run on a micro-controller without any
> underlying OS, then the execution engine could implement such a
> scheduling. As you can see the definition and the exact role of the
> execution engine is to fill the gap between the low level code (OS
> interface, hardware, ...) and the high level code which implements the
> algorithm you want to run.
> 
Yes, I understand. I think.
We call this the "Operating System Interface", because there is also
the gap between the "logical" hardware your robot control algorithms
work with and the real bare hardware. We encapsulate this in the
"Device Interface".

I think (or rather, I am sure) we look at these things along the same
lines. (We did already last year, anyway.) So, it's time to sit
together (possibly virtually) and discuss the concrete API and the
implementation aspects.

Herman

-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480