Using Message-Based Communication

This section describes how we emulate message-based communication in Simulink. In particular, we explain the encoding of messages (Section 6.3.3.1) and the behavior of the helper blocks, namely of the link layer (Section 6.3.3.2), the communication switch (Sec- tion 6.3.3.3), and the delegation switch (Section 6.3.3.4). For a detailed description of the internal implementation of the helper blocks, we refer to our technical report [HRB+13] and the thesis of Volk [Vol13].

6.3.3.1 Encoding Messages

Since Simulink does not support asynchronous messages that are exchanged by discrete com- ponent instances in MECHATRONICUML, we need to define an encoding based on signals in Simulink. We encode messages as tuples consisting of six signals: a package ID, a message ID, a parameter value, a sender ID, a receiver ID, and a timestamp [HPR+12]. The message ID is a uniquely identifiable integer that represents a particular message type of the MECHA-

TRONICUML model. We need to use an integer encoding because Simulink does not support

strings. The parameter encodes a single parameter value. The sender ID is the address of the port structure sending the message, while the receiver ID denotes the address of the message receiver. The package ID is an incrementing integer ID that numbers the messages that are exchanged between two port structures. We utilize this field for detecting lost messages as we explain in Section 6.3.4. The timestamp refers to the point in time where the message was sent based on the simulation time. We use this value for simulating message delay and iden- tifying messages that arrive too late. In Simulink, we implement the six-tuple for a message by means of a bus signal with six entries [HRB+14].

In MECHATRONICUML, a message may define more than one parameter. Since our en- coding only considers one parameter for each message in Simulink, messages with more than one parameter need to be split into several messages [HRB+14]. As an example, consider the messageupdatethat is sent by the port instancerefDistProviderofrg1in Figure 3.103. This message is split into two consecutive messages where the first one contains the value for the

distanceparameter and the second message contains the value for thespeedparameter.

6.3.3.2 Link Layer

For each discrete port instance of an atomic component instance in MECHATRONICUML, we obtain a port structure and a link layer subsystem that is connected to the port structure as described in Section 6.3.1.1. The link layer serves as a middleware between the application- layer component behavior contained in the Stateflow chart and the network infrastructure.

3_{refDistProvider}

Upon creation of the platform-specific model for the system, the link layer needs to be re- placed by the middleware for the system that implements the interfaces to the networking hardware.

In the following, we describe the behavior of the link layer based on the generation tem- plate shown in Figure 6.7. If a message arrives viaport_in at the link layer, the link layer reads the message from the bus signal and checks whether it is the intended receiver by comparing the receiver ID in the message with its ownnet_address. Then, the message is stored in the message buffer for incoming messages. The message buffer is implemented by two arrays; one for message IDs and one for parameter values. These arrays are then sent to the Stateflow chart using the signalswrite_event_queue_inandwrite_event_param_queue_in. Then, the Stateflow chart may consume messages from these signals as we explain in Sec- tion 6.4.2. The modified buffer is sent back to the link layer such that the link layer may keep track of the current buffer status. If the Stateflow chart sends a message, it adds the mes- sage to thez_WriteOutandz_ParamWriteOutqueues that are defined analogously to the queues for received messages. Then, the link layer reads these queues and successively sends the messages viaport_out.

The idea and concept for the link layer subsystems and the encoding of messages has been reused from Henke et al. [HTS+08b]. In their approach, each discrete component only used one such link layer subsystem that was shared by all of the port instances. As a result, the Stateflow chart needed to know the address of the receiving port structure. We reimple- mented their concept such that we use one dedicated link layer for each discrete port instance of our MECHATRONICUML model, which corresponds to the semantics of MECHATRON-

ICUML where each discrete port instance has its own message buffer. In addition, we ex-

tended the link layer such that it considers the QoS assumptions of MECHATRONICUML (cf. Section 6.3.4). In our approach, the Stateflow chart is independent of thenet_addressand

receiver_new_addressand, thus, of the concrete network infrastructure.

6.3.3.3 Communication Switch

The communication switch shown in the middle of Figure 6.14 is responsible for routing messages from the sender port structure to the receiver port structure. Thus, its serves as a virtual networking infrastructure [HPR+12]. Upon creation of the platform-specific model of the system, the communication switch is replaced by the networking hardware (or a sim- ulation model of it).

The behavior of the communication switch is as follows: For each message in inBus, it reads the receiver ID and writes the message to the corresponding field inoutbusthat is con- nected to the receiving port structure. The communication switch learns automatically which field inoutbusbelongs to which receiver ID. First, the order of IDs ininBusandoutBusare the same. That means, if a message is contained ininBus, the communication switch learns the ID of the port structure by reading the sender ID of the message. If a communication switch receives a message whose receiver ID is still unknown to it, it forwards the mes- sage to all unknown receivers. Then, the right receiver will answer with an acknowledgment and the communication switch may update its information. This behavior is inspired by the address resolution protocol (ARP, [Plu82]) that is used in Ethernet networks. It enables to use the same communication switch implementation for all subsystems that were created for structured component instances and the (integrated) system CIC.

6.3.3.4 Delegation Switch

The delegation switch shown in Figure 6.15 realizes a delegation connector instance between two discrete port instances by performing a network address translation (NAT, [SH99]). In our approach, the addresses of the ports are only unique within a subsystem that corresponds to a structured component instance, i.e., each structured component defines its own private subnet. This enables that we may change connector instances inside a structured component instance without exposing this change to another component instance thereby retaining com- ponent encapsulation. In particular, a component instance that is connected to a port instance of the structured component instance does not need to know about the change.

Therefore, the inports extern_net_addr andextern_recv_net_addr of the delegation switch receive the addresses that are used by the port structure for communicating with another subsystem outside its boundaries. The inports local_net_addr andlocal_recv_net_addrdefine the addresses for communicating inside the boundaries of the subsystem. If the delegation switch receives a message viaextern_in, this message contains the external addresses of the port structure. Then, the delegation switch replaces these addresses with its local ones, i.e., the sender ID is set tolocal_net_addrwhile the receiver ID is set tolocal_recv_net_addr.

Consider the generation template shown in Figure 6.15 as an example. The port struc- ture forZ2in the embedded subsystemXhas the addressB, while the delegation switch has addressA. Thus, for any message arriving at the delegation switch viaextern_in, the sender ID is set toA while the receiver ID is set toB. Consequently, the port structureZ2has the

recv_net_addr A. Then, the message is sent via local_out to the communication switch that routes the messages to the receiver. Messages that are sent by embedded component in- stances are treated in the same fashion, however, the delegation switch replaces the local addresses with the external ones in this case.