AUTOSAR Adaptive与智能汽车E/E架构发展趋势

AUTOSAR Adaptive是一个面向现代汽车应用需求的标准，特别实用于那些需要高盘算本领和灵活性的应用。以下是AUTOSAR Adaptive的典范特性：

• 高盘算本领：AUTOSAR Adaptive支持使用MPU（微处理处罚器），这些处理处罚器的性能与PC或智能手机中的处理处罚器相当。这样的高盘算本领是实现半自动驾驶和其他复杂功能所必需的。
  
• 动态更新和管理：AUTOSAR Adaptive的架构允许更动态地处理处罚软件，这意味着可以更轻易地举行空中更新和安装新软件。这对确保车辆软件的最新状态和功能至关紧张。
  
• 模块化和灵活性：AUTOSAR Adaptive支持模块化计划，使得开发和更新变得更加灵活。各个模块可以独立开发和更新，而不需要对整个系统举行大规模的改动。
  
• POSIX兼容操作系统：AUTOSAR Adaptive通常运行在POSIX兼容的操作系统上，这种操作系统可以或许更好地管理资源并提供更强的硬件抽象。这样，开发人员就可以专注于应用功能而不是底层硬件。
  
• 服务导向架构：AUTOSAR Adaptive推动了服务导向架构（SOA）的使用，这种架构使各个ECU之间的依靠性更低。这样，如果需要更改或更新某个ECU，可以最大限度减少对其他系统部分的影响。
  

总的来说，AUTOSAR Adaptive为实现现代汽车的复杂功能提供了一个强大且灵活的平台，支持高性能ECU的使用，确保系统的可扩展性和动态管理本领。
自动驾驶辅助系统、OTA以及后续的附加软件安装将很快成为许多车辆的标准设置。试想一下，未来汽车作为一个新的智能化终端装备，就像当年iPhone为首的智能手机对传统手机的冲击一样，会对传统汽车造成多大的震撼？也许我们的汽车在公路上行驶，遇到了另外一位驾驶智能汽车的小姐姐，我们再也不需要向传统方式一样想尽办法让对方停车互加微信，而是直接通过车车互联，类似IOS17两个装备一靠近就可以传递数据，用自己的爱车加对方的爱车好友，从此建立了联系，然后王子和公主过上了幸福的生存（纯属娱乐哈）……然而，如果没有新的架构和高性能ECU，这些复杂的电子功能是无法实现的。那么，新的软件标准AUTOSAR Adaptive在此中饰演了什么脚色呢？
基于上述功能，车内软件的数量和复杂性持续快速增长。这一趋势并不新鲜。但目前，汽车行业的浩繁企业正在经历显著变革，以满足新的市场需求。这对汽车电子范畴尤为云云。因为新使命所需的盘算本领很高，微处理处罚器在电子控制单位（ECU）中被越来越多地使用，以补充之前在汽车范畴使用的MCU（微控制器）。这些微处理处罚器，往往与微控制器联合在一起，形成所谓的高性能ECU。这些ECU中的微处理处罚器与智能手机或PC中使用的非常相似，因此需要新的软件架构。这样一种架构的一个方面是POSIX兼容的操作系统，它们通常用于高效利用盘算资源。这些操作系统允许对执行的软件举行更动态的处理处罚，并比以前使用的实时操作系统更彻底地抽象硬件。为了将这些微处理处罚器无缝集成到现有的车辆网络中，运行在操作系统之上的中间件基于AUTOSAR Adaptive标准。
车辆的E/E架构也在发生变革。域和中央服务器架构将上述高性能盘算机集成到车辆中。在快速数据网络和强大处理处罚器的支持下，重点不再是高效的数据传输，而是更强的单个ECU解耦。更改单个ECU应对系统的其余部分影响尽大概小。一个典范的做法是引入面向服务的架构。
新的E/E架构与中央服务器

