Motocycle 智能仪表盘

前言

在实习期间参与了一个摩托车智能仪表盘项目，在这里我将介绍一下整个项目的 demo，并拿 WIFI、BT、Audio 功能模块示例。

一、项目介绍

该项目主要包括 JS 应用层，C-JS binding 层，Native Services 层和 Linux 内核驱动层。

设计思想和原则：

• 使用成熟易用 IPC 通信方案：该项目涉及的模块众多，既有 Native Service 模块，又有 JS APP 模块，最后选中 ubus 的 IPC 通信机制，主要是 ubus 采用了更加简化的 API 和更为简练的通信模型，更适应于嵌入式 Linux 操作系统的低内存和低端 CPU 性能的特殊环境。同时，ubus 在 OpenWrt 项目得到广泛的应用。
• 模块化设计 ：采用 “分而治之” 的思想，将项目功能分解为一系列模块，模块之间通过明确定义的接口进行交互。模块的分解需遵循高内聚、低耦合的原则，使得模块具有独立性。
• 分层架构 ：将模块按照一定的原则进行层次的划分，每层内部模块之间具有一定类似的交互方式以及相似的跨层次模块的交互方式，使得软件架构更加清晰。后续，如果有客户不采用 JS APP，希望支持 C++ APP UI，一般 Native Services 层以及 Linux Kernel & driver 层完全可以重用，只需要增加一个C++ API adaptor 层，就可以很方便的支持 C++ APPs。

视频演示：

MotoCycle-智能仪表盘

1. 项目架构图

2. JS 应用层

JS 应用层基于 Persim Studio 工具在 PC 开发，打包下载到开发板上直接运行，主要设计了以下几个界面：

• 主界面
• 设置界面
• 手机投屏界面
• ADAS 界面
• 行车记录仪（DVR）界面

2.1 主界面

主界面有两种显示模式：普通模式和运动模式。默认开机进入到普通模式，示意图如下：

主界面可以显示 TBOX 解析的摩托车协议数据，包括车速、油耗、发动机状态等信息。

2.2 设置界面

设置界面包括车辆设置和系统设置两部分，示意图如下：

车辆设置主要包括：

• 车辆信息
• 胎压学习

系统设置主要包括：

• 版本信息（OTA升级）
• 显示设置（白天或夜间模式）
• 智能终端（无线局域网或车机热点）
• ADAS 设置
• DVR 显示
• 恢复出厂设置

2.3 手机投屏界面

手机投屏支持安卓和苹果手机扫码投屏，投屏完可以实现地图导航和播放音乐等，示意图：

2.4 ADAS 界面

ADAS（Advanced Driving Assistance System，高级驾驶辅助系统），是利用安装在车上的各式各样的传感器（毫米波雷达、激光雷达、单\双目摄像头以及卫星导航），在汽车行驶过程中随时来感应周围的环境，收集数据，进行静态、动态物体的辨识、侦测与追踪，并结合导航仪地图数据，进行系统的运算与分析，从而预先让驾驶者察觉到可能发生的危险，有效增加汽车驾驶的舒适性和安全性的一类技术的统称。

示意图：

ADAS 与 TBOX 通过共享内存进行通信，ADAS 可以实时接收 TBOX 传输过来的速度，进行各种安全预警算法的计算，主要包含：

• 前向碰撞预警（FCW）
  • 计算与前车的相对速度和碰撞时间，ADAS算法需要知道本车的绝对速度 speed 和通过图像识别得到的前车相对速度才能计算出精确的碰撞时间，车速越快，留给驾驶员的反应时间越短，因此预警会更早触发。例如，系统可能设定在 TTC 小于3秒时发出警告，而这个 TTC 的计算就高度依赖于本车的速度。
• 车道偏离预警（LDW）
  • 虽然 LDW 主要依赖车辆在车道内的横向位置，但是在高速公路上，即使轻微的、无意识的车道偏离也可能非常危险，因此系统可能会在更高的车速下更早地发出警告。而在低速城市道路，系统可能会更宽容一些。
