（一）：BMS和ISO26262
BMS & ISO26262简介
BMS即Battery Management System，电池管理系统。作为新能源汽车“三电”核心技术之一，BMS在新能源车上扮演十分重要的作用。按照新能源汽车对电池管理的需求，BMS具备的功能包括电压/温度/电流采样及相应的过压、欠压、过温、过流保护，SOC/SOH估算、SOP预测、故障诊断、均衡控制、热管理和充电管理等。
为了保证汽车电子电气的可靠性设计， 在2011年发布了IS0 26262道路车辆功能安全标准）， IS0 26262 标准是源于工业功能安全标准（IEC61508）[1]。
目前许多汽车企业和零部件企业在控制器开发过程中采用ISO26262这个标准，ISO26262包括了汽车电子电气开发中与安全相关的所有应用，制定了汽车整个生命周期中与安全相关的所有活动，ISO 26262从需求开始，当中包括概念设计、软硬件设计，直至最后的生产、操作，都提出了相应的功能安全要求，其覆盖了汽车整个生命周期，从而保证安全相关的电子产品的功能性失效不会造成危险的发生。如下图所示：
1. 范围及相关项
ISO26262适用于最大总质量不超过3.5吨的量产成用车上的包含一个或多个电子电气系统的与安全相关的系统。在这部分ISO26262和FMEA还是比较相似的，第一步是确定Scope，那些是研究范围之内的。对高压电池系统而言，ISO26262适用于电池包电气系统及BMS系统，而不适用于电池包的电芯及机械结构件等。
1）Function Safety Definition
功能安全：不存在由电子电气系统的功能异常而引起的危害而导致不合理的风险。
为了保证避免不可接受的风险，功能安全开发流程在在ISO262262标准中进行了详细的阐述。概念阶段的function safety requirements应当能够满足整车层面的Safety Goal，电子电气层面的开发出来的technical safety requirements同时也应该满足概念阶段的function safety requirements，最后一步是确定零部件级别的软件和硬件的功能安全需求。下图是ISO26262开发途径。
2）Fault, Errors and Failures Definitions
Fault（故障）：可引起要素或相关项失效的异常情况
Errors （错误）：计算的、观测的、测量的值或条件与真实的、规定的、理论上正确的值或条件之间的差异
Failure（失效）：要素按要求执行功能的能力的终止
基于上面的定义，他们之间存在一定的因果关系，故障会产生错误，而错误会引起功能或者系统的失效，如下图。
在ISO26262标准中，我们要区分两类故障、错误和失效：随机和系统性失效。系统性失效可以在设计阶段通过合适的方法来避免，而随机性失效只能降低到可接受程度。系统性甚至随机性失效会发生在硬件当中，而软件的失效更多的是系统性的失效。
失效同时还可以分为单点失效和多点失效。
单点失效：要素中没有被安全机制所覆盖，并且直接导致违背安全目标的故障
多点失效：由几个独立的故障组合引发，直接导致违背安全目标的失效。
在多点失效中有个特别的失效叫双点失效。由两个独立故障组合引起的，直接导致违背安全目标的失效。
故障发生的时间关系如下图所示：
诊断测试时间间隔（diagnostic test interval）：通过安全机制执行在线诊断测试时间间隔
故障响应时间（fault reaction time）：从故障探测到进入安全状态的时间间隔
3）Risk Definition
风险可以看成一个功能函数F，一个变量frequency of occurrence （f），controllability （C），potential severity （S）功能函数
其中f是Exposure（E）危害时间发生概率λ的函数
ISO26262标准中分别对E，C，S进行了相应的定义
a. 对于每一个危害事件，应基于确定的理由预估每个运行场景的暴露概率。按照下表，应为暴露概率指定一个E0、E1、E2、E3或E4的概率等级。
b. 对于每一个危害事件，应基于一个确定的理由预估驾驶员或其他潜在处于风险的人员对该危害事件的可控性。按照下表，应为可控性指定一个C0、C1、C2或C3的可控性等级。
blob.png
c. 对于每一个危害事件，应基于一个已确定的理由来预估潜在伤害的严重度。根据下表，应为严重度指定一个S0、S1、S2或S3的严重度等级。
d. 每一个危害事件的ASIL等级应使用“严重度”、“暴露概率”和“可控性”这三个参数根据下表来确定。
由于BMS属于新能源汽车高压电池系统的一部分，EUCAR定义了高压电池系统的危害等级。
当BMS不能够很好的监测或者保护电芯时，上表中的危害事件就有可能发生。ISO26262的目标是保护乘客受到危害，因为上表Level 5以上就算是严重危害事件了。因此有必要定义一个电芯工作的最大允许危害级别，5以上时肯定不允许的。
（二）：ASIL等级
1. 相关项定义，ASIL等级，安全目标
如下图所示，第一步通过不同的驾驶情况，不同的环境来确定不同的场景；第二步分析不同场景下的事故所以引起的Hazard Situation. 第三步确定这些Hazard Situation的ASIL 等级，这一部分有很大的主观因素，每个公司考虑问题的角度不一样，针对不同的Hazard Situation设定的ASIL 等级也会不一样。
比如有些OEM定义热失控的ASIL LEVEL为C，有些OEM设定热失控 ASIL LEVEL 为D，不过目前来看热失控以后的ASIL LEVEL会是D，在知乎上看有人说以后大众的高压电池包的安全等级为D，他说的这个电池包应该是指电池包里面的电气架构包括BMS。
ISO 26262-3 Scheme ?TüV Süd
第四步根据上一步确定的不同的故障模型Harzard Situation ASIL的最大ASIL等级。第五步根据上一步确定的最大ASIL等级就可以设定Safety Goal了。在上篇文章中简单介绍了功能安全的开发途径，在开发途径中，Safety Goal是Top Level的Safety Requirements，直接来自于HARA（hazard analysis and risk assessment）。第七步，根据Safety Goal就可以导出 Saftety Requirements。
因为ISO26262涉及到产品的整个开发周期，那么谁该负责这整个流程，主机厂还是供应商？如果BMS是由供应商开发提供给主机厂，那么理论上前5步都应该是主机厂来主导分析，输出Saftety Goal给供应商，供应商根据Satety Goal导出Saftety Requirements，接着是系统设计，硬件设计，软件设计等。同时主机成也会参与到V模型右边的测试部分。
根据上面的分析，我们将BMS最为一个safety element out of context（独立安全单元），独立安全单元的意思在在产品的开发周期内，不用考虑整车内其它要素（element）。
a. Item Definition
Item dedinition首先要确定item的scope，item的边界及与item相关的部件，确定item与外界部件的交互接口，CAN信号，传感器信号等等。一般通常采用方框来表示item的elements，通过这些elements和elements之间的信息交互，就能够确定这个系统的大致架构。
如果下图a是一个电池系统的方块图，电池高压系统主要有Junction box，Modules，cell balance interconnect circuit, HV contactor module, BMS等。BMS通过将传感器采集的数据进行处理，计算电池SOC/SOH，故障诊断等，同时通过整车CAN与VCU进行信息交互。b图是a图所对应的item defintion。一个A00级的BEV电池包。
a） Preliminary architecture of the hypothetical Li-ion battery system
b） Key elements and signals within the energy storage system
点画线表示高压电池系统的边界线，高压系统的与外界的交互信号分成了下表中的七大类。
上面定义了不同类的子系统，下面这张图是上图中（connected modules）连接模组的框框图。
下面这张图是上面连接模组的进一步分解的模组框框图及信号流。
这样一层一层像剥洋葱一样分解系统，很方便追溯所有信号来源。系统与其他外部部件之间的联系，系统内部之间的联系，子系统之间的联系，一目了然。
比如我们想追踪温度传感器的信号流，首先可以从模组框框图开始，temperature sensor 到 monitoring unit， monitoring unit 与外部的 internal communication交互信息，上一次的连接模组的 internal communication 与外界的 Junction box通过内部通讯交换信息Top level 的 junction box 与外界的整车控制器交互信息。
这篇文章里的Itemdefinition是针对高压电池包，我直接引用。BMS系统没有这么多子系统，但是在工作中发现，其实把高压系统的电气系统和BMS作为一个大系统，进行功能安全分析更全面，工作也更好展开。
（三）：ASIL等级
a. ASIL等级
在第二篇中，进行了概念阶段的ite definition分析，item definition应当尽可能将系统的接口描述清楚。比如电池系统电压分类，高压线路的功率能力，CAN通信协议和其他信号的说明，信号电压电流范围，正常值等。
Item definition,不仅需要将系统的功能描述清楚，同时也要将item的失效模式描述清楚，这样才能清楚知道tiem应该是怎么样，而不应该出现某些哪些表现形式。
在ISO26262-3中，Hazrad可以通过，brainstorm或者DFMEA等方法来确认，从整车级别分析这些危害会对车辆或者乘客造成的影响。这个阶段的DFMEA我们可以不用考虑造成这些危害的可能原因有哪些，在后面的DFEMA工作中可以具体来分析造成这些hardzard的可能原因。
在第二篇的中的item defintion中，分析了过一个A00级别汽车的电池包。如下图。
下表是根据上图HARA（Hazard Analysis and Risk Assessment）得到的。定义了93个功能和136个malfunction.
在该文章中选取了6个路况，subterranean garage, small streets, middle streets, large streets, highway and motorway，同时选取了23个常见的驾驶工况，常见的天气情况对场景的影响，最后得到了3128个可能性较大的危害事件。
3128还是个非常大的数字，如果一条一条的分析，是个巨大的工作。文章中提高，他们团队有来不自不同部门的经验丰富的工程师有整车部门，电芯部门，pack部门，EE等，最后团队从这3128危害事件中选择了142个进行进一步分析。
下表是电池系统几个function与malfunction：
在定义好了malfunction后，就可以根据Risk definiton中的三个参数S（Severity），E（ Exposure）， C（Controllability）来确定危害的ASIL 等级了。
下表是一个简单的电芯过放的HARA分析。在这个表格里面，在城市道路上发生电芯热失控导致车辆起火，定的ASIL Level是C；车辆在速度比较低的时候，定的ASIL Level是A。
下表是另外一个文章中过放的HRAR分析：
这两个表格中参数C（Controllability）很大程度上取决于驾驶员将车辆停靠在安全位置的速度，车速越快，车速越快驾驶员需要更多的时间找一个安全位置将电芯热失控的车辆安置好。这两个表格中第二行S/E/C的值都是一样，而ASIL LEVEL却不一样，怎么回事？
有个很简单的公式来确定确定ASIL LEVEL。如果S+E+C的值小于7，那么ASIL LEVEL是A，详细如下表。所以第二个表格中的ASIL LEVEL应该C，文章的小瑕疵。
blob.png
下表是一篇文章对一个高压电池包HARA分析后给出的Safety Goal.同上面两个对比，不同的公司或组织对相同的Malfunction给出的ASIL LEVEL是不同的，上面两个表格对过充的ASIL LEVEL是C，下表为D。
由Saftey Goal衍生出的安全目标应该考虑一下内容：
◆ 运行模式
◆故障容错时间区间（间隔）；或故障容错时间
◆ 安全状态
◆ 紧急操作时间区间
◆ 功能冗余（例如故障容错）
应为每一个安全目标定义至少一项功能安全要求，尽管一个功能安全要求能够cover不止一条安全目标，每一条FSR从相关SG继承最高的ASIL。然后将FSR分配给相关项。比如下表中的SG1定义了两个FSR。
在ISO26262-9中定义了ASIL分解，为了降低安全目标实施成本，可以将一个高ASIL安全目标分解成两个相互独立的低一级安全目标。拿文中的SG1-预防过放作为一个例子，在这里我们假设负载只有驱动电机，可以通过将SG1分解成两个独立的FSR。FSR1.2a:在x ms内断开高压回路，FSR1.2a：通过CAN报文请求负载将需求功率降低为0。
（四）：技术安全要求导出
技术安全要求导出
图1说明了通过分层的方法，从危害分析和风险评估得出安全目标，再由安全目标得出功能安全要求。
图2给出了ISO26262相应部分中的安全要求的结构和分布的说明。将功能安全要求分配给初步架构要素。
技术安全要求（TSR）是对功能安全要求（FSR）提炼，细化了功能安全的概念，同时考虑功能性的概念和初步的体系架构。通过分析技术安全需要来验证符合功能安全需求。在整个开发生命周期，技术安全需求是要落实功能安全概念的技术要求，其用意是从细节的单级功能安全要求到系统级的安全技术要求。
技术安全要求应根据功能安全概念、相关项的初步架构设想和如下系统特性来定义：
a. 外部接口，如通讯和用户接口，如果适用；
b. 限制条件，例如环境条件或者功能限制；以及
c. 系统配置要求。
在第三篇文章中，从安全目标道出了BMS的一个功能安全要求，图3是对功能安全要求FSR1.2a导出的技术安全要求。
系统设计
基于概念阶段的基本系统架构，功能安全概念，技术安全要求和非功能性要求，按照ISO26262的下一步流程就是系统设计了。在这个阶段，系统及子系统需要上面所定义的贯彻技术安全要求，需要反映前面定义的安全检测及安全机制。
技术安全要求的应分配给系统设计要素，同时系统设计应完成技术安全要求，关于技术安全要求的实现，在系统设计中应考虑如下问题：
a. 系统设计的可验证性
b. 软件硬件的技术实现性
c. 系统集成中的执行测试能力
系统和子系统架构应该满足各自ASIL 等级的技术安全需求，每个元素应实现最高的ASIL技术安全需求，如果一个系统包含的子系统有不同的ASIL 等级，或者是安全相关的子系统和非安全相关的子系统，那么这些系统应该以最高的ASIL等级来处理。
在系统设计阶段，为了避免系统系失效，ISO26262针对不同的ASIL等级推荐了不同的分析方法，如FMEA,FAT等。如表1。由于内因或者外因而引起系统失效应当避免或者消除。
为减少系统性失效， 宜应用值得信赖的汽车系统设计原则。 这些原则可能包括：
a. 值得信赖的技术安全概念的再利用；
b. 值得信赖的要素设计的再利用， 包括硬件和软件组件；
c. 值得信赖的探测和控制失效的机制的再利用， 及
d. 值得信赖的或标准化接口的再利用。
为了确保值得信赖的设计原则或要素在新相关项中的适用性， 应分析其应用结果， 以及应在再利用之前检查其基本设想。
ASIL A、B、C、D 规定：为避免高复杂性带来的故障，架构设计应该根据表2 中的原则来展现下列的属性：模块化，层次化，简单化。
基于上面定义的TSR和概念阶段定义的基本架构图，图4是精炼之后的BMS系统架构图。
下一步是定义系统架构，分配TSR给硬件和软件，同时定义好软件硬件接口HIS。
软硬件接口规范应规定的硬件和软件的交互，并与技术安全的概念是一致的，应包括组件的硬件设备，是由软件和硬件资源控制支持软件运行的。软硬件接口规范应包括下面属性：
a. 硬件设备的工作模式和相关的配置参数， 硬件设备的操作模式，如：缺省模式，
b. 初始化，测试或高级模式， 配置参数，如：增益控制，带通频率或时钟分频器。
c. 确保单元之间的独立性和支持软件分区的硬件特性
d. 共享和专用硬件资源，如内存映射，寄存器，定时器，中断，I / O 端口的分配。
e. 硬件设备的获取机制，如串口，并口，从，主/从
f. 每个涉及技术安全概念的时序约束
硬件和其使用的软件的相关诊断功能应在软硬件接口规范中规定：
a. 硬件诊断功能应定义，例，检测过流，短路或过热
b. 在软件中实现的硬件诊断功能
软硬件接口规范在系统设计时制定，在硬件开发和软件开发时被进一步细化。应使用表3列出的方法验证系统设计对于技术安全概念的符合性和完备性。
blob.png
（五）：硬件系统功能安全设计
硬件的详细安全需求来自于TSR，系统架构及系统边界HSI。
硬件系统功能安全设计
根据ISO 26262-8章节6.4.2 硬件安全需求规范应包括与安全相关的每一条硬件要求，包括以下：
a. 为控制要素硬件内部失效的安全机制的硬件安全要求和相关属性，这包括用来覆盖相关瞬态故障（例如，由于所使用的技术而产生的瞬态故障）的内部安全机制；
b. 为确保要素对外部失效容错的硬件安全要求和安全机制的相关属性。
c. 为符合其它要素的安全要求的硬件安全要求和安全机制的相关属性；
d. 为探测内外部失效和发送失效信息的硬件安全要求及安全机制的相关属性；及
e. 没有定义安全机制的硬件安全要求。
硬件安全要求应按照ISO26262-8第6章和第9章的要求进行验证，以提供证据证明。硬件设计可以硬件功能方块图开始，硬件方块图的所有的元素和内部接口应当展示出来。然后设计和验证详细的电路图，最后通过演绎法（FTA）或者归纳法（FMEA）等方法来验证硬件架构可能出现的故障。
对系统设计来讲最大的挑战是满足ISO26262硬件架构度量。针对ASIL C或D，ISO26262强烈推荐计算单失效和潜在失效概率。具体计算法见ISO26262-8附件。针对单点故障SPF （single-point faults），被称为单点故障度量（single-pointfault metric -SPFM），针对潜在失效故障，被称为潜在故障度量（ latent-faultmetric-LFM）。对于每一个安全目标，由ISO26262要求的“潜伏故障度量”的定量目标值应基于下列参考目标值：
对BMS系统来讲，电池包电压传感器是一个非常重要的传感器，因此针对不同的ASIL等级需要分析电池包电压传感器不同的失效模式。下表是不同的ASIL级别所需要覆盖到失效模式。
ISO26262推荐用两个可选的方法以评估违背安全目标的残余风险是否足够低。
两个方法都评估由单点故障、残余故障和可能的双点故障导致的违背安全目标的残余风险。如果显示为与安全概念相关，也可考虑多点故障。在分析中，对残余和双点故障，将考虑安全机制的覆盖率，并且，对双点故障也将考虑暴露持续时间。
第一个方法包括使用概率的度量，即“随机硬件失效概率度量”（probabilisticmetric for random hardware failures-PMHF），通过使用例如定量故障树分析（FTA）或者（Failure Mode Effects and Diagnostic Analysis - FMEDA）及将此计算结果与目标值相比较的方法，评估是否违背所考虑的安全目标。
第二个方法包括独立的评估每个残余和单点故障，及每个双点失效是否导致违背所考虑的安全目标。此分析方法也可被考虑为割集分析。推荐的随机失效目标值如下表3。在文章[1]中选用第二种方法来验证BMS均衡电路的随机失效，单点失效等。
在前面几章分析过从HARA分析得到Safe Goal，从Safe Goal推导出FSR，从FSR推导出TSR。并以BMS的过充作为例子进行了详细的介绍。
文章[1]选取了TI公司的BQ20Z80芯片，监控四个cell电压，管理均衡。图1是电路原图（表示看不清，可以看参考文献[2]的高清大图），该电路的核心元器件是ICBQ20Z80，BQ2940是过充二级保护芯片。文章针对过充保护功能，选择方法2展开对安全目标-“Battery overcharging shallbe prevented ”的随机失效失效评估。该方法不仅考虑到错误发生的可能性同时还考虑到安全机制的有效性。文章评估了芯片BQ2940及采样芯片BQ2931。
ISO 26262标准中引入了失效率等级。硬件元器件失效率的失效率等级评级应按如下确定：
a. 失效率等级1 对应的失效率应少于ASILD 的目标除以100（见表3）
b. 失效率等级2 对应的失效率应少于或等于10倍的失效率等级1 对应的失效率（见表4）
如果单点失效违背ASILC的安全目标，那个对应的合适的失效率等级为FRC 1或者有其他额外测量的FRC2。
采样均衡电路的失效可能会导致电芯过充，进一步引起热失控。因此根据SafetyGoal推导出的安全要求如图2。
blob.png
根据FSR可以推导出TSR，TSR见图3。
这是安全目标所导出想系统的TSR，需要从中分离出单独跟硬件相关的或者和软件硬件都相关的TSR，因此硬件的TSR为：
◆Overcharge condition shall be detectedwithin Y ms and,
◆ Current to the battery shall beinterrupted within Z ms.
◆ 根据上面的分析有两条TSR分配给了硬件系统。在文档[1]中归纳总结了安全目标的安全机制，见表5：
◆ 实施安全机制中需要用到的硬件元器件预估失效率（failurein time- FIT）。用于确定硬件元器件失效率和失效模式分布的业界公认的来源包括IEC/TR62380, IEC 61709, MIL HDBK 217 F notice 2, RIAC HDBK 217 Plus, UTE C80-811,NPRD 95, EN 50129:2003, Annex C, IEC 2061:2005, Annex D, RIAC FMD97 和 MIL HDBK 338。文章[1]中选取数据库MILHDBK 217和芯片供应商所提供的数据来评估安全机制。
◆ 文章[1]中采用AFEBQ2931（TI）作为过充二级保护芯片，表是对过充保护的安全机制的评估。从下表格可以看出，安全目标的失效模式覆盖率为99%，针对不同的与之安全相关的部件。
◆一旦完成硬件架构的设计和样件设计，与之对应的不同的元素，系统集成测试也应该定义好。在ISO26262-8中，针对不同的ASIL等级推荐了不同的测试方法。
（六）汽车软件开发
前面五部分介绍了基于ISO26262标准的开发BMS的系统及硬件部分，最后一部分介绍软件部分。至此整个BMS的功能安全开发流程简单梳理了一遍。这个月国家标准化管理委员会发布了功能安全的GB/T版本，虽是推荐标准，但是以后越来越多的OEM会对供应商列为强制标准，对零部件企业的电子电气系统开发是个极大的挑战。
在汽车行业软件开发一般遵循V模型，左边是开发过程，右边对应的测试过程。ISO26262第六部分推荐的软件开发流程也V模型，如下图所示，跟硬件的V模型开发流程基本一样，需求-->架构-->详细设计。
1. 软件架构设计
软件开发流程跟硬件开发基本一样，由软件TSR和系统需求可以确定软件基本架构。软件安全要求需要与软件架构一起实施，以及与安全相关的其它软件要求。在软件架构中， 由于软件单元获得了分配给他们的不同软件安全性要求，因此考虑这些可能与不同ASILs的要求是否可以共存在同一软件单元中也很重要。
如果不符合这些标准，则需要根据所有分配的安全要求的最高ASIL开发和测试软件。 这些标准可能包括内存保护和保证的执行时间。
软件架构包含静态和动态方面的，静态方面的主要和不同软件单元之间的接口：1）软件结构包括其分级层次； 2） 数据处理的逻辑顺序； 3） 数据类型和它们的特征参数； 4） 软件组件的外部接口； 5）软件的外部接口及 约束（包括架构的范围和外部依赖）。动态方面的涉及：1）功能性和行为； 2）控制流和并发进程；3） 软件组件间的数据流；4） 对外接口的数据流时间的限制。为了说明这两个方面，软件架构所用到的标记法有，非正式标记法，半正式标记法，正式标记法，ASIL 等级越高，标记法越正式。
在软件架构设计中，需要重点考虑软件的可维护性及可测试性。在汽车行业，软件在整个产品周期内都应当考虑维护性，同时还要考虑软件架构的设计测试的容易醒，在ISO 26262标准中，测试是非常重要的一方面，任何设计都应该同时考虑到测试的方便性。
为避免高度复杂性导致系统性故障， ISO26262列出来一些推荐的标准：
◆软件层次性，软件模块的高内聚性，限制软件模块大小。
◆软件模块之间的接口应当尽量少且简单。这个可以通过限制软件模块的耦合度实现。
◆软件调度应当避免使用中断，如果使用了中断，要注意考虑中断的优先级。目的是确保软件单元执行时间。
在软件架构层面，可以检测不同软件单元之间的错误。ASIL等级越高，要求的安全机制越多。下面是ISO26262中提到的一些安全机制，有些安全机机制之间可能有重复。
◆数据范围检查：数据在不同的软件模组读写时，这个简单方法可以确保数据在正常合理范围之内。任何超出这个范围的数据，都可以被认为是错误的数据，比如电池cell电压超出5v，就可以认为这个数据是无效的。
◆真实性检查：软件模组之间的信号传递可以采用这种类型的合理性检查。比如汽车在1s内从静止状态加速到100km/h，这个减速度在汽车上是不现实的。同时可以采用参考模型或者其他来源信息来评估信号的合理性。
◆数据错误检查：有许多方法可以检查数据的正确性，比如数据校验（data checksums），冗余数据备份。
◆控制流监控：通过监控软件单元的执行流程，可以检测到某些故障，包括跳过的指令和软件卡在无限循环中。
◆多样化软件设计：在软件设计中使用多样性设计可以高效的检测软件故障。 该方法是设计两个不同的软件单元进行互相监控； 如果二者行为不同，那么说明其中一个故障。 因为软件设计师也犯了类似的错误并不罕见。 为了避免类似的错误，软件功能越多样化，这些类型的错误的可能性就越低。
一旦软件错误被检测到，应该有相应的错误处理机制。在软件架构级别ISO26262详列的错误处理安全机制如下：
◆静态恢复机制：目的是从破坏的状态回到可以继续正常运行的状态
◆适度降级：当发生故障时，该方法让系统进去一个安全运行模式。汽车软件的通常做法是亮起警示灯通知驾驶员某部件出现了问题，对高压系统而言，如BMS检测到轻度绝缘故障等。
◆独立并行冗余：该安全机制可能会需要硬件冗余，因此成本相对而言较高。这个概念假设基于两个冗余硬件同时发生错误的概率相对很低，并且有一个硬件一直处于正常无故障运行模式。
◆数据纠错码：对于数据错误，有机制可以纠正这些错误。 这些机制都是基于添加冗余数据来提供不同级别的保护。使用的冗余数据越多，可以更正的错误就越多。 这通常用于CD，DVD和RAM，但也可以在汽车领域使用。
一旦软件架构设计结束后，就需要对软件架构的需求进行测试。ISO26262详列了一些方法：
◆设计走查：一种同行审查的形式，软件架构设计者将这种架构描述为一组审查人员，目的是检测任何潜在的问题。
◆设计检查：与走查相比，检查更正式。 它包括几个步骤：规划，离线检查，检查会议，返工和更改的后续工作。
◆仿真：如果软件架构可以通过软件进行仿真，那么仿真是一种有效的方法，特别是在架构的动态部分找到故障。
◆生成原型：与仿真一样，原型设计对于动态部件来说也是非常有效的。 分析原型和预期目标之间的任何差异也是很重要的。
◆形式验证：这种方法用数学证明或反驳正确性，很少用于汽车行业。 它可用于确保预期的行为，排除意外行为，并证明安全要求。
◆控制流分析：这种类型的分析可以用在在静态代码分析。目的是在架构层的软件执行中找到任何安全关键路径。
◆数据流分析：这种类型的分析可以用在在静态代码分析。目的是在软件架构层面找到任何安全关键的变量
2. 软件单元测试
一旦软件安全要求确定了，单元级别的软件架构已完成，那么就可以展看软件单元的设计和实施。 ISO 26262支持手动编写的代码（manually written code）和自动生成的代码。 如果生成代码，则可以省略对软件单元的要求，前提是使用的工具已经通过ASIL等级认证。 在本节中，重点将是人工编写的代码。
与软件架构的规范一样，ISO 26262规定了应用于软件单元设计的符号。 ISO 26262要求适当组合所使用符号。并且始终强烈推荐自然语言。 此外，该标准建议使用非正式符号，半正式符号和正式符号。
关于软件单元实施，ISO26262中提到的许多设计原则。 有些可能不适用，取决于开发过程。 有些也可能被使用的编码指南所涵盖：
子程序和函数采用一个入口和一个出口：多个出口点通过代码使控制流复杂化，代码难以理解和维护。
无动态对象或动态变量，在其产生过程中也没有在线测试：动态对象和变量存在两个主要挑战，不可预测的行为和内存泄漏。 两者都可能对安全产生负面影响。
变量初始化：没有初始化变量，变量可能是任何值，包括不安全的和非法的值。这两者都可能对安全产生负面影响。
不能重复使用变量名称：使用相同名称的不同变量有风险
避免全局变量，否则需证明对全局变量的使用是合理的：全局变量从两个方面来说都是坏的： 它们可以被任何人读取并被任何人写入。开发安全相关的代码，强烈建议从这两个方面控制变量。有些时候，可能存在全局变量优先的情况，如果使用全局变量的相关风险的使用可以被证明安全，ISO 26262允许这些情况。网上文章说丰田的踏板事件中，28万行代码，有1w多个全局变量。
◆限制使用指针：使用指针的两个重大风险是变量值的破坏和程序的崩溃； 两者都应该避免。
◆无隐式类型转换：即使编译器支持某些编程语言，应避免这种情况，因为它可能导致意外的行为，包括数据丢失。
◆无隐藏数据流或控制流：隐藏的流程使代码更难以理解和维护。
◆没有无条件跳转：无条件跳转使得代码更难以分析和理解
◆无递归：递归是一种强大的方法。 然而，它使代码复杂化，使其难以理解和验证。
在软件单元设计和实现的时候，需要验证硬件 - 软件接口和软件安全要求是否满足安全需求。 此外，应确保软件代码符合编码准则，软件单元设计与预期硬件兼容。ISO推荐了的方法基本和软件架构的一样。
◆静态代码分析： 分析的基础是调试源代码而不执行它。 通常包括语法和语义的分析，检查编码指南，如MISRA-C，变量估计，控制流和数据流的分析。
◆语义代码分析：该方法一般考虑到的是源代码的语义方面，是一种静态代码分析。 可以检测的示例包括未正确定义和以不正确方式使用的变量和函数。
