2.3 Execution Models

Since from ROOM models executable code can be generated, it is important to define the way the actors are executed and communicate with each other. The combination of communication and execution is called the Execution Model. Currently the eTrice tooling only supports the message driven and parts of the data driven execution model. In future releases more execution models will be supported, depending on the requirements of the community.

2.3.1 Communication Methods

• message driven (asynchronous, non blocking, no return value): Usually the message driven communication is implemented with message queues. Message queues are inherently asynchronous and enable a very good decoupling of the communicating parties.
• data driven (asynchronous, non blocking, no return value): In data driven communication sender and receiver often have a shared block of data. The sender writes the data and the receiver polls the data.
• function call (synchronous, blocking, return value): Regular function call as known in most programming languages.

2.3.2 Execution Methods

• execution by receive event: The message queue or the event dispatcher calls a receive event function of the message receiver an thereby executes the processing of the event.
• polled execution: The objects are processed by a cyclic execute call
• execution by function call: The caller executes the called object via function call

2.3.3 Execution Models

In todays embedded systems in most cases one or several of the following execution models are used:

message driven

The message driven execution model is a combination of message driven communication and execution by receive event. This model allows for distributed systems with a very high throughput. It can be deterministic but the determinism is hard to proof. This execution model is often found in telecommunication systems and high performance automation control systems.

data driven

The data driven execution model is a combination of data driven communication and polled execution. This model is highly deterministic and very robust, but the polling creates a huge performance overhead. The determinism is easy to proof (simple mathematics). The execution model is also compatible with the execution model of control software generated by Tools like Matlab(TM) and LabView(TM). This model is usually used for systems with requirements for safety, such as automotive and avionic systems.

synchronous

The synchronous execution model could also be called simple function calls. This model is in general not very well suited to support the run to completion semantic typical for ROOM models, but could also be generated from ROOM models. With this execution model also lower levels of a software system, such as device drivers, could be generated from ROOM models.