中国总决赛
全球总决赛
学习进度
待补充
省赛
能力分类
统一互联
能力模型
OpenHarmony统一互联概览
项目介绍
OpenHarmony统一互联项目,致力于解决OpenHarmony系统跨操作系统、跨不同厂家,跟HOS、三方OS的设备可以互通,从建底座、定标准、搭平台三个维度,构筑统一互联的技术底座。
第一阶段先聚焦于OH和HOS之间,以及OH不同设备厂家之间设备的互联互通,包括富对瘦设备控制、富对富投屏、富对富文件互传这3大类应用场景,后续会逐步扩展到业务接续、分布式摄像头,以及和三方OS之间的互联互通。
核心理念
1.统一架构
2.统一标准
3.统一运营
4.统一共建
5.价值场景专项打透
技术架构
略
演进路线
OS组合
OpenHarmony 2B发行版 <-> OpenHarmony 2B发行版 系统原生业务互通能力
OpenHarmony 2B发行版 <-> OpenHarmony 2C发行版HarmonyOS Next 系统原生业务互通能力
OpenHarmony 发行版 <-> Other OS + SDK
备注:优先聚焦①②鸿蒙设备的不同发行版之间基础业务互联互通和标准化,其次和其他OS互通兼容的场景
设备组合
富设备<->瘦设备,1-1和1-n场景
富设备<->富设备,限定1-1基础场景
备注:优先聚焦①行业IOT设备互联控制类场景
业务类型,通过互联互通基础业务标准和认证保证业务兼容性,跨厂商跨行业之间的基本业务互通:
富 <-> 无屏瘦设备:基础IOT业务;业务入口:基础互联APP
富 <-> 有屏瘦设备:基础文件互传,基础业务流转,业务入口:基础互联APP,三方应用
富 <-> 富设备:基础文件互传,基础投屏,基础业务流转等,业务入口:图库/文件/系统投屏,三方应用
互通的传输方式: 近场BLE/BT/WIFI/ETH/星闪SLE/SLB等方式。
OpenHarmony设备互联标准
标准全景

标准的范围主要包括物模型规范、接入与控制接口规范、测试规范、基础投屏规范、文件互传规范、应用接续规范等。
标准简介
物模型规范
本规范规定了以OpenHarmony为系统底座的生态设备的物模型关键设计元素、元素间逻辑配套关系、主要设计原则及元素表达方式等内容。适用于以OpenHarmony为系统底座的各种消费品类设备及各行业生产经营设备的物模型实例化呈现。
起草单位:华为终端有限公司、深圳开鸿数字产业发展有限公司、湖南开鸿智谷数字产业发展有限公司、鸿湖万联(江苏)科技发展有限公司、广东九联科技股份有限公司、山东亚华电子股份有限公司、鼎桥通信技术有限公司、鸿蒙生态服务(深圳)有限公司、诚迈科技(南京)股份有限公司。
接入和控制接口规范
本规范规定了鸿蒙生态设备之间统一的发现、配网、接入认证和控制接口规范,满足不同厂商的鸿蒙生态设备之间能够互联互通互操作。
起草单位:鸿湖万联(江苏)科技发展有限公司、华为终端有限公司、湖南开鸿智谷数字产业发展有限公司、深圳开鸿数字产业发展有限公司、鼎桥通信技术有限公司、广东九联开鸿科技有限公司、山东亚华电子股份有限公司、鸿蒙生态服务(深圳)有限公司。
测试规范
本规范规定了鸿蒙生态设备互联互通互操作业务相关的测试特性和用例,主要包括Wi-Fi、BLE、ETH等类型设备的发现、配网、连接、查询和控制等功能性测试。适用于指导基于OpenHarmony操作系统的生态设备,验证其互联互通互操作业务能力,确保OpenHarmony系统上互联互通组件运行稳定、功能正常,为用户提供便捷、流畅、安全可靠的一致生态交互体验
起草单位:华为终端有限公司、鸿湖万联(江苏)科技发展有限公司、湖南开鸿智谷数字产业发展有限公司、深圳开鸿数字产业发展有限公司、鼎桥通信技术有限公司、广东九联开鸿科技有限公司、山东亚华电子股份有限公司、鸿蒙生态服务(深圳)有限公司。
基础投屏规范
TODO
文件互传规范
TODO
应用接续规范
TODO
物模型规范
术语和定义
1 物模型Thing model
“物模型”,又可称设备模型或数据模型,是对物理设备进行抽象建模后在数字化空间的表达形式。
2 元素Element
元素泛指用于描述设备物模型的各类组成部分,在本文件中包括服务、事件、特征等。
3 特征 Characteristic
特征是指设备具备的某一种能力或当前所处的某个状态。某个特征可以是只读的,即其值不能修改;也可以是可写的,即能被设置为新值。
4 服务Service
服务是由一组特征元素构成的表示设备某个组成部分的逻辑或物理单元。
5 事件Event
事件是设备运行期间在某种条件下主动上报的特定类型信息。一般包含需要被外部感知和处理的通知信息,如故障、告警等。
物模型组成元素与逻辑关系
本章节给出了OpenHarmony设备描述自身能力所需的基本组成元素及彼此间的逻辑关系。如图1所示,用于描述设备物模型的基本组成元素包含服务、事件、特征以及一些“关键信息”。

