物联网操作系统碎片化问题分析与思考

HaaS技术社区 HaaS技术社区     2022-12-27     316

关键词:

一、概述

本文以物联网操作系统面临的碎片化问题为主题,从CPU、外设、组件与接口四个方面出发,阐述物联网操作系统面临的挑战以及一些设计理念。以总分1.0进行度量,我认为整个物联网系统的碎片化指数如下:

 

从根源上来说,物联网系统的碎片化来自应用需求。这些需求的维度包括:成本、功能、性能、启动速度、功耗、实时性、安全性等等,甚至还包括编程语言与接口。有些需求是相互冲突的,比如成本低与功能强。因此我把应用的碎片化指数定义为最高的1.0。

形形色色的物联网应用需求无法用单一硬件架构满足,这导致了底层硬件的碎片化。其中尤以外设最为严重,我认为它的碎片化指数为0.9。通过操作系统的抽象与封装,在一定程度上可以降低硬件碎片化带来的影响,比如,CPU种类繁多,但经软件封装后可以提供较为一致的接口,所以上图中CPU核的碎片化指数为0.4,但CPU抽象层的碎片指数只有0.2。

为了满足应用在不同维度上的需求,物联网操作系统从接口到组件到内核都出现了较为严重的碎片化。同时,操作系统自身版本的演进也进一步带来了碎片化,不同的用户可能在使用不同的版本,甚至有的用户还在按自己的需求独立演进。

本文也将对比PC硬件平台/桌面操作系统,分析它们在面对碎片化问题时采取的策略。

二、CPU与操作系统内核

2.1 CPU的碎片化分析

市场上存在五花八门的CPU,它们各具特色。CPU通过数字电路实现,实现的依据是CPU的架构设计文档,主要是指令集架构(ISA,Instruction Set Architecture),分为两种:

(1)精简指令集(RISC ,Reduced Instruction Set Computing)。它只提供最基本的指令,通过组合多条指令实现复杂功能。该架构的CPU实现简单,功耗低。

(2)复杂指令集(CISC,Complex Instruction Set Computer),提供尽可能强大的指令。该架构的CPU实现复杂,性能高、功耗也高。

在物联网领域绝大部分都使用精简指令集架构的CPU,比如ARM、MIPS、RISC-V、CSKY,且ARM架构处于绝对垄断低位。同时,在IP核授权的产业合作模式下,一种CPU架构被应用到大量种类的物联网芯片上。

每种CPU架构都主要包含如下三个部分:

(1)指令集与寄存器。指令集包含了跳转、运算、位操作等指令,不同的架构提供了不同的指令。同时为了减少指令占用的内存空间,一些CPU架构设计了更紧凑的指令,比如ARM的thumb指令,RISC-V的压缩指令。精简指令集架构的一个显著特点是,CPU只能操作寄存器中的数据,不能直接操作内存中的数据。它提供了load和store指令,用于从内存加载数据到寄存器或把寄存器数据写到内存,即所谓的load/store架构。相比复杂指令集CPU,精简指令集CPU的寄存器个数更多,通常为16个或32个。

(2)异常与中断。异常是由指令触发的同步事件,包括无效指令、访问非法地址、系统调用等。中断由外设触发,用于处理异步事件。精简指令集架构的CPU通常把中断看作异步异常,中断和异常按相同的流程处理。CPU架构的异常与中断部分包括异常向量表、异常使能与禁用、异常进入与返回、优先级配置等。

(3)浮点。硬件提供的浮点计算能力相比用软件实现效率更高。CPU架构的浮点部分包括浮点指令、浮点通用寄存器、浮点控制寄存器等。

虽然物联网芯片基本上都使用精简指令集架构的CPU,但每种架构都有自己的指令编码、寻址方式、异常流程,有自己特有的状态寄存器、控制寄存器,也设计了特有的ABI规范。如果开发者需要面对这些繁杂的细节,不仅开发门槛大大提高,开发的周期也会拉长。C/C++语言及其编译器已经从语言级别实现了一层抽象,但这显然还不够。

