如果你正在梳理 CarPlay 的认证路径，大概率已经被一堆缩写淹过一轮了。iAP2、Facets 3、MFi、PPID、P.1100，这些代号本身不是难点，难点在于它们之间的关系：哪个规范管哪一层，哪个测试检哪一项，你的产品走哪条路决定了你碰哪套流程。这三层逻辑搞清楚，代号就不再是乱码。
有个前提得先讲明白：CarPlay 的技术规范不公开。不像 EN 或 FCC Part 15 那样有标准号可以下载，所有核心文档都锁在苹果的保密体系里，你得签 NDA、成为 MFi 注册会员，才能从 MFi Portal 下载。网上能搜到的任何公开内容，包括这篇，都只能给你搭个框架，具体的参数阈值和判定准则必须以苹果保密文档为准。这篇的作用是让你进了 Portal 之后能快速定位，而不是替苹果发布规范。
四份文档，各有各的管辖区
CarPlay 认证的技术依据不是一份"CarPlay 标准"，是四份文档叠在一起，每份管的层面不同。
最底层那份叫 Accessory Interface Specification，圈内一般叫 iAP2 规范。它定义苹果设备跟外设之间的通信协议：连接怎么建、会话怎么维持、数据怎么传、出了异常怎么恢复。不管你的产品走 USB 有线还是蓝牙加 Wi-Fi 无线，数据链路层都跑在 iAP2 上。这份文档版本迭代很快，2026 年对外商用认证活跃版本在 R26 到 R29 之间。内部测试版偶尔会冒出更高版本号，但从没用于正式商用判定，不用追。实际项目里最该关注 iAP2 的是硬件工程师，他画原理图、选芯片的时候本质上就是在遵守 iAP2 的底层规矩。如果负责画板子的人没读过这份规范，做出来的东西想合规基本不可能。
在 iAP2 之上叠了一份 CarPlay Accessory Addendum，专门管车载场景的专项要求。车辆启动和熄火时 USB 口行为有什么差异、车载电源波动时 iAP2 链路怎么保活、车机屏幕分辨率和触控采样率的下限是多少，这些在通用 iAP2 里不写，由 Addendum 单独定义。逻辑也简单：CarPlay 不是在桌面上插着用的，汽车里的电磁环境、电源波动和温湿度条件比桌面恶劣得多，你的产品得在这种环境下维持稳定。
第三份是 Certification Guide，管流程的。从提交 PPID 申请到最终出结果，每一步走什么节点、交什么材料、按什么准则判定，全在这份文档里。它更新很频繁，实际项目里最常见的翻车原因之一就是拿两三年前的旧版 Guide 来排当前项目的流程，到提交才发现苹果现行要求已经变了。还有一个大变化要记住：2023 年到 2025 年初，苹果分阶段用 Facets 3 替掉了旧版测试系统，到 2026 年 Facets 3 是唯一授权的认证测试平台。它做了账号联动、测试用例自动生成、结果实时上传和自动判定，基础合规项的人为解读空间基本没了，只有异常边界场景还保留人工复核。指望靠人工判定把技术缺陷救回来，这条路已经堵死了。
第四份是 Self-Certification Test Cases，自认证用例集，列的是产品送实验室之前需要自己跑通的全部测试场景。2025 年底这版有个大更新，无线 CarPlay 的覆盖范围扩了很多。但这里有个机制很多人没注意到：Facets 3 实际给你生成的测试用例，不是只看这份用例集，它是 Certification Guide、用例集、加上你在 PPID 阶段填的 CarPlay Configuration Record 三样联合算出来的。Configuration Record 已经迭代到 R3，是一份产品配置问卷。你在里面申报了什么功能，Facets 3 就给你裁出什么测试矩阵。这不是固定题库，是动态的。如果你申报时故意少填功能想省事，到真测的时候实际功能超出了申报范围，面临的不是补测而是合规问题，得不偿失。
测试维度跟着功能走
CarPlay 的测试不是所有产品跑同一套清单，哪些维度被触发完全取决于你申报了什么功能。
硬件电气和信号完整性是所有产品的准入门槛，Facets 3 会查 USB 信号质量、供电稳定性，无线方案还要查蓝牙 BLE 的发现和配对。这关一票否决，硬件电气不过后面全没资格启动。有个常见误解得澄清一下：有线 CarPlay 不需要先拿 USB-IF 的 Embedded Host 认证和 TID。CarPlay 里的 USB 电气测试遵循苹果自有的通用 MFi 配件电气规范，USB-IF TID 在苹果审核流程中不是强制前置条件。当然 USB-IF 认证在别的市场合规场景里有用，很多地区也认，但那是另一回事，别跟苹果的审核流程混在一起。
iAP2 协议栈完整性是覆盖最广的维度。Facets 3 自动跑完整套 iAP2 测试，链路建立断开、角色协商、会话管理、数据传输速率、异常恢复，全流程。有线无线都要过。无线方案在这个维度里会额外叠加蓝牙和 Wi-Fi 的协同测试，从 BLE 发现配对到切换到 Wi-Fi 数据通道的整条过渡链路都要验。过渡过程的时延和丢包率是无线方案在这里最容易挂的地方。目前主流架构是车机端做 Wi-Fi AP、iPhone 做 STA，也有部分合规方案支持 Wi-Fi Direct 直连。选哪种角色配置直接决定硬件选型和测试准备方向，不是能临时改的。另外提一句，iAP2 over BLE 是 iAP2 整体测试框架的一个子集，不是单独的大项，别被名字吓到。
用户体验和功能交互这块，Facets 3 会模拟用户操作来检验。触控跟不跟手，旋钮和方向盘按键映射对不对，音频通道切换顺不顺（比如导航提示音插进来时音乐音量会不会自动降），Siri 从触发到响应的时间在不在阈值内，CarPlay 界面和车机原生界面在来电等场景下谁优先。大部分用例 Facets 3 自动跑，涉及主观体验的边界场景还得人工辅助判定。
语音通信质量在声学暗室里测。人工头模拟驾驶员位声学环境，对车载麦克风阵列逐帧检测。参照框架是 ITU-T P.1100（窄带）和 P.1110（宽带），P.1110 在 2025 年 10 月发了更新版，苹果的参照阈值可能跟着调了。但苹果不是照搬 ITU 值，它在这个框架上叠加了自定义的车载语音指标和回声衰减、降噪专项阈值，实际通过标准可能比 ITU 原文档更严。测试分安静场和噪声场两轮，是综合多维度的评分体系，不是拿一个信噪比数字判生死。任何一个指标超标，整个维度直接不合格。
实车路测这个维度经常被误读。后装配件、无线转接盒、嵌入式模块都不需要路测，台架过了就能拿认证。只有整车厂前装的完整车机项目才需要上预设路线跑，验证 GPS 接收、实车无线干扰、行驶振动对连接的影响。别一上来就把路测的预算和排期都排进去，很多品类根本碰不到。
如果你的产品支持无线连接，还有个无线 CarPlay 专项维度是强制加考的。用例数量不固定，Facets 3 根据 PPID 申报的功能裁剪。全功能高端机型大概对应十几个标准 Wi-Fi 测试项，功能精简的产品会少一些。检的是车载端在 Wi-Fi AP 模式下的连接稳定性和抗干扰能力。
五条通道，各自有各自的规矩
同样叫 CarPlay 认证，不同产品走的通道、审查重点、附加要求差得很远。产品归属搞错了，策略、预算、排期全偏。
OEM 前装车载主机是量级最大的一类。整车厂在车型开发阶段把 CarPlay 嵌进原装车机，认证跟具体车型绑定。这个通道覆盖基础版 CarPlay 和 CarPlay Ultra。Ultra 是苹果的正式品牌名，2025 年 5 月苹果新闻稿原文就是 "CarPlay Ultra, the next generation of CarPlay"，网上很多人叫它"CarPlay 2.0"，但苹果自己的文档和页面没用过这个词。两者共享核心规范，但 Ultra 涉及多屏联动、仪表盘投射、车身控制这些深度定制功能，有独立的补充附录和更多测试用例。到 2026 年 Ultra 还在跟少数高端车企试点，远没到大规模量产。前装通道今年有个新增审查重点：DSM，也就是驾驶状态监测接口，验证比以前严了。配了驾驶员监测摄像头和毫米波雷达的车型，传感器数据要通过标准化接口传给 CarPlay 系统，用来根据驾驶员注意力状态调交互策略。这个在硬件设计阶段就得预留接入端口和计算资源，定型后再补成本极高。另外面向欧洲市场的 Ultra 项目，ISO 21434 汽车网络安全工程标准已经成了关联合规要求，尤其涉及 CAN 总线数据交互的场景。
后装车载主机面向存量旧车市场。车主原来没 CarPlay，换一台后装主机来升级。走标准 MFi 配件认证流程，不跟车型绑定，一台主机一张证。跟 OEM 通道最大的硬件区别是：后装必须部署 MFi 认证芯片，也就是苹果认证协处理器。DSM 接口这块审查相对松，但屏幕式中控如果要高级交互功能，还是得跟苹果确认。
CarPlay 无线适配器是个小盒子，插到原车有线 CarPlay 的 USB 口上把有线转无线。苹果把它归为 Accessory 外设而不是车机主机，所以对 iAP2 链路拓扑和协议透传逻辑的审查比普通车机严。任何对原车机和 iPhone 之间 iAP2 链路结构的篡改或透传逻辑的修改，直接导致认证判定失效。不是通过率低的问题，是规则本身红线更严。前置条件有几个：无线延迟 30 毫秒以内，BQB 蓝牙认证和 Wi-Fi 认证必须先拿到。面向中国市场的产品还要看 GB 44495-2024，这份国标管汽车整车信息安全里的数据隔离和权限控制，跟苹果生态准入是两条独立线，证书互不认可，排期要协同。
CarPlay 嵌入式模块面向设备制造商，是解决方案级产品。模块拿了认证只代表核心协议部分过了合规验证，下游车机厂把认证模块集成进整机之后，还要走整机集成测试和变更评估。模块认证的作用是缩减下游测试范围，不是豁免整机认证。这个误解在实际项目里太常见了，模块过了不代表整机自动合规。
最后是 CarPlay 应用，唯一不碰硬件的品类。App 开发者不用加入 MFi 计划，在 developer.apple.com 申请对应类别的 CarPlay 权限就行。到 2026 年，Apple Developer 页面列的 CarPlay 应用方向有音频、视频、通信与 VoIP、导航、充电、加油、停车、公共安全、快速点餐、语音交互、驾驶任务、汽车制造商应用。通过标准 entitlement 流程能申请的类别至少 9 个，各有独立的 entitlement �识符，汽车制造商应用走独立通道。选对类别、守功能限制是获批前提。
有两条 Apple 的硬底线提一下。通信和消息类应用在 CarPlay 端只能用 Siri 语音朗读和语音回复，严禁任何手动文字输入，没有商量余地。充电、加油、快速点餐这些轻交互类应用可以显示信息和接受预约，但所有支付流程必须回到 iPhone 完成，CarPlay 界面上不能跑任何支付环节。
有线和无线可以合并
同一块硬件同时支持有线和无线的话，不用拆两次认证。在同一个 PPID 下把功能完整申报上去，Facets 3 会把两套测试用例合并执行。双模式车机和适配器都适用。
收尾
CarPlay 认证的规范体系、测试维度、产品通道三层逻辑理顺了，iAP2、Facets 3、PPID 这些代号就各自有了坐标。iAP2 是底层协议基石，Addendum 叠车载专项要求，Certification Guide 管流程，自认证用例集配合 PPID 问卷联合生成测试矩阵，这些文档全在苹果保密体系里，得先成为 MFi 会员。产品功能配置决定哪些测试维度被激活，有线有必考项，无线加考专项，DSM 是 2026 年前装新增重点。五条产品通道各有各的审查重点和准入条件，先确认归属再定策略。你的认证路径，就能从一堆信息碎片变成一条能执行的时间线。