除了解耦各个组件，进步硬件和软件的复用性也是一个紧张目标。这意味着组件可以跨车辆乃至跨制造商使用。比年来的经典E/E架构无法满足这一需求。

图1a展示了一种ECU导向的架构。在这种架构中，一个功能由一个ECU实现，并配有一组相关的传感器和执行器，同时从车辆网络吸收额外的数据。车辆的通讯矩阵描述了这些ECU之间的须要通讯通道。然而，这种计划限定了复用性。传感器和执行器直接连接到功能性ECU上。如果其他总线参与者需要使用这些数值，则需要更改通讯矩阵。为了解决这个题目，就有了域控制器架构（见图1b）。

典范的域包罗“车身域”、“动力域”和“信息娱乐域”等。该架构的基本思路是每个域使用一个强大的控制器，连接大部分须要的传感器/执行器。在该域内，它还协调后续的ECU。这极大地进步了在域内扩展功能的灵活性，因为调整通常只会导致域内的局部变革。但前面提到的使用场景无法直接分配到某个域。高度自动化的驾驶功能需要来自所有域的信息，并且还会将数据反馈给它们。
这种方法的下一步发展是中央服务器架构（见图1c）。

各个域被组合到一个大型高性能盘算机或盘算机集群中。然而，这与域架构有更多的区别。比方，不能再将传感器/执行器直接连接到中央控制单位，因为目前的处理处罚器无法连接云云多的I/O外设。传感器/执行器现在被直接连接到网络，称为“智能传感器”和“智能执行器”，并执行机电使命。因此，它们变得与ECU和车辆无关，可以或许实现具有高重用潜力的模块化系统计划。然而，对低本钱传感器来说，这种方式的本钱收益比不抱负。为了使用这些传感器，它们可以直接连接到图1.c中蓝色表示的集成节点。这些节点ECU还有另一个紧张功能：它们充当传感器和执行器总线系统（如CAN、LIN、FlexRay和以太网)之间的网关。在这个网络中，以太网在朝中央盘算机方向代表紧张的总线系统。通过一个适当抽象的接口与传感器和执行器ECU举行连接，创建了一个模块化且功能可扩展的架构。
中央服务器的复杂架构

中央服务器或集成节点是复杂的ECU，它们通常由多个微控制器和微处理处罚器组成。这种异构布局提供了一些优势，因为控制器和处理处罚器在各自的属性上互为补充。一个例子是微控制器的启动时间较快。开机后，它可以敏捷投入运行，从而参与与其他ECU的通讯并执行其功能。此外，微控制器可以满足微秒范围内的最高定时要求，并且具有低抖动特性。如果实现的功能需要频仍中断，微控制器也是更好的选择。
微处理处罚器在其他范畴有其刚强。最紧张的固然是其性能。所使用的盘算核心提供了更高的时钟频率，并带有许多功能，如高多标度性或跳转预测，这些都能进步匀称性能。更大的缓存还能允许连接速度较慢但容量较大的外部存储装备。除了更多的资源容量外，微处理处罚器还提供更好的硬件假造化支持，使得使用假造机管理步伐（Hypervisor）技术变得更加轻易。
微控制器和微处理处罚器的异构装备在满足安全要求方面也有优势。根据ISO 26262，当前的处理处罚器可以达到最高ASIL B的完整性等级。通过使用冗余，即使是高度自动化驾驶所需的ASIL D等级也可以实现。在这种系统中，额外的微控制器执行两个使命：一方面，它执行监控功能；另一方面，在发生故障时，它还能提供降级功能，使系统可以或许在高可靠性下继承运行。这是对失效操作系统（即在发生故障时必须继承运行的系统）所要求的紧张特性（见图2）。
ECU配备多个可编程组件还有另一个方面：从外部看，它仍旧是一个单一的ECU。然而，内部有许多独立的软件组件实现ECU的功能。这带来了技术和集成方面的挑衅。从技术角度来看，这些组件必须可以或许相互通讯以提供共同的功能。ECU制造商的使命是使用处理处罚器间通讯（IPC）连接这些组件并描述交换的数据。这是ECU制造商的新使命，因为在之前的工作流程中没有这一步。以前只需要描述ECU之间的数据交换。然而，这一责任现在完全由整车制造商负担。同样实用于诊断功能、软件更新和系统的网络管理：过去由一方定义的简单ECU现在需要分布式和协调的实现。
从集成角度来看，集成各种软件组件是一个日益增长的挑衅。ECU的模块化计划和POSIX兼容的操作系统使得来自多个独立团队的软件集成变得更轻易。然而，这也使得ECU集成者的脚色变得越来越复杂。因此，支持ECU集成者的专业工具对于其复杂使命变得更加紧张。

