航空应用CAN总线接口规范V1.7

需积分: 9 201 浏览量更新于2024-07-16 1 收藏 568KB PDF 举报

"canas_17_CANaerospace.pdf" 是一份关于航空应用中的CAN（Controller Area Network）总线接口规范的文档，适用于开发者、学生、教师和设计人员。这份文档详细描述了CAN总线的协议和其他相关技术，是NASA AGATE数据总线的一个版本，修订至1.7版，发布于2006年12月1日。 CAN总线是一种广泛应用的现场总线系统，特别适合在汽车、航空和工业自动化等领域，因其高可靠性、低成本和良好的错误检测能力而著名。CAN总线标准定义了节点间通信的数据帧结构、仲裁机制、错误处理和故障检测等核心要素。文档的修订历史记录了规范的发展过程： 1.0 版本：初始版本。 1.05 版本：修改了标识符列表。 1.1 版本：增加了MIL连接器定义。 1.2 版本：添加了导航标识符。 1.3 版本：发动机/燃料系统参数定义变更，支持多种数据类型。 1.4 版本：重新排列了NAV部分，新增了数据类型。 1.5 版本：更新了连接器定义，标准化了一些数据。 1.6 版本：引入冗余支持和时间触发的总线调度。 1.7 版本：扩展了标识符分布列表，添加了多个节点服务，并进行了澄清。文档中可能包含的内容有： 1. **总线协议**：详述了CAN总线的物理层（包括传输速率、信号电平）、数据链路层（包括帧格式、仲裁、错误检测）以及应用层的规范。 2. **接口标准**：定义了航空应用中CAN总线与其他设备或系统的接口要求，可能包括电气特性、物理连接器类型以及信号定义。 3. **节点服务**：描述了网络中每个节点如何注册、识别和执行任务，以及如何处理来自其他节点的消息。 4. **冗余支持**：介绍了如何在系统中实现冗余，以确保在单个节点或总线段故障时仍能保持通信。 5. **时间触发通信**：说明了如何安排节点按照预定的时间表发送数据，以确保实时性和确定性。 6. **标识符列表**：列出了不同类型的标识符，用于区分网络上的不同数据类型和服务。 7. **数据类型**：定义了不同类型的数据结构和格式，以适应不同应用的需求。 8. **错误处理**：详细解释了错误检测、错误帧的发送以及进入故障被动或主动模式的规则。该文档对于理解CAN总线在航空航天领域的具体应用和设计是非常有价值的，可以帮助读者深入掌握CAN总线的特性和实施细节。同时，由于作者明确声明无版权限制，任何人都可以自由地实施、使用或分发该标准，这使得它成为一个开放的标准，有利于技术的广泛传播和应用。然而，作者对标准的使用可能带来的任何责任不承担责任。

Emergency Event Data (EED) is transmitted asynchronously by the af-

fected unit whenever an error situation occurs. The corresponding

data contains information about the location within the unit at which

the error ocurred, the offending operation and the error code:

Normal Operation Data (NOD) is transmitted during normal operation,

either cyclic or asynchronously. The data type (and therefore the mes-

sage byte count) is taken from the data type list:

Node Service Data (NSH/NSL) is data associated to the node service

protocol as specified in section 4. The message format is similar to

NOD. Node service data, however, is transmitted on specific identi-

fiers only:

The Debug Service Data message format is entirely user-deﬁned be-

cause of the speciﬁc requirements resulting from the various host/tar-

get communication protocols. Aside from using the speciﬁed identiﬁer

range, no restrictions apply. To maximize ﬂexibility, the message layout

and the data types must not follow any of the CANaerospace deﬁniti-

ons. It is encouraged, however, to use the proposed standard.

User-Deﬁned Data message formats may be created for speciﬁc pur-

poses. Aside from using the speciﬁed identiﬁer range, no restrictions

apply. To maximize ﬂexibility, the message layout and the data types

must not follow any of the CANaerospace deﬁnitions. It is encouraged,

however, to use the proposed standard.

3.2 EmergencyEvent

Data (EED) mes-

sage format

3.3 Normal Operati-

on Data (NOD)

message format

3.4 Node Service

Data (NSH/NSL)

message format

3.5 Debug Service

Data (DSD) mes-

sage format

3.6 User-Deﬁned

Data (UDL/UDH)

message format

Byte 4 Byte 5 Byte 6 Byte 7Byte 0 Byte 1 Byte 2 Byte 3

Message Header Message data (type/length as required)

Byte 4 Byte 5 Byte 6 Byte 7Byte 0 Byte 1 Byte 2 Byte 3

Message Header

Error code (SHORT)

OperationID (CHAR)

LocationID (CHAR)

(Byte 1 = $01)

Byte 4 Byte 5 Byte 6 Byte 7Byte 0 Byte 1 Byte 2 Byte 3

Message Header Message data (type/length as required)

A node service is initiated by a node service request message, trans-

mitted on the corresponding identiﬁer. All nodes attached to the net-

work are obliged to continously monitor these identiﬁers and check if

received messages contain the own personal node-ID. If a match is

detected, the corresponding node has to react by performing the re-

quired action and transmitting a node service response message on

the corresponding identiﬁer within 100ms (if this was required by the

request type). The node service response must again contain the per-

sonal node-ID of the addressed node. Any node in the network is allo-

wed to initiate node services. It is recommended, however, that each

node in the network initiating node service requests uses a dedicated

node service channel to avoid potential hand-shaking conﬂicts. The

channel on which a particular node service is run may be deﬁned by

the user. If only one service channel is used, node services must be

run on channel 0 by default. Some frequently used types of node ser-

vices are already speciﬁed below, other services may be added as re-

quired.

Each CANaerospace unit

must support at least the Identiﬁcation

Service (IDS) on Node Service Channel 0. This makes sure that a

CANaerospace network can be scanned for attached units to de-

termine their status, header type and identiﬁer assignment. Note

that within a CANaerospace network, other header types than the

standard CANaerospace header and several identiﬁer assign-

ment schemes (including entirely user-deﬁned ones) are suppor-

ted. Whenever possible, it is strongly recommended to use the

proposed standard header and identiﬁer assignment, however.

102 2004 ($7D4) 2005 ($7D5)

....... ....... ......

115 2030($7EE) 2031 ($7EF)

Node

Service

Code

Response

Required

Action

IDS 0 Yes Identiﬁcation service. Requests

a “sign-of-life” response together

with conﬁguration information

from the addressed node.

NSS 1 No Node synchronisation service,

used to trigger a speciﬁc node or

to perform a network wide time

synchronisation.

Node Service

Channel

Node Service

Request ID

Node Service

Response ID

剩余57页未读，继续阅读

weixin_39775909

粉丝: 0
资源: 1

航空应用CAN总线接口规范V1.7

CAN总线基础知识总结(建议收藏).pdf

CAN总线学习总结.pdf

TI-TCAN337G.pdf

列出30种可以封装在tcp/ip里的工控协议

can常用的应用层协议

CAN 是Controller Area Network 的缩写.doc

TI-ISO1050.pdf

CAN总线协议与总线分析.doc

can总线平台搭建

CAN总线的基本东西资料

最新资源