FlexRay TP

Das Pro­blem der Seg­men­tie­rung stellt sich bei Flex­Ray in ähn­li­cher Form wie bei CAN. Theo­re­tisch kann eine Flex­Ray-Bot­schaft zwar bis zu 254 Daten­by­tes ent­hal­ten, prak­tisch wird man die Bot­schafts­län­ge aber deut­lich kür­zer wäh­len – zumin­dest im sta­ti­schen Seg­ment. Daher hat Auto­sar einen Vor­schlag für einen Trans­port-Layer für Flex­Ray vor­ge­legt, der auch als Basis für den ISO-Stan­dard 10681-2 dient. Aller­dings hat sowohl der Auto­sar-Stan­dard als auch der Ent­wurf der ISO-Norm eine Rei­he von Modi­fi­ka­tio­nen erlebt, so dass es im Augen­blick gewagt wäre zu sagen, dass der Trans­port-Layer für Flex­Ray bereits abso­lut sta­bil sei.

Das Bot­schafts­for­mat wur­de gegen­über ISOTP für CAN nur gering­fü­gig modi­fi­ziert. Zum Bei­spiel in Form der PCI-Infor­ma­tion. Aller­dings woll­te man mit die­sem Trans­port-Pro­to­koll deut­lich län­ge­re Bot­schaf­ten dar­stel­len kön­nen. Des­we­gen hat man den Single-Fra­me über eine ande­re Ken­nung in einen Single-Fra­me-Exten­ded modi­fi­ziert. Hier ist das Feld für die Daten­län­ge so gewählt, dass man bis zu 250 Bytes in eine Bot­schaft packen kann.

Modi­fi­zier­tes Bot­schafts­for­mat für AUTO­SAR FR TP

Dann gibt es einen Fir­st- und einen Con­se­cu­ti­ve-Fra­me, wie wir ihn von CAN ken­nen und des Wei­te­ren eine Exten­ded-Varia­tion des Fir­st-Fra­mes, bei der das Daten­län­gen­feld so gewählt ist, dass man ins­ge­samt eine Daten­län­ge von bis zu vier Giga­by­te adres­sie­ren kann. Bei CAN waren es dage­gen nur vier Kilo­by­te.

Am Anfang der Trans­port­bot­schaf­ten muss­te man bei Flex­Ray ein Feld für die Adres­sie­rungs­in­for­ma­tio­nen ein­fü­gen, das es bei CAN so nicht gibt. Dort hat man die­se über die CAN-ID kodiert. Bei Flex­Ray wer­den nun im ers­ten Teil der Nutz­da­ten einer Flex­Ray-Bot­schaft die Tar­get- und Sour­ce-Adres­se mit­ge­schickt. Der Sinn des Mitsen­dens die­ser bei­den Adres­sen für Quell- und Emp­fän­ger­steu­er­ge­rät ist, dass man bei Flex­Ray nicht für jede Kom­mu­ni­ka­tion zwi­schen einem Sen­der und einem Emp­fän­ger einen sepa­ra­ten Slot in der Sche­du­ling-Table reser­vie­ren will. Dar­aus ergibt sich: Wenn man einen Slot mehr­fach benut­zen will, dann muss es einen Mecha­nis­mus geben, der unter­schei­det, wer Sen­der und wer Emp­fän­ger ist. Aus die­sem Grund wird die­se Infor­ma­tion auf der Trans­port­pro­to­kol­le­be­ne mit­ver­sen­det.

Als letz­tes gibt es dann einen zusätz­li­chen Ack­now­led­ge-Fra­me, der vom Emp­fän­ger zum Sen­der gesen­det wird, um zu bestä­ti­gen, dass die Daten auch kor­rekt ange­kom­men sind. Das ist not­wen­dig, da es im Gegen­satz zu CAN bei Flex­Ray inner­halb der Bot­schaft kei­ne Feh­ler­rück­mel­dung zwi­schen Emp­fän­ger und Sen­der gibt. Auf Appli­ka­ti­ons­ebe­ne muss im Feh­ler­fall eine Sen­de­wie­der­ho­lung ein­ge­lei­tet wer­den, wäh­rend der CAN-Con­trol­ler hier das Ver­sen­den auto­ma­tisch wie­der­holt.

Siehe auch

Transportprotokolle

ISOTP

Andere Transportprotokolle