前段时间有个客户做安全系统的评估,其中涉及到安全程序的评估,在跟用户交流的过程中,感觉到大家对于故障安全程序的编制的一些规则不是很清楚,因此这里按照IEC62061标准,将西门子的故障安全程序的最新规则做一个简要的介绍。
用户在编制安全程序的过程中,除了安全功能块本身,其实还有一个问题总是有些困扰,那就是我的安全程序到底应该怎样编才是合理的、符合安全规范的,或者说是符合安全评估要求的。就这个问题,我这里将相关安全程序的编制的一些主要规则做一个简要的介绍,大家按照这个思路进行安全程序的编制,就是符合基本安全程序的编制要求的。
1 故障安全程序的标准化
1.1 定义程序结构
对于安全程序,最好进行一些结构上的规划(图1),例如:
模块化的区分程序代码,例如:
- 子程序:检测,评估,执行 或
- 按照工厂不同部分
在起始阶段,为每一个模块(根据风险评估的要求)进行功能定义
避免复杂的信号传递
图1 安全程序的结构化处理
另外,对于标准程序,可以调用的层级取决于CPU。但对于安全程序,程序调用的最多层级就是8级。如果超过这个层级的限制,就会出现错误消息。
1.2 程序调用顺序
在Main Safety程序块中,程序块的调用应该按照下列顺序(图2):
安全通讯中的数据接收块(F-CPU—F-CPU通讯)
F-模板/通道的错误确认/重新集成块
传感器的评估
操作模式的评估
逻辑操作、计算、评估等等
执行机构控制块
安全通讯中的数据发送块(F-CPU—F-CPU通讯)
图2 程序调用顺序
1.3 功能块的标准化
对于一些常用的功能块,可以进行标准化处理,创建模块化的功能块,例如:
典型的故障安全的检测功能块
典型的故障安全的执行功能块
常用的故障安全功能块(例如:重新集成、操作模式)
(1) 标准化的检测功能块(F-DI)
对每一个输入检测类型设备,创建一个独立的功能块(例如:急停指令设备,安全门,光栅等),将传感器的评估以及必要的辅助功能结合在一起(图3)。
在处理过程中,对于复杂传感器,可创建F-数据类型。
在功能块里,可以包括相关的辅助功能:
Reset
Reset interlock
Time function
Edge evaluation
Startup test
Provision of diagnostic information
图3 检测部分的标准化功能块
(2) 标准化的执行功能块(F-DO)
对每一个执行类型设备,创建一个独立的功能块(例如:接触器,阀门,驱动设备等),同时将执行器的评估以及必要的辅助功能结合在一起。而对于复杂执行器,创建F-数据类型。
辅助功能包括:
Feedback circuit monitoring
Error acknowledgment
Edge evaluation
Time function
Function switching
Provision of diagnostic information
图4 执行部分的标准化功能块
(3) 标准化的逻辑功能块(F-control)
对于控制部分的逻辑功能块,应根据相关的安全功能生成控制指令,用于控制安全相关的执行器,并且与传感器的使能、操作模式的使能等关联,作为执行器的控制信号 。
这里需要注意:
主要使用AND和OR逻辑指令
尽量减少使用SR指令块
避免跳转
在具体编制过程中,应采用如下原则(图5):
将逻辑分为不同的层级(见IEC62061):
Level1:所有的与模式或者工厂状态无关的安全功能
安全功能的“ANDing”逻辑将永远处于激活状态
典型的急停装置
Level2:所有与模式有关的安全功能
安全功能的“ORing”逻辑用在某些模式下才激活的指令中
例如,安全门在自动模式下,与“使能”一起使用时
图5 安全逻辑功能块的编制
(4) 访问全局性数据
在程序的编制过程中,考虑:
连接全局数据(输入、输出、数据块)在最高级(Main Safety)
使用块接口来传递信号至低层
其优点是:
模块化概念
在其他项目中使用该块时无需修改
减少程序错误
使得整体程序可读性较好
图6 访问全局性数据
2 故障安全程序的数据处理
除了程序结构以及功能块的标准化处理,在安全程序中,数据处理也是很重要的一个内容。
2.1 F-suitable PLC数据类型
在程序标准化处理过程中,如果遇到大数据量的、重复性强的或者较为复杂的数据,可以考虑创建安全型的数据类型(图7)。
在安全程序中,创建F-suitable PLC数据类型为结构化数据
使用F-suitable PLC数据类型进行大数据量的传输
使用F-suitable PLC数据类型进行IO数据的访问,但需要遵循下列规则:
F-suitable PLC的tag的结构应该与F-IO的通道结构相匹配
实例:定义8通道F-IO的F-suitable PLC数据类型:
访问F-IO仅允许针对实际激活的通道。当组态了1oo2的通道时,高地址将不被激活。
图7 安全型数据类型
2.2 安全程序与标准程序之间的数据交换
在安全编制过程中,往往会遇到安全程序中的数据与标准程序中数据相互之间进行传递的情况。此时,安全数据传递给标准程序还好,但反过来,标准程序中的变量如何传递给安全程序往往是一个问题, 因为这个数据是不安全的,在安全程序中使用可能会导致安全等级下降。
因此,在新的规则中,可以按照如下规则进行处理(图8):
使用全局标准数据块用于标准程序与安全程序之间的数据交换。
最好创建两个数据块,分别用于标准程序与安全程序之间双向数据交换。
在数据块中,不应存储更多的其他信息(例如:来自于标准程序的诊断信息),并且数据的变化不能导致安全程序的修改。
可以看到,处理起来相对容易了,而且还有以下的优点:
精简F-runtime group
更好的总览交换的数据
在标准程序中修改诊断或者信号时,不影响安全程序的标签
最大限度的减小向安全程序中写数据导致的数据冲突从而产生的宕机时间
简化编写F-块
改变标准程序下载时,可以不导致CPU的停机
标准用户程序与安全程序可以独立的编制,只需定义好相关的接口
图8 标准程序与安全程序之间的数据交换
当然,并不是所有的数据都可以这么处理,安全的功能块的触发还是需要采用安全信号的,这仅仅是指一些状态位、Reset位以及一些报警信息(图9)。
图9 安全功能块的触发和复位
当复位按钮作为安全功能的一部分时,在SIL等级允许的情况下,可以考虑采用标准数据实现相关的安全复位(I 0.2)。但安全功能的触发仍然是安全的输入信号(I 2.0)。
2.3 从HMI向安全程序写数据
从HMI向安全程序写Tag是有风险的:
来自HMI屏上信号是非安全的,并没有被验证。因此一个错误将可能导致安全值的改变,这将增加风险。
HMI与CPU之间的通讯是非周期的。因此,来自HMI的写访问将可能发生在安全程序的处理过程中,原始的程序可能使用的是原始值,但编码后的程序可能使用的是更新过的值,这将到时安全程序中的数据错误,并导致CPU停机。
因此,可以考虑创建一个数据类型用于数据从HMI向安全程序中传递。在HMI Tag中使用此数据类型,将标准程序中的数据复制到数据缓存区用于安全程序。
可以建立多个Tag用于将HMI数据写入到安全程序,尽量不修改数据类型(图10)。
图10 HMI与安全程序的数据交换
另外,从HMI上进行安全确认时,需要调用功能块(图11)。
TIA Portal提供了“ACK_OP”系统块用于Reset安全功能或进行错误确认。 确认过程分为两步(S7-1200F/1500F):
Step 1:将IN修改为“6”,并保持一个周期
Step2:在1秒钟后,1分钟内,将ACK_ID 修改为“9”并保持一个周期
而为了保证该功能正常工作,应保证安全程序的优先级大于通讯的优先级。
图11 安全确认功能块
2.4 保证F数据不应出错
下列操作容易导致数据损坏:
被更高优先级的报警进行写访问
被HMI/通讯进行写访问
使用系统时钟
被更高优先级的报警更新部分PII
因此对于安全数据,应参考以下相关注意事项:
3 重新集成
当安全系统检测到短路、断线等故障后,会进入钝化状态,此时是需要进行重新集成/去钝化的操作,这里建议采用手动去钝,调用相关的功能块或语句,尽量不要使用自动去钝。
图12 重新集成/去钝化
以上就是根据最新的标准,我们给大家推荐的编制安全程序的一些最主要的规则,大家在编程需要参考,这样将更加符合安全程序的编制要求,也更符合IEC62061 等安全标准,有助于进行安全评估。