2016年9月12日 • 物联网

物联网逻辑便携性

由AMAR Pararmar.

在模拟世界中，输入设备直接控制输出设备。思考开关，调节电动机的电源。如果开关接通，电源流动，电机打开。然后我们进入了变速和双向电动机。所以我们改变了输入设备。对于双向电机，我们2个开关，具有机械互锁，变速电机具有不同的电压或电流。机械互锁和自动化使方式在PCB上电子，然后给基于软件的联锁和自动化。

随着数据在设备、网络、网络中的网络和云上自由移动，输入触发和处理几乎可以发生在任何地方。它可能发生在输入设备、输出设备、网关、云甚至移动UI设备上。作为一名工程经理，为了满足当今的需求，需要在某些地方添加逻辑(例如，电机vs网关vs云)。然而，从产品和技术战略来看，变化是唯一不变的。我们需要为改变做计划!随着需求的改变，逻辑的位置也必须改变。因此，不仅要在物联网堆栈的适当级别和适当的设备上定位逻辑，而且要有一个框架，使您可以轻松地在物联网堆栈的不同部分之间移动此逻辑。

例如，让我们在家里或建筑中拍一款简单的遮荫电机。阴影从墙壁控制器上响应按钮推动;在笔记本电脑，手机和平板电脑上的应用;轻型和占用传感器;天气模式;时钟事件（天文学和一天时间）;来自互联网甚至机器学习的远程信号。这造成了许多挑战，例如：

在类似的时间内接收冲突命令时发生冲突的命令时会发生什么？
每个消息应该如何优先考虑？如果传感器在手机上以应用程序优先考虑？
应该是命令驱动的（例如，传感器命令它做一些特定的东西）或者应该是事件驱动的（例如，传感器传输它的状态，电机决定是否需要反应）
命令/事件处理应该发生在哪里?所有命令/事件处理都应该在电机、网关甚至是云上完成吗?

工业物联网系统的图像

上述大多数问题通过软件逻辑可解决。逻辑/代码的位置虽然不明显。如果今天是明显的，因为业务条件发生变化，它不是如此明显的几个月，甚至从现在开始。

因此，如果可以描述域逻辑，讨论或学习（值创建作品），那么为什么需要花费这么长时间或使其便携式？让我们来看看逻辑便携性的挑战。物联网堆栈的每个部分都有一个不同的编程技术：

1)我们将从边缘节点开始——这是设备的设备或组件，它包含与传感器和致动器交互的处理/电子。边缘节点上的软件通常在裸金属上运行，这意味着在没有相关操作系统的情况下，该节点上的软件直接在硬件上运行。随着现代嵌入式芯片组(如Intel的夸克)和实时操作系统(如风河的VxWorks)的出现，这种方法开始变得不那么流行了。目前的方法通常涉及RTOS(实时操作系统)，用C或c++进行应用层编程。

边缘节点上的本地控制软件的第一次使命以保护自己。无论设备可能接收到哪些冲突的命令，它是“实时”控制系统的责任，不做会损坏设备或对他人造成伤害的事情。冲突的命令可以包括像上升的东西，后面是一个下来的电机。在执行DOWN命令之前，边缘节点要释放UP命令是责任。这是软件锁定的示例。更复杂的设备将具有更复杂的逻辑。

2）接下来是网关。网关通常是连接2网络和两个网络之间的数据的设备。在工业域中的网关的示例是将Modbus网络与TCP / IP LAN网络连接的设备。在此示例中，协议作为物理层的良好是不同的。

今天的网关通常运行用C或c++编写的程序。然而，客户也开始使用Python、Ruby、Lua甚至JavaScript等脚本语言。像Java这样的企业友好语言也在考虑之中。

