嵌入式控制系统设计/汽车

的Wikibook 嵌入式控制系统设计

引言

对于嵌入式汽车系统的设计，整个车辆系统通常被分成四个不同的功能区域，这些区域可以在设计阶段进行分离。

• 底盘
• 传动系统
• 车身
• 远程信息处理

这些区域中的每一个都将具有不同的优先级和需求，并且这些区域通常也会由不同的设计团队负责。需要指出的是，虽然这些区域在过去是完全分离的，但新的功能和法规正在迫使这些不同的区域相互通信。这些区域的设计需求差异很大，区分由于法规而产生的需求和由于竞争而产生的需求至关重要。传动系统和车身（被动安全）区域的大量需求将是由于法规造成的，因此可以被认为是硬约束。另一方面，底盘和远程信息处理的许多需求是由于制造商之间的竞争造成的，并提供了更大的设计自由度。

系统需求

本节不会详细阐述所有不同车辆系统的不同功能需求。而是概述车辆最重要的系统级需求，以及这如何影响嵌入式控制系统的需求。

• 安全性

对安全性的需求将对传动系统和底盘的嵌入式系统施加一些重要的功能和非功能约束。这些需求通常不是由法规驱动的，而是由制造商之间的竞争驱动的。

• • 硬实时约束：所有与安全相关的系统都必须遵守实时约束，这一点至关重要。诸如ABS之类的系统应该能够在几毫秒内做出反应，以确保及时干预。这不仅对处理器的速度提出了约束，而且对整个汽车中使用的通信系统的速度也提出了约束，因为这些系统通常依赖于来自其他系统的输入信号，并且还需要向其他系统发送输出（例如，电子稳定控制系统必须与发动机管理系统通信）。
  • 故障检测：安全关键功能的每个子系统都应该能够自动诊断其功能，并且在发生故障时应该能够切换到安全关闭状态。显然，通信系统也应该能够执行数据传输检查。法规规定，如果检测到故障，也应将其显示给驾驶员（故障指示灯）并将其存储在控制器的故障存储器中。
  • 冗余：关键传感器，如线控油门系统中的节气门，应具有冗余性，以最大程度地降低故障概率。
  • 复位时间？启动时间？
• 成本

与所有行业一样，制造成本在汽车行业也非常重要。

• 排放/燃油经济性

排放约束背后的主要驱动力一直是法规，尽管最近燃油经济性已成为越来越重要的销售论据。这项法规的一个非常重要的方面是车载诊断（OBD），它持续监控发动机系统以确保日常使用符合排放法规。传动系统的一些最重要需求是

• • 监控与排放相关的电气组件（例如，短路）并存储故障（OBD 1）。
  • 监控系统功能（例如，传感器信号的合理性检查）（OBD 2）
  • 必须监控用于监控影响诊断的与排放相关的组件的组件。（OBD 2）
  • 监控频率通常由法律规定。
  • 故障必须通过故障指示灯（MIL）显示给驾驶员。
• 上市时间

对缩短上市时间的推动使系统开发朝着更多可互换组件的方向发展。这目前非常困难，因为没有明确的通信标准。总线通信系统使得将新功能引入现有系统变得更加容易。

• 乘客舒适度

由于竞争的原因，乘客舒适度在汽车行业也非常重要。这些需求主要适用于内部和远程信息处理领域的系统。这也对嵌入式系统施加了一些约束。

• • 软实时约束：许多非关键系统（例如，电动车窗，电动后视镜……）都规定了定时约束，但是违反这些约束不会产生严重影响。例如，许多此类系统必须在100毫秒内做出反应，这是人类可以感知的延迟限制。

设计流程

汽车中的嵌入式系统通常遵循模型驱动设计工作流程（如设计流程一节中介绍的那样）。

功能需求通常应在功能设计阶段予以考虑。这还包括故障安全模式。

应在实施阶段考虑定时约束。确保硬件能够达到定时约束非常重要，但也不要性能过高。还应在此阶段考虑对通信速度的需求。如果通信速度非常关键，甚至可能需要在原始车辆模型中包含通信网络的详细模型。所有用于监控硬件故障的功能也只有在此阶段才能设计。必须满足实时约束的关键功能通常需要其自身的硬件来确保实时运行，因此这是一个从设计开始就应考虑的约束。在实践中，这可能非常困难。

一个非常重要的设计阶段是配置不同车辆系统之间的通信。由于信号数量不断增加且缺乏标准化，这目前非常耗时。AUTOSAR标准旨在极大地促进此阶段。

硬件

最初，汽车配备了单一信号电缆。随着电子系统数量和复杂性的增加，这种方法由于成本、重量和复杂性的原因不再可接受。这就是为什么制造商转向车载总线系统（例如CAN总线）来实现不同系统之间车载通信的原因。一辆汽车中通常有多个总线，每个系统都适应特定系统组的速度需求。有关这些总线系统的更多信息，请参阅有关现场总线的章节。