2.2 CPU抽象层与内核

CPU在运行时先从内存读取一条指令,然后解析指令并执行相应的操作。这个过程以指令为单位不断重复。当中断发生时,跳转到中断入口处,处理完中断后再返回被中断打断的位置。也就是说,从CPU核的角度看,只存在两条执行流:一条是主执行流,一条是中断执行流,且两者分时运行。

传统上的裸机编程就是按CPU的这种运行特点来的,整个应用程序主要包含一个大while循环和一个中断处理入口,分别对应CPU的主执行流和中断执行流。这种编程模式把所有应用的逻辑都放在一个大while循环里面,这不适合开发复杂应用,且应用逻辑只能按顺序执行,对系统的实时性也有影响。

 CPU在运行时,它的状态寄存器、程序执行位置寄存器PC(Program Counter Register)、栈位置寄存器SP(Stack Pointer Register),以及一些通用寄存器和浮点寄存器构成了它的执行快照,称为CPU上下文。我们若能把CPU执行流的上下文保存下来,那么可以用该上下文恢复执行流。

基于此,操作系统研发人员发明了软件并发机制——多线程。其原理是,在系统中创建多个线程,每个线程是一个独立的执行流,通过任务切换分时共享CPU。当前线程在CPU上运行时,把CPU上下文保存起来,该上下文也是当前线程的上下文,作为线程私有数据保存在线程中,然后把另一个线程的上下文恢复到CPU上,以恢复另一个线程的运行。这样当前线程就把CPU让渡给另外一个线程了,以实现多线程并发运行。下图是线程1把CPU让给线程2的一个示意图:

有了多线程机制后,编程模式有了根本性的改变。应用可以拆解为多个逻辑单元,每个逻辑单元由一个线程来执行。同时,可以创建一些系统后台任务,比如软件定时器任务,为应用提供一些系统服务。

多线程只是软件层面构建出来的一个概念,底层CPU在某个时刻仍然只能执行一个线程,这就涉及到一个问题:让哪个线程占用CPU?为了解决这个问题引入了调度算法。在物联网操作系统上一般采用基于优先级的时间片轮询调度算法。应用逻辑拆分为多个线程后,还涉及到一个问题,多个线程之间如何协调?比如两个线程要同时访问一段内存数据时,如何保证数据的完整性。为了解决这个问题引入了同步与互斥机制。更进一步,为了方便地在线程之间传递数据,增加了通信机制。整个内核架构如下图所示:

CPU抽象层实现了CPU能力的抽象,主要包括CPU初始化、异常进入与退出、开关中断、Cache、MMU、任务初始上下文构建、任务上下文保存与恢复,以及提供等接口。把不同架构CPU在指令、寄存器、异常、浮点等等上的差异隐藏起来了。基于该抽象层,内核实现了线程、调度、同步与互斥,以及通信功能。上层应用通过内核提供的接口使用CPU能力。

从本质上来还说,不管是哪种架构的CPU,都是为了提供计算能力。因此都可以抽象出相同的接口。包括多核架构的CPU也可以抽象出和单核相同的接口,只不过在多核处理器上同一个时刻可以运行多个线程。

基于线程模型的软件抽象无疑是成功的,它不仅隐藏了硬件实现的细节,还为硬件赋能:每个线程不仅仅只是一个简单的执行流,它还有生命周期与状态。比如在AliOS Things物联网操作系统上支持就绪、阻塞、睡眠、挂起、删除五个线程状态。应用程序可基于线程能力更方便地实现应用逻辑。AliOS Things上的线程状态流转如下图所示:

 

嵌入式操作系统都采用类似的方法抽象CPU能力为上层提供统一接口,这有效解决了CPU碎片化问题。有些嵌入式操作系统,像FreeRTOS和uC/OS,它们主要就是提供了CPU部分的抽象。

三、外设与板级支持包(BSP)

