符合ASIL D的AUTOSAR基础软件带来的安全和性能
本文转载于符合ASIL D的AUTOSAR基础软件带来的安全和性能，原稿来源：Safety and Performance with ASIL D AUTOSAR Basic Software。
在遵循ISO 26262开发的电子控制单元（ECU）中，经常出现安全相关的软件和与非安全相关的软件并行使用的情况。传统上采用分区措施来避免相互干扰，但是这种分区通常会导致运行时间的开销和复杂化。完全遵循ISO 26262开发的AUTOSAR基础软件，可以最大限度地减少分区数量。
ECU软件中，实现安全相关功能的部分的比例在逐年增加，导致安全相关的应用软件和AUTOSAR基础软件之间的交互更加频繁。如果这两种软件位于不同的分区，交互动作就需要附加的处理时间。比如至少要切换处于活动的任务，并且根据硬件平台的不同，还可能需要对存储器保护单元（MPU：Memory Protection Unit）进行重新编程。
不过，按照ASIL D的要求开发的基础软件，可以与安全相关的应用软件共存于同一个分区。这样就避免了任务的切换、MPU的重新编程和额外的数据复制，从而可以大幅提高性能。并且，额外的但经常需要的安全需求，可以在基础软件中进行实现，这样就没有必要在各个ECU工程中重复的进行开发了。图1以图形的方式比较了这两个方法。
图1：使用QM和ASIL基础软件进行分区的概念
译者注：
QM-软件是指，符合ISO 9001质量管理体系的过程所开发的软件。
ASIL-软件是指，符合ISO 26262道路汽车功能安全的过程所开发的软件。
背景
ISO 26262定义的汽车安全完整性等级（ASIL：Automotive Safety Integrity Level），是作为在软件中实现的功能的一种属性。它指示了要实现的功能的质量要求。对开发中的项目进行危害分析和风险评估得到了ASIL等级。然后分配到安全目标，并被传递到功能和技术上的安全概念，一直到安全相关软件需求。
如果一个软件组件在安全方面有特定ASIL等级的要求，那么在它的开发过程中必须应用ISO 26262第6部分对应的方法（图2）。在基础软件中，这样的安全相关功能的众所周知的例子有，操作系统的内存保护、看门狗堆栈的时间监视、以及AUTOSAR规格书中描述的使用端至端（E2E：End-to-End）保护的通信保护等[1]。
图2：有安全要求或需要做分区共存，而根据ASIL开发的软件组件。
使用AUTOSAR E2E保护是保护安全相关信号的最先进技术。由于它能够检测到所有的相关故障，因此对基础软件的通信组件自身没有安全需求。为了避免E2E保护和通信组件间进行分区，ISO 26262的第6部分也必须应用到通信组件的开发上。这是因为我们假定ASIL等级低的软件，相较于应用更高ASIL等级而开发的软件，含有更多的系统故障。
如果不进行分区，这些故障会级联的引起安全相关软件的故障，从而违反了指定的安全需求。对安全相关数据和软件的安全相关的时序需求的干扰是可能的。干扰引起的潜在危险是要被阻止的。ISO 26262 [2]提供的解决方案是使用与安全相关的功能相同的开发流程，来开发非安全相关的软件组件。那些安全相关的软件组件被认为提供了足够的免受干扰的能力。
对开发的影响
这种说法的含义是，除其他事项外，针对有问题的软件，必须为其开发出粗放的半正式设计。总的来说，这意味着需要额外的开发上的努力，来满足ASIL D的要求。不过，在设计和实现方面所增加的努力，相较于高要求的验证还是低的。对于测试尤其如此。
ISO 26262第6部分表4中指出了，作为软件安全分析的结果，产生了以多种方式实现算法的需求。为了防止系统故障，算法需要以两种不同的方式实现。为了避免这样的不同实现，Vector的组件构建在优秀的可测试性的基础上。软件组件在被测试时，表现出很低的圈复杂度。圈复杂度是一种对函数的控制流程图的路径的度量。为了满足组件在可测试性上的严格要求，很多组件都必须要被重构，例如，其源代码结构必须要改进。这个过程也被用来改善防御性编程，意思是从额外的检查中增强了鲁棒性，以及组件内的模块化。
另一个挑战是AUTOSAR基础软件的广泛的可配置性。ISO 26262只部分的处理了这些可配置性。特别是在单元测试领域，ISO 26262隐含的假设了只有一种可能的代码变体。作为一种独立安全单元（SEooC:Safety Element out of Context） [3]，基础软件会在各种配置下使用，必须找到一种方法来应对这种可配置性。这种可配置性部分地反映在预处理条件中。
Vector根据配置参数之间的用例和依赖关系推导出可能的配置。在其开发过程中，Vector在其预处理条件上，应用了与运行时测试[4]相同的退出标准（exit-criteria）。此外，Vector还在其组件开发中，针对测试定义了额外的退出标准：在每个配置变体中，必须完成针对实现预处理覆盖所必需的运行时测试的完整代码覆盖率。
静态代码分析是这个过程中的一个重要部分，因为相较于功能测试，它能够更可靠地发现某些类型的错误，例如内存污染（memory corruption）。针对可配置软件的情景，Vector开发了一个静态代码分析工具来检测越界访问和无效指针。
因为基础软件有很多变体，这引发了由用户执行的生成配置的自动验证。从而确保了基础软件中的非安全相关部分和安全相关部分之间，可以不受内存方面的干扰。
译者注：
SEooC是表示在ISO 26262之前出现，与特定系统或车辆环境的无关的，在现场得到广泛应用且没有出现故障的组件。
安全概念
上述的面向安全的开发过程，允许为SEooC基础软件定义新的安全需求，因为几乎所有来自ISO26262的相关需求都已经得到满足。Vector为基础软件制定了额外的安全要求：检测非易失性存储器中数据的丢失、污染（corruption）和掩码（masking of data）——由基础软件或硬件的较低层级引起的。
在将来，重新启动软件应用和AUTOSAR的时序保护也能够被视作一种安全机制来使用。Vector也承担了使ECU在初始化过程中进入确定的状态的安全需求。分区所必须的安全需求，通常仍然是需要的。例如，必须集成经常出现的QM软件，因为成本效益分析显示，新的开发或认证（根据ISO 26262第8部分第12条）是不经济的。
假定的安全需求必须经过仔细分析，并且与基本假设进行确认，然后这些需求才能被用在ECU项目的安全概念中。这意味着只有属于假定的安全需求的功能才能用于项目特定的安全概念。例如，Vector对通信组件没有假定的安全需求，所以E2E保护对于传输安全相关数据来说就是必要的。尽管如此，通信组件还是根据ISO 26262中的方法进行开发的。在一个给定项目的非常早期阶段，就应该提供一系列假定的安全需求。
集成
基础软件的用户在根据项目背景验证了假定的安全需求之后，他要使用交付中包含的安全手册来执行基础软件的配置和集成。针对基础软件，供应商通常是已经执行了单元测试。然而，ISO 26262[5]所述的集成和验证过程，则必须由用户执行。由于基础软件开发过程中配置、应用程序以及确切的目标环境的信息不足，基础软件供应商无法提供这些层面的安全案例。
通过基础软件的安全案例，用户可以确认与符合ISO 26262标准的开发流程的兼容性。用户可以参考这个安全案例来创建他的安全案例。安全案例是在用户提交的配置以及其他的东西的基础上创建的。对验证组件测试而言，Vector对配置的检查是必须的。在开发过程中，不可能对所有可能的配置参数的组合都进行测试。为了确定即使是异乎寻常的配置也被测试到了，项目相关特定的测试是必要的。
在认证公司Exida的一个独立评估中，作为示范性的评估，这种方法的有效性已经得到证实。在评估过程中，评估了操作系统、针对CAN、LIN和FlexRay的通信组件、以及系统和内存集群中的组件。图3展示了，根据ASIL D的组件开发的当前概览。
图3：根据ASIL D开发的AUTOSAR 4基本软件组件的当前概览
展望
以上介绍的方法显示了，ASIL D基础软件是如何降低运行时间和分区数量的。另外，ECU项目的复杂性也得到降低，源于安全机制已经包含在基础软件中，而不必由用户再次实施。
Vector的目标是根据其新的面向安全的过程，开发更多的AUTOSAR 4基础软件组件，从而为尽可能多的应用案例提供最佳解决方案。在不久的将来，面临的一个挑战是AUTOSAR组件，已经经历了许多变化。
另一个挑战是源于OEM提供的扩展，以及各种半导体制造商的硬件驱动程序。这些驱动程序还没有必要的质量保证，因此只能在安全的基础软件上使用，这会增加消耗和牺牲性能。
更进一步，Vector和Exida正在实施一个可用于安全相关软件的RTE，而不需要昂贵的认证措施。
更多关于功能安全和ISO 26262的信息：
http://www.vector.com/safety
https://jp.vector.com/vj_safety_jp.html
作者
Jonas Wolf (Dipl.-Ing.)
在斯图加特大学学习太空工程后，于2012年加入Vector公司，现在担任功能安全产品管理工程师。Peter Müller
在获得曼海姆应用科技大学的功能安全学位后，加入了TÜVSüd。2002年加入Exida，自2007年起担任自动化和汽车领域的认证工作的首席审查官。
本文是对在德国发行的“HANSER automotive, July/August 2016”里面刊登的文章内容的英文/日语翻译。
参考文献：
[1] AUTOSAR Specification of SW-C End-to-End Communication Protection Library
[2] ISO 26262 Part 9 Clause 6
[3] ISO 26262 Part 10 Clause 9
[4] ISO 26262 Part 6 Clause 12
[5] ISO 26262 Part 6 Clauses 10 and 11