用于自动驾驶的中间和SOA软件结构(三)

四. SSA对一个或三个申请区的贡献

目前,SOA在车辆软件方面的建筑应用也刚刚开始。 将SOA应用于汽车的几家公司也在试图取得进展。 在这一过程中,有三个关键需求有助于SOA的发展:

转换为SOA的传统汽车电子建筑;

车载娱乐系统(IVI、Vekhique In-Vekhique In一体化)需要结合汽车连通性,扩大SOA应用一体化的范围。

自动驱动的软件结构对于SOA组织来说也是理想的。

这三个方向的一些要求是常见的,而另一些要求则完全属于其特定领域,每个领域都有典型的中间产品。

图4. SOA对一个或三个应用区的贡献

适应性AutoSAR包括汽车部门的更多软件能力、更好的标准系统、对SOA核心通信协议COS/IP的说明,以及更多地注意功能和信息安全,但费用更高。

GENNIVI在车载娱乐和汽车网络领域提供了一批开放源技术仓库,从IDL规格到可能与适应性相容的OCI/IP协议通信支持,达到了一个完整的程序,从IDL规格到OCI/IP协议通信支持,但目前,产品化水平极低。

ROS是开放源码机器人场的中间地带,自动驾驶系统使用汽车作为大型机器人来利用许多机器人场的成熟经验。 因此,ROS常常被用来开发自动驾驶原型系统。 但是,ROS太复杂了,机器人应用毕竟是低速场景,自动驾驶的高速场景,需要很大的改进。 因此,有些中间产品在ROS的基础上得到改进,预计将用于数量生产。 基于ROS的产品进化也有一些SOA风格的特征,但与适应性自动SAR直接互操作,需要开发定制的应用层网关。

四.2 中间自动驾驶要求

4.2.1 SOA建筑设计与自动驾驶系统的适用性

SOA结构风格也是自动驾驶系统的极好选择。

自动驾驶系统包括“许多传感器的遥感和集成、为复杂和可变情况作出规划决定、控制高实时需要的执行”,涉及各种计算方法的标志性数目,需要分别演化,可分为不同的服务分系统,包括“许多传感器的遥感和集成、复杂和可变情况的规划性决定、高实时需要的控制性执行”,涉及各种计算方法的标志性数目,需要分别演化,可分为不同的服务分系统。

“出版物/订阅”形式的通信可有助于减少各服务部门之间的通信互补性。

这两个点与两个SOA结构限制,即“客户-服务”风格和“以事件为基础的订阅”风格相关。 这两种风格解决的基本问题是如何将大系统分解成各种软件组件,并以低相联的方式将其整合。 从这一观点看,有许多方法可以做到这一点。 例如,整个系统在DDS的基础上整合,每个服务都被拆除。

软件结构充分满足了上述两个组成部分,足以支持自主驱动系统的原型产品。 但是,作为一个批量生产产品,需要额外的考虑。 SOA风格的其他特征可以提供更大的支持。

例如,服务发现机制有助于验证必须依赖的其他服务的准备就绪情况,服务代理协助与车辆中的其他系统进行互动,服务组装允许灵活部署自动驾驶软件模块,并提供优化通信的备选办法,服务监督确保整个系统的可靠性和可用性发现机制,例如,帮助验证必须依赖的其他服务的准备情况,服务代理协助与车辆中的其他系统进行互动,服务组装允许灵活部署自动驾驶软件模块,并提供优化通信的可能性,服务监督确保整个系统的可靠性和可用性,服务监督确保整个系统的可靠性和可用性。

四、二.2.2 自动驾驶软件规格说明

然而,与其他软件系统相比,自动化驱动系统所需的软件结构仍有许多独特的需要。 其中一些要求不属于SOA设计风格的一部分,但可在SOA结构中处理;某些非结构化的问题,如具体算法的有效性,必须独立处理。

传感器数据访问需要高带宽。

自动驾驶系统需要大量传感器数据流,其中最常见的是相机图像数据和激光雷达点云数据。

相机技术已在自动驾驶系统中广泛使用,例如,一台800万像素照相机与GPSL2相连接,可拍摄约30个摄像框架,数据容量已经超过6Gbps。

根据SOA结构,我们希望将图像数据采集作为一种服务,将图像数据“公布”而许多数据处理服务是数据收集和使用“订阅”的。 数据处理服务可能很多,从铺设车道线和车辆识别算法到存储影像成像序列。