在物联网系统上,外设是碎片化的重灾区。这部分将对比PC平台,分析物联网系统外设碎片化的原因与挑战。

3.1 PC平台的外设与总线

PC机也会连接五花八门的外设,比如不同性能的显卡、声卡,不同功能的打印机,以及不同协议的通信设备。所以,PC机上的桌面操作系统也会遇到碎片化的问题。但不同硬件配置的PC机,只需安装同一个操作系统,最多额外再安装几个设备驱动即可,并不需要为其定制操作系统。这是如何做到的呢?

PC平台上的外设主要通过PCIE和USB总线进行连接。下面以PCIE总线为例进行阐述。PCIE总线拓扑示意图如下:

 

设备挂载在PCIE总线上,每条总线有一个编号。一条总线上最多可以挂载32个设备,挂载位置从0编码到31。每个设备最多可以有8个功能,从0编码到7。总线可以通过PCIE桥扩展出新的总线,所以整个PCIE总线体系是树形结构。

在系统初始化时将遍历总线,发现并识别设备类型,这个过程称为设备枚举。该操作以深度搜索算法遍历整个总线,依次组合Bus/Device/Function三个编号,尝试从该总线位置读取厂商号vendor ID。若读到的值为0xFFFF,说明该位置无设备,否则该位置存在设备,读到的值为设备的厂商号,进一步可从设备的配置头读取设备号Device ID。系统根据vendor ID/Device ID可以确定设备的类型,并加载指定驱动。

概言之,PCIE总线具备找到外设并判断外设类型的能力。基于该能力,操作系统可以动态加载合适的驱动。

3.2 虚拟文件系统(VFS)

基于设备总线构建的设备框架实现了外设的自动识别与驱动的自动加载,可以有效应对硬件平台外设碎片化带来的问题。然而,每种外设提供的能力都不同,这将导致提供给上层应用的接口出现碎片化,如下图所示:

 

Linux上提出了“一切皆文件”的设计理念,由虚拟文件系统(vfs)抽象外设能力向上层提供统一的open、read、write、ioctl接口。其中open接口用于打开设备,对应设备初始化,read接口对应设备的数据输入,write对应设备的数据输出,ioctl用于控制设备,比如设置模式、读取设备状态。这样上层应用可以使用统一的接口访问不同的设备了。

 

当然,设备毕竟是有差异的,外设的功能细节其实都被集中到ioctl函数中了。该函数的原型设计如下:

int ioctl(int fd, int req, ...);

其中,fd是文件描述符,在调用open函数打开设备时返回。req是操作的命令码,用于表示不同的操作请求。可变参数部分用于传递命令参数,为了便于传递多个参数通常会设计一个结构体。每种外设都需要根据各自的特定需求设计一套命令码以及对应的参数结构体,像复杂一点的显卡,ioctl命令可能多达上百个。

3.3 物联网系统上的外设与BSP

出于成本与功耗的考虑,物联网芯片通常把CPU和外设集成在一个芯片上,即SOC(System-on-a-Chip)或MCU(Microcontroller Unit),且不同的芯片常根据自己的特色集成了不同的外设,这种集成没有统一的标准。用于集成外设的总线通常不具备设备枚举能力,也无法读取设备寄存器判断设备类型。因此,在物联网硬件上开发时,只能查询芯片手册了解芯片上有哪些外设。同时,芯片厂商在集成外设IP核的时候已经为外设分配好IO地址了,开发时查询芯片手册获得该地址,驱动用该地址访问外设。

在这类硬件平台下,只能针对具体芯片定制操作系统了。物联网操作系统的开发者为了尽可能降低碎片化,针对该问题做了很大的努力。一种设计策略是板级支持包(BSP,Board Support Package)。它是外设的抽象层,一种硬件平台对应一个。它为内核提供了统一的外设访问接口,确保内核本身与具体硬件解耦。物联网操作系统提供多个硬件平台的BSP,应用开发者根据自身需求选择使用其中一个,然后重新编译出操作系统镜像。如下图所示:

 

