P09 · YBO Control — 船外 Air 的控制应用与协议集成平台：智能家居协议评估
- 治理摘要：PRODUCT-PLAN P9；T2。
1. 定位与层级
章节标题：“1. 定位与层级”Mate 是船用有线方案的内部控制：Hub、YBO CAN、Core 与 Mate 云构成船上的闭环。Air 无线开关不限于船——它可以卖到住宅、房车/车辆、小型商业空间等船以外的场合（示例，不是市场规模主张）。YBO Control 就是 Air 在船外的产品形态：Air → Air Hub（网关）→ 外部断路器/继电器；Air Hub 同时把 Air 作为无线开关接入 Matter、Apple Home、Home Assistant 等生态，并可经自有云或与第三方云互通。Control 与 Mate 互补，不替代。
三条硬要求来自本次立项，是所有候选协议的淘汰线：
| 要求 | 含义 |
|---|---|
| 离线优先 | 现场无互联网时，App、Air 与生态的全部本地控制可用；控制环路中不存在云节点 |
| 安全隔离 | 逐设备/逐 App 身份；任何第三方生态层触达不到 Air 绑定与执行器链路的授权点之下，也绕不过 Air Hub 上的策略点 |
| 本地可拒绝远程 | 现场可以拒绝或锁死一切来自场外的控制；锁只能在现场解除，并对所有远程通道（自有云、生态云、云对云）同时生效 |
2026-09-11 追加的两条产品要求：
| 要求 | 含义 |
|---|---|
| 作为无线开关加入生态 | Air 能以无线开关身份进入 Matter、HomeKit（Apple Home）、Home Assistant OS 等生态，由生态把按键绑定到它自己的设备 |
| 自有云或与第三方互通 | Control 可以有自有云；也要能与第三方生态/云双向互通——Air 控制第三方设备，第三方也能控制 Air Hub 管理的回路 |
1.1 前提修正
章节标题：“1.1 前提修正”立项描述是"Air 与 CAN 支持外部控制，支持 MQTT 和 Wi-Fi"。受控文档的现状是：
- Air Hub（原 Air Gateway） §2 只推荐 BLE + CAN（STM32G0B1CE + nRF54L15），"无强制云或 Wi-Fi"；执行目标只有 YBO CAN 上的 Core；Matter 控制器/桥接/Thread 边界路由、Wi-Fi 与"网关 + 第三方执行器"独立套件列为另行评审的扩展（§5）。
- 船内的 Wi-Fi、MQTT 上行与本地 Web UI 是 P03 Hub 的能力（FR-07/08/10）。
- 计划 20260911-1919（草案，未批准；其更名与不休眠决定已由任务 20260911-1916 落入工作树）比较了 Air Hub 改为 Linux + 双 ESP32-C6（Wi-Fi 6 / 802.15.4 / Matter）的方案。这就是"Air 支持 MQTT 和 Wi-Fi"所指的方向。
因此，船外产品要求 Air Hub 具备 IP 上行与执行器接口——这是对 Air Hub 规格的新依赖（CTL-O-11），本文记录但不改动 P05；船内则由 P03 Hub 承载同一套 Control 服务作为可选项。
1.2 与既有产品的边界
章节标题：“1.2 与既有产品的边界”| 场景 | 产品组合 | Control 的角色 |
|---|---|---|
| 船外（住宅、房车/车辆、小型商业空间等） | Air 与/或有线 Key + Air Hub + Control App；执行器为第三方断路器/继电器（或直流安装中的 Core） | 整个产品：执行器控制、策略点、生态桥接、App、可选自有云 |
| 船内 | Core / Sense / Key / Air + Hub + Studio + Mate | 可选的生态暴露层，运行在 P03 Hub 上；Mate 的远程开关经 Control 策略点路由（CTL-O-04） |
| 产品 | 拥有 | 不拥有 |
|---|---|---|
| Control（本文） | Air Hub 到外部执行器的控制协议、本地控制 API 与 App、远程否决策略的执行点、面向第三方生态的桥接层、可选自有云、控制审计的本地来源 | Air 无线准入与绑定（Air Hub 固有）、船内配置 schema（Studio）、船舶管理（Mate） |
| Mate | 船用云、遥测时间线、船舶管理、订阅 | 船外产品 |
| Studio P07 | 船内唯一配置 schema：通道、绑定、"可远程"回路标记 | 船外配置——由 Control App 承担（CTL-O-13） |
| Hub P03 | 船内 Linux 桥硬件、本地 Web UI、连接管理器、N2K/MFD | 生态桥接协议（由 Control 定义，在 Hub 上运行） |
| Air Hub P05 | Air 无线准入、绑定、CAN 转发与加密回读 | 对外 IP 协议与执行器接口——船外产品对它的新要求见 CTL-O-11 |
| X01 / X02 | CAN 应用层与配置模式 | 不因 Control 新增加密或改动帧语义 |
现有平台准则原样继承：UI 只渲染设备已确认的回读、约 5 s 无回读回退并提示、每个控制项标注写入目标、每次远程/自动操作审计（PRODUCT-PLAN §1 控制面准则）；保护逻辑在执行器本地，不依赖 Control。
2. 派生需求
章节标题：“2. 派生需求”淘汰线之外，候选方案还要满足从平台准则和现有安全模型推出的需求。ID 前缀 CTL-；本文为需求提出，冻结在 Level-1 规格。
| ID | 需求 | 来源 |
|---|---|---|
| CTL-01 | 本地控制在现场网络（Wi-Fi/BLE/以太网/RS-485）上完成；互联网不可达时功能不降级 | 离线优先 |
| CTL-02 | 控制环路中的每一跳都有逐设备或逐 App 身份；不存在共享密钥 | PRODUCT-PLAN §3 安全规则 |
| CTL-03 | 第三方生态层（Matter 桥、MQTT 集成、云对云）只能到达 Air Hub 上的策略点；不得直接驱动执行器、不得读取 Air 绑定/密钥；船内还不得产生原始 CAN 帧 | 安全隔离；Air Hub GW-01 |
| CTL-04 | 现场存在本地锁：一经启用，来自自有云、生态层与云对云的所有写入被拒绝并审计；只能在现场（物理按键或已认证的本地会话）解除。船内实例即 Mate SFR-18 的舵位锁 | 本地可拒绝远程 |
| CTL-05 | 每条回路声明 local / remote / bridged 标记；未标记的回路不出现在任何远程或生态视图中。安全相关回路默认只允许 local |
PRODUCT-PLAN §P7 护栏 |
| CTL-06 | 远程指令携带过期时间与幂等键；过期指令记录不执行 | Mate SFR-20 |
| CTL-07 | 只渲染执行器确认的回读；无回读不报成功 | 控制面准则 |
| CTL-08 | 场外不开放任何入站端口；远程访问只经云中继 | Hub FR-10 |
| CTL-09 | 生态层与执行器的入网（commissioning）需要现场物理动作或已认证的本地会话，入网窗口有界 | Matter 安全模型；Air Hub SEC-01 |
| CTL-10 | 每次控制写入（本地、生态、云、云对云）审计：来源身份、回路、动作、结果、时间质量；生态来源记录 fabric/控制器身份 | 控制面准则 |
| CTL-11 | 生态协议栈与执行器协议栈在 Air Hub 上作为独立进程/隔离域运行，崩溃或被攻破不影响 Air 准入与本地 App 控制 | 安全隔离 |
| CTL-12 | 所有对外协议为 EU/CN/NA 三个发布区域都有可用的生态端点；不依赖在某个区域不可用的云 | PRODUCT-PLAN §3 区域矩阵 |
| CTL-13 | 每类外部执行器必须有确认回读通道（协议属性订阅、线圈读取或辅助触点）；没有回读的执行器只能标为"未知状态"，不得报成功 | 控制面准则；追加要求 |
| CTL-14 | Air 的每个按键以标准无线开关设备类型暴露给生态，手势（短按/长按/双击）映射为标准事件；生态在自己一侧完成绑定 | 追加要求 1 |
| CTL-15 | 第三方对 Air Hub 回路的控制与 Air 对第三方设备的控制都经策略点；云对云路径同样受本地锁与过期规则约束 | 追加要求 2 |
| CTL-16 | 船外的有线输入形态：Key 面板经 CAN 挂 Air Hub（GW-06），与 Air 走同一策略点和同一回读准则；此形态没有 Core，Air Hub 的可用性同时决定有线开关的可用性 | 2026-09-12；见 SW-O-01…03 |
3. 系统位置与硬件前提
章节标题：“3. 系统位置与硬件前提” 船外： Air ──BLE──►┌────────────────── Air Hub ──────────────────┐──Matter 控制器 / Modbus 主站 / 继电器输出──► 外部断路器 / 继电器 │ Air 准入 │ 策略点（本地锁/白名单）│ 本地控制 API │ │ │ │ 生态桥接 │◄── 生态控制器（Apple/Google/Alexa/HAOS/米家 hub，现场 LAN） └──────────┴────────────────────────┴─────────────┘◄── 本地 App（Wi-Fi/BLE）；可选自有云（mTLS，出站）
船内（可选）：同一 Control 服务运行在 P03 Hub 上，执行器为 YBO CAN 上的 Core，远程经 Mate 云中继。| 硬件路径 | 承载的接口 | 对本文的影响 |
|---|---|---|
| 船外：Air Hub（带 IP 上行与执行器接口）——计划 1919 方案 F 的 Linux ARMv7 + 双 ESP32-C6（Espressif 产品页：2.4 GHz Wi-Fi 6、BLE 5、802.15.4，可做 Matter Wi-Fi/Thread 端点）或等价方案；RS-485 与继电器输出按 CTL-O-11 决定 | Wi-Fi/以太网、BLE、802.15.4；可选 RS-485、干接点 | 船外产品的必需宿主：Matter 控制器 + 桥、可选 Thread 边界路由、Modbus 主站、继电器输出都在这里；控制路径经 Linux 时需要与 P03 相同的失效准则声明（计划 1919 §F 已记录） |
| 船内：P03 Hub（i.MX93 + Murata Type 2EL / NXP IW612：Wi-Fi 6、BLE 5.4、802.15.4—Hub 设计附录 §2） | Wi-Fi、BLE、802.15.4、RS-485、2× CAN | 船内可选运行同一 Control 服务作生态暴露层；执行器是 CAN 上的 Core |
| Air Hub 基础版（STM32G0B1CE + nRF54L15，Nordic 产品页：BLE、802.15.4、Matter，Wi-Fi 需 nRF70 伴随芯片） | BLE、802.15.4、CAN | 没有 Wi-Fi 与执行器接口；不能承载船外产品；只能做 Matter over Thread 端点，本文不把它作为 Control 宿主 |
结论：船外产品要求 Air Hub 带 Wi-Fi/以太网并至少提供一种执行器接口；无论宿主是 Air Hub 还是船内 P03 Hub，本文的协议选择不变。
4. 候选协议逐项评估
章节标题：“4. 候选协议逐项评估”每项按同一提纲：它是什么 → 身份与安全模型 → 离线与云依赖 → 本地否决可实现性 → 隔离 → 认证与成本 → 区域与硬件 → 结论。§4.1–4.11 评估"Air 与 Air Hub 用什么协议进入用户与生态"，§4.12 评估"Air Hub 用什么协议控制外部执行器"。
4.1 Tuya（涂鸦）
章节标题：“4.1 Tuya（涂鸦）”- 是什么：以涂鸦云为中心的设备平台。TuyaOS 提供设备 SDK、Tuya App/OEM App、云 API；TuyaOS Matter 在其上集成官方 Matter SDK，并提供 Matter Bridge SDK。
- 身份与安全：设备身份、激活、证书签发与生产测试都在涂鸦体系内完成（TuyaOS Matter 页面："signed certificate service for Matter devices" 与涂鸦生产/测试系统集成）。身份归属在涂鸦，不在 YBO。
- 离线与云依赖：局域网控制文档 说明"已激活并接入路由器的设备"可由 App 经 UDP 广播发现后建立 TCP 连接，默认最多 3 个 App 同时连接；激活（首次入网）本身经涂鸦云。公开文档未说明 LAN 会话的认证与密钥分发方式，本文按"密钥由云分发"处理（未核实）。社区项目（如 tuya-local）依赖从云取得的本地密钥，也印证这一点。
- 本地否决：策略点在涂鸦 App/云，YBO 无法在 Air Hub 上定义"现场锁死远程"的语义；OEM App 的远程路径就是涂鸦云。
- 隔离：TuyaOS 运行在设备 MCU 上并直接映射数据点（DP），要做到 CTL-03 需要把 TuyaOS 限制在隔离的协处理器上，等于自建策略点后再挂一个涂鸦壳。
- 认证与成本：涂鸦平台费用与 OEM App 费用未收集（未核实）。
- 区域与硬件：中国与全球市场均有；涂鸦芯片/模组绑定其 SDK。
- 结论：不作为核心。身份与远程路径都不在 YBO 手里，与"安全隔离、本地可拒绝远程"直接冲突。若需要覆盖使用涂鸦 App 的用户，经 Matter 暴露（TuyaOS Matter 页面明确涂鸦 App 可作为 Matter 控制器加入第三方 Matter 设备）即可，不需要 TuyaOS。
4.2 Matter
章节标题：“4.2 Matter”- 是什么：CSA（Connectivity Standards Alliance）的 IP 应用层标准；传输为 Wi-Fi、Thread、以太网，BLE 用于入网（CSA Matter 页面）。最新版本 Matter 1.6，2026-06-17 发布（CSA 新闻）；1.4 加入能源管理与家用路由器（CSA），1.5 加入摄像头与闭合类设备（CSA）。
- 身份与安全（Silicon Labs Matter 安全基础）：入网用 PASE（SPAKE2+，设备二维码中的 setup passcode）；运行时用 CASE（每个 fabric 的节点操作证书 NOC）；设备出厂带 DAC，链到 PAI 与 PAA，PAA 根证书与认证记录在 CSA 的分布式合规账本 DCL；每个节点有 ACL，按 fabric/主体授权。多管理员：设备至少同时支持 5 个 fabric（Home Assistant Matter 文档）。
- 离线与云依赖：协议本地运行，"Matter products run locally and always allow local control, with device control done without the need for any internet connection or cloud services"（Home Assistant Matter 文档）。远程访问由各生态自己的 hub 与云提供：Apple 需要 HomePod/Apple TV 作家庭中枢，Alexa 以 Echo 作 Matter 管理员并本地控制（Amazon 开发者文档），Google 由 Nest 设备本地执行（Google Home 开发者文档）。
- 无线开关设备类型：Matter 的 Generic Switch 设备类型基于 Switch 簇（0x003B），瞬时开关支持 InitialPress、LongPress、MultiPress 等事件（Matter Handbook 设备类型、esp-matter generic_switch 示例）；Home Assistant 把多击拆成
multi_press_1/2…事件类型（HA PR #122191）。Air 的短按/长按/双击可以直接映射。各生态对 Generic Switch 事件的自动化支持程度不一，须逐生态验证（CTL-O-14）。 - 本地否决：这是 Matter 的关键局限——Air Hub 看不出一条命令是现场手机发的还是用户在外经 HomePod/Echo 中继的，因为 Matter 的发送方永远是现场 LAN 上的那台生态 hub。因此 Matter 层上的否决只能是：本地锁启用时拒绝整个生态层的写入（返回失败，状态保持回读）；未标记"可桥接"的回路根本不出现在 fabric 里；安全相关回路永远不桥接。这满足 CTL-04/05，但代价是"锁远程"在生态层等于"锁生态"。
- 隔离：Matter 桥模型天然是一个 Aggregator 端点加若干代表被桥设备的端点（Bridged Device Basic Information 簇），被桥设备的协议对 fabric 不可见（Nordic Matter Bridge 文档）。Air 绑定、密钥与执行器链路都留在 Air Hub 内，符合 CTL-03。
- 认证与成本（CSA 会员页，2026-09-11 所载）：Adopter $7,500/年，产品认证 $3,000/件、衍生 $2,500；Participant $21,500/年，认证 $2,000/件；Associate $0/年，仅可通过认证转移计划贴牌已认证产品（$2,500/件 + $500/年）。此外需要 DAC 签发链（自建 PAA 或购买 PAA 服务）与授权实验室测试，费用未收集 (t)。控制器角色的认证要求见 §4.12。
- 区域与硬件：Apple/Google/Amazon 生态在中国不可用，但 Matter 本身在中国有 Aqara（Hub M100：Zigbee/Thread/Matter，Notebookcheck 报道，厂商公告，未逐一核实）、小米与涂鸦的控制器；EU/NA 生态齐全。IW612 与 ESP32-C6 都可承载 Matter over Wi-Fi/Ethernet 与 Thread 边界路由。
- 结论：采用，两个角色：(1) 桥——Air Hub 把每个 Air 按键暴露为 Generic Switch 端点、把它控制的回路暴露为 On/Off / Dimmable / Plug-in Unit 端点，一次认证进入 Apple/Google/Alexa/SmartThings/HA/米家/涂鸦；(2) 控制器——Air Hub 自持 fabric、配网第三方 Matter 断路器/继电器（§4.12）。不把 Air 做成原生 Matter 设备：那会破坏 Air 的 BLE 电池基线，并给每个硬件 SKU 增加 $3,000 认证；船内也不把 Core/Key 做成 fabric 成员（CTL-03）。
4.3 Thread
章节标题：“4.3 Thread”- 是什么：基于 IEEE 802.15.4 的 IPv6 低功耗网状网络层；Thread 本身不定义应用层，应用层由 Matter、KNX IoT 等提供（Thread Group 概览）。Thread 1.4（2024-09 白皮书，Thread Group PDF）加入多边界路由凭据共享、Thread over Infrastructure、标准化互联网路径与诊断。
- 对本文的意义：Thread 不是与 Matter/Tuya 并列的"平台"选项，而是"Air 或第三方设备用什么无线到达 Air Hub"的传输选项。自有 Air 的基线是 BLE（nRF54L15，Air 指南），三年电池预算按 BLE 连接-按下模式核算；把 Air 改成 Thread 睡眠终端（SED/SSED）需要重新核算电池、天线与覆盖，且 Air 就变成 Matter 节点（见 4.2 结论）。船外的第三方 Matter 执行器多为 Wi-Fi 或以太网（§4.12），Thread 执行器需要 Air Hub 提供边界路由。
- 硬件：IW612、ESP32-C6、nRF54L15 都带 802.15.4，边界路由器在 Hub/Air Hub 上可行。
- 结论：只作为传输选项保留：当 Air Hub 带 802.15.4 时，提供 Thread 边界路由以接入 Thread 执行器与第三方设备；不用于自有 Air。是否进入首版在 CTL-O-03 冻结。
4.4 Zigbee
章节标题：“4.4 Zigbee”- 是什么：CSA 的 802.15.4 网状协议，hub 中心、本地运行。Zigbee 4.0 与 Suzi（sub-GHz 800/900 MHz）于 2025-11-18 发布，Suzi 认证计划 2026 上半年开放（CSA 新闻）。
- 评估：本地、无云；但没有跨生态的 IP 应用层——接入 Apple/Google 仍要经 Matter 桥（Aqara、Hue 的做法）。作为 YBO 自有终端的无线会在 Air 上再加一套协议栈，与 BLE 单一硬件平台的决定冲突；作为执行器接入层（涂鸦类 Zigbee 智能断路器），要在 Air Hub 上再跑一个协调器栈，且与 Matter 相比没有生态收益（§4.12）。
- 结论：不采用。第三方 Zigbee 设备的接入交给用户侧控制器（Home Assistant）或 Matter 桥厂商。
4.5 Z-Wave / Z-Wave Long Range
章节标题：“4.5 Z-Wave / Z-Wave Long Range”- 是什么：Z-Wave Alliance 的 sub-GHz 协议；现行规格包 2026A，会员登录后下载（Z-Wave 规格页）。Z-Wave LR 为星形拓扑，最多 4,000 节点、最远 1.5 英里（Z-Wave LR 页面）；频率按区域不同（美/欧各异，本页未列，未核实）。
- 评估：本地、hub 中心、认证严格；但区域频段分立、芯片来源集中（Silicon Labs 700/800 系列，未核实其他来源）、在中国几乎没有生态，且同样需要经 Matter 桥才能进入手机生态。
- 结论：不采用。
4.6 HomeKit（HAP）
章节标题：“4.6 HomeKit（HAP）”- 是什么：Apple 的 HomeKit Accessory Protocol。Apple 明确：分发或销售的 HomeKit 配件需加入 MFi 计划；Matter 配件则经 CSA 认证，Apple Home 自 iOS 16.1 起原生支持 Matter（Apple Developer）。
- 评估：HAP 只覆盖 Apple；Matter 覆盖 Apple 加其余生态。Air 作为无线开关进入 Apple Home 的路径是 Matter Generic Switch 端点（4.2），Apple Home 在自己一侧把按键绑定到场景与配件；远程与自动化需要 HomePod/Apple TV 作家庭中枢。
- 结论：不采用 HAP，经 Matter 进入 Apple Home（满足追加要求 1 的 HomeKit 项）。
4.7 Home Assistant
章节标题：“4.7 Home Assistant”- 是什么：开源本地控制器（Home Assistant OS）。作为 Matter 控制器时经独立 Matter server 进程运行、完全本地（HA Matter 文档）；Thread 边界路由经 OpenThread Border Router + Connect ZBT-1/ZBT-2；MQTT 发现：设备向
<discovery_prefix>/<component>/[<node_id>/]<object_id>/config发布保留配置即可自动出现，支持 switch/light/sensor/binary_sensor/lock/cover 等 39 种以上组件、可用性主题，broker 连接支持 TLS 与客户端证书。 - 评估：对安装商、改装客户与自建集成的用户，HAOS 是事实上的开放控制器；Air 作为无线开关进入 HAOS 有两条路：Matter Generic Switch 端点（HA 原生映射多击事件），或本地 MQTT 发现的
device_automation/事件实体。HA 也能直接订阅 Air Hub 的本地 MQTT 读回路状态。HA 的远程访问由用户自己负责（Nabu Casa 或自建），不进入 YBO 的责任边界——但也意味着 HA 层上的否决同样只能是"生态层整体"。 - 结论：作为首个开放集成目标（满足追加要求 1 的 HAOS 项）：Air Hub 发布 HA MQTT 发现负载；同时 HA 作为 Matter 桥与 Generic Switch 的参考控制器用于验证。
4.8 纯 MQTT 约定（Homie / HA discovery / 自有主题）
章节标题：“4.8 纯 MQTT 约定（Homie / HA discovery / 自有主题）”- 是什么：不是生态，而是本地 API 的组织方式。Homie 5 定义设备/节点/属性模型与
+/5/+/$state发现、支持子设备（桥）；HA discovery 见 4.7；Mate §5.2 已定义ybo/v1/<vessel>/<device>/telemetry|event|alarm|audit|cmd|cmd/ack|config|ota主题、QoS 1、last-will 在线状态。 - 评估：自有主题模型已经存在并与船用云侧一致；在 Air Hub 的本地 broker 上原样使用（
<vessel>泛化为站点 ID），App 与 Air Hub 之间不需要第二套语义；自有云（§6 C）沿用同一模型。Homie 与 HA discovery 只作为输出适配，不替换自有模型。 - 结论：本地控制核心采用自有 MQTT 主题模型 + mTLS（沿用 Mate 的定义），另发布 HA discovery；Homie 不实现。
4.9 KNX IoT
章节标题：“4.9 KNX IoT”- 是什么：KNX 协会的 IPv6 传输层（Thread/Wi-Fi/Ethernet），CoAP + CBOR，沿用 KNX S-mode 语义；官方开源栈 KNX IoT Point API Stack v1.0.0 于 2026-03 发布（KNX 协会、Cascoda 指南）。
- 评估：楼宇自动化生态，ETS 配置、KNX 认证与会员费；商业楼宇与超级游艇集成商会用 KNX，但它不是手机生态，也没有本地否决的语义。
- 结论：不采用；若项目要求，另行评估 KNX 网关。
4.10 生态端点（不是平台选项）
章节标题：“4.10 生态端点（不是平台选项）”| 生态 | Air 作为无线开关的进入方式 | 第三方控制 Air Hub 回路 | 远程访问 | 区域 | 备注 |
|---|---|---|---|---|---|
| Apple Home | Matter Generic Switch（CSA 认证） | Matter 桥端点 | 需 HomePod/Apple TV 作中枢 | EU/NA；CN 可用但无本地云 | HAP 不需要（4.6） |
| Google Home | Matter；Nest 设备本地执行（Google） | Matter 桥端点；二期可加云对云 | 经 Google 云 | EU/NA；CN 不可用 | Works with Google Home 流程（未收集费用） |
| Amazon Alexa | Matter；Echo 为 Matter 管理员本地控制（Amazon） | Matter 桥端点；二期可加 Works with Alexa 云对云 | 经 Amazon 云 | EU/NA；CN 不可用 | WWA 认证另行提交 |
| Samsung SmartThings | Matter 控制器/hub | Matter 桥端点 | 经 Samsung 云 | EU/NA | 未核实细节 |
| 米家 / Aqara | Matter 控制器（Aqara M100 等） | Matter 桥端点；二期可加米家云对云 | 经小米/Aqara 云 | CN 为主 | 厂商公告，未逐一核实 |
| 华为 HiLink / 鸿蒙 | 未核实 Matter 支持范围 | — | — | CN | 待 CTL-O-06 |
| 涂鸦 App | Matter 控制器（4.1） | Matter 桥端点 | 经涂鸦云 | CN/全球 | 不使用 TuyaOS |
| Home Assistant OS | Matter Generic Switch 或 MQTT 发现 | Matter 桥端点或本地 MQTT | 用户自理 | 全球 | 4.7 |
所有生态的远程访问都是它们的云，YBO 既不掌握也不负责；对现场而言它们一律按"远程"处理（§7）。
4.11 现有船用基线：NMEA 2000 与 Modbus
章节标题：“4.11 现有船用基线：NMEA 2000 与 Modbus”MFD（Garmin/Simrad/Raymarine）经 N2K 数字开关 PGN 127501/127502 控制，Victron GX 互通，Modbus RTU 面向工业变体——均已在 PRODUCT-PLAN §1/§3 与 Hub 中定义，由 Hub 承担。它们是船内有线/总线生态，不在本文的手机/智能家居范围内，但受同一策略点约束：舵位锁启用时 MFD 控制页面是否同样被拒，是 CTL-O-05 的问题。Modbus 在船外的角色反过来：Air Hub 作主站控制工业继电器（§4.12）。
4.12 执行器侧集成：Air Hub 如何控制外部断路器与继电器
章节标题：“4.12 执行器侧集成：Air Hub 如何控制外部断路器与继电器”船外没有 Core，Air 的目标是第三方断路器/继电器。候选按 CTL-13（回读）与三条硬要求评估：
| 候选 | 是什么 | 回读 | 离线 | 身份与安全 | 隔离与本地否决 | 认证与成本 | 结论 |
|---|---|---|---|---|---|---|---|
| Matter 控制器角色 | Air Hub 自持 fabric，配网 Matter 认证的继电器/断路器。市面已有：Shelly 1 Gen4 / 1PM Gen4 干接点继电器（Wi-Fi、Zigbee、Matter，Shelly）、Shelly Pro 1PM 40A Gen4 作为首个 DIN 导轨 Matter 模块（matter-smarthome 报道，厂商公告）；其他厂商的 Matter DIN 断路器待收集 | ● On/Off 属性订阅，标准 | ● 本地 | ● DAC 认证执行器、CASE 会话 | ● 执行器只在 Air Hub 的 fabric 内；本地锁在策略点执行 | 控制器/commissioner 软件不像设备那样被审核（NIST 分析）；CSA 对运行在受支持环境上的软件组件（含控制器）有认证程序——Air Hub 控制器是否须认证待 CTL-O-12；YBO 自担配网 UX 与 fabric 管理 | 首选 |
| Modbus RTU/TCP 主站 | 工业 DIN 继电器、电动 MCB、IO 模块；RS-485 已在平台内（Hub、Key 变体） | ● 线圈/寄存器读取 | ● 本地 | ◐ Modbus 无认证，靠物理总线隔离；TCP 变体需网段隔离 | ● 从站只挂在 Air Hub 的总线上 | 无协议认证；Air Hub 需 RS-485 口（CTL-O-11） | 工业/机柜场景采用 |
| Air Hub 自带干接点/继电器输出 | 无协议，直接驱动接触器线圈或分励脱扣器 | ◐ 需辅助触点或电流检测输入 | ● | ● 物理 | ● | Air Hub 需继电器/IO 扩展（CTL-O-11）；执行器侧电气安全归安装规范 | 兜底 |
| Zigbee 协调器 | 涂鸦类 Zigbee 智能断路器 | ● | ● | ● | ● | 再加一套栈，厂商互操作参差 | 不采用 |
| 厂商本地 API（Shelly RPC/MQTT 等） | 逐厂商本地 HTTP/MQTT | ● | ● | ◐ 逐厂商 | ◐ | 逐厂商维护 | 仅作过渡 |
| 厂商云 API | 经执行器厂商云 | ◐ | ○ | ○ | ○ | — | 不采用（违反离线优先） |
三条协议可以并存：同一 Air 按键绑定到 Matter 继电器、Modbus 线圈或本机继电器输出，对 Air 与 App 都是"一条回路"。安全相关回路（总开关、断路器分励脱扣）默认只允许 local，并且必须有回读（CTL-05/13）。
5. 对比矩阵
章节标题：“5. 对比矩阵”● 满足 / ◐ 部分满足或需 YBO 自建 / ○ 不满足 / — 不适用。"执行器控制"指 Air Hub 用该协议驱动外部断路器/继电器；"无线开关进入生态"指 Air 以该协议成为生态里的开关。
| 候选 | 离线控制 | 云依赖 | 身份与加密 | 本地否决 | 隔离 | 执行器控制 | 无线开关进入生态 | 认证与成本 | EU / CN / NA | 硬件适配 | 锁定风险 | 结论 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 自有本地 API（MQTT/mTLS） | ● | ● 无 | ● 自有 PKI | ● 语义自定 | ● | — 经策略点 | ○ 仅 HA | ● 无外部认证 | ● / ● / ● | ● | ● 无 | 核心 |
| Matter（桥 + 控制器） | ● | ● 协议无；生态远程经其云 | ● DAC/CASE/ACL | ◐ 只能整层拒绝 | ● 桥模型 | ● 控制器角色 | ● Generic Switch | ◐ $7.5k/年 + $3k/件 + PAA；控制器认证待定 | ● / ◐ / ● | ● | ◐ CSA 规则 | 执行器 + 生态层 |
| Modbus RTU/TCP | ● | ● | ◐ 无认证 | ● 策略点 | ● 物理 | ● 工业继电器 | — | ● 无 | ● / ● / ● | ◐ 需 RS-485 | ● | 工业场景 |
| 本机继电器输出 | ● | ● | ● 物理 | ● | ● | ◐ 回读需辅助触点 | — | ● 无 | ● / ● / ● | ◐ 需 IO 扩展 | ● | 兜底 |
| Thread | ● | ● | ● 网络层 | — | — | ◐ 经 Matter | — 传输 | ◐ Thread Group 会员 | ● / ● / ● | ● 802.15.4 | ○ | 传输选项 |
| Tuya / TuyaOS | ◐ LAN 需云激活 | ○ 激活、身份、远程均在涂鸦 | ◐ 归涂鸦 | ○ | ○ 需自建隔离 | ◐ 经涂鸦云/DP | ◐ 涂鸦 App | ◐ 未核实 | ● / ● / ● | ◐ 绑定其模组 | ○ 高 | 不采用 |
| Zigbee 4.0 | ● | ● | ● | ◐ | ◐ | ● 需协调器栈 | ◐ 需再经 Matter | ◐ CSA | ● / ● / ● | ● | ◐ | 不采用 |
| Z-Wave / LR | ● | ● | ● | ◐ | ◐ | ● 需控制器芯片 | ◐ 需再经 Matter | ◐ 会员制规格 | ◐ / ○ / ● | ○ 无芯片 | ○ | 不采用 |
| HomeKit HAP | ● | ● | ● | ◐ | ◐ | — | ◐ 仅 Apple | ◐ MFi | ● / ◐ / ● | ● | ○ | 不采用 |
| Home Assistant OS | ● | ● | ◐ 用户自理 | ◐ 整层 | ● | ◐ 用户侧 | ● Matter 或 MQTT | ● 开源 | ● / ● / ● | ● | ● | 首个集成 |
| KNX IoT | ● | ● | ● | ◐ | ◐ | ◐ 楼宇执行器 | ○ | ◐ KNX 认证 | ● / ◐ / ◐ | ● | ◐ | 不采用 |
矩阵反映本文证据日期的判断；"◐ 只能整层拒绝"是 Matter/HA 路径的结构性局限，不随版本变化。
6. 推荐方案
章节标题：“6. 推荐方案”推荐三个并列方向加一个本地核心，全部运行在 Air Hub（船内为 P03 Hub）上；标为推荐，在 PRODUCT-PLAN §6 第 12 项 冻结。
| 方向 | 内容 | 协议 |
|---|---|---|
| 核心 · 本地控制 | 本地 broker + 策略点 + 本地控制 API；自有 App 首先走这一层（Wi-Fi 或 BLE），互联网不可达时全部可用 | 自有 MQTT 主题模型（沿用 Mate ybo/v1/...，<vessel> 泛化为站点）over mTLS；App 身份在现场入网时签发 |
| A · 执行器集成 | Air Hub 作控制器驱动外部断路器/继电器：Matter 控制器角色优先（标准、多厂商、本地、属性回读）；Modbus 主站接工业继电器/电动 MCB；本机继电器输出兜底。三者并存，对 Air 与 App 都是"回路" | Matter over Wi-Fi/Ethernet（可选 Thread 边界路由）；Modbus RTU/TCP；干接点 |
| B · 作为无线开关加入生态 | Matter 桥：每个 Air 按键一个 Generic Switch 端点（短按/长按/多击 → Switch 簇事件），Air Hub 控制的回路再暴露为 On/Off / Dimmable / Plug-in Unit 端点；多 fabric 让 Apple Home、Google Home、Alexa、SmartThings、HAOS、米家、涂鸦控制器并存；HAOS 另有本地 MQTT 发现 | Matter 桥；HA discovery |
| C · 自有云与第三方互通 | 可选 YBO 云中继给 Control App 远程与多站点管理（沿用 Mate 规则：出站 mTLS、逐设备 X.509、无入站端口、指令过期/幂等）；双向互通——第三方经 B 控制 Air Hub 回路，Air 经生态自身绑定或经 A 控制第三方设备；云对云（Works with Alexa / Google Home / 米家云）记为二期，因为多一跳云仍须过本地锁 | 自有 MQTT over mTLS；生态云对云 API（二期） |
不采用：TuyaOS、Zigbee、Z-Wave、HAP、KNX IoT 作为平台；Air 不做原生 Matter 设备（备选：若做，可省去船外 Air Hub 由生态 hub 直接驱动断路器，但打破 Air BLE 电池基线并逐 SKU 认证，且失去策略点——记录，不采用）；船内 Core/Key 不做 fabric 成员。
为什么不是"只做 Matter"：Matter 层无法区分本地与远程来源，也不承载 YBO 的角色、审计与本地锁语义；自有 App 若只经 Matter，就要依赖某个生态 hub 才能远程。为什么不是"只做自有 API"：那样每个生态都要单独接入，而 Matter 一次认证覆盖全部主流控制器，并且给出了执行器侧的多厂商标准。
7. 平台架构与本地否决机制
章节标题：“7. 平台架构与本地否决机制”7.1 策略点
章节标题：“7.1 策略点”所有写入（本地 App、Air 按键、生态层、自有云、云对云、自动化）在 Air Hub 上汇入同一个策略点，再进入执行器驱动。策略点按顺序判定：
- 回路是否允许该来源：逐回路标记
local/remote/bridged（CTL-05）。安全相关回路只允许local。 - 本地锁（CTL-04）：启用时拒绝一切
remote与bridged来源；local来源（现场 App、Air 按键）不受影响。状态存 NVM，重启保持；只能由现场物理按键或已认证的本地会话解除；启用/解除本身审计。船内实例为舵位锁。 - 远程通道开关：独立于本地锁的持久开关，分别关闭"自有云"、"生态层"与"云对云"——用于长期离场或交付前把现场"下线"。
- 指令有效性：过期时间与幂等键（CTL-06）；重复或过期指令记录不执行。
- 执行与回读：经 Matter/Modbus/继电器输出（船内经 X01）下发，只有执行器回读才向来源报告成功（CTL-07/13）；生态层在被拒时返回失败并保持原状态，不出现乐观渲染。
7.2 安全边界
章节标题：“7.2 安全边界”| 边界 | 两侧 | 机制 |
|---|---|---|
| B1 | 执行器链路 ↔ Air Hub | 只有 Air Hub 的执行器驱动进程持有 Matter 控制器 fabric、Modbus 总线或继电器输出；船内只有 CAN 转发进程持有总线，X01 不新增加密（IF-01） |
| B2 | Air Hub ↔ 本地 App | mTLS，逐 App 证书在现场入网时由 Air Hub 签发，入网需物理确认；证书可在现场撤销 |
| B3 | Air Hub ↔ 生态 fabric（桥角色） | DAC 证明 Air Hub 身份；入网窗口由物理按键打开且有界（CTL-09）；每个 fabric 独立 NOC 与 ACL；fabric 可在现场移除 |
| B4 | Air Hub ↔ 自有云 | 出站 mTLS MQTT、逐设备 X.509、无入站端口；云侧指令签名与过期 |
| B5 | 生态栈 / 执行器栈 ↔ 策略点 | 各协议栈为独立进程/容器，只能调用策略点 API（CTL-11）；不可见 Air 绑定与密钥 |
| B6 | 自有云 ↔ 第三方云（云对云，二期） | 第三方经 OAuth 类授权访问自有云的回路 API；自有云把请求作为 remote 来源下发，本地锁与过期规则照常 |
7.3 App 定位
章节标题：“7.3 App 定位”自有 App 是 Control 的一部分：船外承担全部——回路与执行器配置（CTL-O-13）、Air 绑定、本地控制、本地锁与远程通道开关、生态入网（打开 Matter 入网窗口、展示配对码；作为控制器配网执行器）、本地审计查看、可选云账号。船内则只做生态暴露层的操作面，远程监控、时间线与船舶管理留在 Mate；两者是否合并为一个应用外壳是 CTL-O-07。
8. 安全、隐私与合规
章节标题：“8. 安全、隐私与合规”| 主题 | 规则 |
|---|---|
| RED 网络安全 | 委托法规自 2025-08-01 强制适用；EN 18031-1/-2/-3:2024 为协调标准（CEN-CENELEC）。Air Hub 作为联网无线设备按 COMPLIANCE-MATRIX Hub 行的同类路径评估；Control 增加的对外接口（Matter 桥与控制器、Modbus、本地 API、云）纳入同一评估。船外为消费/商业市场，无船用标准，但执行器侧的电气安装规范由断路器/继电器厂商与安装方负责 |
| CRA | 漏洞与事件报告义务自 2026-09-11 起（Mate §7 已记录）；Control 的 SBOM 须包含 Matter SDK（桥与控制器）、broker、Modbus 栈与云组件 |
| CSA 认证 | Matter 桥需 CSA 会员与产品认证（§4.2 费用）、DAC 签发链、DCL 记录；控制器角色认证待 CTL-O-12；Works with Google Home / Alexa 等生态认证另行 |
| Thread Group | 若启用边界路由，边界路由器认证与会员费另行（未收集） |
| GDPR / 数据驻留 | 本地 App 与 Air Hub 不上传个人数据；自有云按区域托管（EU 沿用 Mate 的 EU 托管；CN 需境内托管，CTL-O-15）；生态层的远程访问由各生态的隐私政策覆盖，YBO 在用户文档中说明 |
| 审计 | 本地审计仅追加，容量与掉电语义沿用 Air Hub §2 的 4096 条目标核算方式，具体值在 Level-1 冻结 |
9. 成本与商业挂钩 (t)
章节标题：“9. 成本与商业挂钩 (t)”| 项目 | 数值或状态 |
|---|---|
| CSA 会员 | Adopter $7,500/年（官方页面，2026-09-11） |
| Matter 桥认证 | $3,000/件（Adopter）；Air Hub 作为一个产品认证，Air 不单独认证 |
| Matter 控制器认证 | 是否需要待 CTL-O-12；若需要，作为软件组件认证另计 (t) |
| PAA/DAC、实验室测试 | 未收集 (t) |
| 生态认证（Google/Alexa/Apple/米家） | 未收集 (t)；云对云集成另计 |
| Thread Group 会员/认证 | 未收集 (t)；仅在启用边界路由时发生 |
| 自有云 | 托管与运维按站点数计 (t)；是否与 Mate 共用租户见 CTL-O-15 |
| 商业模式 | 本地 App、执行器集成与 Matter 桥随 Air Hub 提供，不订阅；自有云远程与多站点是否付费、生态云对云是否付费是 CTL-O-08 |
10. 验证计划
章节标题：“10. 验证计划”| 阶段 | 项目 | 方法 | 通过判据 |
|---|---|---|---|
| 原型 | 执行器控制与回读 | Air 按键 → Air Hub → Matter 继电器（Shelly Gen4 级）、Modbus 继电器、本机继电器各一路 | 三路均可控；只有回读到达后 App/生态显示成功；回读延迟 P50/P99 记录 |
| 原型 | 离线控制 | 断开 WAN，用本地 App、Air、HAOS、Apple Home（经 HomePod）操作已桥接回路 | 全部可控 |
| 原型 | 无线开关进入生态 | Air 作为 Generic Switch 加入 Apple Home、Google Home、Alexa、HAOS、米家，各绑定一个生态自有设备 | 短按/长按/多击在各生态可触发自动化；不支持的手势逐生态记录（CTL-O-14） |
| 原型 | 本地锁穿透 | 启用本地锁，从 Apple/Google/Alexa/HAOS/自有云各发一次写入 | 全部被拒并审计；本地 App 与 Air 仍可控；生态 UI 不显示乐观状态 |
| 原型 | 回路白名单 | 未标记 bridged 的回路 |
不出现在任何 fabric 与 HA 发现中 |
| 原型 | 隔离 | 对 Matter 桥、控制器、Modbus 与本地 API 输入做模糊测试；生态栈进程被杀 | 无越权执行器动作；Air 准入与本地 App 不受影响 |
| DVT | 入网安全 | 无物理动作尝试入网（桥与控制器两侧）；fabric 移除后重放旧 NOC | 入网被拒；重放被拒 |
| DVT | 多 fabric | Air Hub 同时加入 5 个控制器，并同时作为控制器持有自己的 fabric | 状态一致；移除任一 fabric 不影响其余 |
| DVT | 云对云（若二期启用） | 经第三方云控制回路 | 本地锁与过期规则生效；审计标明云对云来源 |
| DVT | 认证预评估 | CSA 测试工具、EN 18031 差距审查 | 无开放入站端口；差距有责任人 |
| DVT | 区域 | CN 侧用 Aqara/米家控制器与境内云验证 | 与 EU/NA 相同用例通过 |
11. 待决事项与依赖
章节标题：“11. 待决事项与依赖”| ID | 事项 | 门槛 |
|---|---|---|
| CTL-O-01 | 船内宿主：Control 生态暴露层运行在 P03 Hub 还是 Air Hub；两者都要满足 CTL-11 的隔离 | 计划 1919 决定后 |
| CTL-O-02 | Matter 设备类型映射：断路器、总开关、船用回路（舱底泵、航行灯）没有专用设备类型，用 On/Off Plug-in Unit / Light 表示是否会误导生态 UI 与语音；是否只桥接舒适性回路 | Level-1 规格 |
| CTL-O-03 | Thread 边界路由是否进入首版；目标是 Thread 执行器与第三方设备接入，不是自有 Air | Air Hub 硬件冻结后 |
| CTL-O-04 | Mate P08 的远程开关路径改为经 Control 策略点；需另开任务修改 P08 §2/§4 | 本文批准后 |
| CTL-O-05 | 舵位锁是否同样拒绝 MFD（N2K PGN）与本地 Web UI 的写入；本地 Web UI 视为 local 的条件 |
Level-1 规格 |
| CTL-O-06 | 中国生态端点核实：米家、Aqara、华为鸿蒙对第三方 Matter 桥与 Generic Switch 的支持范围与限制 | CN 发布前 |
| CTL-O-07 | 自有 App 与 Mate App 是否共用一个应用外壳 | Mate alpha 前 |
| CTL-O-08 | 商业模式：自有云远程/多站点、生态云对云是否付费；CSA/生态认证费用摊入 Air Hub BOM 还是订阅 | COMMERCIAL-MODEL 更新 |
| CTL-O-09 | 本地 App 入网流程（B2）与 Air Hub 已授权维护会话的关系：是否共用同一入网工具 | Air 指南 D0 |
| CTL-O-10 | 执行器清单与逐类回读方式：Matter 继电器/DIN 模块（型号、认证状态）、Modbus 继电器/电动 MCB（寄存器映射）、分励脱扣器（辅助触点）；哪些类别允许 remote |
Level-1 规格 |
| CTL-O-11 | Air Hub 船外变体：Wi-Fi/以太网上行、RS-485、继电器/IO 扩展、Matter 控制器所需资源——对 P05 Air Hub 规格的新要求，需经任务 1916/计划 1919 的所有者纳入 | Air Hub D0/D1 |
| CTL-O-12 | Matter 控制器角色是否须 CSA 软件组件认证；自建 PAA 还是购买 DAC 服务 | CSA 会员后 |
| CTL-O-13 | 船外配置模型：Studio 的 X02 schema 是否泛化到船外（回路、执行器、绑定、local/remote/bridged 标记），还是 Control App 自带精简 schema |
Level-1 规格 |
| CTL-O-14 | 各生态对 Generic Switch 手势事件的自动化支持（长按、多击）逐生态验证结果 | 原型验证 |
| CTL-O-15 | 自有云范围：与 Mate 共用租户还是独立；EU/CN/NA 托管与数据驻留；云对云集成的授权模型 | 云技术栈选型（PRODUCT-PLAN §6 第 6 项）时 |
| CTL-O-16 | 船外 Key 形态的回读权威、失效安全表述与支路供电——由 P05 Switch 的 SW-O-01…03 关闭，本文引用其结论 |
D0/D1 |
12. 变更记录
章节标题：“12. 变更记录”| 日期 | 内容 |
|---|---|
| 2026-09-11 | R0.1 首版：新增 P09 Control 产品线的协议评估；推荐自有本地 API + Matter Bridge + HA 集成，Thread 仅为传输选项，Tuya/Zigbee/Z-Wave/HAP/KNX 不采用；记录 Matter 层"只能整层拒绝远程"的局限与本地否决机制 |
| 2026-09-12 | Air 与 Key 合为 P05 Switch 产品线后，船外形态补记有线输入：Key 经 CAN 挂 Air Hub（GW-06），新增 CTL-16 与 CTL-O-16。协议结论、执行器策略与既有 CTL-01…15 不变 |
| 2026-09-11 | R0.2 重新定位：Control 为船外 Air 的产品形态（Air → Air Hub → 外部断路器/继电器），Mate 保持船用有线内控。新增 §4.12 执行器侧集成（Matter 控制器优先、Modbus 主站、本机继电器兜底）、追加要求（作为无线开关加入 Matter/HomeKit/HAOS；自有云与第三方双向互通）、CTL-13…15、Generic Switch 映射、本地锁替代舵位锁、自有云边界 B6、待决项 CTL-O-10…15 |