The sender-receiver communication enables the exchange of data/ information where a sender distributes information to one or several receivers. We can use Sender receiver interface for data exchange, event and mode group exchange.
Figure: Sender Receiver Communication in AUTOSAR- VFB Level.
The sender-receiver interface associated with these ports consists of data-elements that define the data that is sent by the sender and received by the receivers. The type of a data-element can be something very simple (like an “integer”) or can be a complex (potentially large) data type (e.g. an array or a string).
Let’s configure the Sender
Each data-element with “last-is-best”-semantics in a PPort of a sender-component always has a current value. The initial current value of such a data-element should be configured. The sending component can change the current value of the data- element, thereby overwriting the previous value of the data-element.
When we configure the data-element as “queued”, the consecutive values produced by the sender are stored in a queue.We will enable queueing if we need the entire history of the data (event). If only the current data (data) is required we will not enable the queue.
Some of the important attributes that needs to be configured for sender include
INIT_VALUE– This attribute defines the initial value of the data- element, seen by all receivers of this data- element. This initial value can be overwritten by the attribute INIT_VALUE on the receiver side. It is imperative to be configured for exchange of data.
CAN_INVALIDATE– In case this feature is used, the sender can invalidate a data-element. It is optional in case of data exchange
IMPLICIT_SEND – “Implicit sending” means that a runnable can modify a data-element while it is running. After the runnable terminates, the RTE will make the latest value available to receivers of the data-element. It is optional in case of data exchange
TRANSMISSION_ ACKNOWLEDGEMENT – The sending component is notified when the data has been sent correctly. It is optional in case of data exchange
IS_QUEUED – When this parameter is TRUE, the data-element is queued (=used for “events”). When this parameter is FALSE, the data-element has “last-is- best” semantics (= used for data).
Now Lets Configure the Receiver in Sender Receiver Communication. Even if the receiver is not configured at all the receiver will not throw any errors. However, if the sender is not provided with the Init_Value it will throw errors. Some of the attributes that can be configured for data exchange is listed below
Init_Value– A receiver can optionally specify its own initial value, which overrides the initial value of the sender.
RECEIVE_INVALID– The receiver can specify how it wants to respond when an invalid value for a data- element is received.
ALIVE_TIMEOUT – The receiver specifies the maximum period of time it may take to receive a data- element. If the data-element is not received within the defined period, the data-element can be considered as out-dated.
IMPLICIT_RECEIVE – Normally, a runnable wishing to read a data-element needs to do this through an explicit call to the RTE. The “IMPLICIT_RECEIVE” means that the runnable has access to the value of the data- element that was available at the time of the start of the runnable. It does not need to invoke an explicit API to fetch the latest data.
RECEIVE_EVENT– This implies that the receiving applications is notified by the RTE when a new value of a data-element or a mode- switch is received. This implies that the receiving component does not need to poll but can wait for new data- elements or mode-changes.
IS_QUEUED– When this parameter is TRUE, the data-element is queued (=used for “events”). When this parameter is false, the data-element has “last-is-best” semantics.