ARINC615A协议-数据加卸载

目录

一、ARINC615A协议介绍

1. 协议介绍

2. 基本操作

3. 协议文件

二、TFTP协议

1. 协议概述

2. 协议结构

3. TFTP通信流程

三、AFDX网络

四、协议文件具体构成

五、目标端流程

---

一、ARINC615A协议介绍

1. 协议介绍

        ARINC615A协议是一种基于以太网和ARINC 664总线等高速数据总线的数据加载协议。，定义了一种协议标准，规定了数据交互的文件格式和要求，以确保加卸载操作的准确性和可靠性。ARINC615A的目的是规定一种如何把数据文件在加载端和目标端之间交互的协议标准。

        在数据加卸载过程中，分为加载端和目标端，加载端通常为大容量设备，目标端通常为交换机或其他端系统设备。在传输过程中，加载端会向目标端发送数据文件，而目标端会向加载端发送状态文件或历史文件等。

2. 基本操作

        ARINC615A协议两端之间的操作分为五种：Find操作、信息操作（Infor）、上传操作（Upload）、介质定义下载操作（MediaDownload）、操作者定义下载操作（OperatorDownload）。具体功能如下：

• Find：加载端发送Find操作请求包给目标端，目标端接收到请求后通过AFDX网络传输回复Find应答包，信息包括目标硬件设备标识符、类型名称、目标硬件设备身份标识、制造商代码等。加载端在获取到目标端硬件信息后更新信息。在每次加卸载前，需进行Find操作查看目标端是否在线。
• Infor：与Find类似，查看目标端硬件信息，包括名称、硬件序列号、部件号等。
• Upload：加载端上传数据文件至目标端。
• MediaDownload：加载端向目标端请求下载文件。加载端通过AFDX网络将内容为下载请求的TFTP格式的包传送至目标端，等待接受目标端的所有文件。
• OperatorDownload：加载端向目标端请求下载文件。加载端向目标端发送读请求，要求读取目标端的可下载列表文件清单，接收到后再向目标端发送需要下载的文件清单，然后执行下载操作，等待接收文件。

3. 协议文件

        根据ARINC615A-3协议和ARINC665协议可加载标准协议，规定了加卸载过程中各个操作的各个协议文件。

        文件的命名示例：“THW_ID_POS.XXX”，其中THW_ID为设备硬件标识符，POS为位置标识符，XXX为文件后缀。后缀的具体含义描述如下表所示：

文件后缀	所属功能	具体含义
LCI	Find&Infor	通信状态初始化文件
LCL	Find&Infor	含有目标机硬件序列号等信息的目标机配置文件
LCS	Find&Infor	操作过程中目标机组织并发送当前状态文件
LUI	Upload	通信状态初始化文件
LUR	Upload	向目标端上传的文件列表
LUH	Upload	内容含有使目标机支持接收的加载数据的消息内容
LUS	Upload	状态文件
LND	MediaDownload	介质定义下载通信状态初始化
LNR	MediaDownload	请求下载的文件列表
LNS	MediaDownload	状态文件
LNO	OperatorDownload	操作者自定义下载操作过程中通信状态初始化
LNL	OperatorDownload	目标端提供可下载文件列表
LNA	OperatorDownload	加载端要下载的文件清单

        协议文件的具体内容描述请看四、协议文件具体构成...

二、TFTP协议

1. 协议概述

        简单文件传输协议（Trivial File Transfer Protocol，TFTP）用来规定客户端和服务器之间如何互相进行文件传输。该协议位于应用层，基于UDP协议，仅仅提供文件的发送和接收。

        TFTP协议传输开始于服务器发送一个文件读请求或写请求，如果客户端接受该请求，服务器就会建立连接。TFTP规定了传输文件包容量不大于512字节，因此在传输过程中，若包容量低于512字节，系统会标记为文件已经传输完成。如果在传输过程中出现丢包的情况，则数据包会在超时后重新发送出去一个还没有被对方确认的数据包。

        在通信过程中，服务器和客户端都能被称为文件的发送端和接收端，一端发送出去数据宝并等待接受对方的应答，对方发送出去应答的同时接收对方发送的文件信息，TFTP还规定了超时机制，超时后会结束操作。

