SOME/IP
COM, LdCom and the transformer chain
Between the RTE and the PDU Router, SOME/IP data is just one byte array. The RTE may run more than one transformer to build it, and either COM or the leaner LdCom carries it on.
A chain of transformers
The SOME/IP transformer is not always alone. The RTE can run a transformer chain (several transformers run one after the other on the data of one communication): the first one does the serialization into bytes, the next ones work on those bytes. A common second transformer is the E2E transformer (end-to-end protection: it adds a check value and a counter so the receiver can detect corrupted, lost or repeated data).
rule 1
SOME/IP comes first
The SOME/IP transformer turns structured data into bytes, so it must be the first transformer when sending and the last when receiving. All later transformers take bytes in and give bytes out.
rule 2
The RTE runs the chain
It calls each transformer in order with buffers it provides, inside the RTE call of the SWC (or around the runnable for implicit access). A hard transformer error in any of them stops the data from being delivered.
alternative
COM Based Transformer
For small signal-oriented networks there is a different first transformer, the COM Based Transformer (it serializes data exactly like COM would lay out its signals). It cannot be used for methods; SOME/IP services use the SOME/IP transformer.
COM or LdCom
Whatever the transformer chain produced is handed down as one byte-array signal (UINT8_N or UINT8_DYN), the only signal in its I-PDU. Two modules can carry it: COM and LdCom.
| COM | LdCom | |
|---|---|---|
| What it carries | A UINT8_N (fixed length) or UINT8_DYN (dynamic length) signal | Exactly one signal per I-PDU, fixed or dynamic length |
| Extras | All COM features: transmission modes, repetitions, deadline monitoring, filters, update bits, … | None: no transmission modes, no deadline monitoring, no filters, no endianness conversion; it never starts a transmission on its own |
| Data buffer | Kept in COM's own buffer | No buffer of its own; it passes calls straight through between the RTE and the PDU Router |
| Large I-PDUs | Through the normal (IF) path or the transport protocol (TP) path | Through the normal (IF) path or the transport protocol (TP) path |
Which one is used follows from the system description: if the signal's I-PDU is handled by LdCom, the RTE talks to LdCom; otherwise to COM. During a transmission through the TP path, the RTE locks the data until the transmission is confirmed; a second write in that time is refused as "busy".
Try it
Build a transformer chain and pick COM or LdCom. The panel lists what happens on a transmission, one module call after the other.
Things to notice. Adding the E2E transformer adds one more step on each side and one more header in the byte array, but nothing changes below the RTE: COM or LdCom still see one byte array. With LdCom and the TP path, the data stays with the RTE and is copied out part by part, which is why the RTE must lock it until the transmission is confirmed.
Check yourself optional
New terms in this lesson
| Term | Meaning |
|---|---|
| transformer chain | The transformers the RTE runs one after the other on the data of one communication, for example SOME/IP then E2E |
| E2E transformer | Transformer for end-to-end protection: adds a check value and a counter so the receiver detects corrupted, lost or repeated data |
| COM Based Transformer | An alternative first transformer that lays data out like COM signals; not for methods |
Source: RTE, R20-11, sections 4.3.1.16 and 4.10; Large Data COM, R20-11, chapters 1, 4 and 7; SOME/IP Transformer, R20-11, chapter 7; Layered Software Architecture, R20-11 (data transformation examples); SOME/IP Protocol, R20-11, section 4.1.2 (position of the E2E header).