然而,硬件平台不可穷尽,且为了更好满足不同应用的需求,新的物联网芯片也层出不穷。尤其很多厂商为了满足自身应用的需求常定制硬件,在芯片之外增加一些外设。这种情况下,需根据BSP开发规范新开发一个BSP以支持新的硬件。

从PC硬件解决外设碎片化问题的经验来看,软硬件协同设计是一个比较好的思路。HaaS(Hardware as a Service)物联网设备云端一体开发框架提出的硬件积木化正是这种思路在物联网系统上的一个实践。其设计思想是,基于数量收敛的硬件积木搭建出满足各类物联网应用需求的硬件。传统上,通过软件的组件化满足不同硬件的需求。而HaaS的硬件积木是要通过软硬件的协同组件化满足不同应用的需求,从而解决物联网碎片化问题。如下图所示:

3.4 物联网操作系统上的设备接口

Linux桌面操作系统通过VFS层为应用提供了统一的外设访问接口。一些物联网操作系统,像RTThread,借鉴Linux的思想也实现了简化版的VFS组件,除了用于访问文件系统外,也用于访问外设。

AliOS Things除了支持VFS组件外,还提供了另外一种接口——HAL(Hardware Abstraction Layer)。它根据每一种外设的功能,分别为它们设计一组接口。所以HAL其实是一个接口集。它的优势是简单直观,易使用、易对接、易维护。但可扩展性较差,当出现新外设时需要设计新的接口。同时,一些从Linux上移植过来的应用,希望按Linux的方式使用外设,HAL就无法满足了。

虽然通过VFS可以统一外设接口,但在物联网设备上也会出现水土不服的情况。首先是对接设备工作量比HAL接口要大,尤其对一些简单的物联网外设,像GPIO,也要按VFS的规范进行封装。其次使用起来不够直观,比如像I2C设备访问时需要指定从设备的地址,这种情况下就无法直接用read和write接口简单访问了。

两种接口各有优劣,选择哪种接口要看操作系统的整体设计与定位了。当然也可以选择两种都支持,通过配置选择。下面我们来看组件和配置带来的碎片化问题。

四、组件与配置

物联网操作系统的一个特点是可裁剪性强,通过组件配置,应用只选用需要的组件。以灵活的配置来满足不同应用的需求,这也是解决碎片化的一个方法。这是一个好的思路,但在具体实施时也会遇到问题。

首先是组件内部的碎片化。针对物联网领域的第三方组件在设计时通常希望能在更多的平台上运行,主要考虑两类平台:(1)无操作系统,在该类平台上无需考虑多线程问题;(2)有操作系统,在该类平台上需要考虑多线程问题,因此依赖操作系统提供的接口。组件会提供一个对接层,需针对目标操作系统实现该对接层。有些组件基于标准接口开发,比如Posix,或者用C++语言写。如下图所示:

 

为了支持不同类型的物联网平台,三方组件通常提供了灵活的配置,比如占用的内存数量、使能的功能个数,以适用于更多的场景。越灵活意味着可配置的项越多。有些组件为了降低依赖,或提高易用性、性能还会实现一些基础功能,比如内存管理、校验算法,甚至C库。另外每个组件可能有自己的调试信息输出方式、接口设计理念等等。当所有这些设计不同的组件组合在一起的时候,操作系统在整体上就不一致了,功能冗余、配置方式、代码风格不同等等。当然,我们可以对三方组件做本地化的努力,但这将为日后升级将带来阻碍。

其次是如何配置。一种方法是集中配置,在一个或少量几个头文件中集中用宏配置。该方法比较直观,但由于物联网系统的配置项非常多,且组件之间存在依赖(一个组件选上后需要选上另一个组件)或互斥(一个组件选上后不能选上另一个组件),这将导致配置工作比较繁琐,用户很难配置出一个符合其需求的配置集。这种方法只适合小型的物联网操作系统,FreeRTOS采用了该方法。

