在交付日停下的系统 — 我们为何自己做管控平台

定制开发合同里最重要的日期是交付日。整理需求、开发、验收通过，系统就在那一天完成。而它也往往在那一天停下。

如果觉得"停下"太夸张，可以想想五年前建的管控画面。布局还是建成那天的样子。这期间现场加了产线，改了门禁策略，又装了二十台摄像头。只有系统还停在2021年。想挑一个按钮的位置，得先拿报价；当初做的公司早已去了另一个项目。

这就是位置类管控行业的默认状态。我们最初也是这么干的。

"ORBRO OS 的故事"是一组关于我们如何跳出这个默认状态的文章。本篇讲的是最底层的那个选择：不再按项目做系统，而是自己做一个平台。

I. 在交付日停下的系统

定制开发本身并不错。如果需求真的特毊，定制就是对的。问题在于，在位置类管控这个领域，大多数项目其实是在重复做同一件事。

把位置画到地图上的引擎。登记设备、看设备状态的画面。按条件发告警的规则。存数据、查数据的仓库。名字不同而骨架相同的功能，每个项目重新开一遍，变成彼此不兼容的代码，散在一个又一个现场。

这个结构真正的成本不是开发费。是没有任何一个现场能分到另一个现场的改进。为A现场做的好功能，就停在A现场。同一个BUG，有多少个现场就修多少遍。几年下来，手里积下十套彼此相似却互不共享的系统。

对比项	按项目定制开发	平台＋应用（ORBRO OS）
起点	每次从空白画面开始	在验证过的内核之上
需求实现	整套需求全部重写	开启需要的应用，只开发缺的那部分
交付之后	合同结束，更新停止	更新持续送到
改进的传播	只在那个现场生效	成为标准功能，全部客户受益
BUG修复	按现场数量重复修	在内核修一次
客户专属需求	拆开内核改	在API上加定制应用，内核不动

这里会出现一个反问："那个通用平台能适配我们现场吗？"这担心很正当。下面两章就是答案。

II. "OS"不是比喻，而是结构

名字里加OS，是设计决定，不是修辞。

一开始并不是这个样子。早期画面就像常见的管控网页：有菜单，点一下就跳页。我们把菜单拆了，把每个功能重新定义为可以安装、可以删除的应用，然后在上面加上多任务和任务栏。这个决定就是：把管控画面做成桌面，而不是网站。

现在打开ORBRO OS，浏览器地址几乎不变。变的是画面内部：窗口打开、重叠、堆到任务栏里。你可以一边在地图上看资产位置，一边调出门禁记录窗口，再在上面叠一个摄像头窗口。不是跳页的网站，而是在一个桌面上摆应用。

这个结构真正重要的地方不在画面，而在画面之下。操作系统把硬件抽象掉，应用就不必知道硬件；ORBRO OS 把定位基础设施和数据抽象掉。应用不需要知道基站有几台、摄像头是什么型号。也就是说，做新功能时不用把地图、认证、告警再做一遍。所以应用增长得很快。事实也确实如此。

III. 22个应用 — 靠"开启"完成的管控

买手机时，没人会买一台预装所有应用的机器。先有操作系统，再挑应用。ORBRO OS 也是这么回事。目前提供22个应用、5个分类，现场只开需要的。应用可以按工作区启用或停用，用不到的功能根本不会出现在屏幕上。

基础（5） — Dashboard、Device Manager、Setting、3D View、Weather。任何现场都需要的骨架。

定位追踪（10） — Zone Manager、Zone Counting、Zone Effect、In-out Tracking、Reverse Tracking、Alert Zone、Access、Heatmap、Timeline、Record。最厚的一类，也是平台的心脏。画区域，数进出这些区域的人和资产，回溯走过的路径。底层技术整理在RTLS 介绍页。

