可视化本体建模
维护类、属性与约束，把建筑领域概念组织成可复用模式。
01 / 产品总体简介
古河 AI-OntologyAI 本体知识平台
古河AI-Ontology把空间、设备、系统、测点与服务关系组织为本体知识，支持可视化建模、关系查询和OWL交换，为设备定位、影响分析与AI Agent提供上下文。
- 可视化本体建模
- 实例与知识图谱
- 语义查询与集成
面向运维团队、知识建模人员与平台实施团队
02 / 产品架构
从领域模式到设备实例，再连接知识应用
- 01
业务对象与资料
整理设备、空间、系统、测点和维护资料，明确编码及知识来源。
- 02
模式层与实例层
以类、属性和约束定义领域模式，具体设备与空间形成实例及关联。
- 03
关系图谱与知识维护
查看对象关系，维护模型版本、一致性及交换资料，按权限管理知识。
- 04
语义检索与 AI 运维
向查询和 AI 应用提供对象上下文，再通过授权工具读取实时数据或进入业务。
03 / 核心功能
AI 本体知识平台的核心功能
设备与空间实例关联
将具体设备、空间、测点和指令对应到统一对象与关系。
知识图谱查看
通过可视化连接查找对象归属、系统供给和相关设备。
资料与语义检索
围绕设备和问题确定知识、维护资料与检索范围。
版本与一致性维护
检查模型与实例关系，记录知识变化及维护责任。
知识交换与应用集成
支持 OWL 导出并与 AI 运维组合；知识中的指令关系不等于操作授权。
04 / 界面与用途
前台用户界面与后台管理界面
用户查询界面 · 知识图谱
沿设备、空间和系统之间的关系查找相关对象，为查询与业务分析提供上下文。
后台建模界面 · 本体编辑
建模与实施人员维护类、属性、实例和关系，使设备名称与业务含义保持一致。
先把“是哪台设备、与谁相关”说清楚
当值班人员询问“三楼空调为什么报警”时，平台需要识别具体楼栋、空间、设备、测点和资料。AI-Ontology把这些概念与关联组织成结构化知识，帮助人和软件使用同一套对象名称。它服务于设备数据治理、知识检索和AI运维集成，适合运维团队与平台实施人员共同维护。
| 知识对象 | 表达什么 | 建筑中的例子 |
|---|---|---|
| 类别与继承 | 对象属于什么类型 | 空调机组、水泵、传感器、房间和系统 |
| 空间关系 | 对象位于或服务于哪里 | 设备位于机房，机组服务某楼层区域 |
| 系统与供给关系 | 设备属于哪个系统，与谁连接 | 水泵属于冷冻水系统，与上下游设备关联 |
| 测点与资料 | 数据和维护知识属于哪个对象 | 温度点位、故障状态、设备手册和维修规程 |
| 指令与操作对象 | 可选动作对应什么设备接口 | 某设备的启停或设定值接口；实际执行另受权限约束 |
这些关系能支持查询范围与上下文识别。例如沿供给关系找到上游设备，是调查线索；要判断故障原因，还需要有效的运行数据、工况和现场核查。
模式、实例与图谱怎样协作
资料与检索范围
按类别组织知识文章、手册与维护资料，记录来源和状态。解析、索引与检索结果需要检查；新增文件进入资料库后，不应在索引失败时视为已可用。
检查与版本维护
对模型和实例开展一致性检查，核对属性、类型和关联问题。设备搬迁、更换及模型升级时同步更新关系与资料，保留版本及变更责任。
交换与应用集成
可按交付功能导出OWL或供引擎使用的模型内容，选择模式、实例或相应范围。需要映射Brick、REC等外部模型时，先确认概念、字段和版本，并验证转换结果。
以“找到三楼的送风设备”为例
确认查询范围
先确定园区、楼栋和楼层，区分房间与机房，遇到重名对象时要求补充范围。
沿知识关系找对象
通过空间、设备分类与系统关系形成候选设备清单，展示对象编码和关系路径，便于人员核查是否漏项。
读取可用数据和资料
为候选对象查询实时状态、历史或维护资料，说明查询时间及来源；数据缺失时保留待核实项。
进入相应业务
将结果交给监控、运维或AI应用；需要设备操作时另行核对权限、对象和反馈，不能把“模型里有指令”当成已获操作许可。
知识如何支撑AI专家与日常应用
建设重点在知识是否准确且能维护
| 建设事项 | 工作内容 | 验收样例 |
|---|---|---|
| 对象整理 | 设备分类、空间编码、系统关系与点位资料 | 识别重名设备，核对同一对象在业务与图谱中的身份 |
| 知识建模 | 定义类、属性、方向及必要约束，导入实例 | 抽查空间归属、上下游关系和缺失属性 |
| 资料接入 | 登记来源、版本、访问范围与索引状态 | 使用指定问题找到实际资料，并识别无结果情况 |
| 应用联调 | 接入查询工具和AI工作流，设置权限与日志 | 查询结果范围正确，失败不冒充成功，动作符合授权 |
| 持续维护 | 约定新增、迁移、停用设备和资料更新流程 | 变更后可以验证关系、查询结果与版本一致 |
平台复用Java / Spring Cloud业务平台的设备、组织和权限，与公共数据服务及AI运维应用组合。可先选一个系统建立完整知识样板，再按模型和数据质量逐步扩展。
补充产品资料
技术参数与相关资料
用建筑本体连接设备关系与AI上下文
- 知识对象
- 类、属性、实例与关系分别描述设备类别、属性定义、具体对象及相互联系。
- 关系查询
- 从“这台空调服务哪个房间”查到供给关系、空间和关联测点。
- 实时数据
- 本体提供对象关系；实时数值和告警来自已接入的物联或业务接口。
- 控制权限
- 知识中存在控制关系不等于具有操作权限，实际动作由工具权限及现场保护校验。
- 交换维护
- 使用OWL等现有交换能力维护模型，记录来源、版本与变更。
示例：空调机组 → 服务房间 → 室温测点。AI据此定位影响范围，再通过授权接口读取状态或申请操作。
案例、资料与下一步
以下案例提供物联网与建筑集成的公开背景，可用于讨论知识建模的设备和空间基础；不将其表述为已交付本页全部AI功能。
广州奥林匹克中心物联网平台
参考大型场馆中设备数据与系统集成的应用范围。
九江市德福科技研究中心
参考科研场景中的设备、空间与管理对象。
选型常见问题
- 本体知识与普通文档知识库有什么区别？
- 文档知识库保存和检索手册等资料；本体模型明确设备、空间、系统的类别与关系。两者可组合：先确认对象及关系，再查询相关资料和运行数据。
- 已有设备台账能够直接变成知识图谱吗？
- 可以作为建模输入，但需检查编码、类别、空间归属及系统关系。导入后应抽查实例和关系，不完整的台账不会因为可视化而自动变得准确。
- 图谱是否能自动判断所有故障原因？
- 不能据此作保证。关系查询可以找到相关设备与调查路径，故障判断还需要运行数据、规则、工况和现场证据，AI分析结果应保留依据与待核实项。
- 知识中有设备指令，是否就能自动控制？
- 不能。知识中的指令描述可选动作与对象，执行仍需权限校验、范围确认、设备反馈及日志。专业控制与安全保护保留在相应系统。
- 如何开始实施？
- 选择一个边界清楚的系统，准备设备、空间、点位和维护资料，用固定查询样例检查关系和数据，再连接AI或业务应用。模型维护责任与更新流程同时交付。
补充了解：使用背景与建设目标
让AI理解设备之间的关系，而不只是设备名称
同样叫“1号泵”，可能属于不同楼栋和系统；一条维护经验，也可能只适用于特定设备或工况。AI本体知识平台通过对象、属性和关系组织业务含义，帮助团队把分散在人员经验和系统中的知识转为可维护的领域模型。
建立对象与关系
围绕建筑、楼层、房间、系统、设备和业务对象建模，明确隶属、位置和关联关系，为查询与应用提供统一语义。
维护领域知识
由工程人员整理设备说明、运维经验与业务规则，结合模型配置和专家工作台持续维护，使知识更新有具体责任人和使用场景。
连接智能应用
知识模型与设备数据、AI会话和工具协同，让回答能够围绕正确的对象和业务关系展开。知识覆盖范围与实际数据接入范围共同决定可用场景。
微信咨询
