On Sat, Feb 18, 2012 at 10:23 PM, Herman Bruyninckx wrote: > I know at least one area where it achieves a lot less: reusability of the > coordination over different platforms. And the reason being that the data > flow state is a lot more tied to one particular platform than the "logic" > in a pure coordinator. ("Pure" meaning: only doing event logic > computations.) We have encountered lots of examples where it was impossible > to transfer an application written for one robot platform to another one > that was 100% capable of doing the task, but was using different data > flows. Simple example: porting an assembly task from an impedance > controlled platform to a force controlled platform. Very good point. That is exactly the sort of problem I'm interested in hearing about, to find out what is missing currently. We cannot have a complete system without data flow, so if that is not described within the state-machine, it is described somewhere else. >From my naive perspective, if the way that state-machine is embedded in the system is platform-specific, we still have something to solve. However, whether this is really a problem depends a bit on how difficult specifying the state-flow is, and furthermore, whether it is easier to model it outside of the state-machine. In my personal experience, and Jonathan seems to be making the same point, I have found that the state-machine needs to interact with the data-flow anyway, and that this does not make it particularly platform-specific. This may depend on the problem we're trying to solve, though, so let me describe what I'm doing shortly: For example, in my coordination state-machines, one typical use-case is deciding whether a request for an action should or can be performed, given the current (global) system-state, and if yes, the request is passed on to the corresponding component, to perform the action. In that situation, information is passed from the requesting component to the executing one by the coordination component, which is internally modeled as state-chart. The state-chart doesn't need to know very much about the goal, however. Often, the goal specification is opaque, and is just copied from an incoming to an outgoing event. In such a situation, the functionality to locally store and pass on data is essential. Another typical situation is to decide which of several possible actions to take, depending on the content of an input event. This requires looking at the input in detail, and again all or part of its payload may need to be copied as information for the executing component. For that to work well, the state-machine needs to be fairly independent of the specific data types being exchanged. My coordination implementation has substantial independence in that way, but it comes at a cost, of course. For example, I use mappings to a common attribute-value representation internally, and flexible path-matching expressions to analyze the data further. I recognize that not all state-machines implementations might want to do this. I have chosen this approach, because my coordination tasks are at the interface between different parts of the system, so some munging of incoming to outgoing data is unavoidable. However, I realize that if you want to model coordination between some fairly closely coupled components, then all of this might be just overhead, and because the interacting components are coupled anyway, it might be a better idea to set up data-flow between them directly, and just pass some control events in and out. Is that your approach or are you doing something different entirely? cheers, -- Ingo Lütkebohle Bielefeld University http://www.techfak.uni-bielefeld.de/~iluetkeb/ PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B