迎合自动驾驶发展趋势 ISO 26262标准把关车辆安全
随着世界各地自动驾驶车辆上路测试的新闻，让人们对未来运输充满新的愿景，也牵引出如何确保车辆安全的议题，因此ISO 26262车辆电机/电子系统(简称车电系统)之功能安全(Functional Safety)国际标准应运而生。
在自动驾驶车上市之前，先进驾驶辅助系统(ADAS)成为最新车款的标准配备，此类车电系统已由高阶豪华车种，普及到入门平价车款，以因应日渐高涨的安全意识，与逐步完善的安全法规。
根据财团法人车辆研究测试中心(ARTC)产业调查数据[车辆研测信息2015/8]显示，2013年全球ADAS销售为1.24亿套，产值约为147.6亿美元，预测至2018年全球销售将提升至3.55亿套以上，产值也将超过350亿美元，全球ADAS市场成长二倍，而其复合成长率为19.2%。
为协助车辆产业与电子产业参与ADAS产值跃升的趋势，ARTC开发多项车电系统，如紧急煞车辅助系统(Advanced Emergency Braking System, AEB)，研发之雏型性能优异，已对国内业者技术移转，为确保符合消费市场注重之安全议题，在2015年12月通过ISO 26262功能安全流程认证，使开发产品可能的危害风险降到最低，系统功能安全符合国际标准。
ISO 26262功能安全标准剖析
ISO 26262是国际标准化组织(ISO)2011年公告最新车电系统之功能安全国际标准，与车辆安全相关的车电系统均被要求须实现之，本标准是调适自IEC 61508，将功能安全聚焦在车辆议题。ISO 26262提供车辆安全生命周期各阶段重要活动、车辆专属风险基础之整合水平、避免不合理风险的应用需求、确保合适安全水平之验证与确认，以及与供货商的关系需求等。
有关功能安全，最初的国际标准是国际电工委员会(IEC)1998年公告的IEC 61508，针对一般工业领域的电机/电子/可程序电子(Electrical/Electronic/Programmable Electronic, E/E/PE)相关系统之功能安全评估与管控方法加以规范，而车电系统与一般工业用E/E系统有着一些差异，如成本考虑或可靠度要求等，因此在2011年公告专属车辆领域之国际标准ISO 26262，其适用于3.5吨以下客车(M类)所装载之车电系统，本标准使得研发项目清楚定义功能安全相关系统、硬件与软件所应遵循的共同目标，并明确标示系统达成的安全门坎，可作为保安设计之产品开发数据。
近年来，功能安全是否适用其他车辆种类，如货车(N类)或是机车(L类)、如何调适车电系统之零组件如微控制单元(MCU)认证需求、或是ADAS系统防护黑客入侵的保全(Security)议题，均将纳入2016年新修的标准草案，以期满足车辆使用之最新需求。
ISO 26262标准概述
ISO 26262涵盖车辆整个生命周期，称为安全生命周期(Safety Lifecycle)，由管理、开发、生产、经营、维修至报废皆有相应的要求，本标准包含十个章节，计有Part 1名词解释(Vocabulary)、Part 2功能安全管理(Management of Functional Safety)、Part 3概念阶段(Concept Phase)、Part 4产品开发在系统层级(Product Development at the System Level)、Part 5产品开发在硬件层级(Product Development at the Hardware Level)、Part 6产品开发在软件层级(Product Development at the Software Level)、Part 7生产与操作(Production and Operation)、Part 8支持流程(Supporting Processes)、Part 9车辆安全完整性等级导向与安全导向分析(Automotive Safety Integrity Level-oriented and Safety-oriented Analyses)、Part 10 ISO 26262指南(Guideline on ISO 26262)。
ISO 26262实行所谓车辆安全完整性等级(ASIL)的指针来评估车电系统符合之功能安全程度，使得研发项目清楚定义功能安全相关系统、硬件与软件所应遵循之共同目标，明确标示ASIL可作为产品开发之安全目标。ASIL由严重度(Severity)、暴露机率(Probability of Exposure)与可控度(Controllability)决定，等级分为QM(Quality Management)与ASIL A至D五种，QM等级无须适用ISO 26262，比照一般车辆产业质量管理系统ISO/TS 16949要求即可，而ASIL等级愈高，系统功能安全要求愈多，故ASIL D设计开发的安全考虑最严密。
何谓产品安全生命周期
车辆产品的安全议题，要包含功能导向与质量导向之开发活动与工作产品，ISO 26262正是清楚定义研发项目的功能安全相关系统、硬件与软件所应完成之开发活动与工作产品，形成产品的安全生命周期之各个阶段(图1)，完整标准架构即成为车辆开发模型(V-model)。
图1 安全生命周期(Safety Lifecycle)
安全生命周期涵盖ISO 26262 Part 2至Part 7，整个生命周期分为概念阶段、产品开发与生产交付后等三阶段，由综合说明之功能安全管理起始，往下就是大V-model开始之概念阶段，接续是产品开发在系统层级、产品开发在硬件层级、产品开发在软件层级与结束之生产与操作，其间产品开发在系统层级包含产品开发在硬件层级与产品开发在软件层级两章，形成系统、子系统的阶层架构，而软、硬件开发又各成一小V-model，两者并有相互关联，确保系统开发是软硬兼顾。
ISO 26262安全生命周期之细项，依章节如下：2-5 Overall safety management、2-6 Safety management during the concept phase and the product development、2-7 Safety management after the item's release for production、3-5 Item definition、3-6 Initiation of the safety lifecycle、3-7 Hazard analysis and risk assessment、3-8 Functional safety concept、4-5 Initiation of product development at the system level、4-6 Specification of the technical safety requirement、4-7 System design、4-8 Item integration and testing、4-9 Safety validation、4-10 Functional safety assessment、4-11 Release for production、5-5 Initiation of product development at the hardware level、5-6 Specification of hardware safety requirements、5-7 Hardware design、5-8 Evaluation of the hardware architectural metrics、5-9 Evaluation of safety goal violations due to random hardware failures、5-10 Hardware integration and testing、6-5 Initiation of product development at the software level、6-6 Specification of software safety requirements、6-7 Software architectural design、6-8 Software unit design and implementation、6-9 Software unit testing、6-10 Software integration and testing、6-11 Verification of software safety requirements、7-5 Production、7-6 Operation, service。
另外，Part 8与Part 9之细项包括：8-5 Interfaces within distributed developments、8-6 Specification and management of safety requirements、8-7 Configuration management、8-8 Change management、8-9 Verification、8-10 Documentation、8-11 Confidence in the use of software tools、8-12 Qualification of software components、8-13 Qualification of hardware components、8-14 Proven in use argument、9-5 Initiation of product development at the system level、9-6 Specification of the technical safety requirement、9-7 System design、9-8 Item integration and testing。
ISO 26262融入CMMI-DEV流程
ISO 26262只专注于功能安全，与适用于发展的能力成熟度整合模式(CMMI-DEV)之等级2或3(ML2/ML3)流程相当，两者搭形成完整的路线图(Road Map)，才能有效导入组织运作。CMMI-DEV为美国软件工程学院(SEI)自1984年起所发展的一套组织质量管理标准，以确保软/硬件产品的研发质量，已广为世界各研发组织流程改善所遵循；而2004年另一套标准ISO/IEC 15504，就是俗称SPICE(Software Process Improvement and Capability dEtermination)，此软件流程改善与能力检定是与CMMI-DEV相当的系统工程要求。
功能安全技术搭配系统工程之路线图，形成完整的机制，为研发流程融入功能安全之可行方案，以满足车电系统安全又可靠的需求，CMMI-DEV与ISO 26262的关联汇整如表1所示，ARTC透过ML3流程与安全生命周期之相互关联性，融合两者建立完整的开发机制。
表1 CMMI-DEV与ISO 26262关联
检视ISO 26262流程认证的ARTC案例
ARTC研发质量管理流程符合ISO 9001与CMMI-DEV ML3，也着手将功能安全融入ML3流程，让研发项目形成由组织支持专业分工的系统工程团队。为因应车辆电子产业最新功能安全标准(ISO 26262)，已于2015年历经功能安全训练与落差分析、功能安全文件准备与融入流程、功能安全流程认证等作业，最终在年底12月份通过ISO 26262流程认证，进一步呼应车电产业的安全需求。
标准训练与落差分析
ISO 26262为车电系统功能安全之流程/产品认证标准，ARTC为服务车电产业需求，基于科专计划所开发技术，均须再行移转车辆电子产业商品化，确立只进行ISO 26262流程认证，开始与台湾检验科技股份有限公司(SGS)合作内训项目，从2014年起对研发同仁开办多场ISO-26262标准训练，也有6人通过车辆功能安全专业人员(Automotive Functional Safety Professional, AFSP)专业证照，此证照为3年效期，可用工作实绩加以延长。接着，2015年项目重点为安全生命周期V Model左半段(图2)，进行落差分析、功能安全管理、功能安全概念与技术安全概念等阶段，预计年底完成ISO 26262功能安全流程认证，以因应后续技转产品认证需求。
图2 ISO 26262功能安全认证流程
因应功能安全流程认证项目，选择AEB为试行标的，并组成安全小组，依第三方认证单位要求，安全经理(Safety Manager)应由非AEB计划成员担任，其主要负责项目为选择计划成员、建立并维护项目安全计划(Safety Plan)、管理内部接口(各部门)与外部接口(SGS台湾与德国专家，合称SGS-TüV)。
完整团队组成与分工包括：第三方(I3)负责流程认证(含辅导与咨询)；工作产品审核(PM)项目计划之部门主管负责；安全经理(SM)负责安全计划；计划主持人(PL)负责计划执行规划书(IPEP)；系统工程师(SE)负责系统规划，包含项目定义(Item Definition)、危害分析与风险评估(HARA)、安全目标(Safety Goals)、技术安全需求(TSR)；软/硬件工程师(DE/SW/HW)负责硬件规划，承接系统层级之功能安全需求(FSR)，转为软/硬件层级之设计文件；测试工程师(TE)负责测试规划，承接系统层级之FSR，转为测试文件。
SGS-TüV落差分析(Gap Analysis)作业为期两天，由SGS-TüV稽核员(简称主评)对ARTC研发项目流程、AEB计划数据与ISO 26262功能安全标准要求之122项工作产品加以比对，将落差评比分为四类成熟等级(Maturity Level)：符合(OK)、部分符合(Conditionally OK, COK)、尚未符合(Not OK, NOK)与无须符合(Tailored)等，提供第二阶段文件准备之参考，目标完成部分符合与尚未符合之工作产品。
功能安全文件准备与融入流程说明
准备功能安全系统、硬件与软件层级之设计与测试文件，逐步进行V Model左半段之功能安全管理、功能安全概念与技术安全概念等阶段，由安全小组依专业分工，完成各项工作产品，并与SGS专家讨论相关产出，以对应落差分析之主评建议，也以AEB试行计划制定功能安全融入研发流程之可行方案。
首先是V Model的功能安全管理阶段，由安全经理完成安全计划并定期更新，故此项工作产品会在数据纪录表各个章节重复出现，以表现安全计划的最新进度或内容修订。安全计划主要包含项次、标准章节、内容、输入文件、输出文件、负责人、起/迄时间与备注等，这些项目同样与ISO 26262标准要求之工作产品一致，如此逐项检讨安全计划，就可完成功能安全要求，此一安全计划采用附件形式纳入计划执行规划书(Integrated Project Execution Plan, IPEP)。计划主持人也在IPEP新增安全经理之专业分工，因须由非计划成员担任，故列在计划成员之上，以显示其独立性。
另外，为查证各项工作产品，须制定功能安全评估计划(Functional Safety Assessment Plan)，其不同于安全计划，研发流程已透过里程碑审查，进行工作产品的查证，故功能安全评估计划可与里程碑审查整合，又因为ISO 26262针对工作产品之确认措施，皆不可由该工作产品之相关人员执行，所以规划须依Part2车电系统之ASIL执行分级查证，如表2所示。
表2 执行确认措施所需之独立性
研发项目之IPEP包含许多流程次计划，如文件管理、计划监控管理、风险管理、建构管理、流程与产品质量保证、度量与分析、供货商协议管理、查证与确认等，这些次计划与Part8之供货商、建构管理、变更管理、文件章节要求一致。
再来是V Model的功能安全概念阶段，应在项目定义说明文件目的、AEB之功能与目的、功能方块图、边界条件与内/外部接口、安全与可靠度之潜在冲击来源、其他需求(含环境条件)、法规与标准、外部措施与最小风险，这些内容与IPEP之计划目标与范围、假设与限制，产品规格需求书(SRS)之产品介绍、产品用户、产品范围、客户的期望、限制与接口、系统架构等重复，由系统工程师整理为英文的数据，整合式计划管理(IPM)与需求发展(RD)流程维持原订之IPEP与SRS。
危害分析与风险评估(Hazard Analysis and Risk Assessment, HARA)是指车辆因电子电机系统故障所产生的风险，如非预期加速、非预期减速或燃烧/爆炸等，透过故障所生风险之严重度(S)、暴露机率(E)与可控度(C)三项参数，分析车辆安全完整性等级(ASIL)，共有五阶段度量(QM、A、B、C、D)之整车层级安全目标(Safety Goal)，自ASIL A开始，必须采取额外之风险降低措施，而ASIL D表示最高之潜在风险。
以AEB计划所得HARA为例，总计33项整车故障之危害，因不同的操作情境、潜在危害、可能失效与外部减轻等，依据Part3决定ASIL，如某一项危害是非预期加速，其严重性为S3、发生机率为E4与可控性为C2，所以ASIL为C，各项ASIL取最高阶段度量也是ASIL C，代表AEB的ASIL就是C。依前列表2，HARA工作产品须经第三方(I3)查证，SGS专家多次检讨各种AEB危害情境之S/E/C三项参数的想定，确认AEB之ASIL为C。
功能安全概念(Functional Safety Concept, FSC)是依据HARA所得高层之安全目标(安全目标可能与数个危害相关，也可能数个安全目标与一个危害相关)，规范系统之功能安全需求(Functional Safety Requirements, FSR)，并推导功能安全参数(包含安全状态、容许故障时间等)，加以配置至相关组件的活动，另外，因应车电系统量产的成本考虑，ISO 26262制定ASIL分解(Decomposition)作法，将ASIL需求分配到数个组件中，使得单一需求可以降低，这只在项目架构中，被分解组件存在足够独立性条件下才能施行，可以透过「相依性」故障分析，确认独立性之存在。
以AEB计划所得FSC为例，总计有9项安全目标，建立25项FSR，如第1项安全目标(SG1)与FSR1、FSR2、FSR3、FSR15、FSR16建立相关，而单一FSR也与多个安全目标相关，如第1项功能安全需求(FSR1)与SG1、SG3、SG4与SG5相关，SG与FSR非属直线关系，而是交互关联。
最后是V Model之技术安全概念阶段，延续系统之功能安全需求展开为软/硬件之功能安全需求规格，由系统工程师完成技术安全需求(Technical Safety Requirements, TSR)，再交开发工程师制定软/硬件技术安全需求之规格，进而迈入V Model的设计与整合测试阶段。
以AEB计划所得TSR为例，总计有64项TSR，如第1项TSR(TSR1)与FSR 1至FSR 9相关，系统工程师也订定容许故障时间、分配组件与软/硬件单元，以利后续软/硬件开发工程师加以设计，再辅以测试工程师进行整合测试，确认AEB功能安全需求已经实现。
进行功能安全流程认证
为确保SGS-TüV至ARTC进行ISO 26262功能安全流程认证顺利，10月底先以电话会议进行预评，德国主评检讨安全经理所提报资料，包含会前询问中心安全文化与建构管理机制，德国主评对安全小组执行状况的评价良好，只请小组补充计划训练规划与修正工具安全评价(Tool Confidence Level, TCL)档案，并约12月初办理流程稽核(Process Audit)。
为期一天的流程稽核作业，安全经理以流程稽核简报，逐项说明工作产品之执行状况，德国主评对ARTC研发流程表示很好，符合ISO 26262标准，对于各项工作产品，建议注意可读性(Accountability)、可追溯(Traceability)与透明度(Transparency)等数据属性，如同ISO 9001标准之说写作一致要求，并强调安全文化，以期中心的研发项目能更完整对应功能安全。
SGS-TüV在2015年12月中旬签署与发行功能安全流程认证证书(证书编号为FS/71/220/15/0112)，代表ARTC通过ISO 26262功能安全流程认证，此证书是依稽核报告(Audit Report Process)发行。而稽核报告需德国认证单位(Deutsche Akkreditierungss- telle GmbH, DAkkS)授权才能发行，此一关系如同台湾各检测实验室需获全国认证基金会(TAF)认证，所发行之检测报告才能追溯至国际系统。
获颁认证，不仅展显ARTC在研发上的专业，更是对国内汽车电机、电子系统技术水准的肯定，因为ARTC各项研发系统雏型均具备初步功能安全设计与测试数据，在技转予厂商后可缩短开发认证时程，让车电系统更接近世界需求，在开发的前端协助完成了最后一哩路的规划，将加速技术商品化进程，符合车厂对功能安全要求，进而快速加入供应链。
编辑：admin 最后修改时间：2017-09-19
