数字智能物联网平台，从低代码概念到物体模型的演变

在数字时代，物联网和低代码技术正在逐步改变我们的生活和工作方式。本文将深入探讨数字智能物联网平台的发展，特别是低代码概念在物联网应用领域和物联网模型的演变。

近来学习了低代码产品的设计理念，在不同的平台上看到了许多观点，有些人认为低代码技术是福音，特别是国内外 IT 大型工厂的官方声明，整体上对其持乐观态度。还有不少人抛出了低代码简直就是“毒瘤”的观点。

在学习的过程中，尤其是在了解新事物的过程中，我们应该始终以批判性的思维看待各种观点。深入了解发言人的立场，了解他为什么有这种观点，是比直接认可一个看似正确的观点更深层次的学习方法。

01 为什么不看好？

低代码的位置很尴尬，很多人认为它只是处于半吊子的位置。尤其是从大多数程序员的角度来看，低代码的定位非常无味。

首先，对于非技术人员来说，比如商品、运营、销售，甚至甲方客户来说，低代码的操作都不方便，很难上手，需要系统学习才能初步掌握使用方法。

对于开发者来说，低代码的自由度和灵活性肯定是真实代码无法比拟的。如果一些用户的灵活需求一开始设计的低代码系统能够配备好，如果不能配备，最终还是要在底层修改，修改肯定比直接根据需要开发的系统要困难得多。

这个东西和混合动力汽车一样有争议，混合动力汽车的动力系统介于油车和电车之间。认为它好的人认为它通常可以烧电省钱。如果他们不能充电，他们可以给油续航。他们不用担心躺在窝里。他们的眼睛充满了它的优点。看不起混合动力汽车的人觉得烧油比油车贵很多，动力也不够。简而言之，它充满了槽。

事实上，无论是用于举例的混合动力汽车，还是低代码工具，这种处于中心位置的工具，都必须考虑好坏，甚至放大一些优缺点。关键是要明确使用场景和用户，以后合理使用工具，然后取长补短。

在这一点上，我们需要明确低代码这个工具，真正的用户应该是谁。作者认为，应该是“内容运营”或“售后”数字化转型技术制造商 / 售前技术支持"。总的来说，应该交给乙方的非技术人员。经过合理的就业培训，这些专业人员也会熟练地使用低代码工具。

与之相符的工作流程是:产品R&D人员在大量项目中不断积累经验，在不同场景下开发相应的低代码产品，然后由乙方的非技术人员操作。通过与客户的持续沟通，他们可以使用低代码工具为同一场景中不同的客户提供最后一个平台，并提出需求，以满足他们的使用习惯，并在实际使用过程中发现问题，从而为R&D部门迭代优化低代码产品提供参考。

02 数学智能化，走向标准还是定制？

任何提供数字化转型服务的技术制造商都会告诉你，数字产品的设计在不同行业甚至同一行业的不同公司都有很大的不同。但是，当他们以各种方式赢得项目时，R&D人员肯定会考虑是否可以复制和重用以前做过的系统。真的很糟糕，可以参考改变。

数字化转型产品是规范化还是定制化，其实是一个很难选择的问题。对于数字化转型解决方案提供商来说，走标准化路线意味着他们可以大量快速复制和推广自己的产品，从而大大降低边际成本，实现持续盈利，薄利多销，让数字化转型技术让更多的受众受益。

另一方面，基于用户体验，客户也期望看到数字化转型服务提供商深入其一线调研，深刻理解其实际问题，最终交付与其工作流程高度匹配的产品。顾客的想法也很简单:“既然我给了你钱，你的眼里只能有我。不要把别人做的东西复制过来，愚弄我。。"

笔者个人认为，数字产品也趋于进入标准和定制的中间状态。当然，这种混乱的观点也意味着商品设计师需要根据具体情况，顺势而为，大大提高自己的能力要求和主动水平。

在浏览了大量的项目案例后，笔者发现，在很多产品场景中，使用低代码可以很好地解决标准化和定制化之间系统的平衡问题。

过程引擎实际上是一个非常好的例子。如今，许多低代码或零代码产品习惯性地倾向于 OA 由于代码低、灵活性高、可配置性强的特点，工具的发展，实际上解决了企业审批系统的痛点。

例如，在一家大型制造企业中，不同的业务部门、部门和生产线层出不穷。还有一些需要在里面加很多规则，比如“资金超过” 200 要求领导批准，低于 200 “自动通过”。再加上频繁的人事调动，也意味着审批过程中的每一个人都需要及时更新。

