企业官网建设流程全解析

搞功能安全这行的朋友，应该都有过这种经历：客户指着机柜里那台安全PLC问，“你们急停按钮的信号从现场走到柜子里，中间用的什么通讯？万一这根线受干扰，急停还灵不灵？”说实话，十年前我遇到这种问题还得先解释半天“安全继电器为什么比普通PLC可信”，而现在答案变得很直接：FSoE。FSoE全称Fail Safe over EtherCAT，就是跑在EtherCAT总线上的故障安全通信协议。今天这篇文章我不打算从协议栈第一行讲起，而是从一个知识库条目“FSoE之白通道的应用领域”切入，把白通道这个概念到底指什么、实际用在哪、怎么配置、出了故障怎么查，一次说清楚。无论你是刚接触安全控制的新手，还是正在做产线安全方案的老手，这篇文章对你应该都有点参考价值。

1. 先把FSoE和“白通道”这两个词掰开揉碎

1.1 FSoE到底是什么：安全协议里的端到端保镖

FSoE最早由倍福联合TÜV Rheinland开发，如今已经是EtherCAT技术组（ETG）的官方安全规范。它解决的问题特别实在：让一根普通工业以太网线，既能跑运动控制、普通IO、参数上传下载这些标准EtherCAT数据，又能同时跑急停、安全门、光栅、安全限位这些“出了事要命”的安全信号，而且安全信号全程不怕干扰、不怕丢包、不怕数据被篡改。

这里有个关键认知必须先建立起来：EtherCAT这套总线本身不提供任何功能安全保证。它的强项是实时性好、同步精度高，但一个伺服报文里的某个位翻转了，它顶多就是报个错重传一次，对运动控制来说问题不大。但急停信号就不能这么宽容。急停按钮被按下去，要是信号在这根网线上被干扰翻转了，或者因为网络拥堵晚到了几十毫秒，轻则设备损坏，重则直接威胁人身安全。FSoE做的事情，就是在EtherCAT这层“普通快递运输网”上面，再加一道带保险的专线服务，让接收端有足够自信说：“这包安全数据我可以放心执行，触发停车就停车。”

我在项目里常跟客户用一句话概括这个逻辑：FSoE不负责让网络变得更好，它负责让安全应用不怕网络变坏。你放的急停按钮信号哪怕经过了一段电磁环境很差的线缆，FSoE依然能识别出这包数据是不是“原装的、完整的、按顺序到达的”。这份自信不是靠祈祷现场不出干扰，而是靠一套完整的检测机制硬扛出来的。

1.2 白通道与黑通道：一条物理链路里的两股车道

理解了FSoE的定位，白通道就很好讲了。这里说的“白通道”和网络安全里那种“防火墙白名单”完全不是一回事。在功能安全通信领域，我们习惯把同一条物理链路里传输的数据分成两类：

普通过程数据、参数数据、诊断数据，这些数据没经过任何安全机制额外保护，直接塞进EtherCAT报文里头传，这个路径我们叫黑通道。它“黑”不是说数据见不得光，而是说它不承担安全责任。伺服的位置给定、速度指令、设备温度、产量计数，丢了或者错了一个bit，系统顶多性能波动或者重启恢复，不会造成安全事故。

而安全急停、安全门状态、光栅遮挡信号、安全停止速度反馈，这些数据经过FSoE协议层封装，加了CRC校验、序列号、看门狗、连接ID这些安全保险之后，再放进EtherCAT报文里传输，这条路径就是白通道。白通道的“白”，代表的是可信、可验证、有保障。

一个比较形象的类比：同一辆货车（EtherCAT帧）上，一批普通货物随便码在车厢里，叫黑通道；另一批贵重的危险品，先经过安检、贴封条、上保险、专人押运，再放上车，这就是白通道。FSoE组的货物走的是白通道，就算路上的颠簸让包装蹭破点皮，收货方也能通过封条识别出来“这箱东西被动过手脚”，直接拒绝签收，触发安全处理。

1.3 为什么白通道值得单独研究

很多人刚接触EtherCAT安全方案时会有一个疑问：既然安全数据也在同一根网线上传，凭什么它就比普通数据可信？答案就在白通道的完整机制上。

