2016软件新趋势：物联网框架/开发占据主流

　　当前物联网(IoT)大潮奔涌不止，畅游其中的乐趣岂是隔岸观风景之人所能体会的?绝大部分物联网框架变得有血有肉，不再是空架子了，玲琅满目的选择更是让人眼花缭乱。

　　随着越来越精细复杂的开发工具增加了安装和集成成本，云技术逐渐成为主流。公司可以选择雇人来安装、支持和维护这些工具，但开发者则需考虑长期的支持。

　　安全和软件质量至关重要，也更费时费力些，所以在一般的嵌入式空间中也常常被忽略。谁都希望安全有保障，代码零漏洞，但这两者的界限又在哪里?大多数软件项目真正的意义又是什么?对于非联网设备而言，安全当然不是问题。

　　物联网软件

　　即使是物联网最基础的设计(见图)，也要同时处理不同参与实体的界面和连接问题。虽然IoT有诸多优势，还潜在创造了灵活的环境——然而复杂交织着的网络背后埋伏着更多故障和攻击，要勤于维护才好。整个系统要运行流畅，所有部分都要运行流畅，数以百万计的终端节点和网关牵涉其中，一旦出了问题，后果将是灾难性的。

　　公司和厂商正积极解开物联网框架和环境中的“死结”，不断扩展功能和覆盖范围，增加合作伙伴。很多IoT标准组织的前身都是IoT框架设计的厂商组成的团体。2016年当设计理念转变成真实的框架，开发者就可以对其进行检测并加以利用以开发IoT解决方案。

　　公司和厂商正积极解开物联网框架和环境中的“死结”，不断扩展功能和覆盖范围，增加合作伙伴。很多IoT标准组织的前身都是IoT框架设计的厂商组成的团体。2016年当设计理念转变成真实的框架，开发者就可以对其进行检测并加以利用以开发IoT解决方案。

　　虽然如此，还有一个问题仍挥之不去：IoT开发空间中的选择数不胜数，但互操作性也随之被限制。

　　IoT是否安全?

　　软件质量和安全相互关联，错误代码往往导致了安全漏洞，进一步阻碍了物联网发展，因为设备彼此连接之后，远程攻击的风险就难以避免。

　　大多数IoT框架会结合多种安全措施，比如使用通信链接上的传输层安全(TLS)或者安全启动等。加密至关重要，带内置加速的硬件也越来越多，安全密钥存储(secure key storage)，甚至反篡改支持(anti-tamper support)也越来越常见。

　　开发者仍要解决的，是将安全措施纳入设计来抵抗安全攻击;心有余力不足时，也就无暇顾及应用的其他功能特性了。框架和基于策略的安全支持有用，但无法根除安全问题。有些框架和系统声称能处理所有安全问题，其实这种情况很少见，若真如此，系统保护会容易很多。

　　很多IoT开发都是用C语言完成的，这为开发者带来了不便。而很多安全问题都是由于不懂运行原理或粗心大意造成的，最终不得不为框架添加安全措施。静态分析等工具通常支持MISRA C++和新的MISRA C:2012标准。

　　很多之前仅限于军事和航空电子学的方法也逐渐进入产业应用开发领域，运输和自动化领域的公司尝试用Ada和SPARK等编程语言为嵌入式实时应用提供更好的开发环境。常见于正式实验的功能性编程语言也适用于云技术领域，比如系统控制，财务计算和分析等等。

　　“云”端之上

　　不是所有人都愿意涉足云开发领域，但软件厂商一直积极推动着云技术革新，开发者也发现了很多机会。

　　几十个IDE(集成开发环境)云系统/网址可供选择，很多IoT解决方案供应商也在跟这些网站在合作来提升自己的服务，之前也有厂商跟Github和Pastebin等网站合作成功的先例。Cloud9和mbed，甚至Arrow Cloud Connect网站都为ARM Cortex-M0+提供嵌入式IoT支持。

