整车操作系统的各种特征，以及Android系统在其中所扮演的角色
在软件定义汽车的时代，vehicle os需要应对日益严峻的软件开发与集成的挑战，其中之一便是如何将面向特定域开发的软件解决方案无缝集成到整车的架构中。这些软件解决方案并非基于特定的e/e架构开发，但必须能够与之无缝交互。本文将阐述统一的整车操作系统的各种特征，以及android系统在其中所扮演的角色。
许多整车厂正在从机械主导汽车向软件定义汽车（sdv）转型。越来越多的用户可以体验到的功能需要通过软件来实现，而非通过机械或机电部件。因此，整车厂需要通过软件更新，在车辆全生命周期内为其部署或改进功能，从而开辟新的业务领域。
如果要充分发挥sdv的潜力，须满足如下三个条件：
>
e/e（电子/电气）架构必须支持硬件算力（hw）和软件（sw）的解耦。因此，未来的大多数车辆都将基于中央/域控（central/zonal）架构，包含三种ecu：高性能计算机（hpc）、区域集成域控（zonal）和传感器/执行器ecu，如图1。
>
hpc和区域集成域控需要搭载车规级的高性能微处理器和微控制器。此类芯片已经面世，计算能力也在逐代提高。
>
要应对软件开发和集成方面日益严峻的挑战，需要一个功能强大的软件平台和生态系统，即vehicle os（整车操作系统）。这对于hpc和区域集成域控来说尤其关键，因为两者通常采用异构的硬件/软件架构，运行数十到数百个应用程序。
vehicle os
目前业内对“vehicle os”（又称“car os”和“automotive os”）一词的使用和解释尚未达成共识，如下是vector对vehicle os的定义：
vehicle os是所有车辆域软件和服务的开发运行平台，由base layer和software factory（软件工厂）组成，需要支持不同开发者之间的合作。
>
vehicle os的软件运行环境称为base layer，在实例化时会因其所运行的平台（微控制器、微处理器和backend）而有所差异。
>
作为vehicle os的基础架构，software factory支持base layer和软件应用的自动化开发、集成和部署。
>
整车厂和供应商之间紧密而敏捷的合作是成功的关键。
vehicle os将覆盖代码量较大的ecu，尤其是hpc、区域集成节点和backend。整车厂越来越将这些领域视为其价值链的核心要素，并将在更大程度上主导vehicle os的开发。
base layer
base layer有两种基本类型：一种用于车载ecu（in-vehicle base layer），另一种用于相关的backend（backend base layer）。本文的重点是车载base layer，由多个架构层的软件模块组成：从与硬件相关的基础架构软件，到操作系统（os）和中间件解决方案，再到整车定义的系统功能，如图2所示。这个软件的超集（superset）适用于整个vehicle os。在特定ecu上实例化base layer时，只考虑该ecu所需的模块。
对于操作系统和中间件层，autosar classic platform已被大量用于微控制器软件的开发，相应的base layer同样基于该标准。考虑到图片的对称性，os在图2中显示为一个单独的组件（实际上autosar classic platform已经包含os）。微处理器的情况与微控制器不同。在微处理器中，通常会使用多个基于posix的操作系统和不同的中间件，这是因为不同的车辆域对基础架构和中间件有不同的需求，并且遵循各自的开发流程。因此，在某些情况下，特别是在车载信息娱乐系统（ivi）和adas/ad领域，通常会使用特定的软件解决方案。
与autosar classic platform不同的是，autosar adaptive platform不定义自己的操作系统，而是基于posix操作系统。除了支持通过零拷贝机制进行ecu内部高效数据交换以及some/ip等通信协议之外，autosar adaptive platform还支持更多车载用例，如诊断和网络管理等。在定义中间件时，autosar adaptive platform特别强调功能安全和网络安全，同时也没有忽视对数据吞吐量的高要求。基于这些特点，autosar adaptive platform已成为adas/ad应用及其它车辆域（如车身和舒适性等）的中间件。在信息娱乐域，受消费电子产品启发甚至源自消费电子产品的软件解决方案越来越多。由于其来源和定位，往往需要进行针对车辆的专用集成。android车辆操作系统就是一个典型例子，稍后将对其进行更详细地讨论。
software factory
hpc和其它集成大量软件的ecu通常不再按照传统的v模型进行开发，而是遵循devops等敏捷开发方法，通过整车厂和供应商之间的密切合作来实现。这些节点的应用软件通常面向feature开发，同一时期会有大量的源代码分支。因此，不同分支的合并以及对源代码更改的快速验证就显得尤为重要。即使在较小的ecu项目中，应用软件和base layer的集成也非常耗时，工作量随着要集成的应用程序数量指数级增加，这些应用程序通常在不同地区/时区的开发中心并行开发。因此，手动的集成方法已不再可行，software factory通过尽可能完全自动化地进行软件集成来解决这一问题（图3）。集成所需的一些信息已在系统设计中提供，通常位于autosar交换格式（arxml）中。缺失的集成条件或集成指令，如调度信息或对特定base layer的配置，可以通过修改可读性较强的配置文件轻松添加。
software factory基于常见的devops工具，如github和gitlab，并辅以汽车开发专用工具，如自动化的配置工具和专用集成管道。与base layer类似，software factory必须兼容各种标准和现有生态系统，并与之交互，以实现集成过程的完全自动化。
android
android是为智能手机开发的操作系统。这类设备配备图形化的触摸式界面，并具有丰富的音视频功能。智能手机可以处理消费电子产品和移动通信的典型接口，还能动态添加和替换应用程序（app）。安卓系统为应用程序提供一个标准化、高度独立于硬件且易于使用的运行环境，以及一个包含软件开发工具包（sdk）、仿真器、文档和示例的生态系统。在此基础上，一个庞大的全球应用程序开发者社区被建立起来。该解决方案的可扩展核心是google提供的安卓开源项目（aosp）。
由于ivi系统的需求特征与智能手机的需求特征高度相似，因此显然可以在车载域中使用安卓系统。在使用aosp时，整车厂可以自行开发地图服务、语音助手和应用程序商店等重要功能，或以google车辆服务（gas）的形式从google获得商务授权。目前，市场上已经有各种基于aosp的ivi系统，有使用gas的，也有不使用gas的。
android automotive os
纯粹基于aosp的ivi系统还需投入更多的开发才能进行批量生产。google已经认识到这一点，并推出android车辆操作系统（aaos）的增强功能，极大地方便了其在汽车领域的使用。其中一个例子是摄像头硬件抽象层，可以在启动过程的一开始，就能显示后视摄像头的图像。另一个例子是车辆硬件抽象层（vhal），代表为ivi应用程序设计的车辆属性模型，提供的属性包括电池尺寸和充电状态，以及目标和实际的内部温度。配置适当的权限后，应用程序可以更改设置值，从而允许用户通过图形界面控制空调系统。由于ivi系统是许多车辆功能的中央控制单元，vhal通常会根据整车厂特定的基础进行扩展，因此包含的属性比google提供的标准属性更多。
vhal支持开发具有高度复用性的应用程序。在目前的实现中，vhal为不同车辆及其各自在ivi系统中的开发提供合适的解耦。但将aaos集成到特定ivi ecu时，需要针对不同车辆的特性进行调整。不同车辆通常以不同的方式建立网络连接，例如通过专用以太网接口、inter partition通信、进程间通信（ipc）或者多种方式相结合。
vhal generation
ecu之间的车载通信通常依据autosar方法并以arxml进行描述，因此可以利用这些信息将车辆侧提供的信号和服务与相应的vhal属性联系起来。这里需要考虑的是，android应用程序希望其行为符合vhal标准，但在对车辆通信建模时，其它考虑因素也至关重要。因此，信号和服务不一定能够一对一映射到vhal属性。此外，在系统启动或软件更新等关键操作阶段的行为也必须被考虑到。arxml建模的通信元素和预期的vhal行为之间进行适当地转换可以简化初始集成，还能显著减少未来aaos更新或车辆通信需求变化时的适配工作，如图4所示。
conclusion
整车操作系统作为一个覆盖所有相关生态系统的强大软件平台，是实现sdv的前提条件。autosar在嵌入式运行环境和相关开发流程中发挥着重要作用，但是并不能涵盖所有域的完整解决方案。不同车辆域的特定需求需要不同的软件解决方案，这会导致整个系统的异构，给系统集成带来新的挑战，例如android车辆操作系统与车载通信ecu的连接。然而，在这种情况下，可以基于现有autosar系统设计信息生成vhal来最大程度地减少集成工作。
vector正在通过嵌入式软件模块和工具链不断扩展其vehicle os产品组合，以确保不同车辆域软件解决方案之间的交互并在系统级别支持或简化它们的集成。例如，提供用于将aaos有效连接到车辆网络信号/服务的vhal adapter，以及支持将aaos作为autosar adaptive platform运行环境的microsar adaptive。
潍柴动力股价大涨背后原因几何?
Razer推出一款乞丐版外接显卡盒，价格可组一台入门级电脑
解读2019年制造业的发展趋向
久违的越狱，自由越狱的 iOS 10.0.1-10.2 即将推出
老旧建筑感应雷防护施工解决方案
整车操作系统的各种特征，以及Android系统在其中所扮演的角色
OPPOR1910倍无损变焦专利曝光 或许会采用全新的屏幕能将前置相机融合在屏幕中
基带芯片甩开高通？苹果挖角高通技术副总裁
电路板OSP表面处理工艺简介
OPPO开发者大会2021 智能定制化的AI交互
专注工业产品开发的瑞米派强势来袭
南方电网发布招标公告 智能电表市场继续稳步增长
自动白平衡算法
量身定制的LVDS连接器的好处
基于CW32系列MCU的MPU6050姿态传感器设计
苹果新ipadpro配置曝光 超强性能，或成最强平板电脑
苹果公司与芯片初创公司Rivos和解谈判中
基本图像处理技术的数据增强方法介绍
华为Mate 40 Pro的内部设计到底如何呢？
国家级工业互联网平台即将落地
许多整车厂正在从机械主导汽车向软件定义汽车（sdv）转型。越来越多的用户可以体验到的功能需要通过软件来实现，而非通过机械或机电部件。因此，整车厂需要通过软件更新，在车辆全生命周期内为其部署或改进功能，从而开辟新的业务领域。
如果要充分发挥sdv的潜力，须满足如下三个条件：
>
e/e（电子/电气）架构必须支持硬件算力（hw）和软件（sw）的解耦。因此，未来的大多数车辆都将基于中央/域控（central/zonal）架构，包含三种ecu：高性能计算机（hpc）、区域集成域控（zonal）和传感器/执行器ecu，如图1。
>
hpc和区域集成域控需要搭载车规级的高性能微处理器和微控制器。此类芯片已经面世，计算能力也在逐代提高。
>
要应对软件开发和集成方面日益严峻的挑战，需要一个功能强大的软件平台和生态系统，即vehicle os（整车操作系统）。这对于hpc和区域集成域控来说尤其关键，因为两者通常采用异构的硬件/软件架构，运行数十到数百个应用程序。
vehicle os
目前业内对“vehicle os”（又称“car os”和“automotive os”）一词的使用和解释尚未达成共识，如下是vector对vehicle os的定义：
vehicle os是所有车辆域软件和服务的开发运行平台，由base layer和software factory（软件工厂）组成，需要支持不同开发者之间的合作。
>
vehicle os的软件运行环境称为base layer，在实例化时会因其所运行的平台（微控制器、微处理器和backend）而有所差异。
>
作为vehicle os的基础架构，software factory支持base layer和软件应用的自动化开发、集成和部署。
>
整车厂和供应商之间紧密而敏捷的合作是成功的关键。
vehicle os将覆盖代码量较大的ecu，尤其是hpc、区域集成节点和backend。整车厂越来越将这些领域视为其价值链的核心要素，并将在更大程度上主导vehicle os的开发。
base layer
base layer有两种基本类型：一种用于车载ecu（in-vehicle base layer），另一种用于相关的backend（backend base layer）。本文的重点是车载base layer，由多个架构层的软件模块组成：从与硬件相关的基础架构软件，到操作系统（os）和中间件解决方案，再到整车定义的系统功能，如图2所示。这个软件的超集（superset）适用于整个vehicle os。在特定ecu上实例化base layer时，只考虑该ecu所需的模块。
对于操作系统和中间件层，autosar classic platform已被大量用于微控制器软件的开发，相应的base layer同样基于该标准。考虑到图片的对称性，os在图2中显示为一个单独的组件（实际上autosar classic platform已经包含os）。微处理器的情况与微控制器不同。在微处理器中，通常会使用多个基于posix的操作系统和不同的中间件，这是因为不同的车辆域对基础架构和中间件有不同的需求，并且遵循各自的开发流程。因此，在某些情况下，特别是在车载信息娱乐系统（ivi）和adas/ad领域，通常会使用特定的软件解决方案。
与autosar classic platform不同的是，autosar adaptive platform不定义自己的操作系统，而是基于posix操作系统。除了支持通过零拷贝机制进行ecu内部高效数据交换以及some/ip等通信协议之外，autosar adaptive platform还支持更多车载用例，如诊断和网络管理等。在定义中间件时，autosar adaptive platform特别强调功能安全和网络安全，同时也没有忽视对数据吞吐量的高要求。基于这些特点，autosar adaptive platform已成为adas/ad应用及其它车辆域（如车身和舒适性等）的中间件。在信息娱乐域，受消费电子产品启发甚至源自消费电子产品的软件解决方案越来越多。由于其来源和定位，往往需要进行针对车辆的专用集成。android车辆操作系统就是一个典型例子，稍后将对其进行更详细地讨论。
software factory
hpc和其它集成大量软件的ecu通常不再按照传统的v模型进行开发，而是遵循devops等敏捷开发方法，通过整车厂和供应商之间的密切合作来实现。这些节点的应用软件通常面向feature开发，同一时期会有大量的源代码分支。因此，不同分支的合并以及对源代码更改的快速验证就显得尤为重要。即使在较小的ecu项目中，应用软件和base layer的集成也非常耗时，工作量随着要集成的应用程序数量指数级增加，这些应用程序通常在不同地区/时区的开发中心并行开发。因此，手动的集成方法已不再可行，software factory通过尽可能完全自动化地进行软件集成来解决这一问题（图3）。集成所需的一些信息已在系统设计中提供，通常位于autosar交换格式（arxml）中。缺失的集成条件或集成指令，如调度信息或对特定base layer的配置，可以通过修改可读性较强的配置文件轻松添加。
software factory基于常见的devops工具，如github和gitlab，并辅以汽车开发专用工具，如自动化的配置工具和专用集成管道。与base layer类似，software factory必须兼容各种标准和现有生态系统，并与之交互，以实现集成过程的完全自动化。
android
android是为智能手机开发的操作系统。这类设备配备图形化的触摸式界面，并具有丰富的音视频功能。智能手机可以处理消费电子产品和移动通信的典型接口，还能动态添加和替换应用程序（app）。安卓系统为应用程序提供一个标准化、高度独立于硬件且易于使用的运行环境，以及一个包含软件开发工具包（sdk）、仿真器、文档和示例的生态系统。在此基础上，一个庞大的全球应用程序开发者社区被建立起来。该解决方案的可扩展核心是google提供的安卓开源项目（aosp）。
由于ivi系统的需求特征与智能手机的需求特征高度相似，因此显然可以在车载域中使用安卓系统。在使用aosp时，整车厂可以自行开发地图服务、语音助手和应用程序商店等重要功能，或以google车辆服务（gas）的形式从google获得商务授权。目前，市场上已经有各种基于aosp的ivi系统，有使用gas的，也有不使用gas的。
android automotive os
纯粹基于aosp的ivi系统还需投入更多的开发才能进行批量生产。google已经认识到这一点，并推出android车辆操作系统（aaos）的增强功能，极大地方便了其在汽车领域的使用。其中一个例子是摄像头硬件抽象层，可以在启动过程的一开始，就能显示后视摄像头的图像。另一个例子是车辆硬件抽象层（vhal），代表为ivi应用程序设计的车辆属性模型，提供的属性包括电池尺寸和充电状态，以及目标和实际的内部温度。配置适当的权限后，应用程序可以更改设置值，从而允许用户通过图形界面控制空调系统。由于ivi系统是许多车辆功能的中央控制单元，vhal通常会根据整车厂特定的基础进行扩展，因此包含的属性比google提供的标准属性更多。
vhal支持开发具有高度复用性的应用程序。在目前的实现中，vhal为不同车辆及其各自在ivi系统中的开发提供合适的解耦。但将aaos集成到特定ivi ecu时，需要针对不同车辆的特性进行调整。不同车辆通常以不同的方式建立网络连接，例如通过专用以太网接口、inter partition通信、进程间通信（ipc）或者多种方式相结合。
vhal generation
ecu之间的车载通信通常依据autosar方法并以arxml进行描述，因此可以利用这些信息将车辆侧提供的信号和服务与相应的vhal属性联系起来。这里需要考虑的是，android应用程序希望其行为符合vhal标准，但在对车辆通信建模时，其它考虑因素也至关重要。因此，信号和服务不一定能够一对一映射到vhal属性。此外，在系统启动或软件更新等关键操作阶段的行为也必须被考虑到。arxml建模的通信元素和预期的vhal行为之间进行适当地转换可以简化初始集成，还能显著减少未来aaos更新或车辆通信需求变化时的适配工作，如图4所示。
conclusion
整车操作系统作为一个覆盖所有相关生态系统的强大软件平台，是实现sdv的前提条件。autosar在嵌入式运行环境和相关开发流程中发挥着重要作用，但是并不能涵盖所有域的完整解决方案。不同车辆域的特定需求需要不同的软件解决方案，这会导致整个系统的异构，给系统集成带来新的挑战，例如android车辆操作系统与车载通信ecu的连接。然而，在这种情况下，可以基于现有autosar系统设计信息生成vhal来最大程度地减少集成工作。
vector正在通过嵌入式软件模块和工具链不断扩展其vehicle os产品组合，以确保不同车辆域软件解决方案之间的交互并在系统级别支持或简化它们的集成。例如，提供用于将aaos有效连接到车辆网络信号/服务的vhal adapter，以及支持将aaos作为autosar adaptive platform运行环境的microsar adaptive。
潍柴动力股价大涨背后原因几何?
Razer推出一款乞丐版外接显卡盒，价格可组一台入门级电脑
解读2019年制造业的发展趋向
久违的越狱，自由越狱的 iOS 10.0.1-10.2 即将推出
老旧建筑感应雷防护施工解决方案
整车操作系统的各种特征，以及Android系统在其中所扮演的角色
OPPOR1910倍无损变焦专利曝光 或许会采用全新的屏幕能将前置相机融合在屏幕中
基带芯片甩开高通？苹果挖角高通技术副总裁
电路板OSP表面处理工艺简介
OPPO开发者大会2021 智能定制化的AI交互
专注工业产品开发的瑞米派强势来袭
南方电网发布招标公告 智能电表市场继续稳步增长
自动白平衡算法
量身定制的LVDS连接器的好处
基于CW32系列MCU的MPU6050姿态传感器设计
苹果新ipadpro配置曝光 超强性能，或成最强平板电脑
苹果公司与芯片初创公司Rivos和解谈判中
基本图像处理技术的数据增强方法介绍
华为Mate 40 Pro的内部设计到底如何呢？
国家级工业互联网平台即将落地