上周末，忙里偷闲跑到北京参加了脑洞猫组织的“第四次工业革命”博世分会场的物联网黑客马拉松，很幸运地获得了智能制造分赛道的第一。

由于邻近活动前不到一个月的时间才决定参赛，团队准备的时间并不算长。而且本来也是抱着让队伍见世面和看看其他人思路的心态来参加比赛的，因此一开始并没有奢望能得奖。所以能有这样的结果不能不说实在是幸运的很！

参赛方案

我们选择的赛道是“智能制造”，简单说来就是将设备数据采集上来，然后分析和展示。既然是博世出的题目，那采用博世相关的技术自然是再正常不过的了。并且，虽然不奢望获奖，但潜意识里当然还是希望我们的方案能够得到关注，因此结合本身的经验，我们决定这次参赛的方案是：“现代工厂健康看板”。

实现方案并不复杂：

1. 利用博世提供的 XDK 将设备数据采集上来，利用 PPMP 协议与 PPM 软件对接，数据存入 InfluxDB。
2. 设定报警规则和相应的事件产生逻辑，这样就实现了实时的数据报警和相应事件产生，如遇到某些报警之后自动创建工单。
3. 数据展示部分直接利用 Grafana ，除了现成的设备运行状态，就是实现指明工厂和设备健康度的算法。

整个方案最大的特点就是：充分地利用了现有的技术手段快速搭建原型，将重心放在业务逻辑的设计部分。由于工业物联网从业者大多是自动化出身，这种纯软实现的方案，尤其是当我们用 Grafana 来作为看板展示时，他们的吃惊程度也给我们留下了深刻的印象，也让我感受到了所谓“跨界”的威力。

这次黑客马拉松最难能可贵的一点在于：不仅有技术环节的比拼，还有商业模式方面的讨论。这也完全符合我个人的观点：技术不变现，再牛也枉然！相比起来，我对于我们提出的商业模式略带自信，因为它也是这些年创业思索的结果：

1. 目前，面向智能制造的工业物联网充其量只是传统自动化的升级改造，基本上可以视作传统 MES 的变体。
2. 智能制造应该向互联网行业学习，不应只专注于单点，而应采用类似流量思维的做法，学习互联网行业已经成熟的“引流 - 转化 - 变现 - 导流”模式。
3. 只有形成自有的流量生态体系，智能制造的从业者才能不那么苦逼，感觉相比起其他分赛道（如车联网或智能家居）低一等。
4. 智能制造的供应链本身也具备形成流量的能力和条件。

纵观博世分赛场，像我们这样站在产业层面去讨论商业模式的队伍并不多。当然啦，你也可以说我说的有点虚，但很多事情不都是先虚后实么，;)

比赛亮点

说实话，由于这次组队的 3 名队员全部是纯软出身，一开始我们对于设备数据采集这部分是有些担心的，毕竟之前都没有特别强的自动化现场经验。好在博世的 XDK 帮了大忙，借助它自身的传感器，我们很好地完成了任务。而且，因为技术背景的原因，我们的脑回路明显跟自动化工程师不太一样，我们的采集和检测方案也让博世的工作人员大开眼界，连连称奇。

具体检测方案我就不再赘述了，这里推荐一下博世的 XDK。从我们的使用感觉来看，的确能配得上博世宣传的“XDK 是物联网开发的瑞士军刀”。

• 它内部集成了很多传感器，开箱即用。
• 支持扩展，对于没有的传感器可以通过扩展实现。
• 开发门槛不算太高，只要有 C 语言基础就行，常用功能也提供了封装库，降低了编程难度。
• XDK 配备了基于 Eclipse 的 IDE，通过 IDE 不仅开发方便，也可以很快地将程序下载到 XDK 中。

但是，请注意：不要把 XDK 当做现成的解决方案来直接包到你的产品或解决方案中！理由很简单：

• XDK 的价格不算便宜
• 你并不需要 XDK 所有集成的传感器

并且连博世自己都说：XDK 主要是面向开发人员使用的。因此，XDK 正确的打开方式是：

1. 将 XDK 作为开发物联网方案的一个工作台
2. 在开发完软件之后，设计自己的硬件，将开发程序烧入其中调试，最后量产。

XDK 采用的是 FreeRTOS ，因此嵌入式软件层面的问题并不难解决。总得来说，XDK 有助于你降低进入物联网开发的门槛，甚至在多数时候纯软出身的人都可以直接上手开练。

有趣的是，在赛前培训环节，意外地发现博世智能制造部分相关的软件技术栈跟我们还有些许重叠，比如：

• 都使用了 vert.x，于是很自然我就自卖自夸的安利起了我自己写的 vert.x 系列文章。
• PPM 采用了 Agunlar.js，我们之前使用过，目前已经升级到 Angular。
• 数据也是分业务数据和设备数据分开存放。

不过说实话，我对于设备实时数据保存到 InfluxDB 中并不是很感冒。主要有两个原因：

• 历史原因，当初我们选型时 InfluxDB 还不是太稳定，这在工程上没法接受。
• 基于 PG 的时序数据库 TimeScaleDB 本身也不错，在多数场合下有助于降低开发门槛。并且由于是以 PG Extension 来实现，因此在使用和运维上与一般数据库差别不大，还能利用上 PG 本身丰富的 Extension 和能力。这样，业务数据和实时数据在一个数据库内保存就行了，运维成本大大降低。同时，我们也做过压力测试，表现还不错。

不过，InfluxDB 的生态很不错，围绕其诞生的 TICK 也还是有可取之处，可视为 InfluxDB 版的 ELK。尤其是其中的报警处理框架 Kapacitor，我很喜欢。由于将报警处理外部化，提供了不错的 DSL，这使得报警处理更加灵活。

写到最后

最后，说说我的感想吧。

作为一支纯软队伍，通过这次参赛，我们依靠自己的力量完成了对于一个小型自动化产线数据的采集和故障检测，并且还有幸拿到赛道第一，必须得为自己点赞。整个活动内容很丰富，后勤工作非常到位。同时，博世对活动的重视程度也让人体会到德国工业巨头的严谨：

• 配备了大量的工作人员。
• 专门从常州工厂运来一台工业设备来支持比赛，充满真实感！
• 为每位参赛选手提供的纪念奖品（限量版电动起子）更是让人觉得这么辛苦真是值了！

并且，通过参加这个活动也认识了不少优秀的同行，看到了不少有意思的 idea。这都得要非常感谢主办方辛苦组织活动，促进各方交流和脑力激荡，谢谢！