Q: OpenWSN项目的定位?

OpenWSN项目的定位是什么? 它究竟要干什么?最终要达到一个怎样的目标?它与目前国内外的一些WSN项目是否重合或冲突? 要回答这些问题, 首先需要看看国内外这一领域发展的现状以及存在的问题.


国内外现状

o 在国际范围上,美国的TinyOS项目一花独秀, 但OpenWSN与TinyOS是不太一样的,以后有时间将专门陈述;

o 就企业而言, 如TI, Freescale, Atmel, Microchip等, 都有各自的低功耗近距wireless解决方案, 但是从这些解决方案的内容可以发现,企业所关心的内容与TinyOS偏重研究的策略有很大不同, 很多方案根本与TinyOS不沾边;

o 回到国内, 从04年WSN开始在国内风行到现在,尽管国内做的人看似很多并出了不少文章, 但大多停留在跟踪国外发展并作一些小打小闹的改进. 以硬件平台为例, 尽管也有不少的group可以开发出结点,但大多是模仿国外的方案,属于自己的创新和贡献并不多.


综合国内外的情况以及我们对TinyOS的理解, 我们不难发现这样一些问题:

o 缺乏规范性的WSN基础软件平台.厂商提供的硬件五花八门,导致开发者浪费了大量时间与每种硬件的特性打交道, 这在很多情况下其实是完全没有必要的, 特别是对Research类课题而言, 要求博士生们去学习具体硬件的开发, 从Research降格成为Developing是不合适也是不现实的. 如果能够有一套近似标准的基础软件,能够屏蔽具体硬件的差异, 对推动WSN在高校的研究和简化厂商的开发将会是有益的推动;

o 缺乏标准的可互换的WSN基础硬件平台.
目前国内已经有多家厂商和单位,都可以提供类似的平台,但是每个平台都各有特点.对Research而言,我们没有必要每次都重新搞一个新的平台,但是不同的平台之间却难以互换通用. 最起码的,富于变化的传感器子板和射频子板的接口应该首先规范起来,其次还应该包括电源和能量管理部分,试想,如果我们能够根据研究的需要,自由组合各个模板,当Atmel方案不能满足性能要求的时候能够自由替换为ARM/MIPS等方案,岂不是更加理想? 进一步的,学术界的统一也可进一步影响到公司, 进而形成标准的结点规范.

o TinyOS的定位与工业界的要求有差异.
TinyOS本身还是一个定位在研究和新想法试验的温床角度. 它的一些做法和观点作为超前性研究是可以的,但是要用于实现稳固可靠的工业应用,并不合适. 这是学术界和工业界固有的差异,也是TinyOS的管理者难以权衡的地方. 美国最近对TinyOS/WSN领域观点的分化也验证了这点.

o TinyOS的可移植性差.
TinyOS 1.x几乎是与Mica和Telos硬件平台绑定在一起的,这非常不利于其推广应用. 不是每个人都愿意接受Ateml/Crossbow的方案, 硬件平台千差万别,有成本\性能\熟悉程度\开发方便等各方面的区别, 应将这种硬件平台选择的灵活性赋予客户而不是将他们绑定在少数一两家方案上. 当然, 我们也发现, 2006年下发布的TinyOS 2.0已经接受了人们的批评,在这点上作了很多改进,增加了所支持硬件平台的数量. 顺便说一句, 早期,我们曾尝试TinyOS向OpenWSN硬件平台的移植,但最后放弃了, 待TinyOS 2.0稳定后,我们将在合适的时候, 启动TinyOS 2.0向OpenWSN硬件平台的移植.

o TinyOS的开发环境单一, 且与Atmel / Mica等硬件平台绑定太紧
TinyOS因为从大学首发,所以局限在GNU/Cygwin平台,这是可以理解的. 但是对实际开发而言,几乎没有实际的项目会选择GNU系列作开发工具, TI有CCS, ARM有ADS/Keil/RealView, Microchip有MPLAB等, 每个工具都各有特色,我们很难想象, 对一个实际的项目,一部分是厂商提供工具,而一部分又是GNU系列. 理想的方式是提供一套ANSI的源代码,只需在新的环境下编译即可, 而不应对开发工具作出什么约束. OpenWSN努力做到这一点.

o TinyOS不能保护原有的投资
工业界和中国的大学中存在大量的熟练C Programmar, 也有大量经过实际考验的稳固C代码, 这些都是以后开发项目的重要资源, 抛弃这些是完全没有必要的. TinyOS设计了nesC来开发,强调事件驱动方式降低能耗. 就我个人观点而言, 这都是完全没有必要的事情. 我们不可能大量培训我们的C程序员去开发nesC,尽管对善于学习的程序员而言这并非难事. 借用Java领域常见的一个观点, C是语言, 而nesC所强调的接口/组件(Interface/Component)和事件驱动(Event Driven)都应该是编程模式(Programming Pattern),我们应训练我们的开发者掌握这些编程模式,而不是设计一个新的语言. nesC是学术界的尝试,但不论是TI/Chipcon还是Freescale,我从未听到他们强调nesC对于开发的意义. 而且,Event Driven模式相比于目前常用的Multi-thread模式是不是就可以更好的节能, 也并未达成一致意见. Colorado大学计算机系的MANTIS操作系统我就非常喜欢,它就是一个采用了MultiThread方式的Sensor Node OS,顺便说一下,如果有人能够Port MANTIS到OpenWSN的话,我会非常开心. 不仅如此, TinyOS过分强调了事件编程, Event Driven Programming Pattern对付很多问题也是很麻烦的. 在我的眼里, C/C++语言已经足够承担上述指责, 只要我们灵活应用各种编程模式.

o 国外产品价格偏贵
相比于国内各个group实际情况而言, 国外产品的价格还是贵了点. 限于经费原因,很多学校并不能投入大量经费购买国外的结点, 坦率说,买多了也是浪费. 特别是对做研究的主力博士生而言, 也不可能要求他们在短时间内去把整套系统做出来. 而很多试验又要求有一定的规模,所以我们现在很多group的研究不得不停留在算法仿真层面,也是很无可奈何. OpenWSN项目希望能改变这种现状.

最后,还有一个是我们国内的缺点,就是国内对TinyOS中广泛使用的各种开源工具不熟悉, 也妨碍了国内在TinyOS平台上作开发的激情.


因此,我们希望OpenWSN项目能够:

定位在基础软硬件平台(以基础软件平台为主), 创立相应的开放规范,提供可方便移植的参考实现,以开源方式推动国内这一领域的发展. 而OpenWSN的参考实现本身,就将是一套能够满足实际需求并具有工业强度的软件组件集合,可以拿来直接应用.

开放的规范意味着组件化和可互换性, 而且赋予每个Group在力所能及时遵照规范开发自己产品的自由,当然也可以为了进度和可靠性购买现成的产品; 参考实现方便了应用软件的开发, 毕竟,每个Group完全从头做起是没有必要的,如果小小的代价可以换来2个月的进度提前, 何乐而不为? 而开源而是延续我们理想的精神,以群众运动的方式加速它的成熟与发展. 套用西方的一句谚语, United, We Stand!