书接上期，第一期讨论了智能座舱的属性、范围、功能需求，以及未来的发展趋势。

那么有功能需求，就会有非功能需求。今天这期来分析探讨智能座舱的非功能需求部分的内容。

下面从几个维度来分析车载智能座舱的非功能需求，包括：功耗需求、启动需求、功能安全需求、信息安全需求、诊断需求，以及升级需求等等。

第一章：功耗需求

静态功耗

• 背景：考虑整车长时间不使用后，打火电压过低，用户无法打火。

• 指标：5mA => 3mA => 1mA => 500uA => 200uA => …演进过程中指标要逐渐减少。

• 含义：整车掉电后，座舱域控制器常温下稳定时消耗的平均功耗。

• 整车静态功耗分配：整车厂根据整车消耗静态功耗上限要求（某些车厂的整车静态功耗要求为上限30mA左右），在整车掉电后仍然在耗电的ECU之间进行分配。静态功耗指标逐年下降的原因有两方面：一方面，不同OEM对整车耗电的上限值要求严格程度不同；另一方面，整车ECU数量也在逐年增加，单个ECU分担的指标随之降低。

• 新能源汽车：新能源电车智能程度提高后，具备智能补电功能，检测到低压电池电压低于某个阈值，即启动充电，因此不存在无法打火的情况。

STR功耗

• 背景：考虑座舱域控制器操作系统启动时间太长，解决用户等待的痛点，参考手机系统的待机功能，将系统进程冻结再恢复来缩短系统启动时间。

• 指标：约几十毫安，各车厂要求不同。

• 含义：座舱域控制器下电后，DDR保持自刷新状态，SOC的always on模块带电（如有），从Battery输入到DDR供电的电源链路处于ON状态。

• 新能源汽车：由于支持低压电池智能补电的功能，同时解决了用户等待系统上电时间长的痛点，因此STR功能很受车厂欢迎。

典型运行时功耗

• 背景：新能源汽车的出现，新能源电池续航问题成为焦点和短板。在用户正常用车过程中，整车各个模块耗电多少将影响用户的实际用车体验。因此，为了改善电池续航问题，整车厂需要掌握整车各模块在用户通常用车过程中实际的耗电情况。

NEDC功耗

• 背景：与典型运行时功耗不同，NEDC工况为汽车行业统一规范的一种汽车运行工况。在这种工况下，整车耗电多少，将直接影响整车销售时的续航里程参数指标，而这个参数会成为用户买车时的参考指标之一。

• 要求：某些整车厂可能会根据目标续航里程来要求整车各个ECU在NEDC工况下的耗电指标和工作状态。

第二章：启动需求

背景

• 国内Android系统使用之前的阶段，用户对用车体验要求还不强烈，随着互联网应用及需求的逐渐提升，以斑马智行为代表的Tier1供应商因为有着阿里巴巴的互联网基因，引入了斑马OS。

• 这些OS大部分是基于开源AOSP来开发形成的自家的操作系统。由于Android系统为了解决与底层硬件解耦支持更多应用生态从而导致了系统框架层级和模块复杂繁多，于是系统的启动时间也被拉长了。

• 把这个系统引入到智能座舱领域后，相对于传统座舱ECU，启动时间更长了，可能达到二十多秒，优化较好的系统启动时间也在十秒以上。

• 对于那些上车就打火开车的用户来说，这个启动时间无疑是要让用户被动等待一段时间再进行操作，给用户带来了极差的用车体验。

• 因此，斑马的解决方案是：当用户解锁车辆的同时给座舱域控制器上电，让其提前启动，等用户进车并坐好后，座舱域控制器也基本上启动完成了，从而解决用户等待的痛点。

快速启动功能

• Boot animation：系统冷启动时间长，在Boot或Kernel启动阶段显示图片或动画效果，降低用户等待痛点；多屏配置时有多屏联动效果。

• Early Chime：用户上车后启动车辆，打转向、或安全带未系时，系统仍处于启动过程中，需要能够发出告警音，系统上电后2s左右。

• Early RVC：用户上车启动车辆，系统仍处于启动过程中，需要能够显示倒车后视画面，辅助用户完成倒车操作。

• Face ID：用户上车后，此时系统仍处于启动过程稿中，需要能够启动DMS进行用户人脸识别，完成座椅调节等个性化配置。

• Early Radio：系统启动过程中，用户需要能够收听收音机。

第三章：功能安全需求

座舱DMS功能

• ASIL-A/B/QM等级（根据安全目标分解）。