因此，根据系统需求和团队能力的不同，网关看起来要么像嵌入式设备(#1)，要么更接近云实例(#3)。

值得注于网关离开的某些情况也很重要。例如，用于通过ZigBee / ZWave通话的恒温器，然后通过网关将其与LAN网络通信。我们开始看到Wi-Fi恒温器消除网关。在运输行业中，一些设备开始通过蜂窝网络直接通信。在智能城市中，窄带网络（如Sigfox和Lora）开始成为强大的候选人。在最后一个例子中，网关通常由网络供应商在城市级别管理，而不是设备供应商。

3）云服务器（通常被称为后端），同时主要使用Python，Ruby和JavaScript等脚本语言。一些Web应用程序使用企业友好的Java和.NET。

在许多情况下，中间服务，数据存储和规则引擎风河螺旋设备云，正在使用亚马逊EC2，Microsoft Azure或IBM的Bluemix。然后将它们与应用程序后端集成。因此，通过API删除逻辑，编辑逻辑。

同时，客户端，在浏览器中运行的是由HTML5，JavaScript和CSS主导。

4）最后移动应用程序要么用母语编写（用于Android，Objective-C / Swift for iOS的Java）。通过Apache的Cordova，Adobe的Phonegap和英特尔XDK平台等应用开发平台，开始使用HTML5，JavaScript和CSS的越来越多的运动。虽然存在动力，但每个方法都有利弊。因此，基于开发人员团队（及其背景），建议某些方法。

这里为逻辑便携性的问题。物联网堆栈的每个部分都以自己的编程语言和工具为主。所以让我们说我们想做边缘节点的健康监控，就像我们之前用过的电机一样。当我们开始外，我们没有足够的相关数据。导致电机失败的是什么？为了解决这个问题，附着测量温度，湿度，振动等的传感器，并且电机部署在恶劣，现实世界的条件下。

由于物联网设备制造商不想让他们所有的产品都承受如此高的传感器成本，他们决定将其添加到他们的高端产品(这是一个更高的平均售价和更少的故障容忍度)。制造商正处于学习阶段，它希望收集尽可能多的数据。收集所有这些分散数据的最佳地点是云。电机将所有数据发回网关，网关再将数据发送到云端。有了足够的数据，就可以做出推断(通过统计编程或机器学习)。该公司现在对故障何时以及如何发生有了更好的了解。它创建了“故障逻辑”，可以从进入云的数据流中预测故障。

然而，从学习中，他们还意识到，大多数数据回来并不重要。数据的非常小的数据（通常小于5-10％）可以预测失败。因此，返回所有数据都没有意义。他们希望将“故障逻辑”部署到网关，并防止额外的数据即将到来。这也将让它们用此逻辑装备其中端产品系列。但是，由于堆栈的每个部分都不同，逻辑不容易便携。不同的团队需要重新创建网关的逻辑（如果存在）。

经过一段时间，公司获得了更多的经验，并意识到逻辑可以嵌入电机控制单元的电子产品。在这样做时，他们可以用这种逻辑装备所有产品。作为奖励，如果早期检测到故障原因，电机可以自调节并防止失败。但是，要将“故障逻辑”部署到电机，但另一个团队需要重新创建逻辑。当我们通过IOT堆栈时，必须多次重新创建相同的逻辑。通过每个重新创建，代码库是不同的，必须在又一遍地找到类似的错误。

物联网设计中心

鉴于合适的架构和经验，可以避免此逻辑可移植性问题并解决了未来最小的搬运工作。许多工具，如FPGA，逻辑脚本（在Lua或JavaScript），机器学习抽象层（培训和分类），常见协议（如线程）可用于解决上述问题。但是，在设计过程中需要提前设想。

一个整体的端到端的建筑，包括边缘传感器和执行器，输入设备，网关，云和移动设备必须被创建。然后，需要将该体系结构分阶段应用到产品中，以确保在公司朝着其未来目标努力的同时，能够立即创造价值。

因此，风河物联网设计中心成立，其使命是“通过连接、安全、交钥匙解决方案帮助客户利用物联网的潜力。”通过这个卓越中心，我们提供物联网咨询服务: