|
首先，最重要的是：什么是AUTOSAR经典平台（ClassicAS）？ClassicAS是我们多年来所熟悉和喜爱的AUTOSAR的老版本。因此，ClassicAS是一个解决嵌入式发动机控制单元（ECU）的需求和要求的标准。很简单，对吗？然后，大家可能会问，"什么是自适应平台AUTOSAR（AdaptiveAS）？" AdaptiveAS以同样的方式，是汽车行业的软件标准。听起来很奇怪，对吗？这里有一个问题，AdaptiveAS解决了一系列新的需求，与通常的嵌入式ECU不同。 新的功能，如环境感知、自动驾驶、车辆连接和汽车即服务（CaaS），给电气/电子（E/E）全景带来了一系列新的问题。这些新功能与ClassicAS的设计不同。它们不再是简单地替代机电系统。由于缺乏更好的描述，它们是深度自主的，或智能的。因此，它们是高度复杂的，有很高的处理需求。此外，这些新功能预计将在车辆的生命周期内不断发展，与传统功能可能发生的不太明显的变化形成鲜明对比。高复杂度、高计算能力、更快的通信和持续的更新是这些新趋势所规定的要求。 以HPC为例，HPC意味着不是一个或两个，而是许多核心、处理器、GPU和其他处理单元的联合使用。已经在多核环境中挣扎的ClassicAS，无法为新的处理需求定义一个坚实的结构模型。同样，即使以太网提供的更高带宽已经被ClassicAS使用，这个架构也不能完全利用它的力量，因此它在汽车行业的真正潜力还有待发掘。此外，ClassicAS的静态性质使其在某些方面缺乏灵活性。例如，它的调度算法不允许它动态地将任务分配给核心，这意味着一个核心的使用率可能接近100%，而另一个则几乎没有使用。AdaptiveAS提供的动态性来拯救，并将解决方案扩展到多核架构。 AUTOSAR引入了分层架构，因此，自适应AUTOSAR也使用了一个定义明确的架构，尽管不仅有小的差异，而且有独特的特点，使其完全适合新时代的问题和要求。AdaptiveAS架构以关键原则为基础，如C++作为首选语言、面向服务的架构（SOA）、动态性和固有的并行性。 但到底什么是SOA呢？SOA可以被定义为一种模式，其中服务在网络上是可用的。这些服务可以驻留在同一个ECU上，也可以驻留在外部的另一个ECU上。此外，服务是独立的单元；客户（服务的用户）是独立于服务的。此外，服务和客户之间的耦合在运行时是动态的（与ClassicAS的编译时间相反）。应用程序可以消费服务（即成为客户），也可以向其他应用程序提供服务。换句话说，SOA是一个模型，在这个模型中，应用程序在网络上公开地将它们的实用程序作为服务呈现。在这个网络中，其他应用程序可以以动态的、因此是 "自适应的 "方式请求这些服务。 在顶层，我们可以找到新的自适应应用程序（AA）。与软件组件（SWC）相比，AA现在是一个进程，可以是单线程或多线程。它们的另一个重要功能是现在能够在任何时候启动或停止。尽管在ClassicAS中也可以使用分区来完成类似的方案，但关键的方面还是在于静态（ClassicAS）与动态（AdaptiveAS）的行为。AAs可以自行添加（下载），而添加一个新的分区则需要我们重新刷新整个软件。此外，AAs现在由一个熟悉但又全新的实体--AUTOSAR自适应应用运行时（ARA）--维系在一起。这个新的ARA是由来自下一层的构件的应用接口组成的，也就是功能群组。此外，这些功能集群可以是来自自适应平台基础或自适应平台服务。理解ARA的另一个关键方面是，与运行时环境（RTE）以及ClassicAS相比，在AdaptiveAS中，客户和服务在运行时是动态链接的。然而，AdaptiveAS也允许限制动态行为的选项，以减少不良影响的风险。例如，其中一些选项包括公平调度、仅在启动阶段进行动态内存分配，甚至是将进程固定分配给CPU核。换句话说，AdaptiveAS不会忘记它的目标用户，并提供有计划的动态。 自适应基础和自适应服务的软件是以功能集群的形式呈现的。简单地说，一个功能集群是一组按其所指的方面分组的要求。这些功能集群在某种程度上类似于经典平台的基本软件（BSW）的概念。它们的主要目的是以服务的形式为应用程序提供功能。然而，作为新的自适应平台的一部分，与BSW相比，新的功能集群现在是进程，可以是单线程和多线程的。另一个关键特征是动态性与BSW的传统静态性。就像在ClassicAS中一样，有非易失性存储、通信和诊断的需求，仅举几例，这些都是由非易失性存储器（NVM）、Com、诊断通信管理器（DCM）和诊断事件管理器（DEM）来处理的。这些需求在AdaptiveAS中通过功能集群得到满足，如持久性、通信管理和诊断管理。尽管目的相似，但它们在性质上有所不同。例如，持久性是基于键值和流存储的，而通信管理放弃了基于信号的方法，而采用了面向服务的策略。 AdaptiveAS给出的新术语 "状态机"，简单地说就是软件运行的实体。据了解，这个状态机可以是虚拟性质的。实际的硬件可以反过来承载一个或多个状态机。 像HPC和SOA这样的新资源也要求有新的先决条件。其中之一是一个能够满足其需求（动态环境，混合计算资源）的操作系统（OS）。因此，AUTOSAR操作系统和OSEK的静态性质并不适合这项工作。然而，这里的解决方案不是定义一个新的操作系统，而是定义一个操作系统接口（OSI）。该操作系统必须符合便携式操作系统接口（POSIX）。AAs被赋予了一个更受限制的接口--PSE51（一些功能包括：不使用文件系统，单进程）--而基金会和服务部门被允许使用完整的POSIX。有人会问："为什么选择PSE51？" 答案很简单：为了实现干扰上的自由，并为现有的POSIX应用程序提供可移植性。 但是，对于嵌入式系统中如此需要的实时组织，又该怎么办呢？毕竟，可预测性是最重要的。幸运的是，POSIX标准中提供了实时应用的调度策略，类似于AUTOSAR操作系统中基于优先级的调度，SCHED_FIFO、SCHED_RR和SCHED_DEADLINE是存在的，并且是允许的。 根据自适应应用程序和功能集群的架构定义，我们可以很容易地与软件组件和ClassicAS的基本软件进行类似的比较。下面要问的是，"它们是如何相互沟通的？" 在ClassicAS中，SWC之间的所有通信必须通过RTE。这是通过端口和连接器完成的。以类似的方式，SWC和BSW之间的交互也是通过RTE使用设置了服务标志的标准化接口完成的。然而，BSW之间的通信是使用普通的C语言调用。 我们可以使用经典平台开出的先例，以了解自适应平台将如何管理交互。在自适应平台中，自适应应用程序和功能集群都是作为进程实现的，尽管如前所述，自适应应用程序只能使用PSE51，作为一个更受限制的接口的一部分，它不提供进程间通信（IPC）。如果PSE51不包括IPC，那么应用程序之间如何进行交互？ 对于这个新问题，通信管理（CM）已经被定义。它为应用程序提供了类似SOA的通信--事实上是面向服务的通信（SOC），并且可以以透明的方式用于机器间和机器内的互动。这在某种程度上类似于一个SWC与同一ECU中的另一个SWC或与不同ECU中的SWC连接。 另一方面，功能集群不受PSE51的约束，可以使用IPC来相互作用。可能更需要注意的是，它们如何与AA互动。在这种情况下，有两种选择：一种是基于库（链接到AA的接口库调用IPC），另一种是基于服务（进程使用CM）。 尽管人们可能认为AdaptiveAS听起来是进化的下一步，或者说ClassicAS的日子已经不多了，但这仍然与事实相去甚远。目前E/E汽车系统的情况要求合作而不是竞争。现在，实际的下一步看起来像是AdaptiveAS和ClassicAS共同合作的混合体。同样，某些应用的严格实时性要求完全属于ClassicAS所涵盖的深度嵌入式ECU，而软实时性和高计算能力要求则属于AdaptiveAS的领域。理解这种耦合的一个有用的比喻是神经系统，它是由满足不同需求的各种神经回路组成的。例如，某些刺激会导致被称为反射的瞬间行动（可以说是 "低处理 "和 "快速反应"），而其他神经回路则形成了意识和认识（"高处理 "和 "慢反应"）。以同样的方式，一辆智能汽车可以有一个深度嵌入的ECU负责防抱死制动系统（ABS）--类似于反射，而另一个执行自动驾驶功能的ECU则命令启动刹车--类似于意识。 随着新的要求和新的资源进入汽车行业，自适应AUTOSAR应运而生。新的要求，如自动驾驶、车辆连接和持续更新，以及新的资源，如高性能计算和以太网通信，不能被现有的AUTOSAR标准完美地囊括，因此需要一个新的规则集来指导它们，在否则将是另一个混乱的场景中设置秩序。最初的AUTOSAR对于深度嵌入的ECU而言，自适应AUTOSAR对于新一代的车辆计算机而言，就是这样。 根据我们之前的陈述和解释，我们可以确定，适应性AUTOSAR和经典AUTOSAR的不同之处在于，它们各自针对一组不同的ECU，有不同的需求和资源分配给它们。 经典 AUTOSAR 和适应性 AUTOSAR 之间的差异： 1.经典 AUTOSAR 是指在单核或多核架构中运行。自适应 AUTOSAR 的目的是在 HPC 架构上运行，并利用 HPC 架构的优势。 2.经典 AUTOSAR 定义了一个操作系统。Adaptive AUTOSAR 只定义了一个执行环境和一个操作系统接口（POSIX，PSE51）。 3.经典 AUTOSAR 在信号层面进行定义。自适应 AUTOSAR 是以服务方式定义的。 4.经典 AUTOSAR 在本质上是静态的。自适应 AUTOSAR 在应用部署以及通信和资源方面提供 "计划动态"。 5.经典 AUTOSAR 是为深度嵌入的 ECU 准备的。自适应 AUTOSAR 是为新一代 ECU 准备的。 |
|
|
