文件类型：PPT/Microsoft Powerpoint 文件大小：字节
全方位的EES--APC/AEC解决方案/支援电子化制造
程监控应用系统安全指引制定
暨警报管理系统效能改善计画
结案成果报告
报告人:游辉祥
E-mail: HueiShyangYOU@itri.org.tw
Tel: 0921073450; 03-5915008
志 谢
感谢台湾科学工业园区科学工业同业公会暨经济部技术处科技专案经费支持
感谢同业公会水电气供应委员会对本案之支持
感谢联华电子,旺宏电子,华邦电子暨计画参与成员之热心协助,赞助与指教
技术应用背景
制程异常损失
何谓制程异常状态
操作人员在当班的过程中遭遇到不可预期的事件或情况而导致操作人员对工厂的操作产生质疑或导致工厂操作不顺或受干扰
程序可能未受影响或产生足以被观察到的影响
操作人员可能不知道实际的制程状况
制程异常损失
1994 在 Texaco Milford 炼油厂所发生的爆炸及火灾,造成 26 人受伤,损失达 4 仟 8 佰万美金
意外事件有可能因为气候的因素,设备故障或操作人员的疏失所造成
经统计 50% 到 60% 石化厂的爆炸,损伤和意外的排放是因为人为的错误所造成的
一些无法预知的情况往往会造成许多微小但累积起来却相当昂贵的代价,譬如:肇因於设备或财产损坏的直接经济损失,导因於品质不良或减产之产品损失,生产进度或交货中断,人员伤害或环境损害等
每年全球工业因不当的异常操作损失可达 1000 亿美元
以美国石化业为例,其异常操作损失每年近 200 亿美元
制程异常损失(续)
PES安全标准或指引制定之重要性
HSE 调查结果显示
PES失误原因主要源自PES建造与设计阶段
43%之PES失误源自设计规格,其中
38%源自Hardware failure
7%源自Power supply problem
14%源自System and design problems [55%*(18%+7%)]
主要解决对策即为建立安全标准或指引,并严格遵守安全标准或指引来建造与设计PES
於建造与设计PES时完整考虑安全标准或指引之需求,其成本效益是100倍於日后之持续维护与修改设计
Texaco Milford 火灾爆炸案例 HSE 之调查结果显示
产生太多警报
警报无优先顺序处理的规划
不适当的控制画面设计,使操作员无法迅速找出问题所在
操作员缺乏足够的训练,无法应付紧急状况的发生
在爆炸发生前 11 分钟,仍有 275 个警报等待两位操作员逐一确认
PES维护与管理之持续获利策略为建立完整的警报最适管理技术与制度
PES: Programmable Electronic Systems
HSE: Health & Safety Executive, UK
制程异常状态
Potential
Impact
of
Initiating
Event
Time
Incident
Abnormal
Normal
Abnormal Situation Detected
SIS Activated
System Trip
冲击异常状态管理之因素
资料来源:修改自 Honeywell Hi-spec ASM相关资料
Source
Failure
Types
Unsafe Acts
Errors &
Violations
Condition
Tokens
Precursors
Functional
Failure
Types
Safety Information System
Interface
between the
organization
& the individual
Management
Workplace
Defences
General Failure Types
1-10 hit list
Proactive Design
SI Projects
Best Practices
PCM / ASM
ECM / EHM
Poor workplace
Design
High workload
Unsociable hours
Inadequate
training
Poor perception
of hazards
Control room
design
Workspace
Near miss
Auditing
Du Pont
Training
Workspace
Motivation
Attitude
Group Factors
Working Practice
Stylistic or Cultural
Indicators
Top Down:
Commitment
Competence
Cognizance
data collected &
analyzed
Diagnostic and remedial measures
Recommendations
保险界统计:
美国工业界仅设备损坏之损失
每年即超过22亿美元
600
30
10
1
虚惊事件
重大事故
程监控系统功能性安全设计实务
警报管理最适化实务
制程状态高阶监视与异常诊断技术应用
操作限值与设备限值管理
设备健康管理与预测性维修技术应用
线上决策支援系统
执行成果及技术扩散
教育训练
莅厂宣导
联电,旺宏,华邦电,力晶,台积电,奇美电
警报管理最适化技术研讨会
92/07/29,8/1~2: 33人次
厂务管理与控制系统功能性安全技术研讨会
92/11/11: 38人次19厂家
厂务管理与控制系统功能性安全检查实务说明会
92/12/23: 45人次16厂家
衍生推广
异常状态管理在操作效能提升技术研讨会
92/12/03: 38人次20厂家
监控设备功能性安全等级评核技术说明会 (PLC设备商)
93/03/30: 27人次10厂家 --- 力晶委办
厂务监控系统系统整合功能性安全技术说明会 (FMCS系统整合商)
93/04/07: 35人次13厂家 --- 力晶委办
功能性安全如何纳入厂务监控系统建置规范说明会 (厂务设备系统承揽商)
93/05/19: 24人次10厂家 --- 力晶委办
台湾洛克威尔自动化控制解决方案研讨会
93/05/13, 18, 20: 约超过200人次 --- Rockwell Automation主办
莅厂宣导
台积电FAC 2/5, 12A,旺宏电子FAC 1,悠景,铼徳,华映桃园总厂,奇美电LCD 4/5厂(新建案)
智权文件
PFD及SIL需求评估程序及准则
CHAZOP 评估机制程序文件
PES设置检核要项现场访谈问卷
安全联锁作动系统现况评估问卷检核表
控制元件与传输讯号安全考量现况评估问卷检核表
I/O与Controller模组现况评估问卷检核表
工作站与处理器现况评估问卷检核表
PES软体安全需求安全指引检核要项检核表
监控流程架构内其他组成元件安全指引检核要项访谈问卷
PES设置安全指引检核表
特气泄漏程监控系统安全指引检核表
无尘室程监控系统安全指引检核表
化学品供应程监控系统安全指引检核表
纯水程监控系统安全指引检核
警报管理最适化训练教材
结案执行报告
主要发现—监控系统设计
系统架构
未遵守FM 7-45, IEC 61508/61511, ISA SP84等标准进行设计
未遵循BPCS / SIS分离原则之设计理念
未依据SEMI S10 / IEC61508 / IEC61511 / FM 7-45建议之风险评估结果,评估每一个SIS环路SIL等级要求之需求规格选用及设计SIS
未遵照PLC原厂认证合格指令进行系统组构及设计
系统组构设计(含模组型号选用)未评估整体之PFD值 (亦即可靠度与可用度)
软体设计多数放弃原厂经过认证合格之编辑软体(IEC 61131)进行Logic设计
设计施工时未避免Common Cause Failure或未遵循原厂之设计SOP
I/O 模组, 线材及通讯介面在SIS部份未考量Fail Safe及安规认证需求
未评估系统紧急停车或Reset时之Fail-safe Mode如何维持
多数放弃原厂经过认证合格的主动/被动诊断功能及Watch Dog (如此将降低系统之可靠度)
ESD设计
未依据危害等级(火警[财产损失],特气泄漏[人员伤害],环保议题)之评估设计ESD
ESD之设计未遵照FM 7-45设计架构
ESD Button, 线材之选用未符合安规 (IEC 60947)
Safety Relay
Relay之选用未评估安规等级 (IEC 60255)
管理机制
未建立UAS评核机制选用监控设备系统相关组件(含SIS之Sensor, Final Element)
监控系统於纳入现场操作前未执行Functional Safety之评估与测试 (必须遵循IEC 61508/61511之建议进行)
SCADA HMI警报管理功能设计未遵循EEMUA No. 191/201
控制中心设计未遵循EEMUA No. 201, ISO/CD 11064
其他
软体应用系统架设层级未符合FM 7-45之规定
资讯安全解决对策有错误认知
主要发现—SIL等级需求略估
警报管理最适化
主要发现—警报管理问题
无全厂警报价值观与规范
警报发生时,操作员无须采取动作
小操作扰动确引起大量警报
明确的例行操作改变却引起大量无意义之警报
当无任何事件时亦有警报产生 (Nuisance alarms)
重大操作异常时引起无法处置之大量警报 (Alarm flooding)
当警报发生时操作员并非确定知道如何处置 (无建议措施)
有些警报常时期停留於面板
操作程序与警报动作无关
技术扩散
A厂自行进行无效警报评估,去除80%无效警报
B厂自行进行无效警报评估及Disable警报管理,进一步引用电子化工具管理警报系统效能
C厂委托ITRI协助导入完整的AMO技术实务,於新建案一并导入PES Safety Guides设计理念
D厂评估引用电子化工具管理警报系统效能
错误引用AMO技术
警报作动数目不是愈少愈好,是要让无效警报不出现,有用的警报作动数降低至合理可行的程度,并确保不会错失对异常状态的即时掌握
FY94规划
透过TSIA ESH技术委员会,成立Facility Standard Working Group,与SEMI Worldwide接轨,参与FMCS PES设计安全标准制定
ITRI将协助促成此事
附件
程监控系统功能性安全设计
改善建议汇整
SIL等级需求评核结果汇整表
四
三
二
一
项次
1
VOC废气处理程监控系统
1
Clean Room MAU程监控系统
2
Exhaust System 程监控系统
2
特气泄漏程监控系统
SIL需求等级
目标次系统
五
1
化学品供应程监控系统
六
≥1
DI Water供应程监控系统
改善建议汇整
程监控应用系统架构评核缺失
一般制程控制(BPCS)与安全仪表系统(SIS)的相关组成元件皆须分开设置
侦测器与最后控制及作动元件间不可经由"Data Highway"传输通讯
两者皆须直接连线(Directed-wired)至相同的逻辑处理器(SIS Controller)
执行联锁作动决策判断的功能不可由SCADA执行
分散式控制是功能性的分散,而非相同功能控制器的切割
可用度与可靠度仍须维持
SIL2的监控系统
相较於安全联锁作动控制器的多重设计(Redundancy)
以分散式设计将执行安全联锁作动功能的控制器切割成数个单一的控制器来分别执行同一监控系统但不同区域位置的监控,其可用度与可靠度并未提升反而降低
改善建议汇整(续)
程监控应用系统架构评核缺失
安全联锁作动系统之控制器与I/O模组之通讯联系,应采用下列方式设计:
若实务上许可,建议采用Local I/O (Backplane Connected)之设计规格
若实务上的因素,必须采用Local I/O与Remote I/O混合之通讯联系方式
Remote I/O之设计规格,建议采用具备UAS approved security and error checking功能之Remote I/O设计规格
设置於中央监控室的远端手动安全联锁作动人机介面(Remote EMO)应设置独立盘面,不要设置於操作员工作台
若采用一般制程控制用的阀做为安全联锁作动的最后关断元件
此阀必须遵循UAS (User-Approved Safety)的验证认可
改善建议汇整(续)
设备元件规格给定缺失
所有元件应为UAS
当使用端欲选用SIL1等级以上之设备元件时
不能仅选用符合UA (User-Approved) 的规格
是否符合UAS ,使用端公司内必须建立审核与判断基准的管理制度与程序来检视与讨论相关议题
供应商提供的设备元件可靠度与可用度书面资料,不能仅提供MTTF (Mean Time To Failure)数值
供应商所提供的设备元件可靠度与可用度书面资料方面,必须包括硬体故障容忍度(N),故障失效安全比率(SFF) , MTTR(Mean Time To Repair)等
改善建议汇整(续)
设备元件规格给定缺失
硬体故障容忍度定义
假设硬体故障容忍度为N,意谓此硬体当发生N+1个故障事件时,会造成安全功能的丧失
当评估此因素时必须假设此硬体没有其他可控制故障所造成安全功能丧失的方法,例如异常诊断的功能
当一个故障事件会序列性的间接导致其他一个或很多个故障事件的发生时,仅考量为单一故障事件
改善建议汇整(续)
设备元件规格给定缺失
安全故障失效比率(SFF, Safe failure fraction)的定义
安全故障失效(Safe failure)
可定义为此故障事件的发生不会导致安全功能的丧失
危险可被侦测得到的故障失效(Dangerous detected failures)
可定义为此故障事件的发生会导致安全功能的丧失
於失效发生时可经由其他可控制故障造成安全功能丧失之量测方法侦测得知
例如异常诊断的功能
SFF可定义为下列二项因子之比率值:
安全故障失效的平均发生率(Average rate of safe failures)与危险可被侦测得知的故障失效平均发生率(Average rate of dangerous detected failures)二者之和
硬体的总平均失误率(Total average failure rate)
改善建议汇整(续)
设备元件规格给定缺失
审核UAS的管理制度与程序可依据下列原则来拟订:
使用公司与产品制造商共同针对下列议题讨论并发展策略:
将商业产品应用於安全相关系统(例如SIS系统)时,所有可能潜在发生之问题及对安全相关系统的影响效应
产品制造商提供产品所有不安全之失误模示(Unsafe Failure Modes)
产品制造商已辨识出每一个不安全之失误模示,与可能发生频率
公司发展出相关之操作与维护计画,藉以使产品继续不断的符合操作安全需求
使用端检视商业产品之绩效
与目前相关产品之工程规范变更需求(Engineering Change Orders)做比较
评估过去此产品使用前之测试需求方法是否已不符合目前的规范标准所设定之测试标准
此产品过去已於相关应用领域成功适当的操作过
若上述的相关资料已评估考虑并符合所欲应用之系统需求,则此产品可视为User-approved Safety
改善建议汇整(续)
风险评估管理制度与机制的建立
SIL1以上程监控应用系统的设置与整合(System Integration),未使用下列任一方法执行系统潜在危害事件的辨识与风险分析:
失误树分析(Fault Tree Analysis)
失误模式与影响分析(Failure Modes effect and critically analysis)
事件树分析(Event Tree Analysis)
原因后果分析(Cause Consequence Diagrams)
蒙地卡罗模拟分析法(Monte-Carlo Simulation)
改善建议汇整(续)
风险评估管理制度与机制的建立
纳入操作前的验收测试必须包含下述项目的测试:
测试所有已规划於应用软体之安全逻辑功能(Input data is selected to exercise all specified functional cases)
包括异常错误发生时之处理功能
依据原因后果图之分析结果,测试所评估分析之异常事件
测试与执行边界值分析(Test cases from boundary values analysis)
建立定期测试安全仪表系统(SIS)的功能是否正常的测试制度(Passive diagnostics)来诊断SIS的故障
或於程监控应用系统内加入线上异常诊断功能(Active Diagnosis),可於要求SIS执行联锁作动前,预先发现异常并修复
改善建议汇整(续)
风险评估管理制度与机制的建立
建制审核供应商所提供设备元件硬体所属类别的机制,硬体分为A类与B类:
A 类硬体定义如下:
所有组成元件的失误模式已清楚完整的定义(The failure mode of all constituent components are well defined)
於发生故障事件的状况下,此次系统的应答行为能完整性的被评估考量(The behavior of the subsystem under fault conditions can be completely determined)
为了确认供应商所提供关於可侦测与无法侦测得知之危险故障失误率数值的正确性,可获取由实场操作经验统计得出可信赖的故障失误率资料来加以验证
符合上述原则,则可视为A类硬体
B 类硬体定义如下:
至少有一组成元件的失误模式没有清楚完整的定义
於发生故障事件的状况下,此次系统的应答行为无法完整性的被评估考量
无法获取由实场操作经验统计得出可信赖的故障失误率资料来加以验证确认供应商所提供关於可侦测与无法侦测得知之危险故障失误率数值的正确性
符合上述原则,则可视为B类硬体
改善建议汇整(续)
风险评估管理制度与机制的建立
依据目前园区厂务程监控应用系统现况,硬体极大部分可视为B类
依据IEC 61508-2(2000),IEC 61511-1(2003)等规范建议,若选用B类硬体於SIL1以上的程监控系统,可依据下表基准要求供应商符合SIL等级需求
改善建议汇整(续)
共同失效原因(Common Cause Failures)的避免
SIL1以上的程监控系统必须尽量避免任何可能的共同失效原因造成SIS的可用度与可靠度无法达到使用端需求:
若设置多重侦测器,则在不影响可靠度的情况下
应该依据多样性技术(Diversity)
选用不同类型的侦测器
例如:
不同供应商的产品,或
相同供应商但不同类型的产品
执行不同功能的控制器与监控系统的人机介面监控台做资讯传输的输出讯号建议不要通过相同的网路集线器(HUB)
PLC之应用程式软体建议不要同时执行PID控制
一般制程的序列控制(Sequence control)与安全联锁作动控制等逻辑功能
不同次系统的安全仪表系统(SIS)最好分开设置
避免因为共同使用的设备元件失效,造成共同失效原因的发生
改善建议汇整(续)
技术文件资料的提供,更新与保存
执行安全功能逻辑运算的PLC,供应商必须提供使用端逻辑运算功能清单,例如依据下列任何一种方式提供:
Logic/function block diagrams
Sequence diagrams
Data flow diagrams
Finite state machines/state transition diagrams
Time Petri nets
Decision/truth tables
程监控系统通讯联系架构图示与说明的书面资料
其他相关问题或建议
程监控系统基础架构
系统整合度
产品等级与确效验证
系统延展度与弹性
管理制度建立
控制室环境与管理
施工问题
接地
配接SIS相关量测元件,阀件与讯号线之规格要求
PLC SIS 逻辑失效模式分析与测试
可用度确保更胜於可靠度之要求
变更管理
安全评估与核可变更
附件
警报管理最适化
示范厂警报效能分析报告摘要
背警及尖峰警报分析结果
Note: B系统之特定原因已排除
静态组构分析结果
Average number of All alarms per day
Peak alarm rate
Top 29 Alarms showing cumulative contribution
Average number of all alarms per day excluding worst tag
Number of alarms type of each unit
Alarm ack number of All alarms per day
最佳实务
程监控系统功能性安全设计
Risk-based PES设计哲学
HSE, UK
针对不同类型工业34个代表性PES发生意外事故之原因进行探讨
ICI公司
收集分析7年内PES发生意外事故之原因
分析100件意外事故之原因
共通性结论
HSE公告说明PES发生意外事故之原因很多是来自技术上的原因
无论使用何种技术原理来设计PES
於系统生命周期之各阶段,若能依循工程与管理之安全需求,就能降低危害发生的机会
Design-in 的哲学
其成本效益约为日进行修改,变更设计或维护的100倍
Risk-based PES设计哲学(续)
前述数据分析结果显示
大部分PES意外事故之肇因於设置规划的初期阶段即潜藏
主要原因为不适当的设计需求与规格给定,其理由为
欲监控之系统或设备未执行危害风险评估
PES的设计规格不符合欲监控系统或设备之安全需求规格
大部分的意外事故原因并不是因为系统发生不可思议的失误模式,而是可事先分析与评估得知的
如果使用风险为依据(Risk-based)的设计原理
於系统生命周期的各阶段,使用系统化的危害评估方法执行评估,并於设置规划的初期阶段加入安全需求规格,就可有效降低危害发生的风险
如何降低PES风险
欲监控设备或设施
之潜在风险
必须完成的危害风险降低策略
危害事件
后果严重性
Risk Level
5*10-2 (1/Yr)
(before)
Probability of Failure
on Demand (PFD)
2*10-3
Probability of Failure
on Demand (PFD)
5*10-3
Risk Level
5*10-7 (1/Yr)
(after)
危害事件
发生频率
PES
安全功能失效
PES其他风险降低
保护层(IPL)失效
可容忍之
风险目标
依据SIL等级
设定软硬体规格
系统整合安全概念
Dike
Passive protection layer
Emergency response layer
Plant and
Emergency
Response
Process
Value
Normal behavior
Basic
Process
Control
System
Process control layer
Operator
Intervention
Process control layer
By APC or Alarms
Process alarm
Process
Shutdown
Trip level alarm
Safety
Instrumented
System
Safety layer
Emergency
Shut Down
Relief valve,
Rupture disk
Active protection layer
Prevent
(Pre-warning
Predicted
by PCM/ECM;
Corrected
by OAS)
Mitigate
x x
Taking the process to a safe state
when predetermined conditions are violated
安全整合等级
安全整合等级 (Safety integrity levels, SIL)
由安全整合需求决定安全整合等级
不同的安全整合等级有不同的安全功能操作绩效
安全整合等级可区分为4级 (SIL1~4)
等级1 (SIL1)为最低标准之安全功能操作绩效要求
等级4 (SIL4)为最高标准之安全功能操作绩效要求
等级愈高,则要求相关潜在危害事件发生的可能性须愈低
功能安全需求规格 (Functional safety requirement specification)
安全功能需求与安全整合等级需求两项共同组成设置程监控系统(PES)之功能安全需求规格
功能安全需求规格为设计安全相关的PES前,必须加以决定确认的
安全功能的安全整合等级需求与必须正确执行安全功能的设备元件有关
执行SIL评估之目的
评估欲监控设施可能潜在的危害风险,并依据风险管理原理,评估必须达成的设施危害风险降低量
依据上述必须达成的设施危害风险降低量,设定相关PES有效执行安全功能的可靠度或可用度需求(SIL等级)
由SIL等级需求设定PES的软硬体安全规格需求
可藉以达成符合国际要求或公司内部要求的危害风险管控标准
PFD及SIL需求评估程序与准则
O3
O2
O1
A
×
×
B
A
×
C
B
A
D
C
B
E
D
C
F
E
D
G
F
E
H
G
F
SIL等级
评估起点
C1
C2
C3
C4
E1
E2
E1
E2
P1
P2
P1
P2
PFD及SIL需求评估程序与准则(续)
PFD及SIL需求评估程序与准则(续)
PFD及SIL需求评估程序与准则(续)
SIS硬体及软体架构范围
SIS Logic
Solver
Output
Modules
Input
Modules
SIS Input
Devices
SIS Output
Devices
BPCS
Interface
SIS
HMI
SIS
Engineer's
Console
SIS设计考量因子
All fail-safe aspects
Including deenergized-to-trip (失能跳脱) versus energized-to-trip (供能跳脱) operation
Logic structures
Fault prevention / mitigation
SIS / BPCS separation
Diversity (差异,不同点,多样性)
Software considerations
Diagnostics (软体及硬体失效模式诊断)
Human / machine interface (HMI)
Communications
Such as the interface to the BPCS
逻辑结构
SIS Redundancy 可能设计
Logic
Solver
Sensor
Final
Element
1001
1002
2002
2003
1001
1002
2002
2003
1001
1002
2002
符合安全标准之PES设计建议架构
系统架构
FM 7-45
IEC 61508/61511
ISA SP84
PLC软体设计
IEC 61131
HMI软体设计
EEMUA No. 191/201
控制中心设计
ISO/CD 11064
Safety Relay
IEC 60255
ESD
IEC 60947
SIL1 SIS架构示意图
BPCS
Controller
BPCS
Controller
BPCS
Controller
"User Approved Safety" PES
Logic Solver
Final Control
Element
Sensor
BPCS
HMI
Data highway communications
BPCS
SIS
Note 1
Note 2
Note 3
Notes:
Communications between SIS and data highway adheres to separation criteria
SIS HMI is not shown
No data highway communications are permitted between the sensors and the final control element of an SIS. Sensors and final control elements that are interlocked to each other will be direct-wired to the same SIS logic solver
Availability Range: about 0.99
Logic Diagram
Sensor
Final Control Element
PES
Structure
Logic
Solver
SIL2 SIS架构示意图
BPCS
Controller
BPCS
Controller
BPCS
Controller
"User Approved Safety" PES1
Logic Solver
(Note 5)
Final Control
Element 1
(Note 5)
Sensor 1
(Note 5)
BPCS
HMI
Data highway communications
BPCS
SIS
Note 1
Note 2
Note 3
Notes:
Communications between SIS and data highway adheres to separation criteria
SIS HMI is not shown
No data highway communications are permitted between the sensors and the final control element of an SIS. Sensors and final control elements that are interlocked to each other will be direct-wired to the same SIS logic solver
For diagnostic purposes, redundant sensor values are available to each logic solver and/or the BPCS
Sensor, logic solver, and/or final element may be redundant as availability and and reliability
Availability Range: about 0.99 to 0.999
Logic Diagram (Note 5)
Structure
Logic
Solver
Note 4, 5
Symbol
A
AND Gate
A
A
Final Control
Element 2
(Note 5)
"User Approved Safety" PES2
Logic Solver
(Note 5)
Sensor 2
(Note 5)
Sensor
1 (and 2)
Final Control Element
1 (and 2)
PES1 / PES2
SIL3 SIS架构示意图
BPCS
Controller
BPCS
Controller
BPCS
Controller
"User Approved Safety" PES1
Logic Solver
Final Control
Element 1
Sensor 1
BPCS
HMI
Data highway communications
BPCS
SIS
Note 1
Note 2
Note 3
Notes:
Communications between SIS and data highway adheres to separation criteria
SIS HMI is not shown
No data highway communications are permitted between the sensors and the final control element of an SIS. Sensors and final control elements that are interlocked to each other will be direct-wired to the same SIS logic solver
For diagnostic purposes, redundant sensor values are available to each logic solver and/or the BPCS
Caution: PES1 & PES2 are not SIL 1 PESs. See the special requirements shown herein
Availability Range: about 0.999 to 0.9999
Logic Diagram
Structure
Logic
Solver
Note 4
Symbol
A
AND Gate
A
A
Final Control
Element 2
"User Approved Safety" PES2
Logic Solver
Sensor 2
Sensor
1 and 2
Final Control Element
1 & 2
PES1 / PES2
Note 4
Logic
Solver
Sensor
1 and 2
Final Control Element
1 & 2
PES2 / PES1
配电架构示意图
最佳实务
如何将功能性安全设计要求
置入工程招标规范内
系统使用端规格与预算拟定程序
挑选合适设备系统供应商
供应商提出计画书草案
使用端审核系统设备供应商所提计画书草案
确认SIS Logic数目与范围
规格与预算拟定
系统设备供应商依据最后定案的规格
研提正式计画书
引用UAS机制
引用PHA结果
SIS架构设计
SIS元件选用
采购订单
采购需求
计画书草案内容
BPCS / SIS Logic归属之划分
系统商或设备供应商可依据安全评估程序进行判定或根据经验初步给定
提交依据安全评估程序进行判定或根据经验初步给定之相关文件资料
系统商或设备供应商依据其危害辨识结果提交危害辨识与风险分析相关之安全资讯文件
说明其风险评估依据及评估流程
此部份可视实务状况进行必要之补
提交制程流程说明(含开停车流程,维护保养制度SOP),管线仪表图,控制回路清单,安全资讯(本质安全资讯,设计技术资讯,设备规格资讯)等文件
此部份可视实务状况进行必要之补件
计画书草案内容(续)
清查所有仪控AI/O, DI/O表列清单,清单表格栏位至少涵盖下列项目:
Tag ID
Tag Type
System or Area
Description
Engineering Unit
Range
Used by what BPCS Logics
Used by what SIS Logics
BPCS Logic 清查,清单表格栏位至少涵盖下列项目:
Logic ID
Input Tags (Highlight Tag Types)
Output Tags (Highlight Tag Types)
Functional Block Diagram — Appendix
Logic Instruction — Appendix
计画书草案内容(续)
SIS Logic 清查,清单表格栏位至少涵盖下列项目:
Logic ID
Input Tags (Highlight Tag Types)
Output Tags (Highlight Tag Types)
Functional Block Diagram — Appendix
Logic Instruction — Appendix
计画书内容必须说明每一个SIS Logic的SIL等级定义,提供佐证的认证资料与说明
计画书草案内容(续)
计画书内容必须说明报价参考基准,点数依据,SIS 环路数目依据与BPCS 环路数目依据等
计画书内容必须包括警报点规划说明,并 清查所有Alarm Tags,与整理成清单表件,清单表格栏位至少涵盖下列项目:
Alarm Tags
Tag Type
Description
Design Purpose
Priority Assessment —依据Alarm Priority Assessment准则
Parameter Setting建议
计画书内容必须说明是否有防爆区域与防爆等级的规划与设计
警报优先权组态评估基准范例
计画书草案内容(续)
计画书内容必须说明每一个SIS Logic的硬体设计架构,可依据下列的 SIS Logic表列清单方式说明
计画书草案内容(续)
计画书内容必须包括警报点规划说明,并 清查所有Alarm Tags,警报点规划组构清单填写范例请参考下列表格
计画书草案审核
使用客户成立计画书审议小组
针对下列计画书内容进行审议与建议事项,并与系统商或设备供应商达成结论共识:
BPCS Logic 清查
SIS Logic 清查
由系统商或设备供应商所提供的 PID初稿
由系统商或设备供应商所提供的AI/O, DI/O, Logic Table (Including BPCS & SIS)初稿
由系统商或设备供应商提供Functional Block Diagram (Including BPCS & SIS) 初稿
BPCS 与 SIS Logic归属之划分
依据安全评估程序进行判定或根据经验初步给定
为保留采购议价完成后,实施阶段之变更弹性
使用客户需要保留一定比例之变更设计弹性
例如10% Logic数/总体Logic数,系统商或设备供应商可据此报价并控管承接风险
最佳实务:警报管理最适化
第零阶段:认知
警报管理最适化要素地图
事件的种类
Potential
Impact
of
Initiating
Event
Time
Abrupt/Catastrophic
Insidious
Manageable
操作员是站在最前线的
Most operators' view of what's really happening in the field is limited by the "system"
Process Conditions and control signals
Almost NO EQUIPMENT CONDITION
DCS / SCADA
Field
操作员是核心角色
进阶
控制
警报
不在场(场外)
(操作)程序
阀件
问问自己:
程监控系统支援这些功能
到底有多少
现场
作业员
政策
制程
感测元件
商业议题
警报
警报
我记得有15个警报
在那儿已经很久了
我想要知道我必须做什麼
假如高压警报跳车再次发生
这个画面上有23个警报
有效的应变反应
Potential
Impact
of
Initiating
Event
Time
Incorrect
Response
Best
Sub
Optimal
Good Decision Support
Reduces errors
Decreases time to implement response
Manages side effects
Increases awareness
No
Response
警报管理改善程序
警报管理改善程序之目标
在正常操作下,降低警报作动数目至可接受程度
确认警报在目前的操作内涵下是有意义的
最小化驻留警报数目以促成"dark screen"操作
确信在异常状态下警报之产生有助於操作员在最少的时间中安全地稳定制程
以管理系统来避免警报系统效能不会随时间消逝而递减
解决对策建构区块1
警报效能评估(APA)
操作员错失警报之风险为何
每一个问题区域之相对贡献为何
导致警报尖峰的原因是什麼
无效警报 -->"操作员抑制"接著"处理与治疗"
直接序列 -->"动态抑制"
"涟漪效应(Ripple-effect)" -->"优先层级管理"
设定改善之优先顺序
减少无效警报最有效的改善对策是什麼
警报再评估是否需要
假如是,在那个区域
如何循序进行
良好参数设定的要点为何
建议什麼型态的抑制技术
执行APA之工具
背景警报率
尖峰警报率
坏份子(Bad Actor)识别
改善绩效评估
解决对策建构区块2
警报系统设置之责任区分
警报通则
定义某厂或某组织之警报实施与管理之基本原则
巩固所有警报管理工作之基础
必须是一份有用的文件
警报设计准则 – 范例
每个警报均应具备提醒,通知与指导的功能
避免警报组构倾向多设
呈现给操作员的每个警报均应有用且具关联性
避免无效警报(Nuisance Alarms)
每个警报均应有既定的应变措施
每个警报皆应采取行动(Action)
透过管理制度与训练之执行避免人为失误发生
应有充分的时间使操作员完成应变措施
合理的警报界限设计
了解操作极限及制程之偏离演变过程
透过训练与经验传承
每个警报系统应明确在人员操作极限下进行组构设计
人因考量以避免操作人员过负荷
避免抱怨(Complaining)式警报
去除无效警报
警报优先权组态评估基准
解决对策建构区块3
警报再设计评估
也被称为"警报目标分析"
目的
去除不需要的警报 -->清仓
设定警报优先层级以管理"涟漪效应"警报
检视设定 -->避免不合适之参数设定
定义要求规定以执行警报抑制
资源投入与缓步进行
降低背景警报率约50~70%
可使用警报效能分析报告来聚焦或循序进行
去除大部份stale之驻留警报
除非聚焦讨论,否则对尖峰警报没有太多影响
警报再设计评估程序
传统上每个警报都进行评估
耗力费时,成效缓慢
循序进行 -->采用警报效能评估辅助
Top down / bottom up / fight for survival
绩效可以直接评估
可在数周内见效而不必耗时逾年
以资料库的方式记录文件
类似CHazOp的参与成员与评估方式
process eng, ops, control eng, facilitator
警报优先层级
使"critical"警报清楚可见
采用工具管理警报系统的两个面相
在正常操作时,关注工厂的效率
在异常操作时,关注工厂是否仍然在线上
低优先层级警报可以在危机发生时暂时地被忽略
以优先层级排序进行评估,则低优先层级警报会排在后面
高及中等优先层级警报在制程偏离一开始时,帮助操作员处理紧急的工作
采用有效的工具来管理警报泛滥的问题
解决对策建构区块4
什麼是警报抑制
以软体控制抑制警报
抑制的警报仍可於画面上看到及Journal上看到
通常需要与第一次警报互相关联
必须可以
从备用设备中去除驻留警报,以达成"dark screen"操作
减少警报泛滥
帮助确信仅有相关的警报被显示
警报抑制
标准确认
警报效能评估 (也就是尖峰警报分析)
警报再设计评估
持续分析警报泛滥
警报通则之捕抓原理
抑制
序列警报("动态抑制" -->自动)
离线设备警报("静态抑制" -->自动或手动)
无效警报(手动控制)
Mode-dependent警报
改变警报设定或依据设备操作型态关闭警报
软体设计做法
需要依循标准或安全评估
警报系统重新设定实施步骤
通告设计及签认(独立评估小组)
设定双(反)向计画
图面重新设计
执行DCS / SCADA资料库变更(时程掌控)
前置测试图面及组态
表达停止(反向)计画
确认实施
事后稽核
依所需修复及修订
维持最新文件
警报变更管理制度
(1) 目的
为避免厂内制程警报之变更影响到操作人员的操作及处理行动,而引发制程危害事件,影响人员安全卫生,造成设备损坏或是其他不可接受之风险,特制定此程序
(2) 范围
凡厂内涉及下列与制程警报有关之改变,均应遵守本作业程序:
(A) 警报之失能或关闭(Disable)
(B) 警报之新设或删除
(C) 警报之优先权,设定点,参数及显示方式等的修改
(D) 警报之处理行动(Action)的修改
(E) 其他未有书面程序规范其执行方式之制程警报的改变
解决对策建构区块5
持续获益
假如这是值得做的事,那就值得保持
强化警报组构之实施
於固定周期或每班结束时
监视警报系统效能
连续不断地
定期维护警报系统
每6个月至1年
追踪任何主要的危害事件
保证组构的警报是致能的且合理设定
保持动态的抑制警报报表
维持一个警报资料库的所有者角色
不要流於使用者角色,应该掌握主控的维护能力
支持仅有资料库的拥有者才可变更资料库设定或维护资料
变更管制
追踪调查
假使行动有特定目的,追踪是唯一的方法来确认目的会被达成
追踪的目的
在工厂操作间以定量的方式定义警报系统变更的效果
回忆先前所使用的指标而现在我们又再度使用
识别效能较差的区域
方法论
修改后的警报系统已经完成警报效能评估
必要时与标竿比对,必要时重做或重新设计
寻找与确认
每天或每周鉴认无效警报
将问题传送给能够解的人员
操作人员—如果有被授权
区域工程师
仪控工程师
确认根本原因已解决
如何解决
计画的早期阶段应著手处理无效警报
当无效警报再次复发,必须持续不断地处理
设备老旧
制程状态改变
例如产量提升
调查泛滥与偏离
假如您圆满的完成工作,您可以解决问题...
确认事件
什麼,何时,谁在那儿,什麼即将发生,…
组成调查小组
工厂 / 制程
控制系统
仪表技术
操作
小组职责是决定肇因并建议矫正的工作内容
记得是寻找肇因而非病症
追究责任於技术上并无意义
首先—处理…
再次发生之无效警报
无效警报可能导致警报系统不稳定,并且占据少数,可贵的操作员的注意,以致无法认知警报
为避免此效应,操作员必须在一个所谓"CONTROLLED"的方式下暂时关闭(disable)无效警报
警报在横跨班别时不可以被关闭
当换班时,必须有关闭警报的清单
必须允许根本原因可以被侦测且可"治疗"
然后—治疗…
去除无效警报的根本原因
徵用工单
改变制程
必须定义一个管理程序
必须"发现(find)"然后"确定(fix)"无效警报("bad actors")
需要绩效监视工具来执行此事项
报告明列前矛的警报以追踪控管
以KPI (Key Performance Indicators)量测
制程必须维持自动化
E-mail通报范例
警报最适管理总结
好的警报管理应是几乎空白的警示萤幕
The Dark Screen Concept (no accumulation)
理想的警报管理地图(From Philosophy to Maintenance)
警报合理化
所有的盘面警报显示应一致
群组:使重大警报辨识更容易
去除Bulk acknowledge (安全考量)
变更管理 (MOC)
维护与持续获益
All Alarms are Important
All Alarms Require Operator Attention
制程改善检核问卷范例
你曾怀疑过现场量测数据有问题吗
你曾怀疑过整厂物料能量平衡有问题吗
你曾怀疑过线上分析仪的数据,而再到化验室重复确认吗
公司曾有过QC抽样化验合格,但客户觉得品质不佳的情形吗
厂内各单环路控制回路到底控制的够不够好 如何微调
厂内曾有过各控制回路均在设定范围内,但产品品质仍有待改进
厂内对制程状况(操作的顺不顺)有量化的评估标准吗
你曾感觉品质变异过大,但不知从何寻找原因吗
你曾觉得SPC管制图良好,但制程还是有些问题吗
你曾觉得监控系统的警报发放次数过多,但又不敢将警报点取消吗
你曾想知道过去有没有发生同样的异常状况,想参考过去如何解决的方式
你曾觉得若早一点知道制程快「跑掉」了,就可以有充足的时间应变了
你总觉得目前的操作条件还不够恰当,但又不知何种组合最好吗
程监控应用系统安全指引制定
暨警报管理系统效能改善计画
结案成果报告
报告人:游辉祥
E-mail: HueiShyangYOU@itri.org.tw
Tel: 0921073450; 03-5915008
志 谢
感谢台湾科学工业园区科学工业同业公会暨经济部技术处科技专案经费支持
感谢同业公会水电气供应委员会对本案之支持
感谢联华电子,旺宏电子,华邦电子暨计画参与成员之热心协助,赞助与指教
技术应用背景
制程异常损失
何谓制程异常状态
操作人员在当班的过程中遭遇到不可预期的事件或情况而导致操作人员对工厂的操作产生质疑或导致工厂操作不顺或受干扰
程序可能未受影响或产生足以被观察到的影响
操作人员可能不知道实际的制程状况
制程异常损失
1994 在 Texaco Milford 炼油厂所发生的爆炸及火灾,造成 26 人受伤,损失达 4 仟 8 佰万美金
意外事件有可能因为气候的因素,设备故障或操作人员的疏失所造成
经统计 50% 到 60% 石化厂的爆炸,损伤和意外的排放是因为人为的错误所造成的
一些无法预知的情况往往会造成许多微小但累积起来却相当昂贵的代价,譬如:肇因於设备或财产损坏的直接经济损失,导因於品质不良或减产之产品损失,生产进度或交货中断,人员伤害或环境损害等
每年全球工业因不当的异常操作损失可达 1000 亿美元
以美国石化业为例,其异常操作损失每年近 200 亿美元
制程异常损失(续)
PES安全标准或指引制定之重要性
HSE 调查结果显示
PES失误原因主要源自PES建造与设计阶段
43%之PES失误源自设计规格,其中
38%源自Hardware failure
7%源自Power supply problem
14%源自System and design problems [55%*(18%+7%)]
主要解决对策即为建立安全标准或指引,并严格遵守安全标准或指引来建造与设计PES
於建造与设计PES时完整考虑安全标准或指引之需求,其成本效益是100倍於日后之持续维护与修改设计
Texaco Milford 火灾爆炸案例 HSE 之调查结果显示
产生太多警报
警报无优先顺序处理的规划
不适当的控制画面设计,使操作员无法迅速找出问题所在
操作员缺乏足够的训练,无法应付紧急状况的发生
在爆炸发生前 11 分钟,仍有 275 个警报等待两位操作员逐一确认
PES维护与管理之持续获利策略为建立完整的警报最适管理技术与制度
PES: Programmable Electronic Systems
HSE: Health & Safety Executive, UK
制程异常状态
Potential
Impact
of
Initiating
Event
Time
Incident
Abnormal
Normal
Abnormal Situation Detected
SIS Activated
System Trip
冲击异常状态管理之因素
资料来源:修改自 Honeywell Hi-spec ASM相关资料
Source
Failure
Types
Unsafe Acts
Errors &
Violations
Condition
Tokens
Precursors
Functional
Failure
Types
Safety Information System
Interface
between the
organization
& the individual
Management
Workplace
Defences
General Failure Types
1-10 hit list
Proactive Design
SI Projects
Best Practices
PCM / ASM
ECM / EHM
Poor workplace
Design
High workload
Unsociable hours
Inadequate
training
Poor perception
of hazards
Control room
design
Workspace
Near miss
Auditing
Du Pont
Training
Workspace
Motivation
Attitude
Group Factors
Working Practice
Stylistic or Cultural
Indicators
Top Down:
Commitment
Competence
Cognizance
data collected &
analyzed
Diagnostic and remedial measures
Recommendations
保险界统计:
美国工业界仅设备损坏之损失
每年即超过22亿美元
600
30
10
1
虚惊事件
重大事故
程监控系统功能性安全设计实务
警报管理最适化实务
制程状态高阶监视与异常诊断技术应用
操作限值与设备限值管理
设备健康管理与预测性维修技术应用
线上决策支援系统
执行成果及技术扩散
教育训练
莅厂宣导
联电,旺宏,华邦电,力晶,台积电,奇美电
警报管理最适化技术研讨会
92/07/29,8/1~2: 33人次
厂务管理与控制系统功能性安全技术研讨会
92/11/11: 38人次19厂家
厂务管理与控制系统功能性安全检查实务说明会
92/12/23: 45人次16厂家
衍生推广
异常状态管理在操作效能提升技术研讨会
92/12/03: 38人次20厂家
监控设备功能性安全等级评核技术说明会 (PLC设备商)
93/03/30: 27人次10厂家 --- 力晶委办
厂务监控系统系统整合功能性安全技术说明会 (FMCS系统整合商)
93/04/07: 35人次13厂家 --- 力晶委办
功能性安全如何纳入厂务监控系统建置规范说明会 (厂务设备系统承揽商)
93/05/19: 24人次10厂家 --- 力晶委办
台湾洛克威尔自动化控制解决方案研讨会
93/05/13, 18, 20: 约超过200人次 --- Rockwell Automation主办
莅厂宣导
台积电FAC 2/5, 12A,旺宏电子FAC 1,悠景,铼徳,华映桃园总厂,奇美电LCD 4/5厂(新建案)
智权文件
PFD及SIL需求评估程序及准则
CHAZOP 评估机制程序文件
PES设置检核要项现场访谈问卷
安全联锁作动系统现况评估问卷检核表
控制元件与传输讯号安全考量现况评估问卷检核表
I/O与Controller模组现况评估问卷检核表
工作站与处理器现况评估问卷检核表
PES软体安全需求安全指引检核要项检核表
监控流程架构内其他组成元件安全指引检核要项访谈问卷
PES设置安全指引检核表
特气泄漏程监控系统安全指引检核表
无尘室程监控系统安全指引检核表
化学品供应程监控系统安全指引检核表
纯水程监控系统安全指引检核
警报管理最适化训练教材
结案执行报告
主要发现—监控系统设计
系统架构
未遵守FM 7-45, IEC 61508/61511, ISA SP84等标准进行设计
未遵循BPCS / SIS分离原则之设计理念
未依据SEMI S10 / IEC61508 / IEC61511 / FM 7-45建议之风险评估结果,评估每一个SIS环路SIL等级要求之需求规格选用及设计SIS
未遵照PLC原厂认证合格指令进行系统组构及设计
系统组构设计(含模组型号选用)未评估整体之PFD值 (亦即可靠度与可用度)
软体设计多数放弃原厂经过认证合格之编辑软体(IEC 61131)进行Logic设计
设计施工时未避免Common Cause Failure或未遵循原厂之设计SOP
I/O 模组, 线材及通讯介面在SIS部份未考量Fail Safe及安规认证需求
未评估系统紧急停车或Reset时之Fail-safe Mode如何维持
多数放弃原厂经过认证合格的主动/被动诊断功能及Watch Dog (如此将降低系统之可靠度)
ESD设计
未依据危害等级(火警[财产损失],特气泄漏[人员伤害],环保议题)之评估设计ESD
ESD之设计未遵照FM 7-45设计架构
ESD Button, 线材之选用未符合安规 (IEC 60947)
Safety Relay
Relay之选用未评估安规等级 (IEC 60255)
管理机制
未建立UAS评核机制选用监控设备系统相关组件(含SIS之Sensor, Final Element)
监控系统於纳入现场操作前未执行Functional Safety之评估与测试 (必须遵循IEC 61508/61511之建议进行)
SCADA HMI警报管理功能设计未遵循EEMUA No. 191/201
控制中心设计未遵循EEMUA No. 201, ISO/CD 11064
其他
软体应用系统架设层级未符合FM 7-45之规定
资讯安全解决对策有错误认知
主要发现—SIL等级需求略估
警报管理最适化
主要发现—警报管理问题
无全厂警报价值观与规范
警报发生时,操作员无须采取动作
小操作扰动确引起大量警报
明确的例行操作改变却引起大量无意义之警报
当无任何事件时亦有警报产生 (Nuisance alarms)
重大操作异常时引起无法处置之大量警报 (Alarm flooding)
当警报发生时操作员并非确定知道如何处置 (无建议措施)
有些警报常时期停留於面板
操作程序与警报动作无关
技术扩散
A厂自行进行无效警报评估,去除80%无效警报
B厂自行进行无效警报评估及Disable警报管理,进一步引用电子化工具管理警报系统效能
C厂委托ITRI协助导入完整的AMO技术实务,於新建案一并导入PES Safety Guides设计理念
D厂评估引用电子化工具管理警报系统效能
错误引用AMO技术
警报作动数目不是愈少愈好,是要让无效警报不出现,有用的警报作动数降低至合理可行的程度,并确保不会错失对异常状态的即时掌握
FY94规划
透过TSIA ESH技术委员会,成立Facility Standard Working Group,与SEMI Worldwide接轨,参与FMCS PES设计安全标准制定
ITRI将协助促成此事
附件
程监控系统功能性安全设计
改善建议汇整
SIL等级需求评核结果汇整表
四
三
二
一
项次
1
VOC废气处理程监控系统
1
Clean Room MAU程监控系统
2
Exhaust System 程监控系统
2
特气泄漏程监控系统
SIL需求等级
目标次系统
五
1
化学品供应程监控系统
六
≥1
DI Water供应程监控系统
改善建议汇整
程监控应用系统架构评核缺失
一般制程控制(BPCS)与安全仪表系统(SIS)的相关组成元件皆须分开设置
侦测器与最后控制及作动元件间不可经由"Data Highway"传输通讯
两者皆须直接连线(Directed-wired)至相同的逻辑处理器(SIS Controller)
执行联锁作动决策判断的功能不可由SCADA执行
分散式控制是功能性的分散,而非相同功能控制器的切割
可用度与可靠度仍须维持
SIL2的监控系统
相较於安全联锁作动控制器的多重设计(Redundancy)
以分散式设计将执行安全联锁作动功能的控制器切割成数个单一的控制器来分别执行同一监控系统但不同区域位置的监控,其可用度与可靠度并未提升反而降低
改善建议汇整(续)
程监控应用系统架构评核缺失
安全联锁作动系统之控制器与I/O模组之通讯联系,应采用下列方式设计:
若实务上许可,建议采用Local I/O (Backplane Connected)之设计规格
若实务上的因素,必须采用Local I/O与Remote I/O混合之通讯联系方式
Remote I/O之设计规格,建议采用具备UAS approved security and error checking功能之Remote I/O设计规格
设置於中央监控室的远端手动安全联锁作动人机介面(Remote EMO)应设置独立盘面,不要设置於操作员工作台
若采用一般制程控制用的阀做为安全联锁作动的最后关断元件
此阀必须遵循UAS (User-Approved Safety)的验证认可
改善建议汇整(续)
设备元件规格给定缺失
所有元件应为UAS
当使用端欲选用SIL1等级以上之设备元件时
不能仅选用符合UA (User-Approved) 的规格
是否符合UAS ,使用端公司内必须建立审核与判断基准的管理制度与程序来检视与讨论相关议题
供应商提供的设备元件可靠度与可用度书面资料,不能仅提供MTTF (Mean Time To Failure)数值
供应商所提供的设备元件可靠度与可用度书面资料方面,必须包括硬体故障容忍度(N),故障失效安全比率(SFF) , MTTR(Mean Time To Repair)等
改善建议汇整(续)
设备元件规格给定缺失
硬体故障容忍度定义
假设硬体故障容忍度为N,意谓此硬体当发生N+1个故障事件时,会造成安全功能的丧失
当评估此因素时必须假设此硬体没有其他可控制故障所造成安全功能丧失的方法,例如异常诊断的功能
当一个故障事件会序列性的间接导致其他一个或很多个故障事件的发生时,仅考量为单一故障事件
改善建议汇整(续)
设备元件规格给定缺失
安全故障失效比率(SFF, Safe failure fraction)的定义
安全故障失效(Safe failure)
可定义为此故障事件的发生不会导致安全功能的丧失
危险可被侦测得到的故障失效(Dangerous detected failures)
可定义为此故障事件的发生会导致安全功能的丧失
於失效发生时可经由其他可控制故障造成安全功能丧失之量测方法侦测得知
例如异常诊断的功能
SFF可定义为下列二项因子之比率值:
安全故障失效的平均发生率(Average rate of safe failures)与危险可被侦测得知的故障失效平均发生率(Average rate of dangerous detected failures)二者之和
硬体的总平均失误率(Total average failure rate)
改善建议汇整(续)
设备元件规格给定缺失
审核UAS的管理制度与程序可依据下列原则来拟订:
使用公司与产品制造商共同针对下列议题讨论并发展策略:
将商业产品应用於安全相关系统(例如SIS系统)时,所有可能潜在发生之问题及对安全相关系统的影响效应
产品制造商提供产品所有不安全之失误模示(Unsafe Failure Modes)
产品制造商已辨识出每一个不安全之失误模示,与可能发生频率
公司发展出相关之操作与维护计画,藉以使产品继续不断的符合操作安全需求
使用端检视商业产品之绩效
与目前相关产品之工程规范变更需求(Engineering Change Orders)做比较
评估过去此产品使用前之测试需求方法是否已不符合目前的规范标准所设定之测试标准
此产品过去已於相关应用领域成功适当的操作过
若上述的相关资料已评估考虑并符合所欲应用之系统需求,则此产品可视为User-approved Safety
改善建议汇整(续)
风险评估管理制度与机制的建立
SIL1以上程监控应用系统的设置与整合(System Integration),未使用下列任一方法执行系统潜在危害事件的辨识与风险分析:
失误树分析(Fault Tree Analysis)
失误模式与影响分析(Failure Modes effect and critically analysis)
事件树分析(Event Tree Analysis)
原因后果分析(Cause Consequence Diagrams)
蒙地卡罗模拟分析法(Monte-Carlo Simulation)
改善建议汇整(续)
风险评估管理制度与机制的建立
纳入操作前的验收测试必须包含下述项目的测试:
测试所有已规划於应用软体之安全逻辑功能(Input data is selected to exercise all specified functional cases)
包括异常错误发生时之处理功能
依据原因后果图之分析结果,测试所评估分析之异常事件
测试与执行边界值分析(Test cases from boundary values analysis)
建立定期测试安全仪表系统(SIS)的功能是否正常的测试制度(Passive diagnostics)来诊断SIS的故障
或於程监控应用系统内加入线上异常诊断功能(Active Diagnosis),可於要求SIS执行联锁作动前,预先发现异常并修复
改善建议汇整(续)
风险评估管理制度与机制的建立
建制审核供应商所提供设备元件硬体所属类别的机制,硬体分为A类与B类:
A 类硬体定义如下:
所有组成元件的失误模式已清楚完整的定义(The failure mode of all constituent components are well defined)
於发生故障事件的状况下,此次系统的应答行为能完整性的被评估考量(The behavior of the subsystem under fault conditions can be completely determined)
为了确认供应商所提供关於可侦测与无法侦测得知之危险故障失误率数值的正确性,可获取由实场操作经验统计得出可信赖的故障失误率资料来加以验证
符合上述原则,则可视为A类硬体
B 类硬体定义如下:
至少有一组成元件的失误模式没有清楚完整的定义
於发生故障事件的状况下,此次系统的应答行为无法完整性的被评估考量
无法获取由实场操作经验统计得出可信赖的故障失误率资料来加以验证确认供应商所提供关於可侦测与无法侦测得知之危险故障失误率数值的正确性
符合上述原则,则可视为B类硬体
改善建议汇整(续)
风险评估管理制度与机制的建立
依据目前园区厂务程监控应用系统现况,硬体极大部分可视为B类
依据IEC 61508-2(2000),IEC 61511-1(2003)等规范建议,若选用B类硬体於SIL1以上的程监控系统,可依据下表基准要求供应商符合SIL等级需求
改善建议汇整(续)
共同失效原因(Common Cause Failures)的避免
SIL1以上的程监控系统必须尽量避免任何可能的共同失效原因造成SIS的可用度与可靠度无法达到使用端需求:
若设置多重侦测器,则在不影响可靠度的情况下
应该依据多样性技术(Diversity)
选用不同类型的侦测器
例如:
不同供应商的产品,或
相同供应商但不同类型的产品
执行不同功能的控制器与监控系统的人机介面监控台做资讯传输的输出讯号建议不要通过相同的网路集线器(HUB)
PLC之应用程式软体建议不要同时执行PID控制
一般制程的序列控制(Sequence control)与安全联锁作动控制等逻辑功能
不同次系统的安全仪表系统(SIS)最好分开设置
避免因为共同使用的设备元件失效,造成共同失效原因的发生
改善建议汇整(续)
技术文件资料的提供,更新与保存
执行安全功能逻辑运算的PLC,供应商必须提供使用端逻辑运算功能清单,例如依据下列任何一种方式提供:
Logic/function block diagrams
Sequence diagrams
Data flow diagrams
Finite state machines/state transition diagrams
Time Petri nets
Decision/truth tables
程监控系统通讯联系架构图示与说明的书面资料
其他相关问题或建议
程监控系统基础架构
系统整合度
产品等级与确效验证
系统延展度与弹性
管理制度建立
控制室环境与管理
施工问题
接地
配接SIS相关量测元件,阀件与讯号线之规格要求
PLC SIS 逻辑失效模式分析与测试
可用度确保更胜於可靠度之要求
变更管理
安全评估与核可变更
附件
警报管理最适化
示范厂警报效能分析报告摘要
背警及尖峰警报分析结果
Note: B系统之特定原因已排除
静态组构分析结果
Average number of All alarms per day
Peak alarm rate
Top 29 Alarms showing cumulative contribution
Average number of all alarms per day excluding worst tag
Number of alarms type of each unit
Alarm ack number of All alarms per day
最佳实务
程监控系统功能性安全设计
Risk-based PES设计哲学
HSE, UK
针对不同类型工业34个代表性PES发生意外事故之原因进行探讨
ICI公司
收集分析7年内PES发生意外事故之原因
分析100件意外事故之原因
共通性结论
HSE公告说明PES发生意外事故之原因很多是来自技术上的原因
无论使用何种技术原理来设计PES
於系统生命周期之各阶段,若能依循工程与管理之安全需求,就能降低危害发生的机会
Design-in 的哲学
其成本效益约为日进行修改,变更设计或维护的100倍
Risk-based PES设计哲学(续)
前述数据分析结果显示
大部分PES意外事故之肇因於设置规划的初期阶段即潜藏
主要原因为不适当的设计需求与规格给定,其理由为
欲监控之系统或设备未执行危害风险评估
PES的设计规格不符合欲监控系统或设备之安全需求规格
大部分的意外事故原因并不是因为系统发生不可思议的失误模式,而是可事先分析与评估得知的
如果使用风险为依据(Risk-based)的设计原理
於系统生命周期的各阶段,使用系统化的危害评估方法执行评估,并於设置规划的初期阶段加入安全需求规格,就可有效降低危害发生的风险
如何降低PES风险
欲监控设备或设施
之潜在风险
必须完成的危害风险降低策略
危害事件
后果严重性
Risk Level
5*10-2 (1/Yr)
(before)
Probability of Failure
on Demand (PFD)
2*10-3
Probability of Failure
on Demand (PFD)
5*10-3
Risk Level
5*10-7 (1/Yr)
(after)
危害事件
发生频率
PES
安全功能失效
PES其他风险降低
保护层(IPL)失效
可容忍之
风险目标
依据SIL等级
设定软硬体规格
系统整合安全概念
Dike
Passive protection layer
Emergency response layer
Plant and
Emergency
Response
Process
Value
Normal behavior
Basic
Process
Control
System
Process control layer
Operator
Intervention
Process control layer
By APC or Alarms
Process alarm
Process
Shutdown
Trip level alarm
Safety
Instrumented
System
Safety layer
Emergency
Shut Down
Relief valve,
Rupture disk
Active protection layer
Prevent
(Pre-warning
Predicted
by PCM/ECM;
Corrected
by OAS)
Mitigate
x x
Taking the process to a safe state
when predetermined conditions are violated
安全整合等级
安全整合等级 (Safety integrity levels, SIL)
由安全整合需求决定安全整合等级
不同的安全整合等级有不同的安全功能操作绩效
安全整合等级可区分为4级 (SIL1~4)
等级1 (SIL1)为最低标准之安全功能操作绩效要求
等级4 (SIL4)为最高标准之安全功能操作绩效要求
等级愈高,则要求相关潜在危害事件发生的可能性须愈低
功能安全需求规格 (Functional safety requirement specification)
安全功能需求与安全整合等级需求两项共同组成设置程监控系统(PES)之功能安全需求规格
功能安全需求规格为设计安全相关的PES前,必须加以决定确认的
安全功能的安全整合等级需求与必须正确执行安全功能的设备元件有关
执行SIL评估之目的
评估欲监控设施可能潜在的危害风险,并依据风险管理原理,评估必须达成的设施危害风险降低量
依据上述必须达成的设施危害风险降低量,设定相关PES有效执行安全功能的可靠度或可用度需求(SIL等级)
由SIL等级需求设定PES的软硬体安全规格需求
可藉以达成符合国际要求或公司内部要求的危害风险管控标准
PFD及SIL需求评估程序与准则
O3
O2
O1
A
×
×
B
A
×
C
B
A
D
C
B
E
D
C
F
E
D
G
F
E
H
G
F
SIL等级
评估起点
C1
C2
C3
C4
E1
E2
E1
E2
P1
P2
P1
P2
PFD及SIL需求评估程序与准则(续)
PFD及SIL需求评估程序与准则(续)
PFD及SIL需求评估程序与准则(续)
SIS硬体及软体架构范围
SIS Logic
Solver
Output
Modules
Input
Modules
SIS Input
Devices
SIS Output
Devices
BPCS
Interface
SIS
HMI
SIS
Engineer's
Console
SIS设计考量因子
All fail-safe aspects
Including deenergized-to-trip (失能跳脱) versus energized-to-trip (供能跳脱) operation
Logic structures
Fault prevention / mitigation
SIS / BPCS separation
Diversity (差异,不同点,多样性)
Software considerations
Diagnostics (软体及硬体失效模式诊断)
Human / machine interface (HMI)
Communications
Such as the interface to the BPCS
逻辑结构
SIS Redundancy 可能设计
Logic
Solver
Sensor
Final
Element
1001
1002
2002
2003
1001
1002
2002
2003
1001
1002
2002
符合安全标准之PES设计建议架构
系统架构
FM 7-45
IEC 61508/61511
ISA SP84
PLC软体设计
IEC 61131
HMI软体设计
EEMUA No. 191/201
控制中心设计
ISO/CD 11064
Safety Relay
IEC 60255
ESD
IEC 60947
SIL1 SIS架构示意图
BPCS
Controller
BPCS
Controller
BPCS
Controller
"User Approved Safety" PES
Logic Solver
Final Control
Element
Sensor
BPCS
HMI
Data highway communications
BPCS
SIS
Note 1
Note 2
Note 3
Notes:
Communications between SIS and data highway adheres to separation criteria
SIS HMI is not shown
No data highway communications are permitted between the sensors and the final control element of an SIS. Sensors and final control elements that are interlocked to each other will be direct-wired to the same SIS logic solver
Availability Range: about 0.99
Logic Diagram
Sensor
Final Control Element
PES
Structure
Logic
Solver
SIL2 SIS架构示意图
BPCS
Controller
BPCS
Controller
BPCS
Controller
"User Approved Safety" PES1
Logic Solver
(Note 5)
Final Control
Element 1
(Note 5)
Sensor 1
(Note 5)
BPCS
HMI
Data highway communications
BPCS
SIS
Note 1
Note 2
Note 3
Notes:
Communications between SIS and data highway adheres to separation criteria
SIS HMI is not shown
No data highway communications are permitted between the sensors and the final control element of an SIS. Sensors and final control elements that are interlocked to each other will be direct-wired to the same SIS logic solver
For diagnostic purposes, redundant sensor values are available to each logic solver and/or the BPCS
Sensor, logic solver, and/or final element may be redundant as availability and and reliability
Availability Range: about 0.99 to 0.999
Logic Diagram (Note 5)
Structure
Logic
Solver
Note 4, 5
Symbol
A
AND Gate
A
A
Final Control
Element 2
(Note 5)
"User Approved Safety" PES2
Logic Solver
(Note 5)
Sensor 2
(Note 5)
Sensor
1 (and 2)
Final Control Element
1 (and 2)
PES1 / PES2
SIL3 SIS架构示意图
BPCS
Controller
BPCS
Controller
BPCS
Controller
"User Approved Safety" PES1
Logic Solver
Final Control
Element 1
Sensor 1
BPCS
HMI
Data highway communications
BPCS
SIS
Note 1
Note 2
Note 3
Notes:
Communications between SIS and data highway adheres to separation criteria
SIS HMI is not shown
No data highway communications are permitted between the sensors and the final control element of an SIS. Sensors and final control elements that are interlocked to each other will be direct-wired to the same SIS logic solver
For diagnostic purposes, redundant sensor values are available to each logic solver and/or the BPCS
Caution: PES1 & PES2 are not SIL 1 PESs. See the special requirements shown herein
Availability Range: about 0.999 to 0.9999
Logic Diagram
Structure
Logic
Solver
Note 4
Symbol
A
AND Gate
A
A
Final Control
Element 2
"User Approved Safety" PES2
Logic Solver
Sensor 2
Sensor
1 and 2
Final Control Element
1 & 2
PES1 / PES2
Note 4
Logic
Solver
Sensor
1 and 2
Final Control Element
1 & 2
PES2 / PES1
配电架构示意图
最佳实务
如何将功能性安全设计要求
置入工程招标规范内
系统使用端规格与预算拟定程序
挑选合适设备系统供应商
供应商提出计画书草案
使用端审核系统设备供应商所提计画书草案
确认SIS Logic数目与范围
规格与预算拟定
系统设备供应商依据最后定案的规格
研提正式计画书
引用UAS机制
引用PHA结果
SIS架构设计
SIS元件选用
采购订单
采购需求
计画书草案内容
BPCS / SIS Logic归属之划分
系统商或设备供应商可依据安全评估程序进行判定或根据经验初步给定
提交依据安全评估程序进行判定或根据经验初步给定之相关文件资料
系统商或设备供应商依据其危害辨识结果提交危害辨识与风险分析相关之安全资讯文件
说明其风险评估依据及评估流程
此部份可视实务状况进行必要之补
提交制程流程说明(含开停车流程,维护保养制度SOP),管线仪表图,控制回路清单,安全资讯(本质安全资讯,设计技术资讯,设备规格资讯)等文件
此部份可视实务状况进行必要之补件
计画书草案内容(续)
清查所有仪控AI/O, DI/O表列清单,清单表格栏位至少涵盖下列项目:
Tag ID
Tag Type
System or Area
Description
Engineering Unit
Range
Used by what BPCS Logics
Used by what SIS Logics
BPCS Logic 清查,清单表格栏位至少涵盖下列项目:
Logic ID
Input Tags (Highlight Tag Types)
Output Tags (Highlight Tag Types)
Functional Block Diagram — Appendix
Logic Instruction — Appendix
计画书草案内容(续)
SIS Logic 清查,清单表格栏位至少涵盖下列项目:
Logic ID
Input Tags (Highlight Tag Types)
Output Tags (Highlight Tag Types)
Functional Block Diagram — Appendix
Logic Instruction — Appendix
计画书内容必须说明每一个SIS Logic的SIL等级定义,提供佐证的认证资料与说明
计画书草案内容(续)
计画书内容必须说明报价参考基准,点数依据,SIS 环路数目依据与BPCS 环路数目依据等
计画书内容必须包括警报点规划说明,并 清查所有Alarm Tags,与整理成清单表件,清单表格栏位至少涵盖下列项目:
Alarm Tags
Tag Type
Description
Design Purpose
Priority Assessment —依据Alarm Priority Assessment准则
Parameter Setting建议
计画书内容必须说明是否有防爆区域与防爆等级的规划与设计
警报优先权组态评估基准范例
计画书草案内容(续)
计画书内容必须说明每一个SIS Logic的硬体设计架构,可依据下列的 SIS Logic表列清单方式说明
计画书草案内容(续)
计画书内容必须包括警报点规划说明,并 清查所有Alarm Tags,警报点规划组构清单填写范例请参考下列表格
计画书草案审核
使用客户成立计画书审议小组
针对下列计画书内容进行审议与建议事项,并与系统商或设备供应商达成结论共识:
BPCS Logic 清查
SIS Logic 清查
由系统商或设备供应商所提供的 PID初稿
由系统商或设备供应商所提供的AI/O, DI/O, Logic Table (Including BPCS & SIS)初稿
由系统商或设备供应商提供Functional Block Diagram (Including BPCS & SIS) 初稿
BPCS 与 SIS Logic归属之划分
依据安全评估程序进行判定或根据经验初步给定
为保留采购议价完成后,实施阶段之变更弹性
使用客户需要保留一定比例之变更设计弹性
例如10% Logic数/总体Logic数,系统商或设备供应商可据此报价并控管承接风险
最佳实务:警报管理最适化
第零阶段:认知
警报管理最适化要素地图
事件的种类
Potential
Impact
of
Initiating
Event
Time
Abrupt/Catastrophic
Insidious
Manageable
操作员是站在最前线的
Most operators' view of what's really happening in the field is limited by the "system"
Process Conditions and control signals
Almost NO EQUIPMENT CONDITION
DCS / SCADA
Field
操作员是核心角色
进阶
控制
警报
不在场(场外)
(操作)程序
阀件
问问自己:
程监控系统支援这些功能
到底有多少
现场
作业员
政策
制程
感测元件
商业议题
警报
警报
我记得有15个警报
在那儿已经很久了
我想要知道我必须做什麼
假如高压警报跳车再次发生
这个画面上有23个警报
有效的应变反应
Potential
Impact
of
Initiating
Event
Time
Incorrect
Response
Best
Sub
Optimal
Good Decision Support
Reduces errors
Decreases time to implement response
Manages side effects
Increases awareness
No
Response
警报管理改善程序
警报管理改善程序之目标
在正常操作下,降低警报作动数目至可接受程度
确认警报在目前的操作内涵下是有意义的
最小化驻留警报数目以促成"dark screen"操作
确信在异常状态下警报之产生有助於操作员在最少的时间中安全地稳定制程
以管理系统来避免警报系统效能不会随时间消逝而递减
解决对策建构区块1
警报效能评估(APA)
操作员错失警报之风险为何
每一个问题区域之相对贡献为何
导致警报尖峰的原因是什麼
无效警报 -->"操作员抑制"接著"处理与治疗"
直接序列 -->"动态抑制"
"涟漪效应(Ripple-effect)" -->"优先层级管理"
设定改善之优先顺序
减少无效警报最有效的改善对策是什麼
警报再评估是否需要
假如是,在那个区域
如何循序进行
良好参数设定的要点为何
建议什麼型态的抑制技术
执行APA之工具
背景警报率
尖峰警报率
坏份子(Bad Actor)识别
改善绩效评估
解决对策建构区块2
警报系统设置之责任区分
警报通则
定义某厂或某组织之警报实施与管理之基本原则
巩固所有警报管理工作之基础
必须是一份有用的文件
警报设计准则 – 范例
每个警报均应具备提醒,通知与指导的功能
避免警报组构倾向多设
呈现给操作员的每个警报均应有用且具关联性
避免无效警报(Nuisance Alarms)
每个警报均应有既定的应变措施
每个警报皆应采取行动(Action)
透过管理制度与训练之执行避免人为失误发生
应有充分的时间使操作员完成应变措施
合理的警报界限设计
了解操作极限及制程之偏离演变过程
透过训练与经验传承
每个警报系统应明确在人员操作极限下进行组构设计
人因考量以避免操作人员过负荷
避免抱怨(Complaining)式警报
去除无效警报
警报优先权组态评估基准
解决对策建构区块3
警报再设计评估
也被称为"警报目标分析"
目的
去除不需要的警报 -->清仓
设定警报优先层级以管理"涟漪效应"警报
检视设定 -->避免不合适之参数设定
定义要求规定以执行警报抑制
资源投入与缓步进行
降低背景警报率约50~70%
可使用警报效能分析报告来聚焦或循序进行
去除大部份stale之驻留警报
除非聚焦讨论,否则对尖峰警报没有太多影响
警报再设计评估程序
传统上每个警报都进行评估
耗力费时,成效缓慢
循序进行 -->采用警报效能评估辅助
Top down / bottom up / fight for survival
绩效可以直接评估
可在数周内见效而不必耗时逾年
以资料库的方式记录文件
类似CHazOp的参与成员与评估方式
process eng, ops, control eng, facilitator
警报优先层级
使"critical"警报清楚可见
采用工具管理警报系统的两个面相
在正常操作时,关注工厂的效率
在异常操作时,关注工厂是否仍然在线上
低优先层级警报可以在危机发生时暂时地被忽略
以优先层级排序进行评估,则低优先层级警报会排在后面
高及中等优先层级警报在制程偏离一开始时,帮助操作员处理紧急的工作
采用有效的工具来管理警报泛滥的问题
解决对策建构区块4
什麼是警报抑制
以软体控制抑制警报
抑制的警报仍可於画面上看到及Journal上看到
通常需要与第一次警报互相关联
必须可以
从备用设备中去除驻留警报,以达成"dark screen"操作
减少警报泛滥
帮助确信仅有相关的警报被显示
警报抑制
标准确认
警报效能评估 (也就是尖峰警报分析)
警报再设计评估
持续分析警报泛滥
警报通则之捕抓原理
抑制
序列警报("动态抑制" -->自动)
离线设备警报("静态抑制" -->自动或手动)
无效警报(手动控制)
Mode-dependent警报
改变警报设定或依据设备操作型态关闭警报
软体设计做法
需要依循标准或安全评估
警报系统重新设定实施步骤
通告设计及签认(独立评估小组)
设定双(反)向计画
图面重新设计
执行DCS / SCADA资料库变更(时程掌控)
前置测试图面及组态
表达停止(反向)计画
确认实施
事后稽核
依所需修复及修订
维持最新文件
警报变更管理制度
(1) 目的
为避免厂内制程警报之变更影响到操作人员的操作及处理行动,而引发制程危害事件,影响人员安全卫生,造成设备损坏或是其他不可接受之风险,特制定此程序
(2) 范围
凡厂内涉及下列与制程警报有关之改变,均应遵守本作业程序:
(A) 警报之失能或关闭(Disable)
(B) 警报之新设或删除
(C) 警报之优先权,设定点,参数及显示方式等的修改
(D) 警报之处理行动(Action)的修改
(E) 其他未有书面程序规范其执行方式之制程警报的改变
解决对策建构区块5
持续获益
假如这是值得做的事,那就值得保持
强化警报组构之实施
於固定周期或每班结束时
监视警报系统效能
连续不断地
定期维护警报系统
每6个月至1年
追踪任何主要的危害事件
保证组构的警报是致能的且合理设定
保持动态的抑制警报报表
维持一个警报资料库的所有者角色
不要流於使用者角色,应该掌握主控的维护能力
支持仅有资料库的拥有者才可变更资料库设定或维护资料
变更管制
追踪调查
假使行动有特定目的,追踪是唯一的方法来确认目的会被达成
追踪的目的
在工厂操作间以定量的方式定义警报系统变更的效果
回忆先前所使用的指标而现在我们又再度使用
识别效能较差的区域
方法论
修改后的警报系统已经完成警报效能评估
必要时与标竿比对,必要时重做或重新设计
寻找与确认
每天或每周鉴认无效警报
将问题传送给能够解的人员
操作人员—如果有被授权
区域工程师
仪控工程师
确认根本原因已解决
如何解决
计画的早期阶段应著手处理无效警报
当无效警报再次复发,必须持续不断地处理
设备老旧
制程状态改变
例如产量提升
调查泛滥与偏离
假如您圆满的完成工作,您可以解决问题...
确认事件
什麼,何时,谁在那儿,什麼即将发生,…
组成调查小组
工厂 / 制程
控制系统
仪表技术
操作
小组职责是决定肇因并建议矫正的工作内容
记得是寻找肇因而非病症
追究责任於技术上并无意义
首先—处理…
再次发生之无效警报
无效警报可能导致警报系统不稳定,并且占据少数,可贵的操作员的注意,以致无法认知警报
为避免此效应,操作员必须在一个所谓"CONTROLLED"的方式下暂时关闭(disable)无效警报
警报在横跨班别时不可以被关闭
当换班时,必须有关闭警报的清单
必须允许根本原因可以被侦测且可"治疗"
然后—治疗…
去除无效警报的根本原因
徵用工单
改变制程
必须定义一个管理程序
必须"发现(find)"然后"确定(fix)"无效警报("bad actors")
需要绩效监视工具来执行此事项
报告明列前矛的警报以追踪控管
以KPI (Key Performance Indicators)量测
制程必须维持自动化
E-mail通报范例
警报最适管理总结
好的警报管理应是几乎空白的警示萤幕
The Dark Screen Concept (no accumulation)
理想的警报管理地图(From Philosophy to Maintenance)
警报合理化
所有的盘面警报显示应一致
群组:使重大警报辨识更容易
去除Bulk acknowledge (安全考量)
变更管理 (MOC)
维护与持续获益
All Alarms are Important
All Alarms Require Operator Attention
制程改善检核问卷范例
你曾怀疑过现场量测数据有问题吗
你曾怀疑过整厂物料能量平衡有问题吗
你曾怀疑过线上分析仪的数据,而再到化验室重复确认吗
公司曾有过QC抽样化验合格,但客户觉得品质不佳的情形吗
厂内各单环路控制回路到底控制的够不够好 如何微调
厂内曾有过各控制回路均在设定范围内,但产品品质仍有待改进
厂内对制程状况(操作的顺不顺)有量化的评估标准吗
你曾感觉品质变异过大,但不知从何寻找原因吗
你曾觉得SPC管制图良好,但制程还是有些问题吗
你曾觉得监控系统的警报发放次数过多,但又不敢将警报点取消吗
你曾想知道过去有没有发生同样的异常状况,想参考过去如何解决的方式
你曾觉得若早一点知道制程快「跑掉」了,就可以有充足的时间应变了
你总觉得目前的操作条件还不够恰当,但又不知何种组合最好吗
·上一篇：校园网解决方案
·下一篇：我也能完成一个解决方案!