ASPICE汽车软件开发流程学习基地

2026-10-24

eCall车载事故紧急呼叫系统最新技术路线与安全合规分析

从 LTE/IMS 演进与车厂救援链，到可验证的全生命周期证据

文章结构

技术路线约占全文一半：NG eCall、LTE/IMS 与 2026 互操作验证、车厂公开服务链、芬兰运行数据；安全合规约占一半：ASPICE、ISO 26262、ISO/SAE 21434、UNECE、中国强制国标、欧盟 eCall 与 CRA 的融合闭环。

eCall 的工程对象：一条“事故到救援”的端到端链路

eCall（车载事故紧急呼叫）不是单独的 SOS 按键，也不是一个普通车联网应用。它是一条具有安全意义的服务链：车辆识别事故或由乘员手动触发，形成可信的位置和事故数据，建立紧急语音与数据通道，再由公共安全应答点（PSAP）接听、确认并调度救援。链路上任何一个环节失效，都可能把“系统已触发”误当成“救援已送达”。

因此，技术路线不能只按蜂窝代际或模组规格做选择。设计必须同时回答：车端在碰撞后是否还能工作；网络不支持旧式电路交换后能否完成紧急呼叫；位置和数据是否可理解、可信、最小化；PSAP 是否真正接收；软件更新和漏洞响应能否贯穿车辆生命周期。以下按技术路线与安全合规各约 50% 展开。

一、最新技术路线：从“能拨出”走向端到端可用

1. 主路线已从电路交换迁移到 IMS 分组交换

传统 eCall 以 2G/3G 电路交换语音呼叫为基础，将最小数据集（MSD）调制为音频信号，在语音通道中传给应答中心。该方案易于依托既有语音网络，但受制于 2G/3G 退网、语音与数据分时传输、音频链路质量，以及不同网络设备对调制解调流程的兼容性。多个欧洲运营商已规划在 2025—2030 年间逐步退网旧网络，继续把“能找到 2G/3G 信号”作为车辆长期可用的前提，无法满足车型全生命周期的可维护性。

新一代 eCall（NG eCall）的主路线是在 LTE/5G 分组交换网络上，通过 IP 多媒体子系统（IMS）建立紧急会话，并按相应协议传送 MSD。技术上的关键不是简单换成 4G/5G 通信模组，而是车载终端、IMS 紧急呼叫路由、移动网络运营商和 PSAP 的端到端协同：终端要能正确发起紧急会话；网络要识别并路由；应答中心要接收、解析并呈现数据；语音要能建立并维持。

截至 2026 年 10 月，欧盟法规的转换已进入实际车型准入阶段。自 2026 年 1 月起，新型 M1/N1 车型准入进入分组交换 eCall 路径；随后新车生产节点继续迁移，型式批准需按 Regulation (EU) 2024/1180 及其生效时点执行。技术标准也在快速更新：ETSI 2026 年测试报告引用 EN 17184:2024+A1:2026、EN 17240:2024+A1:2026，并列出用于混合电路/分组交换环境的 EN 18052:2025。必须区分“最新技术标准版本”和“法规引用的型式批准基线”：送审时应逐项核对法规附件、车型节点及批准机构接受的版本，不能只用最新标准编号替代法律判定。

终端之外，接警侧也进入并行迁移。欧盟新建 PSAP 自 2024 年 5 月起需支持分组交换 eCall；既有 PSAP 的转换节点为 2026 年 1 月。传统电路交换接警仍需在成员国至少有一个 2G/3G 网络运行期间继续支持。这意味着 2026 年不是“旧网一夜停掉”，而是 IVS、运营商与 PSAP 需要共同通过双栈/迁移期测试。

2026 年 6 月，ETSI 在斯洛文尼亚真实 4G 网络组织 NG eCall Plugtests，面向 IVS 与 PSAP 设备互操作，依据 ETSI TS 103 683，并配置一致性测试能力。报告记录的参考规范包括 EN 17184:2024+A1:2026、EN 17240:2024+A1:2026、EN 18052:2025 与 EN 16072:2025。活动结果用于发现跨厂商实现差异并提出标准澄清/实施指导，不等同于所有参测产品通过某国型式批准。它也说明近期验证主战场仍是 LTE/IMS 端到端互通；5G 是后续接入能力，不应在当前项目中被当成默认测试已覆盖。


