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

近期学习低代码产品的设计理念，在不同平台上看到了很多观点，有的人认为低代码技术是福音，特别是国内外IT大厂的官方说法，总体对其保持乐观态度。也有很多人抛出了低代码简直就是“毒瘤”的观点。

在学习过程中，尤其是了解新事物的过程中，我们始终都应该带着批判性的思维去看待各种观点，与直接认同某个看起来正确的观点相比，深入了解发言人的立场、了解他为什么抱有这种观点，才是更高层次的学习方式。

01 为什么不看好？

低代码所处的位置比较尴尬，很多人认为其恰恰处于一个半吊子的位置。尤其是从大多数程序员的视角来看，低代码这个东西的定位非常鸡肋。

首先，对于非技术人员，比如产品、运营、销售甚至是甲方客户来说，低代码的操控并不算便捷，上手是有一定难度的，并且还需要系统的学习，才能初步掌握其使用方法。

而对于开发者来说，低代码的自由程度和灵活性跟真正的代码肯定无法比拟，一些用户的灵活需求，如果要是一开始设计的低代码系统能配置还好，如果不能配置，最终还是得在底层进行修改，而且修改起来肯定比直接按需开发的系统费劲的多。

这个东西就像混动汽车一样充满争议，混动汽车的动力系统介于油车和电车之间。认为它好的人，认为它平时既能烧电省钱，万一充不上电还可以加油续航，不用担心趴窝，满眼都是它的优点。看不起混动汽车的人，认为它烧起油来比油车费油的多，动力又不太足，总之满是槽点。

其实，无论是用来举例的混动汽车也好，还是低代码这个工具也好，处在中间位置的这类工具，必然是优劣兼具，甚至还将某些优势和劣势进行了放大。关键还是要明确使用场景和使用者，之后恰当地使用该工具，从而扬长避短。

讲到这里，我们需要明确低代码这一工具，真正的使用者应该是谁。笔者认为，应该是数字化转型技术厂商的“产品运营”或“售后/售前技术支持”。总而言之，应该交给乙方的非技术人员使用。这些专门人员在经过合理的上岗培训后，也会熟练使用低代码工具。

与此相匹配的工作流程是：产品研发者在大量项目中不断积累经验，开发出不同场景下对应的低代码产品，之后由乙方非技术人员操刀，通过与客户进行持续沟通，使用低代码工具为同场景下不同的客户配置并交付符合其使用习惯的最终平台，并在实际使用过程中发现问题，提出需求，为研发团队迭代优化低代码产品提供依据。

（图片来源：点维数智PM原创）

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

任何一家提供数字化转型服务的技术厂商都会告诉你，不同行业、甚至同一个行业的不同公司，数字化产品的设计都是千差万别的。然而等他们以各种方式拿下项目后，研发人员一定都会想着在做系统时，能不能照搬和复用之前做过的系统，实在不济，参考着改一下也行。

数字化转型产品，到底是走向标准化还是定制化，其实是一个难以抉择的问题。对于数字化转型解决方案提供商来说，走标准化路线意味着可以大量、快速地复制并推广其产品，从而极大减少边际成本，实现持续盈利，也可以薄利多销，让数字化转型技术普惠更多受众。

另一方面，基于用户使用体验来说，客户也期望看到数字化转型服务商深入其一线调研，并对其实际出现的问题进行深刻的理解，并最终交付与其业务流程高度匹配的产品。客户的想法也很简单：“既然我给你钱了，那你的眼里只能有我，不要拿给别人做的东西复制过来糊弄我。”

而笔者个人的看法是，数字化产品也趋向于走入标准和定制的中间态模式。当然，这种和稀泥的结论，也意味着产品设计者需要结合具体情况，审时度势，能力要求和主动程度都需要进行大幅度的提升。

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

流程引擎其实就是一个非常好的例子。目前很多低代码或零代码产品，都习惯性地往OA工具上发展，这就是因为低代码高度灵活性和可配置性的特点，实实在在解决了企业审批系统的痛点。

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

假如所有的流程都是研发同事们直接开发出来的，那对于这种变动非常频繁，规则复杂且繁杂的应用场景，几乎每天都需要不断迭代，耗费大量开发精力。

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