• DMS摄像头监控驾驶员状态，一旦检测到驾驶员分神，或脱手（抽烟），或疲劳（打哈欠、眼睛睁开幅度过小）等，立即发出告警，确保驾驶员在环驾驶。

座舱音频功能

• ASIL-A或QM等级（根据安全目标分解）。

• 警告驾驶员车辆风险，座舱播放告警音，音量需满足要求。

• 刹车系统告警、安全带未系告警、ADAS系统告警、障碍物碰撞预警等等。

座舱触摸功能

• 档位切换功能：P/D/R/N档位切换，ASIL-A/B等级（根据安全目标分解） 。

• 车身控制功能：车窗控制，座椅控制，车门控制，ASIL-A/B等级（根据安全目标分解） 。

• ADAS功能控制：打开/关闭智驾功能，设置车速跟车时距参数，ASIL-A等级（根据安全目标分解） 。

座舱语音控制

• 车身控制功能：车窗控制，座椅控制，车门控制，ASIL-A/B等级（根据安全目标分解） 。

• ADAS功能控制：打开/关闭智驾功能，设置车速跟车时距参数，ASIL-A等级（根据安全目标分解） 。

座舱显示功能

• 仪表Telltale显示：ASIL-B等级；颜色分为绿色、黄色、红色，分别代表不同警告等级；显示方式分为常亮和闪烁；背景显示有透明、半透明、不透明等，对系统设计要求难度也不同；显示位置不变，或根据换肤风格显示位置可变；图标显示占用像素块大小为32*32、64*64，或按照区域检测等。
  li>HUD显示：ASIL-A或QM等级（根据安全目标分解） ；车速或telltale、导航AR guide、ADAS信息、交通标志等等。
  li>Camera显示：ASIL-A或QM等级；帮助用户有更好的驾驶或倒车的视角，需要显示倒车或环视视野画面。

Telltale信息补充

• Telltale种类：位置灯、远光灯、近光灯、随动转向灯、自动驾驶远光/近光灯、前/后雾灯、AFS自适应前照灯、左/右转向指示灯、驱动系统准备就绪指示灯（Ready）、驱动功率限制工作指示灯、安全气囊故障指示灯、动力系统故障指示灯、巡航状态指示灯、动力电池低/故障指示灯、LKA指示灯、ACC指示灯、充电连接指示灯、EPS助力转向故障报警灯、胎压低/故障指示灯、ESC状态指示灯、制动灯、ABS故障指示灯、EPB驻车工作指示灯、安全带未系指示灯、蓄电池故障指示灯、驱动电机系统故障指示灯、低速提示音关闭/故障指示灯、儿童锁开启状态指示灯、刹车灯故障指示灯、门开报警指示灯、刹车片磨损指示灯、悬架状态指示灯。

第四章：信息安全需求

车联网信息安全定义

• 车联网是一种能够实现汽车与人类、车辆、交通设施等周边环境要素全方位互联互通的信息通信技术，其通信链路需满足低时延、高可靠性等严苛技术指标。

• 从技术维度来看，车联网信息安全以构建多层纵深防御、软硬件协同联动的安全防护体系为核心目标，主要涵盖三大关键技术领域：一是汽车网络安全建模技术，为安全防护提供理论与模型支撑；二是覆盖数据存储、传输、应用全生命周期的三维安全防护体系，保障数据流转各环节的安全性；三是汽车网络安全测试方法，通过标准化测试验证防护体系的有效性与可靠性。

• 从应用角度，车联网网络安全主要包括以下五个方面：

第五章：诊断需求

背景

• 随着用户对汽车体验要求的提高，汽车电控系统变得越来越复杂，从而实现更多的智能化功能。为了保证整车下线出厂质量要求，提高售后服务水平，无缝衔接的诊断系统开发在整车开发中的重要度日益突出。完备的诊断测试系统，不仅能简化零部件供应商的诊断测试工作，更能大大减少OEM厂商的诊断测试工作量，也便于对控制器供应商进行系统管理，保证诊断数据的完备性和可靠性。

诊断

• 诊断分类：OBD诊断，诊断范围聚焦于排放系统相关的电控单元（ECU），主要用于满足车辆排放合规性检测等相关需求；UDS诊断，诊断覆盖整车全部电控单元（ECU），可实现对车辆各系统的全面故障排查与状态监测。

