车载基础软件的标准

ISO 26262 标准

ISO 26262 标准的确立

2018 年，ISO 26262 经过重大更新，增加了两项新标准：针对半导体的要求，以及针对摩托车、卡车和巴士的要求。针对基于模型的开发、软件安全分析、相关失效分析、故障容错等项目增加了指导纲要。

ISO 26262 的汽车安全完整性等级 (ASIL) 基于三个变量：严重程度、接触概率和驾驶员可控性。ISO 26262 假定车辆有人驾驶，因此不直接涉及完全自动驾驶的车辆。但由于整车自动化已经进入汽车行业发展的路线图，功能安全仍是开发任务的重中之重，并且 ISO 26262 标准还将不断发展。

ISO 26262 面临哪些挑战？

遵守 ISO 26262 需要大量的文档和测试，可能会非常耗时。这就要求工程师对其设计软件进行工具置信水平的评估。

虽然 ISO 26262 提供了汽车安全的通用术语，但 ASIL 分类中的一些定义具备的信息参考性高于其法定性 - 为汽车零部件供应商提供了解释空间。作为回应， SAE 发布了 J2980 - ISO 26262 ASIL 危害评级的考虑因素，为评估危害等级提供了更明确的指南。

2018 年版的 ISO 26262 包含一份扩展词汇表，其中包含更加具体的目标。

ISO 26262 的优点是什么？

ISO 26262 确保从一开始就为汽车部件提供高水平的安全性。为整个汽车安全生命周期提供指南，从整体风险管理到具体部件的开发、生产、操作、维修和停用均有说明。 使用 ISO 26262，OEM 可以审核其供应链，并确保在生产过程的后期不会出现电气电子安全隐患，因为修复问题的成本更高。

ISO 26262 说明了这样一个事实：即在越来越多的汽车电子系统中，供应商将尝试通过协力设计硬件和软件来节省开发时间。ISO 26262 委员会概述了并行硬件/软件开发和测试的广泛指南，并指出软硬件必须一起接受测试，才能达到更高安全性。

ASIL

ASIL表示汽车安全性等级。这是 ISO 26262 标准针对道路车辆的功能安全性定义的风险分类系统。

该标准将功能安全定义为“不存在由电气电子系统故障行为相关的危害引起的不合理风险”。ASIL 根据对汽车部件的危害概率和承受度，确立符合 ISO 26262 标准的安全要求。

ISO 26262 确定了四种 ASIL — A、B、C 和 D。ASIL A 代表最低程度的汽车危害，ASIL D 则代表最高程度的汽车危险。

安全气囊、防抱死制动系统和动力转向系统必须达到 ASIL D 级，这是应用于安全保障的最严苛等级，因为其失效带来的风险最高。而安全等级范围的最低等级，如后灯等部件，仅需达到 ASIL A 级即可。大灯和刹车灯通常是 ASIL B 级，而巡航控制通常是 ASIL C 级。 通过执行危害分析和风险评估确立 ASIL 等级。对于车辆中的每个电子部件，工程师测量三个特定变量：

每个变量都可以细分为几个子类。严重程度有四个等级，从“无伤害”(S0) 到“危及生命/致命伤”(S3)。接触概率有五个等级，涵盖“非常不可能”(E0) 到“极有可能”(E4)。可控性有四个等级，从“一般可控”(C0) 到“不可控”(C3)。

需分析并组合所有变量和子分类才能确定所需的 ASIL。例如，最高危害 (S3 + E4 + C3) 的组合将导致达到 ASIL D 等级。

鉴于确定 ASILS 涉及的不确定性， 美国汽车工程师学会 (SAE) 于 2015 年起草了 J2980，“ISO 26262 ASIL 危害分类的考虑因素”。这些指南为评估特定危害的接触概率、严重程度和可控性提供了更明确的指导。J2980 不断发展 - SAE 于 2018 年发布了修订版。

随着自动驾驶汽车的发展，ISO 26262 将需要重新审视目前属于人类驾驶员的“可控性”的定义。正如当前标准中的表述，没有人类驾驶员意味着可控性始终是 C3，这是“不可控”的极限。描述严重程度（伤害）和接触概率（概率）的其他变量，无疑也需要重新检查。