FSoE为每个安全连接分配了独一无二的连接ID（F_ Slot），就像给这条白通道起了个只有收发双方认识的暗号。每一包安全数据里都带一个连续递增的序列号，专门防止攻击性的数据重放或者总线乱序。每包数据还带有一套专为功能安全设计的CRC校验算法，和普通CRC不一样，它的多项式经过安全认证，能把通信故障导致的位翻转识别率做到足够高。再加上收发双方各自运行看门狗，超时立即判定连接失效。

这几层保险叠加起来，白通道的本质就是一种“端到端完整性保护”。什么叫端到端？就是说安全PLC发出一个急停信号的“确认”，和远端安全IO模块最终收到的“确认”，整个保险过程贯穿始终，中间无论经过多少个EtherCAT从站、多少米网线、多少个耦合器，保护都不打折扣。这也是为什么设备厂商敢把安全功能直接做到分布式IO上，而不是把所有安全信号都硬拉回控制柜里的安全继电器。

了解了白通道的底细，接下来最重要的部分是：它在现场到底用在哪些场合。

2. FSoE白通道到底用在哪些场合

2.1 安全PLC与分布式安全IO：急停链路的“高速公路”

最典型的应用场景，就是分布式安全IO。汽车焊装线、包装机械、注塑机这类设备，安全输入点和安全输出点往往散布在整机各个位置。传统方案是把所有急停按钮、安全门开关的触点用硬线拉到控制柜里的安全继电器或者安全PLC，一整套下来线缆粗、走线长、排查故障也麻烦。

用了FSoE白通道之后，现场直接安装安全IO模块，比如倍福的EL1904安全输入端子、EL2904安全输出端子，它们都内置FSoE从站协议。急停按钮的常闭触点接在EL1904上，安全PLC通过FSoE周期性读取这个输入状态，逻辑判断后，再通过FSoE把输出命令写到EL2904，去控制主接触器或者驱动器的STO端子。这根白通道替代的，就是从前那束几十米长的安全硬线。

这种方案的收益很实际。第一是接线量大幅下降，安全信号不用再绕回主控柜；第二是系统扩展灵活，新增一个安全输入点，只要在总线上挂一个安全模块，再更新一下安全逻辑就行，不用重新放电缆。第三是诊断能力强，硬线急停出了问题只会看到“断线”，FSoE能把连接状态、通信质量、故障原因全部上报，现场人员不用拿着万用表一段段去摸线。

我在汽车零部件产线上就见过这样的案例：整条线有四十多个急停按钮分布在四个工位上，原来是40对双芯屏蔽线直接拉回柜子，光是穿管就花了整整三天。后来改成EtherCAT总线加四组安全IO模块，一天就把所有急停信号接完并完成了安全功能测试。验收的时候安全评估师还说，这种带通信诊断的方案，比纯硬线还多了一层可追塑性。

2.2 机器人工作单元：安全门、光栅与STO的默契配合

机器人安全围栏是FSoE白通道的另一个主场。你去看现在主流的机器人控制柜，安全功能的标配是STO（Safe Torque Off，安全转矩关断）。机器人控制器、示教器、外围安全PLC之间怎么协同，很大程度上依赖FSoE。

典型的工作单元是这样的：机器人被安全围栏围起来，围栏入口装有安全门锁开关，内部装有安全光栅，机器人本体上有STO接口。安全门打开或者光栅被遮挡的瞬间，围栏内人员可能进入机器人工作范围，这时候要求机器人的驱动动力必须立刻切断。

如果用FSoE白通道实现，安全门开关接到安全输入模块，光栅的OSSD输出也接到安全输入模块，机器人控制柜里的安全输出模块通过FSoE接收安全PLC的信号，去控制机器人驱动器的STO。整个过程中的“门开了”“光栅挡了”“STO动作了”每一步都能被安全PLC记录，而且因为白通道的延迟是可预测的，设计者可以准确算出从门锁打开到机器人动力切断的总时间，这个时间在安全验证报告里是实打实的参数。

做这类项目时我有个习惯：安全输出模块控制STO的回路，一定选带反馈回读功能的型号。也就是说，安全PLC发出STO命令后，还要通过另一路输入确认驱动器确实已经进入安全状态。这个反馈信号同样走FSoE白通道。这样一来，即使驱动器侧继电器卡死或者线缆断路，安全系统也能在下一个周期内发现异常并停机。别小看这个细节，实际现场出过的绝大多数“光栅动作了驱动还在动”的案例，罪魁祸首都是反馈回路没做。

