新闻中心

EEPW首页 > 物联网与传感器 > 业界动态 > Ruff:一次破局 IoT 研发困境的尝试

Ruff:一次破局 IoT 研发困境的尝试

作者:时间:2018-02-06来源:电子产品世界

作者/郑晔 公司CTO

本文引用地址:http://www.eepw.com.cn/article/201802/375450.htm

  *本文源于“嵌入式系统联谊会主题讨论会(总第22次)——物联网操作系统现状与发展前景研讨会”上作者的报告。该会议主办方:嵌入式系统联谊会,时间:2017年11月12日,地点:北京航空航天大学。

  提及 IoT(物联网,Internet of Things),几乎整个 IT 行业的共识是未来一定会是一个 时代,继互联网时代将更多的人连接到一起之后,时代将会把更多的物(Thing)连接起来。但是,一说到 的研发,人们的第一反应通常是,物就是硬件,做硬件就要懂嵌入式,所以,IoT 开发就是嵌入式开发。于是,我们看到在 IoT 的指引下,各大硬件厂商和嵌入式操作系统厂商摇旗呐喊,纷纷畅想着 IoT 的未来,而现在的 IoT 行业状态却是,只问脚步声,未见人下来。为什么会这样?我们不妨简要分析一下。

  1 IoT 研发困境

  • 产品经理与硬件工程师难以协同

  在 IoT 时代,做一个硬件,已经不再是做一款独立的硬件,本质上,它就是一个产品,与这个时代的其它产品没有区别。无论是硬件厂商,还是操作系统厂商,他们拥有的都是研发实力,但在产品上却不是强项。而哪里拥有最多的产品经理呢?现在的答案是互联网公司。但为什么互联网的产品经理不来做物联网呢?

  不是没有,而是很难。

  曾经有一个互联网产品经理看到了 IoT 的未来,决心投身这个未来,做一款改变世界的硬件产品。根据互联网思维的做事方式,他说,我先要做一个东西先试错,因为我也不确定对这个产品是否是对的。他把这个想法给了硬件工程师,硬件工程师说,我要做六个月。当时这个互联网产品经理就崩溃了,说我从来都有想法大概两周试出来,你告诉我要六个月。双方很努力的协调之后,硬件工程师按照他把初步的想法做出一个东西。临近实现结束,产品经理出来说,我有一个新的想法,这回轮到硬件工程师崩溃了。

  • 瀑布式研发

  双方之所以会有如此大的差异,本质上,是因为双方在用不同的工作模式在工作。硬件研发属于瀑布式开发,而互联网产品研发则采用的是敏捷软件开发,双方对于开发节奏的理解截然不同。瀑布式要求一次性做好所有的事情,而敏捷开发则要不断地试错。在20年前,软件行业的主流开发方式也是瀑布式的,但对于这个需要快速响应变化的年代,瀑布式研发显得越加不合时宜了。

  • 重复造轮子

  在硬件行业里,有一个典型的现象,在一个项目做好的东西很难用到另外一个项目上,比如,TCP/IP 协议栈,即便你已经烂熟于胸,拿到一款新的硬件,往往要重来一次。对于这种现象,在软件行业里,有一个常用的说法:重复造轮子。这在某种程度上是一种浪费,放在行业的角度,这种浪费现象更加严重,你在一个硬件上做的一个工作,在其它公司,会有另外的工程师做着同样的事情,然而你不知道,没法用。在行业中,如此大规模的浪费导致整个行业进展缓慢。

  • 系统与应用一体

  IoT 时代需要的必然产品本质上就是一个应用,但在硬件行业里,大多数人并不能将应用与系统分开,做一款硬件产品,往往需要从硬件到系统,再到上层的应用一起做。这样的做法带来的后果往往是,系统与应用常常混淆在一起,做过开发的人都知道,这也通常意味着代码混杂在一起,维护的难度系数便直线上升。此外,这还有一个隐含的要求,做硬件的人要懂得从系统到应用的各种知识。

  今时今日,前端工程师已经 IT 行业里一个主流的职位。但你不妨同前端工程师交流一下,看有多少前端工程师知道,屏幕上显示的点到底是怎么显示出来的,总的来说,比例不会高,除非他自己非常有热情的去研究这些东西。而在嵌入式领域,要做一个应用必须知道各种细节,包括底层的寄存器。从某种程度上说,这是对人的要求非常非常高。

  这种高要求导致嵌入式行业人才培养也极其困难,即便是一个计算机专业的学生,真正理解操作系统,理解硬件底层是怎么运作都是一件有很高难度的事情。我们看到一个很无情的现实是,虽然我们以为嵌入式领域人才已经很多了,但是与做软件的人比起来做嵌入式的人,数量还是太少。

  2 软硬鸿沟

  换个角度,作为一个软件的人,如果他真的有热情,要去做硬件,他又会面临什么样的问题。

  他会看到一大堆的新名词:GPIO、I2C、C、时序、驱动等等,如果你是做硬件的,这些名词或许很熟悉。但我曾经在一些软件技术大会上做过一些调研,尝试用这些名词去问过不同的人,你知不知道这个词什么意思。这些软件工程师普遍的表情就是见了鬼一样。他们根本不知道我在说什么。

  软件工程师会关心的是什么呢?他们会关心:

  • 需求是什么

  • 用户体验是怎样的

  • 设计模式用什么

  • 系统怎么架构的

  • 怎样在高并发中保持系统的健壮

  我们不难发现,这两套语言几乎就是两个世界的语言,就像中国人说中文,英国人说英文,你没有一个翻译你根本不知道对方在说什么。虽然双方都号称自己从事的软件开发,但谈论的根本不是一回事。这里面存在一个巨大的鸿沟。

  3 IoT 应用研发,出路何在?

  我们回过头想想,问题到底出在哪?

  通过前面的分析,软硬双方,一方是人数不够多,另外一方想进又进不来,所以造成的现状就是,各种硬件厂商在编写各种各样的硬件,所以整个 IoT 的进展速度不会太快。

  亚当·斯密在《国富论》的开篇提到:劳动生产力上最大的改进,以及劳动时所表现的更多的娴熟程度、技巧和判断力,似乎都是分工的结果。

  我们不难从前面的讨论中看出,硬件厂商一个人扮演了三个角色:硬件制造、系统研发、应用开发。如果能够把三个角色分开,由不同的厂商扮演不同的角色:应用的人把应用写好,平台的人把平台做好,做硬件的人把硬件做好。事实上,现在行业里已经有人开始做这方面的尝试了,于是,行业里就出现了各种 IoT 平台。

  接下来,我就以 这个 IoT 平台为例,介绍一下一个 IoT 平台背后的设计理念。

  4 IoT 平台衡量标准

  在讨论 IoT 平台之前,我们需要知道有哪些衡量标准来判断一个 IoT 平台的优劣。下面是我提出的三个衡量标准

  • 现代程序设计语言

  • 面向应用的抽象

  • 提供生产支持

  4.1 现代程序设计语言

  鉴于摩尔定律的存在,在现代软件开发中,开发的效率比代码执行的效率要重要。所以,一个好的 IoT 平台,需要有一门现代的程序设计语言。

  我们不妨先看看 C/C++ 这个传统的嵌入式开发语言在现代程序设计语言所需特性上的表现,如表1。

  表1 C/C++在现代程序设计语言所需特性上的表现

  再来看看 选择的 JavaScript 在这些特性上的表现,如表2。

  表2 Ruff 选择的 JavaScript 在这些特性上的表现

  通过对比,不难发现,虽然 C/C++ 依然战斗力十足,但作为“现代程序设计语言”,它们显得不那么“现代”了。或许你会好奇,Ruff 为什么选择其它的“现代程序设计语言”,主要有下面几点考量。

  4.2 面向应用的抽象

  什么是面向应用的抽象?对比两段代码,我们便不难发现,这两段代码完成是同样的工作,点亮一盏灯。

  先是传统嵌入式风格,简单起见,我们用了 Python 代码做示例:

  GPIO.output(11, GPIO.HIGH)

  再是 Ruff 的代码,用的是 JavaScript 语言

  $('#led').turnOn();

  我们为什么需要硬件抽象呢?因为我们看到整个软件开发的趋势就是抽象度越来越高,从汇编到 C 语言,再到Java,今天还会有各种各样的 DSL (Domain Specific Language,领域特定语言)。早年间,编写代码,我们可能会质疑编译器是否正确,手写汇编效率会更高,但今天,我们肯定不会这么做,开发效率太低,因为有了抽象,底层的东西可以不断优化,越做越好。之所以抽象程度能不断提升,还要拜摩尔定律所赐,硬件能力越来越强,一些执行上的性能损失,我们是可以承受的。

  那我们需要怎样的抽象呢?从发展趋势可以看出,抽象的趋势一定是越来越接近问题领域。对于 IoT 平台而言,一定是越来越接近于应用开发。在 IoT 平台的尝试中,我们看到了几种不同的抽象。

  • 无抽象

  传统的嵌入式开发按照这个标准,就是无抽象的,其特点是面向硬件接口编程。

  GPIO.output(11, GPIO.HIGH)

  • 编程接口抽象

  诸如 Ruff、Tessel、Jonny-Five、Cylon.js 等一些 IoT 平台开始提供面向应用的编程接口抽象,让开发者无需关注底层的实现细节。

  board.on("ready", function() {

  var led = new five.Led(13);

  led.strobe();

  });

  但在这里,我们不难发现,我们依然要对底层的接口有了解,否则,你便不知道,这段代码中的13是做什么用的。

  • 隔离硬件配置的抽象

  Ruff 在提供面向应用的编程接口抽象基础上,更进了一步,将硬件配置隔离出去。在 Ruff 代码中,我们甚至看不出硬件配置是什么样的。

  $.ready(function (error) {

  $('#led').turnOn();

  });

  Ruff 之所以要提供隔离硬件配置的抽象,主要是为了提供生产支持。

  4.3 提供生产支持

  大家对于新出现的 IoT 平台,普遍有一个误解,这些平台只能用在原型研发上,因为它们看到的是,采用 JavaScript 的硬件要求都很高,与现在普遍的硬件开发状况不符。现在 JavaScript 已经可以运行在一些资源有限的系统上,比如 MCU,Ruff 就有自己的 MCU 版本,支持了几款不同的 MCU。

  Ruff 所做的事情更进了一步,它将硬件配置与应用本身分离开来,这样的做法带来一些好处是

  • 应用开发者无需关注硬件如何配置,可以将更多的将注意力放在应用逻辑本身

  • 硬件具体的配置方式可以在具体的部署时决定

  一旦硬件配置可以在部署时决定,便出现了另外一种可能,也就是,同一个应用可以运行在不同的硬件上,也就是跨硬件应用就出现了,这也就让前面提及的“重复造轮子”的情况得到一定程度的缓解。

  伴随跨硬件应用的出现,还会有一个额外的作用:测试。以往硬件测试一定要在硬件上完成,因为前面提及的种种原因,硬件测试往往要部署一个包括系统在内的应用,所以,效率是极低的。而我们知道,应用开发中,大量的测试实际上是应用逻辑的测试,属于软件测试的部分,理论上是可以在开发机上完成的。因为有了硬件隔离,Ruff 就提供了在开发机上做软件测试的能力,开发的效率由此得以提升。

  下面是一个 Ruff 测试代码的例子,可以在开发机上运行:

  var runner = require('ruff-app-runner');

  var verify = require('ruff-mock').verify;

  exports['test should call turn on while application is ready'] = function() {

  runner.run(appPath, function() {

  verify($('#led')).turnOn();

  });

  };

  require('test').run(exports);

  5 结论

  我们总结一下 Ruff 在 IoT 平台衡量标准上的一些做法,如表3。

  表3 Ruff 在 IoT 平台衡量标准上的一些做法

  基于这些做法,采用 Ruff 平台的应用开发,将会看到在一些模式上出现的转变,如表4。

  表4 采用Ruff 平台的应用开发,在一些模式上的转变

  以上就是 Ruff 在破局 IoT 困境上的一些思考和尝试,欢迎读者能够给出自己在这个方面的见解,让我们一起推动 IoT 时代早日到来。



关键词: Ruff IoT

评论

技术专区

关闭