汽车的电气化和电动汽车的发展，自动驾驶、智能汽车已经出现。这些使得电子电气系统在汽车领域的应用比例越来越大，对安全的影响也就越大。

在系统越来越复杂的事实面前，电子电气功能开发的系统化，对安全考虑的系统化，是预防系统性失效的必要手段。ISO26262站在系统和全生命周期的高度，统筹电子电气系统的功能安全，从提出产品概念阶段开始，覆盖系统开发、硬件开发、软件开发、生产运行和售后支持，以系统的方法，指导产品全生命周期的安全事项的实施。

ISO 26262标准提供了给系统产品划分安全等级的具体方法，使得全行业得到一个统一的参考系。全部信息都会以文档的形式留存，形成可以追根溯源的产品安全管理系统。标准还提供了审核方法，使安全体系形成闭环。

总体来说，功能安全是指避免由系统功能性故障导致的不可接受的风险。它关注的是系统发生故障之后的行为，而不是系统的原有功能或性能。因此功能安全的目的就是当系统发生故障后，将系统进入安全的可控模式，避免对人身、财产造成伤害。

 系统安全可以从大量的安全措施中获得，包括各种技术的应用（如：机械，液压，气动，电力，电子，可编程电子元件）。尽管ISO26262是相关于E/E系统的，但它仍然提供了基于其他相关技术的安全相关系统的框架。主要包括了“V”型开发流程，ASIL概念 和功能安全设计开发流程。

·       提供了汽车生命周期（管理，研发，生产，运行，服务，拆解）和生命周期中必要的改装活动。

·       提供了决定风险等级的具体风险评估方法（汽车安全综合等级，ASILs）。

·       使用ASILs方法来确定获得可接受的残余风险的必要安全要求。

·       提供了确保获得足够的和可接受的安全等级的有效性和确定性措施。

功能安全受 研发过程（包括具体要求，设计，执行，整合，验证，有效性和配置），生产过程和服务流程以及管理流程的影响。安全事件总是和通常的功能和质量相关的研发活动及产品伴随在一起。ISO26262强调了研发活动和产品的安全相关方面 。

车辆产品的安全议题，要包含功能导向与品质导向之开发活动与工作产品，ISO26262正是清楚定义研发专案的功能安全相关系统、硬体与软体所应完成之开发活动与工作产品，形成产品的安全生命周期之各个阶段(如下图)，完整标准架构即成为车辆开发模型(V-model)。

安全生命周期涵盖ISO26262 Part 2至Part 7，整个生命周期分为概念阶段、产品开发与生产交付后等三阶段，由综合说明之功能安全管理起始，往下就是大V-model开始之概念阶段，接续是产品开发在系统层级、产品开发在硬体层级、产品开发在软体层级与结束之生产与操作，其间产品开发在系统层级包含产品开发在硬体层级与产品开发在软体层级两章，形成系统、子系统的阶层架构，而软、硬体开发又各成一小V-model，两者并有相互关联，确保系统开发是软硬兼顾。

ISO 26262只专注于功能安全，与适用于发展的能力成熟度整合模式(CMMI-DEV)之等级2或3(ML2/ML3)流程相当，两者配合形成完整的路线图(Road Map)，才能有效导入组织运作。CMMI-DEV为美国软体工程学院(SEI)自1984年起所发展的一套组织品质管理标准，以确保软/硬体产品的研发品质，已广为世界各研发组织流程改善所遵循；而2004年另一套标准ISO/IEC15504，就是俗称SPICE(Software Process Improvement and Capability Determination)，此软体流程改善与能力鉴定是与CMMI-DEV相当的系统工程要求。

功能安全技术搭配系统工程之路线图，形成完整的机制，为研发流程融入功能安全之可行方案，以满足车电系统安全又可靠的需求，CMMI-DEV与ISO 26262的关联汇整如下表所示，ARTC透过ML3流程与安全生命周期之相互关联性，融合两者建立完整的开发机制。

ARTC研发品质管理流程符合ISO9001与CMMI-DEV ML3，也着手将功能安全融入ML3流程，让研发专案形成由组织支持专业分工的系统工程团队。为应车辆电子产业最新功能安全标准 (ISO 26262)，已于2015年历经功能安全训练与落差分析、功能安全文件准备与融入流程、功能安全流程认证等作业，最终在年底12月份通过ISO 26262流程认证，进一步呼应车电产业的安全需求。

准备功能安全系统、硬体与软体层级之设计与测试文件，逐步进行V Model左半段之功能安全管理、功能安全概念与技术安全概念等阶段，由安全小组依专业分工，完成各项工作产品，并与SGS专家讨论相关产出，以对应落差分析建议，也以AEB试行计划制定功能安全融入研发流程之可行方案。

首先是V Model的功能安全管理阶段，由安全经理完成安全计划并定期更新，故此项工作产品会在资料记录表各个章节重复出现，以表现安全计划的最新进度或内容修订。安全计划主要包含项次、标准章节、内容、输入文件、输出文件、负责人、起/迄时间与备注等，这些项目同样与ISO 26262标准要求之工作产品一致，如此逐项检讨安全计划，就可完成功能安全要求，此一安全计划采用附件形式纳入计划执行规划书(Integrated Project Execution Plan, IPEP)。计划主持人也在IPEP新增安全经理之专业分工，因须由非计划成员担任，故列在计划成员之上，以显示其独立性。

另外，为查证各项工作产品，须制定功能安全评估计划(Functional Safety Assessment Plan)，其不同于安全计划，研发流程已透过里程碑审查，进行工作产品的查证，故功能安全评估计划可与里程碑审查整合，又因为ISO26262针对工作产品之确认措施，皆不可由该工作产品之相关人员执行，所以规划须依Part2汽车电子系统之ASIL执行分级查证。

研发专案之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开始，必须采取额外之风险降低措施，而ASILD表示最高之潜在风险。

以AEB计划所得HARA为例，总计33项整车故障之危害，因不同的操作情境、潜在危害、可能失效与外部减轻等，依据Part3决定ASIL，如某一项危害是非预期加速，其严重性为S3、发生机率为E4与可控性为C2，所以ASIL为C，各项ASIL取最高阶段度量也是ASILC，代表AEB的ASIL就是C。依前所述，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的设计与整合测试阶段。