2.3 AGV与移动平台：无线场景下的安全通信

AGV和移动机器人这两年几乎是工厂自动化的标配，它们的通信场景比固定设备更复杂。AGV运行过程中，车体和地面控制柜之间没有固定的硬线连接，常规做法是用无线通信。这带来一个非常尖锐的问题：无线信道的干扰、丢包、延迟抖动比有线网络高一个数量级，怎么把安全信号可靠传过去？

针对有安全需求的AGV，FSoE白通道可以覆盖两类场景。一类是AGV本体内部的安全逻辑，比如激光雷达的紧急避障信号、防撞条信号、急停按钮信号，通过车体内部的安全IO模块采集，经FSoE送到车载安全PLC，再控制驱动器的STO；另一类是车体和调度系统之间的安全握手，比如进入危险区段前接收到“允许通行”信号，这个信号如果走普通无线通信，谁也不敢保证它不会丢包或者被错误数据顶替，而走FSoE白通道，接收端可以通过连接ID和序列号确定信号来源和新鲜度。

需要明确的是，普通WLAN这类非确定性传输介质本身不在标准FSoE直接支持范围内，实际项目更常见的做法是在AGV运行区域布置滑触线或者轨道，FSoE运行在一个确定性的有线骨干上，AGV车体通过机械触点接入。对于一些采用专用实时无线方案的供应商，FSoE也能通过隧道方式跑在厂家封闭的无线帧中。这里我的建议是：除非你非常清楚无线链路的最差情况延迟和丢包率，否则不要在安全相关应用中直接裸奔无线FSoE。见过不少项目栽在“无线信号看着挺好，但一台叉车路过干扰一下安全链路就断了”这种场景上。

2.4 大型设备与过程控制中的安全联锁

白通道在连续型生产设备上的应用，往往体现为区域化、模块化的安全联锁网络。典型的有印刷机械、瓦楞纸生产线、食品饮料灌装线、橡塑挤出线。这类设备的特点是长：从头到尾几十米，中间被分成很多工段，每个工段都有防护罩、检修门、急停拉绳。

老方案里，每个工段的安全信号都汇总到总控制柜的一台安全PLC，西边工段的门开关要拉到东边柜子里，中间还要跨过分断点。用FSoE白通道之后，可以把安全控制分散成若干个逻辑分区：每个分区分一台小型安全PLC或者安全端子站，分区之间再通过网络交换安全联锁信号。比如前面工段卡料停机，后面工段应该自动进入安全停车状态，这个“降速滑行到停止”的联锁信号就走分区之间的FSoE白通道传送，保证两端逻辑一致。

这种方案对设备厂商还有一个隐形好处：出厂调试时每个工段可以单独上电调试安全功能，不用等整条线全部装配完。因为FSoE白通道支持模块化组网，每个模块独立跑通安全回路，最后拼装起来时再联调跨工段的安全互锁即可。工程上省下的调试时间，往往比省下的硬线时间还珍贵。

另外，在过程控制领域，FSoE白通道还可以承担安全联锁PLC与现场仪表安全数字量之间的通信。比如高温高压管道上的安全切断阀，阀位的安全反馈信号经安全IO模块，通过FSoE送到安全PLC做联锁判断，整个过程满足IEC 61508的功能安全等级要求，这在国内外的化工、制药项目里已经有成熟应用。

3. FSoE白通道的组态配置与实操要点

3.1 硬件方案怎么选：从安全耦合器到安全端子

选硬件首先要看清供应商提供的安全产品家族。以最常见的TwinSAFE体系为例，安全IO端子如EL1904（安全输入）和EL2904（安全输出）直接挂在EtherCAT总线上，它们自身就是FSoE从站。如果现场需要把一套独立的第三方安全继电器系统接入FSoE网络，可以使用安全耦合器，比如EL6930，它相当于一座“翻译桥”，把安全继电器回路的硬线触点状态包装成FSoE报文，再送到安全PLC。

选型时有几条硬性条件可以背下来：第一，安全输入模块的通道数量和输入极性必须匹配实际开关类型，急停按钮、安全门锁开关大多是PNP常闭型，也有设备用NPN或者干接点，选错了极性安全回路永远无法进入正常运行状态；第二，安全输出模块的输出类型要和被控对象匹配，比如直接控制主接触器线圈，就要注意输出回路的电流承载能力，必要时经过中间继电器；第三，安全PLC的等级要和设备风险评估结果匹配，不要盲目追求高性能参数，ISO 13849的PLd级和PLe级差价不小，按实际风险定。