ISO 26262 要求汽车原始设备制造商和供应商必须遵循并记录功能安全开发流程（从开始制定规格直到量产发布），以使其设备具备在商用车辆（轿车）内运行的资格。该标准列出了风险分类体系（汽车安全完整性等级，ASIL），旨在降低电气电子 (E/E) 系统故障行为可能造成的危害。

ISO（国际标准组织） 与国际电工委员会 (IEC) 密切合作。ISO 26262 规范作为 IEC 61508 的改编版于 2011 年正式发布，这是 E/E 系统的通用功能安全标准。

ISO 26262 与其他汽车标准有何区别？

ISO 26262 侧重于功能安全 - 确保汽车零部件能够在正确的时间发挥正确的功能。其专门针对汽车提供方案，用于确定 ASIL 风险等级。

AEC-Q100（由汽车电子委员会建立）专事研究汽车应用中集成电路的可靠性，尤其是压力测试。

汽车工程师协会 (SAE) 长期以来一直为汽车发动机的马力评级提供标准，现在又确定了 SAE J3061 中网络安全的最佳实践操作。SAE 积极参与定义车辆无人驾驶等级，并于最近制定汽车测试标准。

MISRA（汽车工业软件可靠性联合会）指南侧重于安全性 - 定义在车辆控制系统中开发安全可靠的可移植软件代码的流程。

OSEK/VDX

OSEK源于德语，英文意思是：“车载电子设备的开发系统和接口”，它是一个标准，用来产生嵌入式操作系统的规范，通讯协议栈，和汽车网络管理协议，也产生其他相关的规范。 OSEK被设计来提供整车的各种电子控制单元的软件标准架构。 由一个德国的汽车公司联盟（宝马，博世，克莱斯勒，欧宝，西门子和大众）和卡尔斯鲁厄大学成立于1993年。

VDX则是汽车分布式执行标准（vehicle distributed executive），由法国的由雷诺和标致汽车发起，也加入到这个联盟来。从此，正式名称为 OSEK/VDX。

在1995年召开的研讨会上众多的厂商对OSEK和VDX的认识达成了共识，产生了OSEK/VDX规范(1997年发布)，简称OSEK规范。

它主要由四部分组成:操作系统规范(OSEK Operating System,OSEK OS)、通信规范(OSEK Communication , OSEK COM )、网络管理规范( OSEK Net Management, OSEK NM)和OSEK实现语言(OSEK Implementation Language,OIL)。

第一个商业化的OSEK操作系统由德国3Soft公司开发，最早应用于奥迪A8的仪表控制器。

OSEK的一部分被标准化为ISO 17356。

Arctic Core 是一个双认证的AUTOSAR实现和OSEK实现，现在已经闭源。archive

MISRA（汽车工业软件可靠性联合会）

MISRA为开发安全和安全保障相关的电子系统、嵌入式控制系统、软件密集型应用程序和独立软件提供指南。

MISRA 由汽车制造商、零部件供应商和工程咨询公司进行协作。其接受指导委员会的管理，该委员会成员包括福特汽车公司、宾利汽车公司、捷豹路虎公司、HORIBA MIRA 公司、ZF TRW 公司和利兹大学 (University of Leeds)。

该标准虽然发源于汽车工业，但已在航空航天、生物医学和金融等其他市场获得认可。同样也被嵌入式、物联网和工业控制系统所接受。虽然其合规性并不能保证软件不会出现任何质量或安全问题，但确实能够生成更强大、更易于维护和更容易移植的代码。

MISRA 与 ISO 26262 和 ASIL 相比有何区别？

MISRA 侧重于编码安全标准。ISO 26262 侧重于功能安全衡量并确立 ASIL 风险等级。

如何使用指南进行规范？

该指南中最突出的内容，旨在针对使用 C 和 C ++ 编程语言开发的项目。其中包括 MISRA C 2004、MISRA C ++ 2008 和 MISRA C 2012 标准。

MISRA 指南分为强制性、必要性和建议性类别。必须不违反“强制性”指导原则才能合规。但是，如果有书面情况解释，则允许存在某些违反“必需性”指南的情况。当且只有在不影响安全和安全保障且没有合理的解决方法时，才允许出现这些偏差。例如，不能更改的第三方自定义代码。

