Download INSTITUT F¨UR INFORMATIK CASE Tools for Embedded Systems

3.2. MODELING THE SYSTEM
31
a message until the message is accepted by the receiver. With message
asynchronous communication, the sender of a message is not influenced by the receiver of the message; the receiver will always accept
the message. This is either the case with buffered communication where
the receiver buffers unread message until consumption or with signalbased communication where unread messages are overwritten by new
arriving messages.
Time Synchronization: This form described the synchronization of the
actions of different components. In event-driven systems, behavior is
triggered by the occurrence of events; in time-driven systems, behavior is triggered by the passing of time.2
The applied tools use different combinations of those synchronization aspects:
Artisan: Method-based, event-driven: Artisan uses a method-based communication model. The exact interpretation of the method call (message-asynchronous or message-synchronous) is left open and depends
on the implementation platform. Since objects are activated by communication events, the model operates in an event-based fashion.
ASCET-SD: Signal-based, time-driven ASCET-SD uses a signal-based communication. Time synchronization usually is performed time-driven
with individual rates for the components; additionally, there are some
predefined events like interrupts.
AutoF OCUS: Signal-based, time-synchronized event-driven: AutoF OCUS
uses a signal-based communication. Concerning time-synchronization
it uses a hybrid model. Communication is performed in a synchronized manner: all components communicate in a time-driven roundbased scheme with a global time-rate for all components. Within
each round events for occurrence of a message as well as as the nonoccurrence can be detected.
Matlab/Stateflow: Signal-based, time-driven Matlab/Simulink use a signal-based communication. Time synchronization usually is performed
time-driven with individual rates for the components; additionally,
there are some predefined events like function calls, or value changes
(rising/falling edges).
2
Note that from a formal point of view event-driven systems can be transformed into
time-driven system and vice-versa, either by adding timing events or by adding explicit
absence events; however when considering additional restrictions like idle-load or efficient
simulation, those transformations are not always suitable.