AUTOSAR 4.2.2 CAN接口规范：详细更新与功能概述

AUTOSAR

CAN

需积分: 9 148 浏览量更新于2024-07-20 收藏 1.76MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

本文档是关于AUTOSAR (Automotive Open System Architecture) Release 4.2.2中的CAN Interface规格说明。AUTOSAR是一个为汽车电子系统开发提供标准的软件架构，它促进了跨供应商的硬件和软件组件的互操作性。本部分详细介绍了自4.1.1版本以来CAN接口规范的演变。在4.2.2版中，文档的重点在于澄清了CAN接口的功能，包括唤醒、缓冲、传输等行为，并移除了过时的API（应用程序编程接口），同时进行了编辑修订。这一更新确保了接口的性能和一致性，支持更高级别的CAN FD（Flexible Data Rate）通信，增强了全球时间同步功能，并去除了`CanIf_CancelTxConfirmation`的取消发送确认机制，以简化开发过程。在4.2.1版中，引入了全面的CAN FD支持，这是对数据传输速率的重大提升，有助于减少通信延迟。此外，还实现了全局CAN网络的时间同步，这在复杂的汽车系统中至关重要。文档在此阶段也做了小规模的改进，以优化用户体验和系统效率。 4.1.3版本中，删除了对BSW（Basic Software）专用区域的限制，并将ICOM（In-Car Communication）支持设置为可选，以便开发者根据项目需求选择是否启用。同时，对CAN标识符类型的处理进行了调整，进一步提升了灵活性。 4.1.2版的改动主要涉及PDU（Protocol Data Unit）模式的限制放宽，删除了章节9中的关键部分描述，以及将`CanIfInitRefCfgSet`设为过时，引入了“Pretended Networking”概念，这些改变旨在简化设计和提高代码的模块化程度。 4.1.1版本的文档管理着重于早期阶段的引入，如CAN FD支持不包含DLC（Data Length Coding）扩展，展示了对重型车辆J1939通信协议的支持，以及不同的Pdu模式选项，这为适应不同类型的车辆应用提供了多样化的解决方案。本资源提供了关于AUTOSAR 4.2.2中CAN Interface的全面规格，对于参与汽车电子系统设计和实施的工程师来说，了解这些变化及其对系统性能、兼容性和可用性的影响是至关重要的。通过阅读和遵循这些规范，开发者可以确保他们的软件设计符合AUTOSAR标准，从而实现高效、可靠的汽车电子系统集成。

资源详情

资源推荐

Speciﬁcation of CAN Interface

AUTOSAR Release 4.2.2

4 Constraints and assumptions

4.1 Limitations

The CAN Interface can be used for CAN communication only and is speciﬁcally de-

signed to operate with one or multiple underlying CAN Drivers and CAN Transceiver

Drivers. Several CAN Driver modules covering different CAN Hardware Units are rep-

resented by just one generic interface as speciﬁed in the CAN Driver speciﬁcation [1].

As well in the same manner several CAN Transceiver Driver modules covering different

CAN Transceiver devices are represented by just one generic interface as speciﬁed in

the CAN Transceiver Driver speciﬁcation [2, Speciﬁcation of CAN Transceiver Driver].

Other protocols than CAN (i.e. LIN or FlexRay) are not supported.

Please be aware that an active PnTxFilter ensures that the ﬁrst messages on bus

is CanIfTxPduPnFilterPdu. In case that CanIfTxPduPnFilterPdu is the NM-PDU the

COM-Stack start up takes care that the PduGroups are disabled until successful trans-

mission of that PDU. However, transmit requests for other PDUs (i.e. initially started

PDUs, TP-PDUs, XCP-PDUs) will be rejected until the conﬁgured PDU was sent.

4.2 Applicability to car domains

The CAN Interface can be used for all domain applications when the CAN protocol is

used.

16 of 215

— AUTOSAR CONFIDENTIAL —

Document ID 012: AUTOSAR_SWS_CANInterface

Speciﬁcation of CAN Interface

AUTOSAR Release 4.2.2

5.1 Upper Protocol Layers

Inside the AUTOSAR BSW architecture the upper layers of the CAN Interface module

(Abbr.: CanIf) are represented by the PDU Router module (Abbr.: PduR), CAN Net-

work Management module (Abbr.: CanNm), CAN Transport Layer module (Abbr.: CanTp),

CAN State Manager module (Abbr.: CanSm), ECU State Manager module (Abbr.: EcuM),

