mirror of https://github.com/iotcat/wIoT
parent
4a8e9a4704
commit
31a65ef563
5 changed files with 1136 additions and 357 deletions
@ -1,2 +1,3 @@ |
||||
- [概述](zh-cn/) |
||||
- [落地方案](zh-cn/plan) |
||||
- [记录](zh-cn/logbook) |
||||
@ -1,349 +0,0 @@ |
||||
# wIoT |
||||
|
||||
|
||||
[](https://app.fossa.com/projects/git%2Bgithub.com%2FIoTcat%2FwIoT?ref=badge_shield) |
||||
 |
||||
 |
||||
 |
||||
 |
||||
 |
||||
 |
||||
|
||||
[](https://github.com/iotcat/wiot) |
||||
[](https://github.com/IoTcat/wIoT/) |
||||
[](https://github.com/IoTcat/wIoT/) |
||||
|
||||
> An awesome project. |
||||
|
||||
|
||||
## 历史回顾与展望 |
||||
古生物学的研究告诉我们，数十亿年来，生物系统从最开始无细胞形态，逐步演变到单细胞形态，再到多细胞形态，乃至多细胞生物间的社会形态。这一系列的演变，使得生物系统的稳定性和鲁棒性愈发强大，能够在更加复杂危险的环境（最开始的海底火山周边[有ref]，到全部海洋，到陆地，再到马上就会抵达的太空和其他星球）中更好地满足自然界提出的生存和繁衍的需求。由此，我们可以得到一些灵感如下。 |
||||
|
||||
我们惊奇地发现，多细胞生物，俨然就是一个近乎完美的分布式系统，具有分布式系统常见的内聚性[有ref]和透明性[有ref]等特征。在这个系统中，各个细胞是相对独立的个体，能够自主完成一系列生命行为，但又高度分工分化，由中央统一进行资源调度管理，比如进食行为和通过血液循环系统的能量分配[有非正式ref]等。于此同时，多细胞生物系统高度模块化和黑箱化，正如我们人类在日常生活中所体验到的。通过心理学研究我们得知，我们具有知觉，而知觉来自于对多个器官感觉的综合和加工[教科书ref]。这一综合和加工流程往往被认为是自动化的，是不受我们认知管理和调控的。我们的认知通过身体提供的“接口”对身体进行感应和操作，而如果身体不对脑认知部分提供“接口”，我们的认知将无法主动使用相应的功能（比如心率，激素调节等）[教科书ref]。可以发现人体这一系统拥有严谨巧妙的权限管理，资源管理等诸多设计。 |
||||
|
||||
理论物理的研究告诉我们，宇宙规律的表达往往是十分简洁的，比如描述电磁力的麦克斯韦方程就是一个经典的例子。由此，我们可以意识到，在宇宙不同层级的现象中，往往可以具备相似的特征。比如，太阳系和更高一级的银河系均成盘装结构（由于角动量守恒）。[有ref]由此，我们不仅思索，在分析设计人类社会时是否可以借鉴多细胞生物系统的实现方法，从而“巧夺天工”。比如，多国参与的人类脑计划，致力于更好的洞悉大脑原理，以研发新的大脑疾病的治疗方法，并根据其建立一套全新的、革命性的信息通信技术。[有ref] |
||||
|
||||
从直觉来看，影响一个分布式计算系统性能理论上限的因素主要有两点：节点性能，节点间沟通效率。[未找到ref]从人类学的研究来看，语言的发明和发展似乎与数十万年来人类迅速抢占扩展生态位的行为有密切关联。[非正式ref]上世纪末以来迅猛发展的基于光量子通信的互联网技术，似乎有推动人类社会进入第二次大发展的迹象。而这两次重要的发明，似乎都在不同程度上提高了人类个体间沟通效率。[社会学：管理学：个人潜力未充分发掘;想法参考日漫psycho-pass描述的社会形态]由此我们可以猜测，人类社会当前发展的主要瓶颈仍然在于节点间沟通效率。任何能够显著提高人类社会沟通效率的技术都有潜力促使人类社会进化。 |
||||
|
||||
我一直在思索，作为人类，生物，乃至宇宙演变进程中一个渺小的多细胞生物个体，我能为其做些什么？我的生态位又在哪里？有学者指出，地球正在表现出一些智能的特征（即全球脑）。在地球上，借助互联网为核心的通信网路，人与人，人与机器，机器与机器，他们联结在一起，彼此交流信息，形成一个特别巨大的智能系统。[有ref]这一过程似乎与多细胞生物系统的形成有诸多相似之处：人与机器高度分工，各司其职。 |
||||
|
||||
随着物联网时代的到来，人类与环境的交互方式将产生革命性的变化。环境，似乎将在这一时期被改造得更加智能。而改造的实施，将意味着对环境安装一系列联网的传感器和控制器等。我个人倾向于将物联网的发展分为三个阶段。在物联网的最初阶段，人类似乎仍需通过特定界面，比如智能手机，与物联网化的机器和环境进行交互。不久的将来，物联网发展将进入第二阶段。这一阶段下，通过手机等界面进行交互的场景将会逐渐减少，与此同时人类与周边环境直接交互的方式（如手势，语音等）将会增加。甚至，智能手机的所有职能将最终被智慧环境（3D全息投影，基于物理位置的音频放送服务等）所完全替代。在这一阶段，混合现实MR等技术将会大展手脚。脑机接口技术的应用和普及将会将物联网推进到第三阶段。在这一阶段，智慧环境中大部分的传感器和控制器将会以某种方式伪装成人脑能够识别控制的感觉和知觉形式，并通过脑机接口将感知和操作权限提供给人脑。此时，对于每一个使用脑机接口接入物联网的人来说，都可以像感受和控制手足一样感知和控制遍布全球乃至宇宙的传感器和控制器。 |
||||
|
||||
（脑机接口是一项非常前瞻性的技术，这项技术的应用和普及将革命性地改变人类间，人类与机器，以及人类与环境交互的模式。然而，令人遗憾的是，我们当前对人脑仍知之甚少，此技术发展仍困难重重，预计数十年内仍将局限于脑部疾病治疗应用。但是，其前景仍值得期待。） |
||||
|
||||
## 经典物联网操作系统 |
||||
|
||||
### 鸿蒙OS |
||||
|
||||
鸿蒙的理念是硬件互助，资源共享。他是由华为主导的一个分布式物联网操作系统项目。面向全场景，多设备。功能包含分布式软总线，分布式设备虚拟化，分布式数据管理，分布式任务调度，一次开发，多端部署，统一OS，弹性部署等。 |
||||
|
||||
缺点： 与华为设备捆绑性强，对社区不太友好。目前对传统开源硬件支持不好。 |
||||
|
||||
### Fuchsia系统 |
||||
由Google开发，面向混合现实MR。微内核。Google面向未来的战略布局。Flutter的最终目的。 |
||||
|
||||
缺点：由于众所周知的原因，国内支持估计好不了。但是其以3D位置坐标为重心的设计非常值得借鉴。 |
||||
|
||||
### Amazon FreeRTOS |
||||
微控制器的操作系统，它使小型，低功耗的边缘设备易于编程，部署，安全，连接和管理。 |
||||
|
||||
缺点：严重依赖AWS。 |
||||
|
||||
### Windows IoT Core |
||||
希望一个Windows 适应所有的设备和屏幕。并为用户及开发人员提供一致的体验。 |
||||
|
||||
缺点：无法适应低功耗场景。严重依赖微软产品。 |
||||
|
||||
|
||||
### Contiki |
||||
|
||||
适用于有内存的嵌入式系统的开源的、高可移植的、支持网络的多任务操作系统。 |
||||
|
||||
缺点：未将联网部分自动化 |
||||
|
||||
### RT-thread |
||||
嵌入式实时多线程操作系统。RT-thread包括如文件系统、图形库等较为完整的中间件组件，具备低功耗、安全、通信协议支持和云端连接能力的软件平台。 |
||||
|
||||
缺点：仅提供协议支持，开发者仍然需要自己在各节点写通信方法，难以做到统一调度管理。 |
||||
|
||||
|
||||
### 综上 |
||||
|
||||
发现大部分物联网操作系统，要么管的太多，像鸿蒙。要么是由嵌入式系统转型，对联网部分支持不好。现在物联网领域的主要矛盾就是大家都各搞一套，缺乏统一标准。A的设备连不上B，B的设备连不上A，各自用各自的协议，还谈何物联。。不如试一下以社区为根据地，提供一套将万物互联的范式，一个灵活的平台。在那里，各种各样实体的和虚拟的物体（传感器，设备，人，流水线上的产品，网页，天气等）都将被集结到一起。无论用户原先是使用华为的HiLink，还是使用微软的系统，都能够轻松接入。 |
||||
|
||||
## wIoT愿景 |
||||
wIoT的目标，是在物联网发展的第一，二，三阶段，找到自己的生态位，满足各阶段都可能需要的物联网建设和运行需求。 |
||||
|
||||
wIoT希望打造出类似多细胞生物血液循环系统的模式，类似血管的职能，提供一种运行在边缘的弹性的客制化的物联网服务范式。 |
||||
|
||||
## wIoT功能设计 |
||||
|
||||
- 面向社区 |
||||
- 与地理三维坐标绑定 |
||||
- 动静结合 |
||||
- 灵活的驱动接口 |
||||
- 灵活的服务接口 |
||||
- 统一的公共管理 |
||||
- 权限管理/安全 |
||||
|
||||
## wIoT设计理念 |
||||
|
||||
- 小而精 |
||||
- 工具丰富 |
||||
- 高扩展性 |
||||
- 万物皆设备（Things） |
||||
- 分类 |
||||
|
||||
|
||||
## wIoT架构 |
||||
|
||||
?> 如果看完有时间可以看一下上面的分析 |
||||
|
||||
在设计wIoT的架构时，我们不禁思索，是否存在一种更加简洁的模式，来实现万物互联。一味地将计算机系统的设计思维强加到物联网系统的设计上，是否不太合适？物联网的本质到底是什么？联网的本质到底是什么？ |
||||
|
||||
|
||||
|
||||
### Thing模型 |
||||
|
||||
在这个模型中，我们假设世界上每一个thing都可以被抽象到简单的供需模型如下。 |
||||
|
||||
!> 以下示意图可能会在移动端变形，竖线应该是对齐的 |
||||
|
||||
```Thing_Model |
||||
| | |
||||
demand ---> | Thing | ---> supply |
||||
| | |
||||
``` |
||||
|
||||
此模型第一个假设是，每一个thing的全部交互行为，都可以被抽象成一系列的demand和supply。比如走廊的灯，则可以被简单地抽象为`demand: electricity; supply: light`。当然，供应和需求可以通过树状结构更加细化地展开描述，比如`demand: electricity{voltage: 220V, power: 20W}; supply: light{color: yellow, PWM: supported}`。再比如一个人，甚至是流水线上的每一个商品，都可以被以类似的方式进行抽象。 |
||||
|
||||
此模型的第二个假设是，所有的demand和supply能够使用树状结构进行分类和管理。 |
||||
|
||||
此模型的第三个假设是，demand和supply之前存在某种对应关系，且这个寻找最优对应关系的过程可以通过计算机自动化。 |
||||
|
||||
|
||||
通过这一模型，我们发现，**万物互联过程的本质，在某种程度上等价于供需关系的建立**。而wIoT可以做的是，**将things之间供需关系的建立过程自动化**。 |
||||
|
||||
### product模型 |
||||
|
||||
假设thing模型中的demand和supply可以使用product进行量化描述。product使用一种类似CSS的描述语言进行描述。wIoT的工作是对需求和供应描述的product进行匹配。 |
||||
|
||||
### 分层架构 |
||||
|
||||
 |
||||
|
||||
如上图所示，遵循万物皆设备（Things）的思想，wIoT的层级架构被设计为球状结构。 |
||||
|
||||
#### 系统内核 |
||||
球体的内部为系统内核，负责为各things生成最优的需求供应匹配。由于系统层面的thing被设计为动态的，因此thing的生成，管理和销毁也由内核进行。此外，内核也会发挥系统常有的如日志，权限管理等功能。 |
||||
|
||||
#### Things |
||||
|
||||
在wIoT系统中，things部分的职责是对各现实层面上多种多样的物体进行虚拟化，并按照规范将每一个thing的需求和供应封装为内核可以识别的形式。thing对象将由内核按需根据template生成。template包含以下几种结构。 |
||||
|
||||
!> template-thing的设计应该还可以再简化，这一点将在今后详细考虑 |
||||
|
||||
|
||||
```template |
||||
|
||||
Real/Virtual Things |
||||
------------------------- |
||||
Driver | Driver | Driver |
||||
------------------------- |
||||
Program |
||||
------------------------- |
||||
Supply | Demand |
||||
------------------------- |
||||
wIoT Kernal |
||||
|
||||
|
||||
``` |
||||
|
||||
在template中，首先通过诸多driver与真实或虚拟的thing产生联系。driver的作用是将thing映射为nodeJS接口。比如，一个人类template可能需要多个驱动共同描述，如连接随身设备手机的驱动，连接智慧手表的驱动等，从而使人类的供应和需求通过这些随身设备映射到wiot上。 |
||||
|
||||
开发者利用诸多驱动提供的接口，将这一thing的需求和供应进行总结，并按照格式提供给内核管理。 |
||||
|
||||
wIoT提供基于npm的全球driver管理器。开发者可以自行开发和发布自己的driver到driver管理器供大家使用。 |
||||
|
||||
对于每一个thing来说，wIoT内核本身也是一个thing，可以通过相应driver调用。 |
||||
|
||||
wIoT系统之间可以通过driver相互调用。例如，可以在wIoT系统A上编写一个template，将wIoT系统B的整体供应需求选择性地映射到wIoT系统A上。 |
||||
|
||||
### 拓扑架构 |
||||
|
||||
 |
||||
|
||||
如图所示，wiot内核运行在边缘的计算节点上（边缘计算/雾计算），与各种things进行交互。开发者使用wiot-cli工具在PC进行开发，运维等操作。 |
||||
|
||||
## 经典场景 |
||||
|
||||
### 动态人场景 |
||||
|
||||
!> 此场景存在一些未明确设计细节，仅供参考 |
||||
|
||||
此场景下，假设有一个大厅，遍布传感器，灯具等设施。使用wiot实现，人走动，灯跟随，且灯的亮度/颜色等符合此人的习惯。 |
||||
|
||||
!> 以下为泳道图，移动端可能会变形，竖线应该是对齐的 |
||||
|
||||
``` |
||||
|
||||
Client Location Register Service |
||||
|------------>| |
||||
| location | |
||||
| | |
||||
|<------------| |
||||
| Edge server | |
||||
| ip |
||||
| |
||||
| wIoT Edge Server |
||||
|------------------>| |
||||
| Client Template |-->Generate Client Thing |
||||
| |<--Indoor Location service |
||||
| |-->Customized Light service |
||||
|<------------------| |
||||
| Service Status | |
||||
| | |
||||
| | |
||||
| | |
||||
| | |
||||
|------------------>| |
||||
| Heartbeat | |
||||
| | |
||||
| | |
||||
|------------------>| |
||||
| Bye |--Client Thing destroyed |
||||
| | |
||||
| |
||||
``` |
||||
|
||||
用户终端设备根据自己的位置信息，向Location Register Service查询（类似DNS查询）此区域的wIoT边缘服务器。之后，用户终端设备向边缘服务器发起请求，并将自己的主人的描述template发送给边缘服务器。wIoT服务器接收到template后会将其实例化为thing，然后使用其它thing如室内定位服务等对其进行追踪来满足其定位需求。并根据这个Clinet Thing的需求实时与周边的灯物体进行需求供应动态匹配。 |
||||
|
||||
用户终端会定时向wIoT服务器发送心跳以确定存活。当定位服务/心跳中断/用户主动断连时，wIoT服务器将销毁用户thing并刷新thing之间的供需关系。 |
||||
|
||||
|
||||
### 车辆行进场景 |
||||
|
||||
!> 此场景存在一些未明确设计细节，仅供参考 |
||||
|
||||
此场景下，使用wIoT内核的智慧车辆行进在遍布传感器和wIoT节点(使用wIoT内核的节点)的道路上。实现车辆与周边车辆，车辆与环境中传感器的自动连接匹配。环境中，交通信号灯，路灯等场景根据car的template按需供应。 |
||||
|
||||
|
||||
!> 以下为泳道图，移动端可能会变形，竖线应该是对齐的 |
||||
|
||||
``` |
||||
|
||||
Car Location Register Service |
||||
|------------>| |
||||
| location | |
||||
| | |
||||
|<------------| |
||||
| Edge server | |
||||
| ip |
||||
| |
||||
| wIoT Edge Server A |
||||
|------------------>| |
||||
| Car Template |-->Generate Car Thing |
||||
| | |
||||
| | |
||||
|<------------------| |
||||
| Service Status | |
||||
| | |
||||
| | |
||||
| | |
||||
| | |
||||
|------------------>| |
||||
| Heartbeat | |
||||
| | |
||||
| | |
||||
|------------------>| |
||||
| Bye |--Car Thing destroyed |
||||
| | |
||||
| |
||||
| |
||||
| Location Register Service |
||||
|------------>| |
||||
| location | |
||||
| | |
||||
|<------------| |
||||
| Edge server | |
||||
| ip |
||||
| |
||||
| |
||||
| wIoT Edge Server B |
||||
|------------------>| |
||||
| Car Template |-->Generate Car Thing |
||||
| | |
||||
| | |
||||
|<------------------| |
||||
| Service Status | |
||||
| | |
||||
| | |
||||
| | |
||||
| | |
||||
|------------------>| |
||||
| Heartbeat | |
||||
| | |
||||
| | |
||||
|------------------>| |
||||
| Bye |--Car Thing destroyed |
||||
| | |
||||
| |
||||
``` |
||||
|
||||
以上是car在行进过程与环境交互的简单模型。Car根据自身的位置通过Location Register Service查询附近的wIoT边缘服务器。car与边缘服务器建立联系，并定期心跳。此时环境会根据car的template提供客制化服务。在car离开此wIoT节点的地理围栏后，car会断连，查询并连接下一个wIoT边缘服务器。 |
||||
|
||||
|
||||
!> 以下为泳道图，移动端可能会变形，竖线应该是对齐的 |
||||
|
||||
``` |
||||
|
||||
Car Location Register Service |
||||
|------------>| |
||||
| location | |
||||
| | |
||||
|<------------| |
||||
| Edge server | |
||||
| ip |
||||
| |
||||
| Car A |
||||
|------------------>| |
||||
| Car Template |-->Generate Car Thing |
||||
| | |
||||
| | |
||||
|<------------------| |
||||
| Service Status | |
||||
| | |
||||
| | |
||||
| | |
||||
| | |
||||
|------------------>| |
||||
| Heartbeat | |
||||
| | |
||||
| | |
||||
|------------------>| |
||||
| Bye |--Car Thing destroyed |
||||
| | |
||||
| |
||||
``` |
||||
|
||||
使用类似的方法也能够实现车辆之间的交互如上图。 |
||||
|
||||
### 工厂流水线场景 |
||||
|
||||
!> 此场景存在较多未明确设计细节，仅供参考 |
||||
|
||||
此场景下，假设有一个工厂流水线，流水线上的是代加工的商品。 |
||||
|
||||
在wIoT节点通过传感器thing感知到新产品进入时，会通过产品template生成商品的thing，并通过定位服务追踪商品并将其信息实时更新至商品的thing中。在商品经过加工槽时，商品thing与加工槽进行供需匹配，并完成加工。商品走完全部流水线，其在wIoT的thing会被删除掉。 |
||||
|
||||
|
||||
### 星际飞船场景 |
||||
|
||||
!> 此场景存在大量未明确设计细节，仅供参考 |
||||
|
||||
此场景下，加速两个进行星际旅行的飞船擦肩而过。在相遇时，两船之间通过wIoT协调进行供需匹配。 |
||||
|
||||
例如，飞船A苹果多，飞船B梨多。飞船A的人想吃梨，飞船B的人想吃苹果。(得不到的东西才想要>\_<)(飞船之所以知道船上的人想要什么是因为飞船上所有的人都有在wIoT有一个虚拟化的thing，在这个thing中，动态地探测并记录着这一切需求)飞船相遇时，两船上的自动化设施将自动进行物质交换，实现最优资源配置。 |
||||
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
Loading…
Reference in new issue