[嵌入式]关于工业物联网的10个笑话

一、没有周期对时机制，抄需量或事件发生时间。走不准的表上还设置个闹钟？功能不闭环

现场多少准的多少不准的，差5s的多少，差30s的又是多少？不准的为何？有没抄时钟电池电压？电池内置外置？欠压的如何更换？

二、嘴上吹的各种预测、推理诊断、AI、各种高大上的统计分析。实际自己的项目交付们采集x种设备y个点z频度办多少M的流量卡套餐还要靠人肉估，连个历史结合档案的统计分析参考数据都没有。

三、拿不出个日或周数采报表，日采集成功率多少？失败的为啥？下行控制的成功率多少？失败的为啥？耗时多少？不用接收现场工况反馈的？这些是程序优化的依据。盖房先搭好脚手架！

四、mqtt自定义协议的不足

众所周知，数采领域细节多如牛毛，现场复杂不明，从下到上影响环节众多。不可否认mqtt协议框架相比于二进制协议的一些优势，但仍有一些缺陷。

1. 各处程序员私定的协议非标、互不兼容、无法互联互通或做到互通需要额外配置工作量、协议不成体系影响数采功能闭环、实时历史事件、下发上报、应用层确认机制、关键信息重传确认的可靠传输、绑死特定厂家平台。形成单点依赖，单一采购来源，后期夹带私货、漫天要价、功能拉垮后患无穷。不公开透明，说的清，必然藏污纳垢。采集到数据只是万里长征的第一步。愚弄用户者，在用户幡然醒悟的那一刻必然失去被信任。把别人当傻瓜往往最后自己成了傻瓜。
2. 滥用主动上报

应在关键数据（如事件）或时效性要求高的数据使用主动上报，滥用会挤占通道资源。断点续传历史数据、当前实时数据、平台统计计算需要及时补全的实时历史数据三者优先级先后传输顺序不灵活或者实现不一。主动轮询采集并非一无是处。

????3.需要的是数据池子而不一定是管道

Kafka、mq等均属于管道只支持顺序读写，先进先出。无法从中间增删改查干预。有时候需要的是随机读写，数据池子更合适。

? ? 4.mqtt中间件屏蔽了一些通信状态，想想EMQX配置文件里面众多client、session、message的相关配置吧

? ? 5.就一个断点续传，100个人有100种不同的实现细节。续传和当前优先级处理，限流等等。

五、协议实现的糙，缺乏实践积累、缺乏接收现场反馈

1、单点调度？自动批量组帧读写，可手动人为干预自动批量组帧？

2、单一链接读写优先级调度与并发不当。

3、写完立即被写点回抄，而后全量回抄？

4、历史数据补抄？事件数据采集与利用？数据不全则业务功能不闭环。

六、档案管理混乱，加上基层流动性大项目运维像考古，多少项目最后在造数据？

档案包含项目从上到下的各种工程配置历史记录，方便监控、追溯、项目运维、输入与输出关联查询统计分析闭环。代码首先是给人看的，项目亦然。实施配置调试门槛高、资料档案传承困难。特别是底层如各种网关，所谓边缘计算的工程配置更是在平台失管失控。

七、各种数采盒子

1、硬件上槽点一大堆：型式规范、EMC可靠性、检验检测、成本价格，整个三无产品。

2、软件上资源占用、整个工程配置导入导出复用、弱网下支持、协议与通信链路的车与路未分离等等简直是开倒车。

3、传统网关与通信管理机具备的通道导入导出、整个工程配置的导入导出复用在盒子这里简直是比登天还难，无法级联作为中继，建议凡是带盒子两字的都不要用。

4、上行转发大多只支持自定义mqtt协议，不支持其它标准协议的转发。就像汽车没安全气囊一样，哪一天甲方说加个数据对接等着后悔吧。

八、又重又大概念又多，操作复杂，功能复杂，逻辑概念多，物理与逻辑层层转换与对应造成溯源反查困难，吃硬件资源、吃人力资源、缺乏生产实践

IT搞OT，嘴上名词术语一大堆，什么数字孪生、云边协同。实际用起来啥也不是痛不欲生，做一个项目点坏几个鼠标的恶心别人。远远不如传统组态软件。地主家烧钱习惯了，不知道甲方是否跟得上。吹牛能吃八碗饭，但家里连八个碗都没有。缺乏实事求是的常识。

九、没有前提、不符合正态分布的大吹指标。秒级采集、毫秒级下行控制。就像说所有的员工都在9点0分0秒到公司一样。用时一时爽，运维扩展火葬场。

十、所谓的物模型

我不反对各种模型，模型应该在最后一环就对应映射，而不是从上扯到下，扯到现场调试里去搞清模型。所谓强龙不压地头蛇，了解项目现场是个循序渐进的过程。没人一开始就能彻底搞清现场的情况，有几个怎么接的点对应搞不清很正常。扯到底层等于把硬骨头抛给弱势群体，从下到上的修改麻烦。关键是错误了不要紧，能补救即可。如果原始的历史数据在平台在上层，对应错了、系数错了没关系，改对了把之前的历史数据重新跑一遍计算即可。请问当物模型在底层能方便代价低的做到嘛？