很多刚上手的人会忽略一点：安全IO端子本身需要额外供电。EL1904这类模块除了总线供电，通常还要接一个24V传感器电源。这个电源的可靠性直接关系到安全回路是否稳定。我有个不改的习惯，整个白通道涉及的安全IO供电一律从经过隔离的、带有诊断的电源模块引出，而且接入方向做成菊花链式供电，避免单点故障影响整条安全链路。

3.2 一个完整的白通道组态流程（以TwinSAFE为例）

用倍福TwinSAFE工具组成FSoE通信回路，我通常按下面这几步走，整个流程不复杂，但顺序错了后面就要走弯路。

首先，在TwinCAT System Manager里扫描EtherCAT总线，确认所有安全IO模块和安全PLC都被正确识别。扫描后每个安全模块都会注册一个FSoE设备节点，每个节点都会分配一个16位的FSoE地址，这个地址后续要严格和各模块地址拨码或者软件配置对应上。地址不匹配是白通道起不来的头号原因。

第二步，创建安全逻辑工程。TwinSAFE逻辑里添加需要参与联锁的安全输入点、安全输出点，然后写安全程序。安全程序的语言和普通PLC有类似的地方，但规则更严格，比如不允许使用非安全的全局变量做安全判断，不允许安全程序和标准程序共享未经认证的内存数据。逻辑块通常有安全功能块可用，比如急停监控块、门锁监控块、双手控制块、光栅监控块，直接把安全触点接入后配置参数即可。

第三步，配置FSoE连接参数。每条白通道本质上是一个FSoE连接，需要把安全PLC侧的一个FSoE连接和远端安全模块上的一个FSoE连接绑定在一起，两边设置匹配的连接ID。同时要设置看门狗时间，一般默认在100ms级别，但实际项目要根据EtherCAT周期和刷新时间调整，设置太长安全反应速度慢，设置太短容易误报断线，我一般先按默认值跑起来，再在实际工况下根据通信余量微调。

第四步，编译并激活安全工程，然后把安全逻辑下载到安全PLC中。这一步完成后，在工具里能看到FSoE连接的状态从INIT经过SESSION进入DATA，这就是白通道打通了。DATA状态下通信正常，安全数据按周期刷新。

最后一步，也是最容易被忽略的一步：做完整的安全功能测试。白通道组态完成不代表安全功能合格。要逐个验证每个急停动作、每扇安全门打开、每道光栅遮挡，都能在预期时间内触发目标输出，并且验证报警恢复后系统能够安全复位。这些测试记录要存档，作为后续安全评估的证据。

3.3 必须盯死的四个关键参数：看门狗、CRC、连接ID、状态机

FSoE白通道工作是否正常，最终体现在几个协议参数上。这里逐个说清楚它们是什么、作用是什么、现场怎么看。

第一个是看门狗时间。FSoE连接上收发双方各有一个通信看门狗，接收端如果在设定时间内没有收到新数据包，就会判定安全连接失效，输出进入安全状态。看门狗时间设置很有讲究，它必须大于最坏情况下的通信抖动周期，但又必须小于安全功能要求的反应时间。举例说，PLC安全程序周期4ms，EtherCAT周期2ms，FSoE报文每周期刷新一次，通信看门狗默认100ms是完全足够的。但如果系统要求“门一开50ms内动力切断”，那你得把总反应链路里的所有环节算清楚，看门狗时间占据的一部分必须预留足够余量。

第二个是CRC。FSoE使用的CRC不是随手写个多项式就算数，它是经过功能安全认证的算法，能检测出常见通信故障尤其是多比特错误。CRC测出的错误数会随着时间累积，我们可以从工具里读出诊断计数器。如果CRC错误计数持续增长，就意味着白通道上有严重的电磁干扰或者物理层异常。出现这种情况，先别急着怀疑软件，去查布线、屏蔽和接地才是正解。

第三个是连接ID。每个FSoE从站占一个F_ Slot，主站和从站建立连接时必须使用匹配的ID。它的作用有点类似楼房里对讲机的房号，只有拨对房号才有人应答。连接ID配置错是刚上手学员最容易犯的错误，典型现象是在工具里看到FSoE连接始终卡在INIT状态，任何安全数据都不交换。

