华为云IoT，敢问路在何方？（一）

写这么庞大的主题绝非笔者的本意，笔者也无力驾驭这种题目，不过，既然在 《20年华为扫地僧，揭开亿万级路灯互联的智能奥秘，参与社区互动赢好礼!》（链接：https://bbs.huaweicloud.com/forum/forum/thread-63672-6-1.html  ），笔者一不小心得了一个茶杯，所以发个博文，根据大家的想法讨论下可能的路径，还是可以的。（然而只是标题党，因为题目错进来的朋友们可以小白退散了）

让我们从一则真实的小故事说起吧，一位也很想得到这个茶杯的朋友（简称L），希望LiteOS能够增加图形化编程功能，以及多跟AI结合，提供相关的平台服务（参见29楼和52楼，当然后者已经被作者删除了。。）其实他的文字还是非常不错的，有图有文，有理论有实例，还有三名辅助提供了资料。眼看着茶杯即将到手，然而一位眼熟的M同学，接着L的话题又谈了多个场景。而我又看到这个讨论很有意思，通过一个回帖加入他们的讨论，我的原文是这样的：

哈哈哈，为了茶杯真是拼了吗？那我也接着52楼和54楼的同学的建议来说一下：

1。LiteOS图形化编程

作者的意思是将LiteOS端的代码写成像Scatch风格的图形化吗？我个人认为，如果像打解包工具这种，倒是可以考虑由现有的IoTDA的云端的物模型中，倒过来生成一份LiteOS设备端的解析代码。这样确实可以减少设备端的开发量，而且正好可以完全匹配云端的解析，相当于，一套配置，设备和云端同时生成不同的代码。这样可能会更有意义点。

但是，现在LiteOS本身就是用C语言做编译比较合适。而且做了这个，也同时可以做起其他ARM芯片的物联网设备的编程，换成图形化界面之后，是否合适，还有待商榷，个人认为，可能不是很恰当。当然可以考虑推出一些积木式的开发工具，但是也要考虑跟现有LiteOS的任务、终端、信号量、内存、互斥锁，这些基本功能的融合。与其这样做，不如做出一些C语言的模板出来，供物联网开发者参考。

况且，从LiteOS轻量化的要求来看，图形化可能带来的是代码的冗余和略重。可能回导致都烧录不到小熊派等设备中去。我有次就遇到一个问题——烧个Logo都不能用WiFi而必须用NBIoT，就是因为包太大了。我当时就提出“WiFi应该是允许更多信息传输才对，怎么反而信息少了”这种质疑。所以与其考虑在图形化动脑筋，不如还考虑在如何压缩代码量，提供优化的压缩算法等方面为LiteOS端的编码做点贡献。

2。AI技术跟IoT的融合

这块IOT这块本来就有AIOT的教程——《深度学习：IoT场景下的AI应用与开发》。其中3.2节已经提到了使用数据接入通道DI、对象存储服务OBS和ModelArts平台跟IoT平台做交互。因为LiteOS本身是个轻量化工具（只有10K），本身不可能提供AI的能力.如果要IoT能AI结合，也就需要在设备端利用云端强大的计算能力，通过调用云端API的方式完成AI计算，并从云端取回结果，而不是将AI计算在设备端实现。

像HiLens，或者是Atlas-昇腾这种，都是在设备端（边缘端）有强大的计算芯片，方可完成AI的计算行为，但是IoT基于这方面的限制，按理说至少在目前是做不了AI本身的事情的。当然，我相信随着科技的发展，可能会将更多的技术融入设备端，但就目前LiteOS而言，感觉先结合起来就可以了。希望IoT团队能在AI融合方面出更多的样板实例，供开发者参考。ModelArts团队也可以提供更多的AI市场产品，通过API Explorer授权发布给IoT设备使用，让IoT设备变相的具备AI能力。

确实，我对他的话理解有误，结果他又在我的回帖中做了评论，我们又在评论中交互如下：（我简称I，他继续简称L）

L：真是为了茶杯拼了。。。。 Arduino Nano 33 BLE 和 STM32F746G 开发板可以使用TinyML。 物联网世界里，有数以亿计的体积小、功耗低、资源受限的设备支撑着物联网应用。如何在超低功耗 (mV 功率范围) 的设备上运行人工智能应用，同时又要满足设备长时间低功耗的运行 AI 应用的需求，已经形成了一个新的课题。 TinyML 指的是在 mW 功率的微处理器上，实现机器学习的方法、工具和技术。它连接了物联网设备，边缘计算和机器学习。

L：图形化界面不是你理解的这样