MISRA 合规性面临哪些挑战？

软件现在可以控制从防抱死制动器和动力转向、到导航和信息娱乐系统的所有功能。这些系统全都由不同的供应商提供。而且软件供应链越来越长，每一个最终产品的代码都包含了多家供应商贡献的力量。

MISRA C/C++ 已经在事实上成为汽车系统的编码标准。但是并未涵盖最近的 C++ 语言改进内容，也未反映最新安全违规和漏洞的知识。

MISRA 如何发展而来？

2019 年 1 月，MISRA 宣布将 AUTOSAR 指南与他们自己建立的最佳实践相结合，单独开发一套”专用”语言子集，用于安全相关的 C++ 开发。MISRA 主导的指南将包含最新版本的语言 (AUTOSAR’s C++17)，以及可用的后续版本 (AUTOSAR’s C++20)。

有机结合的 MISRA-AUTOSAR C++ 采用一套通用规则确立统一的行业标准，是面向整个供应链中所有开发人员的单一参考点。

MISRA 合规的优点是什么？

当今汽车中使用的代码超过 1 亿行。在接下来的十年，汽车中使用的代码平均将达到 3 亿行。MISRA 编码指南促进了满足以下条件的代码开发：

AUTOSAR(AUTomotive Open System ARchitecture)

1、 汽车电子系统复杂度和代码量的不断提升，当前整车控制系统的代码量都已达到千万行代码的级别，其复杂度远比高端的航空航天要高，只是安全性比他们要低些。

2、 软件的复用性差，由于软件依赖于固定的硬件开发，当硬件发生变更时功能往往需要推倒重来，无疑增加重复开发的工作量和周期，这都是血琳琳的投入和成本。

对于此，圈内几位大佬岂能坐视不管，于是相约一起讨论五百回合最后搞了个Autosar出来，并成为最初的九大核心成员（博世、BMW、大陆、福特、戴姆勒、PSA、通用、丰田和大众）。

在没有AUTOSAR之前，每一个新的ECU项目都需要重新编写通信协议栈，存储协议栈等，需要大量的时间与人力，应用AUTOSAR之后，使用AUTOSAR基础软件配置工具可以快速配置并且生成基础软件的代码。使用AUTOSAR后，如果某个ECU需要更换MCU芯片，那么只需要使用芯片厂商提供的MCAL生成工具生成MCAL代码，将这部分替换之前的MCAL代码即可。为什么这么方便呢？因为AUTOSAR将MCAL与其他模块的接口规定好了，各芯片厂商都会根据这些接口编写MCAL代码，所以切换MCAL变得非常简单了，具体的规则，笔者将在后面为大家详细说明。

按照之前没有AUTOSAR时的软件开发方式，架构师可能通过Ecxel文档管理各模块的之间的接口，但是直到编译代码的时候才能发现各模块的接口是否是连接上的，这种方式一方面不直观，另一方面对整个开发进度是不利的。如果使用了AUTOSAR工具，架构师就能够对软件接口进行自动化集成，为后面的软件开发顺利进行奠定基础。

AUTOSAR软件的价格十分高昂：如果需要开发完整的AUTOSAR环境的话，需要购买第三方软件，目前主流的AUTOSAR软件有DAVINCI,ISOLAR等，这些软件动辄百万级RMB，导致AUTOSAR的门槛非常高。

AUTOSAR的正式文档是作为规范而不是作为指南编写的。更糟糕的是，如果你时间有限，并且希望通过阅读AUTOSAR文档学习AUTOSAR，那么你将陷入痛苦的深渊，AUTOSAR文档不仅数量多而且难以理解，AUTOSAR文档的具体格式笔者将在后面的文章中做具体介绍。

AUTOSAR同时也是一家致力于制定汽车电子软件标准的联盟，目前有100多个会员。各会员依据其对AUTOSAR的贡献及责任分为三个等级，Core Partners（核心合作伙伴）、Premium Partners（高级合作伙伴）、Associate Partners（发展合作伙伴）。9家核心公司主要负责AUTOSAR开发模式的筹划、管理和调控，也是AUTOSAR协议的发起人。高级合作伙伴和发展合作伙伴在核心会员成立的项目领导组的协调和监督下开展工作。值得一提的是，目前国内主机厂只有三家支持AUTOSAR协议，上汽、吉利和一汽。