路线	2026 年定位	选型与验证闸门
LTE / IMS NG eCall	当前新型 M1/N1 车型的主要分组交换路径；ETSI 2026 互操作活动以真实 4G 网络测试。	逐市场验证紧急 IMS 注册、呼叫路由、MSD/语音、PSAP 接收和回拨；不能只做模组吞吐测试。
Hybrid CS / PS eCall	EN 18052:2025 覆盖混合电路/分组交换环境的端到端测试情形。	仅在批准方案、当地运营网和 PSAP 均支持时纳入过渡配置；不是所有新车通用的强制回退方案。
5G / 卫星 NTN 扩展	可拓展未来网络与偏远区域覆盖，但当前测试/应急接收能力依地区而异。	须先证明运营商、终端、应急路由、PSAP 与批准体系闭环；不能以“支持 5G/卫星”替代法定公共 eCall。

产品路线还应按车型生命周期分阶段，而不是把“下一代通信”作为一次性硬件替换：


时间窗	技术落点	项目决策闸门
2026–2027：准入切换	EU 新型 M1/N1 车型进入分组交换路径；中国 GB 45672—2025 将于 2027 年 7 月实施。实际互操作仍以 LTE/IMS 为当前重点。	冻结市场/车型和合规版本；以真实或经认可的运营商/PSAP 测试设施完成建链、MSD、语音、回拨与故障测试。
2027–2030：存量迁移	各市场 2G/3G 退网节奏不同。芬兰研究预计其现有 2G/3G eCall 将在 2030 年失效；此日期不能外推到其他国家。	保留区域配置与网络退役台账；评估 eSIM/漫游档案、车载备电、供应商支持期和型式变更影响。
2030+：有条件扩展	5G、NTN 及更丰富的事故上下文可作为演进选项，当前互通、救援接收及法规成熟度因地而异。	只有在终端、网络、呼叫路由、PSAP、法规和服务责任全链路闭合时，才进入量产路线。

项目可建立统一的端到端运营指标，但不应在未获法规/PSAP认可时自创“全球强制阈值”。建议按测试配置分别记录：事故触发至紧急会话请求的时间分布、IMS 建链成功率、MSD 接收/解析完整率、双向语音可懂度、事故后备用电源维持能力、定位新鲜度/可信度、自动与手动误报/漏报、PSAP 回拨成功率，以及不同网络覆盖和区域配置下的故障恢复结果。指标必须绑定车型软硬件版本和测试网络，才可用于量产放行与在役趋势比较。


路线判断 2026 年应把 LTE/IMS 互操作作为可验证的工程基线，把 5G 当作区域化演进能力；PSAP、运营商和车端必须成套验收。支持 5G 本身不等于符合 eCall，也不保证救援链路可靠。2G/3G 兼容策略要以当地网络退网时间为边界。

2. 推荐的车端架构：独立触发、可信定位、直接呼叫

稳健架构应把事故触发、通信和远程运维分开考虑。触发输入可以来自气囊/约束控制器、碰撞传感器及人工 SOS 按钮，由受控状态机完成触发判定、误触抑制和事件锁存。位置模块应提供坐标、方向、时间戳及有效性信息。通信控制单元负责网络注册、紧急会话、MSD 发送、双向免提语音和故障诊断。供电路径则要处理车辆主电源在碰撞中断开的情况。

核心原则是 eCall 至 PSAP 的救援通道不得把 OEM 云平台设置为唯一中继依赖。云端可以承担授权的运维、状态分析和软件更新，但公网故障、云端故障或服务订阅状态，不应成为公共紧急呼叫无法直达的单点故障。事故事件数据也要与常规车辆遥测隔离，按当地规则控制访问、用途和保留期限。

图 1　事故触发、位置/MSD、蜂窝/卫星接入与应急接听的端到端关系。图中卫星路径是补充设想，只有在当地监管及 PSAP 接收机制允许时才可采用。

3. 通信连续性：优先解决网络、语音和电源的失效组合

