Quartz 4

🔍 搜索

Mi AAOS 信号体系实现

7 min read

Mi AAOS 信号体系实现

  1. 由于目前采用 QNX+Android 的车机系统，且基于标准 AAOS 来做车辆系统开发的背景下，需要一套既兼容标准车辆信号(136个)，又满足全场景覆盖（最小需要 400）的信号实现。

目标 :

  1. 基于 SOA 服务接口定义表格 的全信号体系， 且兼容标准车辆信号(136个)
  2. 在 AAOS 的基础上，数据格式采用 SOA 中 Payload 格式定义，但依然对标准 CarApp 采用兼容方案(既标准 CarApp 可以直接运行在 Mi_AAOS 上)
  3. 对 car-lib 不做或少量改动，保证后续升级稳定以及其他兼容性问题

主要任务 :

以 Key/Value 的思路来考虑数据传递，Key 当然是 SOA 中的 Area_1_2_3 | CMD/STATE (非单独字段，只是上下行概念 ) ， 而 Value 则是 Payload。

  • CMD 下行信号： 以调节主驾空调温度为例， 则 Area_1_2_3 为 HVAC/Temperature/FrontLeft， 其对应的 MS11 信号为 DCDFirstLeTSet
  • STATE 上行信号： 以获取主驾空调目标温度为例，Area_1_2_3 依然为 HVAC/Temperature/FrontLeft， 对应的 MS11 信号为 HvacFirstLeTSt

  1. 对于 Key 的传递，使用 String 是可行的方案，不过考虑到性能以及标准 AAOS 的实现，这里依然采用 propId + areaId 的方案来做 Key， 需要一定的机制来保证各端对 Key 的理解一致。

    1. 对信号的理解，完全采用 SOA 定义，其中 Area_1/Area_2 与 propId， Area3 与 areaId 相对应，在AAOS(VehicleProperty) 中已有定义的，propId 以AAOS 为准，未在AAOS中定义的，采用工具统一生成，作为 Q/A 体系公用，针对DBC中具体信号，以 Area_1_2_3 以及 CMD/STATE 共同映射来确定。

    2. 具体方案待定， 目前有以下方案

      1. 添加新的 types.hal 做补充，并添加详细的注释说明，来作为 SOA 与具体信号的关联(与标准方案类似)
      2. 通过新工具生成具体的 JAVA/CPP 代码供各端使用， JAVA 代码补充在 car-support-lib 中， CPP 代码供 VHAL 以及 QNX 使用

  2. 对于 Value，SOA 中定义的 Payload 比起 AAOS 来说，添加了2个额外字段， relative 与 extension ， 这在一定程度上，可以增加信号使用的灵活度，以及减少不必要的信号定义， 这里目前有以下几种方案可供参考：

    1. 更改原生的 CarPropertyValue(Java|car-lib) / VehiclePropValue(VHAL|types.hal) / VehiclePropValue(VHAL|Protobuf)， 添加 relative 与 extension 字段， 工程量最小，缺陷是标准 CarApp 需要重新打包(打包car-lib)才能正常使用， 而且对AOSP 有些许更改，对之后升级以及兼容性都存在一些问题。
    2. 使用双通道兼容方案， 提供 mi-car-support-lib， 在其中添加 mi_CarPropertyValue ，并且针对 mi_CarPropertyValue 根据已有 car-lib 进行新的 aidl 设计(copy ICarProperty 等类并改相关包名称, like androidx)，在 CarPropertyService 中提供原生 property 与 mi_property service 来分别支持 car-lib 和 mi-car-support-lib，而 VHAL 中的实现方案参考 CustomVehicleHAL 接入原生 VehicleHAL 选型分析
    3. 在propId 中做修改，这种做法有点类似于报文头中添加自定义字段，在 mi-car-support-lib 中添加方法支持， 对 CarPropertyValue 添加额外的增加 relative 与 extension 方法，具体为在需要添加额外字段时候， 将 propId 改造，使得 type 为 MIXED 类型，并在具体的 value 里，将原始数据以及 其他字段填充在 Object[] 中，此链路在 Android 内部务须更改， 在 VHAL 与 QNX 通信中，需要额外解析这种自定义类型， 即 只在 mi-car-support-lib 与 VHAL 中做少量改动即可，缺点是这种自定义数据没有对标准 CarApp 做支持(app 不做支持，且CarService 不能分辨client 是 Custom_App or Original_App)。以语音控制空调温度为例， 在 extension 中添加操作来源：