2. 协议结构

        TFTP协议包格式包括：LocalMedium（本地媒介头）、IP、Datagram（数据报头）、TFTP头

LocalMedium

IP

Datagram

TFTP

TFTP头又分为五种格式，不同包格式是由包数据前两个字节的Opcode操作码来分辨的，Opcode具体值如下：

• （1）读文件请求包：Read request，RRQ，对应Opcode为1；
• （2）写文件请求包：Write request，WRQ，对应Opcode为2；
• （3）文件数据包：DATA，对应Opcode为3；
• （4）回应包：Acknowledgement，ACK，对应Opcode为4；
• （5）错误信息包：ERROR，对应Opcode为5；

TFTP规定读请求包和写请求包格式如下：

Opcode	Filename	0	Mode	0
2bytes	string	1byte	string	1byte

Opcode为包类型，RRQ为0x0001，WRQ为0x0002；Filename为请求的文件名，后面跟着1字节0表示结束；Mode为指明文件的传输方式，后面跟1字节0表示结束。

TFTP规定数据包格式如下：

Opcode	Block	Data
2bytes	2bytes	nbytes

数据包的Opcode为0x0003；Block为传输的数据包编号，用来区分数据包，从1开始，累加到65535后，从1重新开始；Data为传输的数据内容。

TFTP规定确认包的格式如下：

Opcode	Block
2bytes	2bytes

ACK确认包是用来加载端与目标端之间确认已经收到对应的数据块，保证正常通讯的确认手段。Opcode为0x0004；Block为接收方收到的数据包编号，用来区分数据包。对于写请求数据包，其ACK的Opcode为0。

TFTP规定错误包ERROR格式如下：

Opcode   ErrorCode     ErrMsg   0

2bytes      2bytes      string       1bytes

Opcode	ErrorCode	ErrMsg	0
2bytes	2bytes	string	1bytes

ERROR的作用是在双方连接建立没有成功或双方的数据传输过程中出现问题的情况下，发送错误包告知对方。Opcode为0x0005；ErrorCode为错误码，用来标识不同错误类型，具体类型如下表。ErrMsg为错误内容，后跟一字节0表示结束。

0	未定义
1	文件未找到
2	访问非法
3	磁盘满或超过分配的配额
4	非法的TFTP操作
5	未知的传输ID
6	文件已经存在
7	没有此用户
8	TFTP操作拒绝

3. TFTP通信流程

        615A加卸载端系统的其余任何操作需要的文件以及请求包的传输都是基于TFTP 协议来设计应用的。

        充当TFTP 客户端和服务端的加载端或者目标端开始建立连接时，向对方发送 WRQ或RRQ，接收到对方的回应后，向对方发送ACK，告知对方已经收到对方的回应，接下来收到对方发送过来数据包或者向对方发送过去数据包后，如果正常接收或者写入，会回复对方个ACK包。当双方的任一方接收一个ERROR 包时，说明该请求被对方拒绝，需终止操作。

三、AFDX网络

具体可参考如下内容：

AFDX网络技术综述——2016年电子技术应用第4期

ARINC 664 P7 AFDX机载航电网络

航空电子全双工交换式以太网AFDX

四、协议文件具体构成

1. LUI

属性	大小（bits）
文件大小	32
协议版本号	16
协议标志码	16
状态描述长度	8
状态描述	0-20

typedef struct LOAD_PROTO_INIT_FILE
{
    uint32_t FileLen;
    uint16_t ProtocolVer;
    uint16_t StatusCode;
    uint8_t  StatusDesLen;\
    unsigned char StatusDes[MAXBUFLEN];
}LOADPROTOINTFILE, *PLOADPROTOINTFILE;

2. LUR

属性	大小（bits）
文件长度	32
协议版本号	16
头文件个数	16
头文件名的长度	8
头文件名	8-2040