实际安全目标不是“覆盖到所有网络”，而是让系统在明确的故障组合中保持可预期行为。建议围绕紧急会话建立网络选择和超时策略：区分 IMS 紧急注册失败、无线接入不足、语音媒体建立失败、MSD 确认失败和 PSAP 无应答；明确重试次数、网络切换条件、呼叫状态提示和本地诊断记录。是否允许回退到传统电路交换，必须依据当地网络、型式批准和运营商配置，不可假设终端可在任何网络自由互通。

eSIM/eUICC 和多运营商配置可提升异网覆盖，但要把运营商档案、紧急呼叫身份、漫游策略和认证状态纳入验证。单纯增加第二张卡或第二套无线模组会引入射频共存、天线、供电、软件切换和认证复杂度。冗余设计要经过故障树与试验论证，不能只看物理器件数量。

备用电源能力尤其容易被低估。碰撞会破坏电池连接、保险、线束或天线馈线；系统需评估主电源丢失时的最低工作时间、语音可懂度、呼叫重试和状态上报。欧盟 2025 年后续法规强化了备用电源测试和车辆周期检验可测性要求，意味着 eCall 的可维护性要从型式批准阶段设计，而不是量产后再补诊断接口。

4. 定位与事故数据：不仅要有坐标，还要知道坐标是否可信

定位可采用多星座 GNSS，并结合惯性测量、轮速和车辆运动信息进行短时航位推算。碰撞后天线受损、地下道路、城市峡谷和遮挡环境会让“最近一次坐标”与事故现场不一致。系统应保留位置时间戳、置信或有效性状态，避免将过时定位包装成实时精确定位。GNSS 欺骗与干扰既是网络安全风险，也会直接破坏救援调度的有效性。

MSD 的工程重点是字段语义一致、编码无歧义、传输完整性和应答中心可解析。法定最小数据集不应被随意扩展成高敏感乘员画像。对可选的碰撞方向、车辆动力状态或座舱乘员信息，要明确数据来源、准确性、用途和接收方能力；未经证实的“伤情预测”不宜作为救援系统的硬性承诺。语音通道仍然重要，因为应答人员需要确认情况，结构化数据不能替代人工问询。

5. 卫星、平台化与软件定义：增长方向，但不等于当前基线

3GPP 非地面网络（NTN）把卫星或高空平台纳入移动通信体系，为偏远道路、灾害区域和地面网络盲区提供补充连接的可能。汽车直连卫星仍涉及终端射频能力、天线视场、功耗、移动波束、法规频段、漫游/服务授权、紧急路由以及 PSAP 接入。因而现阶段的合理定位是“补充覆盖和韧性能力”，而非默认替代地面 NG eCall，更不能未经型式批准或应急部门认可就宣传为通用 eCall。

软件定义车辆的趋势会让 eCall 与 T-Box、中央计算平台、车载以太网、远程诊断和 OTA 更新更加紧密。设计上应保持紧急功能的故障隔离：娱乐、广告、订阅服务或普通远程控制软件的故障，不应拖垮紧急功能；升级中断时应保留可恢复版本；变更通信协议、证书、基带固件或 MSD 映射时，应触发相应回归和合规影响评估。

图 2　技术演进的重点是可靠的地面 IMS 通道与定位融合；卫星 NTN 适合作为有条件的补充覆盖。

6. 车厂公开路线案例：法规型 eCall 与品牌救援服务不是一回事

不同车厂公开资料的共同点是自动识别严重碰撞、传出位置或车辆信息并建立语音/服务连接；差异在呼叫终点、谁来判断并转接救援，以及中间服务失联时的回退方式。公开车主手册通常不会披露基带、IMS 栈、运营商配置或 5G/NTN 方案，因此下表只比较可核实的服务链，不反推未公开的无线实现。

图 3　法规型公共 eCall、品牌呼叫中心中继和扩展型 ACN 三种服务链。表内厂商案例均限定于公开手册所述车型/市场/配置。


