|
在不断发展的汽车技术领域，电子系统标准化和互操作性的需求变得至关重要。随着车辆集成越来越复杂的软件功能，诸如 AUTOSAR（AUTomotive Open System Architecture 汽车开放系统架构）之类的框架已成为汽车行业的基础支柱。AUTOSAR 的历程不仅展示了标准化工作，还展示了为满足现代车辆架构和软件开发范例的需求而不断发展的过程。AUTOSAR 的起源可以追溯到 2000 年代初，当时主要汽车制造商和供应商认识到开发汽车软件时采用标准化方法的必要性。它是一个开放、标准化的汽车软件架构，支持应用软件和基本车辆功能之间接口的标准化，有助于为所有AUTOSAR成员建立通用的ECU软件架构。主要目标是解决车辆电子设备日益复杂和电子控制单元 (ECU) 激增带来的挑战。
从本质上讲，它是一个标准化的开源平台，可实现现代车辆内各种电子控制单元 (ECU) 之间的无缝通信和集成。它提供了结构化的软件架构，使汽车制造商和供应商能够高效协作、缩短开发时间（找元器件现货上唯样商城）并提高软件质量。通过其分层方法，AUTOSAR 简化了复杂的软件生态系统，促进模块化和可扩展性，同时确保不断发展的汽车领域的安全性和可靠性。
AUTOSAR 旨在为成员提供固有的优势，以管理日益复杂的 E/E 车载环境，例如复杂 ECU 网络中功能的轻松集成和交换以及整个产品生命周期的控制。
多年来，AUTOSAR 经历了多次迭代，每次迭代都旨在完善其架构、通信协议和软件开发方法。AUTOSAR 发展的重要里程碑包括：
1.
基础软件（BSW）堆栈：标准化基础软件模块的开发构成了 AUTOSAR 架构的核心。这些模块提供了通信堆栈、诊断和操作系统服务等基本功能，确保了不同汽车平台之间的一致性。
2.
通信协议：AUTOSAR 引入了 CAN（控制器局域网）、LIN（本地互连网络）和 FlexRay 等标准化通信协议，实现了车辆网络内 ECU 之间的无缝通信。这些协议在支持实时、确定性通信方面发挥了至关重要的作用，这对于安全关键型汽车系统至关重要。
3.
方法和工具：AUTOSAR 制定了开发过程指南，包括软件设计、配置和集成的方法。此外，围绕 AUTOSAR 的生态系统已扩展到包括各种开发工具、配置编辑器和代码生成器，从而简化了汽车制造商和供应商的软件开发生命周期。
4.
自适应平台：随着汽车行业拥抱电气化、互联化和自动驾驶等趋势，对更加灵活和可扩展的软件架构的需求变得显而易见。AUTOSAR 通过推出自适应平台来满足这些需求，该平台旨在支持动态软件更新、无线（OTA）功能和高级驾驶员辅助系统 （ADAS）。
5.
与行业标准集成：AUTOSAR 不断与其他行业标准和计划保持一致，包括针对功能安全的 ISO 26262 和针对网络安全的 ISO 21434。通过将这些标准集成到其框架中，AUTOSAR 确保汽车系统满足最高的安全要求。
AUTOSAR 的初始阶段侧重于定义分层软件架构，以促进跨不同车辆领域的汽车软件的开发、集成和可扩展性。分层架构方法允许关注点分离，并实现软件组件更大的模块化和可重用性。经典的 AUTOSAR 平台在微控制器上运行，分为 3 个主要层；
1.
基本软件架构（Basic Software Architecture） - It is common to any AUTOSAR ECU.
2.
AUTOSAR 运行时环境（AUTOSAR Runtime Environment）
3.
应用层（Application Layer）
最近，有必要支持可以在硬件或软件扩展中实现的概念，使 AUTOSAR 能够配置和利用高级硬件功能，而不受任何特定实现目标的限制。
转向集中式和区域式 E/E 架构需要 OEM 为其架构上的许多功能更强大的 ECU 规划更大规模的同步新一代 ECU，这通常与为 OEM 带来更多软件以及更多的内部 ECU 开发相一致。
AUTOSAR 自适应平台的推出是为了支持更多应用程序，例如汽车行业日益可用的高性能计算的功能和灵活性。随后，经典平台和自适应平台的通用功能已转移到基本标准中，以确保保持互操作性。
虽然 AUTOSAR 自适应平台扩展了 AUTOSAR 支持的 ECU 类型，但 AUTOSAR 经典平台仍然适用于许多传统 ECU，但专注于将高计算功能和服务整合到中央/区域/域 ECU 中并不能完全消除功能相对简单的 ECU 控制和监视输入和输出。Classic Platform 非常适合具有安全相关功能的控制功能，同时支持高达 ASIL D 的可用和网络安全扩展，以确保免受恶意或系统故障造成的干扰。
经典平台作为编号版本发布到 4.4.0，其中第一个 4 代表主要平台版本，概念的更改, 不兼容前代。第二个 4 代表增量版本，其中添加了新概念，这意味着同代标准本身也不完全兼容。最后的 0 代表次要版本，对标准进行澄清和修复，而不是概念更改或添加。该标准的所有 3 部分现已作为年度版本一起发布，即 R20-11，对应于 2020 年 11 月。大多数 OEM 为一代 E/E 架构使用特定版本已成为正常做法，通常是稍后（或有时更早）版本或特定于 OEM 系统设计的一些增强和/或定制。
在最近的版本中，根据 AUTOSAR 创建的目标，我们更加努力地协调经典平台和自适应平台之间的架构和功能，从而简化两个平台在生产 E/E 架构中协同工作的部署。
R20-11 版在经典平台中新增对 ieee802.3 g 规定的以太网10BASE-T1S 的支持，使以太网中的总线拓扑成为可能。经典平台和自适应平台都将支持 OSI 模型第 1 层和第 2 层上的这一新扩展。
新增加了以太网唤醒（Ethernet Wakeup On Dataline）功能，扩展了以太网通信栈，结合现有通信功能（如部分网络）使用符合 OA TC10 的以太网硬件（PHY）。
在车辆网络状态管理中，通过动态学习额外路由的可能性，扩展了基于静态路由的现有 PNC 协调算法。
引入了"入侵检测系统管理器 "概念，规定了基于 AUTOSAR 的入侵检测系统 (IDS) 的框架。
此外还定义了车辆运动控制接口、10BASE-T1S、经典平台灵活性，并针对经典平台和自适应平台的交互进行了升级，加强了两个平台之间的互动。
R21-11 版在 R20-11 基础上，进一步定义和增强了经典平台的功能：
1.
定义了 10BASE-T1S 中支持两种可用的 HW 解决方案：通过 SPI 的 10BASE-T1S 外部 MAC 控制器和通过 MII 的 PHYs。
2.
增强了 经典平台灵活性，支持位于应用软件集群中的软件组件基于信号和 SOME/IP 的通信--可独立于主机软件集群及其通信栈构建。
3.
重新设计与 PNC 相关的 ComM 和 NM，用专用 API 代替 ComM 和 Nm。
通过下层组件 MemAcc 和 Mem 扩展了现有内存堆栈，为多个上层模块提供内存访问协调，并提供与内存技术无关的内存驱动程序接口，从而支持空中下载（OTA）软件更新等新用例。
尽管取得了许多成就，但 AUTOSAR 在快速变化的汽车领域不断发展时也面临着一些挑战。一项重大挑战是在标准化和灵活性之间取得适当的平衡。虽然标准化促进了互操作性和兼容性，但它也会抑制创新并阻碍汽车制造商之间的差异化。另一个挑战是适应软件定义车辆日益复杂的情况，以及高级驾驶辅助和自动驾驶系统对人工智能（AI） 和机器学习（ML）算法的日益依赖。AUTOSAR 会不断发展以支持这些新兴技术，同时保持其模块化、可扩展性和可靠性的核心原则。
如上介绍的，汽车开放系统体系结构（AUTOSAR）是汽车工业遵循的标准，AUTOSAR 分层架构的其中一层是 MCAL（微控制器抽象层）。AUTOSAR 为属于 MCAL 层的设备驱动模块提供了非常详细的规范。通过提供 MCAL 层提供标准化的软件接口和配置，使中间件软件（BSW）和应用层独立于底层硬件平台。
英飞凌为 AURIX™ TC4x 系列微控制器提供了 MCAL 层实现，其符合 AUTOSAR 4.6.0 (R20-11) 的定义，内存驱动程序是符合 4.7.0 (R 21-11) 版本的。英飞凌还为没有 AUTOSAR 标准的外设模块提供复杂的驱动程序。
所有MCAL驱动模块的开发都符合 ISO-26262 Automotive SPICE 3.1 Level 3 和 ISO-21434 中定义的流程。所有源代码的开发都符合 MISRA C 编程语言和 SEI CERT-C (2016) 编码标准。
TC4x MCAL 驱动程序提供了完整的源代码，基于 Tresos 配置工具的配置支持，文档和演示软件，使用户能够快速入门。
TC4x MCAL 从四个方面进行了软件提升：
1.
功能安全：避免 ASIL D 实现的额外驱动程序；简化软件分区，提供更大的灵活性（ASIL D 域执行）; 简化系统级安全论证
2.
信息安全：支持强制性网络安全标准；英飞凌为报告的事件提供网络安全事件响应
3.
多核虚拟化：启用对虚拟 ECU 的支持；简化软件分区，提供更大的灵活性（多核操作）
4.
产品质量：支持最新标准: ASPICE ver3.1 level 3；避免需要密集的客户审核
| 
楼主
标题置顶
标题高亮