　　Codevny等则利用云服务器来编译和创建服务，提供的上线支持不亚于基于工作站的工具(比如Eclipse)。Wind River的Helix环境包含Helix Lab Cloud，开发者可以用于在云端硬件上测试自己的应用。

　　免于安装、管理和支持为开发者省下了不少麻烦，他们还能接触到最新软件。但另外一些问题也不能忽视，比如为某一版本的应用保留工具箱和运行时间支持。

　　在线开发对于软件厂商来说相对可控，但对不擅于控制代码和工具的人来说不一定了。网络连接质量怎样、流不流畅都很重要——只有可靠、高速的网络连接才能保证云技术的流畅运行。

　　有了协同支持，云解决方案就能超常发挥，对于跨越多个硬件节点的IoT应用来说这一点至关重要。可惜这一类协同支持在独立运用工具时难以集成。

　　开发者工具集成

　　云环境离不开工具集成和支持，但厂商也不会忽视传统的开发工具链。提供IDEs和编译器之外，他们还纳入操作系统和堆栈来加强工具集成和支持。如今这两者都远远强于过去。厂商为了留住用户，就得比对手提供更多的选择。

　　有时这种集成很有针对性，如Renesas的Synergy针对Cortex-M微控制器的Synergy line，是以Express Logic的Thread-X RTOS为中心创建的。Microchip的Harmony框架则包含诸多第三方组件，更具包容性(见“Interview: Rich Hoefle Presents Microchip’s Harmony”)。

　　两种方法对厂商和开发者来说各有优势。更有针对性的集成能提供更好支持，但、选择范围有限。开发者需要考虑使用这些框架和工具的间接成本，毕竟天下没有免费的IDE，硬件成本等稍不留神就会冒出来。

　　开源软件和IoT

　　开源软件(OSS)和专利软件相互影响着彼此。对于IoT而言，由于参与各方互相协商来统一标准，合作就促成了OSS重头戏的角色。从Linux支持到开源许可软件，厂商可适时用OSS来提升自己的服务，但也不能随心所欲地使用OSS，需要考虑将优势和收益最大化;相比之下，所幸很多开发者都乐意为工具集成和支持付钱。

　　一涉及到安全问题，开发者和公司都要顾及到OSS许可相关的标准。开发者可能要利用Black Duck Software来追踪编译，安全和应用相关的管理问题(见“Is it GPL if it quacks like a Duck?”)，而选择专利许可软件通常更明智，缺点是选择范围有限，在IoT应用环境中，IoT包含太多成分时更是如此。

　　别忘了节能软件

　　移动IoT设备需要考虑高效节能硬软件。一些较精密的硬件在电源控制和配套外部设备上差距太大，因而需要更有效的节能方案。管理不同的电力模式，还有那么多外部设备，芯片厂商不得不提供与应用和操作系统配套的节能框架。

　　安装电池的IoT设备通常采用低耗电模式。要选择低耗电的，从FRAM一类的非挥发性内存，到超低耗电的外围设备芯片，再到利用可配置的智能外部设备相互连接，实现芯片独立于CPU的运行……开发者需仔细斟酌再做出选择。

　　注意：非对称的多芯微控制器解决方案能进一步扩大能耗控制和性能间的鸿沟。复杂的编程环境虽有不足之处，但可以有效隔离系统安全风险。

　　IoT并不意味着一切

　　IoT颇受开发者和厂商持续的关注，但其本质还是嵌入式软件平台。IoT的迅速发展让越来越多公司开始制定相关的长期规划，同时需要考虑如何利用这些解决方案来增加收益。

　　但话又说回来，IoT并不意味着一切，也尚未普及，开发者应切忌盲目跟风。另一方面，很多IoT工具和支持也适用于传统的嵌入式应用。云开发工具也可用于非IoT开发，安全硬软件不管是否是IoT云解决方案，对于非联网和联网设备都同样重要。