案例 / 范围	公开资料可确认的呼叫与数据路径	工程启示
欧盟 112 eCall；新型 M1/N1	车辆自动或手动触发，发送 MSD 并建立语音，接入适当的公共应答点。法规允许在法定 112 eCall 之外提供 TPS 服务。	把法定公共链路与品牌增值服务分别建模；不能用品牌功能替代型式批准。
BMW Intelligent eCall；依市场/配置	官方 FAQ 说明 Intelligent eCall 可向 BMW 呼叫中心发送 GPS 位置/方向、VIN、车色、事故严重度及车内人数；同一资料区分 6AC 与 6AF 配置。	先核对车型配置和国家；数据更丰富并不代表所有市场都走同一目的地。
Volvo V60；特定车型/市场	官方支持资料说明可选择优先联系 Volvo On Call 服务中心或公共应急中心；服务中心优先时联系失败可回退，公共中心优先时失败不一定反向回退。	回退逻辑可能不对称；必须把断链行为写入需求并做实车验证。
Tesla Model Y；中国手册、如车辆配备	重大碰撞/气囊展开可自动激活；手册描述联系 Tesla 道路救援并发送车型、乘员数、事故位置与 VIN，且要求蜂窝信号足够。	品牌救援描述不能单独证明满足 GB 45672 的公共应急链路和批准要求。
GM OnStar ACR；美国服务	官方说明由车载传感器识别严重碰撞，OnStar 顾问接入车内；即使无回应，可向第一响应者提供位置和伤情严重度预测。	把服务型 ACN 与法规型 eCall 分开验证；算法输出是辅助信息，不是医学诊断。

图 3 与表格共同说明三点。第一，公共应急呼叫与品牌服务中心是不同的服务终点，一个车型可以并存，但责任、数据流和消费者提示必须分开。第二，OEM 中继能提供人工确认或更丰富上下文，同时增加了中心可用性、跨境路由、商业服务状态和回退逻辑等依赖。第三，直接送达公共应答点的路径减少一跳，但 MSD 语义、语音建立、当地 PSAP 接收能力和真实互操作更关键。

项目评审不应只看宣传页上的“自动 SOS”。对每个市场版本至少要回答：触发后拨给谁；该终点是否是法定 PSAP 或获认可的服务机构；服务中心无法接通时是否有回退；是否将车辆身份、乘员数、位置或伤情推断传给第三方；信号覆盖不足、无有效订阅或呼叫中心不可用时，系统如何告知和留痕。

7. 运行数据校正设计判断：误报、车队渗透率与救援效益

讨论 eCall 效益时要区分模型预测与真实运行研究。欧盟委员会仍列示早期影响评估的估计：城市响应时间可缩短约 40%、乡村约 50%，死亡人数至少减少 4%、重伤减少 6%。这些是早期部署情景的估算，不能当成 2026 年所有国家都已观测到的实绩。

更近的实证视角来自芬兰。芬兰交通与通信局委托 VTT 对 2019—2023 年事故、应急呼叫和救援数据开展研究，并于 2026 年发布结果。研究按计算估计自动 eCall 在这五年内可能避免约 1 起道路死亡事故，但没有把估值归因到某一宗可单独识别的事故；在用乘用车和货车中的装配率估计为 2025 年 12.5%，并预测到 2035 年约为 27%。研究模型预测 2019—2035 年累计可能避免约 10 起死亡，并使约 13 起原本可能造成重伤的结果降为轻伤，这些都属于预测而非已发生的实绩。

芬兰研究还把误报比例拆到不同链路：全部 eCall 来电中 80.6% 被判为不必要通知；自动触发子集为 55.3%，手动触发子集为 94.0%。经第三方服务中心过滤后、最终到达应急中心的 TPS eCall 中，误报比例为 1.9%；研究指出这种筛选很有效，但服务中心中继也可能增加延迟。各百分比的分母不同，不能当作同一类呼叫的横向性能排名；结论也不能直接外推到其他国家。

图 4　芬兰 Traficom 研究报告 2/2026：车队比例与生命影响分别标明年份/预测口径；误报比例使用不同分母。

这组数据把系统工程重点从“多加传感器”拉回服务质量。自动触发阈值需要兼顾漏报和误报；手动 SOS 应有清楚的操作反馈与可撤销窗口；自动/手动事件要能在 MSD 和 PSAP 界面中区分；第三方中心的过滤收益应与增加的转接延迟一起评估；测试设备必须与真实紧急号码隔离；PSAP 还要能处理重复呼叫、无声呼叫和误触取消。日常测试不得拨打真实 112 或真实公共 eCall 号码。