• 行人检测预警（PCW）
  • ADAS算法需要知道本车速度来预测与行人的相对运动轨迹和碰撞时间。如果车辆静止或低速行驶，即使行人靠近，风险也较低。而当车辆高速行驶时，对行人的检测和预警会变得更加敏感和紧急。
• 盲区监测预警（BSD）
  • ADAS算法通过计算本车还有后车的速度，然后计算出相对速度，根据相对速度来判断风险等级。

2.5 DVR 界面

行车记录仪支持启动和录制两种操作，启动只是视频流在屏幕上显示，录制是后台视频流存储，两种操作可以同时进行，示意图：

行车记录仪启动支持前后摄像头的分别显示，或者两者同时显示，对于前置摄像头，可以支持的 ADAS 功能检测有：

• 前向碰撞预警（FCW），车道偏离预警（LDW），行人检测预警（PCW）、

后置摄像头支持的 ADAS 功能检测为盲区监测（BSD）。

行车记录仪的录制也支持前后摄像头的分别录制或同时录制，录制文件格式支持 MP4 和 AVI 两种，录制模式支持：连续保存，哨兵模式，倾倒保：

• 连续模式下持续循环录制视频，一分钟保存一段，存储达到指定内存后覆盖旧的片段，记录行驶全过程，一般用于事故取证和日常监控。
• 哨兵模式下用于停车后的安全防护，通过摄像头移动检测自动触发录制。
• 倾倒模式通过重力传感器检测车辆剧烈震动或倾斜，自动锁定并保存事件前后摄像头录制的视频。

3. C-JS binding 层

C-JS binding 层完成 JS API 到 C API 的 binding，在这里我负责的模块主要通过 UBUS 进行通信。

UBUS 是 OpenWrt 中轻量级的进程间通信（IPC）框架，基于 Unix 域套接字和 JSON-RPC 协议。
具体介绍可看我之前的文章：

• UBUS 轻量级 IPC 框架和原理详解

Ubus binding 是 JS APP 与 Native services 模块之间的主要通信机制。

4. Native Services 层

本地服务层主要有 ADAS，行车记录仪，手机投屏，WIFI，蓝牙，音频，OTA 等。

