0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Specification of CAN Transport Layer, AUTOSAR 14, R22-11, CP 20230421

Last updated at Posted at 2023-05-03

AUTOSARは自動車用OSの業界団体規格です。 
業務で利用する場合には、会員になることを条件にしています。

2002年から20年経ち、当初の狙いの段階に近づいてきました。

MATLABでモデルさえ記述すれば、あとは自動生成だけでソフトが完成するところまで、あと一歩です。
Ethernet, UNIXが生まれて20年で大衆化したのと同じように考えると分かりやすいでしょう。 

AUTOSARの上で動く、クラウド対応のミドルウェアが出て、開発も運用もクラウドになれば、一気にAUTOSARは大衆化するでしょう。

AUTOSAR Abstract Platformへの道 R22-11

AUTOSARは、ISO、IEC、ITUと情報交換契約を結んでいません。
AUTOSAR文書には、ISO、IEC,ITU記述を全文引用することはできません。
WTO/TBT協定に基づき、国際的な調達は国際規格との差異を記述することにより文化依存しない仕様を目指します。
ISO、IEC、ITU文書を合わせて読むと技術内容は理解できます。 
CAN、OSEK/VDX OS、DIAGは、ISO定義を先に確認しましょう。  
OSEK COM、OSEK NMなどはISOの規定から、基本的な部分でAUTOSARでは定義を変えています。
AUTOSARで変更している部分を仕様等で明記するか、ISOを改定するとよいでしょう。 

AUTOSARの参考文献欄の改定が進んでいません。 
Glossary用語定義の網羅性が低いです。
本文を読む前に確認するとよいかもしれません。
本文を読んでから確認してもよいかもしれません。

<この記事は書きかけです。順次追記します。>
This article is not completed. I will add some words in order.

2023年4月URL変更

この項は2023年4月21日、AUTOSARの文書のURLが変更になった。
/classic/22-11/

/R22-11/CP/
過去記事で、URLでエラーが出たら書き換えてみてください。

/adaptive/22-11/
は 
/R22-11/AP/

/foundation/22-11/
は 
/R22-11/FO/
です。

2022年11月URL変更

2022年11月にもAUTOSAR文書のURLが変更になっている。
/user_upload/standards/classic/21-11/

/standards/R21-11/CP/
などに書き換えてください。

/user_upload/standards/adaptive/21-11/

/standards/R21-11/AP/

/user_upload/standards/foundation/21-11/

/standards/R21-11/FO/

お手数をおかけします。
1年に2度URLを変更するなんて、新しい記事が書ける。とても嬉しい。

一覧

1年に2度URLを変更するなんて、新しい記事が書ける。とても嬉しい。

AUTOSAR R22-11 Qiita記事一覧 20230421 。

分量が多く2分割しました。

AUTOSAR R22-11 Qiita記事一覧 20230421(2)
https://qiita.com/kaizen_nagoya/items/b3b992ec1885ad29801a

記事の表題の最後に「20230421」を加えます。

<この項は書きかけです。順次追記します。>

AUTOSARが、2022年の版、R22-11を公開しました。

R21-11
https://www.autosar.org/fileadmin/standards/R21-11/CP/AUTOSAR_SWS_CANTransportLayer.pdf

R20-11

R19-11

文書は検索してダウンロードできます。

R20-11,R21-11, R22-11の3年分だけになりました。

公開行事の模様は

AUTOSAR R22-11 Release Event 20221208

AUTOSAR R22-11 Classic Platform 一覧はこちら。

Classic Platform Release Overview, AUTOSAR No.0 ,R22-11, CP, 20230421

Abstract Platformとの関係

メモリの抽象モデルを、コンパイル時、リンク時、実行時、退避時について一貫して扱う。

Specification of CAN Transport Layer, AUTOSAR 22-11, CP, No.14

Specification of CAN Transport Layer, AUTOSAR 22-11, CP, No.14

AUTOSAR Countdown Calendar 2022

2022/12/09日の投稿です。

AUTOSARが、今年の版、R22-11公開しました。公開行事の模様は

AUTOSAR R22-11 Release Event 20221208

下記は想定URLです。順次確認中です。

ISO の文書を入手したら、ISOの図表を引用する予定です。

ISO 各種規格に基づいた診断、通信の抽象的な定義をする。

文書変更(Document Change)

Clarification of PduR result value in case of transmit error

用語(terms)

