嵌入式环境（通用9篇）
嵌入式环境 篇1
摘要：嵌入式系统应用已渗入到工业、军事、日常生活等各个邻域。随着嵌入式系统应用的普遍化和网络技术的不断发展,嵌入式网络应用将成为嵌入式系统应用发展的趋势。嵌入式网络的存在,必须要考虑嵌入式网络安全方面的问题。嵌入式系统本身资源有限,无法存储和运行大型的安全工具等。提出了在嵌入式系统上使用蜜罐Honeyd的安全防御措施。介绍了嵌入式系统安全特点并对Honeyd简单介绍,然后分析Honeyd的体系结构及配置,最后实现在嵌入式设备上对Honeyd的移植并进行测试分析。
关键词：蜜罐,Honeyd,嵌入式网络,安全
嵌入式系统应用已渗入到工业、军事、日常生活等各个领域。随着嵌入式系统应用的普遍化和嵌入式系统技术、网络技术、Internet技术的不断发展,嵌入式网络应用将成为嵌入式系统应用发展的趋势。因而,嵌入式网络安全也将成为关注的焦点。然而,由于嵌入式系统自身资源有限,一些安全软件比如防火墙、应用网关(或称为应用代理)等不适宜于应用;而且,嵌入式网络的特殊机理以及IEEE 802.11等无线安全加密认证机制本身的不完善,使得嵌入式网络的安全性相对有线网络更为脆弱和敏感。
蜜罐是一种安全资源,其价值体现在被探测、攻击或者摧毁的时候[1]。通过在系统中留有漏洞来诱使入侵者入侵,从而拖延攻击者对真正目标的攻击,让攻击者在蜜罐上浪费时间。有效地收集和分析黑客所使用的攻击手段和行为,获得有价值的研究信息。Honeyd是一种开放源码蜜罐,本文提出在嵌入式环境下应用Honeyd技术。实现对Honeyd在嵌入式系统上进行移植并进行测试分析。
1 嵌入式网络安全
嵌入式系统网络同计算机网络一样,同样也存在着网络安全问题,它同样会受到病毒侵入、数据截获、破坏数据、身份盗取等侵害。同时,由于嵌入式自身的设备体积小、资源有限以及功能相对单一的特点,它的网络安全具有自身的特点。嵌入式网络安全特点如下:
(1)由于嵌入式设备存储器较小,处理器处理数据能力较差,所以它更容易受到攻击,安全性更脆弱。对一些小系统来说,运行一些像防火墙这样安全软件,几乎不可能的。
(2)首先嵌入式设备功能相对单一,所受到的攻击也是比较单一。嵌入式设备一般都是针对某一要求而开发的,这样它需要的网络功能要比较单一,这样就可以限制其它的访问方式,减少被攻击的机会。比如门警系统它是单向传输,就很难受到网络攻击。
(3)嵌入式系统的存储能力相对较弱,使得一些常驻存储器的病毒较难存在,同时也使得内存消耗型的攻击很容易得手。
(4)由于各种嵌入式设备功能、设计区别都很大,对某一种设备的攻击对另一种设备就可能变得无效。比如对家庭网关的攻击很容易的方法对无线移动设备可能就很难成功。
(5)还有很多的嵌入式设备和上网设备是分离的,大多网络攻击都能被上网设备过虑掉,这样就使得对嵌入式设备的攻击就变得更难。比如信息家电的上网如果都是通过家庭网关,那么对象网络冰箱这样的家电攻击相对就难度增大很多。
当然,这些特点也是相对的,有些嵌入式设备比如家庭网关就能提供许多项网络服务,相当于一个小型的服务器[2]。
2 Honeyd概述
Honeyd是由Niels Provos开发的一种开放源代码的低交互蜜罐,它为蜜罐引入了几个新的概念。其主要目的在于对可疑活动进行检测、捕获和预警,它并不是对单个IP地址进行活动监视,而是对具有数以万计系统的网络进行监视。当它检测到对并不存在系统的探测时,就会动态地承担起这个受害者的角色,然后与攻击者进行交互,这就指数极地增加了蜜罐检测和捕获攻击的能力[1]。它可以在应用程序层和IP堆栈层上模拟数百个操作系统。作为一种开放源码的解决方案,Honeyd是为Unix平台设计的一项免费技术,可以访问到其源代码。Honeyd能在网络层次上大量虚拟蜜罐的软件,它具有下列属性:
(1) Honeyd是作为后台进程来运行,它产生的蜜罐是由后台进程所模拟。所以运行Honeyd的主机能有效地控制系统的安全。
(2) Honeyd与攻击者进行交互时,通过插件的形式载入相应的脚本来运行,以增加与攻击者的交互程度和欺骗攻击者的能力,从而能更好地获取攻击信息。
(3) Honeyd具有相应的指纹匹配机制,能欺骗攻击者的指纹工具。
(4) Honeyd能在网络层虚拟大量的蜜罐,这些蜜罐之间,可以是松散的集合,也可以组成严密的网络体系,从而构成一个虚拟的蜜罐网络[3,4]。
此外,Honeyd还有如下的一些优势:
(1) Honeyd最早是在Linux下开发的一款软件,延续了Linux精神,Honeyd免费开放源代码,能相互修改。
(2)由于程序的模块化设计,Honeyd设计了很多功能的插件接口,人们可以方便地进行修改。
(3)可以模拟的主机系统类型有500种之多,比如Windows、Linux、FreeBSD、Cisco Router 7200、Zyxel Router等。
(4) Honeyd占用的系统资源非常少[5]。
3 Honeyd体系结构及配置
3.1 Honeyd体系结构
Honeyd体系结构[6]由以下组件构成:配置数据库,中央包分配器模块,协议处理器模块,个性引擎和可选路由构件。如图1所示。
系统接受到的数据由中央包分配模块进行处理,首先中央包发配模块进行处理会检查IP包的长度,修改包的校验和。Honeyd响应的是最主要的3种互联网协议:ICMP、TCP和UDP,其他协议包在被记入日志后会被悄悄丢弃。其他请求的处理主要依赖于个性引擎的配置。
在处理数据包之前,中央包分配模块会查询配置数据库,以查找到一个符合目标地址的蜜罐配置。如果没有特定的配置存在,系统会采用默认配置模板。给定配置后,数据包和相应的配置会被转交给相应的协议处理模块处理。
在发送数据到外部网络之前,数据包会经个性引擎处理。个性引擎会修改数据包的内容,使得数据包看上去和从指定配置操作系统的网络栈发出的一样[7,8]。
ICMP协议处理器支持大多数ICMP请求。缺省时,对ECHO请求做出反应并给出目的地址不可达的信息。对TCP和UDP来说,该结构能为任意的服务建立连接,服务是在STDIN上接受数据并把输出发送到STDOUT的外部应用。Honeyd包含一个简化的TCP状态机,完全支持三次握手(Three-way Handshake)的建立连接和通过FIN或RST撤消连接,但是接受器和拥塞窗口管理没有完全实现。UDP数据包直接传到应用,当收到一个发往封闭端口的UDP包的时侯,默认发出一个ICMP端口不可达的信息。
Honeyd支持子系统和内部服务,子系统是一个运行在某个虚拟蜜罐名称空间下的应用程序,子系统的特定应用是在相应的虚拟蜜罐实例化的时候创建的。一个子系统可以绑定端口、接收连接和创建网络连接。子系统是作为外部进程运行的,而内部服务则是一个Honeyd内部运行的python的脚本。内部服务要求的资源比子系统更少,但只能接收连接,不能创建连接。目前,已有对python在armlinux进行交叉编译的资料,但是对python移植仍有些问题,有些python的module文件不能正常import,例如,time,socket,operator等。所以,本文在对Honeyd移植时未考虑用python脚本的应用程序。
3.2 Honeyd的配置
在Honeyd框架中,通过配置模板来配置虚拟的蜜罐。配置语言是一种上下文无关文法,可以设置虚拟网络,操作系统和服务。
新模板应用create命令来产生。bind命令把一个模板分配给IP地址,如果没有模板被指定IP,我们就采用缺省模板。
set和add命令改变模板的配制,set命令把从Nmap指纹文件得到的个性配给模板,这个性决定着网络堆栈的行为。set命令也限定所支持的网络协议的缺省行为,缺省设置可以是:block (阻拦)、reset(重置)或open(开通),block意味着特定协议的所有包被缺省抛弃,reset表明所有端口缺省关闭,open意味着全部缺省开放。add命令来指定服务。除了模板名称外,还需要指定协议,端口和具体执行每个服务的命令。
虚拟蜜罐系统是一个完全被配置起来的计算机系统,它在配置文件中描述每一个引用。下面是本文采用的样本配置honeyd.conf。
4 Honeyd移植
编译环境建立在基于X86体系结构,Redhat Linux操作系统的PC上,在ARM-Linux实验平台(PXA270)实现Honeyd移植。
4.1 Honeyd软件依赖库的安装
Honeyd软件依赖于Libevent异步事件响应库、Libdnet数据包构造与发送库、Libpcap数据包捕获库以及Arpd工具。首先安装Honeyd所依赖的库,过程如下:
分别进入Honeyd依赖的库所在的目录执行以下命令:
生成Honeyd的Makefile和libtool文件,修改Honeyd的Makefile文件,使CC=arm-linux-gcc,RANLIB=arm-linux-ranlib,再修改Honeyd的libtool文件,使CC=arm-linux-gcc,AR=arm-linux-ar,RAN-LIB=arm-linux-ranlib,使编译器指向交叉编译器。否则生成的目标文件只能在PC机下执行。
提示libevent文件的版本过老,要安装新版本。实际上是用交叉编译器与生成的libevent文件不匹配,要重新交叉编译上述库文件,编译3个依赖库及arpd的过程如下:
注:(1) libpcap:需要内核Packet socket CON-FIG_PACKET的支持,若内核未选Packet socket支持,需重新编译、烧写内核;
(2)交叉编译arpd时,要修改arpd.c中的268、285、294、297、426行,把“_FUNCTION_”删掉再编译;
(3)在linux系统下很多Honeyd所需要的库文件都是存在的。由于嵌入式设备资源有限,Honeyd需要的其它库文件不存在,要交叉编译Honeyd所需要的其它库文件,例如:readline、libedit、ncurses等;
(4)本文对Honeyd的移植只是针对本文所用的平台,其它嵌入式设备上的移植可能有所不同。
生成Honeyd所需的所有库文件后,再对Honeyd进行编译和安装。
4.2 系统测试及分析
4.2.1 实验拓扑结构
在实验中,Honeyd软件宿主机的IP地址为192.168.0.140,攻击机的IP地址为192.168.0.17,Honeyd虚拟蜜罐的IP地址为192.168.0.10-192.168.0.13,选用的蜜罐的配置文件为3.2节所显示的honeyd.conf。Honeyd的实验拓扑图如图2所示。
4.2.2 Honeyd测试及结果分析
(1)测试端口开放情况
利用X-Scan对配置的Honeyd进行扫描,扫描参数的检测范围为192.168.0.10-192.168.0.13,扫描模块为:开放服务、漏洞检测脚本和远程操作系统。得到的结果如图3所示。
在192.168.0.10-192.168.0.13的IP地址段中,可以看到扫描出了存活主机的为4,与配置虚拟蜜罐的主机数相符。并且X-scan能够识别出配置样本中所开放的端口。以192.168.0.11这个IP地址所绑定的系统为例,如图4所示,能够看出X-Scan所扫描的端口与Honeyd的配置相一致。
结果显示192.168.0.11上运行的操作系统可能是Linux 2.4.x,并开放四个tcp端口:21端口、80端口、25端口和110端口。从Honeyd配置文件honeyd.conf中可以看出,IP地址192.168.0.11被绑定在一个模拟Linux 2.4.7 (X86)虚拟蜜罐样本上。X-Scan探查出来信息与样本模拟的信息一致。由此可见虚拟蜜罐系统可以成功地欺骗攻击者,使其认为探查到了一个真实的系统。
Honeyd虚拟服务的能力取决于它所引的脚本,可以根据自己需要编写,也可以自由下载。本文只是对X-Scan软件对移植后的Honeyd进行端口扫描测试,也要模拟其它的服务,如TFP、telnet、pop3等。从实验结果可以看出,Honeyd嵌入式设备上的移植是可行的,可以根据不同的安全需求进行改进,为嵌入式系统上使用Honeyd起到基础作用。
5 结论
随着嵌入式系统应用的普遍化,嵌入式网络成为未来网络发展的必然趋势,嵌入式网络安全越来越受到关注。本文综合分析嵌入式网络及嵌入式系统的特点,提出在嵌入式设备上运用蜜罐Honeyd的安全防御机制。对Honeyd的体系结构及配置进行了分析,实现了在嵌入式设备上对Honeyd的移植,并通过实验证明在嵌入式设备上运用Honeyd的可行性。当然,无论是Honeyd还是其他的蜜罐系统都是正在发展中的技术,还需要不断地扩充和完善功能,提高迷惑性和自身的安全性。可以把蜜罐技术和现有的安全机制如防火墙、入侵检测等结合在一起,能更好地应对更为复杂和水平更高的网络入侵。
参考文献
[1] Spitzner L.Honeypots:追踪黑客.邓云佳,译.北京:清华大学出版社,2004
[2]颜世峰,栾贵兴,李莉.TCP/IP网络的攻击方式与安全策略.小型微型计算机系统,2001;22(7):797-799
[3] Provos N.Honeyd-network rhapsody for you.http://www.citi.umich. edu/u/provos/honeyd/,2006
[4] Chandran R,Pakala S.Simulating networks with honeyd.http:// www.paladion.net,2003
[5]梁知音.Honeyd软件框架介绍.北京:北京大学计算机科学技术研究所,2004:5-7
[6] Provos N.A virtual Honeypot framework,http://www.citi.umich. edu/techreports/reports/citi-tr-03-1.pdf 2003.2004:5
[7]官凌青,娄嘉鹏,刘莉.Honeyd的扩展设计与实现.北京电子科技学院学报,2006;14(4):83-86
[8]薛强,孙济洲.完善入侵检测蜜罐系统的方法.计算机工程, 2004;30(15):111-113
嵌入式环境 篇2
摘要：综述开放源码的嵌入式仿真环境SkyEye：介绍SkyEye的背景、目标和存在的意义，对目前SkyEye本身进行简要的技术分析;介绍SkyEye上已经移植成功的操作系统和典型应用。讲述SkyEye正在开展的工作和将来的发展计划。
关键词：SkyEye 仿真 μClinuxμ/OS-II Linux 嵌入式系统
1 SkyEye的目标与意义
1.1 SkyEye产生的背景
操作系统是软件产业的基础和龙头，能左右软件产业发展的方向，是世界软件产业最大的利润来源。对于后PC时代和普适计算(pervasive computing)而言，嵌入式系统无处不在，其中关键的软件核心技术包括嵌入式操作系统和网络互联中间件等。
对于想进行嵌入式系统软件开发和学习，或者想研究嵌入式Linux等操作系统和一些底层系统软件(如TCP/IP等)的研究和开发人员来说，可能存在如下几方面的问题：①经常苦于经费不足，缺少足够的硬件开发板和完善的软件开发环境;相关的书籍对一些最新软件的分析还不够全面，无法深研究和开发嵌入式软件。②高层次的软件设计和开发一般不用过多考虑底层硬件的实现细节，如果直接处于一具体的硬件环境下，在开发和研究中可能会陷入硬件的具体细节中不能自拔，而不能把精力放到高层次的软件设计和开发上。③如果硬件开发环境不太稳定(这种情况经常见到)，且对身体的硬件不是很了解，则可能在排除问题上花费大量不必要的时间。
对于想了解、学习一般操作系统的实现原理、Linux/μClinux操作系统或TCP/IP等系统级软件的实现的人员，目前一般采用的方法是看书和读源代码。这是一种静态的学习方法，但效率较低，比较枯燥，缺少一种动态和亲自实践的感觉。要想深入分析和开发软件，就要动手编程，不能只是看看书，读读代码，只有通过亲手实践才能够掌握软件设计的核心内容。
上面所指出的问题和需求促使了SkyEye项目的诞生。
1.2 SkyEye的目标和意义
SkyEye是开源软件(OpenSource Software)项目，中文名字是“天目”。SkyEye的目标是在通用的Linux和Windows平台实现一个仿真集成开发环境，模拟常见的嵌入式计算机系统;可在SkyEye上运行μClinux以及μC/OS-II等多种嵌入式操作系统和各种系统软件(如TCP/IP、图形子系统、文件子系统等)，并可对它们进行源码级的分析和测试。SkyEye的推出具有下面三方面的意义。
①通过SkyEye仿真集成环境可以很方便地进入嵌入式系统软件学习和开发的广阔天地中。尤其对于缺少嵌入式硬件开发环境和软件开发环境的用户来说，它将是一个非常有效的学习工具和开发手段，因为SkyEye的整个软件系统都是Open Source的，且基于GPL协议(μC/OS-II除外)。因此，如果要学习Linux操作系统或者进行嵌入式系统开发，但苦于没有硬件支持，SkyEye仿真环境软件是一个很好的选择!
②如果想研究与具体硬件无关的系统软件(如TCP/IP协议栈等)，采用SkyEye可以有效地提高工作效率，因为你可以直接在μCOS-II和μClinux for SkyEye上进行开发和调试，而与具体硬件打交道的各种Driver已经存在，且有源码级调试环境，只需关心高层的逻辑设计和实现就可以了。
③SkyEye本身作为一个开放式的项目体系，可以划分为多个独立的子项目系统。通过参与SkyEye的各个子项目，与大家共同交流、协议，可以进一步学习、分析、精通Linux内核，掌握ARM嵌入式CPU编程。
在32位嵌入式CPU领域中，ARM系列CPU所占比例相当大，而ARM7TDMI是其中使用最广泛的CPU之一，因此，SkyEye首先选择了ARM7TDMI作为仿真的目标CPU。目前，SkyEye上可运行并进行源码级调试的有μClinux、μC/OS-II操作系统和LwIP(一个著名的嵌入式TCP/IP实现)、ARM Linux等系统软件。SkyEye可用于学习、分析、开发这些系统软件，了解ARM嵌入式CPU编程，而这一切都可在一个集成环境中完成。如果能够改进SkyEye本身，则大家对ARM、8019Ethernet网络芯片等硬件的了解也会更深入。
SkyEye并不能完全取代开发板等硬件的功能，但通过它可以比较容易地进入到嵌入式软件开发的广阔天地中。由于SkyEye建立在GDB基础之上，使用者可以方便地使用GDB提供的各种调试手段对SkyEye仿真系统上的软件进行源码级的调试，还可以进行各种分析，如执行点分析、程序执行覆盖度分析等。由于SkyEye提供了源代码和相关文档，有经验的用户完全可以修改和扩展SkyEye来满足自已的需求。
2 SkyEye的技术分析
2.1 SkyEye总体结构
SkyEye基于GDB/ARMulator，模仿了一个完整的嵌入式系统，目前包括CPU、内存、I/O寄存器、时钟、UART、网络芯片、MMU、Cache，将来还会仿真LCD、USB等各种硬件。在SkyEye上运行的操作系统和各种系统软件“意识”不到它们是在一个虚拟的计算机系统上运行。
SkyEye从总体上分为四个层次。
①用户接口模块：包括命令行用
户界面和图形用户界面，及时处理用户的输入命令，并把相关调试数据输出给用户。
②符号处理模块：主要处理执行文件的头信息，解释执行文件中嵌的debuger调试信息，管理符号表，解析源代码表达式，定位源代码中的语句位置和机器码的位置关系等。
③目标控制模块：主要完成执行控制(如执行断程序，设置中断条件等)，程序栈结构分析，对具体目标硬件的控制(如本地调试、远程调试和仿真调试的控制)。
④目标仿真模块：主要是模仿计算机系统中的主要硬件(包括CPU、内存和各种硬件外设等)的执行，对执行文件的机器指令进行解释，并仿真执行每一条机器指令，产生相应的硬件响应。
2.2 SkyEye模拟的硬件介绍
目前，SkyEye仿真的CPU包含不带MMU的AT91X40和带MMU的ARM720T，它们都是基于ARM7TDMI CPU内核的。SkyEye还模拟了其它硬件外设，如串口、网络芯片、内存、时钟、网络HUB等。SkyEye的CPU仿真主要完成对ARM指令集处理、寄存器操作和CPU流水线处理等的仿真。
ARM720T具有MMU(Memory Management Unit)，即存储器管理单元，是用来管理虚拟内存系统的操作。MMU的两具主要功能是：
*将虚地址转换成物理地址;
*控制存储器存取允许，MMU关掉时，虚地址直接输出到物理地址总线。
MMU本身有少量存储空间存放从虚拟地址到物理地址的匹配表，此表称作TLB(Translation Lookaside Buffers)。TLB表中保存的是虚地址及其对应的物理地址、权限、域和映射类型。当CPU对一虚拟地址进行存取时，首先搜索TLB表以查找对应的物理地址等信息。如果没有查到，则进行查找Translation Table，称为TTW(Translation Table Walk)。经过TTW后，将查到的信息保存到TLB，然后根据TLB表项的物理地址进行读写。
MMU/Cache的仿真主要是依据ARM720T处理器的体系结构进行的。ARM720T可以看成ARM7TDMI加上MMU/Cache模块，主要是仿真控制MMU/Cache的寄存器结构、TLB结构、Cache结构、Translation Table Walk的控制逻辑以及在此基础上内存的读取操作。
对于网络部分，SkyEye仿真的是兼容NE的8019as以太网网络芯片，支持8位数据通路，仿真实现了远程DMA信道和本地DMA信道两个部分。本地DMA完成控制器与仿真网络的数据交换，主处理器(Host)收发数据只需对远程DMA操作。当主处理器要向以太网络发送数据时，先将一帧(frame)数据经过远程DMA信道，送到以太网络控制器中发送缓存(Ring Buffer)，然后发出传送命令。以太网络控制器在送出前一帧的数据后，继布完成此帧的发送。以太网络控制器接收到的数据通过MAC比较后，由FIFO存到接收缓冲区，收满1帧后，以中断或缓存器标志的方式通知主处理器。
为了有效支持网络仿真，SkyEye还设计了一个虚拟HUB-vnet，可以在一台Host主机上支持多个在SkyEye上运行的OS实例进行网络的通信互联，从而更有助于针对网络方面的开发和研究。
3 SkyEye上已经移植成功的OS
3.1 μClinux
μClinux是应用于嵌入式设备的一个Linux版本，是主要针对不带MMU的CPU而设计的Linux系统。ΜClinux系统对于内存的访问地址都是实际的物理地址。操作系统对内存空间没有保护(这实际上是很多嵌入式系统的特点)，各个进程实际上共享一个运行空间(没有独立的地址转换表)。目前，SkyEye上可以运行μClinux的最新版本。
3.2 μC/OS-II
SkyEye作为一个基于Atmel AT91X40开发板的仿真环境，在它上面可以移植各种适合地嵌入式开发应用的操作系统，将μC/OS-II移植琶SkyEye上是我们对此做的又一次尝试。ΜC/OS-II是一个简单、高效的嵌入式实时操作系统内核。自从1992年以来，已经被应用到各种嵌入式系统中。目前，它可以支持x86、ARM、PowerPC、MIPS等众多体系结构，并有上百个商业应用式系统中。目前，它可以支持x86、ARM、PowerPC、MIPS等众多体系结构，并有上百个商业应用实例，其稳定性和可用性是经过实践验证的。同时，它的源代码公开，任何人都可以从www.ucos-ii.com的网站上获得全部源码以及其在各种体系结构平台上的移植范例。无论是通常学习μC/OS-II来了解实时操作系统的构造，还是直接使用它来针对具体应用进行开发，都是非常方便和可行的。目前，SkyEye支持的μC/OS-II内核为2.5.1版。
3.3 ARM Linux
ARM Linux属于Linux标准发行内核中的一个分支，支持MMU的ARM系列CPU，如ARM720T、ARM920T、Intel StrongARM等。我们目前在SkyEye上仿真的CPU型号为CPU内核是ARM Linux内核选择的本系结构为CLPS711x/EP72lx，它支持ARM20T、UART串口等硬件，都是SkyEye目前仿真的硬件。目前SkyEye已经成功运行了版本为2.4.18的ARM Linux。有关ARM Linux的更多信息请访问www.arm.linux.org.uk/。
4 SkyEye目前支持的网络协议栈
4.1 μCLinux上的TCP/IP
μClinux上面有完整的TCP/IP协议栈，但缺少对SkyEye的网络仿真芯片(仿真兼容NE2000的8019as)的驱动程序。我们实现的驱动程序主要包括了初始化、中断处理、接收数据包的处理、发送数据包的处理等工作，再加上SkyEye的虚拟HUB-vet的协议，使μClinux on SkyEye的多个实例之间、实例与主机之间可以进行TCP/IP通信。
4.2 μC/OS-II上的LwIP
μC/OS-II本身没有TCP/IP协议栈，目前的一些第三方TCP/IP支持都是完全商业化的，很少给出源代码，影响了μC/OS-II的研究和推广。通过把开放源代码的TCP/IP协议栈LwIP移植到μC/OS-Ii上来，就获得了一套可免费研究、学习的嵌入式网络软件平台。其系统示意图如图1所示。
LwIP是瑞士计算机科学院(Swedish Institute of Computer Science)的Adam Dunkels等开发的一套用于嵌入式系统的开放源代码TCP/IP协议栈。LwIP的含义是Light Weight(轻型)IP协议。LwIP可以移植到操作系统上，也可以在无操作系统的情况下独立运行。我们目前使用的是LwIP的最新稳定版V0.5.3。
LwIP协议栈在设计时就考虑到了将来的移植问题，因此把所有与硬件、OS、编译器相关的部分独立出来，放在/src/arch目录下。因此，LwIP在μC/OS-II上的实现就是修改这个目录下的文件，其它的文件一般不应该修改。
我们在SkyEye中所仿真的网络芯片是NE2000，所以目前实现的网络设备驱动是针对NE2000的，其它类型的网络芯片驱动可以在LwIP的网站上找到。现在LwIP已经顺利运行在μC/OS-II上了，目前可以从Host主机和SkyEye上运行的μC/OS-II+LwIP顺利进行TCP/IP的通信。
4.3 更多的TCP/IP协议栈
除了LwIP之外，还有很多开源的嵌入式TCP/IP协议栈。它们各有各的特点，有些功能较全面，有些占用资源出奇的少，能适合不同场合的需要，而且多接触一些不同的思路，对协议和编码能有更好的理解。其中的代表有tinyTCP、ucIP、uIP等，它们的基本思路应该都是一致的。SkyEye小组希望能有列多对TCP/IP协议栈感兴趣的人参与进来，特别是ucIP，实际上它是专门为μC/OS-II设计的。
5 SkyEye上已经实现的简单应用
5.1 LwIP上的Echo服务器
做完LwIP的移植修改工作以后，就可以在μC/OS-II中初始化LwIP，并创建TCP或UDP任务进行测试了。值得注意的是：LwIP的初始化必须在μC/OS-II完全启动之后也就是在任务中进行，因为它的初始化用到了信号量等与OS相关的操作。
LwIP提供了两种API，供用户使用这个协议栈。
第一种是BSD API。这种API非常像BSD标准UNIX中的socket API，所以对其这样命名。它跟普通的socket API一样，是基于open-read-write-close模型的。(本网网收集整理)它提供了一种标准的方法来使用LwIP协议栈。但这种API效率较低，消耗资源较多，因此不推荐使用。
第二种称为RAW API。这种API接口实际上是直接使用了LwIP协议栈中的回调函数(call back functions)，从而使应用程序和协议栈代码能够更好地集成在一起，运行同一个线程即任务中。RAW API相对于普通BSD API来说，速度更快，消耗内存资源更少;唯一的缺点是编程复杂，对程序员的要求高。考虑到我们是在嵌入式设备中工作，这样的缺点是可以接受的。事实上，BSD API就是用RAW API来实现的。
利用Berkley API实现的tcpecho_thread是一个TCP Echo服务器，监听7号端口，这实际上是实现了RFC中最简单Echo协议：收到什么，就往回发同样的内容。编译运行后，用ping IP地址命令可以得到ICMP reply响应。用telnet IP地址7(登录7号端口)命令可以看到Echo Server的回显效果。说明ARP、ICMP、IP、TCP协议都已正确运行。
5.2μC/OS-II只提供了操作系统内核，用户要自己添加文件处理、人机界面、网络接口等重要部分。大部分人认识OS都是从这里开始的。
由于SkyEye下的仿真串口UART已经实现了中断方式的接收(实际是从键盘接收输入)和输出(实际上是输出到终端屏幕)，所以实现一个类似Bash的简化版Shell并不困难。其本质思想就是：Shell作为一个μC/OS-II下的任务，工作于内核之外，占用一个任务号。它接收用户输入的字符，存储到缓冲区，并回显到屏幕上，以回车键为用户输入的结束信号，随后解析用户输入的命令名称、参数，调用相应的命令函数。一直到这个命令函数运行返回，才继续Shell的人机交互界面。
我们目前在μC/OS-II下实现的Shell被命名为Genie Shell。它实现了最基本的命令输入、解析参数、调用命令函数功能，以及两条示例性的命令。这个Shel
l的特色是采用了一些面向对象的思路来实现Shell的各种命令。Genie Shell把每个命令看成一个对象，对象的属性是命令名，而对象的方法就是命令的执行函数本身。用户输入命令及参数后，将参数传递给对象的方法并执行。要Shell中增加一条命令，就是增加一个对象，并实现这个对象的方法，以利于今后做进一步的扩充。
5.3μClinux上的应用程序
目前μClinux-dist-0305已经可以在SkyEye上运行。其中的sash(shell)、ping、ifconfig、telnet，telnet server、ftp、ftp server、boa(http server)、mount with nfs support等主要的应用程序都可以成功地运行在SkyEye中，而且不需要对应用程序进行任何修改。
6 SkyEye正在开展的工作
6.1 LCD仿真
作为单片机系统重要的输出设备，LCD屏幕用得非常广泛，因此，我们认为有必要为SkyEye加入LCD控制器设备仿真。我们使用GTK+图形函数库在Xwindow中模拟出一个LCD屏幕，这样在SkyEye上运行的OS,其LCD驱动程序会像驱动真正的LCD控制器一样发送控制命令，而SkyEye解释这些控制命令，并且应地在GTK+绘出的窗口中画不同灰度或颜色的点。这里对GTK+的使用仅限于绘制窗口和画点，因为这是LCD屏幕的最基本动作，其它所有的工作如画图、GUI的实现都应该由应用程序利用画点的功能去实现，与SkyEye本身无关。
LCD的buffer RAM是映射到内存RAM中的。LCD屏幕的每个点对应内存中的1位或几位，各个点所对应的内存按行序连续存放。LCD上显示什么内容，完全由这块内存决定。LCD仿真控制器会根据这块内存去刷新屏幕显示，刷新频率等参数要根据具体使用的LCD屏幕来决定。OS中的`LCD驱动程序要往LCD屏幕上写东西，就是写这块内存。
6.2 基于ARM的其它体系结构的仿真
S3C4510B是三星公司推出的针对嵌入式应用的16/32位嵌入式处理器，是一款应用十分广泛的嵌入式处理器。该微控制器专为以太网通信系统的集线器和路由器而设计，具有低成本和高性能的特点。S3C4510B中内置了ARM公司设计的16/32位ARM7TDMI处理器，可以执行32位的ARM指令，也可执行16位的THUMB指令，并集成了多种外围部件。目前，SkyEye仿真的体系结构还比较少，尝试对S3C4510B的仿真，一方面是使SkyEye能够支持更多的体系结构;另一方面，通过仿真S3C4510B，有助于为SkyEye设计可扩展框架，使SkyEye更具通用性和模块化。
Intel公司的StrongARM芯片SA1110的最高运行速度可达206MHz;其内部有强大的指令操作能力、高速缓冲能力、寄存器管理能力、读/写缓冲器能力。SA1110寄存器总线接口可与DRAM、SDRAM、ROM、SMROM、SRAM以及其它潜在的I/O器件共享数据信号，其寄存器与PCMCIA模块支持4个快速大同小页操作模式(FPM)、扩展数据输出(EDO)、同步DRAM、6个静态存储器、6个ROM/SDRAM等。SA1110可提供系统支持逻辑、多个串行通信通道、1个彩色/灰度LCD控制器、2个PCMCIA插槽、28个GPIO口;内部提供定时器、电源管理、指令控制、复位控制、时钟产生、中断控制等功能。SA1110电源管理提供正常、空闲、睡眠三种工作状态，其内部包含六通道的DMA控制器，用于支持串行通信过程中的数据高速运行，如串行通道与外部寄存器、DRAM、SRAM、Flash、ROM等之间的通信;此外，还有1个用于支持LCD控制器工作的独立的DMA控制器SA1110，它有5个独立的串行通道，可分别执行半双工被动协议的通用串行总线(USB)通信、红外数据(IrDA)通信、多媒体通信口/同步串行口(MCP/SSP)通信等。SA1110通过指令和数据断点提供调试支持，还提供JTAG口，用于进行系统连续检查。通过对StrongARM芯片的仿真，除了有助于SkyEye设计可扩展框架外，还将推动下一步对Intel的XScale系列CPU的研究。
5.3 SkyEye集成开发环境的实现
集成开发环境是SkyEye的一个重要组成部分，利用它，可以直接在可视环境中编辑、编译、调试和修改OS代码，方便了软件开发和称一。由于SkyEye的用户接口是基于GDB的，所有支持GDB的集成开发环境都可以很容易地移植为SkyEye的集成开发环境。目前的Windows版本借鉴Dev-Cpp的源代码，主要与Cygwin版本的SkyEye进行通信，以进行方便的、可视化的调试。Linux版本的IDE采用的是修改过的KDevelop3.0，目前它能和SkyEye进行很好的集成，完成全以充分利用Kdevelop3.0的强大功能。
6.4 SkyEye可扩展框架的设计
目前SkyEye各个部分的仿真还是紧耦合的，各仿真模块之间的接口还不够清晰，这不利于SkyEye的扩展。如果要支持更多的CPU和嵌入式环境，需要很大的工作量，而且用户也无法进行二次开发，阻碍了SkyEye的进一步推广和应用。这就需要为SkyEye设计一个可扩展框架。目前，框架的设计要集中于定义和实现CPU的内部接口，如内存接口和协议处理器接口等，以让它支持更多的CPU;下一步会为SkyEye设计虚拟外部接口，让用户可以根据自己的硬件或者应用，来定义外设的功能，并能在SkyEye上方便地仿零点和验证，从而为用户增加二次开发的功能，让SkyEye得到更广泛的应用。
7 总结与展望
经过几个月的努力，SkyEye已经有了很大的发展，各方面的工作已经按照计划有条不紊地进行着。可以说，SkyEye作为嵌入式系统的仿真环境，已经成为学习嵌入式系统十分
有效的工具。同时，SkyEye在许多方面还有待手改进：一是要提高SkyEye的易用性，这就需要完善SkyEye的集成开发环境，改善其用户接口;再就是提高SkyEye的通用性，这需要SkyEye支持更多的外围设备、更多的体系结构乃至更多的CPU类型。
嵌入式环境 篇3
关键字：大数据 嵌入式服务 信息服务
中图分类号： G252 文献标识码： A 文章编号： 1003-6938（2014）01-0030-05
Analysis on Model of Information Services Embedded Process of Scientific Research in Big Data Environment
Abstract In this paper the requirements on which information services of scientific research process are explored， and the connotation and elements of information services which supporting data-intensive scientific research are discussed. On this basis， it summarizes the typical characteristics of model of information services embedded process of scientific research. And then， the new challenges are analyzed.
Keywords big data； embedded service； information service
1 引言
如今，大数据这个术语已是耳熟能详，它通常是海量的、形式多样的、非结构化数据的代名词，是信息化、网络化快速发展下要经历的必然过程[1]。与此同时，在现代科学研究过程中，数据量的生成呈现指数增长也是显而易见，不管是由于高通量的科学试验，还是千万亿次的科学计算，高分辨率的传感器，以及错综复杂的网络科学研究环境。
因此，在大数据环境下，科学研究人员的信息需求和科学研究模式发生了显著性的变化，而嵌入科研过程的信息服务在科学研究的整个流程中，始终坚持以科研人员为中心的原则，从其课题选定到结束的整个过程提供具有广度的信息展示，个性化的信息推送和深度的信息互动。而科学研究的本质是信息的整理和分析[2]，鉴于此，为顺应科研环境的转变，如何为科学研究人员提供高效的数据管理和新型的信息服务模式，是值得思考和探讨的。
2 科学研究过程中信息服务的需求分析
2.1 科学研究模式的转变
科学研究正在进入一个崭新的阶段，在信息与网络技术迅速发展的推动下，大量从宏观到微观、从自然到社会的观察、感知、计算、模拟、传播等设施和活动产生了大量的数据。同时，学科的发展逐渐呈现交融化、协同化和复杂化，研究人员逐渐把数据作为科学研究的对象和工具，基于数据来思考、设计和实施科学研究，因此促进了数据密集型科学的兴起，使密集型数据成为科学研究活的基础，并逐步总结形成了科学研究第四范式的研究模式[3]。
从科研人员的原始数据，相关数据到科技文献的产出，研究过程中的数据和信息既是研究创新活动的参考资源和知识创造工具，又是新的研究的起点，科研人员必须在此基础上依赖资源的数字化、交流手段的网络化、科研工作的协同化以及科研数据的共享化来把握科学的发展规律，洞悉海量数据背后的信息和知识。然而科研人员研究对象和环境的转变，使其对信息的发现和分析能力愈加欠缺，直接导致在数据的挖掘和信息的管理方面面临着挑战。以数据为驱动的数据密集型科学研究改变了科研人员的信息行为模式，同时也产生了新的信息服务的需求。
2.2 大数据环境下科学研究用户的信息需求
当前，密集型科学数据作为大数据的重要组成部分，在具备大数据特征的同时，在数据分析和管理方面有更高的要求[4]，必然导致科研人员对研究过程的个性化、专深化、集成化和协同化的信息需求不断增强。
（1）大数据环境下科学研究对象的虚拟化，导致科研人员拥有更强的数字化交互式的信息管理能力需求。网络快速传播迅速产生的海量科学数据以及大量来自互联网的数据和信息成为科学研究的主要组成对象，使得研究转变成以网络为基础的高度协作性活动，如何对海量虚拟化的数据和信息进行有效管理，成为科研人员必须面临的问题。
（2）大数据环境下科学研究需求的深度知识化，导致科研人员拥有海量数据实时的分析挖掘需求。一方面，以网络为基础的数字信息资源改变了科研人员的研究行为，数据的获取不是问题的关键，而关键在于数据背后的深度知识挖掘；另一方面，科研人员需求泛化的同时，更加专深化。如何根据每个科研人员独特的研究特征进行数据的跟踪、比对和分析，使专业化和针对性的知识实时获取，成为科研人员必须面临的问题。
（3）大数据环境下科学研究交流方式的便捷化和多样化，导致科研人员拥有科学数据融汇和多学科协同的信息资源共享需求。在数据密集型的科学研究学术交流过程中，交流方式随着信息技术的不断深入，而愈加便捷，但是对于整合所有科学数据和文献，形成一个具有全球开放获取的互操作世界，仍有相当大的差距[5]。如何使科研人员在查看文献的同时能够找到文献的所有原始数据，并可以在此数据基础上，重现作者的分析过程，成为科研人员必须面临的问题。
3 嵌入科研过程的信息服务模式的分析
3.1 嵌入科研过程的信息服务模式的含义
模式通常被解释为某种事物的标准形式或使用人可以照着做的标准样式[6]。即模式是将解决某类问题的方法总结归纳到一定的理论高度，并用来帮助指导人们设计优良的解决方案和完成某类任务的方法论。因此，模式是方法的抽象概括和总结，是解决某一类问题的方法论。而信息服务，在传统上认为的是以信息资源为基础，利用各种方法或技术手段对信息进行收集、整理、使用并提供相关信息产品和服务的一种活动[7]。并且伴随着科研用户需求的多样化，逐渐转变成通过研究用户，以用户的需求为导向来收集相关的数据和信息，进行信息组织和分析后，将有价值的信息传递给用户最终帮助用户解决问题，来实现信息增值。从这种意义出发，服务主体、服务客体、服务方法和服务内容是信息服务模式的主要组成部分，这些要素及其相关关系成了区别不同模式的主要依据。
nlc202309040720
另外，嵌入式理论提倡把事物的产生、发展和特点与其周遭环境联系起来，放到更大的背景中去考察[8]。而嵌入科研过程就是融入科学研究的整个细节和流程中，考虑科研用户需求的产生与发展，从课题选定到结束的整个过程中提供满足科研人员的具有全局性和个性化的信息与知识需求。将嵌入式理论应用到科研信息服务中，在一定程度上满足了在网络环境下科研人员面对的数据量体量大、结构多样化、生成速度快、价值密度低的研究问题的个性化服务需求。
因此，嵌入科学研究过程的信息服务模式将数据管理与信息服务融入到科研用户一线，嵌入到用户科研环境和科研过程，是以专业的信息服务人员为基础，采用先进的计算机技术（如云计算、语义网和Web3.0等），构建具有强大的资源整合能力、海量信息分析能力、大数据挖掘能力和多维度信息可视化能力的集成平台，以科研用户需求环境和需求趋势为导向，是一种面向用户发现问题、分析问题、解决问题和提供解决问题决策的信息展示、交互和推送的服务模式。
3.2 嵌入科研过程的信息服务模式的要素
信息服务模式是对信息服务活动的组成要素及这些要素之间相互关系的概况[9]。基于此，笔者将大数据环境下科学研究过程中的服务需求，组成嵌入科研过程的信息服务模式的服务主体、服务客体、服务方法及服务内容四个要素相结合并逐一进行分析。
3.2.1 服务主体
嵌入科研过程的信息服务模式的服务主体是信息服务活动的实施者，即信息服务人员，其根据科研人员的需要，采取相应的服务策略，提供满足研究者需要的信息服务产品。在嵌入科研过程服务的环境下，一方面，服务主体要求嵌入科研人员情景中，并作为研究团队成员，通过现场交互（包括现场和网络渠道），来把握知识需求、组织知识环境、定制知识工具和提供服务成果[10]。另一方面，服务主体提供的信息服务产品具有实时性、多样性、针对性和易用性的特点，更加注重将科研人员自身的知识背景，研究工具、研究领域的实时动2态以及研究目标与信息服务产品的有机结合。
鉴于此，嵌入科研过程服务的提供者应需要包括：①具有对信息内容强大而灵活的分析能力的信息分析师；②具有支持信息资源知识化处理能力的知识建构师[11]；③具有精通各种发现、分析和组织知识的方法与工具的检索与组织专家；④具有对特定领域深入了解的情报分析专家和学科专家。这样通过其之间的合作与互补，将大量跨领域科研人员、海量密集型的科学数据、信息内容和分析过程有机地融汇起来，促进科研人员高效推动成果的创新。
3.2.2 服务客体
嵌入科研过程的信息服务模式的服务客体是指信息服务的需求者，在一个特定的项目实施过程中，服务的需求者可根据应对研究问题的规模和复杂程度的人员数量进行划分，包括了科研团队群体需求者和单一科研人员需求者。
而鉴于嵌入科研过程的信息服务模式对于服务主体、服务方法和服务内容有更严格的要求，其成本也是相对较高的。因此，对于服务客体也有特定的要求，其中主要应包括以下两个方面的科研人员：一方面，对于攻克涉及多学科，跨领域的重点研究项目的研究团队，其面临的课题更具开放性与不确定性，研究过程中随之而来会遇到更多复杂的技术、方法等方面的难题，对于多学科的深层次信息服务拥有更强烈的需求；另一方面，对于引导学科发展方向的先驱，其面临的课题更具专深化与前沿性，研究过程中随之而来的是以战略眼光审视研究问题，对于特定性的实时动态信息服务拥有更强烈的需求。这样，嵌入科研过程的信息服务模式对于跨学科、跨国界和跨领域的重大科研项目以及具有前沿战略性的研究工作无疑是一种值得考虑的服务模式。
3.2.3 服务方法
嵌入科研过程的信息服务模式的服务方法是针对科学研究的信息服务手段，其主要是为服务主体完成信息服务行为提供有效的工具。服务方法随着科学研究方式的转变而不断变化，如今，现代科学研究朝着数据化和计算化的方向发展，从计算科学中逐步分离出了数据密集型科学，所有资源对象都被信息化、数字化表征，海量科学数据被迅速和大量创造，并经过网络快速传播。这样，促使了新型的信息服务方法根据研究人员的研究场景，将研究过程中的信息或知识深度地嵌入到解决科学问题的各个过程，促使科研人员的知识发现和知识创造。基于嵌入式理念，在总结传统信息服务方式的文献代查、专题报告总结的基础上，笔者进一步深化了嵌入科研过程的信息服务模式的服务方法。
通过对研究问题的处理流程进行分析，在此将嵌入科研过程的信息服务模式的服务方法从四个方面进行展开：①嵌入科学研究过程的语义关联的信息资源发现服务，在各类数字资源中嵌入语义导航体系，并融入科研人员与系统交流，构建关联主题图，触发知识的偶然发现；②基于用户情景的开放式信息资源获取服务，采用模块化组装思想，进行信息关联与协同化组织管理，根据科研人员当时当地具体情境自适应地提供获取服务；③集成信息资源云平台的大数据交互式的挖掘服务[12]，科研人员针对个人分析问题、解决问题的独特方式，借助云平台中开放的分析挖掘工具进行相关的大数据深度分析，对于潜在问题进行定向分析；④融于可视化技术的动态多维信息资源呈现服务，从科研人员体验入手，支持图像界面、语音界面和触摸屏界面，以构建、传达和表示复杂信息或知识，通过丰富的数据观察方式帮助科研人员识别隐性信息。
3.2.4 服务内容
嵌入科研过程的信息服务模式的服务内容是确定的信息产品，是服务主体交付给服务客体的最终成果或其享受到的各种信息服务。其主要保障科研人员在研究过程中项目的顺利推进以及促进科研人员的自主创新和交叉融汇创新。在项目处理生命周期中嵌入科研过程的信息服务内容（见图1）。
（1）评价与预测性信息推送。在识别问题的基础上，服务主体一方面通过当前现状的调查和相关问题的数据集分析挖掘，向科研人员提供其研究发展前沿与趋势的预测性研究成果；另一方面，分析国内外当前类似项目组的科研状况与进展，评价其优势与劣势，为项目的选定提供参考性和建设性建议。
nlc202309040720
（2）方案规划信息参考咨询。将服务主体嵌入到项目规划中，不仅有助于服务主体能对项目在一定程度上有整体性和全局性的把握，而且有利于服务主体与服务客体的沟通，形成优势互补。同时，服务主体以用户需求为导向，通过多层次的探讨，采用相应的工具，提供个性化的参考咨询，保证项目规划的科学性。
（3）过程管理与信息重构。数据密集型科研环境下实施项目，必须利用海量信息分类聚类、抽取要点和发现关系，来分析揭示隐藏的知识结构。而通过对信息网络的重构，进行趋势分析、问题鉴别和路径探索是服务主体的优势。利用这一优势可以减轻科研人员的负担，使其能够集中精力于自己的研究领域。同时，在实施过程中遇到的困难，服务主体将实施情况与规划对比，关注偏差，实时采用相应的服务方法帮助科研人员分析原因，提供可借鉴的解决方案。
（4）专题信息关联性管理。在项目结题过程中，服务主体一方面依据数据生命周期全面分析整理并记录科研用户的数据处理情况，另一方面依据研究生命周期细致总结各阶段研究成果，并将相关的数据、信息和知识进行关联、回溯与保存。
4 嵌入科研过程的信息服务模式的特征
嵌入科研过程的信息服务模式是以信息服务为轴心，以科研用户为中心，以数据资源为核心，以科研用户需求为导向，以嵌入式信息服务团队为重心开展工作。信息服务是嵌入科研过程的信息服务团队提供的工作内容，服务团队的工作是围绕信息服务这一根本而展开的。满足服务客体的实际需求和潜在需求是嵌入式信息服务团队工作的最终目标，而为了达到这一目的，嵌入式信息服务团队需要掌握核心的数据资源技术，以便能够在课题查新、文献检索、隐性知识挖掘方面提供个性化、专业化的服务。
4.1 覆盖协同多领域
科学研究是一个创新的过程，其需要具备的信息亦是多样的，这样嵌入式信息服务团队对于科研的促进作用也是显而易见的。一方面，学科的交融，科研项目的合作紧密化，科研用户除了需要本学科研究的信息外，还需要大量交叉学科的知识，嵌入式信息团队中的学科专家能够采用辅助或合作的形式为科研用户提供满足其需求的个性化相关学科的信息或知识；另一方面，多领域科研用户的合作，必须保证科研团队间的目标协同和科研资源的组织协同，嵌入式信息服务团队能够与科研用户加强交流互动，与用户建立长期稳定的协作关系，并构建协同工作机制，来保证服务内容的有效性和针对性，服务方式的准确性和高效性。
4.2 贯穿科研全过程
科学研究是在现有的研究基础之上来对未知事物的探索性活动，这就导致了科研用户的研究活动具有动态的信息需求，在科研项目的选定阶段，嵌入式信息服务团队能够以伙伴合作型方式推送课题项目的研究背景、研究综述和研究进展；在科研项目的规划阶段，嵌入式服务团队能够整体和全局地把握课题项目所使用的相关技术或研究计划方案；在科研项目的实施阶段，嵌入式服务团队能够根据用户的需要，跟踪国内外研究进展和动态信息，对海量信息进行深入分析，对隐性知识进行全面挖掘；在科研项目的结题阶段，嵌入式信息服务团队能够根据信息的生命周期，将信息进行归类、关联与保存。
4.3 情景感知个性化
科学研究的主体是科研用户，而科研用户情景是指用于表征与交互环境相关的实体状态的信息集合，包括用户位置、所处时间、用户情绪、心理状态及其相互关系等[13]，能够实时动态地获取科研用户情景信息，把握其具体需求，是科学研究活动高效推进的重要保障。与之对应，情景感知是对用户情景的获取与应用[14]，嵌入科研过程的信息服务模式通过以下两个方面的用户情景感知来提供个性化服务：一方面，科研用户与系统的交互，嵌入式信息服务团队通过监控用户在学科社区、博客和学科群等挖掘科研用户偏好和相关隐性信息需求；另一方面，嵌入式信息服务团队通过与科研用户协同交流，及时感知获取用户的长期目标和短期目标，根据科研用户的潜在需求来组织信息环境、定制信息工具、提供个性化的推送服务。
5 嵌入科研过程的信息服务模式所面临的挑战
数据密集型科学下的科研范式，更加强调科研人员在网络环境下的协同交流、资源开放、信息共享、智能关联与协同应用。嵌入科研过程的信息服务模式在促进现代科学研究创新的同时，也面临着一系列的问题和挑战，寻求合适的标准规范和技术对策有助于切实推动新型信息服务模式的转变，促进科研过程的推进与创新。
（1）嵌入到用户科研过程并且根据用户研究背景提供个性化信息推送对情报研究人员的挑战。一方面，大科学的兴起，科研人员的研究课题通常会涉及多学科和多领域的研究，这就要求情报研究人员具有跨学科的综合分析和信息获取能力，从多视角、多层次为科研用户提供信息服务；另一方面，将情报研究人员嵌入到科研过程，其必须具有战略性的眼光，对研究的整个过程有全面的认识，明确每个阶段为科研人员提供的信息服务类型，通过自身的优势提供其所需的信息资源，必要时能够进行科研项目的管理，以情报分析的严谨性来引导科研过程的科学性。
（2）新型技术的应用对密集型科学数据的全面整合与共享的挑战。首先，大数据时代的到来，使科学研究正在被大量密集型的数据所淹没，在数据的分级、归档、备份和保护的问题上对数据共享的性能提出了挑战[15]；其次科学研究大数据集涵盖了各类学科、各类层次研究人员或团队、各个研究阶段以及各类来源的数据集合，这些数据集合的多样性与复杂性对其整合提出了挑战；最后科学研究范式发展成为以数据为驱动的研究模式，强调将科研数据集合长期保存，并且将数据与关于数据的文件集合成一体，数据的流动、交互、融合、引用和回溯都将记录并保存下来，这对数据资源的整合与共享提出了又一新的挑战。
（3）研究环境的变化以及相应信息服务方法的转变对数据分析挖掘能力的挑战。一方面，密集型数据分析挖掘成为信息服务必不可少的支撑点，而密集型数据在具备大数据特性的同时，必然使传统的分析挖掘工具和算法面临着挑战；另一方面，嵌入科研过程的信息服务模式的服务主体需要利用数据对科研创新合作过程及交互型信息服务过程将要发生什么进行分析和预测，以便为服务客体实时提供相应的辅助决策，这种综合性和多维性的预测对数据实时与深度挖掘提出了挑战。
nlc202309040720
6 结语
大数据不仅仅是数据量的剧增，也不仅仅是信息技术的飞跃，而是人类对客观世界认知飞跃的前奏[16]，科学研究已进入数据密集型科学知识发现，因此，研究构建对科学数据、模型工具以及大数据挖掘平台，支撑跨区域、跨学科和跨团队的协同研究，满足现代科学研究需求的信息服务模式，对于促进科研创新是非常重要和迫切的。
另外，深层次的嵌入科研过程的信息服务模式由于成本、技术和人员素质要求等限制，只能针对特定的有高度需求的科研人员或群体。但是，一方面对于嵌入科研信息服务模式的服务主体学科背景知识、新型技术的运用能力、嵌入服务意识、沟通能力和协作能力提出了更高的要求；另一方面，对于不同的科研人员和工作环境如何采用多样化的服务方法来提供个性化的服务内容，促使其提升科研效率，也面临着极大的挑战。毫无疑问，面对全新科研范式带来的强大动力，利用信息服务模式的转变来推动科学研究的不断创新和发展将是大势所趋。
参考文献：
[1]刘明，李娜.大数据趋势与专业图书馆[J].中华医学图书情报杂志，2013，22（2）：1-6.
[2]王凭慧.科学研究项目评估方法综述[J].科研管理，1999，20（3）：18-24.
[3]王学勤，Amy Stout， Howard Silver.建立数据驱动的e-Science图书馆服务：机遇和挑战[J].图书情报工作，2011，55（13）：80-83.
[4]Delserone L M. At the watershed： Preparing for research data management and stewardship at the University of Minnesota Libraries[J].Library Trends，2008，57（2）： 202-210.
[5]Tony Hey.潘教峰译.第四范式：数据密集型科学发现[M].北京：科学出版社，2012.
[6]中国社会科学院语言研究所词典编辑室.现代汉语词典[M].北京：商务印书馆，2005：301-302.
[7]张树华，王京山，刘录茵，等.数字时代的图书馆信息服务[M].北京：北京图书馆出版社，2005：1-9.
[8]秦铁辉.嵌入性理论对情报学研究的启示[J].图书情报工作，2009，（12）：1-3.
[9]刘媛筠，李志民.当代图书馆的三种信息服务模式[J].图书馆杂志，2013，（1）：26-31.
[10]张晓林.研究图书馆2020：嵌入式协作化知识实验室[J].中国图书馆学报，2012，38（197）：11-20.
[11]张晓林.走向知识服务：寻找新世纪图书情报工作的生长点[J].中国图书馆学报， 2000，（5）：32-37.
[12]樊伟红，李晨晖，张兴旺，等.图书馆需要怎样的“大数据”[J].图书馆杂志， 2012，（11）：63-68.
[13]万亚红，黄樟钦，陈旭辉，等.基于主动推理的情景感知系统框架[J].计算机工程，2004，30 （12）：8-9，70.
[14]KM S W， PARK S H， LEE J B. Sensible Appliance： Applying Context-awareness to Appliance Design [J].Personal and Ubiquitous Computing，2004，8（3）：184-191.
[15]Science Staff. Challenges and Opportunities[J]. Science Special Issue： Dealing with Data，2011，（331）：692-693.
[16]Felice Frankel， Rosalind Reid. Big data： Distilling meaning from data[J]. Nature， 2008，7209，（455）：30-33.
作者简介：邓仲华（1957-），男，武汉大学信息管理学院教授，博士生导师；李立睿（1989-），男，武汉大学信息管理学院研究生；陆颖隽（1963-），男，武汉大学信息管理学院副教授，硕士生导师。
嵌入式环境 篇4
近年来随着网络化概念的不断推广,嵌入式系统也摆脱了以往“信息孤岛”的封闭局面,相互之间逐渐形成了分布式的协作关系。然而嵌入式系统在网络的应用层上常常采用自定义的传输协议,加之各系统之间巨大的平台差异性,给系统间的互访以及企业级信息的集成带来了困难[1]。Web Service技术具有良好的跨平台和松耦合特性,能够实现不同平台的分布式系统之间的无缝集成,降低了企业进行设备升级和服务重组时的投入[2]。本文以32位微处理器ARM Cortex-M3为核心,借助于嵌入式TCP/IP协议栈和实时操作系统,在嵌入式环境下实现了Web Service技术。
1 Web Service与SOAP协议
Web Service是网络化应用的一种,可以将其看成一种函数调用,只不过这个函数的实体存在于某个服务器上,而对函数的调用在客户端进行,客户端只要接入装有服务的机器所在的网络即可调用函数。为了实现这种远程调用,需要对传输的数据格式采取一些约定措施,简单对象访问协议(Simple Object Access Protocol,SOAP)很好地应对了这种需求[3]。SOAP协议以XML形式提供了一个简单、轻量的机制,用于在分布环境中交换结构化信息。SOAP本身并没有定义任何应用程序语义,如编程模型或特定语义的实现;实际上它通过提供一个模块化的封包模型和在模块中进行数据编码的方法,定义了一个简单的表示应用程序语义的机制[4]。
SOAP消息是由Envelope,Header和Body三部分组成的XML文档,其中Envelope是SOAP消息的根元素,必须在SOAP消息中出现;可选的Header元素包含有关 SOAP 消息的应用程序专用信息;必需的Body元素包含打算传送到消息最终端点的实际SOAP消息[5]。最后,为了进行基于SOAP的远程调用,需要一种低级传输协议。SOAP规范允许使用HTTP,SMTP甚至原始的TCP/IP套接字,其中HTTP协议最为常用。
2 Web Service在嵌入式环境下的实现
2.1 底层软硬件结构
本文中所使用的硬件基于ST公司推出的ARM Cortex-M3 32位微处理器STM32F107VC[6]。Cortex-M3是针对价格敏感但又有高系统效能需求的嵌入式应用而设计的ARM内核,作为ARM7的后继者,大刀阔斧地改革了设计架构,显著简化了编程和调试的复杂度,处理能力也更加强大[7]。STM32F107VC工作频率最高为72 MHz,带有256 KB的片上FLASH和64 KB的SRAM,以及以太网MAC控制器,因此外接一片PHY芯片RTL8201,完成与以太网的物理通信。
为了达到实时任务管理,本文选用嵌入式实时操作系统FreeRTOS和轻量级TCP/IP协议栈lwIP组成底层软件开发平台。FreeRTOS作为一个免费开源的小型实时内核,主要用于建立和管理各个模块的任务[8];lwIP则为数据的TCP/IP封装提供了一个良好的软件基础[9]。
2.2 SOAP消息的处理
目前已经有许多成熟的SOAP工具,例如针对C++的gSOAP、针对Java的kSOAP等,但是这些实现方案均是为PC机或者带有高级操作系统的嵌入式系统设计的,对资源的消耗较多。对于低端的嵌入式环境,需要更轻量型的处理方法。
由前文可知,SOAP可以简单的理解为HTTP+XML+远程调用规则,因此SOAP消息的处理也分为3步:HTTP协议的实现、XML解析、具体服务实现。其总体结构如图1所示。
SOAP在HTTP上的远程调用的具体实现过程大致如下:客户端通过SOAP工具生成基于XML文档的SOAP消息,在该SOAP消息里包含有客户请求的服务名称及调用服务程序所需的参数,并使用HTTP POST方法通过网络向应用程序所在的服务端发送 SOAP请求;另一方面,当服务端接到HTTP信息之后,又从中提取出SOAP 消息,启动XML文档解析器进行解析,获取客户需要调用的方法名及其参数,以此来调用相应的服务程序,之后以类似的方法将运行结果打包成SOAP消息返回给客户,完成应用程序的远程调用。
2.2.1 HTTP协议的简单实现
HTTP是基于请求/响应模式的协议,客户端的通信过程一般分为4个步骤:建立连接、发送请求消息、接收响应信息、关闭连接。HTTP定义了众多请求方法(Method),如GET,POST,HEAD,DELETE等[10],由于SOAP主要使用POST方法来发送请求,因此HTTP的实现集中在POST方法上。SOAP协议中规定 POST 请求至少包含两个 HTTP 头,Content-Type(定义MIME类型)和Content-Length(定义消息的长度)。例如:
如图2所示,程序利用lwIP提供的API创建一个监听连接,绑定到HTTP的80号熟知端口上,当接收到POST请求时检查必要的HTTP头,之后开始接收HTTP正文(SOAP请求),并将接收到的请求存放在预先开辟的缓冲区中,再交由XML解析器处理。为了节省资源,将SOAP消息解析和HTTP接收放在同一线程,一次只处理一个SOAP请求,因此整个解析过程只需要一个缓冲区。同时开启连接超时机制,如果客户端连接后长时间无动作,接收程序将切断连接,避免后续请求无法得到响应。
2.2.2 XML解析
SOAP消息是由XML语言组成的,因此对XML的解析是处理SOAP消息的一个重点。当今有2种流行的XML解析API,它们是DOM(Document Object Model)和SAX(Simple API for XML),尽管这两种方法都能用来解析XML数据,但相互间却有很多本质的不同:DOM一次性把整个XML文档读入内存并建立完整的树结构,而SAX则基于事件驱动模型,一次只读取一个XML元素,每当遇到一个读取事件时就会触发一个事件处理器[10]。两种方法各有优缺点:DOM在处理单个元素之前必须把其他所有的元素都读入内存建立树结构,这既费时间又费内存,在这方面SAX的性能更为优异,但DOM一旦建立树结构之后,就可以方便地处理文档中的任意元素,因为整个XML结构都在内存里,而SAX则必须从头逐个解析XML文档每一个元素,直到需要的那个元素。
考虑到SOAP消息的解析是一次性的过程,不需要进行元素的随机访问,而且嵌入式环境下资源有限,为此采用SAX做为XML的解析方式。定义以下结构体用来存储节点结构。
另外建立一个列表用来存储XML文档中声明的命名空间,避免XML文档里的元素名或属性名相互之间可能会发生的语义冲突。在XML文档的解析过程中,保留当前节点及其父节点的结构体,除此之外的节点在读取完毕后立即释放其占用的资源,必要时还可以关闭对节点属性的解析,进一步降低内存消耗。当遇到新的读取事件时(节点开始、节点结束、发现节点值),将此次事件的相关信息作为参数传入回调函数,在回调函数中对节点信息进行处理:
2.2.3 具体服务实现
为了方便查找服务,程序里将所有支持的服务函数的名称以及对应的命名空间预先保存在一个列表中。当进入XML解析的回调函数后,根据XML节点的节点名称以及命名空间,首先试图从列表中搜索本次SOAP消息所请求的服务,如果所请求的服务函数存在,则将XML节点信息传入该服务函数对应的初始化函数,完成对服务函数的参数列表的初始化,为之后的服务函数执行做好准备。图3给出了该过程的程序框图。XML解析完毕后退出XML解析器,此时服务函数也已经完成初始化,直接调用服务函数的执行部分,并将结果打包成SOAP格式发送回客户端。鉴于动态生成XML文档需要耗费较多的资源,程序中为每个服务函数预存了一个模板,模板中已经定义好了回复消息的整体结构,仅需在服务函数被实际调用后往模板中填入结果即可,另外可以在发送回复消息的过程中复用之前的接收缓冲区,这样一来同时节省了处理时间和资源消耗。
2.3 性能测试
由于Web Service函数是被其他程序调用的, 一般不会提供界面让用户或测试人员直接使用,这造成了测试上的困难。由eviware公司推出的Web Service测试软件soapUI极大的改变了这一局面,在soapUI中通过简单的操作即可完成复杂的测试,不需要了解底层的通讯细节, 大大减轻了工作量。为了测试系统的性能,将STM32F107VC接入局域网之中,并开启A/D采样,客户端通过Web Service函数ReadValue获取指定通道的A/D采样值(最大值、最小值、平均值)。SOAP消息的具体请求和响应示例如下:
在soapUI中模拟多个用户线程对系统进行90 min的压力测试,每个线程每次的请求间隔随机分布在0.5～1 s之间,图4给出了10个用户线程下系统的平均响应时间曲线,其中横轴表示经过的时间(单位:s),纵轴表示线程个数以及SOAP请求平均响应时间(单位:ms)。由于系统同一时间只处理一个SOAP请求,当多个用户线程同时连接时,未处理的请求会被排队,其处理时间也会相应延长。受网络环境变化和连接并发情况的影响,平均响应时间会出现波动,在10个线程的情况下平均响应时间介于30～50 ms之间,整个系统保持稳定,没有内存泄露或者连接丢失现象发生。
3 结 语
本文基于32位微处理器ARM Cortex-M3以及小型实时操作系统FreeRTOS,在资源极其受限的情况下完成了XML语言的解析以及SOAP和HTTP协议的绑定,实现了不易实现的嵌入式Web Service技术。XML语言强大的表达能力和SOAP协议的灵活性,有效地解决了嵌入式设备与异构平台间的信息交换问题,大大降低了系统集成的难度。随着网络化思想的进一步深入以及硬件成本的逐步下降,面向服务的编程思想所代表的新一代软件架构技术会逐渐渗透到越来越多的嵌入式系统当中。
嵌入式环境 篇5
嵌入式通信设备 (比如移动电话、掌上电脑等) 已经成为人们学习生活工作不可缺少的一部分, 在日常生活中已经起到了越来越重要的作用。因此在嵌入式系统下求解微分方程产生混沌信号, 并将其应用于保密通信中的研究意义是非常重大的。随着更高级别、更复杂且实用的嵌入式系统和可编程逻辑器件的快速发展, 使基于混沌的通信系统向市场化方向越来越近了。已有事实证明, 基于混沌的通信可以在一定程度上解决现有通信系统诸多矛盾和缺陷, 有较强的发展潜力。有专家预测: 基于混沌的通信技术将是21世纪通信技术研究的重要方向之一, 因其广阔的应用前景正在被专家学者所深入研究。
2 嵌入式系统硬件组成
嵌入式系统强调的是硬件与软件的整体协同性, 在一定的项目开发要求下, 要尽可能挖掘系统的软硬件能力, 能够根据实际开发项目需要对软硬件进行选择, 根据项目需要对系统进行裁剪, 最终得到性价比较高的设计方案。嵌入式系统的核心是系统软件和应用软件, 由于存储空间有限, 因而要求软件代码最优化且运行可靠, 一部分嵌入式系统还对实时性有较严格的要求, 硬件整体结构如图1所示。
为了更快地研究嵌入式系统下混沌动力学特性, 嵌入式系统硬件部分是选用TQ2440实验板。
TQ2440实验板包括CPU核心板及底板, CPU核心板单独布置, 选用的处理器内核为ARM920t, 它是ARM9系列的一款通用微处理器, 采用哈佛结构。该处理器由ARM920t内核、内存管理单元 (MMU) 和高速缓存组成, ARM920t采用五级流水线(Fetch、Decode、Execute、Memory及Write) 体系 , 具有16K字节指令及16K字节数据缓存, 内置追踪宏单元接口和写缓存。
底板上电路主要包括3.3V供电电路、Jtag电路、复位电路以及Nor/Nand Flash启动选择电路等。
3 搭建开发环境
研究采用的嵌入式Linux操作系统版本为Linux-2.6.30.4,交叉编译器版本为EABI-4.3.3。Linux操作系统作为嵌入式系统中的一种, 内核源码以及驱动程序源码是开源的。开源代码好处就是: 开发过程快捷简单, 一些代码不需要自己编写。可根据所选的CPU型号及外围芯片型号修改u-boot程序下的相关文件、Linux内核配置及系统驱动程序, 使软硬件匹配,从而大大缩短开发周期。
所采用的是Linux内核的Fedora系统, 搭建开发环境步骤如下:
(1) 首先进行VMWARE workstation虚拟机安装。
(2) 在虚拟机下导入下载完成的Fedora10系统的文件 ,按照安装的预定步骤设置好虚拟机内存大小、挂载的分区大小、共享目录、网络连接方式及其他事项, 然后进行安装。
(3) 安装完Fedora10操作系统后 , 进行交叉编译工具安装, 交叉编译器是允许开发者在一台主机上编译生成某一个目标系统的二进制代码, 对于下位机是Linux系统及ARM硬件平台的组合, 应使用“arm-linux”格式的工具包。利用如下命令修改配置文件, 使交叉编译器生效: #gedit /etc/profile。
执行这个命令的目的是打开环境变量的配置文件, 在配置文件中修改所要添加的交叉编译器的绝对路径, 也即是export PATH=/绝对路径/:$PATH
#source /etc/profile
执行这个命令的目的是更新配置文件, 使上一步所添加的交叉编译器的绝对路径在系统终端下生效。
#arm-linux-gcc -v
执行这个命令的目的是测试交叉编译器是否安装成功。
嵌入式Linux都是来源于应用在X86体系结构上的标准Linux系统, 根据嵌入式设备硬件选择以及用户的要求, 对标准的Linux系统进行裁剪和小型化, 最后生成、下载并固化在几MB左右的存储器设备空间内。
嵌入式Linux系统启动分为两个步骤: (1) 系统引导程序, 对一部分的硬件设备进行初始化。Bootloader是嵌入式系统的引导加载程序, 它是系统上电后运行的第一段程序, 其作用与PC机上的BIOS类似; (2) 在完成对系统的初始化任务之后, 开始启动过程的第二步, 对系统的内核镜像文件进行加载。将非易失性存储器中的Linux内核映像拷贝到RAM中去, 然后跳转到内核的第一条指令处继续执行。Linux内核在完成系统的初始化之后需要挂载根文件系统。根文件系统是Linux系统的核心组成部分, 它可以作为Linux系统中文件和数据的存储区域, 通常它还包括系统配置文件和运行应用软件所需要的库。
由此可见, Bootloader和Linux内核有着密不可分的联系,在这里首先介绍Bootloader程序。
4 Bootloader
Bootloader程序是执行在具体的硬件设备上的, 根据不同的硬件芯片型号的选择, 需要修改Bootloader程序代码, 以适应所选择的硬件体系结构。Bootloader程序运行的第一步主要完成的工作如下[15]:
(1) 定义程序的入口地址及设置程序的异常中断向量表。
(2) 对存储设备进行初始化和一些有特殊要求的端口和设备的初始化。
(3) 初始化中断处理程序设置入口以及初始化堆栈指针寄存器状态。
(4) 完成用户程序要执行环境的初始化以及设置程序中断处理的入口地址。
(5) 跳到C程序入口地址处。
目前很多嵌入式系统设计中都采用Flash作为程序的存储介质, Bootloader程序是设定从Nor Flash启动的。由于Bootloader通常存储在Flash芯片上, 内核的映像文件和根文件系统也都下载到这里。
5 编译与移植方法
5.1 U-Boot 编译与移植
U-Boot是用于多种嵌入式CPU的Bootloader程序 , 支持X86、ARM以及MIPS等目标体系。
U-Boot的修改主要是在u-boot的目录体系结构下完成对应部分的修改, 这些子目录里主要包含了不同体系结构的源代码。U-Boot目录包括以下文件内容: (1) board: 开发板相关目录;(2) common: 通用的命令函数; (3) cpu: cpu架构相关目录;(4) doc: 相应开发使用文档; (5) drivers:所支持的设备驱动程序;(6) fs: 支持的文件系统; (7) include: 头文件和开发板配置文件; (8) lib: 与体系结构相关的库文件;(9) net: 各种网络协议等。
在充分理解U-Boot程序整体架构细节的基础上, 可以针对所选择的硬件设备部分修改u-boot程序, 以便适应自己所选择的硬件型号。本文对u-boot详细移植过程不多分析, 只介绍移植思路。
由于U-Boot-1.1.6.tar.bz2版本不支持文中所使用的微处理器S3C2440, 但是对同一个系列的S3C2410却有很完善的支持。移植工作主要是在S3C2410处理器基础上修改完成。移植u-boot到嵌入式系统开发板上, 主要有两个层面的移植工作:第一层面是针对CPU的移植, 第二层面是针对BOARD移植。
当修改完成后, 可以用以下命令进行编译:
#make LL-config
此命令对重新编写后的U-Boot程序进行配置, 其中LLconfig是在uboot源码的根目录下Makefile文件中的一个选项。
#make此命令主要是用于测试编译是否成功。
如果编译成功且正确, 将会在U-Boot目录下生成uboot.bin、uboot以及uboot.srec 3个映像文件。uboot.bin文件是原始二进制的映像文件, 要下载到实验板; uboot是ELF格式的二进制映像文件; 而uboot.srec是S-Record格式的映像文件。
5.2 Linux 内核的编译与移植
在下载成功U-Boot之后, 进行Linux内核的编译, 嵌入式Linux内核编译移植过程[16]关键环节是:
(1) 首先获取Linux内核源代码。
(2) 进入内核的目录文件 , 在Makefile文件中添加对ARM平台的支持, 如图2所示。
(3) 修改所选择的硬件设备的时钟频率 , 使之与外部晶振输入频率相同。
(4) 根据选择硬件设备的型号 , 对设备的驱动程序进行编写或者修改。
(5) 制作与S3C2440实验板相应的配置单 , 内核配置是构建适用于硬件设备的Linux的重要环节, 执行命令: #makemenuconfig, 见图2进入配置菜单后, 根据硬件要求选择相应的配置项制作配置单, 配置完成之后保存。
(6) 在制作完成文件系统之后 , 在fs/Kconfig文件中添加对根文件系统的支持。
(7) 配置完成后, 终端执行以下命令, 对系统进行编译:#make zImage。
(8) 编译成功后, 在linux-2.6.32.4目录下生成zImage.bin的映像文件。在uboot下载成功的基础上, 在找到生成路径后, 把zImage.bin文件下载到实验板上。
5.3 根文件系统编译与移植
支持用户操作系统使用的根文件系统移植也非常关键的。
(1) 建立工作目录 (根目录 ) ,向各个目录文件下添加相应内容。
(2) 交叉编译busybox, 首先添加交叉编译工具, 其次是配置busybox, 最后安装执行。
(3) 复制库文件并建立配置文件。
(4) 制作根文件系统映像并烧写到实验板上。
6 结语
详细介绍了嵌入式Linux系统的开发环境搭建与移植的具体步骤与实现方法, 对研究嵌入式系统开发的研究人员提供了思路与借鉴。为在嵌入式系统下对典型的混沌电路模型进行分析求解, 为进一步实现基于嵌入式系统下的通信数据信息加密奠定了基础。
摘要：选用TQ2440实验板,在嵌入式Linux操作系统下实现了开发环境的搭建与移植。详细介绍了Linux内核的Fedora系统、搭建开发环境步骤、Bootloader程序的使用、U-Boot编译与移植、Linux内核的编译与移植根文件系统编译与移植的具体操作方法。
嵌入式环境 篇6
环境试验设备是一种根据设计不同, 而具备模拟一种或多种综合环境气候功能的自动化设备, 为各种环境试验的实现提供了高效可靠途径。企业或机构在产品设计、研发、制造过程中, 可通过环境试验设备对材料、零部件或产品整机进行各种环境试验, 如高温、高湿、盐雾、砂尘、雨淋、凝露等环境试验, 有效地验证材料或产品是否达到相应标准所要求的质量与可靠性[1]。因此, 环境试验设备是大多数企业与机构验证材料或产品可靠性所必不可少的设备。
控制系统作为环境试验设备的最核心组成部分, 它的控制精度直接影响到该设备所做环境试验的准确性与可信性。目前环境试验设备控制系统的应用型式主要分为通用型与专用型。其中通用型控制系统指的是, 传统的人机界面 (HMI) 与可编程控制器 (PLC) 的组合控制方式, 或工业PC组态软件与PLC的组合控制方式;专用型控制器指的是, 针对不同环境试验设备的控制特性开发出来的专用控制器。国内专用型环境设备控制器领域相对国外较为空白, 这也是造成国内环境试验设备精度与稳定性普遍不如国外环境设备的主要原因, 因此专用型控制器的研发对国内环境试验设备的发展具有相当大的意义。
1 设计原理
本文中的环境设备控制系统, 主要面向温度类环境试验设备, 如高温试验箱、高低温试验箱、冷热冲击试验箱、恒温恒湿箱、湿热箱等[2]。而温度类环境试验设备通常由主箱体、加热系统、制冷系统、风循环系统、主控制系统组成, 如图1所示。
其中整个设备的主要控制对象包括:制冷系统中的制冷压缩机、电子膨胀阀及控制冷量排放的电磁阀;风循环系统的离心风机;加热系统中的固态继电器与交流接触器。
整个设备的主要测量参数包括:制冷系统中的压缩机排气回气的温度与压力、冷凝器出口温度、蒸发器出入口温度、压缩机工作电流电压值;风循环系统中的风机温度、工作电流电压值;加热系统中的电加热器的工作电压电流值;箱内的温湿度等。
在上述测量参数中, 部分参数与设备的控制过程并无直接关系, 如压缩机与风机的工作电压电流、风机转速与风速等。但是, 随着现代科技工业信息技术的迅速发展, 在航天、航空、工业应用等各个领域的设备与系统对可靠性、安全性与经济性的要求越来越高, 促使故障预测和健康管理 (Prognostics and Health Management, PHM) [3,4]逐渐成为工业设备的主流发展方向之一。但是PHM系统是需要建立在全面监测设备的运行状况的基础上, 而使用通用型PLC控制系统的情况下, 过多的参数采集意味着PLC模块的增加, 不但提高了设备的制造成本, 也让设备控制系统的体积变得臃肿。为此, 本文提出了一种基于嵌入式的控制系统, 通过利用嵌入式系统开发自由度高、成本低、针对性强、实时性高、集成度高的方案, 实现设备的整机运行参数监控;且更易实现复杂的算法运算, 提高设备的控制精度与稳定性, 如设备的模糊PID控制算法, 防脉冲干扰平均滤波、限幅平均滤波法等数字滤波算法。
2 控制系统硬件设计
控制系统由控制器与测控模块组成;其中测控模块包括I/O模块与测量模块, 均采用模块化设计, 针对设备所需的配置进行模块式增减;而控制器仅需针对不同配置的设备作出相应的软件设置或调整。这样不仅能低成本地采集设备整机运行参数;又能提高控制系统的集成度, 减小控制模块的体积。控制系统硬件框架如图2所示, 控制器获得测量模块将所采集设备整机参数后, 根据控制设定对I/O模块进行I/O与PID控制输出。
控制器与I/O模块、测量模块间采用基于485接口Modbus协议的通讯方式。由于Modbus总线广泛应用于仪器仪表、智能高低压电器、变送器、可编程控制器、人机界面、变频器、现场智能设备等诸多领域, 因此, 使得控制器与I/O模块、测量模块拥有极大的可扩展性与独立成为产品的可能性。
2.1 控制器硬件设计
本嵌入式控制器是基于A R MCortex-A9四核微处理器的硬件开发平台, 主要负责控制系统中人机界面的运行、逻辑运算、I/O与PID控制。硬件平台采用的Exynos4412处理器拥有高性能的数据处理能力以及较为完备的硬件接口, 为构建Linux嵌入式系统提供了良好的硬件基础。控制器硬件开发平台的功能框图如图3所示, 板载WIFI、3G模块、10M/100M自适应网卡、10.1寸触摸LCD、4路USB HOST等。
硬件平台支持从e MMC或SD卡启动, e MMC用于烧写系统镜像, 因此控制器上电后默认从e MMC启动;而SD卡启动功能可与USB OTG配合实现快速升级固件及系统软件。WIFI、WCDMA 3G、LAN等网络接口均用于不同情况下控制器与互联网的连接, 为实现设备的远程控制、远程故障预警或报警、专家远程故障诊断等新型应用提供了硬件支持。
为了保证控制器能与测控板实现高速实时可靠的通讯, 本控制器两路RS485通讯电路设计均基于ADM2483。ADM2483是集成通讯隔离的RS485收发器件, 最高通讯速率可达500kbps, 在保证通讯速率与抗干扰能力的前提下, 避免了采用光耦隔离设计需占用较大PCB布局面积的情况。且ADM2483采用了限摆率设计, 把压摆率降控制在一个适当的水平, 能降低不恰当的终端匹配与接头产生的误码。而通讯模块的接口电路则采用了限流限压的设计, 如图5所示, 稳压管D1、D2与自恢复保险丝PTC1与PTC2对接口电路形成了一个有效的保护, 提高了485通讯模块的电气可靠性。
2.2 测控模块硬件设计
测控模块硬件框图如图6所示, 以LPC1758为核心, 负责设备运行数据的采集、I/O地址译码与I/O的控制;设备的相关温度、电流、电压、湿度、压力等参数经过采集电路后, 再经LPC1758进行数字滤波后, 存储到FLASH中;控制器可通过RS485与LPC1758通讯, 读取所需参数用于逻辑运算, 运算后再将I/O控制命令下达到LPC1758执行。I/O电路包括晶体管输出、继电器输出与特殊应用输出, 如电子膨胀阀控制I/O、变频器控制I/O等。
其中滤波采样电路中采用的M a x i m的单通道2 4位A D C M A X 1 1 2 1 0。该A D C集成了模拟和参考输入缓冲放大器, 并提供四个GPIO口, 可用于控制一个外部16通道模拟开关, 令MAX11210有效地对16通道的模拟信号进行采集, 降低了LPC1758的I/O资源负担。采样电路框图如图7所示。
最后, 为了保证I/O电路的准确性与可靠性, 硬件电路中增加了I/O状态检测设计。对于输出点, I/O状态检测电路将输出状态生成对应的O u t p u t序列信号, 当控制器改变输出状态的命令发送到LPC1758并执行后, 输出点状态改变, LPC1758将改变后的Output序列信号与控制器下发的输出命令进行对比, 以确保输出的准确性;而对于输入点, 则生产对应的Input序列信号, 当输入状态改变后, LPC1758通过比较实际的输入状态与Input序列信号, 可判断输入端电路是否发生错误。
3 控制系统软件设计
为满足控制器多硬件接口、多软件程序应用开发、多文件操作、系统定制等要求, 采用Linux嵌入式操作系统, 主要应用程序有人机界面程序、数据处理程序、软PLC程序, 如图7所示。其中人机界面程序是由Windows环境下运行的图形化软件通过图元、控件以及宏命令组合生成[5], 可通过USB导入到控制器以实现人机界面的更新。数据处理程序主要负责设备工控记录、PID运算、设备状态监测等功能。软PLC程序则是由德国Infoteam Open PCS软件开发, 支持ST、IL、SFC、FBD、LD、CFC六种IEC语言, 负责I/O逻辑运算。
由于测控模块不需要过多的应用程序与图形界面, 因此选择了相对Linux嵌入式操作系统机构要小巧的多的u C/OS-II。该系统功能丰富, 涵盖了任务调度、任务管理、时间管理、内存管理和任务间的通信和同步等功能[6]。主要应用程序有数据采集程序, I/O检测程序, I/O控制程序。整个I/O的控制流程如图9所示。若出现I/O电路错误报警, 用户可选择将设备断电重启或请求技术支持。
4 结束语
本文设计的嵌入式环境试验设备控制系统, 其控制器与测控模块均具有成本低、集成度高、精度高、可拓展性强等优点, 可在一定程度上改善环境试验设备批量小、品种多等特点对设计与生产造成的不良影响。且通过充分利用我公司生产环境试验设备的优势, 可不断通过环境试验改善控制系统的可靠性设计。该控制系统现已应用在我公司的标准化系列环境设备上, 控制精度与稳定性均达到了国内先进水平, 且硬件配置丰富, 具有良好的拓展能力。
参考文献
[1]周修源, 江鲁.环境试验技术与设备发展概述[J].中国仪器仪表.2008 (06)
[2]刘文斌, 曹广忠, 李永光, 等.温湿度环境试验设备的现状及发展[J].现代制造工程, 2013, (11) :133-140
[3]景博, 杨洲, 张劼, 等.故障预测与健康管理系统验证与确认方法综述[J].计算机工程与应用, 2011, 47 (21) :23-27
[4]彭宇, 刘大同, 彭喜元, 等.故障预测与健康管理技术综述[J].电子测量与仪器学报, 2010, 24 (1) :1-9
[5]雷晓明.可靠性与环境试验设备控制器的设计与开发[J].电子产品可靠性与环境试验, 2013, 31 (5) :33-36
嵌入式环境 篇7
为此, 在教学设计时, 必须依据行业的技术状况及职业岗位要求, 按照职业资格标准, 按照人才订单要求设计教学环节, 根据学生的能力设计选择教学环节。建立嵌入式实验室和实训基地, 可以通过实验, 使学生对嵌入式系统的设计与开发过程有更深地体会。
1 嵌入式实验实训环境需求分析
高等职业教育主要培养高素质技术技能人才, 在人才的培养过程中, 能力的培养具有重要的地位。技术、技能培养需要环境, 需要系列实践教学环节来保障。在高职教育中, 实践教学环境的设计与实施、实验实训基地的设计与建设, 是高职教育教学改革的一项重要任务。
实训基地的主要功能是实现课堂无法完成的技能操作, 有目的、有计划、有组织地进行系统、规范, 模拟实际岗位群的基本技能操作训练。在建设工程中要坚持下面各主要原则:
1) 创造真实的实训环节, 提高学生实习效果。
2) 实训设备要体现专业高技术含量的特点, 与地区经济和科技发展水平相适应。
3) 注重实训基地的开放性, 扩大与地方其它单位的合作, 扩大基地使用范围。
4) 扩大实训基地的通用性, 保证教学和实践的切实需要。
2 嵌入式实验实训室规划与建设
高职院校嵌入式实验实训室规划与建设如表1所示。
3 实验实训室使用与管理
实验实训室是学生技能训练的场所, 进行现场教学和实验教学的课堂, 开展社会培训服务的基地, 是办好学校的基本条件之一[4]。所以实验实训室的使用与管理显得尤为重要。在实验实训室使用上应采取开放形式, 按学生对实验实训室的利用情况对开放实验实训室可以分为以下几种形式:
1) 全天开放实验实训室:是实验实训时间、内容、教学形式等对学生24小时开放, 学生可以自选实验实训设备和实验实训题目, 自己安排时间, 独立或在老师指导下完成实验。
2) 定时开放实验实训室:实验实训室每天在一定得时间内开放, 学生在实验实训课时不太明白或没做完的实验等都可以在开放实验实训室中继续做。
3) 综合开放实验实训室:在该实验实训室既可做虚拟实验实训, 又可完成实际操作性实验。
4) 第二课堂开放实验实训室:学生可在该实验实训室完成自己设计的小实验、小制作、小发明等。
实验实训室的管理上首先要制定规章制度, 完善实验实训考核办法。规章制度有《实验实训室安全管理规定》, 《实验实训室仪器设备管理及使用方法》, 《开放实验实训室的考核办法》, 《事故责任与损坏、丢失赔偿制度》, 《实验实训室学生负责制管理办法》等。开放实验实训室的管理可分以下几种方式。
1) 全部由实验实训员管理:实验实训所用的仪器, 实验实训室的安全、卫生等都有实验员负责。
2) 实验实训员和学生共同管理:可以分为两种情况。一种是以学生为主体, 实验实训员辅助管理。另一种是以实验实训员为主体, 学生辅助管理。
3) 完全由学生管理:做实验实训所需的仪器等都是学生负责管理。要求学生必须负责心非常强, 踏实认真, 一丝不苟。
参考文献
[1]姜大源.职业教育学研究新论[M].北京:教育科学出版社, 2007.
[2]向丽.工作过程理念下职教实践教学模式的解构与重构[J].职教论坛, 2008 (8) .
[3]于明.ARM9嵌入式系统设计与开发教程[M].北京:电子工业出版社, 2007.
嵌入式环境 篇8
目前的远程环境在线监测系统中的监测点单元主要有两种解决方案,一种是单片机数据采集器配合专用通讯适配器的解决方案,另一种是以工业控制计算机为核心进行数据采集和数据远程传输的方案[2]。嵌入式系统应用于环境在线监测系统的监测点,可以避免单片机系统在性能上的不足,也有望解决由于采用工控机系统带来的高昂价格和环境适应性差等方面的问题,是目前开发新型环境在线监测系统的有效途径。
本开发项目采用了uClinux作为基础应用平台,致力于开发高性价比、工作稳定、环境适应性强的新型嵌入式监测点系统和远程环境在线监测系统。本文对基于uClinux的嵌入式远程环境在线监测系统的开发进行了探讨,提出了基本的解决方案。
1 嵌入式远程环境在线监测系统的总体设计
远程环境在线监测系统分为监控中心系统、通讯子系统和无人职守监测点子系统等几个基本单元。
环境在线监测系统的基础数据平台为大范围、分散分布的无人职守监测点子系统。下位监测点系统不但要对各种监测仪送来的各种环境数据进行实时采集,根据要求完成比较复杂的计算、监测任务,担当智能监测站的角色,还需要能够与上位监控中心系统相连,实现远程监控。由于下位监测点系统处于无人值守状态,这种系统还必须具有一定的容错性、健壮性、抗干扰性及能够长时间连续运行,维护简单等特点。传统的监测点采用单片机数据采集器进行数据采集,配合专用通讯适配器完成数据上传的模式,这种监测点在多任务方面存在性能瓶颈,数据通讯方面的性能不足,工作很不稳定[3,4]。采用工业控制计算机(IPC)的监测点系统[2],系统完全基于win32系统,具有宽接入、工作稳定的特点,但由于监测点采用了通用IPC和板卡,系统的成本较高,环境适应性不足,开发周期较长。嵌入式系统在监测点上没有使用传统的工业控制计算机,而是采用了嵌入式单元,这使的整个环境监测系统的建设和运营维护成本较低,减少了现场调试和维护的时间。除此之外,本项目在嵌入式系统设计方面,还着重考虑了以下两个方面的问题:
1)考虑到环境在线监测仪器的高智能化,嵌入式的监测点系统在数据采集方面主要采用了串行RS-232C/485技术,取消了基于板卡的AD采集,不但克服了模拟信号采集方式局限性,提高了检测结果的精度,而且使系统结构简单、接口统一、安装维护容易,实现了全数字化,工作稳定性和性能价格比也得到提高。
2)嵌入式环境在线监测系统实现数据远传的方式多种多样,包括了LAN等宽带网络方式、有线拨号方式(PSTN)、无线通讯(GPRS)和数传电台等方式。监测点的各种通讯单元和嵌入式主板之间也基本采用了串行方式,系统扩展十分方便,通讯单元的这种开放性给用户带来了许多方便,用户可根据监测点现场的具体情况选择。
2 嵌入式软件平台的选择
uClinux是应用于微控制领域的一种嵌入式Linux操作系统,嵌入uClinux使得现场设备的功能大大扩展,系统伸缩性也较好。系统主要有以下特点:
(1)嵌入uClinux可运行于多种硬件平台,移植性较好,支持各种典型的处理器架构,包括ARM、PowerPC、X86、M68K、MIPS、Alpha等30多种处理器。嵌入式系统占用资源少,可裁减,有2种可选的运行方式,可在flash(闪存)上直接运行,也可加载运行。uClinux的文件系统要求的空间少,可满足仅具有少量内存的嵌入式设备的需要。嵌入式uClinux硬件及软件平台的这种灵活性使得监测点的配置变得非常灵活,可以满足不同档次监测点系统开发的需要。
(2)通讯网络支持完整,功能强大,支持TCP/IP等几乎所有常见协议,且易于自行开发协议栈。数据通讯是远程在线环境在线监测系统必须解决的核心技术,嵌入uClinux系统通讯功能强大而稳定,完全可以取代基于win32的系统。
(3)支持多进程,虽然uClinux不支持MMU,但它在标准Linux多进程实现原理上进行了优化,合理的回避了没有MMU所带来的种种问题。环境监测点系统具有多任务的特点,必须保证在无人职守的情况下稳定运行、不死锁和一定的实时性,采用uClinux能够达到上述要求。
(4)使用成本低,uClinux遵从GPL版权协议,源代码公开并且有大量优秀的开放源代码的应用软件和开发工具可用,如嵌入式Web Server、NFS、telnet、FTP、VPN、PPP、TFTP等。这一点对降低整个环境在线系统的建设成本十分有利。
(5)从开发的角度看,uClinux拥有精简的C库、数学函数库和标准丰富的API,支持POSIX接口,应用软件原型可以在标准平台上开发,然后移植到具体的硬件上。这些特点对环境在线系统的开发十分有利,减少了现场调试的成本和用户安装调试负担,加快了软件与硬件的开发过程。
3 嵌入式监测点主控制板的硬件结构
考虑在线环境监测的要求,监测点的嵌入式单元需要有I/O接口、RS232/485接口、以太网接口等,而由于长时间处于无人值守状态,键盘接口、显示接口等设备接口则为可选配置。
嵌入式主板选择了Motorola的Coldfire系列MCF 5307微处理器。MCF 5307是一款32位高性能、低价位、高集成度的微处理器,针对嵌入式控制应用而设计,处理能力达75MIPS,工作频率88.47MHz,总线频率44.236MHz,为运行uClinux提供硬件上的支持。板上还集成有2M字节FLASH ROM、16M字节DRAM、一个10M以太网接口、8个RS232C串口、4个RS485接口、I/O接口等单元。监测点嵌入式主板能够装载和运行嵌入式Linux操作系统、uClinux-Coldfire和应用软件。板上2M的FLASH ROM中,1M用来存放操作系统和应用程序的镜像,另外1M用来存放应用程序动态配置数据和临时存放监测结果。如果需要保存更多数据,还可以通过IDE接口外接一个DOC(Disk On Chip)电子盘。I/O接口用来监测各种状态量、驱动各种电机和报警信号等。RS232/485通讯接口用于下位数据采集和上位数据远传,如COD监测仪、TOC监测仪、流量计、CO2监测仪、嵌入式GPRS模块等。
4 嵌入式监测点的软件设计
为了适应在线环境监测系统的要求,实现各种仪器的宽接入和快速部署,我们采用了结构化、模块化的软件编写方法。整个系统软件被分为3个大的模块,采样管理模块、通讯管理模块、数据处理模块。具体结构如图1所示。
4.1 采样管理模块实现
采样管理模块主要功能包括I/O设备的驱动和操作、RS232/485通讯、各种监测仪器的采样操作等。Coldfire对I/O端口的操作是通过内存映射实现的,在uClinux-Coldefire中,可以通过宏inb(address)和outb(value,address)实现输入输出[1],使用POSIX标准实现RS232/485通讯。
采样管理模块的另一个功能是进行采样结果的分析处理,这些功能需要调用通讯管理和数据处理模块的相关功能实现。处理的内容包括采样数据有效性分析、上报采样结果、下传控制指令和本地存储采样结果等。
在采样管理模块的实现和程序开发中,必须解决的问题之一是如何方便地接入不同厂家的仪器,做到开发迅速和宽接入[3]。在环境监测点,各生产厂商的环境监测仪器虽然大多提供串行通讯口,但没有统一的通讯协议,这使得监测点的开发难度加大。解决这一问题的途径是建立环境在线监测仪器通讯用的基础构件库。这一思路的基础有两点,一是虽然不同厂家仪器串行操作指令串不同,但其命令串的结构是类似的,为有限的几种结构。二是用途相同的仪器,串行通讯指令串不同,但通讯取得数据后,其输出经过变换之后所得到的环境指标数据的结构是一样,也就是说应该按照在线监测系统的要求提取有用的、一致的数据。基于这些分析,首先按照用途对仪器进行分类,对同类仪器串行通讯命令串的结构进行抽象,建立基类,实现一个通用的应用编程接口,然后通过实例化,实现一台具体仪器的通讯编程。实践证明上述开发思路是有效的,可以较好地解决现场仪器的宽接入问题,在新设备接入时,只需按仪器的串行通讯命令串的具体内容,修改很少代码即可迅速完成通讯程序开发,大大加快了开发速度,实现了底层的宽接入。
4.2 通讯管理模块实现
通讯管理模块负责下位机系统的通讯连接建立、取消,下位机系统和监控中心的通讯管理等功能。包括了下位机系统与监控中心之间的一套用于现场处理的系统控制命令集及其实现。对于数据传输电台,其通讯模型决定了它仅相当于一个串口延长线设备。因此,需要在协议里面包含各个检测点的编码信息和数据校验信息。
uClinux环境提供对TCP/IP及其它Internet协议全面支持,而且易于自行开发协议栈。uClinux内核直接支持LAN网络,因此可以用于上级监控中心和下级监控分中心之间,监测点与企业局域网之间等的通讯开发。
对于无人职守监测点和各级监控制中心之间,目前主要基于PSTN有线通讯、GPRS无线通讯以及类似的拨号网络,如ISDN来实现,具体是通过PPP协议实现的。PPP是在串行连接上运行IP以及其他网络协议的一种机制,可以把uClinux连接到一台PPP服务器上并访问该服务器所连接的网络资源。在uClinux网络连接环境下,通过在make xconfig的network device support中选中SLIP support和PPP support,在用户程序里选中diald、chat、pppd,即可实现PPPD+DIALD方式的通讯。本文在监测点和监控中心之间采用了这一通讯方式。
4.3 JFFS、本地存储实现
uClinux系统采用ROMFS作为根文件系统,相对于一般的EXT2文件系统,具有节约空间的优势,但是ROMFS是一种只读的文件系统,不支持动态擦写保存。因此,在嵌入式监测点系统开发中,对于临时性的数据,采用了虚拟RAM盘的方法(使用EXT2文件系统),对于采样数据和系统参数等需要“永久”存储的数据,采用了Flash进行存储。
JFFS文件系统(Journaling Flash File System)可以将Flash作为系统的硬盘来使用,程序对它的操作与操作硬盘的文件和数据一样。要使用JFFS文件系统,需实现uClinux下对Flash芯片的驱动,这一步骤是通过对现有驱动的修改来实现的,包括配置JFFS文件系统的大小和配置erase等。
由于u Clinux 2.0内核不支持内核模块LKM(loadable kernel modules),设备驱动和文件系统需要静态编译进内核。其操作过程如下:
(1)在内核加入对JFFS和Flash设备的支持。具体是使用Make xconfig配置内核,设置在Additional Block/FLASH Devices中支持Flash块设备,在Filesystems中设置支持JFFS文件系统,在Filesystems Aplications中设置支持erase应用程序。
(2)针对具体设备修改Flash设备驱动程序,即修改linux/drivers/block/flash.c文件以适应具体设备,一般只需修改函数flash_probe()即可。
(3)编译内核及应用程序。配置完成之后,在/home/uClinux-coldfire/romfs/dev下增加一个设备文件,文件名称为@flash1,b,60,17,使用命令为touch@flash1,b,60,17。其中flash1是设备名,b代表块设备,60是主设备号(major),17是次设备号(minor)。
(4)重新编译内核并下载到目标系统中。目标系统重起后,就可以使用erase命令擦除所要mount的JFFS的扇区,使用flash1设备erase/dev/flash1,执行mount-t jffs/dev/flash1/mnt在flash1分区上建立了JFFS文件系统。如果想自动挂接JFFS文件系统,可以将mount命令放在vendorsGenericbigrc文件中。
5 结束语
本文提出了一个基于嵌入式uClinux的环境在线监测系统的设计方案,对嵌入式远程环境在线监测系统的系统设计、监测点系统平台的建立、监测点系统数据采集和处理等的关键技术问题提出了解决方案,设计并实现了一种宽接入、多适应性、配置灵活的环境监测点系统。研究表明嵌入式系统应用于环境在线监测系统的监测点,避免了单片机系统在性能上的不足,也解决了IPC工控机系统带来的高昂价格和环境适应性差的问题,是目前环境在线监测系统开发的有效途径。
参考文献
[1]Craig Hollabaugh.嵌入式Linux——硬件、软件与接口[M].北京:电子工业出版社,2003:120-125.
[2]肖薇,裴植.Linux实用组网技术[M].北京:清华大学出版社,2001:39-55.
嵌入式环境 篇9
系统设计由气体浓度信息采集模块、单片机核心系统、网络接口模块、电源模块、显示部分组成。环境信息采集模块采集回的数据经过单片机处理后分别送本地显示和上传到网络, 当采集回的信息满足报警条件时, 系统报警, 实现对室内多种有害气体浓度测试、远程数据传输、方便携带等功能及特点。
2硬件设计
硬件设计包括MSP430F149小系统、温湿度采集、以太网控制器CS8900A为核心的网络通信模块的设计、LCD显示、报警电路等。其中重点在于网络通信模块的设计, 用以实现与互联网通信的接口转换。
2.1网络通信模块
由以太网控制器CS8900A、网络变压器20F-01R和RJ45接口组成, 设计采用8位I/O口, 映射成16个连续的8位I/O空间。CS8900A内部集成了10BASE-T收发器, 可以使用一个隔离变压器与局域网相连。当CS8900A工作在3.3V时, 所选用的变压器对TX和RX的分压比必须为1:2.5和1:1, 否则收发数据会出现漏帧的问题, 隔离变压器外围的电阻用于阻抗匹配。
2.2信息采集
前端信息采集需完成气体浓度到电信号的转换、信号的滤波和放大处理, 使单片机在最合适的电压范围内进行采样以得到最高的精度。针对四类有害气体CO、室内VOC、烟雾、可燃气体分别采用了四款传感器:MS2200、MS1100、MS5100、MC101。
2.3单片机系统和电源设计
核心控制系统完成数据采样、处理、嵌入式WEB服务器、本地显示、键盘控制、声音灯光报警等功能。根据设计需要, 选用低功耗LCD液晶显示屏FM12232F, 显示气体名称、浓度、级别, 采用并行驱动的方式, 相关端口直接与单片机I/O相连接。键盘为了方便控制显示内容切换或锁定等, 使用4×4行列键盘。电源管理模块为整个系统提供所需电压额供电。该设备共需两种电压:3.3V和5V。
3系统功能测试
3.1基本功能测试
测试时设定服务器的IP地址为222.196.33.222。作为客户端的10台IP地址设定在222.196.33.0~222.196.33.255的PC机、嵌入式服务器, 经网络交换机组成一个局域网。在PC机上打开IE浏览器输入服务器的IP, 便可通过网络访问WEB网页界面, 实现远程监测的功能。对温、湿度的测试采用多用温、湿度计与传感器采集的温、湿度值做对比, 实验结果如表1所示。
系统实现了对环境信息 (温、湿度) 的采集、本地和远程实时显示功能、网络数据传输功能、环境温度超过60摄氏度时系统报警的功能。系统服务器可供10台远程PC机同时访问, 对两个点的温湿度同时监测。系统还具有对历时数据的掉电存储功能和对被监测点的环境信息的近1小时、1天、1月和1年平均数据进行统计求平均并在远程显示的功能。
3.2系统扩展功能
扩展功能测试中, IP地址配置和组网方式与基本功能测试一致, 当空气质量情况发生变化时, 网页上的空气质量信息数据也会更新显示, 从而实现了网页数据的动态显示;当任一种气体含量超标, 系统报警, 蜂鸣器发出警告声, 对应气体的指示灯亮起且网页上能够明显显示报警情况, 很好地完成了报警功能。
4结语
本设计方案容易移植, 通过对嵌入式设备的硬件接口改造, 同时成功地将精简TCP/IP协议嵌入MSP430单片机中, 嵌入式WEB服务器能够连接到Internet, 实现对空气质量信息的远距离监测。经测试, 系统具备气体浓度采集、分析、显示、超阈值报警、远程监测等功能。