做NG eCall认证，材料准备是最容易被低估的环节。很多企业觉得"把产品送去实验室测就行了"，结果卡在技术文件上——描述和实际产品对不上、该有的文档缺了好几份、IMS信令流程图画得像教科书但没有覆盖实际实现中的异常处理逻辑。这些问题被发现的时候，往往已经浪费了两三周的等待时间。
这篇文章把NG eCall认证需要的材料拆开来讲，同时说清楚证书拿到之后的有效期和后续义务。不是列一个材料清单就完事，而是重点讲每份材料在审核中容易被挑毛病的点。
前面几篇反复说过这个问题，这里从材料的角度再明确一次。
NG eCall型式批准走的是(EU) 2015/758框架，技术要求依据(EU) 2017/79和(EU) 2024/1180。如果设备中包含独立无线电发射模块（比如作为独立产品销售的通信模组），还需要做CE-RED（2014/53/EU）。两条路径对材料的要求有重叠但不完全相同，型式批准偏重功能验证和IMS协议一致性，CE-RED偏重射频和EMC。
以下主要讲型式批准路径的材料。CE-RED路径需要额外准备的技术文件（射频测试报告、EMC测试报告、无线电频谱使用说明等）会在相关位置单独说明。
二、NG eCall型式批准需要的核心材料
1.产品技术规格书
这是整份技术文件的基础，其他所有材料都围绕这份文档展开。
技术规格书需要覆盖的内容包括：产品型号和版本号（必须和实际送检样品完全一致）、产品功能描述（eCall手动触发、自动触发、MSD数据传输、IMS语音通话）、通信能力（4G/5G制式、支持频段）、定位方式（GNSS星座支持、定位模式）、硬件架构（处理器、通信模组、GNSS模块、备用电池）、软件架构（IMS协议栈实现方案、eCall应用层软件版本）。
最容易被挑毛病的地方有两个：一是型号/版本号和样品不一致——企业内部开发过程中改了版本但文档没更新，审核的时候对不上；二是功能描述只写了"支持什么"，没有写"怎么实现"，审核方需要看到足够的技术细节来判断方案的合理性。
2.系统架构说明
这份材料主要描述eCall系统的整体架构，特别是IMS通信链路。
需要覆盖的内容：系统框图（从eCall触发按钮到PSAP的完整信号链路）、IMS注册流程（SIP REGISTER消息交互序列、鉴权过程）、紧急呼叫建立流程（SIP INVITE、SDP协商、RTP媒体建立）、MSD数据传输流程（在SIP INVITE或INFO消息中承载MSD的方式）、语音通话路径（AMR-WB语音编解码在IMS架构下的实现）。
这里有一个容易犯的错：直接从ETSI标准文档里截图流程图贴上去，但实际产品的实现和标准流程有差异（比如某些可选字段没有实现、注册超时处理逻辑不同）。审核方对比测试报告和文档时一旦发现不一致，会打回来要求修改。系统架构说明应该反映的是你的产品实际怎么做的，而不是标准怎么规定的。
3.IMS信令一致性说明
这是NG eCall型式批准中技术含量最高的部分。测试依据是EN 17184:2024（系统应用层协议）和ETSI TS 103 128系列（IMS信令一致性测试规范）。
需要准备的材料：IMS协议栈选型说明（自研还是模组厂提供）、IMS注册流程的详细实现描述、SIP消息格式说明（REGISTER、INVITE、BYE、INFO等关键消息的字段配置）、SDP协商参数说明、紧急呼叫路由策略、IMS重注册和异常恢复机制。
如果用的是模组厂家提供的IMS方案，需要拿到模组厂家的IMS一致性测试报告或合规声明。但这不能完全替代整机层面的测试——即使模组层面通过了IMS测试，T-Box整机层面的IMS一致性仍然需要验证。
4.定位性能相关材料
定位测试依据法规(EU) 2017/79的要求，验证设备在不同场景下的定位精度。
需要准备的材料：GNSS方案说明（支持的星座和频点、单星座/多星座模式）、定位算法说明（冷启动、温启动、热启动策略）、定位精度说明（CEP 95%在开阔区域和城区场景下的预期表现）。
法规对开阔区域CEP 95%要求50米以内、城区场景150米以内。不强制多星座融合——单GNSS星座单频模式（至少包括Galileo和GPS）下能达标也是合规的。但测试时需要验证设备在单星座单频模式下的实际表现，所以材料中需要覆盖这种模式的方案说明。
5.电路原理图和PCB布局
审核方需要通过电路图确认：射频电路设计合理、天线匹配参数符合要求、备用电池供电回路设计满足法规对断电后续航的要求、ESD防护措施到位（这直接影响EMC测试结果）。
6.软件版本说明
这份材料在NG eCall认证中比传统eCall重要得多。原因很简单：IMS协议栈、eCall应用层、GNSS定位算法、MSD数据编码逻辑都由软件实现，软件版本和认证结果直接绑定。
需要说明：IMS协议栈软件版本和供应商、eCall应用软件版本、GNSS固件版本、通信模组固件版本。这些版本号必须出现在最终的型式批准证书上，后续量产时使用的软件版本必须和证书上的一致，任何重大变更都需要重新评估。
7.风险分析和测试计划
风险分析需要对eCall系统可能面临的故障模式进行系统性的识别和评估：IMS注册失败（网络不可用或超时）、GNSS定位失败（信号遮挡或干扰）、备用电池失效、SIM卡异常等。针对每种风险，说明系统采取的容错措施和降级策略。
测试计划描述的是整个认证测试的覆盖范围和测试方法。通常由检测机构和企业共同确认后作为正式测试的依据。
8.测试报告
这是所有材料的最终落脚点。检测机构完成测试后出具的正式报告，包括：功能测试报告、IMS信令一致性测试报告（EN 17184:2024）、端到端一致性测试报告（EN 17240:2024）、定位性能测试报告、通信性能测试报告、EMC测试报告、环境可靠性测试报告。
注意：测试报告中引用的标准版本必须和当前有效的法规要求一致。EN 17184和EN 17240已经从技术规范（CEN/TS）升级为正式标准（EN），2026年做的认证应该引用EN版本。
CE-RED路径需要的额外材料
如果你的产品（或其中的通信模组）需要同时做CE-RED认证，除了上述型式批准材料之外，还需要准备：
无线电设备技术文件，包括射频参数说明（发射功率、频率范围、调制方式）、EMC测试报告（辐射发射、传导发射、辐射抗扰度、传导抗扰度、ESD）、风险评估文件（RED指令第11条要求，评估设备对健康、安全、网络安全的潜在风险）、用户手册（需包含使用说明和安全注意事项）。
CE-RED路径需要指定欧盟授权代表（EC-REP）。EC-REP不只是一纸文书，它承担着和欧盟市场监管机构对接的法定责任。EC-REP的义务属于CE-RED维度，不属于eCall型式批准维度——这两个认证虽然都涉及EMC等重叠测试内容，但在材料归属上是分开的。
三、NG eCall认证证书有效期和后续义务
1.型式批准证书
NG eCall型式批准证书本身的有效期在法规中没有设定固定的过期时间。但证书的有效性取决于产品持续符合认证时的技术状态。以下几个因素可能导致证书失效：
·产品发生重大变更。如果IMS协议栈版本、eCall应用软件版本、GNSS方案、备用电池设计发生了影响已测试功能范围的变更，需要重新评估是否需要重新测试。
·法规更新。NG eCall法规体系在不断演进——EU 2024/1180引入了新的标准引用和过渡安排，EU 2025/1871进一步修订了(EU) 2017/79的多个条款。如果新法规引入了新的测试要求或修改了已有标准，已获证产品可能需要补充测试。
·企业义务未履行。型式批准要求企业在有效期内持续满足法规义务，包括：配合市场监管部门的抽查、对产品变更进行影响评估、保存技术文件等。
2.技术文件保存
法规要求技术文件保存至产品停产后的十年。这意味着即使产品已经退市了，这些文件也不能销毁。欧盟市场监管部门有权在任何时候要求查阅。
十年保存期的含义是：如果你2026年拿证、产品2032年停产，那么技术文件至少要保存到2042年。涉及的文档包括技术规格书、测试报告、设计图纸、软件版本记录、变更管理记录等。
这个保存义务很多企业容易忽视。尤其是过了几年之后，当初负责认证的人员离职、文档存储介质老化、文档管理系统更换，都可能导致文件丢失。一旦市场监管部门要求查阅而提供不了，后果严重。
3.产品变更管理
证书拿到不是终点。量产过程中的任何产品变更，都需要评估对认证的影响。变更管理的逻辑大致是：
·不涉及已测试功能的变更（比如外壳颜色、非关键元器件替换）——记录在案，不影响证书。
·涉及已测试功能但范围有限的变更（比如软件bug修复、参数微调）——需要评估影响，必要时提交检测机构确认。
·涉及核心功能的变更（比如IMS协议栈更换、定位方案改变、备用电池方案调整）——大概率需要重新测试。
·实际操作中，变更影响评估的边界有时候并不清晰。如果拿不准，建议和检测机构沟通确认，不要自己判断。
CE-RED路径的持续义务
如果产品同时做了CE-RED认证，还需要履行CE-RED的持续义务：EC-REP年费持续缴纳、DoC（符合性声明）持续有效、产品变更需评估对RED合规的影响、技术文件保存十年。
这些义务和型式批准的义务并行存在，但分别属于两个合规维度。型式批准归欧盟各成员国型式批准主管机关监管，CE-RED归市场监管体系监管，检查的侧重点不同。
蓝亚技术深耕汽车电子检测认证领域多年，已为多家企业提供过eCall认证（涵盖传统CS-eCall和NG eCall）的全流程技术服务。从法规解读、技术文件编制**、预测试到正式测试和证书签发，提供完整的认证服务链条。如需进一步沟通可联系蓝亚技术检测认证机构顾问：13632500972（Benson）。