目前，大多数功能都编程在带有程序存储器（EPROM或闪存）的微控制器中。由于功能种类繁多，现代汽车中也存在各种传感器。安全关键组件（如ESP传感器）上的传感器也需要具有内部自监控功能。

Autosar

当前问题

当前的车辆系统以专有解决方案为特征：不同车辆系统中的应用程序使用其他接口或其他通信标准。这导致供应商为每个系统开发和维护单独的软件，而不是在每个系统上使用相同的软件并处理通信、功能和信号定义的兼容性问题。

原始设备制造商 (OEM) 负责集成不同的系统并保证集成系统的确定性运行。这项任务常常因不同供应商的应用程序所使用的不同诊断服务而变得复杂。随着嵌入式控制系统数量和交互程度的增加，专有解决方案的进一步扩散将需要更多资源，并且保证集成系统的确定性运行将变得更加困难。

此外，还有一个趋势是为客户提供更大的灵活性；客户希望从不同的选项中进行选择。这导致了一个基本车辆系统出现许多细微的变化，这在现代模块化和实现灵活性水平较低的系统中需要大量的设计工作。

为了解决这些问题，汽车制造商、供应商和工具开发商联合起来开发了一个新的标准。该项目名为 AUTOSAR，它是 AUTomotive Open System Architecture（汽车开放系统架构）的首字母缩写。在 AUTOSAR 的维基百科文章 中，解释了 AUTOSAR 的目标和技术信息。

AUTOSAR 标准

AUTOSAR 标准旨在成为一项突破，它应该能够实现车辆系统设计的范式转变，并带来功能改进和更高的安全性。

术语

AUTOSAR 项目引入了自己的术语，这些术语将在本文的其余部分使用。更多信息可以在 AUTOSAR 的维基百科文章 中找到。

AUTOSAR 方法：一种四步方法，可用于从设计模型开始创建车辆系统架构。

基础软件：标准化的软件，不包含任何对最终用户可见的功能，但提供硬件相关和硬件无关的服务。

运行时环境：在软件级别实现可能的通信路径。

应用软件：实现实际功能的软件，这些功能对最终用户可见。

标准分析

可重用性

AUTOSAR 项目选择标准化通信和非功能性软件，例如运行时环境和基础软件。功能软件，即应用软件，仅通过其接口进行标准化。

这有几个影响

• OEM 可以通过为每个特定应用程序选择最佳的软硬件来构建车辆系统，而无需担心兼容性问题。这意味着集成成本降低。此外，维护更容易执行，因为可以为所有应用程序标准化诊断服务，而不是依赖于供应商。
• 供应商仍然可以在应用软件组件的实现方面进行竞争。这应该会导致更好的组件。同样，由于接口清晰，供应商可以为所有不同的车辆系统构建、调试和维护其应用软件的一个版本，从而减少软件的扩散。由于接口清晰，在供应商之间或供应商团队之间划分开发也有更多选择。
• 硬件供应商仍然可以在最佳硬件方面进行竞争，仅用于使用硬件的必要基础软件将被标准化，但将有选择来保护特定软件（例如，用于消除执行器非线性效应的特殊软件）。
• 由于定义明确的领域，新公司可以轻松进入市场。一家公司只需要在其领域成为专家即可。

安全性

为了提高根据 AUTOSAR 标准设计的车辆系统的安全性，包含了一些安全措施。

• 安全完整性功能，这些功能是 AUTOSAR 中必须具备的安全措施，独立于应用上下文。这些功能支持应用功能和安全功能的正确执行。通常，这些功能与资源保护、监控和自检有关。由于 系统复杂性 的变化，需要采取此类别的额外安全措施。例如，如果两个应用程序可以使用相同的资源并共享内存，则需要构建一些安全措施；例如，防止写入其他应用程序的数据段。
• 支持依赖于应用程序上下文的安全功能。这意味着支持来自不同应用程序的系统中典型的安全功能，例如关键应用程序的快速重置。
• 通用安全要求，例如在不传播的情况下本地检测故障。

安全功能可以自动添加到所有车辆软件中，这与现有的车辆软件设计方法相比是一个很大的优势。

标准和接口的清晰集合减少了由于应用程序之间错误交互而导致故障的可能性。

AUTOSAR 中的设计

基于组件的设计

AUTOSAR 项目在车辆软件设计中引入了基于组件的软件设计概念。由于车辆系统日益复杂，因此需要进行此更改，这导致需要团队合作。

• 在基于组件的设计中，每个组件应该做什么很清楚，因此设计可以轻松地划分为不同的团队。此外，接口是标准化的，这保证了数据交换的一致性。
• 元模型 简化了团队合作。车辆系统的正式描述确保了信息的结构可以清晰地可视化，并保证了信息的一致性。
• 基于组件的软件设计促进了基于模型的设计的使用。因此，可以扩展基于模型的设计的使用，这是车辆系统设计中的当前标准。
• 基于组件的设计使汽车软件开发从基于 ECU 的方法转变为基于功能的方法，并使编写独立于所用 ECU 的应用程序软件成为可能。