另一种方法是离散配置,即把每个组件的配置信息放在组件内部。由于配置项分散在各个组件中,配置起来有难度,因此有些系统会利用类似于menuconfig的图形化配置工具。该方法能够辅助用户处理组件之间的依赖与互斥关系,即当用户选中一个组件时,它依赖的组件也被自动选上,与它互斥的组件被排除。然而当配置项多了之后,整个图形配置层级较多,用户配置起来也会遇到困难,比如要配置某个参数,若不熟悉的话,可能会像走迷宫一样找不到位置。大部分物联网操作系统,像AliOS Things、RTThread、ARM Mbed都采用了这种离散配置的方法。

配置方式处理得不当,最后的结果就是很多不是必须的组件都被配置进去了,失去了系统的可裁剪性。在Linux系统上,由于用户会跑各类应用,因此内核需要支持全功能,但若把所有模块都加载到RAM上,将导致内存浪费。为此Linux开发了动态加载功能,一些组件作为模块存放在外部硬盘上,当需要时才载入内存。相比静态配置的方式,动态加载更为方便。然而,有些物联网系统非易失性存储空间也很紧张,甚至比RAM还小,无法存下所有待加载的组件。

一种发展方向是收缩应用面,往垂直领域发展。这样各类组件不再需要为不同类型的应用提供多种配置,还可以针对垂直领域的应用需求做针对性的优化,不仅提高了易用性,也增加了性能。当然,更好的方式是打造平台化能力,这要求操作系统具备良好的组件“分”“合”的能力。在保持组件独立性的前提下,能快速组合。比如,离散+集中的混合配置方式,离散配置方式生成一个集中的配置文件,该配置文件就是一个垂直方案。既简化了配置,又可实现配置的复用。如下图所示:

五、接口与框架

物联网操作系统的接口主要包括两类,一是针对应用开发者的API,它代表了操作系统提供给用户的能力;二是针对BSP开发者的平台对接接口,它代表了操作系统所依赖的硬件能力。在物联网领域,应用开发者和BSP开发者很有可能是同一个人。

物联网操作系统通常会提供一套原生的C接口,使用原生接口的好处是性能高、占用的资源少,这有利于那些资源受限的平台。但它不是一套通用的标准接口,增加了应用开发者的学习成本,以及移植成本。当把其他系统上的应用移植过来时需要修改应用调用的系统接口。移植的工作量因系统差异而不同,比如若遇到没有相同语义的接口,则需调整应用代码或新增一个接口,若两个系统任务优先级值的定义不同,需要调整应用中每个任务的优先级。

Linux系统上的应用基于Posix接口开发,这是一套标准接口。一些应用开发者希望自己只维护一份代码,它既能在Linux跑又能在物联网系统上跑。为了方便这些开发者,物联网操作系统,比如AliOS Things,提供了Posix接口支持,这大大降低了把Linux应用移植到物联网操作系统的工作量。带来的代价是增加Posix层的开销。

物联网应用正朝着更加智能化的方向发展,一些AI组件,比如语音识别、手势识别,以及图形引擎,常用C++语言开发,因此对物联网操作系统提出了支持C++语言的要求。一个特例是ARM Mbed物联网操作系统,它把整个系统用C++进行了封装。

为了便于不熟悉C语言的开发者开发物联网应用,HaaS物联网设备云端一体开发框架提供了JS与Python语言的支持。

原生接口满足内存占用小的需求,Posix接口满足复杂应用的需求,C++语言及其库提供的接口满足面向对象开发的需求,JS与Python满足轻量级开发的需求。四五套接口看起来似乎很碎片化,有一种用碎片化应对碎片化的感觉。但我认为判断软件碎片化的标准应该是:为了满足不同应用的需求,需要增加的代码量或调整代码的量(包括配置项数量)。这四五套接口能够应对绝大部分应用的需求,并不需要因为应用的变化而增加接口或调整接口,所以我认为这部分的碎片化是低的。