额外图像、座舱传感器或健康数据可能帮助应急人员判断，但应以接收端可处理、法律允许、数据最小化及乘员授权为前提。信息量增加本身不等于救援更快；如果 PSAP 无法解析、数据不可信或隐私边界不清，新增字段会增加工作负担和攻击面。

二、安全与合规路线：把标准变成闭环证据

8. 先分清“法规、标准和过程模型”各自解决什么问题

合规项目常见失败不是缺少标准名称，而是把不同性质的要求混成“做一次认证就全部满足”。法规或强制技术规范定义市场准入和产品结果；ISO 标准提供安全/网络安全工程方法；ASPICE 提供研发过程能力评价框架；UNECE 管理制度要求则关注整车企业级的网络安全、软件更新管理系统。它们可以共享需求、风险和验证证据，但任何一项都不能自动替代其他项。


层级 / 基线	核心关注点	在 eCall 项目中的落点
产品型式批准与强制技术要求	规定车型、系统和关键性能如何证明符合市场规则。	触发、位置、语音/MSD、耐久/电源、互操作与型式试验。
ISO 26262:2018	处理道路车辆 E/E 系统故障行为导致的功能安全风险。	依据系统定义与 HARA 分配安全目标、需求、验证和安全论证；不预设通用 ASIL。
ISO/SAE 21434:2021	对车辆 E/E 系统全生命周期开展网络安全风险管理。	TARA、网络安全目标、工程措施、漏洞管理与网络安全案例。该版正处于修订推进阶段，现行项目仍应以有效发布版为基线并监测修订。
Automotive SPICE 4.0	评价系统、软硬件、支持和组织过程能力。	形成需求追溯、架构、集成验证、配置/变更和问题闭环证据；不是法规认证或功能安全等级。
UN R155 / R156；中国 GB 44495 / GB 44496	整车网络安全管理与软件更新管理及相关产品要求。	把 CSMS/SUMS 组织机制落实到车型，并联动 eCall 通信、凭证、OTA 和漏洞事件。
欧盟 CRA	数字产品的网络安全设计、漏洞处理和市场义务。	须先判断产品边界；适用时需纳入漏洞/事件报告和生命周期维护要求。汽车型式批准法规覆盖的产品有法定范围排除。

9. ISO 26262：对功能失效做风险分析，不给 eCall 预设 ASIL

ISO 26262:2018 面向量产道路车辆 E/E 安全相关系统，关注系统异常行为及其与其他系统交互可能造成的危害。eCall 的失效多数表现为未触发、延迟呼叫、位置错误、错误触发、碰撞后供电丢失、语音不可用或网络切换失效。它通常不直接控制车辆运动，但具有减少事故后果的安全目标，仍需由系统定义、运行场景和危害分析决定标准适用范围及必要的安全措施。

工程上应先定义 item 边界、功能与接口，再开展 HARA，分析严重度、暴露率和可控性，并形成安全目标及功能/技术安全需求。不可因为“这是紧急功能”就直接指定 ASIL D，也不可因为“它不控制转向制动”就认定 ISO 26262 完全无关。ASIL 是特定危害与安全目标推导的结果，系统内不同功能可有不同等级或经论证采用 QM。

验证至少要覆盖正常触发和异常触发、车辆网络消息错误/缺失、定位无效、关键任务超时、存储器或电源异常、音频链路故障、主电源切断和通信模块复位。安全机制和诊断应能区分“已尝试呼叫”“已建立语音”“MSD 已送达/确认”等状态，避免只以一个灯或故障码宣称系统可用。

10. ISO/SAE 21434 与 R155：从 TARA 到量产后的漏洞闭环

ISO/SAE 21434:2021 定义汽车网络安全风险管理工程要求，覆盖概念、产品开发、生产、运行、维护和退役。对 eCall 做 TARA 时，资产不仅是车辆数据，还包括紧急呼叫可用性、位置真实性、PSAP 路由可信性、车辆身份与通信凭证。攻击面包括 SOS 按键与车载总线、无线基带和 IMS 配置、GNSS、远程诊断/OTA、供应链软件组件，以及 OEM 后端与外部服务接口。