• UDS诊断协议类型：UDS诊断协议根据底层通信链路的不同，分为两种实现形式。DoCAN，基于 CAN 总线通信的 UDS 诊断协议；DoIP，基于以太网通信的 UDS 诊断协议。

• 诊断角色划分：诊断架构中包含两类核心角色，诊断 master，作为诊断指令的发起方，负责控制诊断流程、下发诊断请求；诊断节点，作为诊断指令的接收方，响应主设备的请求并反馈自身运行状态与故障数据。

第六章：升级需求

升级

• 升级途径：支持两种核心升级方式：USB 本地升级与 OTA 远程升级。

• 数据传输链路：升级数据的传输连接方式包含三类：4G/5G 移动网络、WiFi 无线网络，以及 USB 有线传输。

• 升级内容分类：升级覆盖两大核心类型：车载控制器固件升级与 车机应用程序升级。

• OTA Master：承担整车电子控制单元（ECU）升级包的分发调度，以及全流程升级过程的统筹管理职责。

• 云端管理职能：负责升级策略制定、升级任务编排、软件版本全生命周期管控，以及升级相关数据的统计分析等工作。

• 车端执行职能：具体完成升级软件包的下载、刷写安装、差分包还原，同时开展升级包的安全性校验与完整性校验等单车级升级操作。

OTA升级

• 车端交互与控制：升级通知触达：向用户推送软件升级提醒；支持用户授权立即升级、授权预约时段升级，以及取消已预约的升级任务。配套策略与交互：OTA 升级期间自动调整车辆电源管理策略；车机端实时展示升级进度、版本信息等内容；同时支持通过手机端发起远程升级操作。

• 云端升级任务管控：支持升级包的分组定向发布能力，在新升级包上线后，可根据预设条件筛选特定用户群体，精准推送对应的升级包，实现分批次、分场景的升级部署。

升级流程

• OEM负责：软件新版本 - 升级包生成 - 升级包测试 - 升级策略 - 升级任务；

• 用户负责：获取通知 - 用户授权 - 升级包安装 - 升级结果反馈。

升级流程说明

• 软件新版本上传：OEM或其供应商完成车载电子控制单元（ECU）软件新版本的研发与测试后，将对应的软件包上传至 OTA 云端管理系统，为后续升级流程奠定基础。

• 升级包智能生成：OTA 云端系统会结合已上传的新软件包，以及车辆零部件当前搭载的软件版本信息，通过自动或手动方式生成软件升级包。针对体积较大的软件包，系统可同步启用差分技术，实现升级包的轻量化处理。

• 升级包严格测试：为保障升级过程的稳定性，所有生成的升级包均需通过全面测试，测试合格后方可面向终端用户下发。优质的 OTA 系统还具备测试车辆的全生命周期管理能力，可支撑升级包的验证工作。

• 升级策略定制：不同车型、不同控制器的升级流程、触发条件及安全标准存在差异，OTA 云端需根据这些差异化需求，定制对应的升级策略。该策略需完成测试验证，再与软件包一同下发至车辆端。升级策略的定制灵活度，是衡量 OTA 系统性能的核心指标。

• 升级任务制定与审核：升级策略用于规范单辆车的升级流程，升级任务则针对批量车辆的升级需求进行统筹规划。任务内容需明确升级覆盖的车辆范围、涉及的零部件类型，同时规定升级前向用户推送的通知内容与提示要点。此外，升级任务需通过内部审核机制把关，审核通过并发布后，目标车辆即可接收升级通知。

• 车辆接收升级通知：OEM 在云端发布升级任务后，处于升级覆盖范围内的车辆，会自动获取云端推送的升级通知。通知内容通常包含升级适用范围、预计耗时等关键信息。

• 用户授权确认：车辆售出后，其内置程序与存储空间归用户私有，OEM 对车辆软件进行任何改动，均需获得用户的明确授权。仅在用户授权通过后，车辆端才可启动软件包下载与升级操作。

• 升级包下载与校验：车辆端从云端获取本次升级所需的软件包及配套的升级执行脚本，随即对其进行安全性与完整性校验，校验无误后方可进入正式升级环节。

• 升级包安装执行：升级包安装是车载软件升级的核心执行阶段。尽管这一过程与电脑软件升级有相似之处，但因车载控制器的特殊性，实际操作逻辑和技术要求存在显著差异，需匹配对应零部件的专属升级方式。

• 升级结果云端反馈：车辆端完成升级操作后，无论升级成功与否，均需将详细结果回传至 OTA 云端。车端数据的实时反馈，是实现升级全流程管控与优化的关键基础。