<p>互联网“行业”如火如荼的发展，曾经也想过转行去做“互联网”，奈何犹豫太久，已然提不起太多兴趣。凭借当年的沉淀与积累，有个半成品的框架，在工作索然无味的情况下，毫不犹豫的投身到物联网框架的开发与产品化的进程中。别人都说物联网的时代来了，如果真的是这样，也不知道是自己的选择好，还是命好。</p>    <p>这方面的工作纯属个人爱好，业余时间在干，一般晚上21点到23点是自己的第二个工作时间。这两年积极的投身到新的框架开发中，提高性能、统一接口、跨平台……等方面的工作。也做了自己的基础硬件产品，智能网关。</p>    <p>有人会问，那你正式工作是干什么的？在某集团公司工业版块负责大数据建设的相关工作。在没有大数据、云服务概念的时候，做过远程E服务相关的项目。说实话，对于传统行业来讲，是很困难的一件事。但是作为企业来讲，要么等死，要么在改变中死，完全在于自己的选择。</p>    <p>2. <strong>占领大脑和丢了脚</strong></p>    <p>不知道从什么时候，物联网、大数据、云服务、云计算……等一批概念流行起来。大厂都在争夺高制高点，大数据、云服务、各种标准……，做这些事情都很有意义。但是我在想，大家都去占领大脑，脚就不重要了嘛？！显然不是，应该是同等重要。华为设备部、中兴仪器仪表……对于基础物联层，也是很头痛的一件事，这是大厦的根基，特别是工业领域。所以，我坚信对于我们的框架有很大的市场应用空间，创造的直接价值那是另外一回事。</p>    <p>3. <strong>物联的现实困难</strong></p>    <p>对困难理解的前提是对现实世界的认知，有些传统制造业都不具备物联的基础条件，更谈不上物联网、智能制造、智能工厂，但是至因为落后，才有广阔的市场空间。就算有物联的基础，条件比较落后，底子比较薄，面临四个多样性：设备多样性、协议多样性、通讯机制多样性、数据多样性。这就是我们面临的问题，难道问题有多大吗？为了生存，企业都说能做。但是结构化的多样性问题，要用结构化的手段或框架来解决，这是各方面保障的前提。</p>    <p>4. <strong>效率与成本</strong></p>    <p>接触一家上海公司，有专人负责网关层的数据采集，有专人负责服务（云）端的对接，不太稳定、经常出现问题。解决细节问题，不能用细节的思维方式去解决，而是要有更广阔的思维、结构化思路才能够彻底的、更好的解决问题。网关层、服务端是否可以使用同一套框架？并且框架之间是否可以无缝对接？如果可以实现，应用同一套框架，开发效率会提高，用人成本和时间成本会降低。好的组织结构、好的框架总之要解决效率和成本，否则没有任何价值。</p>    <p>5. <strong>逆向思维</strong></p>    <p>大厂都在搞云平台、协议标准……，当然他们有资本和实力这样搞，软件用他们的、硬件用他们的，对于他们来讲，养这么多人，反而成本是最低的。他们奉行一流企业定标准，用这种思维模式去整合资源，竞争比的就是占领资源的多少。我们认真考虑一下，对于传统企业来讲，本来生存就很困难，和房地产、互联网拿投资的没法比，他们有能力一下子完全统一化的更新换代嘛？！参加上海工业博览会，也进行了市场调查，简直是开玩笑。我们再认真考虑一下，用框架性的东西去解决设备多样性、协议多样性、通讯机制多样性、数据多样性的问题，在物联网和集成系统的建设中是否也是整合资源的一种手段？！先解决企业互联监控的问题，再解决企业标准化的问题，这样是否也是一种思维模式？！是的，我们就先这样干！</p>    <p>5. <strong>智能网关，跑Windows 10 IOT</strong> <strong>和Ubuntu Mate</strong></p>    <p>网关在物联网和集成系统建设中是重要的一个环节，实现数据的初步整合（采集），再进行数据的转发，形成体系层次清晰的级联网络系统。市场的网关大至分为两类：纯硬件接口的转换、搭载操作系统的小型机。当然也有在硬件基础上搭载自己的软件框架，但是不多见。在我们的智能网关上可以实现搭载我们ServerSuperIO物联网框架，使软件和硬件无缝结合，设备驱动的接口统一，可以开发一套驱动跑在不同的嵌入式操作系统上，Windows 10 IOT和Ubuntu Mate，对于系统建设的方案选择更灵活。</p>    <p>智能网关的硬件配置：</p>    <p>l  四核1.2GHz Broadcom BCM2837 64位CPU。</p>    <p>l  1GB RAM。</p>    <p>l  板载BCM43143 WIFI和蓝牙低功能耗（BLE）。</p>    <p>l  40引脚扩展GPIO。</p>    <p>l  4个USB接口。</p>    <p>l  全尽寸HDMI，并且转VGA接口。</p>    <p>l  微型SD卡端口，用于运行操作系统和存储数据的介质。</p>    <p>l  升级切换的微型USB电源，高达2.5A。</p>    <p>l  可搭载的操作系统：Ubuntu Mate、Windows 10 IOT。</p>    <p>智能网关实体机照片：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/0f943e748e9891f9193afea89bdd0957.png"></p>    <p>6.SuperIO <strong>到ServerSuperIO</strong> <strong>发展历程和解决的实现问题</strong></p>    <p>  SuperIO&ServerSuperIO最早的雏形于2010年开始开发，当时主要是解决公司内部硬件产品众多、协议众多、以前的软件经常出问题、维护成本高、搞集成系统时各方面都很累。经过两三年的发展，确实解决了公司内部的产品体系问题，所有硬件产品都可以挂载到平台下运行。离开公司之后，感觉这个平台从代码、应用等方面还有很大发展空间，2014年逐步产品化后才形成了SuperIO（SIO）这个平台。</p>    <p>但是SIO也只是解决了设备驱动（众多协议）插件式挂载的问题，不过只限于运行在Windows系列操作系统下，一般性的PC机和工控机上数据采集完全没有问题。但是在运行效率方面还有很大提升空间、设备驱动的接口还可以进一步标准化（为了各层级都可以应用）、跨平台运行必须攻克、设备（驱动）之间信息交互与控制必须实现、框架在不同层级应用的级联与控制必须实现、多服务实例的应用等等，一系列的框架和技术性问题还可以进一步完善。从整体物联网建设的框架性方面考虑，从2015年初开始，基于SIO的核心思想重新开发新一代物联网框架，也就是现在的ServerSuperIO（SSIO）框架，经过两年多的发展，搭载在智能网关的基础上，可以形成综合性的解决方案。</p>    <p>7. <strong>一套设备驱动，支持多种IO</strong> <strong>通讯</strong></p>    <p>不管是zigbee、wifi、有线网络，还是RS485、RS232、RS422，总之主要分为两种硬件接口：网口和串口。至于OPC协议，可以用SSIO服务接口的形成间接实现，形成服务插件的一部分。如果不结构化的设计IO，网口和串口独立存在，随着产品越来越多，是很头痛的一件事，也不一定运行稳定。对于ServerSuperIO框架，在此基础上开发一套设备驱动可以分别实现通过网口或串口与硬件设备（传感器）进行交互，非常方便。有人认为通讯很简单，其实如果把众多问题都考虑进去，那么将变得很复杂。也有很多纯网络通讯框架，业务场景、通讯机制的不同，纯网络通讯框架也未必能够完全的适用于现场环境。</p>    <p>示意图如下：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/7ce636287eaaab04b23c5dba21072993.png"></p>    <p>8. <strong>一套设备驱动，统一接口，多种平台挂载运行</strong></p>    <p>针对ServerSuperIO框架的设备驱动接口进行标准化设计，另外针对ServerSuperIO框架本身进行了跨平台运行的移植工作，所以一次开发设备驱动，可以在多种平台下挂载运行。现在支持的平台包括：Windows xp SP3以上的版本操作系统（包括Server）、Windows 10 IOT嵌入式操作系统、Ubuntu&Ubuntu Mate操作系统。</p>    <p>示意图如下：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/9e494a8033f9c91519585b74d0846aef.png"></p>    <p><strong>9.</strong> <strong> 物 联 通讯的级联 </strong></p>    <p>如果单单是采集硬件的数据与控制，也只能算是本地的系统，但是在物联网和集成系统建设中，必须形成体系化、网络化框架。所以ServerSuperIO在采集本范围内的数据信息与控制外，还要形成与上一级的ServerSuperIO进行数据交互，以及接收下一级的ServerSuperIO的交互数据，那么ServerSuperIO之间就形成了级联的关系，主要完成两大职责：数据的级联上传和反向控制，进而对设备本身进行级联控制。</p>    <p>结构示意图如下：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/e1c0be654b41c55756becb1f949753a7.png"></p>    <p>10. <strong>设备之间的通讯、控制</strong></p>    <p>采集与控制单个设备，在实际应用中还远远不够，还要能够设备与设备之间进行信息传递与控制，并且返回给发送控制源设备确认信息。例如：在监测流量计严重报警的情况下，是否应该调节或控制液体源头的阀门。类似的例子很多。</p>    <p>在ServerSuperIO最新的3.1版本中（还没有发布），支持设备向另一个设备发起传递信息和控制后，被控制设备是否立即返回确认信息，还是自主异步决定返回确认信息。增加了异步返回确认信息的功能，因为控制命令只是发给了另一个设备驱动，设备驱动还会进一步与实际的硬件设备进行交互，与实现硬件交互成功后，再返回确认信息给发起的源设备驱动。</p>    <p>示意图如下：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/0d35a94c4506895281a4cf0bca3b83f6.png"></p>    <p>11. <strong>与云端的交互、控制</strong></p>    <p>ServerSuperIO提供了服务驱动的接口，一些除设备驱动类的功能以外，都可以以服务驱动的方式存在，例如：多设备采集的数据的融合模型计算、与其他平台或上层进行交互等等，在此仅以与服务端进行交互为实例进行介绍。与设备驱动之间的交互与控制不同的是，设备驱动主动把采集的数据信息传递给服务驱动，服务驱动与云端进行交互，在接收云端指令后，发起传递信息或控制设备驱动，设备驱动再返回确认信息给服务驱动。</p>    <p>示意图如下：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/9e6e8e3de1e9048421b59f2b8b9c08b7.png"></p>    <p>12. <strong>未来的规划</strong></p>    <p>从大环境来讲，肯定是有很广泛的应用；从本公司来讲，将来在工业基础物联层面，肯定也会用的上；从个人兴趣来讲，也乐意能够继续做这方面的工作，当然是除正式工作之外。</p>    <p>从ServerSuperIO本身来讲，3.1版本（未发布）对代码进行优化以及增加了异步返回确认信息的交互能力。后期会增加对数据安全方案的验证机制，以保障在工业领域应用数据交互与控制的安全性。另外从体系结构来讲，以ServerSuperIO框架为基础，增加云端的建设能力，例如：数据分布式持久化等。从嵌入式应用为讲，要增加远程可配置能力等。</p>    <p>13. <strong>结束语</strong></p>    <p>在现在的社会，长期坚持做一件事很不容易，做成产品级以及配合体系方案更不容易。慢慢往下走吧，希望机会会眷顾那些踏实、实干的人。</p>    <p> </p>    <p>来自：http://www.cnblogs.com/lsjwq/p/6185169.html</p>    <p> </p>