（图片来源：点维数智PM原创）

接下来，笔者将通过自己设计的产品案例，来进行低代码这一产品理念在产品设计中应用的复盘。在实际项目中，笔者对这两个产品进行了大胆创新，虽然还有很多地方需要完善，但这两个案例，在低代码解决数字化项目中标准与定制之间矛盾的问题上，已初具雏形。

03 案例：楼宇自控项目复盘

楼宇自控系统一般会在智慧楼宇项目中体现。我们平日所见的高楼大厦，内部都安装着复杂的电气设备，来保障楼宇内环境的舒适。其中包括调节温度的空调系统、保持室内环境清新的送排风系统、以及常见的给排水系统、变配电系统、照明系统等。

楼宇内各种系统的详细工作原理，日后再与大家做详细讨论。在数字化项目中，针对楼宇自控系统，我们一般需要做如下功能：

1. 设备台账管理，楼宇自控系统包含空调、送排风机、潜水泵等设备设施，照明、电梯、监控等电器也包含在内。按照统一标准为所有设备建立台账，构建逐一对应关系，并在其他流程中引用，确立系统与硬件之间的交互关系，都需要基于设备台账这一系统基础。
2. 数据监控，楼宇内各个系统的传感器或数据监测点，都可以实时采集大量数据，例如当下的温度、湿度、送风温湿度、水箱水位等。数据监控系统也是大多数综合解决方案提供商所能做到的层次，核心技术就是协议解析、数据采集与分析。
3. 下发控制命令，有采集信息的点位，必然也有下发控制指令的点位，例如设置空调制冷温度，打开送风阀，控制水泵开始运作等等。在产品设计层面，我们可以设计为手动控制，或根据一定的条件由系统自动控制。
4. 可视化，无论是组态图绘制，还是数字孪生技术的使用，都是可视化的一种。
5. 自动调度，这也是最难但是能形成核心壁垒的东西，通过引入智能算法，根据现场条件，自动控制楼宇内各个环节，达到环境舒适的同时，又能节能，且可以延长设备使用寿命的目标。

笔者在设备台账管理、数据监控和下发控制命令层面，引入了低代码的设计理念，设计了一套自由，可配置化程度比较高的通用型产品。

首先，要想实现楼宇自控的基础功能，大体需要规划两个模块，一个是软件平台，另一个是协议解析模块。

先说协议解析模块，如果我们遇到比较好的硬件商家，从系统平台上直接提供API接口，那开发就可以直接写代码对接了，省时省力。如果硬件商家提供的是遵循某个协议的数据传输服务，那我们就需要解析协议，并封装成标准接口或消息推送，常见的物联网传输协议包括obix、modbus等。

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

这样做的劣势是，系统的定制化属性太强，特别还是智慧楼宇这种，不同客户差异性比较大的项目，几乎每换一个客户，都要重新开发一次。而且还需要拿到所有电气及弱电系统的点位、设计图之后，才能进行分析、开发，不仅开发量大，工期也难以保障。

所以，为了使系统更为灵活，笔者从数据角度出发，对点位数据进行分类整理，设计了一套智慧楼宇低代码产品。产品部署完成后，可以由非技术人员进行配置，在拿到设备点表以及接口列表后，可以快速配置并上线。

（图片来源：点维数智PM原创）

对智慧楼宇场景下的数据来说，如果按照数据类型来划分，总共也就数字类型和模拟类型两种。工科的同学可能清楚，数字类型无非就是0或1，例如设备的开和关，设备的在线/离线，就可以用0和1来代替。模拟类型则代表连续值，例如温度值、湿度值等连续且可以在一定范围内任意取值的数据指标。当然，在实际场景中，受制于设备采集精度，也只能取离散值。

如果按照功能类型来划分，所有的数据分为两种，采集数据和控制数据。例如某些接口中的数据，我们需要调用接口将其采集上来，而某些接口中的字段，我们可以通过调用进而控制其开关或进行温度、湿度等数值的设定。

基于此，我们可以开始设计智慧楼宇低代码管理系统的雏形。首先，在主页面设置一个列表，列表横向分为三个区，一是设备信息区，用来导入设备台账；二是数据采集区，用来读取各个点位所检测的数据；三是控制指令区，用来手动发送控制指令。