第四个是状态机。FSoE连接有明确的运行状态：INIT是初始状态，SESSION是握手协商，DATA是正常交换，ERROR是检测到异常。排查问题的第一件事永远是看当前状态卡在哪一步。卡在INIT查地址和连接ID配置，卡在SESSION查握手超时和CRC失配，运行中频繁跳ERROR查看门狗时间和物理层质量。状态机就是FSoE的“病历首页”，哪里不舒服一目了然。

4. 白通道的故障排查与经验速查

4.1 急停按下但设备不停：先看FSoE状态机

真到了现场，最要命的故障就是“急停按下去了，设备还在跑”。遇到这种情况，大部分人第一反应是怀疑安全PLC程序写错了，其实FSoE白通道项目里，这类故障真正出在通信机制上的概率不低。

排查第一步，打开TwinSAFE工具查看FSoE连接状态。如果连接在DATA状态正常，说明从急停输入到安全PLC这节白通道是通的，问题很可能在逻辑判断或者安全输出侧。接下来就要看输入模块上对应的通道信号是否已经翻转，如果输入点灯已经变化而安全PLC里看到的还是旧值，八成是安全逻辑工程没有重新下载，或者急停信号没有映射到安全程序里。

如果FSoE连接已经跳到ERROR状态，问题就复杂一些。这时候安全PLC为了保险，默认会切断所有安全输出，设备按理应该停下来。可如果实际设备没停，那就要把注意力转移到安全输出之后的部分，比如EL2904的输出触点是否真实断开、中间继电器的线圈供电是否异常、接触器是否因为粘连而无法断开。这种层层叠加的排查思路，我给它起了个名字叫“从通信到功率逐级取证”，每一级都要有实测数据支撑，千万别隔着两级去猜中间环节。

4.2 通信频繁中断：EMC和布线才是最大嫌疑

FSoE白通道跑得好好的，隔一段时间就报一次断线，过一会又自动恢复。这种“癫痫式”故障最耗人精力。很多工程师上来就调看门狗时间，把100ms改成500ms，表面看断线次数少了，实际上是掩耳盗铃，把通信质量问题硬压成了隐性隐患。

我遇到过的这类故障，十有八九出在布线和接地环节。EtherCAT网线虽然用了工业级屏蔽双绞线，但屏蔽层接地如果悬空，在变频器、伺服驱动器旁边就是一根完美的天线。查这类问题有个高效办法：把通信故障的CRC错误计数清零后观察增长曲线，如果错误计数和设备的升降速、机器人加减速动作有相关性，那基本锁定是动力线缆的电磁干扰通过耦合窜进了通信链路。解决办法不外乎三件事：网线屏蔽层在PLC侧和模块侧都可靠接地，动力线和网线分开走线槽明显拉开距离，必要时换用带金属铠装的工业以太网线。

还有一次排了一下午才发现的坑，是某个从站模块内部因为长期高温导致供电不稳，使FSoE报文频繁丢失。所以遇到间歇性断线，别忘了给所有安全模块测一遍现场供电电压，确认电压波动范围是否在允许区间内。供电不稳引发的通信故障，光靠通信侧诊断是查不出来的。

4.3 地址与槽位配置的“低级错误”清单

在FSoE项目里，大量让人哭笑不得的停机故障属于配置类错误。我把这些年踩过的和看别人踩过的坑整理成了一张速查表，每次现场排查都按这个顺序过一遍，效率提高很多。

第一个是FSoE地址重复。EtherCAT总线上两个模块被配置成了同一个FSoE地址，主站建立连接时就会冲突，表现是一个连接能起来，另一个连接永远起不来。解决办法是给每个模块编好唯一地址，并在模块端子上贴标标注。

第二个是安全模块插错槽位。有些项目现场把EL1904和EL2904插反了，因为外形非常接近，而且都是挤在一排端子模块里。它们的FSoE功能完全不同，插反之后安全输入信号全部失效，通信虽然看着正常，但逻辑判断永远读不到正确输入。

第三个是急停和安全门开关的常开常闭类型配置错误。FSoE安全模块的输入滤波和类型配置必须和机械触点的标称一致。配置成常闭的急停，如果实际是常开，系统上电后会立即诊断为输入链接故障，要么一直报错，要么无法复位。遇到这种问题，别急着怀疑模块损坏，先看工具里输入通道的实时状态和配置是否相符。