然而,数据传输所需的带宽不再可用千兆字节,数据传输必须通过共享内存加速。 如果这些连接服务在同一芯片上的单一操作系统上运行,共享内存仍然很容易;如果各种操作系统(例如,如果许多SoC总芯片被置于多氯联苯电路板上,则还必须提供基于PCIe的跨芯片在OS之间的存储共享,否则,只有SOC芯片可以局限于处理与之相关的相机数据。

也就是说,我们希望利用SOA提供的结构特征,同时在SOA结构范围内处理与传感器有关的高带宽数据传输要求。

至少有几种替代办法:

SOA的通信协议使用DDS, 某些DDS的实现已经嵌入了共享的内存通信,这些内存通信越来越常见。 很难创建带有数据序列操作的零副本。 其优点是它已经成熟。

基于共享记忆的虚拟网络卡适合基于PCIe的跨 SoC通讯。 数据序列操作零副本难以执行。

与服务组装一起,不同的优化技术在透明程序内、流程之间和东道方之间自动修改。

自动驾驶系统在运行过程中,可被视为“遥感一体化规划和控制实施”的连续流。 它涉及许多种类的算法,必须加以跟踪和互动。

具体算法在可行的情况下尽快实施,从而导致整个流动线整体的拖延时间最短。

算法实施时间的波动率保持在最低水平,减缓目前整个线路的波动率稳定下来。

总体延迟时间越短,车辆干预越频繁,对高速自动驾驶的支持越多;总体延迟时间越稳定,所控制的产出就越稳定,车辆驱动器就越稳定,对危机的反应也就越迅速。

整个延迟时间由执行每种算法所需的时间、传输数据所需的时间以及显示算法所需的时间来界定,所有这些都需要有重点的优化。 然而,对总体延迟稳定性的影响主要是由算法运动驱动的。

当自动驾驶函数ECU只在固定环境下执行少数功能时(例如任务时间安排的相关性在L1/L2中并不明显),因为启动/停止的算法的生命周期是静态的。一旦产品制造出来,它不会改变。但是,在域控制器时代,高算数自动驾驶域控制器在不同情况下具有不同的特点,在传感器和算法方面也存在一些差异。 通过OTA更新新功能和场景支持也是可行的。

任务分配的一个极端技术是将其完全留给操作系统。每种算法服务都作为一个独特的过程存在,操作系统分配过程的执行时间。开发者可能影响任务时间安排的方式只是为每个过程确定优先次序。这就是大多数自动试运行原型系统是如何产生的。

“操作系统过程”中的排程器粒子太大,无法适当计算算法活动的时间。

SOA结构风格可能导致更多的服务,当操作系统有太多的流程时,流程到流程系统成本消耗了系统太多的时间。

优化方案可以使用“服务组装”方法将许多SOA服务合并成同一个服务包装程序,为每项服务指定一个“操作系统线 ” 。 这使得上述两个问题有所改进,因为时间表的粒子大小缩小到线性水平,在同一过程中线条切换的成本低于程序切换的成本。

以流程为基础的调度和以行为基础的调度都依靠操作系统自己的共同分配机制,每个流程或线到线过渡都需要完成操作系统中的核状态,之后,CPU将转换为用户-状态执行的用户代码。 CPU核执行时间(在上下文中切换)如果存在过多的流程或线条,在严重情况下达到或超过30%,可能会急剧增加。

进一步优化并不取决于操作系统的同时开发机制,而是取决于使用几条线索作为执行机制。 每种算法处理行动都密封在一项由用户调度机制组织的任务中。

例如,就OCH/IP而言,对方法呼叫的每一个答复都作为所收到的每个事件响应的一项任务处理。 任务转移机制被放在适当的线索中。 这些任务有各种名称,有些称为用户-状态线,有些称为用户-状态线,有些称为有名信息,有些称为协调或光纤。 这项工作的转换完全在用户-状态进行,对系统的成本较低。

支持异构体平台的软件和硬件

用于自动驾驶域控制器的 SoC芯片往往高度一体化,除了多核CPU之外,还被纳入DSP、NPU、FPGA或其他专门的计算机加速装置,有时还纳入CMU芯片,这是一种硬件异构体。

随着虚拟化,多核CPU可以在不同的虚拟机器上运行多个操作系统,例如,运行Linux,以充分利用Linux社区的成熟软件生态,运行QNX或VxWorks,以实现更高级的实时。SOC中包含的MCU模块还将运行RTOS系统。DSP和NPU还将使用针对具体平台的接入方法。

最好是保护软件和硬件异构体平台不受使用自动SOA中间体的服务的影响,一方面,异构体平台可在SOA中互动,另一方面,通用功能逻辑可以移植到不同的硬件平台。

例如,DSP或NPU的使用情况包含在一个特定的平台图书馆中,它自称为标准SOA服务,一些/IP和外部通信也用于MCU RTOS系统,在该系统中,对RTOS执行的任务也是SOA的外部服务。

自动驾驶开发阶段的援助

在自动驾驶系统的开发测试阶段,也需要中间系统的支持。 首先是数据记录、回放和可视化。 这在自动驾驶系统的开发中特别重要。 由于不可能在每一次软件服务开发中都使用实况车辆环境,因此,不可能在每次软件服务开发中都使用现场车辆环境。 SOA服务与外部数据的互动可以很容易地记录下来,软件是利用已记录的数据进行回放开发的,与服务组件进行模拟可以大大便利于开发。 数据可视化还便于对数据进行直观理解,便于理解软件实施的结果并检查错误。 ROS提供了用于记录和重播的Robag工具以及用于数据可视化的RViz工具。 这是广泛使用ROS的原因之一。

自动模拟系统是自动试点功能测试的基本工具,可以大大减少开发和测试费用。 中间方对模拟系统的支持通常不反映在模拟的基本结构中,而是与模拟系统的各种接口相匹配。

我们往往在不同的发展环境中使用不同的发展语言。 MCU的开发基于 C 语言, Linux/ QNX 环境可以很好地支持 C++ 语言, 测试者喜欢 Python, Linux 和 MCU 终端都可以使用 Rust 作为系统编程语言, 以加强进程内存安全 。

四.3 创建自动驾驶SOA的中间体。

已经研究了SOA中间体和自动驾驶系统之间相辅相成的联系,SOA中间体应力求优化自动驾驶功能,一方面为自动驾驶系统创建一个强大的平台,另一方面为特定领域的深层应用创建一个平台,另一方面改善SOA中间体的迭代开发。

适应性汽车SAR(以下简称AP)标准正在迅速发展,是SOA的中层标准,正在稳步逐步成熟。 然而,尽管标准的APA文件可以公开提供,但几乎所有APA制造商的产品都非常昂贵,而且大多数开发商仍然有相当的学习和使用门槛。 GENIVI提供开放源SOA技术商店,可以与AP平台连接,但也可以用来设计软的SOA。

这一章将针对这两个技术路线做一些对比和技术展望，提出构建适中间的自动驾驶 SOA思路。

四.三.1 技术和产品说明

POSIX标准简述

首先,迅速讨论POSIX标准,特别是嵌入的POSIX标准,由于机载的中间SOA及其应用,必须有一个明确的操作系统操作环境标准,以确定其可能工作的环境。

POSIX是便携式操作系统接口(UNIX的移动操作系统接口,缩写为POSIX),POSIX标准界定了操作系统应为程序提供的接口标准。 POSIX是一个标准组合,有一套标准和每隔几年略作修改。

最基本的要求是POSIX.1,又称IEE 1003.1, 被接受为ISO/IEC 9945, 2017年版本[28],长度约为4,00页,界定了四个关键领域,即“基本定义、系统接口、壳牌和实际流程、原理”。 Linux 和 QNX Neutrino 符合这一标准。

该标准为实时应用程序和嵌入应用程序提供了四种替代基本配置,PSE51是最小和最受约束的系统。 PSE52、PSE53和PSE54逐步减少限制,允许增加能力。

下文概述了各种安排的职能范围。

图4.2 内嵌POSIX标准设置比较

我们利用《亚太行动计划》平台象征一种《亚太行动计划》中间产品,该中间产品根据《亚太行动计划》的标准实施,通常包括实施《亚太行动计划》的基础和平台服务功能,并作为一种独特的中间产品存在。

应当强调的是,APP应用软件仅限于PSE51 API, 但APP平台可以使用非PSE51 API, 甚至操作系统专用API, 特定API的使用将由APP平台实施者选择,而不是标准化 [30]8. 一. 应当强调,APP应用软件仅限于PSE51 API, 但APP平台可以使用非PSE51 API, 甚至操作系统专用API。

APP程序无法调用网络或访问文档系统, 因为它仅限于 PSE51API 。 APP 平台随后提供“ 通信管理” 能力和“ 可持续性” 模块以满足这两个需求。 但是, 为了提供这两个能力, API 被用于克服 PSE51 限制 。

如果我们想要建立一个SOA中间平台,下表将概述该领域每个POSIX配置的能力。

可以看到, PSE 51 本身是不够的。 “ PSE 52+Web 通讯” 已经有能力提供 SOA 中间平台。 这些平台是典型的 RTO 平台, 如 VxWorks 。 这些平台缺乏 MMU 支持, 不允许多个处理器, 而整个系统是一个过程, 可以在一段时间内完成各种线索或任务 。

很难找到一个只支持PSE53/54的操作系统, 一般来说,POSIX是直接支持POSIX的。

PSE52是一个分水岭点,在这个点上,基于PSE52的中间SOA平台可用于大多数RTOS系统,如VxWorks、RT-Tread等。其他几个RTOS也拥有自己的POSIX兼容层,可作为SOA中间体的操作平台。SOA应用在这些平台上使用的OSS平台的API应仅限于PSE51。

多数AP平台目前都是在Linux和QNX的基础上开发的;GENNIVI技术仓库只支持Linux,移植到QNX并不难。 可用于SOA应用的API范围越窄,便捷性就越大,尽管对与传感器功率有关的特定服务和算法来说,使用针对平台的API是不可避免的。

适应性汽车SAR的简短解释

本文件的目的不是全面介绍《亚太行动计划》,而是从《奥氏体》结构的角度对《亚太行动计划》进行简单分析,关于更详尽的资料,请参考其他来源。

根据亚太行动计划标准文件,亚太行动计划职能分为许多职能组,以下图像描绘了各职能组(以箭头标出)之间的主要依附联系。

多数其他功能类通常由静态图书馆提供,在静态图书馆中,AP应用程序可实现某些SOA服务功能和与这些静态图书馆的联系。 “升级和配置管理”、“网络管理”和“国家管理”通常作为AP平台产品中独立的SOA服务而存在。

如果在POSIX.1中,一个兼容的OS平台,它是否属于AP平台本身的服务和用户开发的服务,如果在一个兼容的OS平台中,它是否是一个独立进程;如果在PSE52兼容的OS平台中,它是否属于系统唯一一个进程的任务。

“执行管理”职能组负责“服务组装”和“服务包装”,而“通信管理”负责服务间通信,需要按AP标准支持某些协议/IP协议,一些AP平台已经为ODS和共享记忆获得了支持。

“国家管理”和“健康管理”这两个职能分组是“服务监督”。

图4. 图3 依赖适应性自动搜索和救援功能

服务通信界面、服务组装和执行管理技术在XML格式的《宣言》文件[14]中界定。

GENNIVI 技术储存库概览

GENNIVI是开放源码的SOA技术平台的基础,该平台的实施和应用在与POSIX.1兼容的操作系统(主要是Linux;其他操作系统必须转让,这并不困难)上运作。

图4. GENNIVI技术仓库各种软件模块的附属图见图4。

蓝色部分 它是一个公共组成部分,不与任何单一的通信渠道挂钩,由三个单元组成:

定义:Franca以及Franca的语义工具。

根据Franca,这一工具生成通信代码。

API 通用运行时间是一个没有连接的通信频道运行时间图书馆。

所有三个单元都是开放源码,随时可以使用。

绿色部分 与某些通信渠道相关联,例如:

具体通信渠道具有约束力是受管制的。

为某些通信线路生成代码的工具

某些通信渠道的运行时间图书馆

COIS/IP和D-Bus的通信渠道得到GENNIVI的支持。

橙色部分 用户必须做些什么才能为各种SOA应用做好准备,例如:

根据弗朗卡标准,界定特定SOA应用的界面。

特定SOA采用对通信渠道有约束力的定义,并受该渠道具有约束力的标准的约束。

一个独特的 SOA 应用程序的函数代码 。

图4. 图4 依赖GENNIVI技术储存库软件模块

灰色部分 是工具生成的代码。

可以看出,使用者建造的SOA应用代码并不直接使用通信频道的具体功能(绿色部分),因此,用户代码不是针对某一特定通信频道而写的,而是在运行时与某一特定通信频道连接。

如图4图5:30所示,这一技术设计与适应性汽车搜索救援系统的“通信管理”有关。

图4. GENNIVI 5 AP Ara:com

图4描绘了法语界面要求、AP界面定义和某些/IP规格的图示。

图4.6 亚太行动计划、弗朗卡地图和一些/IP地图

可以满足所有接口要求,使GEONNIVI技术仓库能够根据COS/IP与适应性自动合成孔径雷达进行通信。

GENIVI全套技术栈都是开源的，架构上提供了较好的扩充能力。可以自行对接口定义语言、代码生成工具、Runtime库进行扩展改进，也可以添加新的通讯通道绑定。可以作为一个SOA中间件的架构基础，并与Adaptive AutoSAR互操作。下文会以此为基础讨论进一步改进优化方案，为实现适中间的自动驾驶 SOA提供思路。

四、三.2 连接的动态多通信频道

AP和GENNIVI都提供Ethernet Some/IP电信装订能力,使以RPC为基础和以事件为基础的订阅成为完成SOA服务通讯的基础,还需要扩大GENNIVI技术商店通过共同记忆捆绑的能力。

图4. 图7. SOA服务部署实例

如前所述,共享记忆处理不同流程之间的高效沟通,可以将若干SOA服务纳入同一服务集装箱流程,在同一个流程中,有多种服务,其互动可以直接通过API进行。

图4说明了这一点:图7描述了通过以太网连接的两个单独的操作系统,每个操作系统运行一个或一个以上“服务包装流程”,每个集装箱流程运行一个或一个以上SOA服务。

提供了以下服务:

• 服务1和服务2都是同一服务集装箱程序A的一部分。

• 第3项服务部署在集装箱流程B中,该流程由在同一操作系统中运行的两个流程组成。

• 第4和第5号服务正在操作另一个OS服务集装箱过程中运行。

服务1和服务2都是同一服务集装箱程序A的一部分。

第3项服务部署在集装箱流程B中,该流程由在同一操作系统中运行的两个流程组成。

第4和第5号服务正在操作另一个OS服务集装箱过程中运行。

Alpha事件是由服务1引发的,服务2/3/4订阅该事件,使用自己的控件_功能处理。然而,该事件的接收方式不同:

• 集装箱处理 A 即时呼叫 Handle_通过 API 服务 2。

• Service 3 从共享记忆中获取该活动的集装箱处理程序。

• 收到和处理的网上活动(SOME/IP)

集装箱处理 A 即时呼叫 Handle_通过 API 服务 2。

Service 3 从共享记忆中获取该活动的集装箱处理程序。

收到和处理的网上活动(SOME/IP)

在这个例子中,服务1造成的事件以三种方式到达接收者,下表比较了这三种途径,假定数据数量为100字节(表明数据数量不是延误的主要来源)。

进程内API绑定

可以看到,当优化 CPU 缓存时, API 会以最快的速度运行。 不需要数据复制或排序。 对于 C++, 程序语言只是为自动恢复数据内存所必需, 数据内存是具有参考号的智力安全的线条。 这意味着, 单独开发的两个 SOA 服务, 如果装入同一服务集装箱程序, 则直接通过 API 传输, 用于服务 id 。

原则上,服务集装箱应在程序内直接提供对API具有约束力的能力,在IDL编码的帮助下,服务集装箱应自动识别各种服务在这一程序中的相互作用,并将一项服务的请求或活动与其他相应的服务或活动自动联系起来。

程序内约束的API不应同步进行,即该方法的“所谓的”与“答复者”之间、“发货方”与事件“答复方”之间,而不是需要分步骤执行或分行执行的同步API呼叫。

多通道绑定能力

服务1活动在前一个例子中以三种方式传达。但是,服务1不需要知道真实事件信息是如何传输的。服务1的用户代码只是使用IDL生成的骨骼代码,由中间人Runtume图书馆和服务集装箱共同选择适当的通信方法。

这就需要运行时图书馆和中间物品服务集装箱具有动态的多通道装订能力,目前,AP平台产品和GENNIVI的默认实现使单个走廊能够约束,有必要进一步扩展。

此外,服务集装箱最有能力识别和记录服务订阅服务1点,从而可以确定是否根据用户向某些渠道传输数据,例如,如果上图中的服务4取消了活动订阅,数据将不提供给以太网。

进一步的优化

在前一例子中,服务集装箱C服务需要接收和处理泰网上空的数据,通过以太网接收数据必然需要反顺序进程,服务4和5每次要求相同的反顺序,进一步优化后,服务集装箱可以与中间集装箱匹配,运行时间可以进行反顺序活动,然后通过API将获得的事件数据传送到服务4和服务5。

----

为了实现上述优化,必须扩大与APP的中间点实施管理,将《宣言》产生的代码与实施管理相结合纳入其中,为了实现GENNIVI,其API共同运行时间和COMon API代码生成工具必须加以改进,以提供动态多字符串、直接约束API和增加共享记忆约束(可以在冰激凌的基础上实现)。

为使服务更加单一,我们尽可能将更多的基本、未命名的服务区分开来。 然而,过多的服务通信影响业绩。 上述所有优化都旨在限制服务分类对业绩的影响。 在开发阶段,我们关心服务功能,但在部署阶段,“接近”部署通信密集型服务,这自动a。

四、三.3 规定效率和现成业务任务

任务时间安排和天体活动在过渡期间相当重要。

在下图中,IDL描述一个附加操作,代码生成工具为客户生成代理代码,为服务端生成管道代码。

通用代码生成工具为客户代理代码创建同步和非同步方法。 在例 Plus 中, 同步方法在获取结果之前不会返回, 步骤方法+ Async 提供回声函数 _ 回召, 附加Async 方法在被调用后会尽快返回, 计算结果将达到贫血结果, 用户的回召方法将启动以提取计算结果 。

用户代码提供这项服务的方式是,从服务的根代码中继承基型 MathStub, 并给予适当的不实现功能。 用户在此示例中添加的功能由 Runtime 在中间调用 。 此示例显示了 RPC 模式“ 请求/ 响应” 下的行为, 如果服务器订阅事件, 处理事件的方法是相同的, 与接收 r3 2 的服务提供商相同。 3, 射击和忘记, 或只有一种方式 。

图4. 同步/压力使用守则实例

同步机制分析/气候同步化

对于客户来说,表面同步的API/同步的API“Appearance”和深度同步的 IO/同步的 IO O“Assyncious IO”“Assync ” 。 这是上个例子中+/+Async 的例子, 其区别在于同时的API呼吁等待结果到来, 然后返回, 而无症状的API 立即返回, 当它到达时触发回声功能 。

中间运行时间的实现决定了实际的IO机制是同步的还是偏离轨道的。 现代通信的中间通常使用无症状的 IO。 换句话说,即使API同步化,最底层的物理通信机制可能是引入对抗性 IO。 只要在中间运行时间挂断并醒来以同步API电话。

也就是说, 标准“ 请求/ 回应” RPC 电话, 至少有两个客户工作需要中间运行时间才能执行。 一个是不对称的数据发送任务,另一个是获取返回结果后对已注册的回回函数的回响 。

中心用户代码的运行时间呼叫

如前所述,在Runtime中间至少有三种情况需要使用用户代码:

• 一旦服务中级运行时间收到RPC的要求,请拨用户代码处理。

• 当 Runtime 在服务中收到订阅者活动时, 拨打用户代码 。

• 客户中级运行时间接收 RPC 回复并返回用户注册回调功能。

一旦服务中级运行时间收到RPC的要求,请拨用户代码处理。

当 Runtime 在服务中收到订阅者活动时, 拨打用户代码 。

客户中级运行时间接收 RPC 回复并返回用户注册回调功能。

中间运行时间在执行任务方面还有两个困难:“中间运行时间的线型”和“中间运行时间的指定”。

中心线的线性模型Name

方便用户的中间系统(中间系统的用户)应保护用户不受复杂的线条管理的影响,而用户只需给中间(运行时间)调用的方法功能即可。

中间线性模型的设计对用户准备这些模型的容易程度有相当大的影响。 中间本身往往基于使用不对称 I/O(典型反应器模式)进行底部通信(网络/共享内存),以及建立一个线性集合,使新的任务从线性集合中自由执行线性执行。 因此,所有相互竞争的资源问题都由用户程序解决,任务时间安排取决于系统的同步。

另一个组织者(_A)

如前所述,与其说取决于操作系统的线性时间表,倒不如说应该有一个更复杂的自动驾驶中间器任务时间安排机制。 一方面,过多的线条占用了更多的内存(每个线条都有独特的存储空间,而Linux通常有8MB以上的默认设置 ), 另一方面,线条切换系统的成本昂贵,而线线的用户则无法管理。

这种办法是维护许多任务队列的独立性,为任务的执行和实施逐个获取少量线索。

用户启动的组装任务

拨打中间线 Runtime 的用户代码

前者通常在自动试运行软件系统中启动不对称的IO活动,而后者则是中间运行时间行为的特点。 这种用户状态任务的同时设计因独特的实现方法而不同,例如“协作”[32]和“操作模型”[31]。

这种办法特别有利于共同处理计算工作和I/O任务,以及自动驾驶软件的附加好处,因为自动驾驶软件可以在CPU用户国精确安排任务。

完成目标所需的时间

同样的工作将再次执行。

在计算I/O的影响时,同一类型任务的执行时间相当一致。

例如,视觉目标测试技术需要一秒钟才能处理50个框架。 这种算法的应用有时间限制,在激活后会重复,没有特定的意外情况(主要在I/O上),而且实际执行在狭窄的范围内波动(执行期间的统计差幅很小)。

为了获得这种发送帮助,中间用户还必须告知中间副本Runtime他所需要的时间安排要求,我们将继续在下一节“IDL的定义扩展”中详细介绍。 中间的API更适合处理这种调度机制,即使涉及程序语言特征,如下文“程序语言支持”一节所述。

----

执行与本节有关的职能所需的中间过程与适应性汽车SAR中的“执行管理”功能组相对应;对于GENNIVI来说,它与共同API核心相对应。 以IDL为基础的代码也必须与运行时的API协调。

四、三.4 改进方案支助

COIS/IP协议没有具体规定与QOS有关的支持。 与QOS有关的产品是目前对QOS支持最开发的产品。 QOS协议也被RTPS(实时公共订阅)协议描述为DDS的互操作性标准。 [34]8.7 。

因此,为了获得QOS支持,大多数中间产品目前使用DDS直接约束DDS作为底线通信方式,适应性AutoSAR的“通信管理”是使用有约束力的DDS来提供QS能力[35]7.7.3.3.,并描述ARXML 中的QS标准,具体说明服务配置。 [14]10.1.2 COIS/IP-SD协议包括了QOS特性的定义,在利用DDS作为通信渠道时,这些特性也用于服务交换。

就GENNIVI而言,通过提供装订DDS,可改善QOS支持,但这一技术不允许使用COIS/IP进行QOS通信,为OCIS/IP的浅度和深度通讯提供QOS。

利特支持只是中间运行时间,在不改变OCH/IP协议的情况下单方面对QOS提供有限的支持。 例如,应提供RPC请求中限定的重试次数,但这只适用于 " 单一 " 等请求。 在RPC请求中增加一个截止时间也是可行的,但不能假定服务结束会得到支持,而且只有在当地期限过后才会提出虚假建议。

需要为SOA服务提供大力支持的双方(RPC申请者和响应者、事件生产者和消费者)都可以处理QOS信息,然而,关于这些行动的协议本身并不是OCI/IP协议本身的一部分,如果SOA系统中的客户和服务使用中间产品,而SOA系统中的中间产品是同一制造商制造的产品,则可获得类似于DDS的QOS能力。

IDL 定义扩展能力为4. 3.5.5

IDDL必须具备的基本特征是服务接口API的描述,包括数据类型、RPC方法、订阅活动等等。 2 如前第2节所解释的。

同样,本节前面各节也提出了在IDL中可以扩大的一些特点。

• 通过接口()达到线索示范标准。

• 接口满足任务时间表的要求 ()

• 对 QoS 的需求

通过接口()达到线索示范标准。

接口满足任务时间表的要求 ()

对 QoS 的需求

图4. 在图8的例子中,我们可以提供IDL中描述的附加方法,从同一个客户中指定一个在同一线线上执行的方法,要求完成时间不超过20毫秒,只有在由于通信频道故障而无法自动这样做5次的情况下,才报告错误。代码生成工具可以根据这一信息生成等效代码,中间运行时间可以利用这一信息构建相似于8的对应代码,我们也可以提供IDL中描述的附加方法,从同一个客户中指定一个方法,要求完成时间不超过20毫秒,只有由于通信频道故障无法自动完成5次才报告错误。代码生成工具可以根据这一信息生成等效代码,中间运行时间可以利用这一信息构建相应的代码。

适应性自动合成孔径雷达接口规格以 ARXML 格式发布。 其IDL 类似于自定义的 XML 标准, 指定了一套有效的 XML 标记和语言 。 [14] 将 ARXML 防患于未然是XML 的一种方言,用户更难直接阅读。 因此,适应性自动SAR制造商必须提供可视化工具供用户使用。 如果要扩大 ARXML, 可以添加自定义标记, 并检测和处理相关的可视化工具 。

弗朗卡与一般程序语言相似,可以理解,在相关汇编者进行分析之前,可由用户直接制作。 [11]3.5 。

四.3.6 提高服务集装箱服务管理能力

服务集装箱的主要目标是实现3.3.3.6“服务组装”方法,为SOA服务提供部署和管理服务的自由(此处的集装箱与Docker集装箱没有联系)。 同时,如果你想实现4.3.3。 科内所述SOA服务之间的通信在过程中直接通过API调用,也必须得到服务集装箱的支持。 9 两项服务与负责内部API对接和美学处理的同一中间批次共享,在不同的SOA服务的服务集装箱程序中也可能有许多中间体,尽管“API-in-process”服务之间的通信难以实施。

图4. 9服务容器

除了服务装配的基本能力之外,我们还可以利用服务集装箱完成更方便的工作。

监测和说明所有负责服务的民间社会组织对请求和事件处理行为的答复情况也是可行的,这可以提供清晰的信息,如请求/答复或处理事件的平均时间等信息,此外,这些统计能力并不要求每个民间社会组织服务机构作出特别努力。

服务集装箱可能也会被藏匿起来,对服务中发现的信息作出反应,服务集装箱程序已经开始,即使没有装载任何服务,它也可以接收网络上其他服务机构的广播信息(OCH/IP Service Discovery Protocol),在服务装上时,服务集装箱可以更快地生成这种信息。

例如,一个SOA服务机构就一个其QOS每秒只收到10次通知,但在网络上每秒发送30次。 在这种情况下,服务集装箱可以减少调用管理SOA服务的次数。 反过来,一个SOA服务机构通过分析服务发现中的QOS信息,就一个特定主题每秒提供30次活动,其中服务集装箱通过分析服务发现中的QOS信息,发现外部服务预计该活动的最大框架比率只有10个框架,这减少了外部发送的数量。 服务集装箱对管理SOA服务的干预是透明的,服务集装箱中的管理SOA服务是透明的,服务集装箱中的管理SOA服务是透明的。

服务集装箱也可以同时装上两种相同的服务,一种是起作用的,一种是备份的,但只能从外部找到一个联系点,如果工作失灵,服务集装箱立即将要求转至备用服务处处理。

四.三.7 改进服务发现

OCH/IP服务发现协议是一个分散协议。 一旦存在SOA服务,它会播放“提供服务”信息,并通知网络中的其他服务。 如果服务需要其他服务的信息,可以自己发布“发现服务”信息,等待办公室服务的答复。 问方只有兴趣获得“提供服务”的结果,而不管谁发送了“提供服务”协议是一个分散协议。 如果存在SOA服务,它会播放“提供服务”信息,并通知网络中的其他服务。 如果服务需要其他服务的信息,可以自己发布“发现服务”信息,等待办公室服务的答复。 问方只有兴趣获得“提供服务”的结果,不关心谁发送了“提供服务”的结果。

上一节涉及可能储存在服务集装箱中的结果信息,以便在服务装满时能够更快地回答查询查询;同时,服务集装箱如果出乎意料地退出,服务未及时交付,则可以取代管理下的服务(停止服务)。

此外,一些/IP的服务迪斯科特协议已经下放,但我们也可以设计一个具体的“服务发现支持服务 服务 ”, 负责根据报告缓存网络中不同服务接入点信息提高服务发现的效率和可靠性。 当车载以太网(Ethernet)被分解成多个网络部分,甚至与车辆侧面发生互动时,这将非常有益。

四.3.8 增加RTOS系统支助

开发完善的自我驱动SOA中间体应具备RTOS支持能力,中级运行时间本身可以运行POSIX PSE52型RTOS系统这一事实提供了深入的支持,当时,整个RTOS系统作为一个过程存在,本身就是一个服务集装箱。

RTOS的地表下支持能力只是需要支持某些/IP协议和某些/IP服务发现协议。 可能使在RTOS上的操作看起来是一种SOA服务。

在领先的SOC之外,自动驾驶系统通常使用高实时、高安保的MISU,满足ASIL-D,而MCU主流软件平台程序使用激光自动SAR,目前可用于支持COS/IP。

目前用于自动驾驶的高性能 SoC芯片通常被纳入芯片中,用于高实时操作的一个或多个Cortex-R核心芯中,还有一个单独的有电力的MCU岛来监测SOC的工作。 经典AutoSAR使用内置的MCU和外部MCU,这不符合成本效益,因为芯片结构不同,与硬件有关的模块往往要多付一个费用,而且费用昂贵。

目前,SoC公司的MCU运行的RTOS系统不是典型的AutoSAR系统,支持SOA的能力有限,我们可以在这个内置的CMU芯片上实施“服务监督”服务,以提高SOA系统的整体可靠性。

为此,必须开发适当的代码生成工具,根据IDL规格(如ARXML或Franca)建立的支持界面,以制作适合某些区域贸易机会的代码,并完成与SOA有关的互动。

增加新的语文支助(四.3.9)

支持 Python 语言也是广泛使用 ROS 的额外分项目之一。 Python 让许多 AI 算法开发专家在不掌握复杂的 C 编程语言的情况下将其算法纳入整个 RSOS 软件系统。

虽然适应性汽车SAR和GENNIVI的实施表现良好,但软件测试对不同能力水平的开发者来说是令人不快的。

对特定发展语言的深入支持是指以该语言建立一个完整的中间运行时间系统,也称为本地语言支持,例如,ROS基于C语言开发,而适应性自动SAR基于C++开发,地下支持是开发基于一种本地语言的另一种语言的API界面。

在性能要求和实时要求方面,为主要实现选择动态语言对于车载软件来说不那么可行,但是,以Python等动态语言提供浅度的API支持仍然可以为自动驾驶系统的发展提供相当大的好处,特别是在软件测试和快速原型创建期间。

除了C和C++之外,近年来快速增长的鲁斯特语是选择土著语言的好选择,鲁斯特担心其记忆安全,这克服了与记忆安全和执行效率不相符的程序语言的历史困难。

图4. 图10 最低业绩和安全结合

我们知道GoogleC++代码[37]包含大约100页的编码标准,而AutoSAR CPP14编码准则已达500页。这些规则的很大一部分旨在尽量减少记忆错误。 从历史上看,处理记忆安全关切的传统方法一直是使用自动垃圾收集(Java.Net et al. ), 当垃圾收集、程序执行被停止时(这在车载软件中是不可取的 ) 。 Rust通过严格的所有权和生命周期管理解决了这个问题。 [38] 。

除了记忆安全外,Rust还为非同步编程提供设计完善的语文级支持,Async/await key字使启动非同步工作相对简单,同时能够建立完全定制的任务时间表机制。

当然,要让鲁斯特成为正式的车辆软件语言,还必须逐步建立一个工具链系统,满足功能性安全标准,并需要一段发展时期,但前景光明。

四、三. 自动启动10个更新接口

由于SOA服务已经在IDL定义中提供了具体的数据类型定义、方法名称和参数,因此完全可以直接根据IDL定义建立基于HTTP的RTF接口。 中间实现应使我们能够扩大IDL定义,支持开发RESTful API, 这种方法在IDL描述中被明确描述为接口。

[rest_enable uri=/math]

interface Math {

methodplus{

in {

Int32x

Int32 y

}

out{

Int64 result

}

}

}

代码生成工具随后应构建代码,以便使用附加方法,利用 POST 行动访问 URL "http://xx:xx/math/plus."。 WebServer 可以直接将中间、运行时间或嵌入服务容器中,并接收HTTP为子孙后代提出的请求,请求提供受监管的SOA服务。

本章摘要为四、三.11。

这一章我们结合SOA架构风格和自动驾驶系统的特殊性，提出了对支持自动驾驶的SOA中间件的一些设想。并讨论了对Adaptive AutoSAR 和 GENIVI 两个技术体系分别分析了进行扩充的方向。其中有一些已经在某些中间件产品中得到实施，更多的还没有得到实践的检验，这也说明适中间的自动驾驶 SOA还有很大的发展空间。

全文结语

这是一份严格的技术性文件, 但是在对全文的总结中, 我想把技术放在一边,

首先,适应性AutoSAR给了我大量CORBA和J2EE的气息:一个完善但复杂的标准体系,但学习曲线陡峭,前进困难重重;标准组织定义规范,提供参考,以及制造商之间标准合作,以进行商品竞争,但产品成本昂贵。

AutoSAR制造商允许的步骤的定价如下:最廉价的许可只能提供给由公认的一级供应商制造的单一的ECU产品,其具体的芯片只能供应给OEM。 批量货物(图中的单个步骤块)的价格超过500万元,如果需要功能安全,则乘以1。

如果在这一价格计划下,各种开发商广泛使用AutoSAR,我担心每个人都很难为中间工厂工作。

虽然AutoSAR标准可以作为各种各样的程序员在网上自由获得,但如果你想在AutoSAR上建立,你应该加入一个汽车软件公司,假设至少花费数百万美元用于研究前研究。 由于AutoSAR的建立在很大程度上依赖于具体的IDE工具,因此工具通常以100 00美元出售Licenense。

在互联网领域,有许多开放源技术系统,在沙之下和海浪之下,而且能够流行的技术必须在某些方面加以定性,而且比较容易解决特定问题。 一般而言,要么侧重于具体的技术点,以促进与其他系统结构的融合;要么是一个整体结构,但可以更灵活地加以使用,并且可以全部或部分地加以使用,如Spring Framewerk.Spring Framewerk在J2EE规范中也使用大量技术,但如果不适合,则适宜使用这种技术并开始使用另一种炉灶。 不论它是否适当,还是不取决于对实际问题的更好解决办法。 此外,这些开放源技术很容易获得,而且人才的发展非常容易和有用,以便更好发展。

汽车软件、汽车操作系统的Linux、汽车操作系

本文由 在线网速测试 整理编辑，转载请注明出处，原文链接：https://www.wangsu123.cn/news/12965.html。