AI（4） — AI Event、AI RTLS、Multi Cam、LPR。AI Event 从摄像头画面里找出未戴安全帽、倒地、火災、进入危险区域、碰撞这类情况。与边缘产品 AI Event Manager 联动，视频分析在现场的边缘设备上完成。

数据分析（2） — Scan Insight、Nearby Search。查询和分析积累的位置与信号数据。如果管控是看"现在"，这一边就是为"下一步"做准备。

服务（1） — SOP。条件触发后，把规定的处置流程直接调到屏幕上。让事情发生时没人需要去翻手册的应用。

同一个平台，制造工厂和写字楼开的组合完全不同。工厂把 Alert Zone、AI Event、Zone Counting 放在前面；写字楼以 Access、Heatmap、Dashboard 为中心。选完应用的那一刻，通用平台就成了那个现场自己的管控系统。靠配置，不靠开发。

IV. 一个现场的需求，如何变成所有人的标准功能

做平台这么久，我们守住了一条原则：尽可能把客户需求吸收成"标准功能"。说起来容易，所以看三个真实的例子。

一家运营展览空间的客户提出，一有人进入某个区域就立即通知。为这个需求做的功能没有停在该客户专用，而是打磨成了一个叫 Alert Zone 的应用。现在它是22个应用之一，所有客户都在用。

一家运营大型建筑工地的客户希望，出事时系统能直接把处置流程推到眼前。由此产生了 SOP 应用。一并接入的无线传感器——空气质量、燃气、漏水、紧急按钮——现在也是标配。

一家运营露天堆场的客户想用条码扫物料出入库。对一个定位平台而言，条码是个陌生的需求。这个也进了标配。条码资产管理和PDA扫描枪对接成了正式功能，其他用仓库的客户直接拿去用。

三个例子里，提需求的客户得到了自己要的，没提需求的客户得到了自己没要的。

当然也有吸收不了的需求。只存在于那家公司业务规则里的画面，只有那个组织在用的审批流程。这时候我们不拆内核，而是在平台已经开放的API上加一个该客户专用应用。既保住内核的稳定，也保住现场的特毊性，内部叫它混合模式。

我们能把这个结构负责到底，是因为每一层都是我们自己做的。位置标签硬件、放在现场的边缘设备、以及之上的管控软件，都由一家公司设计。我们不附在某个大企业的生态上，所以出问题时不管在哪一层都能自己动手修，下一步做什么也由我们自己定。

V. 数据不出现场

ORBRO OS 采用本地部署。不是云产品额外"支持"本地部署，而是从一开始就按照服务器放在现场内部来设计。

这是由国内B2B现场的条件决定的。公共机构和制造现场常有网络隔离和安全审查，把数据往外部云上传本身就不可行。作业人员的位置和摄像头画面尤其敏感。在这类现场，本地部署不是一个选项，而是入场条件。

适配的现场，最后往往都在问同一个问题：什么东西在哪里。要看作业人员安全和动线的制造业，要跟资产和物流流向的仓储，要管门禁和空间运营的写字楼，要在一个屏幕上看清辖区情况的政府部门。需求各不相同，但底层的问题一样，在上面叠各自不同的应用组合就行。

结语

我们自己做管控平台的理由很简单：按每个现场从头重做的方式，任何一个现场都不可能拥有一套持续变好的系统。

ORBRO OS 没有交付日，只有发布日。从拆掉菜单、改成应用体制的那一天起，一年多的时间里我们发布了将近三十次。

再想想前面那个要求危险区域提醒的客户。他要的是一个应用。这段时间里，他的屏幕上多了二十一个他没要的应用。条码、处置流程、视频事件检测，最初都是别的现场提的需求。一套停在五年前画面上的系统，不会发生这种事。

接下来的文章会按分类看看填满这个平台的应用：最厚的十个定位应用、没人盯着也能读懂现场的AI应用，以及托住这一切的基础应用。如果想先看屏幕，演示和导入咨询随时欢迎。