如果所有的过程都是R&D同事直接开发出来的，那么几乎每天都需要不断迭代，花费大量的开发精力，这种变化非常频繁，规则复杂，使用场景复杂。

因此，如果 OA 系统灵活可配置。在日常运营过程中，即使流程千变万化，也只需要安排一些普通员工随时配备即可。现在 OA 低代码基本上已经占据了工具的主导地位，但是在其它领域，笔者认为，这一产品理念的实施还不够深入。

接下来，笔者将通过自己设计的产品案例，重新审视低代码产品理念在产品设计中的应用。在实际项目中，笔者大胆创新了这两款产品。虽然还有很多需要改进的地方，但这两种情况在低代码处理数字项目的标准和定制之间的矛盾上已经初具规模。

03 案例:建筑自动控制项目复盘

建筑自动控制系统通常反映在智能建筑项目中。我们平日看到的高层建筑都配备了复杂的电气设备，以确保建筑物内部环境的舒适性。包括调节温度的空调系统、保持室内环境新鲜的通风系统、常见的给排水系统、变配电系统、照明系统等。

以后我们会详细讨论建筑中各种系统的具体工作原理。在数字项目中，我们通常需要对建筑自动控制系统做以下功能:

设备台帐管理，建筑自动控制系统包括空调、排气扇、潜水泵等设备设施，还包括照明、电梯、监控等电器。根据统一标准，为所有设备建立台账，逐一建立相互关系，引用其他环节，建立系统与硬件的互动关系，都需要基于设备台账的系统基础。

数据监测，大量的数据，如当前的温度、湿度、送风温度和湿度、水箱水位等，可以在建筑物内系统结构的传感器或数据监控点实时收集。数据监控系统也是大多数综合解决方案提供商可以达到的水平，核心技术是协议分析、数据收集和分析。

发布控制指令，如果有收集信息的点，也必须有发布控制指令的点，比如设置空调制冷温度，打开送风阀，控制泵开始运转等等。在产品设计方面，我们可以设计成手动操作，也可以根据一定的条件自动控制系统。

可视化，无论是组态图的绘制，还是数字孪生技术的应用，都是一种可视化。

自动调度，这也是最难产生核心堡垒的东西。通过引入智能算法，可以根据现场条件自动控制建筑的各个环节，达到舒适环境、节能、延长设备使用寿命的目的。

在设备台账管理、数据监控、控制指令发布等方面，笔者引入了低代码的设计理念，设计了一套通用商品，可以自由配置，水平相对较高。

第一，要实现建筑自控的基本功能，大致需要规划两个模块，一个是软件平台，另一个是协议分析模块。

先说协议分析模块。如果我们遇到更好的硬件商家，我们会直接从系统平台提供。 API 接口，然后开发可以直接敲击代码对接，省时省力。如果硬件供应商提供遵循一个协议的数据传输服务，那么我们应该分析协议，并将其打包成标准接口或新闻提醒。常见的物联网传输协议包括 obix、modbus 等。

总之，提供给软件平台的一定是标准化接口已经包装好了。按照以往的开发方式，我们会先根据客户的需求开发相应的页面，然后开发同事会对接接口，提取数据进行分析，做一些按钮，发出控制指令。

这样做的缺点是系统的定制特性太强，尤其是智能建筑，几乎每次换客户都要重新开发不同客户差异较大的项目。此外，在分析和开发之前，需要获得所有电气和弱电系统的点和设计图纸，这不仅使开发量大，而且使工期难以保证。

所以，为使系统更加灵活，作者在数据方面，对点位信息进行收集整理，设计出一套智能建筑低代码产品。商品配置完成后，可由非技术人员配置，在获得设备点表和接口目录后，可快速配置并上线。

对于智能建筑场景中的数据，如果按照数据类型进行划分，总共也就是数字化类型和模拟型两者。工科学生可能很清楚，数字类型无非是 0 或 例如，设备的开关，设备的在线。 / 离线，即可使用 0 和 1 替换。模拟类型代表持续值，如温度值、湿度值等数据指标，可以在一定范围内随意取值。当然，在实际场景中，由于设备采集精度的限制，只能取离散值。

若按功能类型划分，所有数据分为两类，收集数据，控制参数。例如，对于某些接口中的数据，我们应该调用接口来收集它们，而对于某些接口中的字段，我们可以通过调用来控制它们的开关或设置温度、湿度等值。

