Dear List,
It is largely unspecified in UML2 when state transitions are
evaluated, the only restriction being that a run-to-completion step
(which represents the actions performed during transition (exit, do,
init)) may not be interrupted. The remaining semantic variation is
commonly captured in two models:
1) discrete time model
2) continuous time model
In the discrete time model a state machine is advanced after fixed
time units. At each step events are processed which accumulated since
the previous step. OROCOS state machines work according to this model.
The advantages of this model are that the execution of the state
machine is more deterministic (no supersteps, see below, possible) and
it allows prioritization / scheduling of the accumulated events.
In the continuous time model events are processed as they occur. This
may result in so called supersteps, which are multiple
state-transitions within a single time instant.
The advantage of this time model is the lower latency (ideally zero)
involved in the reaction to events, though at the price of less
deterministic behavior.
So from a practical point of view model 1) seems suitable for
classical state machine applications, whereas 2) appears more
appropriate for reactions to rare but critical conditions.
Therefore a third, hybrid variant could be imaginable: combine both
discrete and continuous time models by defining sets of events which
are to be treated either according to one or the other model. For
example this would allow the logic of the automaton to be modeled with
the more deterministic model 1) and real-time critical events be
handled at the lowest possible latency using model 2).
Has anybody ever missed the lack of the continuous time model in
OROCOS state machines? Any comments?
Best regards
Markus
Time models for state machine progression
On Fri, Sep 26, 2008 at 9:38 AM, Markus Klotzbücher
<markus [dot] klotzbuecher [..] ...> wrote:
Hi Markus,
[it's paste twelve, so forgive any nonsense below :-)]
> It is largely unspecified in UML2 when state transitions are
> evaluated, the only restriction being that a run-to-completion step
> (which represents the actions performed during transition (exit, do,
> init)) may not be interrupted.
AFAIK orocos does nothing to avoid preemption during such a
run-to-completion step. Is that something in which the RTT deviates
from the UML specificiation?
> The remaining semantic variation is commonly captured in two models:
> 1) discrete time model
> 2) continuous time model
Are these two models mentioned in the spec too, or is that information
you gathered somewhere else?
> In the discrete time model a state machine is advanced after fixed
> time units. At each step events are processed which accumulated since
> the previous step. OROCOS state machines work according to this model.
They do if their owner-Taskcontext is connected to a periodicActivity.
> The advantages of this model are that the execution of the state
> machine is more deterministic (no supersteps, see below, possible) and
> it allows prioritization / scheduling of the accumulated events.
>
> In the continuous time model events are processed as they occur. This
> may result in so called supersteps, which are multiple
> state-transitions within a single time instant.
OK, I have seen often that people refer to this scheme as "discrete
event" (iso continuous time)
> The advantage of this time model is the lower latency (ideally zero)
> involved in the reaction to events, though at the price of less
> deterministic behavior.
>
> So from a practical point of view model 1) seems suitable for
> classical state machine applications, whereas 2) appears more
> appropriate for reactions to rare but critical conditions.
>
> Therefore a third, hybrid variant could be imaginable: combine both
> discrete and continuous time models by defining sets of events which
> are to be treated either according to one or the other model. For
> example this would allow the logic of the automaton to be modeled with
> the more deterministic model 1) and real-time critical events be
> handled at the lowest possible latency using model 2).
>
> Has anybody ever missed the lack of the continuous time model in
> OROCOS state machines? Any comments?
It is available if you connect your TaskContext to a
NonPeriodicActivity (unless I misunderstood you).
Best regards,
Klaas
Time models for state machine progression
Hi Klaas,
On Sat, Sep 27, 2008 at 12:26:30AM +0200, Klaas Gadeyne wrote:
> On Fri, Sep 26, 2008 at 9:38 AM, Markus Klotzbücher
> <markus [dot] klotzbuecher [..] ...> wrote:
> Hi Markus,
>
> [it's paste twelve, so forgive any nonsense below :-)]
I can't see any nonsense...!
> > It is largely unspecified in UML2 when state transitions are
> > evaluated, the only restriction being that a run-to-completion step
> > (which represents the actions performed during transition (exit, do,
> > init)) may not be interrupted.
>
> AFAIK orocos does nothing to avoid preemption during such a
> run-to-completion step. Is that something in which the RTT deviates
> from the UML specificiation?
No, the standard even explicitly notes that run-to-completion could be
implemented by a thread which might be preempted. What's important is
that this instance of a state machine is not advanced by any other
thread, so that when the preempted thread resumes it simply continues
its RTC step.
> > The remaining semantic variation is commonly captured in two models:
> > 1) discrete time model
> > 2) continuous time model
>
> Are these two models mentioned in the spec too, or is that information
> you gathered somewhere else?
No, they are not mentioned in the standard. I've seen these two models
here and there, but I think the source is this paper [1].
> > In the discrete time model a state machine is advanced after fixed
> > time units. At each step events are processed which accumulated since
> > the previous step. OROCOS state machines work according to this model.
>
> They do if their owner-Taskcontext is connected to a periodicActivity.
Yes, right.
> > The advantages of this model are that the execution of the state
> > machine is more deterministic (no supersteps, see below, possible) and
> > it allows prioritization / scheduling of the accumulated events.
> >
> > In the continuous time model events are processed as they occur. This
> > may result in so called supersteps, which are multiple
> > state-transitions within a single time instant.
>
> OK, I have seen often that people refer to this scheme as "discrete
> event" (iso continuous time)
True, there seems to be a lot of different terms in use. Often
asynchronous and synchronous are used, unfortunately sometimes with
the opposite meaning: asynchronous event occurrence vs. synchronous
event processing.
> > The advantage of this time model is the lower latency (ideally zero)
> > involved in the reaction to events, though at the price of less
> > deterministic behavior.
> >
> > So from a practical point of view model 1) seems suitable for
> > classical state machine applications, whereas 2) appears more
> > appropriate for reactions to rare but critical conditions.
> >
> > Therefore a third, hybrid variant could be imaginable: combine both
> > discrete and continuous time models by defining sets of events which
> > are to be treated either according to one or the other model. For
> > example this would allow the logic of the automaton to be modeled with
> > the more deterministic model 1) and real-time critical events be
> > handled at the lowest possible latency using model 2).
> >
> > Has anybody ever missed the lack of the continuous time model in
> > OROCOS state machines? Any comments?
>
> It is available if you connect your TaskContext to a
> NonPeriodicActivity (unless I misunderstood you).
Yes, you are right concerning the processing of Orocos Events. But
other types of events (e.g. ChangeEvents) will not be generated at all
(unless we are in automatic mode, which does not exist in UML).
Based on Herman's thoughts I'm starting to think that these two models
are too abstract, and it really boils down to two issues:
1) when / how often is _internal_ evaluation performed:
* checking of ChangeEvent conditions and their generation
* checking expired timers and generation of ChangeEvent
* ...
2) when / how often does the state machine advance (invoke its step()
function)
Whatever configuration is chosen, errors will be made. For example
there will always be a certain latency between the arrival/generation
of an event and the time that a transition is triggered by this
event. Dependent on the application this error might or might not be
acceptable, but it needs to be visible. So besides functional
properties, a state machine will have a set of parameters that affect
its non-functional properties, and a set of outputs that can be used to
characterize the quality at which the state machine is performing.
Would you agree?
Best regards
Markus
[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.20.5519
Time models for state machine progression
On Monday 29 September 2008 10:51:14 Markus Klotzbücher wrote:
[...]
>
> Yes, you are right concerning the processing of Orocos Events. But
> other types of events (e.g. ChangeEvents) will not be generated at all
> (unless we are in automatic mode, which does not exist in UML).
>
> Based on Herman's thoughts I'm starting to think that these two models
> are too abstract, and it really boils down to two issues:
>
> 1) when / how often is _internal_ evaluation performed:
>
> * checking of ChangeEvent conditions and their generation
> * checking expired timers and generation of ChangeEvent
> * ...
>
> 2) when / how often does the state machine advance (invoke its step()
> function)
>
> Whatever configuration is chosen, errors will be made. For example
> there will always be a certain latency between the arrival/generation
> of an event and the time that a transition is triggered by this
> event. Dependent on the application this error might or might not be
> acceptable, but it needs to be visible. So besides functional
> properties, a state machine will have a set of parameters that affect
> its non-functional properties, and a set of outputs that can be used to
> characterize the quality at which the state machine is performing.
>
> Would you agree?
Look, first of all, I almost feel like I have no right of telling, having
implemented the complex 'situation' we have today. Nevertheless, please learn
from my mistakes. Before commenting on your 2 points above, this is how I
view the ideal 'N-threaded' (with N: 0->...) protocol of state machines.
Event processing
1. Each event gets delivered into a thread-safe wait queue of the state
machine
2. This 'trigger()'s the activity of the associated task context
3. If that task context is of the 'Sequential' type, the event is processed in
the callers thread and this trigger() function will cause that
3.a A task context-local lock is acquired (the 'execution lock') with
a 'trylock'. If that lock fails, return and leave event processing to the
thread holding the lock right now.
3.b In case we got the lock: The event is fetched from the queue and processed
by the SM, the guard is checked and one or more transitions are made. All
events in the queue are processed in this way.
3.c The lock is released, return.
4. If that task context is of the 'Active' type, the event is processed in the
receiving taskcontext's thread and the trigger() function will only serve to
notify that thread to wake up. That thread will then execute steps 3a, 3b,
and 3c. It doesn't really matter if this thread is periodic or not.
Implementation notes
The implementation will need to handle concurrent event delivery, preferably
non blocking, and race condition-free. I worked this out once on a piece of
paper. It can work quite efficiently.
Also, I would drop the current restriction that only one state can be visited
in an execution step(). We can set a 'safe' maximum of 'recursive' calls and
let that parameter be tunable by the application.
The 'execution lock' is our guard for serialising access to the 'thread-safe'
functions of a task context (TC). It allows a Sequential TC to be safely
called by multiple threads. I've seen this in other frameworks as well. It
works, but you might require a recursive mutex to handle calling back (which
may be hard, if not impossible, to detect in distributed systems...).
For 'Active' TC's, it also prevents other threads accessing critical parts
when its thread is executing.
Conditions
We don't have a change event and I doubt if we can find an efficient
implementation. Also, I'd really like to see another project have something
like this and then copy it (all good ideas are copied :-). We clearly have
two options: 1. evaluate periodically (polling) or 2. tie an event to each
condition. (2.) is already covered by the section above. The polling goes
along the line we have now but currently only works reliably with a periodic
activity. I'm a bit afraid of the overhead/complexity we would create when
there would be an independent option to control how fast a variable was
polled. If it's that critical, an event should be (manually) associated to
have 'immediate' response. As I said, I'd rather copy a working solution :-)
Run/step executions ?
The current run {} program would then become synonymous to a 'true'-condition
transition to self. This maps it 1:1 on UML state machines. It will be
evaluated as a condition pointed out above.
Somewhere along the way, I think I answered your questions... :-)
Peter
Time models for state machine progression
Hi Peter,
On Tue, Sep 30, 2008 at 03:31:43PM +0200, Peter Soetens wrote:
> Look, first of all, I almost feel like I have no right of telling, having
> implemented the complex 'situation' we have today. Nevertheless, please learn
Well, exactly for this reason you comments are so valuable.
> from my mistakes. Before commenting on your 2 points above, this is how I
> view the ideal 'N-threaded' (with N: 0->...) protocol of state machines.
>
> Event processing
> 1. Each event gets delivered into a thread-safe wait queue of the state
> machine
> 2. This 'trigger()'s the activity of the associated task context
> 3. If that task context is of the 'Sequential' type, the event is processed in
> the callers thread and this trigger() function will cause that
> 3.a A task context-local lock is acquired (the 'execution lock') with
> a 'trylock'. If that lock fails, return and leave event processing to the
> thread holding the lock right now.
> 3.b In case we got the lock: The event is fetched from the queue and processed
> by the SM, the guard is checked and one or more transitions are made. All
> events in the queue are processed in this way.
> 3.c The lock is released, return.
> 4. If that task context is of the 'Active' type, the event is processed in the
> receiving taskcontext's thread and the trigger() function will only serve to
> notify that thread to wake up. That thread will then execute steps 3a, 3b,
> and 3c. It doesn't really matter if this thread is periodic or not.
Ok, it's trickier than I thought...
> Implementation notes
> The implementation will need to handle concurrent event delivery, preferably
> non blocking, and race condition-free. I worked this out once on a piece of
> paper. It can work quite efficiently.
>
> Also, I would drop the current restriction that only one state can be visited
> in an execution step(). We can set a 'safe' maximum of 'recursive' calls and
> let that parameter be tunable by the application.
Ok - I'm somewhat in doubt if such a parameter will be useful and
meaningful for a state machine user, but having it shouldn't be much
effort.
> The 'execution lock' is our guard for serialising access to the 'thread-safe'
> functions of a task context (TC). It allows a Sequential TC to be safely
> called by multiple threads. I've seen this in other frameworks as well. It
> works, but you might require a recursive mutex to handle calling back (which
> may be hard, if not impossible, to detect in distributed systems...).
> For 'Active' TC's, it also prevents other threads accessing critical parts
> when its thread is executing.
>
> Conditions
> We don't have a change event and I doubt if we can find an efficient
> implementation. Also, I'd really like to see another project have something
> like this and then copy it (all good ideas are copied :-). We clearly have
Hmm, are you looking in any particular direction? :-)
> two options: 1. evaluate periodically (polling) or 2. tie an event to each
> condition. (2.) is already covered by the section above. The polling goes
Do I understand correctly: 1. means polling from inside the state
machine and 2. means probably polling too (but outside of the state
machine) and generation of an event when the condition becomes true?
> along the line we have now but currently only works reliably with a periodic
> activity. I'm a bit afraid of the overhead/complexity we would create when
> there would be an independent option to control how fast a variable was
> polled. If it's that critical, an event should be (manually) associated to
> have 'immediate' response. As I said, I'd rather copy a working solution :-)
I agree that polling from inside of the state machine is not a good
idea. The way conditions need to be evaluated will be just to
different. I think 2. would be more in line with UML and probably
simpler too.
> Run/step executions ?
> The current run {} program would then become synonymous to a 'true'-condition
> transition to self. This maps it 1:1 on UML state machines. It will be
> evaluated as a condition pointed out above.
>
> Somewhere along the way, I think I answered your questions... :-)
Yes, thank you! Implementationwise it's not very clear to me yet, but
a lot of issues will become obvious when I start writing some code.
At the moment I'm in the process of gathering all feedback and trying
to come up with a concrete first proposal for a new interface.
Best regards
Markus
Time models for state machine progression
On Thursday 02 October 2008 12:44:04 Markus Klotzbücher wrote:
>
> > Implementation notes
> > The implementation will need to handle concurrent event delivery,
> > preferably non blocking, and race condition-free. I worked this out once
> > on a piece of paper. It can work quite efficiently.
> >
> > Also, I would drop the current restriction that only one state can be
> > visited in an execution step(). We can set a 'safe' maximum of
> > 'recursive' calls and let that parameter be tunable by the application.
>
> Ok - I'm somewhat in doubt if such a parameter will be useful and
> meaningful for a state machine user, but having it shouldn't be much
> effort.
It's working like an 'infinite loop' detector. The OS could do so as well, but
will have to suspend/kill the thread, which is a more drastic approach from
which it is hard to recover.
> > two options: 1. evaluate periodically (polling) or 2. tie an event to
> > each condition. (2.) is already covered by the section above. The polling
> > goes
>
> Do I understand correctly: 1. means polling from inside the state
> machine and 2. means probably polling too (but outside of the state
> machine) and generation of an event when the condition becomes true?
yes, as Herman said, synchronous vs asynchronous checking... I didn't say they
were exclusive options, today we have (1) and (2).
>
> > along the line we have now but currently only works reliably with a
> > periodic activity. I'm a bit afraid of the overhead/complexity we would
> > create when there would be an independent option to control how fast a
> > variable was polled. If it's that critical, an event should be (manually)
> > associated to have 'immediate' response. As I said, I'd rather copy a
> > working solution :-)
>
> I agree that polling from inside of the state machine is not a good
> idea. The way conditions need to be evaluated will be just to
> different. I think 2. would be more in line with UML and probably
> simpler too.
2. is simpler than 1., but the implementation will need to evaluate guards
anyway (in all ways the UML spec envisions), so you can't drop polling
literally.
Peter
>
> > Run/step executions ?
> > The current run {} program would then become synonymous to a
> > 'true'-condition transition to self. This maps it 1:1 on UML state
> > machines. It will be evaluated as a condition pointed out above.
> >
> > Somewhere along the way, I think I answered your questions... :-)
>
> Yes, thank you! Implementationwise it's not very clear to me yet, but
> a lot of issues will become obvious when I start writing some code.
>
> At the moment I'm in the process of gathering all feedback and trying
> to come up with a concrete first proposal for a new interface.
>
> Best regards
> Markus
Time models for state machine progression
On Thu, 2 Oct 2008, MarkusKlotzbücher wrote:
[...]
>> Implementation notes
>> The implementation will need to handle concurrent event delivery, preferably
>> non blocking, and race condition-free. I worked this out once on a piece of
>> paper. It can work quite efficiently.
>>
>> Also, I would drop the current restriction that only one state can be visited
>> in an execution step(). We can set a 'safe' maximum of 'recursive' calls and
>> let that parameter be tunable by the application.
>
> Ok - I'm somewhat in doubt if such a parameter will be useful and
> meaningful for a state machine user, but having it shouldn't be much
> effort.
This smells like featuritis! "I am not sure why exactly this feature is
needed, and how it should be used, but, hey, I can do it, so let's do it!"
:-)
Let me suggest this design rule: a candidate feature should not be added,
unless we have very clear use cases and/or policies for it.
>> The 'execution lock' is our guard for serialising access to the 'thread-safe'
>> functions of a task context (TC). It allows a Sequential TC to be safely
>> called by multiple threads. I've seen this in other frameworks as well. It
>> works, but you might require a recursive mutex to handle calling back (which
>> may be hard, if not impossible, to detect in distributed systems...).
>> For 'Active' TC's, it also prevents other threads accessing critical parts
>> when its thread is executing.
>>
>> Conditions
>> We don't have a change event and I doubt if we can find an efficient
>> implementation. Also, I'd really like to see another project have something
>> like this and then copy it (all good ideas are copied :-). We clearly have
>
> Hmm, are you looking in any particular direction? :-)
The OpenSAF middleware _might_ be such a direction. It is middleware
created for high availability in telecommunication systems, but at the
lowest levels they deal with the same things: events, IPC, robustness,
clear semantics, ...
Considering the professional efforts behind this software, I think it is a
much more serious source of inspiration and "best practices" than the
robotics middleware projects.
>> two options: 1. evaluate periodically (polling) or 2. tie an event to each
>> condition. (2.) is already covered by the section above. The polling goes
>
> Do I understand correctly: 1. means polling from inside the state
> machine and 2. means probably polling too (but outside of the state
> machine) and generation of an event when the condition becomes true?
Is "inside" vs "outside" important"? Or is "synchronous" vs "asynchronous"
the real issue? Anyway, I think the current UML statecharts are focused on
synchronous activities, in a completely known context, isn't it? While
these are exactly two constraints we do not want to have in Orocos. Or
rather: that we want to handle separately: the core _must_ be a
synchronous, "object-level" FSM implementation within one single context;
and that core must be extended with an asynchronous, "component-level" FSM
functionality, where one is _sure_ that things will not be done atomically
and reliably, so where robustness is the major issue.
Would that be a good working hypothesis for now: to try to identify the
synchronous issues and the asynchronous issues, and to handle them
differently?
>> Run/step executions ?
>> The current run {} program would then become synonymous to a 'true'-condition
>> transition to self. This maps it 1:1 on UML state machines. It will be
>> evaluated as a condition pointed out above.
>>
>> Somewhere along the way, I think I answered your questions... :-)
>
> Yes, thank you! Implementationwise it's not very clear to me yet, but
> a lot of issues will become obvious when I start writing some code.
Maybe I am too theoretical, but I would prefer some more thinking before
starting to write code. Peter already did that, so new code should only be
written because we know _exactly_ why and where Peter got it "wrong"...
> At the moment I'm in the process of gathering all feedback and trying
> to come up with a concrete first proposal for a new interface.
Good! I think that this interface will be binary: an object-level one (all
state knowledge is centrally available) and a component-level one (one can
never be sure about how events will be handled exactly).
I have the feeling this effort is going somewhere :-)
Herman
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Time models for state machine progression
On Thu, Oct 02, 2008 at 12:57:22PM +0200, Herman Bruyninckx wrote:
> On Thu, 2 Oct 2008, MarkusKlotzbücher wrote:
>> Ok - I'm somewhat in doubt if such a parameter will be useful and
>> meaningful for a state machine user, but having it shouldn't be much
>> effort.
>
> This smells like featuritis! "I am not sure why exactly this feature is
> needed, and how it should be used, but, hey, I can do it, so let's do it!"
> :-)
I was expecting this :-) Well, I do fail to see real benefit for
allowing "supersteps", but it seems to be (or was) a "central topic of
[...] heated deliberations" [1], so even if we do not make it
configurable it should be taken into account that it might become
necessary later...
> Let me suggest this design rule: a candidate feature should not be added,
> unless we have very clear use cases and/or policies for it.
Agreed!
...
>>> Conditions
>>> We don't have a change event and I doubt if we can find an efficient
>>> implementation. Also, I'd really like to see another project have something
>>> like this and then copy it (all good ideas are copied :-). We clearly have
>>
>> Hmm, are you looking in any particular direction? :-)
>
> The OpenSAF middleware _might_ be such a direction. It is middleware
> created for high availability in telecommunication systems, but at the
> lowest levels they deal with the same things: events, IPC, robustness,
> clear semantics, ...
>
> Considering the professional efforts behind this software, I think it is a
> much more serious source of inspiration and "best practices" than the
> robotics middleware projects.
Ok. Maybe I should visit those developers days.
>>> two options: 1. evaluate periodically (polling) or 2. tie an event to each
>>> condition. (2.) is already covered by the section above. The polling goes
>>
>> Do I understand correctly: 1. means polling from inside the state
>> machine and 2. means probably polling too (but outside of the state
>> machine) and generation of an event when the condition becomes true?
> Is "inside" vs "outside" important"? Or is "synchronous" vs "asynchronous"
> the real issue? Anyway, I think the current UML statecharts are focused on
> synchronous activities, in a completely known context, isn't it? While
Yes, it simply leaves open anything dealing with "asynchronous"
aspects.
> these are exactly two constraints we do not want to have in Orocos. Or
> rather: that we want to handle separately: the core _must_ be a
> synchronous, "object-level" FSM implementation within one single context;
> and that core must be extended with an asynchronous, "component-level" FSM
> functionality, where one is _sure_ that things will not be done atomically
> and reliably, so where robustness is the major issue.
I think this is what I (clumsily) tried to describe with inside and
outside with respect to the ChangeConditions: it can't really be done
efficiently in the synchronous core, so it would be better placed
(one layer further) outside.
> Would that be a good working hypothesis for now: to try to identify the
> synchronous issues and the asynchronous issues, and to handle them
> differently?
Yes, sounds fine.
>> Yes, thank you! Implementationwise it's not very clear to me yet, but
>> a lot of issues will become obvious when I start writing some code.
>
> Maybe I am too theoretical, but I would prefer some more thinking before
> starting to write code. Peter already did that, so new code should only be
> written because we know _exactly_ why and where Peter got it "wrong"...
I think you are right generally, but OTOH without a thorough
understanding of the implications of the OROCOS internals I feel a bit
like fantasizing. But you're right - it's too early for (hard) coding
this.
That said, I would really love to prototype this somehow. This is
off-topic now, but was it ever considered to add something more
powerful than OROCOS scripts to the component interface, such as
embedding an existing language? That way applications (and similar
state machines) could be prototyped in the scripting language itself,
then later made real-time and fast.
>> At the moment I'm in the process of gathering all feedback and trying
>> to come up with a concrete first proposal for a new interface.
> Good! I think that this interface will be binary: an object-level one (all
> state knowledge is centrally available) and a component-level one (one can
> never be sure about how events will be handled exactly).
>
> I have the feeling this effort is going somewhere :-)
I do hope so :-)
Best regards
Markus
[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.20.5519
Time models for state machine progression
On Thu, 2 Oct 2008, MarkusKlotzbücher wrote:
>>>> Conditions
>>>> We don't have a change event and I doubt if we can find an efficient
>>>> implementation. Also, I'd really like to see another project have something
>>>> like this and then copy it (all good ideas are copied :-). We clearly have
>>>
>>> Hmm, are you looking in any particular direction? :-)
>>
>> The OpenSAF middleware _might_ be such a direction. It is middleware
>> created for high availability in telecommunication systems, but at the
>> lowest levels they deal with the same things: events, IPC, robustness,
>> clear semantics, ...
>>
>> Considering the professional efforts behind this software, I think it is a
>> much more serious source of inspiration and "best practices" than the
>> robotics middleware projects.
>
> Ok. Maybe I should visit those developers days.
Indeed... talking to the developers will let your learn faster about where
this project wants to go, what its focus points are, and whether our
robotics/machine tool use cases make any sense to them.
[...]
> That said, I would really love to prototype this somehow. This is
> off-topic now, but was it ever considered to add something more
> powerful than OROCOS scripts to the component interface, such as
> embedding an existing language? That way applications (and similar
> state machines) could be prototyped in the scripting language itself,
> then later made real-time and fast.
Yes, we thought long about using existing languages such as Python instead
of inventing our own scripting language. The reason for choosing the latter
was that it was the only way to be able to guarantee real-time safeness in
one way or another. As soon as you say "we support Python", people expect
to be able to use any Python library and feature out there...
Herman
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Time models for state machine progression
On Thu, Oct 02, 2008 at 04:50:02PM +0200, Herman Bruyninckx wrote:
> On Thu, 2 Oct 2008, MarkusKlotzbücher wrote:
...
>>>> Hmm, are you looking in any particular direction? :-)
>>>
>>> The OpenSAF middleware _might_ be such a direction. It is middleware
>>> created for high availability in telecommunication systems, but at the
>>> lowest levels they deal with the same things: events, IPC, robustness,
>>> clear semantics, ...
>>>
>>> Considering the professional efforts behind this software, I think it is a
>>> much more serious source of inspiration and "best practices" than the
>>> robotics middleware projects.
>>
>> Ok. Maybe I should visit those developers days.
> Indeed... talking to the developers will let your learn faster about where
> this project wants to go, what its focus points are, and whether our
> robotics/machine tool use cases make any sense to them.
I'll be there!
> [...]
>> That said, I would really love to prototype this somehow. This is
>> off-topic now, but was it ever considered to add something more
>> powerful than OROCOS scripts to the component interface, such as
>> embedding an existing language? That way applications (and similar
>> state machines) could be prototyped in the scripting language itself,
>> then later made real-time and fast.
> Yes, we thought long about using existing languages such as Python instead
> of inventing our own scripting language. The reason for choosing the latter
> was that it was the only way to be able to guarantee real-time safeness in
> one way or another. As soon as you say "we support Python", people expect
> to be able to use any Python library and feature out there...
Well, but the same is true for many C++ libraries, isn't it? Don't get
me wrong, I do think the real-time scripts have their rights. But an
optional, powerful scripting language which is explicitly declared as
non-real time seems like low hanging fruit in terms of improving
usability.
Just my 2 Cents :-)
Regards
Markus
Time models for state machine progression
On Thu, 2 Oct 2008, MarkusKlotzbücher wrote:
[...]
>>> That said, I would really love to prototype this somehow. This is
>>> off-topic now, but was it ever considered to add something more
>>> powerful than OROCOS scripts to the component interface, such as
>>> embedding an existing language? That way applications (and similar
>>> state machines) could be prototyped in the scripting language itself,
>>> then later made real-time and fast.
>> Yes, we thought long about using existing languages such as Python instead
>> of inventing our own scripting language. The reason for choosing the latter
>> was that it was the only way to be able to guarantee real-time safeness in
>> one way or another. As soon as you say "we support Python", people expect
>> to be able to use any Python library and feature out there...
>
> Well, but the same is true for many C++ libraries, isn't it? Don't get
> me wrong, I do think the real-time scripts have their rights. But an
> optional, powerful scripting language which is explicitly declared as
> non-real time seems like low hanging fruit in terms of improving
> usability.
>
> Just my 2 Cents :-)
It were Peter and mine two cents also, years ago :-) And Peter implemented
support for any kind of "new" language, indeed at the non-realtime level.
Up to now, nobody has made use of this feature...
Herman
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Time models for state machine progression
On Thu, Oct 02, 2008 at 10:00:53PM +0200, Herman Bruyninckx wrote:
> On Thu, 2 Oct 2008, MarkusKlotzbücher wrote:
>
> [...]
>>>> That said, I would really love to prototype this somehow. This is
>>>> off-topic now, but was it ever considered to add something more
>>>> powerful than OROCOS scripts to the component interface, such as
>>>> embedding an existing language? That way applications (and similar
>>>> state machines) could be prototyped in the scripting language itself,
>>>> then later made real-time and fast.
>>> Yes, we thought long about using existing languages such as Python instead
>>> of inventing our own scripting language. The reason for choosing the latter
>>> was that it was the only way to be able to guarantee real-time safeness in
>>> one way or another. As soon as you say "we support Python", people expect
>>> to be able to use any Python library and feature out there...
>>
>> Well, but the same is true for many C++ libraries, isn't it? Don't get
>> me wrong, I do think the real-time scripts have their rights. But an
>> optional, powerful scripting language which is explicitly declared as
>> non-real time seems like low hanging fruit in terms of improving
>> usability.
>>
>> Just my 2 Cents :-)
>
> It were Peter and mine two cents also, years ago :-) And Peter implemented
> support for any kind of "new" language, indeed at the non-realtime level.
> Up to now, nobody has made use of this feature...
Interesting! Are you saying the interfaces are there, but nobody
hooked up anything yet?
Regards
Markus
Time models for state machine progression
On Mon, 29 Sep 2008, MarkusKlotzbücher wrote:
[...]
>>> The advantages of this model are that the execution of the state
>>> machine is more deterministic (no supersteps, see below, possible) and
>>> it allows prioritization / scheduling of the accumulated events.
>>>
>>> In the continuous time model events are processed as they occur. This
>>> may result in so called supersteps, which are multiple
>>> state-transitions within a single time instant.
>>
>> OK, I have seen often that people refer to this scheme as "discrete
>> event" (iso continuous time)
>
> True, there seems to be a lot of different terms in use. Often
> asynchronous and synchronous are used, unfortunately sometimes with
> the opposite meaning: asynchronous event occurrence vs. synchronous
> event processing.
So, adding a "glossary" to your documentation page could be very useful!
:-) Orocos has a need for such a thing since a long time already. And
providing information about possible different meanings for the same term
used in different contexts/standards/projects/... is also worthwhile.
[...]
> Based on Herman's thoughts I'm starting to think that these two models
> are too abstract, and it really boils down to two issues:
>
> 1) when / how often is _internal_ evaluation performed:
>
> * checking of ChangeEvent conditions and their generation
> * checking expired timers and generation of ChangeEvent
> * ...
>
> 2) when / how often does the state machine advance (invoke its step()
> function)
>
> Whatever configuration is chosen, errors will be made. For example
> there will always be a certain latency between the arrival/generation
> of an event and the time that a transition is triggered by this
> event. Dependent on the application this error might or might not be
> acceptable, but it needs to be visible. So besides functional
> properties, a state machine will have a set of parameters that affect
> its non-functional properties, and a set of outputs that can be used to
> characterize the quality at which the state machine is performing.
>
> Would you agree?
I agree with any description that separates "mechanism" (= FSM semantics)
from "policy" (e.g., how does an _implementation_ deal with time? how is it
robust against the fact that multiple conditions cannot be checked
atomically all the time? etc.) In addition, the same policy can have a
varying "Quality of Service" (QoS), depending on the situation.
I also think that the "Models of Computation" (MoC) (for which Klaas has
built up some non-trivial knowledge in the meantime) would bring in a lot
of clarity in the picture. There _must_ be a relationship between QoS and
MoC and dealing with time and atomicity...
Herman
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Time models for state machine progression
On Saturday 27 September 2008 00:26:30 Klaas Gadeyne wrote:
> On Fri, Sep 26, 2008 at 9:38 AM, Markus Klotzbücher
> <markus [dot] klotzbuecher [..] ...> wrote:
> Hi Markus,
>
> [it's paste twelve, so forgive any nonsense below :-)]
Hi Markus,
I agree with all Klaas' remarks below, they're right on the spot.
Peter
>
> > It is largely unspecified in UML2 when state transitions are
> > evaluated, the only restriction being that a run-to-completion step
> > (which represents the actions performed during transition (exit, do,
> > init)) may not be interrupted.
>
> AFAIK orocos does nothing to avoid preemption during such a
> run-to-completion step. Is that something in which the RTT deviates
> from the UML specificiation?
>
> > The remaining semantic variation is commonly captured in two models:
> > 1) discrete time model
> > 2) continuous time model
>
> Are these two models mentioned in the spec too, or is that information
> you gathered somewhere else?
>
> > In the discrete time model a state machine is advanced after fixed
> > time units. At each step events are processed which accumulated since
> > the previous step. OROCOS state machines work according to this model.
>
> They do if their owner-Taskcontext is connected to a periodicActivity.
>
> > The advantages of this model are that the execution of the state
> > machine is more deterministic (no supersteps, see below, possible) and
> > it allows prioritization / scheduling of the accumulated events.
> >
> > In the continuous time model events are processed as they occur. This
> > may result in so called supersteps, which are multiple
> > state-transitions within a single time instant.
>
> OK, I have seen often that people refer to this scheme as "discrete
> event" (iso continuous time)
>
> > The advantage of this time model is the lower latency (ideally zero)
> > involved in the reaction to events, though at the price of less
> > deterministic behavior.
> >
> > So from a practical point of view model 1) seems suitable for
> > classical state machine applications, whereas 2) appears more
> > appropriate for reactions to rare but critical conditions.
> >
> > Therefore a third, hybrid variant could be imaginable: combine both
> > discrete and continuous time models by defining sets of events which
> > are to be treated either according to one or the other model. For
> > example this would allow the logic of the automaton to be modeled with
> > the more deterministic model 1) and real-time critical events be
> > handled at the lowest possible latency using model 2).
> >
> > Has anybody ever missed the lack of the continuous time model in
> > OROCOS state machines? Any comments?
>
> It is available if you connect your TaskContext to a
> NonPeriodicActivity (unless I misunderstood you).
>
> Best regards,
>
> Klaas
Time models for state machine progression
On Fri, 26 Sep 2008, MarkusKlotzbücher wrote:
> It is largely unspecified in UML2 when state transitions are
> evaluated, the only restriction being that a run-to-completion step
> (which represents the actions performed during transition (exit, do,
> init)) may not be interrupted. The remaining semantic variation is
> commonly captured in two models:
>
> 1) discrete time model
> 2) continuous time model
>
> In the discrete time model a state machine is advanced after fixed
> time units. At each step events are processed which accumulated since
> the previous step. OROCOS state machines work according to this model.
>
> The advantages of this model are that the execution of the state
> machine is more deterministic (no supersteps, see below, possible) and
> it allows prioritization / scheduling of the accumulated events.
Are you sure that this model completely prevents "supersteps"? Because the
handling of one event can cause transitions to other states, and these
states could have auto-transitions to yet other states...
And it's not only the _number_ of states visited in one "processing" that
is important, but also _how long_ the processing takes.
> In the continuous time model events are processed as they occur. This
> may result in so called supersteps, which are multiple
> state-transitions within a single time instant.
>
> The advantage of this time model is the lower latency (ideally zero)
> involved in the reaction to events, though at the price of less
> deterministic behavior.
>
> So from a practical point of view model 1) seems suitable for
> classical state machine applications, whereas 2) appears more
> appropriate for reactions to rare but critical conditions.
This conclusion is maybe a bit premature. For example, it could be perfectly
ok to handle a critical situation in a discrete time architecture, if the
reaction time is sufficient for the dynamics required by the critical
condition handling.
> Therefore a third, hybrid variant could be imaginable: combine both
> discrete and continuous time models by defining sets of events which
> are to be treated either according to one or the other model. For
> example this would allow the logic of the automaton to be modeled with
> the more deterministic model 1) and real-time critical events be
> handled at the lowest possible latency using model 2).
>
> Has anybody ever missed the lack of the continuous time model in
> OROCOS state machines? Any comments?
All mechatronic systems that I know have dynamics that are slower than what
can be serviced by activities with typical sample frequencies of 1KHz. The
"model 2" events are often hidden behind the HAL interfaces, e.g., the
interrupts one gets from fieldbus drivers.
Herman
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Time models for state machine progression
On Fri, Sep 26, 2008 at 10:01:06AM +0200, Herman Bruyninckx wrote:
> On Fri, 26 Sep 2008, MarkusKlotzbücher wrote:
>
>> It is largely unspecified in UML2 when state transitions are
>> evaluated, the only restriction being that a run-to-completion step
>> (which represents the actions performed during transition (exit, do,
>> init)) may not be interrupted. The remaining semantic variation is
>> commonly captured in two models:
>>
>> 1) discrete time model
>> 2) continuous time model
>>
>> In the discrete time model a state machine is advanced after fixed
>> time units. At each step events are processed which accumulated since
>> the previous step. OROCOS state machines work according to this model.
>>
>> The advantages of this model are that the execution of the state
>> machine is more deterministic (no supersteps, see below, possible) and
>> it allows prioritization / scheduling of the accumulated events.
> Are you sure that this model completely prevents "supersteps"? Because the
Yes..
> handling of one event can cause transitions to other states, and these
> states could have auto-transitions to yet other states...
What are auto-transitions? I believe supersteps are not possible,
because only one event will be processed at a time and only at fixed
points in time provided that the run-to-completion step has been
processed.
For example after a run-to-completion step has finished, a state
machine will start executing the "do" (or run) behaviour of the active
state, which upon completion will generate a CompletionEvent which in
turn may trigger some transition. Assuming this behaviour finishes
instantly this event might be generated before we "trigger" the next
run-to-completion step, so the state machine would simply pause until
this happens.
> And it's not only the _number_ of states visited in one "processing" that
> is important, but also _how long_ the processing takes.
Yes, agreed, but this duration will be mainly imposed by the
application logic / underlying system. And UML provides primitives
like TimeEvents for modeling timeouts that allow us to control the
time spent in certain states.
>> In the continuous time model events are processed as they occur. This
>> may result in so called supersteps, which are multiple
>> state-transitions within a single time instant.
>>
>> The advantage of this time model is the lower latency (ideally zero)
>> involved in the reaction to events, though at the price of less
>> deterministic behavior.
>>
>> So from a practical point of view model 1) seems suitable for
>> classical state machine applications, whereas 2) appears more
>> appropriate for reactions to rare but critical conditions.
> This conclusion is maybe a bit premature. For example, it could be perfectly
> ok to handle a critical situation in a discrete time architecture, if the
> reaction time is sufficient for the dynamics required by the critical
> condition handling.
Yes agreed, it was meant to be slightly provocative statement :-)
>> Therefore a third, hybrid variant could be imaginable: combine both
>> discrete and continuous time models by defining sets of events which
>> are to be treated either according to one or the other model. For
>> example this would allow the logic of the automaton to be modeled with
>> the more deterministic model 1) and real-time critical events be
>> handled at the lowest possible latency using model 2).
>>
>> Has anybody ever missed the lack of the continuous time model in
>> OROCOS state machines? Any comments?
>
> All mechatronic systems that I know have dynamics that are slower than what
> can be serviced by activities with typical sample frequencies of 1KHz. The
> "model 2" events are often hidden behind the HAL interfaces, e.g., the
> interrupts one gets from fieldbus drivers.
Ok, thank you. This is an important statement. So from a practical
point of view it seems safe to focus on the "discrete time model" in
order to fill this semantic variation gap.
Best regards
Markus
Time models for state machine progression
On Fri, 26 Sep 2008, MarkusKlotzbücher wrote:
> On Fri, Sep 26, 2008 at 10:01:06AM +0200, Herman Bruyninckx wrote:
>> On Fri, 26 Sep 2008, MarkusKlotzbücher wrote:
>>
>>> It is largely unspecified in UML2 when state transitions are
>>> evaluated, the only restriction being that a run-to-completion step
>>> (which represents the actions performed during transition (exit, do,
>>> init)) may not be interrupted. The remaining semantic variation is
>>> commonly captured in two models:
>>>
>>> 1) discrete time model
>>> 2) continuous time model
>>>
>>> In the discrete time model a state machine is advanced after fixed
>>> time units. At each step events are processed which accumulated since
>>> the previous step. OROCOS state machines work according to this model.
>>>
>>> The advantages of this model are that the execution of the state
>>> machine is more deterministic (no supersteps, see below, possible) and
>>> it allows prioritization / scheduling of the accumulated events.
>> Are you sure that this model completely prevents "supersteps"? Because the
>
> Yes..
>
>> handling of one event can cause transitions to other states, and these
>> states could have auto-transitions to yet other states...
>
> What are auto-transitions?
The state machine can decide to switch states because something happened
internally in a state, without inputs from somewhere else. For example, a
time out, or a transition because the activity running in the state reached
an error, ...
> I believe supersteps are not possible,
> because only one event will be processed at a time and only at fixed
> points in time provided that the run-to-completion step has been
> processed.
The processing of one event could give rise to another event...
> For example after a run-to-completion step has finished, a state
> machine will start executing the "do" (or run) behaviour of the active
> state, which upon completion will generate a CompletionEvent which in
> turn may trigger some transition. Assuming this behaviour finishes
..."assuming"... If it's only an assumption (and not a certain fact) it
will be invalidated sooner or later.
> instantly this event might be generated before we "trigger" the next
> run-to-completion step, so the state machine would simply pause until
> this happens.
>
>> And it's not only the _number_ of states visited in one "processing" that
>> is important, but also _how long_ the processing takes.
>
> Yes, agreed, but this duration will be mainly imposed by the
> application logic / underlying system. And UML provides primitives
> like TimeEvents for modeling timeouts that allow us to control the
> time spent in certain states.
_Assuming_ that processing of time does not take any time itself. I think
this is again an assumption that cannot be guaranteed in robot control
systems, since it is sometimes the environment that dictates the timing...
>>> In the continuous time model events are processed as they occur. This
>>> may result in so called supersteps, which are multiple
>>> state-transitions within a single time instant.
>>>
>>> The advantage of this time model is the lower latency (ideally zero)
>>> involved in the reaction to events, though at the price of less
>>> deterministic behavior.
>>>
>>> So from a practical point of view model 1) seems suitable for
>>> classical state machine applications, whereas 2) appears more
>>> appropriate for reactions to rare but critical conditions.
>> This conclusion is maybe a bit premature. For example, it could be perfectly
>> ok to handle a critical situation in a discrete time architecture, if the
>> reaction time is sufficient for the dynamics required by the critical
>> condition handling.
>
> Yes agreed, it was meant to be slightly provocative statement :-)
Good! I like to be provoked! (To some extent :-)
>>> Therefore a third, hybrid variant could be imaginable: combine both
>>> discrete and continuous time models by defining sets of events which
>>> are to be treated either according to one or the other model. For
>>> example this would allow the logic of the automaton to be modeled with
>>> the more deterministic model 1) and real-time critical events be
>>> handled at the lowest possible latency using model 2).
>>>
>>> Has anybody ever missed the lack of the continuous time model in
>>> OROCOS state machines? Any comments?
>>
>> All mechatronic systems that I know have dynamics that are slower than what
>> can be serviced by activities with typical sample frequencies of 1KHz. The
>> "model 2" events are often hidden behind the HAL interfaces, e.g., the
>> interrupts one gets from fieldbus drivers.
>
> Ok, thank you. This is an important statement.
Or rather, an _assumption_, not unlike many of the ones that you have made! :-)
> So from a practical
> point of view it seems safe to focus on the "discrete time model" in
> order to fill this semantic variation gap.
No, we need more, if possible: we need a quantifiable measure that
indicates the loss in "Quality of Service" that comes with being more or
less compliant with the assumption.
I think this "QoS" concept (together with "robustness" against
deteriorating QoS) is one of the essential things that robotics can bring
into the discussion of the UML standard... There is at least one other
domain that has a similar kind of QoS problem: in telecom, the quality of a
communication channel is not constant, and loosing some quality is (most
often) also not a disaster.
Herman
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Time models for state machine progression
On Fri, Sep 26, 2008 at 03:38:28PM +0200, Herman Bruyninckx wrote:
> On Fri, 26 Sep 2008, MarkusKlotzbücher wrote:
>> On Fri, Sep 26, 2008 at 10:01:06AM +0200, Herman Bruyninckx wrote:
...
>>> handling of one event can cause transitions to other states, and these
>>> states could have auto-transitions to yet other states...
>>
>> What are auto-transitions?
> The state machine can decide to switch states because something happened
> internally in a state, without inputs from somewhere else. For example, a
> time out, or a transition because the activity running in the state reached
> an error, ...
I see, you are refering to the OROCOS step() and requestState()
operations? In UML there is nothing such - of course there will be a
step() or trigger() "under the hood", but I don't think a behavior
should not be allowed to call such low level operations (besides maybe
for debugging purposes). But indeed, as you write below, a transition
may itself generate new events...
>> I believe supersteps are not possible,
>> because only one event will be processed at a time and only at fixed
>> points in time provided that the run-to-completion step has been
>> processed.
> The processing of one event could give rise to another event...
... which will end up in the queue to be processed the next time the
"engine" calls step(). So one transition per step()
>> For example after a run-to-completion step has finished, a state
>> machine will start executing the "do" (or run) behaviour of the active
>> state, which upon completion will generate a CompletionEvent which in
>> turn may trigger some transition. Assuming this behaviour finishes
>
> ..."assuming"... If it's only an assumption (and not a certain fact) it
> will be invalidated sooner or later.
True, but it's a worst-case assumption, therefore its invalidation
will result in a superior situation! :-)
>> instantly this event might be generated before we "trigger" the next
>> run-to-completion step, so the state machine would simply pause until
>> this happens.
>>
>>> And it's not only the _number_ of states visited in one "processing" that
>>> is important, but also _how long_ the processing takes.
>>
>> Yes, agreed, but this duration will be mainly imposed by the
>> application logic / underlying system. And UML provides primitives
>> like TimeEvents for modeling timeouts that allow us to control the
>> time spent in certain states.
>
> _Assuming_ that processing of time does not take any time itself. I think
> this is again an assumption that cannot be guaranteed in robot control
> systems, since it is sometimes the environment that dictates the timing...
But the error introduced by time processing will be only one of many
errors made by various assumptions in the system. It might be small
compared to others.
...
>> So from a practical
>> point of view it seems safe to focus on the "discrete time model" in
>> order to fill this semantic variation gap.
>
> No, we need more, if possible: we need a quantifiable measure that
> indicates the loss in "Quality of Service" that comes with being more or
> less compliant with the assumption.
Ok, now I'm beginning to understand where you want to go...
> I think this "QoS" concept (together with "robustness" against
> deteriorating QoS) is one of the essential things that robotics can bring
> into the discussion of the UML standard... There is at least one other
> domain that has a similar kind of QoS problem: in telecom, the quality of a
> communication channel is not constant, and loosing some quality is (most
> often) also not a disaster.
I like this idea. The MARTE profile has more on QoS, and I have to do
more reading before I can comment on what it does and does not
provides. But surely this is not a topic restricted to state machines?
Rather a state machine could provide one or more inputs to the "QoS
algorithm" (or of course react to the "QoS level" it in some way) ?
Best regards
Markus
Time models for state machine progression
Dear List,
It is largely unspecified in UML2 when state transitions are
evaluated, the only restriction being that a run-to-completion step
(which represents the actions performed during transition (exit, do,
init)) may not be interrupted. The remaining semantic variation is
commonly captured in two models:
1) discrete time model
2) continuous time model
In the discrete time model a state machine is advanced after fixed
time units. At each step events are processed which accumulated since
the previous step. OROCOS state machines work according to this model.
The advantages of this model are that the execution of the state
machine is more deterministic (no supersteps, see below, possible) and
it allows prioritization / scheduling of the accumulated events.
In the continuous time model events are processed as they occur. This
may result in so called supersteps, which are multiple
state-transitions within a single time instant.
The advantage of this time model is the lower latency (ideally zero)
involved in the reaction to events, though at the price of less
deterministic behavior.
So from a practical point of view model 1) seems suitable for
classical state machine applications, whereas 2) appears more
appropriate for reactions to rare but critical conditions.
Therefore a third, hybrid variant could be imaginable: combine both
discrete and continuous time models by defining sets of events which
are to be treated either according to one or the other model. For
example this would allow the logic of the automaton to be modeled with
the more deterministic model 1) and real-time critical events be
handled at the lowest possible latency using model 2).
Has anybody ever missed the lack of the continuous time model in
OROCOS state machines? Any comments?
Best regards
Markus