I：来来来~~主要是IoT的理解范围问题。广义的IoT范围很广，LiteOS仅仅是其中的一小部分，我们可以认为，阿里的、腾讯的物联网OS，甚至树莓派Andruno都可以是物联网设备端的一部分。你所说的边缘设备，HiLens，工业互联网网关、泰山，各种带有或者不带有智能单元的单片机，也可以是物联网的一部分。那么，如果华为的IoT产品要发展，势必要考虑不仅仅是支持自家厂的产品，也要支持其他的产品，也就是不仅仅基于LiteOS。其他什么OS都可以。但是从窄一点的理解来说，目前就现在跟小熊派的推广而言，也还暂时没有形成产量。Hilens团队也是其他的团队。工业领域、家庭领域、社区领取、教育领域等各种垂直应用也并没有到上规模的地步。我们如果考虑这方面的话，个人觉得首要的思路是把华为LiteOS的周边生态给搞好。然后再去想不是LiteOS的生态

I：你说的那个TinyML确实很不错。但是这东西能否放在现有的LiteOS上现在都存疑。且不说LiteOS设备本身的算力问题，就拿它系统包大小来说，TinyML能否装入进来都是个问题。当然这点需要LiteOS本身的产品经理来考虑是否需要给LiteOS填上AI的翅膀。或者说另辟蹊径搞个别的什么物联网OS直接就是支持TinyML的。现在小熊派自己连个内置系统时钟都没有。在这条设备端机器学习的道路上，我认为还有很长的路要走。

当然，L同学因为后来没有中奖，他认为官方的评判标准有问题，就删了52楼的回帖。虽然我本人可能是构成了对他33.33333%的奖品竞争关系，我依然认为这是一个不得多得的人才，有想法而且能很好地表述出来。（其实官方可能欠他一个茶杯——当然，不是我的那个。。。）

其实L同学提出的两个角度非常好，图形化是从如何快速搭建IoT设备的角度，AI结合是从他对TinyML设备端AI趋势的深度理解的角度。这也是我下面要提到的比较能够切题的部分。（感谢L，没有你就没有这篇博文）

我们一个一个来谈：

首先说图形化编程，我们想想，图形化的目的是什么？所见即所得，用户零门槛入门，快速搭建目的原型和实现功能。将内涵的技术点都尽量屏蔽，让用户集中精力在业务的实现上。——其实，这不就是我们无论是Ocean Connect、IoTDA、还是沃土数字平台AppCube、还是其他的一切可能的好产品，努力想实现的目标吗？降低用户的进入门槛，就可以吸引更多的用户。举个例子，乐高机器人大赛之所以吸引了不少小朋友参加，就是因为乐高提供了一套积木，加上一些基本的组件（如轮胎，传感器，马达等），使得即便是小朋友也能实现快速的机器人开发。（而小朋友脑洞大开，思路可能比成年人更惊奇，所以成果也会更丰富）。所以说，这种想法是非常的好。

我也期待某一天，我能使用图形化工具，工具给我一些组件（如各种温湿度、气压、水质、PM2.5、陀螺仪。。。等各种传感器，马达、风扇、警铃、灭火器。。。等各种控制器，加上金银铜铁锡等各种材料），通过拖拉拽的方式，快速地将一个简易模型设计出来。然后，如果可能的话，通过超级无敌的3D打印技术，将我所需要的设备打印出来。另外，在布线和制作电路方面，结合设备形状和电路性质，也能够所见即所得的通过一些智能技术，生成电路板或者接线图。在外形和电路都符合的情况下，设备就能快速成型了。这是对于设备的硬件制作方面，能够达到的一个高度（我想的高度）。

那么，在以上的基础上，我们考察上述传感器和控制器使用的场景，就可以继续使用图形化的方式进行编码了。比如这些传感器上送哪些参数到IoTDA，自己本身根据传感器获取的参数，在本地如何驱动控制器进行处理。在云端也可以根据条件驱动设备进行处理（这些功能已经有一部分IoTDA已经具备了。）这些都可以用物模型的方式进行编程。而我第一个回帖中提到的“一套配置，设备和云端同时生成不同的代码”这个思路，其实就是能保证设备和云端一致的编码方式。云端的物模型生成好设备端所需的代码模块，通过下载到用户设备端开发环境，或者直接下载到设备的方式，快速进行设备端代码的实现。

有了设备硬件，有了设备软件，IoT设备的诞生就这么简单（貌似这应该是本文的标题。。。）。

但是确实还是要回到我前面回帖提到的场景，在使用LiteOS为华为IoT设备端基础操作系统的情况下，以上的实现是否可能？从现有的LiteOS看，个人感觉可能性不是很大，但是从LiteOS长远的发展来看，只要想得到，其实就可以做得到的。只是可能硬件的基础已经不是小熊派，也不是LEGO，而是华为高，简称HUAWEIGO（这个名字是我突然想的，是不是应该注册下——对，华为你自己注册下，HWGO，HDCGO，HUAGO，除了HUGO不可以，估计其他都可以吧？）了。（隔壁小熊派老王会不会气晕过去。。。不管了。。。）所以在这方面发起这一探讨，还是很有必要的。

至于AIoT的IOT与AI结合的话题，感觉在这篇文字中已经展不开了。我们下次再说吧。。（留下伏笔，是为了多发一篇。。。）