Complex Driver modules (Abbr.: CDD), Universal Calibration Protocol module (Abbr.: XCP),

Global Time Synchronization over CAN (Abbr.: CanTSyn), J1939 Transport Layer mod-

ule (Abbr.: J1939Tp) and J1939 Network Management module (Abbr.: J1939Nm).

The AUTOSAR BSW architecture indicates that the application data buffers are lo-

cated in the upper layer, to which they belong. Direct access to these buffers is pro-

hibited. The buffer location is passed by the CanIf from or to the CAN Driver module

(Abbr.: CanDrv) during transmission and reception. During execution of these trans-

mission/reception indication services buffer location is passed. Data integrity is guar-

anteed by use of lock mechanisms each time the buffer has been accessed. See

section 7.17 Data integrity.

The API used by the CanIf consists of notiﬁcation services as basic agents for the

transfer of CAN related data (i.e. CAN DLC) to the target upper layer. The call param-

eters of these services points to the information buffered in the CanDrv or they refer

directly to the CAN Hardware.

5.2 Initialization: Ecu State Manager

The EcuM initializes the CanIf (refer to [3, Speciﬁcation of ECU State Manager]).

5.3 Mode Control: CAN State Manager

The CanSm module is responsible for mode control management of all supported CAN

Controllers and CAN Transceivers.

5.4 Lower layers: CAN Driver

The main lower layer CAN device driver is represented by the CanDrv (see [1, Speciﬁ-

cation of CAN Driver]). The CanIf has a close relation to the CanDrv as a result of its

position in the AUTOSAR Basic Software Architecture.

The CanDrv provides a hardware abstracted access to the CAN Controller only, but

control of operation modes is done in CanSm only.

The CanDrv detects and processes events of the CAN Controllers and notiﬁes those

to the CanIf.

18 of 215

— AUTOSAR CONFIDENTIAL —

Document ID 012: AUTOSAR_SWS_CANInterface

Speciﬁcation of CAN Interface

AUTOSAR Release 4.2.2

The CanIf passes operation mode requests of the CanSm to the corresponding under-

lying CAN Controllers.

CanDrv provides a normalized L-PDU to ensure hardware independence of CanIf.

The pointer to this normalized L-PDU points either to a temporary buffer (for e.g. data

normalizing) or to the CAN hardware dependent CanDrv. For CanIf the kind of L-PDU

buffer is invisible.

The CanIf provides notiﬁcation services used by the CanDrv in all notiﬁcations scenar-

ios, for example: transmit conﬁrmation (subsection 8.4.2 CanIf_TxConﬁrmation, see

[SWS_CANIF_00007]), receive indication (subsection 8.4.3 CanIf_RxIndication, see

[SWS_CANIF_00006]), transmit cancellation notiﬁcation (subsection 8.4.4 CanIf_ControllerBusOff,

see [SWS_CANIF_00218]) and notiﬁcation of a controller mode change (subsection 8.4.8,

see [SWS_CANIF_00699]).

In case of using multiple CanDrv serving different interrupt vectors these callback ser-

vices mentioned above must be re-entrant, refer to section 7.24 Multiple CAN Driver

support. Reentrancy of callback functions is speciﬁed in section 8.4.

The callback services called by the CanDrv are declared and implemented inside the

CanIf. The callback services called by the CanIf are declared and placed inside the

appropriate upper communication service layer, for example PduR, CanNm, CanTp.

The CanIf structure is speciﬁed in section 5.7 File structure.

The number of conﬁgured CAN Controllers does not necessarily belong to the number

of used CAN Transceivers. In case multiple CAN Controllers of a different types operate

on the same CAN network, one CAN Transceiver and CanTrcv is sufﬁcient, whereas

dependent to the type of the CAN Controller devices one or two different CanDrv are

needed (see section 7.5 Physical channel view).

5.5 Lower layers: CAN Transceiver Driver

The second available lower layer CAN device driver is represented by the CanTrcv (see

[2, Speciﬁcation of CAN Transceiver Driver]).

Each CanTrcv itself does operation mode control of the CAN Transceiver device. The

CanIf just maps all APIs of several underlying CanTrcvs to a unique one, thus CanSm

is able to trigger a transition of the corresponding CAN Transceiver modes. No control

or handling functionality belonging to CanTrcv is done inside the CanIf.

The CanIf maps the following services of all underlying CanTrcvs to one unique inter-

face. These are further described in the CAN Transceiver Driver SWS (see [2, Speciﬁ-

cation of CAN Transceiver Driver]):