Term Description
I- Relative to AUTOSAR COM Interaction Layer
L- Relative to the CAN Interface module which is equivalent to the Logical Link Control (the upper part of the Data Link Layer - the lower part is called Media Access Control)
N- Relative to the CAN Transport Layer which is equivalent to the OSI Network Layer.
CAN L-SDU This is the SDU of the CAN Interface module. It is similar to CAN N-PDU but from the CAN Interface module point of view.
CAN LSduId This is the unique identifier of a SDU within the CAN Interface. It is used for referencing L-SDU’s routing properties. Consequently, in order to interact with the CAN Interface through its API, an upper layer uses CAN LSduId to refer to a CAN L-SDU Info Structure.
CAN N-PDU This is the PDU of the CAN Transport Layer. It contains a unique identifier, data length and data (protocol control information plus the whole N-SDU or a part of it).
CAN N-SDU This is the SDU of the CAN Transport Layer. In the AUTOSAR architecture, it is a set of data coming from the PDU Router.
CAN N-SDU Info Structure This is a CAN Transport Layer internal constant structure that contains specific CAN Transport Layer information to process transmission, reception, segmentation and reassembly of the related CAN N-SDU.
CAN NSduId Unique SDU identifier within the CAN Transport Layer. It is used to reference N-SDU’s routing properties. Consequently, to interact with the CAN Transport Layer via its API, an upper layer uses CAN NSduId to refer to a CAN N-SDU Info Structure.
I-PDU This is the PDU of the AUTOSAR COM module.
PDU In layered systems, it refers to a data unit that is specified in the protocol of a given layer. This contains user data of that layer (SDU) plus possible protocol control information. Furthermore, the PDU of layer X is the SDU of its lower layer X-1 (i.e. (X)-PDU = (X-1)-SDU).
PduInfoType This type refers to a structure used to store basic information to process the transmission\reception of a PDU (or a SDU), namely a pointer to its payload in RAM and the corresponding length (in bytes).
SDU In layered systems, this refers to a set of data that is sent by a user of the services of a given layer, and is transmitted to a peer service user, whilst remaining semantically unchanged.
BS Block Size
Can CAN Driver module
CAN CF CAN Consecutive Frame N-PDU
CAN FC CAN Flow Control N-PDU
CAN FF CAN First Frame N-PDU
CAN SF CAN Single Frame N-PDU
CanIf CAN Interface
CanTp CAN Transport Layer
CanTrcv CAN Transceiver module
CF See “CAN CF”
Com AUTOSAR COM module
Dcm Diagnostic Communication Manager module
DEM Diagnostic Event Manager
DET Default Error Tracer
DLC Data Length Code (part of CAN PDU that describes the SDU length)
FC See “CAN FC”
FF See “CAN FF”
FIM Function Inhibition Manager
Mtype Message Type (possible value: diagnostics, remote diagnostics)
N_AI Network Address Information (see ISO 15765-2).
N_Ar Time for transmission of the CAN frame (any N-PDU) on the receiver side (see ISO 15765-2 [1]).
N_As Time for transmission of the CAN frame (any N-PDU) on the sender side (see ISO 15765-2 [1]).
N_Br Time until transmission of the next flow control N-PDU (see ISO 15765-2 [1]).
N_Bs Time until reception of the next flow control N-PDU (see ISO 15765-2 [1]).
N_Cr Time until reception of the next consecutive frame N-PDU (see ISO 15765-2 [1]).
N_Cs Time until transmission of the next consecutive frame N-PDU (see ISO 15765-2 [1]).
N_Data Data information of the transport layer
N_PCI Protocol Control Information of the transport layer
N_SA Network Source Address (see ISO 15765-2 [1]).
N_TA Network Target Address (see ISO 15765-2 [1]). It might already contain the N_TAtype(physical/ function) in case of ExtendedAddressing.
N_TAtype Network Target Address type (see ISO 15765-2 [1]).
OBD On-Board Diagnostic
PDU Protocol Data Unit
PduR PDU Router
SDU Service Data Unit
FS Flow Status
CAN FD CAN flexible data rate
CAN_DL CAN frame data length
TX_DL Transmit data link layer data length
RX_DL Received data link layer data length
SF_DL SingleFrame data length in bytes
Default Error Tracer The Default Error Tracer is merely a support to SW development and integration and is not contained in the production code. The API is defined, but the functionality can be chosen and implemented by the developer according to his specific needs.
Diagnostic Event Manager The Diagnostic Event Manager is a standard AUTOSAR module which is available in the production code and whose functionality is specified in the AUTOSAR project.
Extended addressing format A unique CAN identifier is assigned to each combination of N_SA and Mtype. A unique address is filed to each combination of N_TA and N_TAtype in the first data byte of the CAN frame data field. N_PCI and N_Data are filed in the remaining bytes of the CAN frame data field.
Function Inhibition Manager The Function Inhibition Manager (FIM) stands for the evaluation and assignment of events to the required actions for Software Components (e.g. inhibition of specific “monitoring functions”). The DEM informs and updates the Function Inhibition Manager (FIM) upon changes of the event status in order to stop or release functional entities according to assigned dependencies. An interface to the functional entities is defined and supported by the Mode Manager. The FIM is not part of the DEM.
Functional addressing In the transport layer, functional addressing refers to N-SDU, of which parameter N_TAtype (which is an extension to the N_TA parameter [1] used to encode the communication model) has the value functional. This means the N-SDU is used in 1 to n communications. Thus with the CAN protocol, functional addressing will only be supported for Single Frame communication. In terms of application, functional addressing is used by the external (or internal) tester if it does not know the physical address of an ECU that should respond to a service request or if the functionality of the ECU is implemented as a distributed server over several ECUs. When functional addressing is used, the communication is a communication broadcast from the external tester to one or more ECUs (1 to n communication). Use cases are (for example) broadcasting messages, such as “ECUReset” or “Communication Control” OBD communication will always be performed as part of functional addressing.
Mixed addressing format A unique CAN identifier is assigned to each combination of N_SA, N_TA, N_TAtype. N_AE is placed in the first data byte of the CAN frame data field. N_PCI and N_Data are placed in the remaining bytes of the CAN frame data field.
Multiple connection The CAN Transport Layer should manage several transport protocol communication sessions at a time.
Normal addressing format A unique CAN identifier is assigned to each combination of N_SA, N_TA, N_TAtype and Mtype. N_PCI and N_Data are filed in the CAN frame data field.
Physical addressing In the transport layer, physical addressing refers to N-SDU, of which parameter N_TAtype (which is an extension of the N_TA parameter [1] used to encode the communication model) has the value physical. This means the N-SDU is used in 1 to 1 communication, thus physical addressing will be supported for all types of network layer messages. In terms of application, physical addressing is used by the external (or internal) tester if it knows the physical address of an ECU that should respond to a service request. When physical addressing is used, a point to point communication takes place (1 to 1 communication). Use cases are (for example) messages, such as ”ReadDataByIdentifier” or ”InputOutputControl ByIdentifier”
Single connection The CAN Transport Layer will only manage one transport protocol communication session at a time.
Connection channel The CAN Transport Layer is handling resources used by multiple connections in order to save RAM. When a connection becames active, the channel that is used by this connection will be unavailable for other connections.
Connection A transport protocol session, either is a transmission or a reception session on a N-SDU