AUTOSAR Adaptive作为中央ECU的平台

如前所述，在微处理处罚器上运行的软件组件通常不基于AUTOSAR Classic标准。相反，为了满足模块化、动态性和更新本领的要求，使用AUTOSAR Adaptive。这使得AUTOSAR Adaptive成为车载高性能盘算平台的究竟标准。AUTOSAR Adaptive中间件使用如Linux、PikeOS或QNX等POSIX兼容的操作系统，并为其补充了所有须要的汽车扩展功能。AUTOSAR Adaptive的紧张功能之一是通讯层ara::com。它不仅支持与其他AUTOSAR Adaptive应用步伐的通讯，还可以与车辆内的其他软件组件（SWC）举行通讯（见图3）。

诊断、安全和掩护功能补充了该平台的功能特性。这听起来很像AUTOSAR Classic基础软件，但两者在架构和技术上有许多差别之处。比方，ara::com是一种面向服务的中间件。这允许在运行时建立动态通讯路径。这种动态性是支持在运行时安装应用软件的条件条件。而传统的通讯矩阵需要调整才能将新内容发送到ECU。而采用面向服务的方法，信息可以通过订阅获取。
还有一些不那么明显的优势：硬件驱动步伐和高级软件被更严格地分开。这样，车辆中的硬件无关应用变得高度可移植。这比AUTOSAR Classic ECUs能实现更大的资源优化。比方，在开发阶段，如果资源限定超出预算，软件可以轻松地在差别的ECU之间移动，以避免更改硬件计划。另一个优势是，软件组件在差别车型中的复用性进步了。
在AUTOSAR Adaptive项目中，软件和硬件的分离还带来了整车制造商和供应商之间全新的工作分配方式。以前，功能总是以物理装备的情势出现在车辆中，现在可以完全以软件情势采购。为实现这一点，每个AUTOSAR Adaptive应用步伐现在都是一个独立的二进制文件。应用步伐开发因此独立于ECU开发。车辆的驾驶员可以通过应用商店安装额外的应用步伐，成为自己的集成者。
但如果系统在路上出现故障，谁来负责呢？车辆中大概安装了未经测试的应用组合。这种情况与AUTOSAR Classic ECUs中的典范集成方法相冲突，在后者中，每个设置都经过彻底测试。为了避免测试所有应用组合，必须保证应用之间的相互独立性。商用操作系统可以保证安全相关应用的内存限定不会被逾越。他们为此提供硬实时调理方法。这需要定义内存限定和应用步伐的最坏执行时间（WCET）。由于没有直接与硬件交互，由更改的中断负载引起的时间相关副作用不再显著。
固然，这种努力仅对安全相关的应用步伐是须要的。使用假造机管理步伐（Hypervisor）可以使差别动态性和安全等级的系统并行运行。质量管理（QM）应用可以位于系统中更动态和类似IT的分区中，这些分区可以使用开源软件。然而，在安全相关的分区中需要审慎，因为软件错误和安全漏洞不能以须要的速度消除。使用开源软件在产品责任方面也存在风险。
   文章参考来源：
  AUTOSAR Adaptive Platform
  AUTOSAR Adaptive | Vector

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。