前言

在某些B 端产品中，会通过安装物联网设备来提高工作效率，比如能耗监测、智能抄表、远程监测等等。如果接入的物联网设备品牌多、各家协议、数据格式不一致的话，那么就需要产品层面设计一个物联网接入模块，这个模块充当业务层和设备层的桥梁，使得业务层无需关心具体接入设备的品牌、协议和数据格式。有了物联网接入模块后，接入新的设备时就不需要更改业务层的设计了，也就能够减少业务层的开发工作量，提高整个团队的产出效率。

一个反面案例

先给大家看一个没有物联网设备接入模块的反面案例，这样会更好理解为什么需要物联网接入模块。本人曾经接触过一个物联网监测项目，他们的产品选用的物联网设备只有一个厂家，因此产品设计没有多考虑，开发这边也是为了尽快上线，于是设计了下面这样的产品架构。

结构很简单，实现起来确实也很快，产品顺利上线了。随着业务的发展，从成本和厂家设备的质量综合考虑，公司又选了另外一个厂家的同类设备，但问题来了，新厂家的数据格式和之前的厂家的完全不同，为了接入新设备，他们的产品架构变成了下面的样子。

业务模块变“胖”了，需要新的业务逻辑来对接新厂家的数据 API 接口。更为失误的是，他们的前端页面的字段名称是按照之前的设备写死的，这就意味着前端应用也需要按不同的厂家类型做适配，如果是厂家1就按厂家1的数据格式展示，如果是厂家2就按厂家2的数据格式展示。

之后，公司又引入了新的厂家，然后开发同学就“炸锅”了 —— 简直就是在人工制造“代码屎山”啊！引入一个新的厂家，一是整个开发链条从设备数据 API对接，到业务逻辑处理再到前端页面展示全部都需要跟着改动；二是整个业务的代码里面堆积了一堆按不同厂家做的条件判断，越来越臃肿，难以维护。开发同学怨声载道，对产品经理的配合度自然会下降很多。

问题在哪？

出了问题，自然要看看怎么“甩锅”。那么这里到底是产品同学的问题还是开发同学的问题呢？个人觉得都有问题，但是产品是源头，责任更大一些。作为产品经理，应该要具备业务前瞻性。以这个案例来说，物联网设备属于硬件设备，作为公司运营肯定会考虑硬件采购的成本，产品的质量、稳定性。因此，很大可能会使用其他厂家的设备替换。而且，物联网设备有一个很大的特点就是，设备已经部署后，可能分布在全国各个地方，根本不太可能用一个新厂家的设备完全替换已有的设备。这就意味着，产品设计上需要考虑不同厂家设备的共存情况 —— 也就是要能够支持多个厂家的物联网设备接入。

物联网设备接入需要考虑不同厂家的兼容性，需要能够同时接入不同厂家的同类功能设备。

如何解决问题？

先讲我们生活中的一个例子，我们知道不同国家的交流电的电压是不同的，有220伏 ，也有110V的。如果直接接入电器设备，电器设备会因为工作电压超出范围而导致烧毁。这个问题是怎么解决呢？通过电源适配器来解决，比如下图是一个笔记本的电源适配器，标明了工作输入电压范围是100-240伏，虽然输入电压波动范围很大，但是输出一直稳定在笔记本需要的电压范围内（下图是19.5伏）。

适配器就是解决不同的输入源不影响输出的一个中间设备。受到适配器的启发，软件设计领域就产生了一个“适配器”模式。适配器模式就是将不同的输入转换为相同的输出，从而避免业务层和输入直接产生关系。这样，输入源的改变处理全部由适配器来完成，业务层则无需关心输入源的变动。

对于物联网设备接入，我们会发现和适配器要解决的问题是一样的。因此，对于物联网设备接入，我们应该设计一个适配层，作为厂家数据 API 和业务层的桥梁。这个适配层的职责就是接入不同厂家的物联网设备数据 API，然后转换为业务层需要的标准格式数据。这样，即便是换厂家、换设备，都只需要更改适配层，业务层和前端都不需要做任何改动。有了适配层之后，我们的产品架构就演变成下面的样子。这种架构下，不管接入多少个厂家、多少种设备，都只需要在适配层进行调整，业务模块和前端无需做任何修改。

图中绘制的箭头是单向的，实际上换成双向箭头也是没问题的。如果业务模块需要下发指令到物联网设备，同样也可以通过适配层将标准指令转换为不同厂家设备能够接收的相应指令，接入新厂家设备同样也不需要更改业务模块。

经验分享

其实上面说的反面案例类似的情况十分常见，出现这样的问题很大程度上是没有类似的产品设计经验。本人曾经负责过一个智能电表抄表模块的产品设计，这里面就涉及到抄表、计费、欠费拉闸断电、充值恢复通电、手动通断电等等业务。在产品设计时，由于有适配器这样的概念（实际经验来自做软件开发时的设计模式），所以提前考虑了做适配层。并且，明确和开发同学交待要考虑未来新的厂商设备接入。到后面，确实也因为采购成本原因，采购了另一个厂家的设备。由于有适配层的存在，新厂家的智能电表非常快就接入到产品中，而业务层并没有做任何改动。要知道，如果要更改业务层的抄表、计费、通断电指令那开发的工作量就非常多，而且还容易出现纰漏导致 bug。

对于物联网设备适配层，通常来说需要下面几个模块：

设备档案：设备档案主要维护设备的基础信息，其中关键的一个信息就是与厂家平台对接的唯一标识，通常会是设备编号或 IMEI。在产品设计的时候，需要考虑支持移动端登记设备档案以及批量导入。移动端登记是方便设备安装的时候边安装边登记；批量导入是应对大量设备的批量录入，提高效率。

接口管理：与不同厂家的对接接口管理，这里有两种处理方式，一是开发直接在代码层面完成，二是通过页面配置完成。第二种会更复杂一些，但是通用性更强。

数据格式配置：将厂家的设备数据转换为业务模块的标准格式数据，和接口管理一样，一种方式是开发在代码里完成，另一种方式是通过配置完成。通常，如果是配置会和接口配置一起完成，将厂家的设备数据字段映射到业务模块相应的字段。

异常监控：异常监控包括两种类型，一个是厂家的服务可用性监控，另一个是业务数据层的监控。可用性是防止厂家的服务不可用导致自有业务的不可用；业务数据层的监控是监测异常数据，方便及时发现业务层面的问题。比如我们的智能电表就遇到过一个极端的案例，由于线路故障导致抄表数据异常。

另外，如果你的产品是 SaaS 平台，那么建议是按照“开箱即用”的理念来设计物联网设备接入模块。什么是“开箱即用”？那就是脏活累活由平台运营来做，客户在业务系统中只需要关注业务模块即可。以我们的抄表为例，我们把设备档案这个最繁杂的工作留给了平台运营层面完成。我们会在平台层面完成设备档案的录入，然后将设备分配给客户的对应的业务单元。到了客户这边，只需要完成业务层面的计费、通断电规则就可以像使用非智能表一样使用我们的智能抄表功能。

总结

本篇以实例的方式介绍了物联网设备接入的产品设计。可以看到，通过引入适配层可以有效实现多厂家设备快捷接入而不影响业务层。对于产品经理而言，在做物联网设备接入或者类似的功能模块时，应当具备业务前瞻视野，提前预判可能的变化，在产品设计上引入应对变化的适配层，从而提高产品迭代的速度、减少开发工作量的同时提高产品的稳定性。