英日単語帳

日本語は仮訳

T.B.D.

参考(reference)

[1] Road vehicles – Diagnostics on Controller Area Networks (CAN) – Part2: Network layer services

ISO 15765-2:2016
Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 2: Transport protocol and network layer services

2 Normative references

ISO/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model — Part 1
ISO 11898-1:20152, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling

Bibliography

[1] ISO/IEC 10731, Information technology — Open Systems Interconnection — Basic Reference Model — Conventions for the definition of OSI services
[2] ISO 11898-2, Road vehicles — Controller area network (CAN) — Part 2: High-speed medium access unit
[3] ISO 11898-3, Road vehicles — Controller area network (CAN) — Part 3: Low-speed, fault-tolerant, medium-dependent interface
[4] ISO 11898-4, Road vehicles — Controller area network (CAN) — Part 4: Time-triggered communication
[5] ISO 11898-5, Road vehicles — Controller area network (CAN) — Part 5: High-speed medium access unit with low-power mode
[6] ISO 11898-6, Road vehicles — Controller area network (CAN) — Part 6: High-speed medium access unit with selective wake-up functionality
[7] ISO 14229-1, Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements
[8] ISO 14229-2, Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services
[9] ISO 14229-3, Road vehicles — Unified diagnostic services (UDS) — Part 3: Unified diagnostic services on CAN implementation (UDSonCAN)
[10] ISO 15031-2, Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics — Part 2: Guidance on terms, definitions, abbreviations and acronyms
[11] ISO 15031-5, Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics — Part 5: Emissions-related diagnostic services
[12] ISO 15031-6, Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics — Part 6: Diagnostic trouble code definitions
[13] ISO 15765-1, Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 1: General information and use case definition
[14] ISO 15765-4, Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 4: Requirements for emissions-related systems
[15] ISO 27145-2, Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics (WWH-OBD) communication requirements — Part 2: Common data dictionary
[16] ISO 27145-3, Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics (WWH-OBD) communication requirements — Part 3: Common message dictionary
[17] ISO 27145-4, Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics (WWH-OBD) communication requirements — Part 4: Connection between vehicle and test equipment
[18] SAE J1930, Electrical/Electronic Systems Diagnostic Terms, Definitions, Abbreviations and Acronyms
[19] SAE J1939:2011, Serial Control and Communications Heavy Duty Vehicle Network — Top Level Document
[20] SAE J1939-73:2010, Application layer — Diagnostics
[21] SAE J1979, E/E Diagnostic Test Modes
[22] SAE J2012, Diagnostic Trouble Code Definitions
1 ISO 15765-3 Implementation of unified diagnostic services (UDS on CAN) has been withdrawn and replaced by ISO 14229-3 Road vehicles — Unified diagnostic services (UDS) — Part 3: Unified diagnostic services on CAN implementation (UDSonCAN)
2 The dated reference is to the first version of ISO 11898-1 that includes the definition of CAN FD. Versions after the dated reference are also valid. Future dated references are valid for CAN FD.