typedef struct HEAD_FILE
{
    uint8_t       HeadFileNameLen;
    unsigned char HeadFileName[MAXBUFLEN];
    uint8_t       LoadPNNameLen;
    unsigned char LoadPNName[MAXBUFLEN];
    unsigned char LoadRatio[3];
    uint16_t      LoadStatus;
    uint8_t       LoadStatusDesLen;
    unsigned char LoadStatusDes[MAXBUFLEN];
}HEADFILE, *PHEADFILE;

3. LUS

属性	大小（bits）
文件长度	32
协议版本号	16
上传状态码	16
上传状态描述长度	8
上传状态描述	小于2040
计数器	16
等待时长	16
估计时长	16
加载列表完成比例	24
头文件个数	16
头文件名的长度	8
头文件名	8-2040
加载比例	24
加载状态	16
加载状态描述长度	8
加载状态描述	小于2040

 

typedef struct LOAD_PROTO_UPLOAD_STATUS_FILE
{
    uint32_t      FileLen;
    uint16_t      ProtocolVer;
    uint16_t      StatusCode;
    uint8_t       StatusDesLen;
    unsigned char StatusDes[MAXBUFLEN];
    uint16_t      Counter;
    uint16_t      ExceptTimer;
    uint16_t      EstimatedTimer;
    unsigned char LoadListRatio[3];
    uint16_t      NumOfHeadFile;
    PHEADERFILE   *ppHeaderFile;
}

五、目标端流程

1. 管理员获取服务公告或软件更新项。
2. 管理员通过 Find广播命令获取目标硬件网络信息(响应的设备为可支持数据加载的设备)。
3. 选择传输协议

4. 操作员选择一个可加载部件，其中包含一个头文件，一个数据文件（大小为4个block，每个block仅包含一个record）。
5. 数据加载器应用程序（DLA）向目标硬件应用程序（THA）发送数据上载请求，请求LUI文件。
6. THA 根据相关状态参数判断是否满足数据加载请求条件，并向向DLA发送<THW ID POS>LUI 文件。其中，LUI 文件中Status Code值为0x0001，表示接受操作。
7. DLA 接收并解析.LUI，进入列表传输阶段。
8. THA 向 DLA 首次发送LUS（过程状态文件，后续周期性发送) 
LUS 文件中Load List Ratio"值表示总传输比率。
LUS 文件中Load Status"值为0x0001，
LUS 文件中Load Ratio 值表示当前文件传输比率。

9. DLA 接受并解析LUS 文件，并向THA发送LUR文件（待上载头文件列表清单）。
10. THA 接收并解析LUR文件，进入教据传输阶段。
11. THA 根据LUR 文件选择第一个头文件发起LUH
文件读请求
12. DLA 接收到LUH 读请求后，检测目标文件是否存在以及目标文件是否可用。检查通过后，开始向THA传输文件，详细命令响应如下：
12.1 DLA THA发送 Request to Send”（包括当前block的record教量）
12.2 THA确认准备接收的record 教里没错，发送“Clear to Send'响应 DLA
12.3 DLA收到 Clear to Send响应后2s内向问THA 发送"data Folows”，并开始传输第一个record到THA
12.4 当DLA问THA发送"final Word'，同时 THA响应回复 ACK，代表这个record 传输完成。
重复上述4步 直到一个数据文件的全部block 全部传输完成，DLA 问 THA 发送"HDR Status Word'
13. THA 接收的文件存储到临时存储区中，并对接收文件进行如下检测：
DLA 应对接收的文件（*LUH 中指出的每一个文件）进行 CRC 校验。
当 DLA 接收完一个 Header Fie 中所有文件后应进行Load Cheek Value 校验。
兰 DLA 接收完一个Header Fie 中所有文件后应进行Load CRC 校验。。
上述校验均通过，向DLA发送Load Complete Command"指令
14. 对每个文件进行完整性检查，
Load CRC 校验
Load Check Value 校验
完整性检查构通过，THA 最后一次向DLA 发送LUS文件。LUS 文件中Upload Operation Status Code值为0×0003，描述为操作完成，无錯误；
LUS 文件中"Load List Ratio值为100表示传输列表比率为100；
16、固化：THA 将临时存储区中的文件逐个拷贝到可加载应用存储目录