BSP开发者通过实现硬件对接接口,把物联网操作系统移植到目标平台上,该套接口的设计决定了物联网操作系统支持一个新平台的工作量,所以它也是影响物联网操作系统易用性的关键因素之一。

我曾把FreeRTOS、RTThread、ARM Mbed三个物联网操作系统移植到同一个开发板上并跑通性能测试用例。这个过程中花时间最少的是FreeRTOS,最多的是ARM Mbed。两个系统的差别是,ARM Mbed的硬件对接接口背后有一整套极为完善、复杂的框架,想要适配一个新的平台需对该框架的使用有一定的了解,而这个过程需要不少时间。FreeRTOS没有设备框架,内核直接调用到硬件对接接口。可见,硬件对接接口背后的框架是一把双刃剑,用的好是助力,用的不好将成为掣肘。它需要具备如下三个特性:(1)抽象外设功能,整合通用操作,以降低对接的工作量;(2)具备良好的可扩展性;(3)使用的边际成本低,虽然一开始接触比较花时间,但后续使用可以减少大量时间。

如果不具备上述特性,那么硬件对接接口背后的框架将变成一场灾难。用户想要添加新功能不知道从何处入手,想了解背后的机制需要了解一整套框架,学习成本、维护成本、使用成本大大增加。同时,在外设碎片化需求的冲击下,框架本身逐渐被瓦解,变得越来越碎片化。

六、总结

相比硬件,软件的最大优势是边际成本低,甚至可以趋于零。然而,碎片化问题将大大增加物联网操作系统的复用成本,阻碍物联网操作系统成为通用的设备端软件平台。处理得不好,不仅将使软件边际成本低的优势荡然无存,甚至还会使之成为高边际成本的软件怪物,比如一些针对特定平台的特殊处理成为在其他平台上应用的障碍。

在开发物联网操作系统时将面对多个决策维度,包括性能、功能、易用性、实时性、资源占用小等等。基于不同的设计决策,开发的代码差异较大。因此,务必要确保基于同一个设计决策开发,这样才能使整个操作系统具备良好的一致性。另外,文档是解决碎片化问题的一个重要辅助手段。

 

物联网项目的思考

   一直从事物联网领域相关的工作,前不久也陆陆续续写过几篇关于物联网的文章,对物联网的前景是一直看好的,但是具体实施起来,要真正让物联网项目落地,却不是一件很容易的事。最近一两年实施了几十套污... 查看详情

顺丰科技胡典钢:边缘计算在工业物联网中的应用实践与思考

在云原生边缘计算峰会KubeEdgeSummit2022上,顺丰物联网平台负责人胡典钢为大家带来了题为“ 边缘计算在工业物联网中的应用实践与思考”主题演讲。工业物联网作为智能制造和工业4.0的重要使能技术和关键实现路径,以... 查看详情

物联网如何学习?

物联网如何学习?谁有好的建议呢想要成为一名物联网工程师,可以学习以下几个方面:1、物联网产业与技术导论:全面了解物联网RFID、M2M、传感网、两化融合等技术与应用。2、C语言程序设计:物联网涉及底层编程,C语言为... 查看详情

我的物联网成长记3如何开发物联网应用?华为云技术分享

【摘要】物联网应用是设备管理、故障监测、数据分析的重要工具。本文介绍如何基于物联网平台开发应用,包括API、SDK和图形化开发三种方式。-------------------整体方案-------------------物联网应用是企业和开发者进行设备管理、... 查看详情

工控安全入门分析

...ttp://bobao.360.cn/learning/detail/659.html)0x00写在前面工业4.0,物联网趋势化,工控安全实战化。安全从业保持敏感,本篇以科普角度对工控安全做入门分析,大牛绕过,不喜轻喷。  0x01专业术语SCADA:数据采集与监视控制系统ICS:工业控... 查看详情

入门物联网,嵌入式是关键

入门物联网,嵌入式是关键在2019年,我国人力资源社会保障部、市场监管总局、统计局正式向社会发布了13个新职业,其中就包括了物联网工程技术人员、人工智能工程技术人员、大数据工程技术人员等等。那么对于想要成为物... 查看详情