[2] Diagnostics on controller area network (CAN) – Part 4: Requirements for emission-related systems (Release 2005 01-04)

ISO 15765-4:2021
Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 4: Requirements for emissions-related systems

2 Normative references
ISO/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model
ISO 11898-1, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling
ISO 11898-2, Road vehicles — Controller area network (CAN) — Part 2: High-speed medium access unit
ISO 14229-2, Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services
ISO 15031-3, Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics — Part 3: Diagnostic connector and related electrical circuits: Specification and use
ISO 15765-2, Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 2: Transport protocol and network layer services

Bibliography

[1] ISO/IEC 10731, Information technology — Open Systems Interconnection — Basic Reference Model — Conventions for the definition of OSI services
[2] ISO 15031-5, Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics — Part 5: Emissions-related diagnostic services
[3] ISO 27145-3, Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics (WWH-OBD) communication requirements — Part 3: Common message dictionary
[4] SAE J1979, E/E Diagnostic Test Modes — OBDonEDS
[5] SAE J1979-2, E/E Diagnostic Test Modes — OBDonUDS
[6] SAE J1979-DA, Digital Annex of E/E Diagnostic Test Modes
[7] SAE J2178-1, Class B data communication network messages detailed header formats and physical address assignments

[3] Glossary, AUTOSAR_TR_Glossary

[4] General Specification of Basic Software Modules

AUTOSAR_SWS_BSWGeneral

[5] Specification of PDU Router

AUTOSAR_SWS_PDURouter

[6] Specification of CAN Interface

AUTOSAR_SWS_CANInterface

[7] General Requirements on Basic Software Modules

AUTOSAR_SRS_BSWGeneral

[8] Requirements on CAN

AUTOSAR_SRS_CAN

関連文書(Related document)

「はじめてのCAN/CANFD 」 ベクタージャパン <エンジニア夏休み企画>【読書感想文】

三方良し Udemy 車載LAN入門講座 CAN通信編

詳解 車載ネットワーク CAN, CAN FD, LIN, CXPI, Ethernetの仕組みと設計のために(1) 著者  <エンジニア夏休み企画 読書感想文>

詳解 車載ネットワーク CAN, CAN FD, LIN, CXPI, Ethernetの仕組みと設計のために(2)参考文献 <エンジニア夏休み企画>【読書感想文】

詳解 車載ネットワーク CAN、CAN FD、LIN、CXPI、Ethernetの仕組みと設計のために

ISO15765-2 メッセージ 送受信 基礎編

PCAN-ISO-TP API・ダウンロード

PCAN-Basic API・ダウンロード

ISO-TP入門

参考資料 

@kazuo_reve 私が効果を確認した「小川メソッド」

@kazuo_reve 新人の方によく展開している有益な情報

自己参照 

AUTOSAR Abstract Platformへの道(詳細編)

AUTOSAR Abstract Platform User Group Weekly Report(1) 2022.1.8

祝休日・謹賀新年:2023年の目標

AUTOSAR  R22-11で リンク切れ、表示しない文書

ボッシュ自動車handbook(英語)11版(0-1) 課題と記事一覧new

「ぼくの好きな先生」「人がやらないことをやれ」プログラマになるまで。仮説(37)

小川メソッド 覚え(書きかけ)

DoCAP(ドゥーキャップ)って何ですか?

@kazuo_reve 新人の方によく展開している有益な情報」確認一覧

全世界の不登校の子供たち「博士論文」を書こう。世界子供博士論文遠隔実践中心

Views1万越え、もうすぐ1万記事一覧

「想定外」3.11 東日本大震災をIT技術者が振り返る

Researchmap

R23-11

<この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。>

文書履歴(document history)

ver. 0.01 初稿  20230503
ver. 0.02 ありがとう追記 20230503

最後までおよみいただきありがとうございました。

いいね 💚、フォローをお願いします。

Thank you very much for reading to the last sentence.

Please press the like icon 💚 and follow me for your happy life.

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?