基于此，我们可以开始设计智能建筑低代码管理系统的雏形。首先，在首页布局一个目录。目录横向分为三个区域。首先，设备信息区域，用于导入设备台帐；数据收集区域，用于读取每个点检测到的数据；控制指令区域，用于手动发送控制指令。

我们可以在设备信息区添加导入功能，导入设备台帐中的设备，并获得其设备。 ID。这样，我们就可以清楚地知道在调整接口时，每行数据采集了哪些设备的信息。当然，在设备信息区域，我们也可以添加其他设备属性，如设备名称、设备位置、设备自定义代码等。

在数据收集区，我们可以逐一添加需要收集的字段给指定设备。在配置每个字段时，我们需要配置以下信息:

字段名称：对于这一数据指标，例如出风阀温度、进出水量、室内温度、系统在的自定义名称， / 离线状态等。

字段类型：对于数据监控字段，字段有两种类型，一种是模拟类型，这种类型的字段可以直接取回值，例如温度、湿度等。另外一种是枚举类型，一般可以包括数字类型，不同的是，数字类型一般是 0 和 1 两个枚举，而广泛的枚举类型，一般可有多个枚举值。枚举类型的数据，一般返回值为枚举值，例如， 0,1,2 这类代码，我们应根据界面定义，定义每个枚举值的含义，例如， 0 代表关掉、1 代表在线设备等。

接口地址：对于系统来说，在回到我们需要的统计数据之前，我们需要明确调用哪个接口，输入相应的调用值。一般每个接口都会在一定的网络范围内提供唯一的接口调用地址。如果我们配置好接口地址，系统就会知道找哪个接口来执行调用操作。

对应字段：一个接口调用后，通常会返回很多值，那么我们配备的字段可以对应哪个值呢？此时需要明确配备的字段与实际接口返回字段的映射关系，并在相应的字段输入框中填写相应的返回值。

控制指令区和数据收集区的原理基本一致。当控制指令区配备控制字段时，每个字段都需要配置字段的名称、类型、接口地址和相应的字段。不同的是，数据收集区输入的相应字段应该从接口的导出值中找到，而控制指令区输入的相应字段应该从接口的输入值中找到。

04 物模型

作为一名新的产品经理，上述章节在行业通用产品的设计过程中普遍探索逻辑，无需相关理论知识的积累。

经过对市场上完善的物联网平台产品的使用和分析，我们可以发现，物联网平台要实现其灵活性，贯彻低代码的理念，虽然与低代码工具有一定的区别。

面对复杂多样的物联网设备，目前通用先进的解决方案是将具有相同功能的设备定义为产品，并将来匹配该产品的模型。物联网平台中的物联网模型也是一个重要概念。由于篇幅有限，这次只简单介绍一下，有机会可以详细拆解。

当我们将相同功能和设备集成到一个产品中时，产品模型的概念应该从特性、服务和事件三个维度进行。

特性：设备的功能模型之一一般用于描述设备运行时的状态，如环境监测设备读取的当前环境温度。软件系统可以启动属性读取和设置请求。(相当于为设备定义一个数据库，完成标题)

服务：设备的功能模型之一是设备可以被外界调用的能力或方法，输入参数和输出参数可以设置。与特性相比，服务可以通过指令实现更复杂的领域模型，例如执行特定的任务。(相当于为设备定义相关的功能接口)

事件：设备的功能模型之一是设备运行过程中的事件。事件一般包括需要外部感知和处理的通知信息，可以包含多个输出参数。例如，事件可以通过订阅和推送某个任务结束的信息，或者设备出现故障或报警时的温度来订阅和推送。(相当于给设备添加几个消息提醒，并定义好消息体)

模型定义好之后，就相当于在物联网软件平台上构建了相关设备的虚拟数字实体。虚拟实体即时投射实际设备，我们可以直接面对已经设置好的物体模型的虚拟数字实体进行操作，比如设备台账、设备巡检、构态可视化、逻辑安排等。所谓数字化的第一步——数据收集，我们已经踏过了门槛之一。

本文由 @点维数智空间 原发布于每个人都是产品经理，未经许可禁止转载。

题图来自 Unsplash，基于 CC0 协议

这篇文章的观点只代表作者本人，每个人都是产品经理平台，只提供信息存储空间服务

本文仅代表作者观点，版权归原创者所有，如需转载请在文中注明来源及作者名字。

免责声明：本文系转载编辑文章，仅作分享之用。如分享内容、图片侵犯到您的版权或非授权发布，请及时与我们联系进行审核处理或删除，您可以发送材料至邮箱：service@tojoy.com