软件安全分析是整个汽车系统安全审查的一部分。其目的是降低车辆使用过程中由软件缺陷给车内人员带来的风险。ISO26262-6第7节要求对车辆ECU的软件体系结构进行特定的安全导向分析，以实现以下四个目标：
1、证明软件可提供指定安全相关的功能和属性；
2、识别并确认软件的安全相关部分；
3、支持安全机制以及安全机制的验证；
4、检测可能违反所需干扰自由度的故障模式。
由于软件呈爆炸式增长，错误发生的几率增加。意味着不再可能分析给定软件系统的每个状态，并确定是否存在相关的错误。相反通过分析某些特性，如复杂性、代码静态检查等，可以估计软件中错误数量的概率。然而，ISO 26262-6第7节也要求，对于某些类型的错误，在架构级(车辆功能)层面，应该进行全面的分析。以下就是基于此发展的一种方法。
软件安全分析中的缺陷
进行系统安全分析的方法包括以下内容：
1、失效模式及影响分析FMEA；
2、故障树分析；
3、事件树分析；
4、危险和可操作性分析。
使用这些方法进行软件安全分析的基本问题是，软件作为一个系统，其状态比硬件多几个数量级。实际上不可能对所有状态进行分析，并以合理的方式确定哪些状态应优先考虑。也就是说，我们的研究中使用了一些系统安全分析方法的概念，如“指导词”和“故障模式”，作为标准表示。
另外，也有人提出以软件为重点的安全分析方法，如:
1、Petri网分析；
2、失效传播转化符号FPTN；
3、软件关键性分析；
4、软件FMEA
5、软件故障模式、影响和关键性分析（SFMECA）。
FPTN更多的是一种标记技术，它不能进行详尽的分析。Petri网分析适用于基础软件。软件FMEA和SFMECA是使用应用层软件的，但随着软件复杂性的增加，它们需要付出更多的努力。软件临界性分析和SHARD关注的是数据流。在SHARD中提出的数据流概念在我们的上下文中很有价值，它在以下的方法中有使用，但使用的顺序和抽象层不同。这些方法从整个架构层面开始分析，从上到下研究输入输出信号和相应的故障模式。它们假设有一个前端架构，不会随着时间发生显著的变化。
然而，在现代软件开发中，架构基本是不断变化。就沃尔沃汽车而言，敏捷团队拥有称为软件包的架构组件（图 1）。与电子控制单元 (ECU) 级别的架构决策相比，软件包内部的架构决策是紧急的，后者随着时间的推移相对稳定。紧急架构阻止进行自上而下的分析，因为信号的状态可能会在过程中间发生变化，从而使结果无效。此外，在我们的案例中，基础软件和部分应用软件由供应商采购，因此无法进行自上而下的分析。
图1 沃尔沃汽车ECU软件概述
应用软件的复杂性、对客户的响应性、多站点开发以及紧急架构都敦促我们开发一种新的软件安全分析方法，以帮助我们遵守ISO 26262-6。然而，这种方法是针对以Simulink模型作为软件单元开发的应用软件而设计的。该方法不适用于手写软件和基础软件。与Simulink模型相比，手写代码具有较少的开发限制(例如，非强制性地遵守干净的编码标准)和更多与其他文件和函数的耦合。因此，分析不那么清晰的数据流需要付出更多的努力，这在开发中可能是不可承受的。
01
研究方法
研究过程中的一个关键决定是首先识别软件中的所有错误类型，因为由于错误的多样性，不确定哪些类型应该进行面向安全的软件分析。以及哪些错误会影响软件安全分析的目标实现。通常采用行动研究来处理这种情况：成立了一个从业人员参考小组，在行动研究周期中进行迭代。其成员包括一名软件工程技术领导，一名软件安全技术专家，一名高级安全工程师，一名软件开发首席工程师，一名软件架构师，一名高级软件开发人员，以及一名负责开发车辆安全关键功能的产品负责人。任务包括以下内容：
1．根据给定的软件开发过程和工作产品，识别应用软件中可能发生的所有类型的错误；
2．针对已识别的错误类型，调查并记录当前的解决方法
3．为尚未发现的错误类型指定预设解决方法；
4．审查面向安全的软件分析方法的开发。
沃尔沃为未发现的错误类型提出了初始的解决方法。他们还设计了面向安全的软件分析方法的框架。并且根据参考小组在行动研究周期中对这些建议提出的批判性的质疑，讨论得出了初步的结果。在大约一年半的时间里，软件安全分析方法基本上具体化了。之后将该方法应用于沃尔沃某大型ECU内部应用软件，对分析方法进行了更多的调整。应用该方法的软件有大约200个Simulink模型(产生大约80万行代码)，由12个敏捷团队开发。
02
软件安全分析方法
分析方法由两部分组成。首先是对软件开发过程的评估，并采用一套实用且有效的方法来检测整个开发链中的错误。这些方法可以识别并消除绝大部分开发阶段的软件错误。这个过程被称为软件安全的通用分析，它明确地包含了软件错误检测的概率性质，并非所有软件状态都可以检查。但这确保了通过可用的方法和工具将总体软件错误的可能性降至最低。
第二部分是在架构级别的面向安全的软件分析，以消除可能在通用分析中遗漏的并且可能不利于安全目标实现的错误。架构级别的安全分析保持与软件工程保持同步，并且跟通用分析也是同步进行的。这两种分析中通常采用自动化检查、基于度量的更正、同行评审和自动化测试等方法来辅助分析。
软件安全的通用分析识别了开发链中的错误，并给出解决办法。表1中记录了我们产品的此类调查结果。如果某类错误可能影响四个安全目标中的任何一个，则应进行额外的安全导向分析。这些错误类型在表中以粗体显示。他们会定期评估和更新（例如，一年一次）。负责的软件安全专家应确保该表的信息是最新的。
表1 汽车软件确定的错误和解决办法
03
架构级别面向安全的软件分析
面向安全的分析旨在识别由于需求错误说明、错误分配、软件模型之间不正确的信号接口和不正确的功能调用（表1中以粗体显示）而导致的错误。分析分为两个阶段。第1阶段的全部分析是面向Simulink模型。有一个敏捷团队每次选择一个Simulink模块，并在软件安全专家的支持下进行分析。第2阶段的分析实体是应用软件。软件架构师在软件安全专家的支持下进行分析，并使用阶段1的结果。
第1阶段开始于产品负责人与敏捷团队和软件安全专家一起组织一个研讨会。假设团队已有关于给定模型的故障模式以及每个故障模式对应的车辆级安全级别（CLs）的正确信息。事实上，这一分析的目标之一就是纠正这一假设。CLs的定义如下：
1．如果车辆级后果未违反安全目标，则归类为CL1。如果模型只有CL1，则模型本身被分类为CL1。
2. 如果车辆级后果违反安全目标，但有安全机制避免该后果，则将其归类为CL2。如果模型只有CL2和CL1，则模型本身被分类为CL2。
3. 如果车辆级后果违反安全目标且没有任何安全机制，则将其归类为CL3，模型本身被分类为CL3。
第1阶段和第2阶段的概述如图2所示。下面是逐步详细的描述。
图2 阶段1和阶段2概述
阶段1：由敏捷团队在安全专家的支持下进行
1. 了解模型实现的功能；
2. 根据模型的输出信号和功能调用确定故障模式；
3. 尽团队所知，确定每个故障模式的车辆级后果；
4．将每个故障模式的车辆级后果分类为CL1、CL2或CL3。
-
车辆级后果是否违反安全目标？如果没有，则将结果分类为CL1。如果是，请转到下一点。
-
模型外部是否有安全机制来避免这种后果？如果是，将后果分类为CL2，并参考安全机制。如果没有，请转到下一点。
-
相应的输出信号（功能调用）是否为CL3？如果是，将其车辆级后果分类为CL3。如果否，则检测到不合适的设计。
5. 确认软件的CL3部分。
-
具有CL3故障模式的模型在架构描述中是否有相应的ASIL等级分类？如果否，则检测到不合适的设计。
-
具有CL3故障模式的模型是否有相应ASIL分类的故障模式要求？如果否，则检测到不合适的设计。
6. 对于至少有一个CL2或CL3的模型，应该用相应的输出信号(函数调用)记录所有故障模式。
-
记录信号(函数调用)、故障模式、车辆级后果、CLs和ASIL级别的名称。
7. 尽团队所知，确定并记录CL3故障的原因。
-
将原因按CL1、CL2或CL3分类。原因可以是输入信号、触发器、代码开关、配置和其他错误类型。
8.在实践时，应记录团队认为完成第 1 阶段所需的补齐的知识点。
在第1阶段之后，所有标记为CL3的模型应与系统安全工程师共享，以确认危害分析中的相应ASIL等级。ASIL等级应与表第5点下第一个条目中的信息一起记录。
引导词用于系统地表示特定设计意图的可能偏差，并确定可能的后果。引导词可用于识别弱点、故障和故障。选择合适的引导词取决于所检查功能、行为、属性、接口和数据的特征。分析中应使用的指导词集取决于上下文，因此应由分析工程师在安全专家的协助下选择。表2中提供了第1阶段分析结果的样本。分析的第二阶段使用第一阶段的结果来确认CL2模型的安全机制，并评估安全相关软件的抗干扰性。
表2 Simulink模型分析的示例结果
阶段2：由软件架构师在安全专家支持下进行
1. 通过检查第1阶段的所有CL2相关的模型及其安全机制，确认软件的CL2部分。
-
目标软件版本中是否包含安全机制？如果否，则检测到不合适的设计。如果是，评估安全机制的充分性；
-
是否为安全机制规定了适当的软件/系统集成测试？如果否，请指定一个。
2.通过检查软件架构中的所有模型，确认各功能的分区合理性。
-
具有给定ASIL等级的模型是否分配给具有相同或更高ASIL等级的软件分区？如果否，则检测到不适当的分配。
-
如果不同ASIL等级的模型分配到同一分区，请在架构描述中确认这些模型是根据最高ASIL开发标准设计的。
3. 检查从较低ASIL分区到较高分区的故障模式传播。
-
所有CL3输入信号是否都来自CL3模型?如果不是，则检测到紧急架构和合理架构之间不一致的规范。
4.根据阶段1分析，确认应用软件的接口信号具有正确的ASIL分类。
建议团队在每个项目增量期间执行第1阶段。在一些敏捷方法中，每个增量可能是8到12周。第2阶段应在每次产品发布之前执行，前提是明确不会发生进一步的功能更改。
04
总结
该方法被认为是经济上可承受的连续安全分析方法。原因如下：首先，软件安全的一般分析方法在很大程度上是自动化的，并与软件开发环境集成。一旦部署了这些方法（表1），就很容易定期审查和更新信息。其次，一旦进行了以安全为导向的分析，在未来，团队将拥有足够的知识和文件，根据输出信号的变化及其相应信息（故障模式、车辆级后果等）更新评估。文档可以是Excel表格和基于浏览器的半自动方式。
面向安全的软件分析有助于关注直接违反安全目标的错误。这种分析超越了自动检查，这重点关注模型实现了哪些功能，模型间如何相互干预，以及模型与架构决策如何一致。这有助于避免可能危及功能安全的意外设计决策。
一般来说，以上的分析需要了解模型在车辆级功能中的作用。以安全为导向的分析增强了敏捷团队的这种意识，开拓了成员的知识面，使他们能够做出更明智的设计决策。使用此方法过程中也得到了有关改进的反馈，主要提高了自动化程度并集成到软件开发环境中，以减少技术的管理工作。
推荐阅读
特斯拉的电池管理系统 (BMS) 相比其他电动车有哪些优势？
原文始发于微信公众号（汽车ECU开发）：沃尔沃：敏捷开发中满足ISO26262的软件安全分析
