协议标准规定了报文与行为,但没有规定软件怎么写。同一套标准可以写出结构清晰、可移植的实现,也可以写成一堆互相耦合的状态判断。这一节讨论三件事:软件怎么分层、协议栈从哪来、以及带时间窗的机制该放在什么执行上下文里。
1. 分层与职责
推荐的划分是四层,每层承担明确职责:
| 层次 | 职责 | 典型内容 |
|---|---|---|
| 驱动 / 板级支持 | 硬件抽象与中断管理 | CAN 驱动、定时器、Flash、I/O、看门狗 |
| 协议层 | 实现 ISO 11783 定义的机制 | 网络管理(地址声明)、传输层会话、各功能块客户端与服务端 |
| 应用层 | 农具或拖拉机的业务逻辑 | 作业控制、策略状态机、故障处理与降级 |
| 服务层 | 跨功能的支撑能力 | 参数管理、日志、诊断、升级、时间同步 |
分层的判断标准是依赖方向:应用层只依赖协议层提供的接口,协议层不感知具体农具。这样的直接收益是同一套协议层代码可以复用到不同产品上。
2. 协议层要实现什么
按功能块划分,协议层的常见组成有:
- 网络管理:上电后的地址声明、NAME 配置、地址冲突处理、地址变化后的重新注册。这一块是所有通信的前提。
- 传输层:连接管理会话状态机、超时与中止处理、并发会话隔离、重组缓冲管理。
- VT 客户端:能力探测、对象池组装与上传、掩膜激活、事件处理、会话保活。
- TC 客户端:接收作业指令、回报过程数据、响应分段命令、导出作业记录。
- TECU 客户端:读取拖拉机侧发布的速度、PTO、悬挂等信息。
- 诊断服务:故障码读取与上报。
- 文件服务客户端:与文件服务器交互,完成文件读写。
只做农具控制器的产品,前三项是必须项;后四项取决于目标场景与售后能力。
3. 协议栈选型:三条路径
| 路径 | 优点 | 需要补的工作 |
|---|---|---|
| 自研 | 完全可控,可按产品裁剪 | 标准覆盖面大,网络管理与边界场景的实现代价高 |
| 商用栈 | 有认证支撑,边界场景处理较完整 |