控制措施要按风险分层：安全启动和签名验证保护启动链；硬件安全模块或等效安全存储保护密钥；分区和最小权限限制普通应用对紧急通信资源的影响；通信认证和完整性校验保护数据；网络隔离、诊断授权和速率限制降低滥用风险；软件物料清单、漏洞监控、补丁和事件响应控制供应链及量产后风险。对于公共紧急通信链路，不应机械套用“端到端加密”而忽略 PSAP 是否可解密；必须在保密、完整性、可路由性和救援中心接收能力之间形成协议级论证。

UN R155 要求制造商建立并维持网络安全管理体系（CSMS），识别和管理车辆生命周期网络安全风险，持续监测并处理攻击/漏洞；R156 对软件更新管理体系（SUMS）和更新过程提出要求。它们是型式批准和整车制造商管理体系层面的法规要求。ISO/SAE 21434 可以提供工程方法和证据，但不等同于一张可替代 R155 型式批准的证书。

11. ASPICE 4.0：让安全与法规工作可追溯、可复现

Automotive SPICE 4.0 由 VDA QMC 于 2023 年发布，是过程参考模型/评估模型，不是强制法规，也不直接证明 eCall 产品安全。它的价值在于把法规条款和安全目标转成可执行的系统/软硬件需求，保持双向追溯，控制供应商接口、版本、变更和问题解决，提供设计评审、集成验证、系统验证及发布证据。

对 eCall 供应链，建议把触发策略、MSD 字段、通信配置、证书和密钥、基带固件、PSAP 测试端配置作为受控工件。每次变更需记录影响分析，识别需要重跑的 HARA/TARA、回归测试、无线认证、型式批准扩展及网络运营商互操作试验。ASPICE 目标能力等级由客户、采购合同和项目风险决定；不能把“达到 CL2”写成满足 ISO 26262 或 R155 的充分条件。

12. 大融合：一份事故场景，多条独立论证，共用一条证据主线

真正的“大融合”不是把 ASPICE、ISO 26262、ISO/SAE 21434、R155/R156、GB 强制标准和 CRA 合并成一个模糊的“总认证”。合理做法是让它们围绕同一车型、同一软件/硬件版本和同一运行场景共享需求、接口、配置与测试记录，同时保留各自的风险方法、适用范围、责任主体和批准结论。


证据视角	需要回答的 eCall 问题	共享的项目工件 / 验证证据
市场准入与产品结果	目标车型在目标国家要把呼叫送到哪里？要符合哪一版产品/型式要求？	市场/车型矩阵、法规条款映射、PSAP/运营商接口、型式试验与批准记录。
ISO 26262 功能安全	漏触发、延迟、误触、断电或状态误报会造成什么危险？	Item 定义、HARA、安全目标、故障响应需求、故障注入/电源/状态验证。
ISO/SAE 21434 网络安全	位置欺骗、拒绝服务、密钥滥用、诊断/OTA 攻击如何影响求救能力？	TARA、网络安全需求、可信启动/密钥控制、漏洞与网络安全案例。
ASPICE 4.0 过程能力	需求、设计、实现、测试和问题关闭能否双向追溯且可复现？	需求基线、架构/接口、版本配置、变更影响、评审、测试结果与缺陷闭环。
更新与整车管理	OTA、供应链组件或网络配置变更会不会破坏紧急功能？	R155/CSMS、R156/SUMS、GB 44495/44496、ISO 24089 更新流程与回滚验证。
数据与 CRA 边界	紧急数据由谁接收、为何需要、保留多久？产品是否落入 CRA？	数据流/权限/保留矩阵、隐私评估、CRA 产品边界意见、事件与漏洞报告责任。

图 5　同一个复杂事故场景驱动不同标准视角，并汇入车型级安全与网络安全论证；量产后的误报、失呼和漏洞再反馈到变更管理。

