这两年我经手的工控产品送检项目里最绕不开的一个词就是GB/T 42456。很多自动化厂商第一次听到“SL评测认证”都会愣一下以为是某个新出的安全标准体系或者跟SIL认证有什么重复。实际上GB/T 42456-2023《工业过程测量、控制和自动化 功能安全与信息安全框架》是2023年正式实施的国家标准它不替代GB/T 20438也不替代网络安全等级保护而是把“功能安全”和“信息安全”这两条线在工业自动化系统层面拧在了一起。对于做PLC、DCS、伺服驱动、网关、软PLC这类产品的团队来说基于这个标准的SLSafety Level评测认证正在成为进入高端装备、能源、冶金等项目的隐形门槛。这篇文章我主要结合自己送检软PLC控制器的经验把“基于GB/T 42456的工控产品SL评测认证”拆开讲清楚标准本身怎么理解、认证流程怎么走、送检产品到底要准备什么再附带一个很多同行都在问的实操场景——Codesys Control RTE SL软PLC下如何配置EtherCAT主站。无论是准备送检的认证工程师还是刚接触软PLC开发的朋友这篇应该都能帮你少走不少弯路。1. GB/T 42456到底在评什么先别急着把SL和SIL划等号1.1 标准出身从IEC 63069到国标本土化GB/T 42456-2023的底子是IEC 63069:2019《工业过程测量、控制和自动化 功能安全与信息安全框架》。这个标准的核心思路用一句话概括就是在工业自动化系统里功能安全防止设备故障造成人身伤害或环境事故和信息安全防止网络攻击、非法操作造成系统异常不能各管各的必须在系统生命周期里统一考虑、统一评估、统一管理。为什么会出这样一个框架标准因为早期很多产品做安全设计时功能安全团队和信息安全团队是分开的。功能安全考虑了故障模式和失效率却没考虑黑客可能通过网络非法触发某些安全功能信息安全团队做了防火墙和加密却可能因安全策略太激进导致安全联锁回路响应延迟。GB/T 42456的存在就是把这两者拉到同一张桌子上对话。实际送检时认证机构一般会参考这个标准的框架再结合IEC 61508电气/电子/可编程电子安全相关系统的功能安全和IEC 62443工业自动化和控制系统信息安全的具体技术指标来展开评估。所以你在准备材料时别只盯着GB/T 42456这一份文档相关配套标准一定都要梳理到。1.2 SL和SIL的爱恨纠葛在GB/T 42456语境下SL通常指的是Safety Level即安全等级。但它和SILSafety Integrity Level安全完整性等级不是完全等同的概念。SIL来自IEC 61508是一个有严格数学定义的东西。它通过量化安全功能在单位时间内的失效率将安全完整性划分为SIL 1到SIL 4四个等级每一级都有对应的PFD需求时平均失效概率或PFH每小时危险失效概率范围。SIL等级高不高最终要落到失效率数据和硬件架构约束上这个是很硬的指标。而GB/T 42456框架里的SL更偏向于系统层面的综合安全能力。它考察的是产品在功能安全与信息安全协同机制下的整体表现比如安全通信协议是否在遭受网络干扰时还能保证实时性安全功能是否会被非法指令覆盖故障诊断是否覆盖了因网络攻击引发的新故障模式。很多国内第三方检测机构在做SL评测时会把SIL的等级粒度搬过来用最终给出类似“SL 2”这样的结论但它的含金量更多体现在功能安全与信息安全的融合设计上。顺便提醒一句Codesys系列里有个常见的产品叫Codesys Control RTE SL这里的SL是Single License单机版授权的缩写跟安全等级不是一个意思。别在技术交流时把两个SL混为一谈我见过不止一次因为这个名字引发的乌龙。1.3 哪些项目开始强制要求SL评测认证目前从项目端反馈看能源、轨道交通、冶金、化工等对安全生产要求极高的行业已经开始在招标文件里明确要求“关键控制系统需提供依据GB/T 42456的SL评测报告或认证证书”。一些大型装备出海项目也会把这个作为功能安全和网络安全合规的加分材料。对厂商来说这个认证的价值不只是拿一本证书它还能反向倒逼研发团队把功能安全和信息安全的接口设计规范化。很多产品在做完SL评测后最大的收获是发现了一批“在异常网络工况下安全功能响应异常”的隐患这类问题在传统纯功能安全测试里几乎测不出来。2. SL评测认证流程拆解从材料准备到拿证的时间线2.1 送检前要准备哪些材料我梳理一份通用的材料清单大家对照着准备不同机构可能会有微调但大方向是一致的材料类别具体内容备注产品基础信息产品型号、硬件版本、软件版本、功能规格书、用户手册版本必须和送检样品完全一致功能安全文档系统架构图、安全功能清单、故障模式分析FMEA/FMEDA、安全生命周期文档涉及SIL等级要求的需附计算书信息安全文档威胁模型分析、网络架构图、端口与服务清单、通信协议说明、安全配置指南列清默认口令策略、端口开放情况开发过程文档开发流程说明、配置管理记录、测试报告、变更记录体现研发过程的规范性样品与工具送检样机、调试软件、编程电缆、加载程序、特殊工具一般要求两套以上样品其他营业执照复印件、产品合规声明、授权委托书委托第三方检测时需盖章这里要特别强调材料里的“版本一致性”是机构老师最看重的。你手册上写的通信协议版本和样机里的实际固件对不上第一次开评审会就会被质疑轻则补充材料重则推迟测试周期。2.2 技术评估环节功能安全与信息安全交叉评审技术评估是整个SL评测认证中最核心的阶段评审组会分两条线并行开展。功能安全线主要看安全功能定义是否清晰安全完整性等级分配是否合理硬件架构是否满足所申报等级的约束诊断覆盖率有没有达标安全通信协议如PROFIsafe、CIPSafety、FSoE是否对非安全数据和网络攻击具备足够的鲁棒性。信息安全线主要看产品对外的攻击面有多大开放的端口和协议是否必需身份认证和权限控制是否到位安全日志是否完整固件更新机制能否防回滚以及在信息安全事件发生时安全功能能否继续保持可靠。这两条线的交集之处就是GB/T 42456真正发力的地方。评审老师通常会设置一些交叉测试场景比如模拟网络层持续丢包期间验证安全联锁的响应时间仍满足SIL要求在遭受暴力破解登录的同时确认安全功能不能被非授权指令触发或抑制。要是产品在设计阶段没有做过这类融合测试送检时大概率会暴露短板。2.3 型式试验与现场审核有哪些常见卡点型式试验一般包括环境试验高低温、湿热、振动、冲击、电磁兼容试验ESD、浪涌、射频骚扰、传导发射、电气安全试验绝缘、耐压、接地。这些项目在传统的CE、CCC认证里大概率都做过SL评测的额外之处在于试验过程中需要在信息安全措施开启和关闭两种状态下分别执行安全功能观察行为是否一致。现场审核则考察生产制造环节包括物料管控、产线测试项目、出厂检验记录、可追溯性、售后变更流程等。如果你之前没有过ISO 9001或者ISO/SAE 21434这类体系审核经验这一环可能要花点精力补记录。常见卡点包括关键安全元器件没有单独的来料检验记录、SMT贴片参数没有留档、固件烧录过程缺少校验记录这些在审核老师眼里都是体系不完善的表现。2.4 整个认证周期要多久结合我实际经历的项目给出一个大致的周期参考阶段预计周期说明合同签订与资料初审1~2周机构会先判断产品适用哪套评估方案技术评审文档沟通3~6周视产品复杂度而定复杂系统可能开多轮会实验室测试2~4周环境、EMC、功能、网络安全测试并行现场审核1~2天一般在实验室测试通过后进行问题整改与复测2~6周视问题严重程度浮动需预留时间证书签发1~2周之后会有年度监督或换证周期正常情况从签约到拿证大约3~5个月这是指材料齐全、问题不多的情况。如果第一次测试就暴露重大设计缺陷再花3个月整改也不奇怪。所以建议在产品量产前至少半年启动这个认证给整改留足余量。3. 送检产品里的常客Codesys Control RTE SL软PLC3.1 软PLC为什么在SL评测中越来越常见先解释一下Codesys Control RTE SL是什么。它是德国3S公司推出的基于PC或嵌入式系统的软PLC运行时。RTE是Real-Time Extension实时扩展的缩写SL在这里是Single License单机版授权。装了Runtime之后一台普通工控机或嵌入式板卡就能变成符合IEC 61131-3的控制器直接在Codesys开发环境中编写逻辑、调试运行。在SL评测认证的送检产品里基于Codesys软PLC的控制器占比很高。原因也很直白研发周期短、硬件成本低、生态成熟。很多企业做中高端控制器时底层逻辑不再自研而是用Codesys这套成熟的运行时把精力放在硬件设计、行业算法和应用驱动上。检测机构对于这类产品的评估也积累了整套方法既评估内置Runtime本身的安全性能也评估厂商在硬件层面、通信层面的安全设计。3.2 软PLC做安全评估的特殊性软PLC的SL评测比传统硬PLC多出几个特有难点硬件平台多样性。同样是Codesys Control RTE SL可以跑在x86工控机上也可以跑在ARM嵌入式板卡上。不同CPU、不同网卡、不同实时补丁策略都会影响实时性和安全性。认证时你需要固定送检的硬件配置并在文档里声明支持范围。实时操作系统的不确定性。RTE SL在Windows下通常配合实时扩展驱动使用在Linux下需要使用PREEMPT_RT补丁。评测机构会关注任务抢占、中断延迟、网络中断处理等指标。我曾经遇到过在Windows平台下一个USB设备的驱动异常导致EtherCAT主站周期任务抖动超过50us的情况这种问题在传统硬PLC上几乎不会出现。3.3 评测环境搭建的前置准备送检前我建议自己先搭一套评测环境把该验证的都验证掉。硬件至少准备一台目标控制器装有Codesys Control RTE SL Runtime、一台装有Codesys Development System的开发电脑、若干EtherCAT从站端子模块或伺服驱动器均可、一台普通交换机用于调试和抓包。软件准备包括对应版本的Codesys开发环境、目标设备的Runtime授权确保是最新版本、从站厂商提供的ESI文件EtherCAT Slave Information、Wireshark或者抓包工具用于排查网络故障。环境搭好之后第一件事就是跑一遍EtherCAT主站的通信测试因为很多基于Codesys的控制系统安全功能的触发和状态上传都依赖EtherCAT总线的稳定通信。这也是为什么“Codesys Control RTE SL如何配置EtherCAT主站”会成为搜索热词的原因——配置不顺利后续的SL功能测试根本无从开展。4. 实操Codesys Control RTE SL下配置EtherCAT主站的完整步骤4.1 配置EtherCAT主站前置准备在Codesys中EtherCAT主站是通过设备库集成的不需要额外安装复杂组件但有几个前置条件必须满足确定目标平台的EtherCAT主站支持。Codesys Control RTE SL带有内置EtherCAT主站功能但Windows平台下需要选择支持的网卡最好使用Intel或Realtek千兆网卡并安装官方最新驱动。获取从站ESI文件。每个EtherCAT从站设备都有对应的XML描述文件里面定义了对象字典、PDO映射、同步模式等。这个文件在从站厂商官网下载或从设备自带的U盘中获取。规划好站号分配。建议按物理拓扑顺序分配站号从1开始备用节点放到广播地址1000以后便于后续维护。我在工程里习惯先把所有EtherCAT从站串联好用一根屏蔽网线从主站网卡接到第一个从站再从第一个从站OUT口接到第二个从站IN口。这里提醒一句EtherCAT要使用屏蔽双绞线工业环境中强烈建议使用带金属水晶头的成品网线很多通信问题都是网线质量造成的。4.2 新建工程并添加EtherCAT主站打开Codesys后按以下步骤操作新建标准工程选择目标设备比如“Codesys Control for Linux SL”或“Codesys Control Win RTE SL”点击确定。在左侧设备树中右键点击“Device”选择“添加设备”。在设备库中找到“EtherCAT Master”点击添加。添加后主站会显示在设备树下。选中EtherCAT主站在右侧参数中设置“Sync Unit Assignment”和“Cycle Time”。我一般默认用1ms周期如果从站需要更快控制可调到500us甚至250us但务必确保CPU负载和网卡中断延迟能跟上。添加完主站后第一件事是给EtherCAT主站分配一个周期任务。在Codesys里右键点击主站选择“设置任务”将EtherCAT Master分配到1ms的循环任务上。这里要特别注意EtherCAT主站的通信任务必须与PLC逻辑任务协同配置如果PLC_PRG跑在10ms周期而EtherCAT跑在1ms通信会把CPU资源消耗掉逻辑任务很容易被饿死。4.3 添加从站手动导入与在线扫描从站添加有两种方式。第一种是手动添加点击EtherCAT Master选择“添加从站”从设备列表中选择对应的从站型号。前提是你已经把ESI文件导入到了Codesys的设备库中。第二种是在线扫描这是我最常用的方式。操作步骤将控制器和从站设备正常供电连接好网线。在Codesys中点击“登录”并选择“启动”这里要注意先不要直接启动应用切到在线模式后右键点击EtherCAT Master选择“扫描设备”。扫描结果会列出当前拓扑上的所有从站设备勾选后点“插入”即可自动生成从站节点。如果扫描不到从站先检查网卡是否被Codesys识别再检查网线连接和从站供电。扫描插入后从站节点会出现在主站下面每个从站会显示对应的产品代码和站地址。我习惯立即把站号改成实际规划的地址方便后续程序里直接按站号读写。有一个容易踩的坑如果扫描时出现“EtherCAT从站状态错误”或“AL状态码”提示多半是某个从站没有正确退出OP状态。此时先断开整条链路只留一个从站测试确认它能正常进入OP后再逐步增加从站这样定位问题快很多。4.4 过程数据映射与DC同步配置EtherCAT主站添加完成、从站也扫描进来之后最关键的步骤是配置过程数据映射和分布式时钟DC。在从站节点的“过程数据”选项卡下可以看到从站支持的PDO列表。一般来说代码量大的端子模块都默认启用了标准映射比如数字量输入模块会有一个字节的输入数据。对于伺服驱动器则需要根据驱动器手册勾选需要的PDO条目比如控制字、状态字、目标速度、实际位置等。配置完PDO之后还要到“I/O映射”选项卡中把每个PDO条目映射到PLC变量或直接通过地址访问。我建议在映射时统一使用符号名比如“Axis1_ControlWord”“Axis1_StatusWord”别用%QW或%IW地址。原因是后续做SL评测时评审老师拿到工程文件后要看变量命名是否清晰符号化命名能让整个评估周期顺畅很多。DC分布式时钟同步的配置要点点击EtherCAT主站的“DC”选项卡勾选“启用DC同步”同时确保最靠近主站的从站作为参考时钟。如果从站不支持DC则只能依赖主站周期触发但多轴同步性能会明显下降。实测中启用DC同步后多轴位置偏差能从几十微秒级降低到微秒级。评测环境下如果涉及伺服多轴同步务必确认所有从站都支持DC并正确启用。4.5 下载运行与调试验证配置完成后点击“登录”并“下载”程序到控制器。下载时注意勾选“启动所有周期任务”否则EtherCAT通信任务不会自动启动。启动后观察设备树中各从站的当前状态正常情况每个从站都会显示为OP状态。同时可以打开“Diagnostics”窗口查看EtherCAT主站的通信错误计数。我判断链路是否干净一般看三个指标丢帧计数、CRC错误计数、Invalid Frame计数。这三个值持续为0最为理想如果出现缓慢增长说明物理层有噪声或连接松动如果出现突发增长多半是网线质量差或从站供电不稳定。完成通信验证后继续检查PLC逻辑任务与EtherCAT数据交互是否正常。写一段简单代码周期读取所有从站输入依次输出到另外一组从站输出模块用万用表或示波器验证输入与输出的对应关系。这一步通过后EtherCAT链路基本就稳定了可以开始后续的安全功能测试和SL认证流程了。5. 常见问题与避坑清单全是现场摸出来的经验5.1 认证申报中的典型问题材料版本不一致问题是最常出现的。很多厂商前期开发过程中频繁升级固件提交送检的文档还是上一个版本检测老师一开始核对就发现对不上整个评审节奏被完全打乱。我的习惯是送检前将所有文档、固件、调试工具统一封版把所有文件放在一个加密压缩包里存档并记录MD5值。另一个问题是安全等级的预期值要和产品实际能力匹配。有些厂商一上来就要评SL 3但产品硬件根本没有冗余通道单通道架构再怎么优化也达不到SIL 3的硬件故障裕度要求。这种情况建议前期就请检测机构的工程师做一次预评估根据硬件架构和诊断覆盖率选定一个合理的等级目标免得评审会上被打回来。安全通信协议的处理也值得留意。很多产品在标准通信之外还开发了私有协议用于参数读写和固件升级。评审老师一定会追问这些私有协议有没有做身份认证、防重放、防篡改机制。如果你的私有协议只是简单CRC校验几乎没有安全措施那就要么在送检前补上安全功能要么在文档中明确说明协议仅限工程调试使用并采取措施限制在安全网络内。5.2 EtherCAT配置阶段的典型报错速查表故障现象可能原因处理方式扫描不到任何从站网卡不被实时驱动支持网线问题从站未供电更换兼容网卡更换屏蔽网线检查24V供电从站在PREOP/SAFEOP抖动无法进入OPESI文件版本与从站固件不匹配SM通道配置错误从站掉电更新ESI文件恢复出厂设置并重新配置检查电源容量通信周期偶尔抖动超过设定值CPU负载过高网卡中断合并实时任务优先级配置不当关闭实时核心上的其他高负载任务网卡驱动配置关闭中断合并重新分配任务优先级DC同步后出现“Sync error”从站不支持DC或时钟源选择错误网络拓扑环路检查从站DC配置改为参考时钟补充模式确保链路是线型拓扑下载程序后主站状态为INIT设备树中主站未分配到周期任务应用未启动确认任务配置里包含EtherCAT Master任务启动所有周期任务后重新登录5.3 几条实测下来的实战心得先说说Windows平台下RTE SL的实时性限制。Windows不是一个硬实时系统即使加了实时扩展网卡驱动的中断延迟在某些主板上依然不稳定。如果EtherCAT周期要求1ms以上Windows平台基本能应付但如果要做多轴高精度同步我建议直接把Runtime部署到Linux PREEMPT_RT环境实时表现会好很多评测数据也更好看。这一点在你做SL评测的“功能安全通信实时性”测试时非常关键评审老师会用示波器或专用工具测量EtherCAT周期的抖动测试结果会写进报告。再说说从站的强电源隔离。现场布线和评测实验室环境不同实验室的电源都很干净但工业现场电磁干扰严重。如果一个从站供电不稳会导致整条EtherCAT链路周期性报错。评测实验初期我就因为一个输入端子模块的供电线太细导致链路通信在负载变化时偶尔闪断排查了很久才定位到是电源线压降太大。所以在做SL认证测试前把所有EtherCAT从站的供电线都换成1mm²以上的导线并做好接地能省去大量排查时间。最后关于Codesys工程文件的管理。在SL评测中评审老师会反复查看工程配置检查安全相关变量是否有访问保护检查逻辑任务与通信任务的优先级设置。建议你在正式送检前在Codesys工程中设置好Source Code Management的访问级别给安全关键程序块加写保护同时把“强制登录”“在线更改”等操作权限收紧。这个细节看起来不起眼但在评审现场给老师留下的专业印象完全不同。根据我自己的经验把EtherCAT主站配置稳定这件事放在整个SL评测流程的前面是最高效的安排。因为后续要做的安全联锁响应时间测试、上下电故障注入测试、网络异常工况抗干扰测试全都离不开一个稳定可靠的通信链路。链路不稳测试数据就不可信评审结论自然不理想。如果你最近也在准备基于GB/T 42456的工控产品送检建议先拿一台样机把EtherCAT这条链路跑稳再把功能安全和信息安全的融合测试用例一条条过。等拿到证书的那一刻你会发现之前那些熬夜调试、反复整改的日子都是值得的。
