4、PROFINET协议栈集成：p-net栈源码分析、设备角色配置、实时数据通道建立、诊断与报警处理
PROFINET 在工控圈子里地位很特殊。它不像 Modbus TCP 那样随便抓个 socket 就能跑，也不像 EtherCAT 那样对硬件有近乎苛刻的要求。它是个「既要实时性、又要 IT 兼容性」的协议。说白了，它想在标准以太网上跑出工业总线的确定性。
我最早接触 PROFINET 是在一个汽车焊装线的项目里。甲方要求网关必须同时支持 RT 和 IRT 模式，而且诊断报文要能直接上到他们的西门子 SCADA。那时候市面上能用的开源栈不多，p-net 算是为数不多能打的一个。今天我们就把它拆开看看。
4.1 p-net 栈源码结构
p-net 是西门子工程师用 C 写的一个开源 PROFINET 协议栈。它不依赖操作系统，可以在裸机上跑，也可以移植到 Linux 上。我习惯把它看作三层：
- 底层（Port Layer）：负责以太网帧的收发，直接操作网卡驱动或 raw socket。
- 中间层（Stack Core）：处理 DCE/RPC、LLDP、PTCP 等协议，维护连接状态机。
- 应用层（Application Layer）：提供 API 给用户，处理 GSDML 配置、IO 数据交换、报警等。
源码目录结构大致如下：
p-net/
├── pnet_api.h # 应用层 API 头文件
├── pnet_api.c # API 实现
├── pnet_eth.c # 以太网帧收发
├── pnet_dcp.c # 发现与基本配置协议
├── pnet_ptcp.c # 精确时间同步协议
├── pnet_cmrpc.c # DCE/RPC 连接管理
├── pnet_alarm.c # 报警处理
├── pnet_diag.c # 诊断处理
└── examples/ # 示例工程
每个模块的职责很清晰。我最喜欢的是它的状态机设计——每个连接都维护一个有限状态机，从 INIT 到 DATA_EXCH 再到 ABORT，每一步都有明确的超时和错误处理。
核心要点：p-net 栈不处理硬件实时调度，它只负责协议逻辑。真正的实时性（比如 IRT 的等时同步）需要底层网卡和驱动配合。这一点很多初学者会搞混。
4.2 设备角色配置
PROFINET 网络里有三种角色：IO Controller、IO Device 和 IO Supervisor。我们的工控网关通常扮演 IO Device，也就是从站。但有时候也需要做 Controller，比如在边缘侧直接控制现场设备。
配置角色时，p-net 需要你提供一份 GSDML 文件。这份 XML 描述了设备的能力：支持的子模块、输入输出数据长度、诊断通道、报警类型等。我建议你直接用 p-net 自带的示例 GSDML 改，别从头写——那玩意儿光命名空间就能把人绕晕。
角色配置的核心代码在 pnet_api.c 里：
pnet_cfg_t cfg = {
.device_role = PNET_DEVICE_ROLE_DEVICE,
.station_name = "gw-profinet-01",
.vendor_id = 0x1234,
.device_id = 0x5678,
.num_subslots = 4,
.subslot_cfg = subslot_configs
};
pnet_init(&cfg);
这里要注意 station_name 必须和 DCP 工具里设置的名字一致。我在现场遇到过好几次，代码里写的是 "gateway-01"，但西门子的 PLC 那边认的是 "Gateway-01"——大小写不匹配，死活连不上。嗯，PROFINET 的名字解析是大小写敏感的。
| 参数 | 说明 | 常见坑 |
|---|---|---|
| device_role | 设备角色：DEVICE / CONTROLLER | 选错角色会导致连接被拒 |
| station_name | 站名，DCP 发现用 | 大小写敏感，不能有空格 |
| vendor_id | 厂商 ID，需向 PI 申请 | 测试时可用 0x1234 占位 |
| num_subslots | 子模块数量 | 必须与 GSDML 一致 |
我的习惯：在开发阶段，我会把 station_name 做成可配置的，通过命令行参数或配置文件传入。这样不用每次改代码重新编译，调试效率高很多。
4.3 实时数据通道建立
PROFINET 的实时数据通道分两种：RT（实时）和 IRT（等时实时）。RT 走标准以太网帧，优先级用 VLAN 标签控制。IRT 则需要硬件支持，在特定的时间窗口内发送数据，保证抖动在微秒级。
p-net 默认支持 RT。建立数据通道的流程是这样的：
- 连接建立：Controller 通过 DCE/RPC 发起连接请求，Device 回复确认。
- 参数协商：双方交换 IO 数据长度、发送间隔、看门狗时间等参数。
- 数据交换：进入 DATA_EXCH 状态，周期性收发 IO 数据。
- 连接监控：通过看门狗检测连接是否中断。
代码层面，数据通道的回调函数是关键：
// 数据接收回调
void pnet_data_ind(pnet_t *net, uint32_t api, uint16_t slot,
uint16_t subslot, uint8_t *data, uint16_t len) {
// 处理来自 Controller 的输出数据
memcpy(output_buffer, data, len);
}
// 数据发送请求
void pnet_data_req(pnet_t *net, uint32_t api, uint16_t slot,
uint16_t subslot, uint8_t *data, uint16_t len) {
// 填充输入数据，发送给 Controller
memcpy(data, input_buffer, len);
}
我曾经在一个项目中遇到数据丢包的问题。排查了很久，最后发现是看门狗时间设置得太短——Controller 那边默认是 500ms，我这边设了 200ms，结果网络稍微波动一下就被踢出连接了。后来我把看门狗时间统一设为 1000ms，问题解决。
注意：看门狗时间不是越长越好。太长会导致故障检测延迟，可能引发安全事故。一般建议设为发送间隔的 3-5 倍。
4.4 诊断与报警处理
PROFINET 的诊断机制很完善。每个子模块都可以上报诊断信息，Controller 端通过 DCE/RPC 读取。报警则分为两种：
- 诊断报警（Diagnosis Alarm）：设备状态变化时触发，比如传感器断线、温度超限。
- 过程报警（Process Alarm）：由用户自定义，用于通知特定事件。
p-net 的报警处理在 pnet_alarm.c 里。上报一个诊断报警的流程如下：
pnet_alarm_send_diag(net, api, slot, subslot,
PNET_DIAG_CHANNEL_TYPE_INPUT,
PNET_DIAG_CHANNEL_NUMBER_1,
PNET_DIAG_SEVERITY_FAULT,
PNET_DIAG_CODE_OPEN_CIRCUIT);
这里 severity 分三种：FAULT（故障）、WARNING（警告）、INFO（信息）。diag_code 则对应具体的故障类型，比如开路、短路、超限等。这些码在 GSDML 里定义，必须和 PLC 侧一致。
诊断信息的读取是 Controller 主动发起的。Device 端只需要维护一个诊断缓冲区，当 Controller 来读时返回即可。p-net 内部用链表管理诊断条目，支持多条同时存在。
| 报警类型 | 触发条件 | 处理方式 |
|---|---|---|
| 诊断报警 | 设备状态变化 | 自动上报，Controller 确认 |
| 过程报警 | 用户自定义事件 | 需调用 API 手动触发 |
| 拔出报警 | 子模块被移除 | 硬件检测或软件模拟 |
避坑指南：我曾经在调试诊断报警时，发现 PLC 那边收不到报警。查了半天，原来是诊断缓冲区满了——p-net 默认只缓存 10 条诊断信息，超过的会被丢弃。后来我把缓冲区大小改成了 50，并且在上报新诊断前先清除已确认的旧条目。
4.5 整体架构图
下面这张图展示了 p-net 栈在工控网关中的位置，以及各模块之间的数据流关系。
从这张图可以看得很清楚：p-net 栈把硬件细节封装在底层，上层用户只需要关注 API 回调。数据流是单向的——从网卡到用户应用，再反向回去。诊断和报警则走独立的通道，不影响主数据流。
嗯，到这里 PROFINET 协议栈集成的核心内容就差不多了。p-net 是个好栈，但用好它需要你对 PROFINET 协议本身有足够的理解。我建议你在集成之前，先拿 Wireshark 抓包看看正常的 PROFINET 通信是什么样的——这样出了问题才知道往哪个方向查。