用一个组合故障场景检查融合是否真的落地：车辆发生严重碰撞，主电源中断，GNSS 最近一次定位已过时，LTE/IMS 注册首轮失败，而某软件分区正处于 OTA 更新。HARA 应解释备用电源、任务监控、有限重试、语音/MSD 状态和驾驶员提示的安全目标；TARA 应分析定位欺骗、拒绝服务及不可信更新如何阻断求救；型式和网络互操作试验要覆盖信号恢复、MSD 有效性及呼叫中心可见状态。

ASPICE 负责让每项措施落到受控需求、接口、软件/硬件版本、验证用例和问题关闭记录。R156、ISO 24089 与 GB 44496 的更新流程应证明 eCall 分区能在更新失败后恢复到可工作版本；R155/GB 44495 的 CSMS 机制负责监测在役漏洞并评估影响车型。法规型 eCall 与品牌救援中心若并存，还要分别验证公共应急路径是否独立成立、服务中继失败时如何处理。

项目不必把所有文件装进一份巨型报告，但应建立统一证据索引：每条法规要求或风险控制都有唯一标识，能链接到设计实现、软件/硬件配置、验证结果、责任人和在役处置方式。这样可以复用测试与工件，避免重复劳动；同时让每个标准、市场和批准路径的结论仍可单独审查。

13. 全球法规落地：车型批准、系统证据与数据治理分开管理

中国：eCall 强制国标与整车网络安全国标并行

GB 45672—2025《车载事故紧急呼叫系统》于 2025 年 4 月 25 日发布，实施日期为 2027 年 7 月 1 日，是中国 eCall/AECS 产品要求的重要强制基线。当前公开的技术解读与认证规划主要聚焦 M1、N1 类车型；项目仍须以正式标准正文和主管部门实施口径确认车型分类、适用范围、试验细节及同一型式判定，不能只依据市场宣传材料规划型式试验。当前应把触发、定位、通信、数据、测试条件和救援接收接口尽早转成需求和证据计划。

GB 44495—2024《汽车整车信息安全技术要求》和 GB 44496—2024《汽车软件升级通用技术要求》均已于 2026 年 1 月 1 日实施。它们分别把整车信息安全和软件升级纳入中国强制要求。eCall 若运行于整车 T-Box、共享计算平台或 OTA 体系内，必须通过车型级安全架构和更新流程把紧急呼叫功能一并覆盖；同时遵守个人信息保护、数据安全和汽车数据治理规则，保持紧急事件数据的最小化、授权和可审计。

欧盟与 UNECE：NG eCall、网络安全和更新批准组合适用

欧盟 112 eCall 的基本法规框架是 Regulation (EU) 2015/758；授权法规 2024/1180 将分组交换/IMS 纳入迁移路径：2026 年起新型 M1/N1 准入支持分组交换，2027 年起新车生产节点继续转换，并设有后续合格证有效性的过渡安排。授权法规 2025/1871 更新型式试验方法，强调自检故障模式分别测试、周期检验可测性、备用电源验证和技术中立的试验设计。ETSI 2026 技术报告已引用 EN 17184:2024+A1:2026、EN 17240:2024+A1:2026 等版本；但标准更新版不自动等于法律引用版，具体审批必须按当时有效的法规附件、车型节点和批准机构口径核对。

接警侧也须同步升级：新建 PSAP 自 2024 年 5 月起支持分组交换 eCall，既有 PSAP 的转换节点为 2026 年 1 月；传统电路交换仍需在成员国至少有一个 2G/3G 网络运行期间继续支持。德国电信公开披露其网络自 2023 年 12 月具备 NG eCall 测试准备，并在 2025 年行业验证中开放真实网络；ETSI 2026 年活动又在斯洛文尼亚真实 4G 网络测试 IVS—PSAP 互操作。它们是部署与验证进展，不等同于所有国家、所有运营商和所有车型均已完成端到端商用验收。

UN R144 是事故紧急呼叫系统（AECS）的联合国型式批准规则之一；其适用取决于缔约方实施与市场准入安排。UN R155/R156 则分别聚焦网络安全与软件更新的管理体系和车辆型式批准。不要把“通过 R144 测试”误当成已满足 NG eCall IMS 互操作，也不要把“满足 R155”误当成产品 eCall 功能通过型式批准。目标国家、车型类别、审批路径和受理机构要逐项目确定。