泛在电力物联网分析—架构形式

:国家电网公司在2019年3月7日发布了泛在电力物联网建设大纲,对于电力物联网的建设和发展进行了工作部署。根据文件内容,通过三年攻坚,到2021年初步建成泛在电力物联网;通过三年提升,到2024年建成泛在电力物联网。本文... 查看详情

阿里云iot云产品交流会:物联网痛点多,阿里能做啥?

参考技术A经历了互联网、移动互联网,人类正在迈入万物互联、万物智能的世界。5G、IoT、云计算、人工智能成为社会关注的对象,数字经济成为政策宣传的重点,各种概念和解释产生,使得当下有很多话题可以讨论。数字经济... 查看详情

给大家推荐两门课程,利用碎片化的时间去提升自己

古人云:“活到老,学到老。”互联网算是最辛苦的行业之一,“加班”对工程师来说已是“家常便饭”,同时互联网技术又日新月异,很多技术人都疲于应付,叫苦不堪。以至于长期以来流传一个很广的误解:35岁是技术人员... 查看详情

基于图模型的物联网系统-软件组件与程序编排

        在基于图模型的物联网系统中,信息模型描述了各个物模型以及它们的相互关系。看上去它们都是静态的数据模型。那么,物联网系统的程序如何建模,并且执行呢?本博文讨论这个问题。物联网程序... 查看详情

什么是物联网

物联网的英文是InternetofThings,是指在互联网、传统电信网等载体上实现各种设备的互联互通。通过物联网可以实现对各种设备的远程控制、数据采集,极大的减少人力提高效率,同时通过大量的采集数据汇聚成大数据进行人工... 查看详情

了解物联网知识需要学习哪些知识

物联网是一个新的领域,要了解物联网知识需要学习哪些知识?读哪些书?课程名称使用教材备注物联网产业与技术导论《物联网:技术、应用、标准与商业模式》,电子工业出版社,等教材。在学完高等数学,物理,化学,通... 查看详情

嵌入式操作系统与物联网演进之路

...访了著名的嵌入式系统专家何小庆,跟他一起探索嵌入式操作系统与物联网演进之路。何小庆,著名的嵌入式系统 查看详情

华为iot_物联网概述

   物联网(InternetofThings),国内外普遍公认的是MITAuto-ID中心Ashton教授1999年在研究RFID时最早提出来的。国际电信联盟ITU:物联网(InternetofThings)一般的定义是指,通过射频识别(RFID)(RFID+互联网)、红外感应器、全... 查看详情

生产车间物联网化对制造企业有什么影响?

随着互联网技术和移动互联技术的飞速发展,物联网技术也得到了深入的发展。现在工业自动化产品正在迅速的覆盖到从工厂车间的设备层、到管理的各个层次,生产自动化和自动控制系统正在广泛的应用,这也标志着制造型企... 查看详情

关于物联网管理设备问题分析

随着物联网设备的快速増长,设备管理策略对于工业物联网部署变得越来越重要。事实上,据预测,在2020年,物联网设备的数量将超过200亿台,如今,2020年已经到来,我们也看到越来越多的设备联网... 查看详情

linuxfoundation都有哪些开源项目

...tomotiveGradeLinux和Dronecode。我们还忽略了面向互联网的开源操作系统发行版,包括Brillo、Contiki、Mbed、OpenWrt、Ostro、Riot和Ubuntusnappping。这次,我们将智能这里介绍的21个项目包括由Linuxfoundation管理的两个大型项目:Allseen(Alljoyn)和ocf... 查看详情

物联网系统与coap之hello,world

物联网系统与CoAPHello,World关于CoAP与物联网系统我们在上一篇中(ps:CoAP与物联网系统)中做一个简单的介绍,接着我们便開始试试CoAP协议的应用CoAP应用開始之前我们须要能訪问coap://localhost/,于是我们便须要安装一个Firefox的插件Cop... 查看详情