• Unique CanTrcv mode request and read services to manage the operation modes

of each underlying CAN Transceiver device.

• Read service for CAN Transceiver wake up reason support.

19 of 215

— AUTOSAR CONFIDENTIAL —

Document ID 012: AUTOSAR_SWS_CANInterface

Speciﬁcation of CAN Interface

AUTOSAR Release 4.2.2

• Mode request service to enable/disable/clear wake up event state of each used

CAN transceiver (CanIf_SetTrcvMode(), see [SWS_CANIF_00287]).

5.6 Conﬁguration

The CanIf design is optimized to manage CAN protocol speciﬁc capabilities and han-

dling of the used underlying CAN Controller.

The CanIf is capable to change the CAN conﬁguration without a re-build. Therefore, the

function CanIf_Init (see [SWS_CANIF_00001]) retrieves the required CAN conﬁg-

uration information from conﬁguration containers and parameters, which are speciﬁed

(linked as references, or additional parameters) in chapter 10, see Figure 10.1.

This section gives a summary of the retrieved information, e.g.:

• Number of CAN Controllers. The number of CAN Controllers is necessary for

dispatching of transmit and receive L-PDUs and for the control of the status of

the available CAN Drivers (see CanIfCanControllerIdRef).

• Number of Hardware Object Handles. To supervise transmit requests the CAN

Interface needs to know the number of HTHs and the assignments between each

HTH and the corresponding CAN Controller (see CANIF_HTH_CAN_CONTROLLER_ID_REF,

ECUC_CanIf_00625; CANIF_HTH_ID_SYMREF, ECUC_CanIf_00627 ).

• Range of received CAN IDs passing hardware acceptance ﬁlter for each hard-

ware object. The CAN Interface uses ﬁxed assignments between HRHs and L-

PDUs to be received in the corresponding hardware object to conduct a search al-

gorithm (see section 7.20 Software receive ﬁlter, see CANIF_SOFTWARE_FILTER_HRH,

CANIF_HRH_CAN_CONTROLLER_ID_REF, CANIF_HRH_ID_SYMREF, ECUC_CanIf_00634)

CanIf needs information about all used upper communication service layers and L-

SDUs to be dispatched. The following information has to be set up at conﬁguration time

for integration of CanIf inside the AUTOSAR COM stack:

• Transmitting upper layer module and transmit I-PDU for each transmit L-SDU.

=> Used for dispatching of transmit conﬁrmation services

(see CANIF_CANTXPDUID, ECUC_CanIf_00247).

• Receiving upper layer module and receive I-PDU for each receive L-SDU.

=> Used for L-SDU dispatching during receive indication

(see CANIF_CANRXPDUID, ECUC_CanIf_00249).

The CanIf needs the description of the controller and the own ECU, which is con-

nected to one or multiple CAN networks. The following information is therefore re-

trieved from the CAN communication matrix, part of the AUTOSAR system conﬁgu-

ration (see containers: CanIfTxPduConﬁg, ECUC_CanIf_00248; CanIfRxPduConﬁg,

ECUC_CanIf_00249):

20 of 215

— AUTOSAR CONFIDENTIAL —

Document ID 012: AUTOSAR_SWS_CANInterface

剩余214页未读，继续阅读

yf820625

粉丝: 53
资源: 5

AUTOSAR 4.2.2 CAN接口规范：详细更新与功能概述

AUTOSAR_SWS_CANInterface.pdf

AUTOSAR_SWS_CANInterface43_autosar_

AUTOSAR_MCAL_BASE_IM 整合指南

AUTOSAR_CANDrive标准规范详解

AUTOSAR_SRS_TTCAN: TTCAN需求规范

AUTOSAR_BSWModuleList: 基本软件模块清单

AUTOSAR_OS详解：抢占任务优先级天花板与中断集成

AUTOSAR中的OS_RTOS概念及应用

autosar_sws_timesyncovercan

autosar_sws_e2elibrary r19

autosar_sws_cannetworkmanagement_4.3_中文版本.pdf

autosar_sws_diagnostics.pdf

autosar_sws_e2elibrary.zip

autosar_sws_secureonboardcommunication

autosar_sws_cannetworkmanagement 中文版

AUTOSAR_SWS_CRC

autosar_sws_diagnostics.pdf 中文翻译

autosar_sws_someiptransformer.pdf

翻译一下Adaptive AUTOSAR规范文档《AUTOSAR_SWS_Diagnostics.pdf》

autosar_sws_e2elibrary

最新资源