系统设计的四个基本“关注点”

由于车辆系统的复杂性不断增加，因此需要明确控制交互过程，而不是隐式定义嵌入在不同子系统本身中的交互。

在这种情况下，引入了 系统设计的四个基本“关注点” 的概念。这些代表了交互过程中的不同层次。

明确的层级由于更好地概述了交互过程而促进了车辆系统的设计。特别是车辆系统的变化，这需要协调方面的变化，将更加直接。

• 通信取决于所使用的协议、接口以及有关数据交换格式的约定。这在标准中有所规定。
• 计算取决于应用软件组件。
• 配置取决于系统设计人员和用于该方法的工具链。系统设计人员设计 ECU 网络的物理拓扑结构，并决定要向车辆系统添加哪些应用程序。在遵循该方法时，所选工具链中的优化算法确定不同应用程序在不同 ECU 上的分布。
• 协调在 运行时环境 中指定。运行时环境是配置的实现，能够管理 ECU 间和 ECU 内通信，并且可以调用不同的应用程序以在其通信端口处理通信。

应用软件仅影响计算步骤，因此不知道计算和配置层。这使得创建不知道交互伙伴数量的应用软件成为可能。这样，通信和功能之间就有了明确的区分。

交互的明确控制使得可以向车辆系统添加应用程序，而无需更改与新应用程序交互的某些应用软件。必要的更改位于运行时环境中，在使用 AUTOSAR 方法时，在 ECU 配置步骤中会自动调整运行时环境。

对系统复杂性的影响

AUTOSAR 标准也改变了 车辆系统的复杂性。现代车辆属于分布式硬件分布式软件类型。

AUTOSAR将系统视为在单个虚拟平台上运行的不同应用程序。该标准使得将虚拟平台转换为不同ECU上的实际实现成为可能，其中一些应用程序可能运行在同一ECU上。这种方法为转向分布式硬件-集中式软件的系统铺平了道路。

这种新的车辆系统模型对安全有一些影响。

从实际的角度来看，ECU的共享也是必要的。车辆中嵌入式控制系统的数量不断增加，但车辆中ECU的数量正在达到极限。成本过高，车辆空间有限。通过AUTOSAR提供的虚拟化工具，可以在ECU上严格分离功能，而不会损失安全性。这可以为减少（但更强大）的ECU打开道路。

实际方面

整车厂

Autosar标准化是车辆系统设计方法的重大改变。这使得将现有车辆系统适应Autosar兼容架构变得困难。根据Autosar核心合作伙伴的推广计划，整车厂不会在一天内切换到Autosar兼容系统，而是会从在一个经典设计的E/E架构中为一个大型子系统集成一个Autosar兼容的ECU开始（引用）。通过这种方式，可以积累经验，然后整个子系统，最终整个车辆系统都可以变得与Autosar兼容。

供应商

缺乏现有的Autosar兼容车辆系统使得供应商难以测试旨在与Autosar兼容的新组件。为了解决这个问题，一些公司在项目中联合起来，生成一个Autosar兼容的测试平台，不同的公司可以在其中测试其软硬件。例如SWAP项目，其中八家瑞典公司拥有设计专业测试平台的必要和互补能力，联合起来。

未来

展望未来，这些趋势似乎将继续下去。例如，网络汽车或无人驾驶汽车需要了解整个车辆的状态才能以最佳方式控制车辆。只有当存在集中式软件时，这才能实现。

在遥远的未来，汽车之间以及汽车与道路基础设施之间的通信可能会成为一种趋势。

例如，网络汽车车队。这样的车辆车队在一个道路网络上形成一个管理的运输系统，用于乘客或货物，具有按需和门到门的运输能力。 这种类型的系统属于“分布式硬件-集中式软件”类别。车队问题主要涉及以下要素： - 将车辆分配到特定需求，- 行程结束后重新分配车辆，- 避免死锁，- 需求管理和票价收取，- 分布式与集中式管理，- 通信架构。

除了由中央管理系统控制的车队之外，还可以想象，人们也会寻求仅与其周围环境以及可能收集交通信息的中央系统通信的自动驾驶汽车。然后，这辆汽车可以自主决定应该采取什么行动。

梅赛德斯-奔驰目前正在开展这方面的实验。他们的工程师正在开发一个名为“交互式车辆通信”的系统，该系统允许汽车相互通信。他们研究的现状体现在他们的概念车“ESF”中。不同汽车之间的数据交换是通过车辆之间在短距离内形成的“临时”网络进行的。这些WLAN不需要额外的外部基础设施。传输频率为5.9 GHz，距离最远可达500米。当然，如果不同的汽车相互通信并将消息传递给对方，则此距离会扩展。

目前，法兰克福有一个名为“simTD”的项目。 不同的德国汽车制造商参与了这项测试，最多有400辆汽车相互通信。这项测试的主要目的是提高道路安全。

参考文献

嵌入式控制系统设计