1) 设备关键信息涵盖的具体内容可参见下表描述
名称 | 英文名称 | 数据类型 | 最大长度/固定长度 | 是否必选 | 说明 |
设备型号ID | prodId | String | 固定长度:5个字节 | 必选 | 对于一款设备来讲,该ID是其在整个OpenHarmony生态产品体系内的唯一标识。其值由设备物模型运营主体统一分配。长度为5个字符。其首字符当前默认取值为1,即“1XXXX”。而其余的后4个字符,每个字符的取值范围是[0-9]或[A-Z]。理论上可提供1679616种取值选项。 |
设备名称 | deviceName | String | 最大长度:255个字节 | 必选 | 通过字符串表示。最长255个字节。 |
设备认证型号 | deviceModel | String | 最大长度:32个字节 | 必选 | 设备厂商用于标识不同型号设备的一段字符串。例如某厂商手表的一些设备型号有GTN-B19、ESA-D20。其长度最长为32个字节 |
设备品类ID | deviceTypeId | String | 固定长度:4个字节 | 必选 | 该ID代表设备的所属种类。其值由设备物模型运营主体统一分配。长度为4个字符。为了与现有OpenHarmony生态设备保持兼容,其首字符默认取值为0,即“0XXX”;而其余的后3个字符,每个字符的取值范围是[0-9]或[A-Z]。理论上可提供46655种取值选项。 |
设备品类名称 | deviceTypeName | String | 最大长度:255个字节 | 必选 | 对应于上一行的“设备品类ID”,该信息表示设备种类名称。最长255个字节。 |
设备制造商ID | manufacturerId | String | 固定长度:3个字节 | 必选 | 该ID是设备制造商在整个OpenHarmony生态产品体系内的唯一标识。长度固定为3个字节。其取值与OpenHarmony社区XTS认证时分配给厂商的ManufactureID值保持一致。 |
设备制造商名称 | manufacturerName | String | 最大长度:255个字节 | 必选 | 对应于上一行的“设备制造商ID”,该信息表示设备制造商名称。最长255个字节。 |
2)除了“设备关键信息”之外,设备物模型还可包含其他两类元素,即“服务”与“事件”。“服务”代表了设备的某个组成部分,可以表示一个独立的逻辑或物理业务单元。其中包含了外部可访问的相关信息或能力。设备物模型中至少应提供一类“服务”;“事件”是设备运行期间在某种条件下主动推送或上报到外部的特定类型信息。在设备物模型中可以不提供任何事件,也可以提供多个事件。
3)服务是物模型模块化设计理念的体现。同一服务类型在多个不同设备对象中“可复用”。另外,在一个设备对象中可以包含同一服务类型的多个实例。
4)“特征”是“服务”及“事件”对外呈现信息或体现具体能力的基本承载单元。外部可以读取某个特征携带的数据来获得设备的相关状态,也能通过修改某个特征的取值来驱动设备执行某个动作。一类“服务”至少应该包含一个“特征”;一种“事件”可以不含任何“特征”,也可以包含多个“特征”。