汽车软件架构 网络安全和功能安全相结合
功能安全性与网络安全性息息相关，在开发中任何方面都不能忽略。但是，如何才能正确完成呢？
功能安全性与网络安全性息息相关，在开发中任何方面都不能忽略。但是，如何才能正确完成呢？
随着诸如自动驾驶之类的新技术的引入，汽车软件开发需求正在增加。在此过程中，电子控制单元（ECU）和软件功能的数量正在增加，就像接管越来越多的驾驶任务的各个功能的复杂性一样。
据估计，可能有超过 1 亿行代码，而一辆高级车辆可能具有 100 多个控制单元。但是，在这些高度复杂的整体系统中，尤其是在车辆互连性不断提高的情况下，如何才能满足功能安全和网络安全的要求？高质量是当今汽车软件开发的基础，而诸如汽车 SPICE 之类的过程模型是坚实的基础。
AUTOSAR 和功能安全
适当的软件体系结构是业界满足这些功能和非功能要求并同时试图控制复杂性的最重要方面。通过 AUTOSAR 已定义了标准化的体系结构。它允许制造商和供应商之间使用“通用语言”。在此框架中，不仅要确定功能要求和软件组件，还要确定用于描述应用程序，接口和其他元素的数据格式。这种标准化还可以实现 OEM 和供应商生态系统之间现在常用
的合作模型。改善的合作关系显着提高了软件组件的重用性，并总体上提高了质量。
同时，对功能安全性的要求也越来越高，因为在车辆中安装了越来越多的主动功能或干预驾驶动态的功能：从制动器（例如 ABS，ESP 或转向系统，例如 EPS）到主动安全功能例如安全气囊或自动紧急制动（例如AEB）。由于不正确的激活或系统故障可能会导致严重的后果，因此此类系统与安全性相关。
ISO 26262 安全标准定义了如何在过程和方法级别的系统开发中实现功能安全的各个方面。对于软件体系结构，功能安全是决定性的影响因素。因此，例如通过 AUTOSAR 已经处理了标准化的部分内容。基本的完整性机制（如系统完整性监视，分区，时间和过程监视或安全通信）已经可用，并且已在批量生产项目中使用（图 1）。此外，功能安全的许多系统或特定于项目的方面正在单独考虑和解决。
（*图 1：Elektrobit 的 AUTOSAR 架构，扩展了功能安全的标准组件）
安全的多核系统
同时，不仅正在开发更多的功能，而且正在开发更多的 CPU 密集型功能，这些功能对车辆所需的计算能力提出了更高的要求。因此，就像 IT 领域的计算机一样，使用多核系统来代替单个处理器。这直接影响了软件体系结构，因为现有的软件系统通常是专门针对单个处理器开发和优化的，只能充分利用额外的计算能力。多核系统还可以整合车辆中 ECU 的数量，从而可以节省功耗和重量。这样的域控制器系统通常接管汽车领域中的许多功能，例如动力总成或车辆内部。这会影响功能安全的要求：如果仅合并的功能之一与安全相关，那么整个系统也必须是安全的。
从无提示到操作失败
传统上，大多数汽车系统并非开发为“无故障的”，即它们不是故障操作的。安全状态通常意味着禁用某个功能或一组功能。驾驶员会得到通知，但是根据故障系统的安全性，无法继续行程。这对于制造商和驾驶员而言都是令人沮丧的，但是从功能安全的角度来看，通常是故意选择的安全状态。系统承担的驾驶动力功能越多，但是，仅关闭功能的可能性就越小，并且故障本身被归类为与安全相关。过渡是流畅的，但是无论如何在最晚的高度自动化驾驶中，都必须将系统开发为可故障运行：尽管出现故障，但系统至少必须提供有限的功能。例如，它可能不会在行驶过程中简单地关闭，而是必须至少缓慢地滑行至安全位置的停车处。对
于系统和软件开发以及最终的软件体系结构而言，这种系统可靠性代表着另一个挑战。
联网车辆和网络安全
网络安全在汽车系统开发中一直很重要。诸如发动机防盗器，安全电子钥匙或里程表读数的安全保存之类的系统已经是基本设备。但是，车辆之间不断增加的互连性给行业带来了挑战。现在提供在线产品可以从许多制造商处获得：车辆诊断可以部分远程执行，交通信息可以实时传输，导航系统的地图信息可以自动更新。与 IT 的基本规则一致，“无论什么连接都将受到黑客的攻击”，安全性和数据隐私的系统方面在汽车工业中也越来越突出。通过远程访问或 Internet 对系统进行的首次成功攻击已经公开，并引起了强烈的反响。为此，SAE 于今年年初发布了用于开发安全系统的手册[1]。该手册同时描述了过程和方法，并从 ISO 26262的生命周期中衍生而来。它本身不是标准，但是在文档中，总结了诸如研究程序或标准以及迄今为止的出版物之类的基本工作。从这个意义上讲，这是一个宝贵的贡献，可以作为引入流程和方法的切入点。
共同考虑安全保障
功能安全性和网络安全性的两个方面通常被孤立地考虑，并且彼此独立。在组织上，任务也分配到汽车公司的不同部门。但是在车辆中，这两个方面必须同时实现。因此，有必要使流程和开发彼此同步。从系统工程的角度来看，这是有道理的，因为在此领域中，功能安全性仅被视为专
业工程，而不是彼此隔离。这种认识早已在其他行业中确立，例如在航空工程或机车工程中。
安全与保障之间相互作用的一个例子是风险分析。在功能安全中，一个是指危害和风险分析（HARA），在安全性中，是指威胁和风险分析（TARA）。威胁（例如通过攻击）如果成功，会在功能安全的意义上导致危险。在实践中已经显示的一个示例是未经授权的制动消息，该消息通过外部连接的系统发送到车载系统。因此，通常在开发过程的早期就进行这两种分析。比较识别出的风险或威胁，并从“其他”角度再次将其视为潜在风险（图 2）。
（* 图 2：用于系统工程的组合过程模型）
关于该主题的出版物已经很多，并且 SAE 手册还结合了流程，尤其是TARA 和 HARA 风险分析。在未经授权的制动消息的情况下，这将导致保护消息的安全。
与功能安全类似，实际上，安全的目标也是将用作方案基本组件的基本机制标准化。因此，AUTOSAR 已经具有加密功能和接口的基本库，并定义了控制单元之间的安全或加密通信。根据使用情况，这些基本组件
可以在保护要求较低的简单系统中完全用软件开发，也可以依靠专用硬件。在 EVITA 项目中，提出了各种方案和系统。因此，具有高保护要求的系统可以使用硬件组件，例如硬件安全模块（HSM）。
在未来的系统架构中，对车辆的在线访问特别重要，必须同时满足功能安全性和安全性的要求。例如，“智能”天线被指定用作车辆的中央接入点，因此配备了远程信息处理功能。此外，它可以执行必须与基本功能隔离的动态应用程序（图 3）。
（*图 3：结合带有远程信息处理单元的“智能”天线示例的组合架构）
当今，ECU 的体系结构要求变得更加复杂。通过标准架构，功能安全性，安全性，多核系统和可用性等方面的组合，可以设计可靠的系统，并根据用例理想地评估和组合各个系统方面。图 4 显示了各种系统方面的可能解决方案。
在具有实时性和功能安全性要求的经典多核系统中，使用了 AUTOSAR体系结构。向具有安全性要求的动态系统过渡将是不稳定的。对于各种
情况，都需要结合可以从工具箱中获取的标准元素的灵活“配方”和特殊的解决方案。这些系统一起加入了自动化软件工厂，以确保质量并提高效率，最终使安全和自动驾驶成为可能。
（*图 4：多核系统的各种解决方案）
参考书目：
[1] SAE J3061，“网络物理系统网络安全指南”，2016 年
作者：Rudolf Grave 和 Alexander Much
来源：Elektrobit (EB)ktrobit (EB) tomotive GmbH