萧瑟平生只自知 玉箫忍按悼亡词 桃花飞影潮生后 尽想东邻一笑痴
东邪黄药师
最后我们开始聊我的老东家阿里，作为国内互联网圈第一个开始涉足智慧建筑的大厂，同时也是17年第一个召开智慧建筑行业峰会的企业，阿里如何做智慧建筑代表了很多同行的期许，也给了后来者勇气和信息介入这一传统行业。
阿里内部是有着勇于试错，敢于试错的传统的，支付宝、阿里云、菜鸟、盒马…都是这些BU不拘泥于现有观念，勇于打破传统 才做成功的。而阿里的智慧建筑也是一样的出发点。15年开始，阿里在原有置业部的基础上，开始尝试做数字化转型，BU的领导层希望能有一个数字化的平台产品来服务楼宇这块业务，加速应用的孵化和服务的升级。基于这个出发点，我们开始摸索和学习市场上现有楼宇软件级平台产品。作为这个部门最早的系统设计人员，我们的路走得也不是一帆风顺。这里我总结为“三进三退”
- 一进 “从外部合建平台 到 自研平台”
- 一退 “从自建全功能网关 到 侧重解决智能设备接入的IBOS Edge”
- 二进 “从端-边一体 到 接入端-边缘侧 自洽分布式”
- 二退 “从交付部署总包 到 交付部署软件化分包”
- 三进 “从云端PaaS平台 到 分离抽象 通用PaaS和领域PaaS”
- 三退 “从独立的智慧楼宇平台 到 浓缩为阿里云的N个行业解决方案”
一进 从外部合建平台 到 自研平台
IBOS（Intelligent Building OS）作为阿里巴巴智慧建筑事业部的自有品牌，自然也经历了内部纠结，从无到有的过程。一开始，我们是尝试和一家云服务商合作，同时对市场上做类似楼宇智能化的产品进行扫描分析，通过整合研华Wise本地接入网关，云端微软Azure IoT Hub的模式，打造了一套可以落地的楼宇方案。在17年的阿里深圳中心 通过该云服务商的方案，将照明、AI人脸通信、VAV新风空调、电表、环境传感器都接入云端，实现统一管理和控制，据此开发了智能会议室、智能工位、能源管理、智慧寻车等多个应用。这次项目实践使得阿里逐步发现，楼宇平台是实现各类数字化应用的关键，也是未来可以产品化的核心能力，所以开始思考整合内部资源，自己构建这样一套自研楼宇平台。从17年中 阿里开始逐渐用自己的楼宇平台来实施后面的多个园区项目，也注重从标准化方面通过召开IB峰会来推动生态共建
深圳阿里中心
一退 从自建all functions网关 到 Focus smart device IBOS Edge
IBOS（Intelligent Building OS）作为一个整体楼宇解决方案产品，包括云端和现场。一开始阿里是计划建立一个可适用绝大多数楼宇场合的边缘网关，这也和其他微软、亚马逊、腾讯这些互联网大厂做楼宇的思路类似。这是用做惯了C端智能家居的物联网思路来玩B端智能楼宇。我在智慧建筑事业部，早期也和阿里云IoT团队的同学一起讨论，用IoT Smart Gateway加阿里云IoT platform的软硬件一体化方案来做Intelligent Building。这种思路后面其实被钉钉做智慧办公时延续了过去，以智能软件平台为载体来落地智慧产业社区的生态共建模式。但经过一系列的MVP（Minimum Viable Product）验证，这种阿里云IoT和涂鸦智能采用的商业路径并不合适智慧建筑板块。尤其是在楼宇的传统智能化方面更是力有不逮。
建筑智能化中的很多厂商品牌是针对楼宇控制这块的，不比最近新拓展的AI人脸通行、智慧停车等功能，这些新系统大多符合联网的需求，对接方式也较灵活，不存在太大的技术难度。传统BA（楼宇自动化）、FA（消防智能化）这些子系统和设备则大多选用几十年来稳定运行，久经市场考验的工业品牌，比如霍尼韦尔、ABB、RockWell的产品序列，虽说现在为了联网的需要，也增加网络型的控制模块来支持数据入网，但如果需要更精细的控制和逻辑优化，不深入了解传统协议的工作模式和数据含义是做不成功的。所以为了更好的做好对Bacnet、Modbus、KNX、OPC-UA这块工业协议的支持，我们后来还是觉得与其自己投入资源和精力重新理顺这块，包括开发相关的网关驱动适配，莫不如借助已有的成熟产品来打通现场接入和数据本地化的难题。所以后面我在部门使用的架构如下
三方楼控边缘网关/服务器负责传统工业系统的接入和本地边缘处理，阿里的IBOS-Edge则负责智能设备/子系统，比如停车子系统、人脸设备、人流统计AP设备等。通过这种组合，我们理顺了设备选型和分工协同的实际问题，加速了后续多个阿里智慧项目的部署和落地交付过程。
二进 从端-边一体 到 接入端-边缘侧 自洽分布式
在早期IBOS-Edge边缘服务推出之前，IBOS-Edge其实面临了三块工作职责，j现场接入 k本地处理 lBPM规则执行，现场接入 繁琐且差异化很大，本地处理和BPM规则执行则相对比较确定 但和本地算力有关，初期的想法是用一套IBOS-Edge解决这三类问题，这就面临着硬件指标选型难的情况。如果要支持485总线，支持几路，每一路的设备数目既和电气特性有关，又与现场设备安装的物理位置有关，同时这套硬件盒子要处理某一采集频率下的数据运算，也需要相应的CPU和存储要求。受限于现场场所位置和算力的双重抉择，这样的边缘硬件设备要不ODM后成本较高而不能灵活适用，要不单个成本降下来了但整体算力有限，BPM规则难以运载相对复杂的业务流。经过摸索，我们后来将边缘能力拆分为两块：接入 和 算力。接入IBOS-Connector专门负责设备接入和数据标准化预处理，接入IBOS-Streaming Gateway负责视频流设备的接入与处理，IBOS-Edge在这两类接入网关之上负责数据过滤、数据质量治理、数据聚合等ETL本地数据处理 以及 基于本地规则引擎的BPM执行。
二退 从交付部署总包 到 交付部署软件化分包
阿里早期的落地项目，深圳中心、成都阿里中心，从IBOS-Connector、IBOS-Edge的系统安装 到 阿里云IBOS Cloud的DevOps部署，再到应用软件神鲸的部署及全链路调试验收，都属于自己团队完全包干的。而在后面的亲橙里智慧商超、虹桥阿里中心、滨江阿里园区项目中，随着软件产品的标准化和成熟度上升，以及生态合作伙伴的健全，我们逐步将交付部署采用软件分包的方式。IBOS-Connector和Edge的安装使用Docker部署方案，IBOS Cloud则分为项目基础数据部署（空间初始化、设备初始化、用户权限初始化）和业务数据部署（空间业务初始化、业务规则初始化）两块。通过开发出相应的部署工具，同时赋能合作伙伴完成在线的部署与实施验收，真正实现了部署的可交付、可三方委托。借助这些部署工具，不仅降低了部署的成本，而且大大降低了部署的周期（缩短80%），提高部署的准确度。
三进 从云端PaaS平台 到 分离抽象 通用PaaS和领域PaaS
对于要从PaaS平台抽象聚合出更能集中反映楼宇这一行业特性需求，解决这一行业难题能力的想法，从开始做IBOS平台，我们就一直在思考如何合理的做分割。虽然通用PaaS和领域PaaS的想法很容易确立，但哪些服务能力属于Domain PaaS的，哪些属于Common PaaS，很多情况下难以一刀切。比如空间管理是属于通用功能，空间能耗分析则属于领域业务范畴，人员定位属于通用能力，人员画像则属于业务服务能力，这些都需要结合业务的发展而不断丰富和拓展。一个主要的原则是，提炼的领域能力能更好地满足复用性和独立性的要求，能更利于SaaS化产品的孵化。如果没有足够的业务推动力，则不急于从统一的PaaS抽离。业务驱动才是第一生产力
三退 从独立的智慧楼宇平台 到 浓缩为阿里云的N个行业解决方案
如果仔细留意阿里最近几年的组织调整，可以发现是以阿里云作为基础设施能力门户的一个强化过程，无论是蚂蚁金融云并入阿里云成为旗下一朵行业云，还是最近的钉钉全面融入阿里云构成“云钉一体”战略，都是做强做丰富阿里云这个基础能力核心的一个个举措。所以阿里的智慧楼宇平台成长到一定的阶段后，也一样面临如何与阿里云协同的问题。早期的IBOS Cloud，其实只是借用了阿里云的IaaS基础，连阿里云IoT平台的能力都算不上用过（前文也有说明为何不用阿里云IoT那套）。双方的关联性并不大，和一些外部客户没啥区别，但进入19年，当IBOS已经成为阿里各地办公中心、园区标准项目配置产品，随着集团以阿里云作为智慧城市主打方案产品，智慧建筑作为城市下的一条行业线，内部围绕整合IBOS到阿里云，形成智慧办公、智慧园区解决方案的呼声越来越大。于是成为阿里云的行业解决方案产品就列入上路线图
尾声
未来会如何我们没法把握，不过数字化是可见的大趋势，工业数字化可以带来新技术革命的更新，推动国家战略转型和弯道超车，农业、基建、零售无不面临着一样的机遇窗口。我不赞同当前将互联网企业能力过分高光的做法，像一些自媒体那样鼓吹我们有了BAT，远超出日本、德国的数字化基础水平。毕竟工业和制造这些实体才是根本，互联网所体现的荣光只是长在其上的。没有根就如水上浮萍和墙上芦苇，是站不牢的。不过互联网的优势能力又是值得肯定的，他们对于数字的使用和运营确实比传统工业企业成熟不少。如何将这两者结合好，取其精华，做到1+1>2，这也是我们作为行业从业者需要思考的。既不过高看待自己的IT经验，又不轻视传统工业的积累，融会贯通方成大器。
1410
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