第四个是安全程序和安全模块固件版本不匹配。新批次的安全IO模块可能更新了固件，安全PLC还是老版本协议，FSoE握手时CRC校验算法不兼容，连接就是进不了DATA。排查这类问题时，把工具里弹出的FSoE协议版本号和模块规格书对比一下，往往能一锤定音。

这四条错误清单看着都很初级，但我在不同项目里已经见过至少十次。很多时候功能安全验收卡壳，卡的不是什么高深理论，就是这些每个人都觉得自己不会犯的低级配置问题。所以后来我给自己定了个习惯：任何FSoE白通道项目验收前，强制用工具导出一份完整的FSoE连接参数清单，和现场配线表逐项核对。

5. 从白通道延伸出去：完整的安全通信设计心得

5.1 白通道不是孤岛：安全逻辑与运动控制的时序配合

FSoE白通道应用得好不好，不只是安全专业一个领域的事，它和运动控制系统的配合极其关键。比如一个伺服轴的STO动作，触发后驱动器立即切断转矩，但如果此时机械结构正在高速移动，直接切断动力可能导致物料飞出或者机械冲击。所以在很多设备上，急停触发后的反应不是“立即零速”，而是“先减速到安全速度再切STO”，这就需要在标准EtherCAT通道（黑通道）里让运动控制器执行一个安全停止曲线，同时让安全PLC通过白通道监控轴的实时速度，等确认速度低于安全阈值后，再允许STO动作。

做这种时序配合时，我通常会把安全逻辑里加一条“速度确认”信号，来自伺服驱动器的安全速度监测功能（SS1或者SLS功能），通过安全通信传回安全PLC，作为STO触发的使能条件。这样一来，白通道承载的不仅仅是简单的开关量急停信号，还承载了安全速度这类过程量级别的安全数据。FSoE在这方面有一个很实用的特点：它能在一个连接里同时传输多个安全数据对象，你可以定义急停状态、门锁状态、速度反馈、复位请求等一堆变量同时刷新。

实际开发中，最好在项目一开始就让电气工程师和软件工程师坐到一起，把安全链路响应时间和运动控制响应时间画在一条时间轴上，确保每个环节的延迟贡献都被记录。我在帮客户做安全方案评审时，最常改的评审意见就是：安全反应时间算得很漂亮，但漏了运动控制器执行减速曲线的本身时间。白通道只负责安全数据的交换逻辑，设备最终的物理反应时间是整个链路的和。

5.2 安全等级与认证：别让白通道白费

最后聊一个经常掉进去的认知陷阱。很多人觉得用了FSoE白通道，设备的安全等级就是PLe、SIL 3了，大错特错。FSoE这条通信通道本身是经过TÜV认证的，它满足的是安全相关通信的传输要求，但整个安全功能回路的等级，取决于传感器、逻辑、执行器、以及设计过程的整体可靠性。

举个例子，你的安全PLC和执行机构之间走的是FSoE白通道，通信环节的可靠性足够高，但急停按钮本身如果只用了普通行程开关而不是经过安全认证的急停按钮，整条回路的PFHd（每小时危险失效概率）照样不合格。同样，安全输出侧的接触器如果用了普通接触器，没有做强制导向或者反馈监控，安全等级依然会有缺口。功能安全是木桶理论，白通道只是其中一块质量过硬的木板，不是跳板。

所以每次做完白通道配置，我建议额外做一遍安全回路完整性检查，把传感器、逻辑、通信、执行器、供电每个环节的失效率数据填到评估表里，看看最终计算出的安全等级是否达到目标PL或者SIL。这也是第三方安全评估师来验收时必然会查的资料。不要等到验收当天才做，项目初期就按这个思路把清单列好，整个设计过程都会少走很多弯路。

最后再分享一个个人习惯：每次在FSoE白通道上做完一个安全功能回路，我都会在工具里截图保留连接状态、看门狗参数、CRC诊断计数，连同安全程序的版本号一起归档。设备运行半年后如果出现安全性投诉或者功能变更，这些看似不起眼的记录能帮你快速定位问题是不是从最初组态时就带进来的。这套资料甚至比最终的调试记录还顶用。搞安全这一行，扎实的过程记录，本身就是功能安全的一部分。