在设备信息区，我们可以添加一个导入功能，将设备台账中的设备导入进去，并且获取其设备ID。这样就可以明确，每一行数据在调接口时，采集的是哪个设备的信息。当然，在设备信息区，我们也可以随设备台账加入其他设备属性，例如设备名称、设备位置、设备自定义编码等。

在数据采集区，我们可以逐个为指定设备添加一个个需要采集上来的字段，在配置每一个字段时，我们需要配置以下几点信息：

• 字段名称：为这个数据指标起一个自定义的名称，例如出风阀温度，进水流量，室内温度，设备在/离线状态等。
• 字段类型：作为数据监测字段来说，字段类型共分为两类，一类是模拟类型，这种类型的字段直接取返回值即可，例如温度，湿度等。另一类是枚举类型，该类型一般能够包含数字类型，不同的是，数字类型一般就是0和1两种枚举，而广泛的枚举类型，一般可以有多个枚举值。枚举类型的数据，一般返回值都是枚举值，例如0,1,2这样的编码，我们需要根据接口定义，对每一个枚举值定义其含义，例如0代表关闭、1代表设备在线等等。
• 接口地址：对于系统来说，我们需要明确调用哪个接口，输入对应的调用值以后，才能返回我们需要的监测数据，一般每个接口在一定网络范围内都会提供一个唯一的接口调用地址，我们将接口地址配置好，系统就知道找哪个接口去执行调用操作了。
• 对应字段：一个接口调用后，往往会返回一大堆值，那么具体返回的哪个值能对应上我们配置的这个字段呢？这时候就需要明确所配置字段与实际接口返回字段的映射关系，将接口中对应的返回值填入对应字段输入框。

控制指令区与数据采集区的道理基本相同，我们在控制指令区配置控制字段时，每个字段都需要配置字段名称、字段类型、接口地址和对应字段这几项，不同的是，数据采集区录入的对应字段要从接口的输出值中找，而控制指令区录入的对应字段要从接口的输入值中找。

（图片来源：点维数智PM原创）

04 物模型

以上章节都是在没有相关理论知识储备的情况下，作为一个新入门的产品经理，在行业通用产品的设计过程中普遍的思考逻辑。

在对市面上成熟的物联网平台产品进行使用和分析后，我们可以发现，虽然与低代码工具有一定差别，但物联网平台要实现其灵活性，贯彻低代码的理念是非常重要的。

面对复杂多样的物联网设备，现行的通用且先进的解决方案是将具有同一类功能的设备定义为一个产品，之后为这个产品匹配物模型。物模型在物联网平台中也是一个重要的概念，受篇幅限制，本次只进行简单介绍，后续有机会我们可以详细拆解。

当我们把同一类功能相同的设备集合成一个产品后，对产品物模型的定义，要从三个维度进行，分别是属性、服务和事件。

1. 属性：设备的功能模型之一，一般用于描述设备运行时的状态，如环境监测设备所读取的当前环境温度等。应用系统可发起对属性的读取和设置请求。（相当于给设备定义一个数据库，并且把表头写好）
2. 服务：设备的功能模型之一，设备可被外部调用的能力或方法，可设置输入参数和输出参数。相比于属性，服务可通过一条指令实现更复杂的业务逻辑，如执行某项特定的任务。（相当于给设备定义好相关的功能接口）
3. 事件：设备的功能模型之一，设备运行时的事件。事件一般包含需要被外部感知和处理的通知信息，可包含多个输出参数。例如，某项任务完成的信息，或者设备发生故障或告警时的温度等，事件可以被订阅和推送。（相当于给设备加上几个消息推送，并把消息体定义好）

物模型定义好以后，相当于在物联网软件平台上构建好了相关设备的虚拟数字化实体，该虚拟实体实时映射实际设备，而我们接下来在搭建应用时，如设备台账、设备巡检、组态可视化、逻辑编排等，可以直接面向已经设置好物模型的虚拟数字化实体进行操作。所谓数字化的第一步——数据采集，我们也算踏过了其中一个门槛。