AUTOSAR致力于标准化嵌入式软件架构，为创新的电子系统改进性能、安全、环境友好等奠定基础。软硬件之间彼此独立，各个层级之间的开发从此解耦，节省了开发成本和开发时间。对于OEM和供应商而言，彼此的软件复用性都大幅提升，提高了开发效率和开发质量。

AUTOSAR（AUTomotive Open System Architecture），即汽车开放系统架构，由全球汽车制造商、零部件供应商及其他电子、半导体和软件系统公司建立，目的是为了降低汽车控制软件的开发风险，提高软件复用度。AUTOSAR联盟自2003年成立以来，成员队伍不断壮大，基本上涵盖了世界各大著名整车厂、零部件供应商、半导体公司及软件工具开发商。近年来也有越来越多的中国企业例如华为、百度、长城汽车等加入联盟。

Autosar是国际几大OEM和tier1联合搞出来的开发标准，尽管不是强制标准，但只要主机厂要求支持，ECU开发中还是要支持的。

AUTOSAR中规定的操作系统就是OSEK，而通信和网络管理虽然和OSEK有区别，但思路一样的。

所以认为，AUTOSAR是基于OSEK提出的（但不仅基于OSEK），OSEK被AUTOSAR标准软件架构包含。

这里说的AUTOSAR随着汽车智能化和网联化发展，被称为Classic AutoSAR。

Classic AutoSAR是基于强实时性的嵌入式OS上开发出来的软件架构，能满足传统汽车定制化的功能需求，且能很好胜任；但是一旦要汽车接入网络，网络很可能有延迟、干扰，很可能无法满足强实时性。

这种情况下Classic AutoSAR就无能为力了，所以就需要一套能够满足非实时性的架构系统软件，在这样的背景下，Adaptive AUTOSAR就诞生了。但是由于Adaptive AUTOSAR安全级别基本还停留在ASIL-B（最高是D），所以很多需要强安全级别的ECU当下还是需要Classic AutoSAR（能满足ASIL-D）来实现。

基于Classic AutoSAR平台开发的汽车控制器，具有如下特点：

1、硬实时，可在us时间内完成事件的实时处理，硬实时任务必须满足最后期限的限制，以保证系统的可靠运行。

2、高功能安全等级，其可达到ASIL－D的安全等级。

3、对CPU、RAM或Flash等资源具有较低的占用率。

4、软件功能通常是固化不可动态变更的。

Apdative Autosar作为异构软件平台的软件架构，主要用于域控制器，可以成为连接Classic AutoSAR和Linux这样的非实时OS的桥梁，其具有如下特点：

1、软实时，具有毫秒级内的最后期限，且偶尔错过最后期限也不会造成灾难性后果。

2、具有一定的功能安全要求，可达到ASIL－B或更高。

3、与经典平台不同的是，它更适用于多核动态操作系统的高资源环境，如QNX。

Adaptive Autosar与Classic Autosar相比，虽实时性要求有所降低，但在保证一定功能安全等级的基础上，大大提高了对高性能处理能力的支持，以支持智能互联应用功能的开发，因此C＋＋将成为Adaptive Autosar平台的主要开发语言。

尽管AUTOSAR C ++并没有明确要求工具资格来批准使用静态分析解决方案，但ISO 26262确实需要。因此，当计划使用AUTOSAR C ++简化对ISO 26262的遵从时，建议选择一种静态分析解决方案，该解决方案为最终用户提供适当的证书和资格认证工具。

严格来讲，使用C++14编译器编译的代码是不能遵从MISRA规范的。所以，开发团队采用AUTOSAR编码规范是毋庸置疑的。不仅如此，如果您的项目需要按照C++14编码并且需要说明该项目符合ISO26262功能安全标准，那么AUTOSAR编码规范就是无可替代的，因为在AUTOSAR编码规范之前没有其他的编码标准是为了支持符合C++14编写的安全关键型软件而设计的。

JasPar

日本的autosar还有中国的autosar等等待补充

总结