WIFI：该模块提供 WiFi (支持AP，STA，P2P）连接的建立和释放管理，以及 WiFi 热点的创建和删除管理。它与其他模块以及 JS 应用层的交互主要基于 ubus 来进行。

BT：该模块主要提供 BT 的使能和关闭功能，以及 A2DP 连接的建立和释放管理过程，支持 BT audio 的播放。它与其他模块以及 JS 应用层的交互主要基于 ubus 来进行。

Audio：该模块提供音乐的播放管理，它与其他模块以及 JS 应用层的交互主要基于 ubus 来进行。

OTA ：该模块提供远程固件版本查询和版本更新功能，它与其他模块以及 JS 应用层的交互主要基于 ubus 来进行。

• 目前方案支持基于 A/B 分区的 OTA 更新过程，软件运行在A分区，可以在运行的过程中，使用最新的OTA版本来更新B分区。升级重启后，uboot会检查A/B分区的版本，如果B分区版本比A分区新，也就是B分区优先级比A分区高，选择从B分区启动。并且支持升级失败时，回滚到升级之前可以工作的版本上。

5. Linux 内核驱动层

Linux 内核驱动层主要提供各种驱动的支持，比如 WIFI，BT，Audio，Camera 等。

二、WIFI_BT_Audio 模块设计

在这里我主要介绍一下 WIFI，BT，Audio 模块设计的 demo，详细功能比较复杂，这里就简单示例。

由于整体项目比较复杂，功能模块比较多，模块的分解需遵循高内聚、低耦合的原则，使得模块具有独立性，所以 WIFI，BT，Audio 等本地服务层主要通过 ubus 与 JS 应用层通信，模块之间通过明确定义的接口进行交互。

1. WIFI 模块设计

主要包含以下功能：

1. 控制 Native services 层 wifi 模块的启动以及对应模式的使能
   • AP 模式：
     • 负责为无线客户端（如手机、电脑）提供网络接入服务
   • STA 模式：
     • 负责连接到 AP（Access Point，接入点）以访问网络资源
   • P2P 模式：
     • 允许两个或多个设备绕过传统 AP（接入点）直接交换数据
2. 根据 Native services 层 wifi 模块上报的 wifi 操作结果

这里我们通过 ubus 协议对外封装好 WIFI 操作相关的接口，示例实现对外接口：

• 开启 / 关闭 wifi 总开关
• 开启 / 关闭 ap 开关
• 开启 / 关闭 p2p 开关
• 开启 / 关闭 sta 开关
• 获取 wifi 开关状态
• 获取 ap 开关状态
• 获取 p2p 开关状态
• 获取 sta 开关状态
• WiFi 信息查询（获取详细的WiFi接口信息（wlan0、p2p0等））

JS 应用层通过 ubus invoke 接口调用来通知服务层的 WIFI，示例如下：

项目使用瑞芯微开发板，根据瑞芯微提供的 SDK 进行开发，在这里添加项目的代码模块：
为了适应不同的使用场景、简化编译流程或支持不同的配置需求，我们的模块代码可以通过以下三种方式编译：

• 在模块代码目录编译模块
• 在顶层目录执行 make + target 单独编译模块
• 在顶层目录编译全部模块

代码示例，以开启 / 关闭 wifi 总开关，获取 wifi 开关状态接口为例：

#include <unistd.h>
#include <signal.h>
#include <stdio.h>
#include <syslog.h>
#include <libubox/blobmsg_json.h>
#include <libubus.h>
#include <libubox/blob.h>static struct ubus_context *ctx;
static uint32_t wifi_status = 0;/*ubus list -v wifi.service"wifi":{"wifi_op":""Int""}"get_wifi_state":{}example:ubus call wifi.service wifi '{"wifi_op":1}'ubus call wifi.service get_wifi_statenote: open=1；close=0
*/enum {WIFI_OP,__WIFI_MAX
};static const struct blobmsg_policy wifi_policy[] = {[WIFI_OP] = { .name = "wifi_op", .type = BLOBMSG_TYPE_INT32 },
};enum WIFI_OP_RC {OP_SUCCESS,WIFI_NOT_ENABLE,OTHER_ERROR,
};enum GET_STATE_RC {OFF,ON
};static int wifi_handler(struct ubus_context *ctx, struct ubus_object *obj,struct ubus_request_data *req, const char *method,struct blob_attr *msg)
{// 用于存储解析后的属性数组struct blob_attr *tb[__WIFI_MAX];uint32_t operate = -1;int result = -1;int ret = -1;// 解析 msg，结果存入 tbblobmsg_parse(wifi_policy, __WIFI_MAX, tb, blob_data(msg), blob_len(msg));// 从解析后的属性中取出整数 operate，只允许0（关闭）或1（开启），否则报错返回operate = blobmsg_get_u32(tb[WIFI_OP]);if (operate != 0 && operate != 1){syslog(LOG_ERR, "Operate AP is error.\n");return UBUS_STATUS_PARSE_ERROR;}// 打开或关闭 wifiif(operate == 1){ret = system("/oem/wifi/open_wifi.sh");syslog(LOG_INFO, "WiFi is turned on.\n");}else if(operate == 0){ret = system("/oem/wifi/close_wifi.sh");syslog(LOG_INFO, "WiFi is turned off.\n");}// 初始化 blob 缓冲区用于构建回复struct blob_buf bbuf_local = {};blob_buf_init(&bbuf_local, 0);// 判断脚本是否执行成功	if (operate == 1 && ret == 0){wifi_status = 1;result = ON;}else if(operate == 0 && ret == 0){wifi_status = 0;result = OFF;}else{result = OTHER_ERROR;wifi_status = 0;}// 构建回复消息并发送blobmsg_add_u32(&bbuf_local, "rc", result);ubus_send_reply(ctx, req, bbuf_local.head);blob_buf_free(&bbuf_local);return 0;
}static int get_wifi_state_handler(struct ubus_context *ctx, struct ubus_object *obj,struct ubus_request_data *req, const char *method,struct blob_attr *msg)
{int result = wifi_status;// 初始化 blob 缓冲区用于构建回复struct blob_buf bbuf_local = {};blob_buf_init(&bbuf_local, 0);if (result == 1)result = ON;elseresult = OFF;// 构建回复消息并发送blobmsg_add_u32(&bbuf_local, "get_wifi_state", result);ubus_send_reply(ctx, req, bbuf_local.head);blob_buf_free(&bbuf_local);return 0;
}// UBUS_METHOD 有参数，参数解析规则为 ap_policy
// UBUS_METHOD_NOARG 无参数，只有对象和方法
static const struct ubus_method wifi_methods[] = {UBUS_METHOD("wifi", wifi_handler, wifi_policy),UBUS_METHOD_NOARG("get_wifi_state", get_wifi_state_handler),
};// 定义对象类型，名称为 wifi，方法如上
static struct ubus_object_type wifi_object_type =UBUS_OBJECT_TYPE("wifi", wifi_methods);static struct ubus_object wifi_object = {.name = "wifi.service",  			   // 对象在系统中的名称.type = &wifi_object_type,			   // 指向上面定义的类型.methods = wifi_methods,			   // 对象支持的方法数组.n_methods = ARRAY_SIZE(wifi_methods), // 方法数量
};static void server_main(void)
{int ret;// 添加 wifi_object 对象到 ubus 上下文ret = ubus_add_object(ctx, &wifi_object);if (ret)syslog(LOG_INFO, "Failed to add object: %s\n", ubus_strerror(ret));// 启动循环uloop_run();
}int main(int argc, char **argv)
{const char *ubus_socket = NULL;// 初始化循环系统uloop_init();// 忽略 SIGPIPE 信号。当向一个已关闭的套接字写入数据时，系统会产生 SIGPIPE 信号，导致程序终止。忽略它可以让程序继续运行，并通过写操作的返回值来处理错误。signal(SIGPIPE, SIG_IGN);// 连接 ubus ctx = ubus_connect(ubus_socket);if (!ctx) {syslog(LOG_INFO, "Failed to connect to ubus\n");return -1;}// 将 ubus 连接与 uloop 事件循环关联，使得 ubus 消息能够在事件循环中被处理ubus_add_uloop(ctx);// 添加 ubus 对象并启动事件循环server_main();// 释放 ubus 上下文资源ubus_free(ctx);// 清理 uloop 事件循环资源uloop_done();return 0;
}

在模块代码目录编译得到可执行文件：

mkdir build
cd build
cmake -DCMAKE_TOOLCHAIN_FILE=../toolchain.cmake ..
make

在顶层目录单独编译 wifi 模块：

make mywfd_test-dirclean
make mywfd_test

2. BT 模块设计

主要包含以下功能：

1. BT 蓝牙的 connect、disconnect
2. 支持 BT scan 和 A2DP 连接

这里我们通过 ubus 协议对外封装好 BT 操作相关的接口，示例实现对外接口：

• 获取蓝牙连接信息
• 获取蓝牙扫描结果
• 获取已配对蓝牙设备列表
• 设置蓝牙焦点设备
• 断开蓝牙设备
• 根据给定参数清除蓝牙配对记录

JS 应用层通过 ubus invoke 接口调用来通知服务层的 BT，示例如下：

接口代码跟上面 wifi 代码类似，这里不再示例。

在模块代码目录编译得到可执行文件：

mkdir build
cd build
cmake -DCMAKE_TOOLCHAIN_FILE=../toolchain.cmake ..
make

在顶层目录单独编译 bt 模块：

make mybtd_test-dirclean
make mybtd_test

3. Audio 模块设计

主要包含 2 方面的功能：

1. 播放本地音频
2. 目前只支持 wav 格式

这里我们通过 ubus 协议对外封装好 BT 操作相关的接口，示例实现对外接口：

• 开启 / 关闭 Audio 总开关

JS 应用层通过 ubus invoke 接口调用来通知服务层的 Audio，示例如下：

接口代码跟上面 wifi 代码类似，这里不再示例。

在模块代码目录编译得到可执行文件：

mkdir build
cd build
cmake -DCMAKE_TOOLCHAIN_FILE=../toolchain.cmake ..
make

在顶层目录单独编译 audio 模块：

make myaud_test-dirclean
make myaud_test

4. 添加全部模块

Buildroot 介绍可以看我之前写的文章，链接如下：

• 使用 Buildroot 构建文件系统

在 Buildroot 中的 package 目录添加自己的源码模块，以 wifi 模块示例，其它类似。

添加 Config.in 和 mywfd_test.mk 文件：

Config.in

config BR2_PACKAGE_MYWFD_TESTbool "My wifi display"helpthis package for motocycle my_wifi display

mywfd_test.mk

MYWFD_TEST_SITE = $(TOPDIR)/../external/mywfd_test
MYWFD_TEST_SITE_METHOD = local
MYWFD_TEST_DEPENDENCIES += json-c
MYWFD_TEST_DEPENDENCIES += ubus
MYWFD_TEST_DEPENDENCIES += libuboxMYWFD_TEST_CONF_OPTS += -DCMAKE_INSTALL_PREFIX=$(TARGET_DIR)
MYWFD_TEST_CONF_OPTS += -DCMAKE_C_FLAGS="$(TARGET_CXXFLAGS)"
MYWFD_TEST_CONF_OPTS += -DCMAKE_LIB_DIR="${TARGET_DIR}"ifeq ($(BR2_PACKAGE_RK_OEM),y)MYWFD_TEST_DEPENDENCIES += rk_oemMYWFD_TEST_INSTALL_DIR := $(BR2_PACKAGE_RK_OEM_INSTALL_TARGET_DIR)
elseMYWFD_TEST_INSTALL_DIR := $(TARGET_DIR)
endif#/oem/usr/bin
define MYWFD_TEST_INSTALL_TARGET_CMDSmkdir -p $(MYWFD_TEST_INSTALL_DIR)/ap;mkdir -p $(MYWFD_TEST_INSTALL_DIR)/wifi;$(INSTALL) -D -m 0755 $(@D)/ubus_wifi $(MYWFD_TEST_INSTALL_DIR)/usr/bin/$(INSTALL) -D -m 0755 $(@D)/ap/* $(MYWFD_TEST_INSTALL_DIR)/ap/$(INSTALL) -D -m 0755 $(@D)/wifi/* $(MYWFD_TEST_INSTALL_DIR)/wifi/$(INSTALL) -D -m 0755 $(@D)/wifi/rfkill $(MYWFD_TEST_INSTALL_DIR)/usr/bin/$(INSTALL) -D -m 0755 $(@D)/wifi/libsmartcols.so.1 $(MYWFD_TEST_INSTALL_DIR)/usr/lib/
endef$(eval $(cmake-package))

修改上层目录 Config.in，添加：

修改启动文件，使开发板上电后自动运行程序：

5. 编译全部模块并上机

在顶层目录添加模块配置：

make menuconfig

保存配置：

make savedefconfig

编译所有模块：

./build.sh lunch
./build.sh

编译成功后将镜像烧写到开发板：

开发板上电自动运行程序：

ubus 调用正常：

三、总结

之前都是自己结合所学知识和兴趣做的项目，在公司接触企业级项目后，学到了很多东西，不管是对于产品还是对于技术深度、个人职业发展都受益匪浅，也十分感谢在公司带我的前辈。

1. 个人技术发展

对于个人技术发展，最好对应用层，中间件，底层/驱动，测试开发流程都有一个整体的了解，再选择一个或者两个方向深入研究。

以嵌入式车载领域为例：

1.1 应用层开发

典型项目 ：

• 车载中控（IVI，如 Android Automotive、QNX 系统上的 UI 开发）。
• 语音交互、导航、车机-手机互联（CarPlay/Android Auto）。
• 基于 AI 的驾驶员监控系统（DMS）。

技术栈与能力要求 ：

• 编程语言 ：C++（性能核心）、Java/Kotlin（Android Automotive）、Python（脚本/算法原型）。
• 框架 ：Qt（仪表盘/HMI）、ROS 2（自动驾驶应用层）。
• 通信协议 ：CAN FD、SOME/IP（车载以太网）、MQTT（与云端交互）。
• 行业标准 ：AUTOSAR Adaptive（面向服务的架构，SOA）。

发展方向 ：

• 纵向 ：车载应用专家 → 智能座舱系统架构师（主导多模块集成）。
• 横向 ：跨域融合（如与 ADAS 系统交互，实现“导航+自动驾驶”联动）。

行业趋势 ：

• 高通/英伟达芯片平台（如 SA8155P、Orin）的普及，推动 3D 渲染、多屏互动需求。
• 需求缺口：熟悉 AUTOSAR Adaptive 的应用开发者 。

1.2 中间件

典型项目 ：

• 车载网络中间件（如 CAN/CAN FD 协议栈、DDS 中间件）。
• AUTOSAR CP/AP 的 BSW（基础软件）配置与开发。
• OTA（远程升级）模块、车载诊断（UDS 协议）。

技术栈与能力要求 ：

• 核心技能 ：
  • AUTOSAR 工具链（Vector Davinci、ETAS ISOLAR）。
  • 实时通信框架（SOME/IP、DDS-RTPS）。
  • 功能安全（ISO 26262 ASIL 等级理解）。
  • 优化方向 ：低延迟通信（如自动驾驶传感器数据分发）、内存安全（Rust 在中间件的应用）。
• 发展方向 ：
  • 成为 AUTOSAR 专家 （国内稀缺，薪资溢价高）。
  • 转向 车载以太网/SDN（软件定义网络） 方向。

案例 ：

• 特斯拉的 Vehicle Controller 中间件采用自定义架构，需要开发者兼具 AUTOSAR 和实时系统经验。

1.3 底层/驱动

典型项目 ：

• 车载 ECU（如 BMS 电池管理、MCU 微控制器）的驱动开发。
• 传感器驱动（摄像头、毫米波雷达、激光雷达）。
• 低功耗管理（12V/48V 电源系统优化）。

技术栈与能力要求 ：

• 硬件基础 ：
  • 熟悉 ARM Cortex-R/M 系列（如 NXP S32K、Infineon Aurix）。
  • 掌握 SPI/I2C/CAN 等接口的硬件调试（示波器、CANoe）。
• 安全关键 ：
  • 符合 ISO 26262 ASIL-D 的代码开发（如 MISRA C 规范）。
  • 硬件冗余设计（锁步核、ECC 内存）。

发展方向 ：

• ECU 驱动专家 → 车载硬件系统工程师（参与域控制器设计）。
• 切入 车载芯片原厂 （如 NXP、TI 的技术支持岗）。

行业动态 ：

• 域控制器（如英伟达 Drive Orin、高通 Snapdragon Ride）推动 高性能异构驱动 需求（GPU/NPU 加速）。

1.4 测试与验证

典型项目 ：

• HIL（硬件在环测试）台架搭建（如 dSPACE、NI 平台）。
• 自动化测试脚本开发（CAPL 语言、Python 控制 CANoe）。
• 故障注入测试（模拟 ECU 异常场景）。

技术栈与能力要求 ：

• 工具链 ：

  • CANoe/CANalyzer（总线分析）、Jenkins（持续集成）。
  • ISO 26262 工具（LDRA、Polyspace）。

• 核心能力 ：

  • 制定 ASPICE 流程中的测试用例。
  • 分析 FMEA（失效模式与影响分析）报告。

• 发展方向 ：

  • 功能安全工程师（TÜV 认证）→ 质量经理（主导车规级认证）。
  • 转向 自动驾驶仿真测试 （如 CARLA、LGSVL 场景库）。

• 行业需求 ：

  • 国内车企对 功能安全（ISO 26262）和 ASPICE 流程 人才需求激增。

2. 完整项目开发流程

一套完整的产品从需求提出到全量上线的研发流程大概如下：

需求发布

• 含义 ：由产品方（如汽车制造商、车载系统供应商的产品部门）明确并传达智能车载系统的各项要求。以文档形式详细描述系统应具备的功能（如导航、多媒体娱乐、车辆信息显示等）、性能指标（响应时间、处理速度等）、可靠性标准（在不同环境下的稳定运行时长）、安全性要求（符合的安全规范）以及与其他车载设备的兼容性等内容，向开发团队、测试团队等相关人员阐述项目目标和预期成果。
• 示例 ：发布一款智能车载系统的需求，要求具备高精度的实时导航功能，支持多种地图数据更新方式；多媒体系统要能流畅播放高清视频和音频，且支持与手机无线连接投屏；车辆信息显示要准确、及时，能显示车速、油耗、胎压等关键数据。

需求优先级评估

• 含义 ：综合多方面因素对收集到的需求进行重要性和紧急程度的排序。考虑因素包括需求对产品核心竞争力的影响、开发成本、技术实现难度、市场需求的迫切性等。
• 示例 ：在智能车载系统中，导航功能直接影响用户的出行体验，是核心需求，优先级较高；而一些个性化的主题更换功能，虽能提升用户体验，但并非核心功能，优先级相对较低。

需求评审/UE评审

• 含义
  • 需求评审 ：组织跨部门团队（开发、测试、产品、售后等人员）对需求文档进行审查。检查需求的完整性（是否涵盖所有必要功能）、准确性（表述是否清晰无歧义）、可行性（在现有技术和资源条件下能否实现）和一致性（各功能需求之间是否相互矛盾），并对需求进行澄清和修改。
  • UE（用户体验）评审 ：关注用户与智能车载系统交互的全过程和感受。评审人员（包括设计师、用户代表等）从用户的角度出发，评估系统的界面设计是否友好、操作流程是否便捷、信息呈现是否清晰易懂等。
• 示例 ：在需求评审中，开发人员发现某些功能的实现需要依赖尚未成熟的技术，可能导致项目延期或成本大幅增加，需与产品方协商调整需求；在 UE 评审中，用户代表认为车载系统的菜单操作过于复杂，提出简化建议。

技术评审

• 含义 ：由技术专家和开发团队对实现需求的技术方案进行评估和审查。评估内容包括技术的可行性（所选技术是否能实现需求）、架构设计的合理性（系统架构是否易于扩展和维护）、系统的性能和稳定性（能否满足性能指标和在各种情况下稳定运行）、与现有车载系统和设备的兼容性等，确保技术方案既能满足需求又具有良好的可维护性和扩展性。
• 示例 ：对于智能车载系统的开发，技术评审时会讨论采用哪种操作系统（如 QNX、Linux 等）、芯片平台（高通、英伟达等）、通信协议（CAN、LIN 等），评估这些技术选择是否能实现导航、多媒体等功能，以及是否能保证系统的低功耗运行和实时响应。

排期

• 含义 ：根据需求的优先级、技术复杂度和团队资源情况，为项目的各个阶段和任务制定详细的时间计划。明确每个任务的开始时间、结束时间和责任人，合理安排资源，确保项目按计划推进。
• 示例 ：制定智能车载系统开发项目的排期，预计硬件设计需要 4 周，软件开发需要 12 周，硬件和软件联调需要 6 周，测试需要 8 周，预留 2 周作为缓冲时间，整个项目计划在 32 周内完成。

开发

• 含义 ：开发团队按照技术方案进行智能车载系统的代码编写、硬件设计和调试等工作。包括硬件开发（如设计电路板、选择电子元件、制作 PCB 板等）和软件开发（根据需求实现各种功能模块，如导航算法开发、多媒体播放程序编写等）。
• 示例 ：硬件工程师设计智能车载系统的主控电路板，选择合适的芯片、内存、存储等元件；软件工程师使用 C、C++ 等编程语言编写导航、多媒体、车辆信息显示等功能的代码。

联调

• 含义 ：将开发完成的硬件和软件集成在一起进行联合调试。检查硬件和软件之间的接口是否正常工作，数据传输是否准确，各个功能模块之间的协同工作是否符合预期，解决硬件与软件之间的兼容性问题。
• 示例 ：在智能车载系统的联调过程中，测试导航模块的数据能否准确地从 GPS 硬件传输到软件处理单元，软件能否正确解析和显示地图信息；检查多媒体系统与音响硬件的连接是否正常，音频和视频播放是否流畅。

产品/UE走查

• 含义
  • 产品走查 ：产品经理从业务需求的角度对开发完成的智能车载系统进行全面检查。验证系统的功能是否完整、准确地实现了需求，各项性能指标是否达到要求，是否满足业务目标和市场定位。
  • UE 走查 ：设计师和用户体验专家再次检查系统的用户体验。确保界面设计符合用户的使用习惯，操作流程简洁高效，信息呈现清晰直观，提升用户对系统的满意度。
• 示例 ：产品经理在产品走查时发现智能车载系统的导航功能在某些复杂路况下的路线规划不准确，需要开发团队进行优化；设计师在 UE 走查时发现系统的显示界面在强光下部分信息难以看清，提出调整显示亮度和对比度的建议。

CR（Change Request，变更请求）提测

• 含义 ：开发团队完成开发和联调，并根据产品/UE 走查的反馈修复问题后，向测试团队提交测试申请。同时，提供详细的测试说明和相关文档，如功能说明、测试用例等，说明系统的变更内容和测试重点。
• 示例 ：开发团队将修复后的智能车载系统提交给测试团队，附上《智能车载系统功能测试说明》和更新后的测试用例，详细说明针对导航功能路线规划不准确和显示界面在强光下可视性问题的修复情况及测试要点。

测试

• 含义 ：测试团队根据测试用例对智能车载系统进行全面测试。包括功能测试（验证系统的各项功能是否正常工作）、性能测试（评估系统的响应时间、处理速度、吞吐量等性能指标）、可靠性测试（模拟各种恶劣环境和使用场景，检查系统的稳定运行能力）、兼容性测试（测试系统与不同车型、不同品牌的手机等外部设备的兼容性）等，发现系统中存在的缺陷和问题，并记录下来反馈给开发团队进行修复。
• 示例 ：对智能车载系统进行功能测试，检查导航功能的路线规划是否准确、多媒体系统的播放功能是否正常；进行性能测试，评估系统在多任务处理时的响应速度；进行可靠性测试，在高温、低温、潮湿等环境下长时间运行系统，检查是否出现故障；进行兼容性测试，连接不同类型的手机进行蓝牙配对和数据传输测试。

准入

• 含义 ：在智能车载系统正式上线或交付前，对系统进行最后的检查和评估。确保系统满足上线的基本条件和标准，如功能完整性、性能指标达标、可靠性符合要求、安全性通过验证等。只有通过准入检查，系统才能进入后续的验证和发布流程。
• 示例 ：对智能车载系统进行准入检查，要求导航功能的路线规划误差在规定范围内，多媒体系统的播放流畅度达到一定标准，系统在连续运行一定时间内无故障，且符合相关的安全法规和标准。

沙盒验证

• 含义 ：将智能车载系统部署到与实际使用环境相似的沙盒环境中进行验证。沙盒环境是一个独立的、封闭的测试环境，用于模拟真实的车辆运行场景、通信网络环境和用户操作行为。进一步验证系统在实际运行中的稳定性、可靠性和安全性，发现潜在的问题和风险。
  示例 ：在沙盒环境中模拟车辆的行驶过程，包括不同的车速、路况和驾驶习惯，同时模拟与外部服务器的通信（如地图数据更新、实时交通信息获取等），检查智能车载系统是否能够正常工作，数据传输是否准确，系统是否会出现异常崩溃等情况。

灰度

• 含义 ：也称为灰度发布或金丝雀发布，在正式全量发布前，先将智能车载系统的新版本逐步发布给一小部分用户（如特定地区的部分车辆用户）进行试用。通过收集这部分用户的反馈和使用数据，评估系统的稳定性、兼容性和用户满意度，及时发现和解决潜在的问题，降低全量发布的风险。
• 示例 ：将智能车载系统的新版本灰度发布给 5% 的车辆用户，收集他们的使用反馈，如是否遇到系统卡顿、功能异常、与手机连接不稳定等问题。同时，分析系统的性能数据（如响应时间、资源占用率等），根据反馈结果对系统进行进一步的优化和调整。

全流量

• 含义 ：在灰度发布经过一段时间的验证，确认智能车载系统稳定可靠后，将新版本全面推广到所有用户的车辆上。让所有用户都能使用到新的功能和服务，实现系统的全面更新和升级。
• 示例 ：经过灰度发布验证，智能车载系统的新版本没有出现严重问题，且用户反馈良好，于是将新版本全量发布，所有支持该系统的车辆用户都可以通过 OTA（Over - the - Air，空中下载）方式更新到新版本。