预期数据
{"mPropertyId":0x15600503, "mAreaId":0x1, "mValue":20.5, "mExtension":{"triggerSource":"VoiceRecognition"}}
 
其中mPropertyId的定义为
     HVAC_TEMPERATURE_SET = (
        0x0503
        | VehiclePropertyGroup:SYSTEM /* 0x10000000 */
        | VehiclePropertyType:FLOAT  /* 0x00600000 */
        | VehicleArea:SEAT /* 0x05000000 */),
 
则最终数据变更为
 
     HVAC_TEMPERATURE_SET = (
        0x0503
        | VehiclePropertyGroup:SYSTEM /* 0x10000000 */
        | VehiclePropertyGroup:MI_CUSTOM /* 0x80000000 */
        | VehiclePropertyType:MIXED  /* 0x00e00000 */
        | VehicleArea:SEAT /* 0x05000000 */),
 
{"mPropertyId":0x95e00503, "mAreaId":0x1, "mValue":[0x00600000/*VehiclePropertyType:FLOAT*/,0 /*relative:false*/, 20.5, /*extension*/{"triggerSource":"VoiceRecognition"}]}

之前遇到使用 extension 的场景为，驾驶模式需要同时发送多个信号，为避免歧义或QNX中过多的逻辑判断，在 extension 中添加了加速/踏板能量回收等信息， 也有在控制投屏中添加全屏，播放等状态的场景。

PropId 构成

下表描述了 32 位 propId 各 bit 段的语义。AAOS 部分沿用 AOSP 标准定义；MiCar 部分新增 MICAR group、MiVehicleZone(A0/A1)、A2 自定义位段。

MASK0xf00000000x0f0000000x00ff00000x0000f0000x00000f000x000000ff
字段含义AAOS VehiclePropertyGroupAAOS VehicleAreaAAOS VehiclePropertyType(AAOS unique id 低段)(MiCar A0/A1)(MiCar A2)
AAOSSYSTEM 1
VENDOR 2		GLOBAL 1
WINDOW 3
MIRROR 4
SEAT 5
DOOR 6
WHEEL 7
BODY 8		STRING 0x00100000
BOOLEAN 0x00200000
INT32 0x00400000
INT32_VEC 0x00410000
INT64 0x00500000
INT64_VEC 0x00510000
FLOAT 0x00600000
FLOAT_VEC 0x00610000
BYTES 0x00700000
MIXED 0x00e00000		colspan=3 → unique id from 0x0000 - 0xffff
MiCarMICAR 6A0 (0x0 - 0xf)
MiVehicleZone		A1 (0x0 - 0xf)
MiVehicleZone*		A2 (0x00 - 0xff)

📷 [图片: PropId 构成表 — AAOS 与 MiCar 的位段分配对照，原文以 7 列 HTML 表格呈现，含 VehiclePropertyGroup / VehicleArea / VehiclePropertyType / unique id / MiVehicleZone A0·A1·A2 各列。已在上方以 Markdown 表格还原。]

参考链接：

propId 组装示例：

KEYBOARD_UP = 1631589891 /* (0x03 | MiVehicleZoneBody:KEYBOARD | MiVehiclePropertyGroup:MICAR | VehiclePropertyType:INT32 | VehicleArea:GLOBAL) */,

当前实现 :

目前采用 双通道兼容方案 (2.b) ， 在 Android 内部使用2套通信链路，来保证各 MICar APP 以及 AOSP Car App 的正常使用。

📷 [图片: 双通道架构示意图 (readonly diagram block, id=doxcnCnfekDKpY9Og3IhWGG7v7m) — 展示 CarPropertyService 同时提供原生 property service (对应 car-lib, 兼容 AOSP CarApp) 与 mi_property service (对应 mi-car-support-lib, 提供 mi_CarPropertyValue), 两套链路在 VHAL 层汇聚与 QNX 通信。]

Graph View

Backlinks