CRA：2026 年报告义务已启动，但先做产品边界判断

欧盟《网络韧性法案》（CRA）主要义务自 2027 年 12 月 11 日起适用；主动遭利用漏洞和严重安全事件的报告义务已从 2026 年 9 月 11 日开始。对落入 CRA 范围的制造商，需在知悉后 24 小时内提交早期预警、72 小时内提交通知；主动遭利用漏洞的最终报告应在纠正措施可用后 14 天内提交，严重事件的最终报告通常应在 72 小时通知后一个月内提交。关键边界是：CRA 第 2 条对适用 Regulation (EU) 2019/2144 的数字产品设有排除。整车或受车辆型式批准法规覆盖的产品不能一概按消费电子产品重复套用 CRA；但独立销售的产品、软件或服务是否属于排除范围，要逐项按产品定义、上市方式和法规关系判断。

若产品落入 CRA，漏洞处理、支持期限、技术文档和市场监管义务要纳入产品生命周期；报告对象还需建立单一报告平台操作准备。不能因某个车载部件进入汽车供应链，就自动断言其所有相关软件或云端服务均被排除。边界结论应形成书面法规适用性分析，并与 R155、整车型式批准和合同责任进行交叉映射。

美国等市场：重视本地应急链路，不假定全球统一号码和平台

全球 eCall 并非一套号码、一种数据格式即可通用。美国常见自动碰撞通知（ACN）由车厂或服务商的呼叫中心接收，再联系当地 911 与应急资源；与欧盟 112 公共应答点架构不同。其他市场在紧急号码、PSAP 能力、运营商路由、数据字段、隐私规则、型式批准和网络代际上也存在差异。全球平台可以复用安全架构和工程过程，但须对每个市场维护法规配置、MSD 映射、网络配置和端到端验收证据。

图 6　中国、欧盟 eCall 与汽车网络安全法规关键时间节点。CRA 仅在产品落入其适用范围时触发对应义务。

14. 一套能通过审查、也能在路上工作的项目实施路径

对整车厂和供应链，推荐把合规工作拆成可审计的阶段门，而不是临近 SOP 再补材料：

·市场与责任边界：明确 M1/N1 等车型类别、销售国家、法规版本、型式批准路径、PSAP/呼叫中心接口和数据控制者/处理者责任。

·系统定义与风险分析：冻结 item、接口和运行场景；分别完成 HARA、TARA 与隐私/数据流分析；把风险控制转成有责任人和验证方法的需求。

·架构与供应商控制：确定 LTE/5G IMS 基线、区域网络配置、定位策略、主/备供电、故障隔离、密钥与更新机制；对模组、天线、SIM/eSIM、云服务和测试设备建立接口协议。

·集成验证与型式试验：按需求追溯执行触发、定位、网络注册与切换、MSD、双向语音、断电、碰撞后性能、自检、故障注入、互操作和地区法规测试；确认 PSAP 测试流量不会误入真实报警队列。

·量产及在役治理：运行漏洞监控、事件响应、软件物料清单、服务支持期、版本回滚、运营商退网迁移、召回/缺陷处置和数据访问审计。重大变更应评估重新试验或批准扩展。

最小可行的证据包至少包括法规适用性矩阵、系统架构和接口控制文件、双向需求追溯、HARA/TARA、隐私与数据流分析、软硬件验证记录、端到端 PSAP/运营商互操作报告、型式试验报告、配置基线、供应商交付物、OTA/漏洞处置流程和量产后监控方案。证据应能说明每个安全目标和法规要求由什么设计实现、在哪个版本上验证、出现失败时如何处置。

结论：把 eCall 当作一项持续运营的安全服务

LTE/IMS 已进入真实互操作验证，5G/NTN 仍需条件成熟。车厂与芬兰案例表明，救援终点、误报、回退和数据治理决定系统是否可用。项目应以同一事故场景串联型式批准、HARA/TARA、ASPICE、更新与在役响应，证明求救信息最终到达可响应的应急服务。

eCall大安全融合服务解决方案添加微信：nalanqiguan 或扫描二维码

【声明】内容源于网络