终端嵌入（精选九篇）
终端嵌入 篇1
随着网络应用的迅速发展,作为网络系统重要接入手段的嵌入式终端也得到了广泛应用,很多新的功能被加载在嵌入式终端上,并且在其上保存很多重要的用户信息,这使得很多网络攻击都从嵌入式终端开始,由于嵌入式终端系统存在易受攻击、安全性差等问题,因此嵌入式终端的安全问题日益突出[1]。
可信计算组织TCG(Trusted Computing Group)认为如果从一个初始的“可信根”出发,在平台计算环境的每一次转换时,将这种信任状态通过传递的方式保持下去不被破坏,那么平台上的计算环境始终是可信的,在可信环境下的各种操作也不会破坏平台的可信,平台本身的完整性得到保证,嵌入式终端的安全自然也得到了保证,这就是信任链的传递机制。而针对当前信任链的研究,大多是在硬件平台启动后在软件层调用TPM的安全功能,来实现嵌入式终端信任链的传递、构建嵌入式终端的可信环境,这使得可信环境的建立并没有真正地实现从可信根出发,更不能保证该环境下的操作是值得信任的,因此并没有形成一条完整的信任链。
本文针对当前嵌入式终端安全问题难以解决,以及信任链的传递不完整,在传统嵌入式终端中引入TPM构建嵌入式可信终端,提出了嵌入式可信终端信任链模型,设计了嵌入式终端启动可信、操作系统加载可信、应用程序加载可信,实现了嵌入式可信终端信任链传递。
1 相关概念及可信基本假设.
信任链[2]是嵌入式终端系统可信的一个关键组成部分,要实现一个完整的信任链,必须满足两个条件:(1)有一个可信根,这个根是通过硬件封装和保护能力实现的;(2)系统从可信根开始引导,每一级系统运行控制组件只有在确认其下一级系统运行控制组件是可信的时候,才将系统运行控制权转移给它。本文将TPM作为嵌入式可信终端的可信根,来实现信任链的传递。
1.1 相关概念
本文提出的嵌入式可信终端是在传统嵌入式终端中引入TPM,调用TPM的身份认证、平台标识、数据安全保护等硬件级安全功能,构建嵌入式可信终端软硬件系统,控制嵌入式终端从启动到运行的全过程。主要包括可信的硬件层、可信操作系统层、可信应用层(如图1所示),这三个层次相互配合,从而使得嵌入式可信终端具备可靠的安全支持。其中该嵌入式可信终端的安全核心是TPM。
TPM(Trusted Platform Module)[3,4]:可信平台模块是嵌入式安全可信模块,并且本身也是小的计算机系统,由CPU、密码运算器、I/O、易失性存储器、非易失性存储器等组成,主要完成对嵌入式可信终端的完整性度量信息的存储和报告、密码学服务,以及身份认证等安全功能。其中密码运算器是TPM可信平台模块中重要的硬件部件,密码运算器主要功能模块有:随机数生成器、密钥生成器、SHA引擎、HMAC引擎、对称加密算法引擎和非对称加密算法引擎。随机数生成器负责产生各种运算所需的随机数。密钥生成器负责生成对称密钥和非对称密钥对,SHA引擎负责完成基本的HASH运算;HMAC引擎依赖于SHA引擎,用于确认报文数据的正确性,它可以发现数据或者命令流在传输过程中是否发生错误或者被篡改。对称加密算法引擎实现AES、DES运算,它们只供TPM内部使用,不对外提供服务。非对称加密算法引擎实现RSA运算,提供对内对外的数字签名功能,内部存储和传输数据的加解密功能。TPM所涉及的密码算法都采用国家标准密码算法。
可信根是TPM可信平台模块中重要的软件部件,包括三个可信根:可信度量根RTM(Root of Trust for Measurement)、可信报告根RTR(Root of Trust for Report)和可信存储根RTS(Root of Trust for Storage),这三个可信根分别用于用户引导和完整性度量、记录报告保护、存储保护。可信度量根的核心CRTM(core root of trust for measurement)是嵌入式可信终端启动后初始化TPM时的第一段执行代码,是初始化代码中不可更改的一部分,同时也是信任链传递的起点。
1.2 可信基本假设
任何信任的建立都不可能是无条件的,都要有其假设的信任起点,信任链模型建立基于以下四种假设:
1)认为所用的TPM制造方、评估方是可信的。具体到一个国家敏感部门,所用TPM必须是国内生产并评估的;而一个军队所用TPM产品必须是军队自己生产和评估的。
2)认为可信度量根CRTM模块是可信的,只有制造方才可以对其更新、修改和维护。
3)认为可信报告根能够唯一标识嵌入式可信终端身份。
4)认为是可信存储根是足够安全的,任何主体都无法通过非法手段获取和修改其内部存储信息。
可信度量根、可信报告根以及可信存储根都是TPM内部的管理部件,并且由TPM设计规范决定,只有这样TPM才能作为可信基本假设的信任链起点。
2 嵌入式可信终端信任链模型
根据可信计算的思想,结合上文提出的可信基本假设,本文提出的嵌入式可信终端信任链模型(如图2所示),从可信根出发,在信任链传递过程中,一级认证一级,一级加载一级,保证自底向上的启动可信和自顶向下的应用加载可信,形成了一条可信链闭环。
自底向上可信启动执行过程如图2右侧所示:
1)终端上电,进行TPM初始化,由TPM可信度量根对Bootloader进行完整性度量,并将所得完整性度量值和存储在TPM内部的完整性基准值进行比较,若相同则将控制权交给硬件平台CPU运行Bootloader,并将完整性度量值存入存储完整信度量值的平台配置寄存器PCR(Platform Configure Register)。
2) Bootloader进行嵌入式可信终端硬件初始化,加载操作系统内核,并调用TPM中的功能接口函数对操作系统内核的完整性进行度量,将完整性度量值和完整性基准值进行比较,若相同,存入PCR。
3)运行操作系统内核,操作系统内核进一步初始化硬件、加载文件系统,并调用TPM度量文件系统完整性;度量通过,内核运行初始化进程init,这时系统处于闲置(idle)状态,嵌入式终端平台进入可信运行环境并等待用户应用程序的执行。
应用程序加载可信是在保证自底向上的启动可信,嵌入式终端平台进入可信运行环境的前提下执行的,自顶向下的应用程序加载可信执行过程如图2左侧所示:
1)应用程序首先通过系统调用API从用户态进入内核态执行。
2)嵌入式可信终端平台通过调用TPM对应用程序的身份进行认证,若通过身份认证,则对其进行处理,并将处理结果返回用户空间。
根据上述信任链模型执行过程,下文以Linux嵌入式系统平台为原型,设计并实现了嵌入式可信终端的可信启动和应用程序的可信加载。
3 基于信任链模型的可信启动设计
3.1 Bootloader可信引导
1) Bootloader启动过程分析
传统嵌入式终端的Bootloader启动大多数都分为两个阶段[5]。第一阶段主要包含依赖于CPU的体系结构硬件初始化的代码,通常都用汇编语言来实现。这个阶段的任务是基本的硬件设备初始化(屏蔽所有的中断、关闭处理器内部指令数据cache等);为第二阶段准备RAM空间,如果是从某个固态存储媒质中,则复制Bootloader的第二阶段代码到RAM;设置堆栈;跳转到第二阶段的C程序入口点。第二阶段通常用C语言完成。这个阶段的任务有:初始化本阶段要使用到的硬件设备;检测系统内存映射;将内核映像和根文件系统映像从Flash读到RAM;为内核设置启动参数;调用内核。
2) Bootloader的可信引导
嵌入式可信终端Bootloader的可信引导过程如图3所示。
(1)硬件平台加电,TPM复位并执行CRTM,调用Tspi＿TPM＿SelfTestFull进行TPM自检,完成TPM初始化。
(2) TPM对用户进行身份认证(用户可以通过密码或开机身份卡)。如果通过开机身份认证,则进入可信引导过程。
(3) TPM调用Tspi＿HashGetUserData对Bootloader的自检程序进行HASH运算生成完整性度量值,并调用Tspi＿NV＿ReadValue取出存储在TPM非易失性存储器中的完整性基准值进行比较。如果完整性度量值和完整性基准值匹配成功,则向嵌入式可信终端硬件平台CPU发复位信号,硬件平台的CPU从00000000H开始执行,并执行该处指令进入硬件平台的自检。
(4)硬件平台自检成功后,Bootloader调用TPM的SHA-1引擎接口函数,由TPM对Bootloader第二阶段内核加载程序进行HASH运算得到完整性度量值。并将度量值和基准值比较,若相同,将内核加载程序读到内存,进入操作系统内核加载阶段。
通过上述引导过程保证了从系统加电开始到Bootloader运行完毕并将控制权交给操作系统内核之前整个嵌入式可信终端硬件平台加电引导过程的可信。
3.2 操作系统内核可信加载
1)操作系统内核的运行过程
Linux内核有两种映像:一种是非压缩内核,叫Image;另一种是它的压缩版本,叫zImage。由于嵌入式终端的存储空间容量一般比较小,一般采用zlmage。操作系统内核的运行过程如下[7]:
(1) Bootloader将内核映像从Flash中拷贝到RAM;
(2)调用decompress＿kemel ()解压内核;
(3)跳转到start＿kemel()函数开始内核的初始化工作;
(4)调用第一个用户进程-init进程并等待用户进程的执行。
2)操作系统可信内核加载
要实现操作系统可信内核加载,可以分为以下两个过程:
(1)首先在内核解压缩之前,调用TPM的SHA-1引擎接口函数对内核压缩包进行完整性度量求得HASH值,将所得完整性度量值和完整性基准值比较,若相同,将度量值存入PCR中,并将内核进行解压。
(2) Linux内核函数start＿kemel调用1号进程(init),首先通过init函数获得该进程的控制权,该函数最后启动init进程,为了度量,我们将原来的execve函数替换为measure＿execve。在函数measure＿e xecve增加一个度量过程,将所得完整性度量值保存到PCR中。
3.3 文件系统可信加载
文件系统是操作系统中负责存取和管理信息的模块,当操作系统达到稳定的状态时,内核和应用程序都不断地和文件系统产生联系[6]。因此文件系统的可信,对可信链的传递提供了非常重要的支持。Linux的文件系统从结构上看可以分为两个部分:虚拟文件系统VFS(Virtual File system Switch)和具体文件系统(包括Ext2,Ext3,VFat等)。虚拟文件系统VFS可以对用户程序隐去各种不同文件系统的细节,为用户程序提供一个统一的、抽象的、虚拟的文件系统通道。在Linux文件系统的关系是一种“总线调用”的关系,即虚拟文件系统根据跳转表把通用文件系统接口重定向到具体文件系统的实现。每种文件系统都有自己的file＿operations数据结构,结构中几乎都是函数指针,实际上就是函数跳转表,例如read就指向具体文件系统用来实现读入文件操作的入口函数。因此要实现的文件系统可信,就需要构造一个file＿trust＿operations结构,本文将原来Linux的file operations指针进行重新定义,将对可信函数的实现增加至file operation来构造file＿trust＿operations结构,实现函数体加入内核,从而实现文件系统可信,文件系统的可信为上层应用程序的可信提供了保证。图4为可信文件系统的层次结构。
4 基于信任链模型的应用程序可信加载设计
在Linux上,应用程序一般被认为是二进制文件[7]。二进制文件又包括库文件和可执行文件格式(ELF格式)。文件的执行被内核当作一个进程,通过系统调用sys＿execve()从用户态进入内核态,通过measure＿execve()把文件加载入内核,并判断出可执行文件的格式,作出不同的处理。
为了保证应用程序的完整性、可信性,我们将Linux的可执行文件.out进行重新定义,如图5所示:当第一次终端初始化时,选择对称加密算法将每一个加载时需要验证文件进行对称加密得到密文,并选择HASH算法对该文件进行哈希运算,得到一个固定长度的哈希值,用签名算法的私钥对哈希值签名,把得到的对称密钥、哈希值、签名值、密文进行数据压缩,形成.trust文件,并将.trust存储在嵌入式可信终端的存储介质中。
为了保证应用程序的可信加载,如图6所示。
1)通过系统调用sys＿ececve进入内核态,并对.trust进行解压,得到对称密钥、hash值、数字签名,密文。
2)用签名算法的公钥对数字签名解密,得到定长的哈希值,将所得HASH值和.trust中的哈希值进行比较,若相同则说明应用程序的身份可信。
3)用对称密钥将密文进行解密,得到明文,再次用HASH算法对明文进行HASH运算得到相同长度的哈希值,对这两个哈希值进行比较,如果相同,说明文件完整性没有被破坏;如果不同,说明文件被破坏或篡改,系统对用户进行提示。
被加载的可执行文件通过验证后,才真正被加载,这样就保证了被加载文件的真实性与完整性,实现了嵌入式可信终端自顶向下的应用程序加载可信,是信任链传递中重要的一步。
5 结束语
嵌入式可信终端的信任链传递是保证嵌入式可信终端安全的重要部分。本文依据可信计算的思想,以Linux嵌入式系统平台为例,提出了自底向上的启动过程可信和自顶向下的应用程序加载可信,形成了一条信任链闭环。本文提出的嵌入式可信终端信任链模型已在星载嵌入式可信终端中得到应用,应用结果表明可以较好地实现星载嵌入式可信终端的可信性、可靠性、安全性。
参考文献
[1]李光,余综.嵌入式设备在可信领域中的应用研究[J].计算机工程与应用,2006,41(增刊):140-144.
[2]王江少,余综.可信计算之信任链技术研究[J].计算机工程与设计,2008,29:2195-2198.
[3]Trusted Computing Group.TPM Main Specification:Design Principles (Versionl.2)[EB/OL].(2005-6-10)[2008-7-10].http://www. Trustedcomp- utinggroup.org.
[4]谭兴烈.可信计算平台中的关键部件TPM[J].信息安全与通信保密,2005(02):13-16.
[5]王新成,孙宏蔡,吉仁,等.基于TPM芯片的计算机安全启动系统设计[J].计算机工程与应用,2005(6):1-4.
[6]毛德操,胡希明.linux内核源代码分析[M].2000:415-658.
终端嵌入 篇2
关键词：嵌入式操作系统 Linux MiniGUI 信息终端
引言
近年来，随着软硬件资源的成熟与完善，嵌入式技术越来越和人们的生活紧密相关，功能单一的公用电话也开始向嵌入式多媒体信息终端转型。对嵌入式系统的研究，在全球激起了人们极大的兴趣。
选择开放源码的Linux操作系统开发新一代嵌入式产品已经成为其中新的技术热点。在本系统中，采用了MontaVista Linux系统。它提供了很多处理器、目标板和主机环境的组合，有一套完整的辅助开发工具，便于嵌入式系统专用人员设计、开发和发布应用程序。
与此同时，配备一个优秀的图形用户界面，使产品和用户能进行友善可靠的交互也已成为开发工作中非常紧迫的要求。本系统中使用的MiniGUI就是嵌入式Linux系统下一个轻量级的图形用户界面支持系统，目前已比较成熟，并已被用到很多项目的实际开发中。
1 嵌入式Linux系统
嵌入式系统是以应用为中心，以计算机技术为基础，并且软硬件可裁减。适用于用户系统对功能、可靠性、成本、体积、功耗有严格要求的专用计算机系统。从20世纪80年代末开始，陆续出现了一些嵌入式操作系统，如VxWorks、pSOS、WindowsCE、Linux等。其中免费源代码的Linux操作系统因其内核小、支持多种硬件平台、可裁减性好等显著优点，得到了广泛的关注，为嵌入式系统开发提供了一个极有力的选择。
(2)MontaVista Linux
目前，已有多家公司推出了嵌入式Linux发行版本。本系统中采用的是应用全球三大嵌入式Linux供应商之一MontaVista Software公司的最新版MontaVista Linux3.0。它使用的是最标准Linux内核2.4.2,是针对嵌入式设备度身定制的实时的、专业的嵌入式操作系统。考虑到嵌入式设备处理器、存储器资源有限的情况，在不减少新内核对嵌入设备有利特性的基础上，MontaVista公司对内核部分进行了高度裁减、配置，使MontaVista Linux 3.0。它使用的是标准Linux内核2.4.2，是针对嵌入式设备度身定制的实时的、专业的嵌入式操作系统。考虑到嵌入式设备处理器、存储器资源有限的情况，在不减少新内核对嵌入设备有利特性的基础上，MontaVista公司对内核部分进行了高度裁减、配置，使MontaVista Linux 3.0系统性能具备稳定、突出等特点，同时还为MontaVista Linux 3.0配备了一个由优先级驱动的实时调度器(RealTime Scheduler)，从而使客户对实时性的要求得到更大的满足。
2 软件开发平台
MontaVista Software公司在嵌入式Linux发行版中已提供了系统开发所需的环境：
a)内核和文件系统工具――目标配置工具(TCT)、库优化工具(LOT);
b)交叉开发工具――GNU GCC/C++编译器、GDB源码调试器、DDD图形界面调试器等;
c)实时性能工具和分析工具。
系统内核则通过Abatron公司的BDI调试器进行测试，内核运行于PowerPC体系的CPU上。该目标系统已实现以太网接口、串口、USB接口，LCD也能正常显示。
3 系统框架结构
应用程序是最上层的开发，其交互界面直接通过MiniGUI图形系统的API接口函数实现。MiniGUI屏蔽了对底层显示、输入设备编程的细节，使程序员更能专注于信息终端界面的特色上，从而缩短了编程投入时间。MiniGUI图形率编译安装后一般以库的形式存放在操作系统/usr/lib文件目录下。
该嵌入式系统的框架结构如图1所示。(本网网收集整理)
4 MiniGUI的移植
(1)MiniGUI特点
MiniGUI是由魏永明主挂的一个自由软件项目，现完全遵循GPL(General Public License)条款的纯自由软件，可以运行在任何一种具有POSIX线程支持的POSIX兼容系统上。MiniGUI在体系结构上有许多独特之处。它的主要特色有：
a)提供了完备的多窗口机制;
b)对话框和预定义的控件类;
c)消息传递机制;
d)多字符集和多字体支持;
e)全拼、五笔等汉字输入法支持;
f)BMP、GIF、JPEG等常见图像文件的支持;
g)小巧，包含全部功能的库文件大小为300KB左右;
h)可配置，可根据项目需求进行定制配置和编译;
i)可移植性好。
(2)MiniGUI的移植过程
要使MiniGUI运行在入式目标板PPC上，需在MontaVista Linux 3.0的`交叉开发环境下移植该图形包。
MiniGUI 1.2.6版发布时含资源文件压缩包minigui-res1.2.6.tar.gz、库文件压缩包libminigui-1.2.6.tar.gz和一个综合示范程序mde-1.2.6.tar.gz。
在开发主机上安装好MontaVista Linux 3.0后，把主机NFS服务的输出目录配置为硬盘路径/opt/hardhat/devkit/ppc/8xx/target。目标板运行起来后，会自动挂载到该目录下。
将该目标作为当前路径安装MiniGUI。
打开资源文件压缩包，执行如下命令
tar-xvf minigui-res-1.2.6.tar.gz
会自动在当前路径下生成minigui-res目录。在该目录下可以看到config.linux文件，修改其中TOPDIR=NONE一项，使TOPDIR=/opt/hardhat/devkit/ppc/8xx/target，此处的路径对应的就是前面设置的NFS输出目录。运行安装命令make install即可。
编译库文件压缩包libminigui-1.2.6.tar.gz时，解压步骤如上。不同的是须在当前目录下运行configure命令对库文件进行移植的配置。命令行如下：
CC=ppc_8xx-gcc./configure
--build=i386-linux
--target=ppc-unknown-linux
--prefix=/opt/hardhat/devkit/ppc/8xx/target
--libdir=/opt/hardhat/devkit/ppc/8xx/target/usr/lib
--includedir=/opt/hardhat/devkit/ppc/8xx/target/usr/include
--enable-debug
其中，ppc_8xx-gcc是针对PowerPC体系结构目标的编译器，是MontaVista Linux提供的;build是指执行编译的机器，这里是x86的开发主机;target是运行该编译器所产生目标文件的机器;prefix是所有安装路径的前缀;libdir是库文件安装路径;includedir是头文件安装路径;enable-debub指编译时需包含调试信息。
配置完，运行编译安装命令。
综合示范程序mde-1.2.6.tar.gz的安装方法和库文件类似的。
终端嵌入 篇3
【关键词】OTG；显示终端；USB驱动管理
引言
目前的交换机、路由器设备一般都是密封的盒式或机箱式设备，没有配备显示界面，若要查看交换机、路由器设备运行状态，一般需要外接PC设备进行监控，但是我们并不是随时都携带PC的。现在智能手机飞速发展，且手机已经是每个人必备设备，若能够将手机作为交换机、路由器设备的显示终端，将极大的方便对交换机、路由器设备的使用和故障排查。
现有技术
对于交换机、路由器设备的管理一般采用计算机系统。计算机和交换机、路由器设备之间的通信方式包括：
1.通过以太网口以Telnet方式连接；
2.通过以太网口以SNMP协议方式连接；
3.通过以太网口以HTTP方式连接；
4.通过以太网口以LDAP协议连接；
5.通过串口与设备以控制台方式连接。
这些的所有连接方式都离不开PC设备，都必须以PC设备作为交换机、路由器设备的管理和显示界面。在目前这个人人必备手机的社会，若能够将手机作为交换机、路由器设备的管理显示设备将极大的方便人类对交换机、路由器设备的使用。
本文研究
本文主要研究如何将手机作为交换机、路由器设备的管理显示工具，新增了另一种控制显示交换机、路由器设备的方法，即通过OTG线连接手机和交换机、路由器设备的USB连接口，在可以加载可执行软件的智能手机上运行一种专门的应用软件（USB控制台软件），可以在这个应用软件上显示交换机、路由器设备的终端信息，也可以将一些命令通过这个应用软件传输到交换机、路由器设备中。
如图所示是两种终端显示的具体实施的模块布局图。
终端数据处理模块：处理设备内部发送到终端的数据和从外部终端接收到的数据，对于将发送到终端的信息，在发送给串口的TTY1的同时，也另外复制一份发送给一个新的TTY2模块，也就是PC和手机能够接收到从交换机、路由器发送过来的相同内容的信息；终端数据处理模块接收从外部终端传输到设备内部的数据，包括通过串口传递进来的数据和从USB口传递进来的终端数据，对内的信息都统一接收处理。
TTY2模块：一般一个控制终端需要新增一个TTY，本模块是为了处理USB收发的终端信息的模块，对于对外传出的信息，将即将输出的字符转为终端可以理解的字串，对于对内输入的信息，将其转换为终端数据处理模块可以理解的字符信息。
USB驱动管理模块：属于USB驱动层的管理模块，这个层用于区分各个不同的USB设备（如U盘、鼠标、键盘等），如U盘、手机的文件传输主要是使用Mass storage协议来实现。
下面重点描述USB驱动管理模块。
Mass Storage模块：Mass Storage是USB海量存储驱动管理模块，这个模块对应就是文件传输信息，比如已有的技术，交换机、路由器设备和手机之间就是通过Mass storage来实现文件信息传输。
管理模块：Mass Storage只负责传输文件信息，现在增加了终端信息也需要通过这个机制来传递信息，这就需要增加一个管理模块来管理是终端信息还是文件信息。管理模块需要剥离终端信息和文件信息。
发送端：对于往外发送的消息在尾部增加一个字节类型标志字段。
接收端：对于接收到信息需要根据尾部一个字节的类型标志字段来区分是终端信息还是普通文件信息。對于接收是终端消息时，可以将接收到的消息缓存在一个终端消息缓存中，并通告终端应用来读取消息。
提供收发接口：封装一个消息发送接口，专供终端调用，而不需要通过文件系统才能发送信息，以便提高速率。
USB底层驱动模块：即设备端的USB控制器驱动层，通过手机来访问交换机、路由器设备，但是交换机、路由器设备也可以主动发送信息给手机，交换机、路由器和手机之间需要通过OTG连接线进行连接。
手机端的USB底层驱动模块：即USB控制器驱动层，手机端的USB模块必须支持既可以作为USB主机也可以作为USB从设备的功能，才能够主动访问交换机、路由器设备或者接收从交换机、路由器设备发送过来的信息。手机端的USB底层驱动模块主要负责将控制台软件将发送给交换机、路由器设备的信息转发出去，或者接收从交换机、路由器设备发送过来的终端信息。
手机端的USB控制台软件模块：手机端的控制台软件是手机端的应用软件，在智能手机上可以安装一些可执行软件，控制台软件和交换机、路由器端的USB终端信息处理软件进行信息交互，将用户输入的信息进行打包，并通过手机端的USB模块发送到交换机、路由器端，也可以接收USB模块上传上来的交换机、路由器端发送过来的终端信息，并显示在界面上。
获取USB终端消息模块：通过调用手机端USB的接收接口接收从交换机、路由器设备发送过来的USB终端消息。
USB消息解析模块：手机的USB通道的消息可以有很多种，终端消息只是其中一种消息，需要先判断消息是否是终端消息，若是的话则取出消息，并进行消息解析，去除报文头消息，取出数据区数据。
终端消息显示模块：将USB消息解析模块解析出来的消息显示在手机的终端消息显示模块界面上。
用户输入消息处理模块：用户通过终端界面输入消息，本模块对用户输入的消息进行缓存处理，直到用户输入确认键才作为一条即将发生的消息（注意终端界面只支持英文输入，不支持汉语输入）。
USB消息打包模块：用户输入的消息在发送之前要先进行打包处理，打包处理主要是为了在报文头加终端界面消息的标志，防止和其它USB消息混淆。
发送USB终端消息模块：通过调用手机端USB的发送接口往交换机、路由器设备发送USB终端消息。
结束语
本文研究实现手机作为交换机、路由器设备的界面控制台，极大的方便对交换机、路由器设备的使用，只要带着装有控制台软件的手机加一条OTG数据线就可以随时查看交换机、路由器设备的运行状态，也可以对交换机、路由器设备进行配置管理操作。
本文增加了一个设备输出输入信息的传输通道，用户在串口出现问题时，还可以通过USB口来控制操作交换机、路由器设备。
参考文献
[1]《一种计算机与移动手机控制管理的血糖仪》，专利申请号：201210001748.4
[2]《无线监控器》，专利申请号：200510063434
嵌入式车载无线视频监控终端设计 篇4
随着城轨列车运营条件的不断完善,已日趋成为各大城市居民出行首选的交通工具。而运载能力的提升给运营管理单位提出了更高的安全要求。人员拥挤导致的偷窃、暴力事件时刻威胁着居民的出行安全。许多运营单位急切需要对车内的情况进行实时监控,以保证在必要时果断采取措施。现有的本地存储、事后查看的方式已经不能满足实时性的管理需求。而在运行的列车上又无法采用有线的方式将视频画面传回。因此,嵌入式车载无线视频监控终端很好的解决了上述问题。当终端登录WIFI网络后,可以立即将监控画面实时的传回监控中心。
2 终端结构
整个车载终端主要分为6个部分,其结构如图1所示。首先终端连接好WIFI模块之后,通过Linux系统调用WIFI驱动程序,与监控中心建立连接。图像采集部分使用中星微公司生产的ZC301系列摄像头,将采集的图像数据通过USB总线传给车载终端,在终端后台运行的采集应用程序通过调用H.264编码库将采集的视频图像进行编码处理,以适合其在无线网络中传输,同时节省了带宽的使用。最后通过无线网络传回监控中心。
3 终端设计
3.1 Linux开发环境搭建
为了能够有效的节省开发资源,上位机开发环境选择使用在WMWARE 6.0虚拟机上进行。上位机开发选用Linux Ubuntu图形化操作系统。嵌入式硬件平台选用ok6410开发板作为视频采集终端模块,内核选用的是飞凌公司为ok6410开发板提供的linux 2.6.36内核,与Linux2.4以前的内核版本相比,集成了USB驱动和声卡驱动,因此只要在内核配置时使用能对应的驱动就可使硬件正常工作。内核及驱动的移植为终端开发节省了大量重复性的工作。
3.2 内核与驱动移植
首先配置内核使其支持摄像头驱动、USB驱动以及网卡驱动。进入内核顶层目录后,使用命令mv config_ok6410 .config命令,将文件名改为.config,然后使用make menuconfig命令进入内核配置菜单界面。
在【Device drives】下配置Multimedia support
在【Device drives】|【Multimedia support】下选择Video For Linux, Video capture adapters
在【Device drives】|【Multimedia support】|【Video capture adapters】下选择V4L USB device
在【Device drives】|【Multimedia support】|【Video capture adapters】|【V4L USB device】下选择GSPCA based webcams
在【Device drives】|【Multimedia support】|【Video capture adapters】|【V4L USB device】|【GSPCA based webcams】下可以将所有驱动选上,以便能够确保Linux内核支持zc301和ov519的摄像头:ov51x/OVFX2/W996xCF USB Camera Driver, ZC3XX USB Camera Driver。利用相同方法配置内核,使其支持WIFI驱动,保存退出并使用make uImage编译内核,将生成的内核镜像文件u-boot通过tftp服务器拷贝到开发板。
3.3 视频采集应用程序的设计
在视频采集应用程序同级目录中执行make命令编译,将生成的可执行程序拷贝到开发板上。视频采集应用程序工作流程如图 2所示。
部分实现代码:
int main(int argc, char *argv[])
{
int i;
int new_sock;
int sin_size;
struct sockaddr_in cli_addr;
if (-1 == cmdline_parse(argc, argv))
_exit(EXIT_FAILURE);
if (-1 == camera_init(g_video_dev_name,
g_cur_res_list[g_cur_res_no].w,
g_cur_res_list[g_cur_res_no].h,
g_pixfmt) )
_exit(EXIT_FAILURE);
adjust_devinfo();
signal(SIGINT, sig_handler)。
4 终端采集测试
将ok6410开发板连接好电源、WIFI模块。采用NFS方式起根文件系统。配置相应的网络参数,与PC机建立连接。将USB摄像头接口插入开发板,运行文件系统中的视频采集应用程序cam_server,输入命令./cam_server-d/dev/video2,如图3所示,可以看到终端中打印出摄像头初始化的一些信息。通过无线路由器与PC机互联后,在上位机监测软件中可以看到清晰的图像。如图 4所示。
5 结论
实验结果表明,终端运行正常稳定,能够满足城轨列车无线视频监控的需要,确保了调度人员能够实时掌握车内情况。为及时处置突发性事件提供了平台。终端具有良好的实时性、可靠性,应用前景广阔。
摘要：为满足城轨列车运营管理实时化的需求,设计了一种基于ARM11处理器的嵌入式车载无线视频监控终端。利用此终端,可以在linux环境下登录到附近的WIFI网络。或通过网桥连接将监控画面传回调度中心,确保了调度人员能够实时掌握车内情况。实验结果表明,终端运行正常稳定,有良好的实时性,可靠性。
关键词：ARM11,视频监控,Linux,H.264
参考文献
[1]S3C6410X RISC Microprocessor USER'S MANUAL[Z].Feb 13,2009.REV 1.20.
[2]Linux2.6内核配置参考[EB/OL].http://wenku.baidu.com/view/2448dfe9172ded630b1cb697.html.
[3](美)科波特,魏永明,耿岳,钟书毅译.LINUX设备驱动程序[M].北京:中国电力出版社,2006.
[4](美)博韦,西斯特著,陈莉君,张琼声,张宏伟译.深入理解LINUX内核[M].北京:中国电力出版社,2007.
[5]孙俊,李正明,殷春芳等.变电站中的嵌入式视频监控系统的设计[J].中国农村水利水电,2007(8):106-110.
[6]张辉,李新华,刘波等.基于V4L2的视频设备驱动开发与移植[J].电脑知识与技术,2010(5):3988-3990.
[7]卢上二,冯菊香,莫金旺等.基于无线Mesh网络的嵌入式视频监控系统设计[J].电视技术,2010(2):78-80.
终端嵌入 篇5
关键词：移动视频监控,嵌入式,系统测试,性能指标
1 引言
社会经济发展使得安防问题日益受重视。当公共场所发生突发事件、违法犯罪、恐怖活动或地震火灾等事故时，公安、消防指挥中心需要快速、及时地掌握现场情况。传统的视频监控系统采用布线方式成本高、周期长，采用无线网络快速搭建移动视频监控系统，可以满足处理突发事件的需求。
移动视频监控系统由三部分组成：其中前端部分安装于指挥车上，一般要求体积小、功耗低、集成度高、可靠性高等。故前端部分由嵌入式系统实现，满足被监控场所恶劣环境的要求。
系统测试对于保证嵌入式系统的产品质量具有重要意义，本文主要针对移动视频监控系统嵌入式终端进行功能和性能测试设计。
2 移动视频监控系统结构
如前所述，移动视频监控系统由三部分组成：前端、无线传输系统和后端，图1给出了移动视频监控系统的功能结构[1]。
其中，前端部分安装于移动指挥车上，主要负责接收被监控点的模拟音视频信号和烟感、红外等探测信号;对音视频信息进行相关预处理操作(包括音视频去噪处理、视频信息叠加、视频运动侦测和目标检测、目标跟踪、异常识别等图像智能分析)，若信号正常，则继续进行压缩、存储、上传操作，若信号异常，则进行报警处理;若接收到探测信号，则进行报警处理。根据系统设置，报警处理可以在图像上叠加报警图标给予指挥车内操作员直观提示，可以触发前端的报警输出装置(如警灯等)，可以将探测信号和音视频异常报警信号编码上传后端指挥中心。同时，前端可以接受并处理后端指挥中心(监控中心)的控制信息，包括请求视频码流上传、视频通道切换、各种参数设置、云台镜头控制等。
无线传输系统主要负责前端和后端间的信息传输，将车载音视频和报警信息传输到后端，使后端指挥人员及时掌握前端情况及处理报警;将后端的控制信息及时反馈给前端。CDMA 1X公共无线网络数据传输带宽理论值为153Kbps，实际测试带宽为20Kbps～80 Kbps，基本可以满足视频压缩后的带宽要求。
后端部分安装于指挥中心(监控中心)，主要负责接收无线传输系统传送的前端被监控点的音视频信息和报警信息，将音视频信息存储、解码显示并根据接收的信息手动或自动控制前端被监控点。后端部分需管理可以操作系统的用户，验证用户身份及赋予用户优先级;需管理前端各个设备及其音视频资源，当多个用户访问音视频资源时能正确分发;当多个用户同时控制前端设备时能根据用户优先级向前端正确发送控制信号;后端部分接收并储存各个分散的前端被监控点的视频信息，需保证足够的存储量。
3 嵌入式终端测试分析
前端部分由嵌入式终端设备、无线通讯模块、摄像机(带云台)、云台解码器、各种报警探测器等组成。嵌入式终端设备将摄像机输出的现场视频模拟信号数字化后，采用最新的H.264压缩标准进行编码，然后根据系统设置或命令响应进行存储、上传等操作。
无线网络带宽有限，可能不能满足实时高质量清晰度的图像要求，监控中心可以控制终端设备抓拍一帧或几帧高质量JPEG图片。
可以通过本地遥控器或监控中心指令配置嵌入式终端设备相关参数，以满足监控需求。嵌入式终端设备也可以响应本地遥控器或监控中心的相关操作命令。下面从功能和性能角度对终端设备进行测试分析。
3.1 功能测试分析
按照等价类划分的思想，将功能测试内容分为两部分：1)终端设备对控制、查询命令的接受及响应测试;2)终端设备对外部事件的响应测试。
3.1.1 终端设备对控制、查询命令的接受及响应测试
本项测试内容主要是测试终端设备接受本地遥控器、监控中心发出的控制、查询命令及对命令的响应情况，目的是看其能否正确地接受控制、查询命令及做出相应的处理动作。
遥控器命令包括：设置参数命令(包括系统设置、视频设置、录像设置、储存管理)、日志查询命令、配置加载命令、历史视频查询命令、历史视频回放命令、云台控制命令、报警设置命令等。
监控中心命令包括：码流配置命令、码流上传命令、JPEG抓图命令、云台控制命令等。
3.1.2 终端设备对外部事件的响应测试
本项测试内容主要是对音视频信息的处理情况及环境中某些指标(温度、烟雾等)超过阈值的响应。这里的音视频信息指语音对讲信号和摄像机处理被监控场景中交互对象(包括人和被监控物件)输出的视频信号。目的是看其是否能够按照参数设置正确处理音视频信息，是否能侦测出异常事件，是否能正确处理环境中温度、烟雾等指标的报警信号。
3.2 性能测试分析
嵌入式系统的的系统测试[2]是将开发的软件系统(包括嵌入式操作系统和嵌入式应用软件)、硬件系统和其他相关因素(如人员的操作、数据的获取等)综合起来，对整个产品进行的全面测试。因此，通过了功能测试仅仅是满足了用户对系统的最基本要求，移动视频监控系统嵌入式终端的运行环境一般比较恶劣，用于突发事件现场时对系统的稳定性、可靠性要求较高，一旦出现故障将会对指挥、抢险等工作造成严重的后果，故要对终端设备进行性能测试，尽可能地发现问题以优化系统，保证其质量。
3.2.1 终端性能指标
本文提出以下几个嵌入式终端的性能指标[3]：
1)嵌入式数据库存储数据量;
2)嵌入式数据库检索速度;
3)系统无故障连续运行时间;
4)无线网络视频连接、传输性能;
5)日志式嵌入式文件系统抗掉电性;
6)整机功耗;
7)系统抗震性;
8)系统抗电磁干扰性;
9)系统的环境温度适应性。
为了日后的查询、取证，嵌入式终端需要根据系统设置保存相关的历史视频文件，嵌入式数据库中记录了视频文件的相关属性，包括文件录制的起始和结束时间、触发方式、日期时间、码率等。数据库的存储量可以间接反映终端的存储能力，以验证终端是否适应长时间录像工作。同样，当指挥现场或者取证工作需要查询历史文件时，数据库能够及时响应用户的请求也是一个关键指标。
可靠性是嵌入式系统最重要的质量指标，如前所述，移动视频监控系统终端的运行环境恶劣、系统运行时要求连续稳定，因此要对其进行可靠性测试并据测试结果进行评估。系统主要是通过无线网络传输视频和控制信息，无线网络的传输性能很大程度上决定了系统性能的好坏，需要保证数据通过无线网络时的安全性、完整性和实时性。
当系统由于意外情况掉电重启时，需要保证各项配置参数及正在录像文件的正确性，因此需要测试文件系统的抗掉电性。系统的运行环境决定了要保证其他几项性能指标满足要求。
4 嵌入式终端测试设计
本节根据测试分析选取部分内容进行终端测试设计，主要包括历史视频文件回放、云台控制和可靠性设计。
4.1 历史视频回放设计
历史视频回放主要是用户根据需要选择查询条件后，终端设备查询数据库文件，查找所有符合条件的记录，当用户选择播放某条记录对应的录像文件时可以进行控制操作。用户进行控制时，系统在几个状态之间切换，采用状态转换测试技术[4]，验证其在给定的条件内是否能产生需要的状态变化。
首先分析系统构建状态图，如图2所示，其中的字母代表系统接收到的事件，P表示播放，F表示快进，R表示快退，PS表示暂停，S表示停止。之后根据状态图编写状态-事件表，如图3所示，最后得到状态转换树，如图4所示。状态转换树中的每一条路径就是一个测试用例。
4.2 云台控制设计
云台控制是系统的重要功能，指挥车内或监控中心工作人员需要观看其他方向场景，或是为了更清晰了解现场情况时，都需要发送云台控制命令，当终端设备接收命令解析后，就可以通过RS485串口向云台解码器发送控制指令以使摄像机或镜头正确动作。
本项测试采用模拟技术[5]，模拟器向嵌入式终端发送云台控制命令，并接收终端处理命令后向云台解码器发送的控制指令。模拟器解析接收到的控制指令验证是否同发送命令的预期响应一致。终端设备和模拟器间的通信协议为Pelco-P和Pelco-D，即云台解码器协议。
4.3 可靠性设计
可靠性测试是在真实或仿真的环境中，为对系统进行可靠性评估而做出的测试。可靠性测试中必须按照运行剖面和使用的概率分布随机地选择测试用例[6]。
移动视频监控系统中嵌入式终端要处理的主要业务有：上传码流、视频存储、历史视频查询回放、报警处理和云台控制处理等。相对应地，终端设备就要正确及时地响应各种控制命令或事件。
可靠性设计就是针对这些命令或事件构造操作剖面，采用多线程方式模拟各种事件或控制命令，以验证系统对连续的事件或命令的响应处理情况，从而根据测试结果可以评估系统的可靠性。模拟程序将每一类操作(事件或命令)用一个线程实现，根据各类操作的实际发生概率不同，对应线程产生时间序列的频率不同，当到达某一个时间点时即发送相应的命令或模拟产生各种事件，之后线程休眠直至下一个时间点。模拟程序将系统的各种操作结果写入日志以备分析评估。
5 结语
技术的进步使得移动视频监控系统将会应用于不同的领域，前端嵌入式设备的质量直接影响着整个监控系统。本文简要介绍了移动视频监控系统的功能结构，之后详细分析了功能和性能测试点，并对部分测试内容进行了测试设计，对视频监控系统的测试具有一定的参考意义。
参考文献
[1]移动视频监控系统需求说明书[Z].同济大学系统计算机科学与技术系测试与评估技术实验室,2008.
[2]李庆诚,张建华.嵌入式系统的系统测试和可靠性评估[J].单片机与嵌入式系统应用,2003(8):11-13.
[3]移动视频监控系统测试建议稿[Z].东华大学移动视频监控系统课题组,2008.
[4]Bart Broekman,Edwin Noteboom.Testing Embedded Software[M].北京:电子工业出版社,2004:112-119.
[5]沈君华.嵌入式系统模拟技术及其应用[D].上海:同济大学电信学院图书分馆,2008:41-48.
VOIP在嵌入式终端中的实现 篇6
VoIP(Voice Over Internet Protocols),即指在网络上使用协议以数据包的方式传输语音。使用VoIP协议,无论是因特网、企业内部互连网还是局域网都可以实现语音通信。在一个使用VoIP的网络中,语音信号经过数字化的压缩并转换成IP包,然后在网络中实时进行传输。VoIP可在网络上便宜地传送语音、传真、视频和数据等业务。
众所周知,VoIP可谓语音通信的未来。大多数电信厂商承认目前VoIP仅占国际语音通信流量的5%,电信运营商宣称IP电话在语音通信时间中所占比例正在快速增长,由其带来的大量新兴电话服务已经得到运用。而在未来4到5年内则毫无疑问地将占据大约50%的语音通信流量。
2 SIP协议
VoIP有两套控制信令体系:ITU-T的H.232系列和IETF的会话邀请协议SIP(Session Initiation Protocol)。H.323协议是一个相当复杂的协议,它不是特意为VoIP设计的,最初主要是提供以太LAN的视频会议支持。这一方面,SIP明显比H.323进步,它是特意为VoIP开发的。相对H.323而言,SIP的结构更加简单,内置的功能更少,呼叫建立时间更短。其简单性是通过模块化实现的,也就是说,它将一些复杂的特性留给了其它应用程序。虽然,中国电信继续选择H.323协议栈作为VoIP的基本通信协议,一个经过长期考验的、得到大量测试保证的协议是不能不令考虑稳定和互操作的网络建设者所在意的。但是,VoIP是否仍然采用H.323协议提供语音服务却遇到了争论,后起之秀SIP协议成为这场争论的焦点。基于此,本文选择一个基于SIP的VoIP在嵌入式终端的实现。
SIP是NGN的重要协议,近来在通信和网络研究领域受到极大关注,越来越得到业界的重视。SIP支持代理、重定向、登记定位用户等功能,支持用户移动RTP/RTCP、SDP、RTSP、DNS等协议配合,可支持和应用于语音、视频数据等多媒体业务。值得关注的是在NGN中,由于大量IP产品的应用,使得端到端必须基于纯IP网络。3GPP已经确定将SIP协议作为3G移动通信全IP网络的控制协议。
2.1 SIP协议在协议栈的位置
本系统采用了呼叫控制与媒体传输相分离的设计思路,呼叫控制采用SIP协议,SIP可以封装进TCP或是UDP来传输。而媒体流使用RTP/RTCP通过UDP来传送。其协议栈如图1所示。
一次简单的SIP/RTP会话可以分为三个步骤:首先通过SIP协议商定通话双方的通话参数,之后通过RTP/RTCP协议建立RTP连接传输语音包,最后通过SIP协议来解除连接,结束这次会话。
3 硬件结构
随着移动设备上网功能的普及,迫切要求在移动终端实现便宜而又方便的即时通信。而嵌入式终端实现的功能便是音频数据的采集与传输。本文采用Samsung公司的S3C2440微处理芯片,音频数据的采集与播放部分则采用UDA1341TS芯片,它们之间的连接是通过IIS总线实现。如图2所示。
各个引脚功能说明如下:
IISDI:UDA1341中采集来的数据。
IISDO:传到UDA131中播放的数据。
IISLRCK:用于指出现行数据采样值为左声道还是右声道数据。
IISCLK:向UDA1341提供用作采样逻辑的串行声音速率时钟。
CDCLK:音频设备主时钟,一般为采样频率的256倍或384倍,符号为256fs或是384fs,其中fs为采样频率。CDCLK通过处理器主时钟分频获得,可以通过在程序中设定分频寄存器获取。
L3DATA、L3MODE、L3CLOCK是UDA1341TS的L3控制总线,用于在播音过程中去重音、音量控制、低音增强、高音和软件静音等DSP特征。
4 软件设计
我们选择的操系统是Linux,对于UDA1341的驱动设计流程及关键函数如下。
(1)控制音频设备,设置好工作参数,如速度,声道,采样宽度等,同时设置对应的IIS总线和L3总线。sbc2440_audio_ioctl(struct inode*inode,struct file*file,uint cmd,ulong arg)
(2)根据采样参数计算出缓冲区的大小,分配对应的DMA空间audio_setup_buf(audio_stream_t*s)
(3)激活语音设备sbc2440_audio_open(struct inode*inode,struct file*file)
(4)把采样数据放到发送缓冲区,或是从接收缓冲区读取数据。
(5)关闭设备sbc2440_audio_release(struct inode*inode,struct file*file)
5 VOIP软件的移植
在已经配置好的硬件基础上,就需要定制平台和编写代码实现各个功能模块,最终实现整个系统。而整个系统的软件结构可分为如下几个功能模块:用户界面同、SIP消息处理、语音处理、实时语音传输。其中Linphone是一款基于SIP成熟的开源的网络VoIP软电话,可以运行于Linux下及Windows下,并与其它开源的功能模块很好地配合工作。现在要实现的便是Linphone软件与其依赖的功能模块移植到基于ARM的移动终端。下面给出几个重要功能包的详细移植过程。
首先下载的包有:linphone 2.0.1,alsa-lib-1.0.19,libogg-1.1.3,readline-5.2,
Libosip2-3.0.3,ncurses-5.6,speex-1.2beta3,libeXosip2-3.0.3-2
在Linux下的终端执行如下操作:
(1)交叉编译libosip2-3.0.3可以为多媒体应用程序(IP电话,等等)提供信令功能。它为SIP语法提供了一个完全可用的语法分析器,实现了草案中定义的"事务"层。它也提供了一个SDP分析器和为用户代理提供的额外功能。
(2)#export PKG_CONFIG_PATH=/root/armbuild/lib/pkgconfig#cd/libe Xosip2-3.0.3-2 e Xosip是Osip2的一个扩展协议集,它部分封装了Osip2协议栈,使得它更容易被使用。
(3)cd/libogg-1.1.3音频压缩包
(4)cd/speex-1.2beta3用于音频处理的包
(5)#rm-f$ARM_INSTALL_TREE/lib/*.la
把/root/armbuild/lib/下所有的*.so.*的文件放到开发板的/lib目录下。
(cp*.so.*/lib)
把/root/armbuild/bin/下所有的linphonc文件放到开发板的/home目录下。然后进入目标板,此目录下先增加权限chmod+x linphnec再在终端执行./linphonec进行相关配置
6 测试与结论
Linphone是基于SIP协议的VoIP软电话,故我们还需要一个SIP服务器来完成一个真实的仿真环境。这里我们选择asterisk,作为一个在Linux下运行的SIP服务器。对asterisk进行一个简单的配置,仅对asterisk的中文体sip.conf和extensions.conf两个文件进行配置即可,例如建立用户名为1001、1002的两个用户。其SIP的配置文件如下:
同理用户名为1002与1001类同,extensions.conf的配置文件如下:
这样服务的配置完成,接下来要完成的是对终端软电话的配置.在软件终端输入linphonec来启动移植到终端的Linphone.配置如下:
然后我们再下载一个运行在Windows下的Linphone软件安装以方便我们测试嵌入式终端Linphone的效果,进行相关配置,用户名为1001。首先看是否两个终端的软件提示注册成功,提示注册成功,在嵌入式终端则可以用call 1001来呼叫另一个终端。通过抓包可以分析整个SIP协议建立的流程如图3所示。
经测试,除了有些时延外,通话质量良好。
摘要：随着VOIP技术的成熟,通过互联网去实现一个即时通信已成为人们一种省钱方便的选择。本文研究了在嵌入式终端实现一个基于SIP协议软电话功能的方法。其中详细讨论了利用S3C2440与UDA1341TS在IIS总线下搭建一个硬件环境及相应的驱动方法,进而为实现声音通信服务。同时讨论了SIP软电话的详细移植过程。
关键词：嵌入式,会话邀请协议,UDA1341TS
参考文献
[1]方上玮.基于对等SIP协议的IP电话在手机上的研究与实现[D].成都:电子科技大学,2008
[2]李群懿,赵利.基于SIP的嵌入式无线可视电话终端设计与实现[J].电子技术应用,2008,(9):46-48.
[3]罗苑棠.嵌入式linux驱动程序和系统开发实例精讲[M].北京:电子工业出版社,2009,1
[4]苏伟良,周胜源,陈名松.基于SIP协议的VOIP系统的实现[J].大众科技,2008(1):36,40-41.
[5]ShepherdG,KruglinskiD.Programming withVisualC++[M].北京:机械出版社,2003.
终端嵌入 篇7
随着人民生活水平的提高和生活方式的转变,餐饮业的市场急剧扩大,利润飞速增长,被称为中国的黄金产业。而电子点菜系统的应用,提高了餐馆档次和营业效率、优化了业务流程,为餐饮行业带来崭新的管理理念与服务手段。目前较为流行的点菜终端主要分为2种模式。第一种采用单片机和无线模块实现,该模式成本低,但是功能和界面较为简单,通信距离也较短,使用者一般是服务员;另外一种采用商业PDA和无线网卡实现,功能强大,界面华丽,操作方面,但成本较高,不利于大范围推广与应用。此外,友好的自助点菜终端要给客户提供诸如每道菜肴的名称、插图、介绍和价格等各种相关信息,这些信息需要随着菜单的变化实时更新。由于嵌入式系统的存储空间有限,大量的图片等信息存储和实时更新成为现有点菜终端设计的一个难题[1]。
本文提出了一种新型电子点菜系统模式该系统由自助点菜终端和网站服务器组成,自助点菜终端为全触摸屏操作,无需点菜员参与,可完全由顾客自己完成点菜;且采用了开放源代码的自由软件开发方式,降低了系统成本。对于大量数据的存储与更新问题,本文提出构建一个服务器网站,由此解决大容量数据的存储与更新问题,提高餐饮服务批量生产与业务升级效率。顾客可通过自助点菜终端访问服务器网站自主完成菜谱查询、点菜、结账、多媒体娱乐等操作。点菜终端与服务器之间的通信基于WiFi无线网络。
1 系统概述
本文所介绍的点菜系统,分前台系统和后台系统2 部分,采用B/S架构,前台和后台之间采用WiFi无线通信,集无线网络通信技术与手持移动终端技术于一身。
前台手持自助点菜终端设备,无需点菜员参与,完全由顾客自己完成点菜。前台开发环境为嵌入式Linux,Qt/Embedded Linux。后台系统平台为PC,也可以称为整个系统的服务器,它的主要用户为餐馆的管理人员管理员可以通过后台服务器向系统添加餐馆的新菜、修改菜价、查询历史记录等。服务器负责协调各设备的工作,对各种数据做必要的处理,及时为工作人员、管理人员提供真实、可靠的数据。后台开发环境为Windows XP,MyEclipse,SQL Server。电子点菜系统的结构如图1所示。
2 自助点菜终端硬件设计
自助点菜终端的核心处理器采用ARM920T核的S3C2440芯片,其主频可达到400 MHz,外接64 MB SDRAM和64 MB FLASH。终端的硬件结构图如图2所示。其中,显示接口采用8寸TFT液晶屏,像素640×480,为用户提供友好的操作体验。用户通过触摸屏访问服务器网站自主完成菜谱查询、点菜、结账、多媒体娱乐等操作。该系统以无线宽带路由器作为无线AP(Access Point)接入点,点菜终端内置无线网卡,在内核支持、驱动程序的配合下,客户终端便能够接入无线网络,连接到远端服务器,访问网站[2]。
3 自助点菜终端软件设计
自助点菜终端的软件设计主要是开发基于嵌入式Linux系统的客户端应用程序,用以访问服务器网站。终端软件结构如图3所示。该系统开发主要有3个主要内容:开发平台的构建、编译Qt/Embedded库和终端应用程序的实现[3]。
3.1 嵌入式Linux系统开发平台的构建
搭建交叉编译环境是嵌入式开发的第一步,也是必备一步。由于一般嵌入式开发系统存储大小有限,通常需要在功能强大的PC机上建立一个用于目标机的交叉编译环境。该系统主机开发平台选择Fedora 12系统安装交叉编译器用来编译Linux内核,安装ARM 920t-eabi用来编译Qt/Embedded库,用来支持浏览程序的开发。终端以嵌入式Linux作为操作系统,管理系统软硬件资源。该终端采用Linux 2.6.29内核版本,首先移植了系统引导程序U-boot,然后编译裁剪的Linux内核,加载无线网卡等驱动,制作根文件系统[4,5,6]。
3.2 编译Qt/embedded库和Tslib触摸屏库
Qt/Embedded是一个多平台的C++图形用户界面应用程序框架,其对象容易扩展,可移植性好,支持多个GUI平台的交互开发。Qt/Embedded被广泛地应用于各种嵌入式产品和设备中。因此本文选择Qt/Embedded为本系统的GUI。
Qt/embedded Linux是为嵌入式Linux优化过的Qt版本。为了尽可能减少内存占用量,Qt/embedded Linux可以被重新编译以去掉那些不用的特性。
首先编译安装tslib,添加触摸屏支持:下载,tslib1.4.tar.gz,解压后执行配置、编译和安装命令。
然后通过./configure开始配置Qt embedded库,将不需要的应用去除以减小库的大小。配置完毕后,用make命令编译,用make install命令安装Qt/embedded Linux到指定的目录。
3.3 设计点菜终端应用程序
对于自助点菜终端应用程序的设计使用Qt Creator规划点菜终端程序的大致界面,然后遵循Qt/Embedded编程一般规则编写代码,主要分为浏览器核心类和主窗口类的实现,最后编译并通过NFS进行板上测试。
浏览器核心类使用Qt提供的QWebView类。该类提供了常用的功能,如加载特定的URL、设置、历史记录和网页对象。它还提供包括后退、向前和重新加载在内的基本浏览功能[3,7]。
例如,以下代码实例化用于显示网页并与其互动的QWebView类,指示QWebView加载URL并显示,这样就得到可与网站互动的基本窗口。
4 服务器网站开发
该系统利用普通的PC机和Windows XP作为网站服务器,数据库使用SQL Server 2005,Web服务器使用Tomcat 6.0。在MyEclipse环境下开发完成了JSP网站,网站实现了如图4所示功能[8,9,10]。
5 结语
本文设计的自助点菜终端,具有价格低廉,操作简单,界面友好等特点,采用开放源代码软件设计,使系统的成本降低,更具有市场竞争力;点菜终端通过WLAN以模式与服务器交互降低了客户端的设计难度解决了大容量数据的存储与更新问题。经实验测试验证,该系统所有功能模块都能正常运行,达到了预期效果,能够满足一般餐饮企业的实际要求。自助点菜系统使餐饮企业改善了餐馆的经营策略、管理效率和服务质量。随着信息化的发展,将得到更为广泛的应用,有着广阔的前景。
参考文献
[1]颜泽球,廖晓东,涂钦.触摸屏自助点菜终端的设计与实现[J].现代电子技术,2010,33(5):125-126.
[2]蔡子裕.基于ARM嵌入式无线点菜系统终端的研究与设计[D].长沙:中南大学,2008.
[3]吴鑫毅.基于Qt和ARM的无线点菜系统软件设计[D].厦门:厦门大学,2009.
[4]孙纪坤,张小全.嵌入式Linux系统开发技术详解[M].北京:人民邮电出版社,2006.
[5]孙琼.嵌入式Linux应用程序开发详解[M].北京:人民邮电出版社,2006.
[6]韦东山.嵌入式Linux应用开发完全手册[M].北京:人民邮电出版社,2008.
[7]倪继利.Qt及Linux操作系统窗口设计[M].北京:电子工业出版社,2006.
[8]范立峰,乔世权,程文彬.JSP程序设计[M].北京:人民邮电出版社,2009.
[9]邱加永,卞志城,郑经煜.JSP基础与案例开发详解[M].北京:清华大学出版社,2009.
终端嵌入 篇8
关键词：Linux,抄表终端,代码审查,单元测试
1、引言
随着嵌入式硬件的飞速发展, 嵌入式系统软件的规模日益增大, 其结构也越来越复杂。嵌入式系统越来越多的被应用在工业控制、信息家电、移动通信、国防等对质量要求非常严格的领域[1], 用于一些关键性的控制管理。因此, 嵌入式系统中出现的问题往往会导致无可挽回、致命的错误, 这使得对嵌入式系统软件代码的安全性, 可靠性和稳定性的要求极高, 在软件开发阶段, 对软件代码进行审查, 在早期发现并解决问题显得尤为重要。
嵌入式Linux系统的内核是用C语言编写, 在Linux编程环境下, 终端软件应用程序的开发使用的也是C/C++语言。现代的C/C++编译器都能在一定程度上发现代码存在的问题和缺陷[2], 并对代码进行一定的优化。但是, 大部分的编译器只能发现代码的一些基本语法问题, 平衡代码的执行速度和大小[3,4]。如果想要提高代码的安全性, 可靠性和稳定性, 并得到执行快速而又小的代码, 仅仅依靠编译器是不可能的[5]。目前, 常用的代码审查方法和问题总结有很多, 但是针对嵌入式代码的却很少, 也几乎没有人做过系统全面的研究。
长沙威胜信息技术有限公司研发的系列智能抄表终端产品, 均采用Linux+ARM架构, 并使用C/C++语言进行应用程序开发。软件部分包括抄表模块, 规约解析模块, 数据管理模块, 菜单显示模块, 设备监控模块等多个模块, 系统结构复杂, 程序代码量大, 如果在软件开发阶段, 没有对代码质量严格把关, 进行层层测试, 产品进入现场后, 将会暴露大量问题。实践也已经证明, 从现场反馈回来的许多问题, 都是由于在软件开发阶段, 对代码缺乏严格高效的审查所造成的。如果在软件开发的早期, 能够对代码进行的严格的审查和优化, 这些问题都可以得到避免。为此, 在产品的前期研发阶段和后期的维护阶段, 开发人员编写或修改的每一条代码都必须经过代码测试人员的严格测试, 包括动态测试和静态测试。本文根据大量工作实践经验, 总结了基于嵌入式Linux的终端软件代码的审查技巧和方法。
2、嵌入式Linux终端软件代码的常见问题
2.1 运算符优先级问题
运算优先级问题是代码中常见的问题, 它不涉及到语法, 编译器无法识别程序员的真正意图, 在软件后期维护中容易造成理解错误, 例如:
2.2 内存泄露问题
代码审查过程中, 发现仍然存在很多资源回收处理的问题, 主要体现在以下几个方面:
2.2.1 函数返回时的return问题
函数return时, 需要进行资源回收处理, 这里的return既包括错误处理分支return false, 也包括函数执行完后的正常退出, 资源释放包括关闭文件指针, 释放内存空间, 关闭数据库等等。在终端软件程序中存在这样的问题较多, 示例参考2.2.2中的代码:
2.2.2 strdup使用问题
在使用strdup后, 没有调用free () 函数释放资源。strdup函数本身具有特殊性, 在调用函数的时候, 隐式的调用了malloc函数进行内存申请。所以, strdup函数的使用也应该和free函数配对使用。这样的函数实际中还会大量存在, 我们在调用时, 应该先明确函数功能描述, 例如:
2.2.3 sqlite_exec () 函数使用问题
使用sqlite_exec () 函数后, 没有判断返回值, 对errmsg指针进行释放;使用sqlite_get_table () 后, 异常退出时, 没有释放获取的table信息, 由于在进行函数调用的时候, 隐式的获取了资源, 所以, 在异常退出时, 容易忽略对资源的回收处理, 例如:
2.2.4 new内存后, 异常返回时, 没有delete内存
在使用new申请动态内存后, 如果遇到异常情况返回时, 没有使用delete释放内存, 之前该内存依然被占用, 这个问题在程序运行的短时间内可能不会体现, 但是如果该操作时在循环内执行, 在长时间运行后, 系统内存将被大量占用, 可能导致系统运行缓慢甚至崩溃, 例如:
2.3 数组访问越界
数组访问越界问题是一个非常严重的问题, 在程序运行时, 它的表现是不定的, 有可能程序会正常运行, 有时候可能会导致系统突然崩溃, 如果在程序开发阶段没有发现这个问题, 一旦产品流入市场, 它就会像一颗定时炸弹, 随时可能造成无法估量的后果。数组越界主要表现在以下几个方面:指针变量地址访问越界、循环变量失控, 导致越界、循环变量与数组元素数量没有关联, 导致明显访问越界、代码编写时, 拷贝引起的笔误导致数组访问越界等, 例如:
2.4 编程规范性问题
在进行软件开发前, 首先需要制定企业的编程规范, 然后根据编程规范, 列出需要重点改进的编程规范性问题列表, 程序员根据编程规范进行编码, 代码测试人员在进行单元测试时, 也要根据编程规范进行审查, 这样可以大大提高代码的可读性和可移植性, 并且降低风险和减少后期维护成本。
3、嵌入式Linux终端软件中的线程安全性问题
线程中隐藏的一个问题就是他们可能会调用非线程安全的库函数, 这样可能会产生错误的结果, 如果多个线程能够同时执行函数的多个活动请求而不会相互干扰, 那么这个函数就是线程安全的 (thread-safe) 。POSIX规定了非线程安全的函数如下, 这些函数一定要有一个以后缀_r表示对应的线程安全版本函数。 (如图1)
既然上述函数不是线程安全函数的, 那么我们就必须对代码中这样的函数调用进行专项审查, 通过搜索, 函数查找等方法进行逐项排查, 确保多线程执行的程序代码中不存在非线程安全的函数调用。实际上这样的问题, 在实际应用多次出现, 并且问题的定位和解决困扰了开发人员很长时间, 在嵌入式Linux终端软件代码审查时, 我们需要汲取这样的经验教训。
4、代码审查工具的使用
4.1 使用改进后的Pc-Lint审查工具对整个软件工程进行全面审查
PC-Lint是一种C/C++软件代码静态分析工具, 借助PC-Lint可以对整个软件工程的代码进行批量检测, 根据输出的检查结果, 分析代码中潜在的问题隐患。目前, 在我们的代码审查工作中, 已经大面积的在使用Pc-Lint, 通过实际的工作, Pc-Lint还是存在一些不足, 比如在检查之前要进行大批量的命令行输入, 最后的审查结果以文本格式输出, 没有进行分类汇总, 针对这些问题, 我们使用VBA编程技术, 将Excel和Pc-Lint结合起来使用, 收到了很好的效果。
我们将PC-Lint内嵌至Excel中, 并设计了一个简单的操作界面, 将参数设置, 选项设置, 待检查文件写入全部集中于一个操作界面中。在启动宏时, 同时启动PC-Lint, 可以避免大量的手动输入, 并使检查结果自动分类, 如图2所示:
在检查完成后, 检查结果以电子表格的形式输出, 并且已经进行了分类汇总, 在输出的检查结果中, 各类代码问题按照不同模块, 不同文件排列出来, 还给出了出现问题的行号, 问题类型, 以及详细的错误信息, 这样一来, 程序员可以快速定位到发生错误的地方, 及时加以纠正, 而且便于分类汇总, 统计分析。
4.2 使用beyond compare工具对代码修改进行有针对性的审查
终端软件在日常开发并修改后, 通过CVS代码管理系统提交到服务器, 修改内容可以通过CVSTRAC网页工具进行查看, 相关修改信息一目了然, 这对于每日代码修改的审查提供了很大的方便, 然而, 借助专业代码比较工具beyond compare, 可以对不同版本代码进行深入细致比对, 并对修改部分进行重点审查, 确保修改能够真正满足要求, 如图3所示:
在beyond compare工具的比对窗口中, 红色部分表示此次修改的内容, 测试人员由此可以迅速的定位到代码的修改部分进行重点审查, 大大的提高了效率, 降低了工作量。
5、结语
本文结合多年来对嵌入式Linux软件代码的审查经验, 总结了在代码审查过程中发现的一些常见问题, 并针对终端软件代码多线程编程的特点, 根据实践经验, 对线程安全性问题进行了分析, 最后介绍了根据实际需要进行了改进的Pc-Lint检查工具和beyond compare工具的使用, 因此, 本文对基于嵌入式Linux的抄表终端软件的代码审查具有一定的借鉴和指导意义。
参考文献
[1]周小丽, 李俊峰.嵌入式系统编程中的代码优化[J].上海:电脑开发与应用, 2004, 17 (1) .
[2]彭裕辉, 王双喜.基于代码审查的综合软件质量评估方法[J].武汉:软件导刊, 2010, 099 (3) .
[3]ISO/IEC9126?-1.Information Technology-Software Product Quality-Part1:Quality Mode1, 1998
[4]Wagner D, Foster J, Brewer E et al A Fi6t Step110wards Automated Detection of Buffer Overrun Vulnerabilitics In Pro-ceedings ol the Year2000Network and Distributed System Secu-rity Symposium (NDSSI, San Diego, CA, 2000:3, 17
[5]Bishop M, Dlger M Checking tbr Race Conditions in File Access Computing Systems, 1996.
终端嵌入 篇9
●硬件平台:指车载终端中,用于承载功能软件的硬件设备,包括外壳、各种电路、线束等。
●驱动程序:可以使设备的软件与硬件之间进行通信的特殊程序,相当于硬件的接口,应用软件只有通过这个接口,才能控制硬件设备的工作。
●接口程序:指应用程序编程接口,是一组预先定义的函数,目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力,而又无需访问源码,或理解内部工作机制的细节。
●APP程序:指第三方的应用程序。此处指陕汽业务逻辑,运行在驱动接口层之上的应用程序。
●时钟:在计数系统中,所有的波形都与一个基本时序波型同步,称之为时钟(clock)。时钟是周期波,每两个脉冲之间的间隔等于一个位时间。
●内存:内存(Memory)也被称为内存储器,是嵌入式系统中重要的部件之一,它是与CPU进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的,其作用是用于暂时存放CPU中的运算数据,以及与硬盘等外部存储器交换的数据。
●CAN总线:CAN是控制器局域网络(Controller Area Network,CAN)的简称,是德国BOSCH公司开发的,并最终成为国际标准(ISO 11898),是国际上应用最广泛的现场总线之一。
●天行健车载终端:天行健车载终端是陕重汽为重卡用户打造的基于车联网技术的一种智能服务系统中的采集终端。该终端为整个智能服务系统提供GPS卫星定位、GPRS数字移动通信、采集车辆发动机ECU、车身中央控制器CAN总线等信息,并通过天行健车载终端向管理平台上传上述信息、同时天行健车载终端接收管理平台下发指令帮助用户实现对车辆的远程监控和管理。天行健车载终端在以下文中简称车载智能终端。
前言
陕西中交天健车联网信息技术有限公司是陕西汽车集团有限责任公司的下属控股子公司。陕西汽车集团有限责任公司建于1968年,前身为陕西汽车制造厂,是我国主要生产重型汽车的大型骨干企业。产品主要覆盖重型军用越野车、重型卡车、中型卡车、大客车及底盘、重型车桥、大型马力发动机等。其中重型卡车市场占有率40%以上。陕西中交天健车联网信息技术有限公司是陕西汽车集团为了由制造型企业向服务型企业转型及卡车智能化、物联化,进而大力发展重型卡车产业,于2013年6月成立的。
陕西中交天健车联网信息技术有限公司是中国第一家专业于卡车车联网技术研究、应用、终端产品生产及销售的高科技车联网平台运营商和综合服务提供商。公司自主研发的天行健车联网服务系统及智能终端拥有数十项专利及软件著作权,全面满足交通部、公安部国标/部标等相关要求及JT/T794-2011、JT/T7808-2011、GB/T19056-2012标准,成功被工信部授予“国内独家车联网技术应用实训示范基地”。
基于中国4000万卡车运输市场,依托陕汽集团47年专业卡车制造及运营数据研究平台,中交天健公司前瞻性的开发出“天行健”车联网系统及智能终端,成为国内首例卡车物流运输行业高成长性新兴产业企业。2013年,公司实现配套及销售1万套,产品在国内市场上覆盖31个省、直辖市及自治区,是中国2013年车联网及终端市场占有率第一品牌,并于2013年8月特邀成为汽车工程学会发起成立的“车联网产业技术创新联盟首届理事单位”。2014年,公司销量突破5万套,继续稳居重卡车联网行业领导者地位;天行健渣土车管理平台推动全国渣土车管理变革,成为行业渣土车的参考标准;同年9月,中交天健公司成为行业首家通过“双软企业认证”的企业。
中交天健公司致力于卡车的全生命周期及用户使用全过程的系统解决方案的平台搭建及信息管理。通过打造开放的信息平台和信息管理,公司为用户提供引领高效节能运输的物流解决方案,依托陕汽集团2017年产销20万辆的制造主体,愿景目标是成为中国车联网技术及应用的引领者和规则制定者。
由于陕西汽车集团有限责任公司在车载智能终端业务方面的需要,基于以下需求:
◆基于更为方便广泛的选用备用供应商需要;
◆基于树立行业标准的需要;
◆基于服务依赖标准来获得更好的可操作性需要;
◆基于降低软件开发复杂性,以便于开发及分工的需要;
◆基于不要求所有的数据和逻辑都驻留在单一的MCU上需要;
◆基于服务的体系结构允许使用非常灵活的部署策略需要;
◆基于专有应用程序逻辑离散单元的保密需要;
◆基于专有应用程序逻辑离散单元的快速优化及更改需要;
◆基于便于后续软件维护的需要;
陕西汽车集团有限责任公司决定在业界首次引进嵌入式分层技术,由中交天健定义软件分层接口标准,生产厂商按照该标准开发陕汽定制车载智能产品。本文档不对具体系统设计及调度要求,系统设计要求请参见《天行健车载终端技术要求》,主要描述了分层结构APP应用层级与中间件级之间的标准接口,以指导终端软件按照嵌入式分层技术为主体进行开发,终端软件中间件级、平台级及整体软件系统设计由供应商提供符合应用层级要求的终端软件设计方案。
1、软件分层结构概述
1.1 软件的分层
软件分层是目前典型的应用软件的三层结构。
表述层:提供与用户交互的界面。GUI (图形用户界面)和web页面是表述层的两个典型的例子。
业务逻辑层:实现各种业务逻辑。
数据库层:负责存放和管理应用的持久性业务数据。
1.2 区分物理层和逻辑层
软件的分层包含两种含义:一种是物理分层,即每一层都运行在单独的机器上,这意味着创建分布式的软件系统;一种是逻辑分层,指的是在单个软件模块中完成特定的功能。业务逻辑层和数据库层运行在同一台机器上,这台机器即是应用服务器,又是数据库服务器,因此整个系统物理上分为两层,而逻辑上分为三层结构。
1.3 软件层的特征
软件层必须符合以下特征:
1、每个层由一组相关的类或组件(如EJB)构成,共同完成特定的功能。
2、层与层之间存在自上而下的依赖关系,即上层组件会访问下层组建的API,而下层组件不应该依赖上层组件。例如:表述层依赖于业务逻辑层,而业务逻辑层依赖于数据库层。
3、每个层对上层公开API,但具体的实现细节对外透明。当某一层的实现发生变化,只要它的API不变,不会影响其它层的实现。
1.4 软件分层的优缺点
●软件分层的优点
恰当的为软件分层,将会提高软件的以下性能。
1.伸缩性(指应用程序是否支持更多的用户)
2. 可维护性(指的是当发生需求变化,只需修改软件的某一部分,不会影响其它部分的代码。层数越多,可维护性也会不断提高
3.可扩展性(指的是在现有系统中增加新功能的难易程度)层数越少,增加新功能就越容易破坏现有的程序结构。层数越多,就可以在每个层中提供扩展点,不会打破应用的整体框架。
4.可重用性(指的是程序代码没有冗余,同一个程序能满足各种需求)
5.可管理性(管理系统的难易程度)
●软件分层的缺点
软件分层越多,对软件设计人员的要求就越高。在设计阶段,必须花时间构思合理的体系结构。此外软件层越多,调试会月困难。如果应用规模较小,业务逻辑很简单,软件层数少反而会简化开发流程并提高开发效率。
2、天行健终端嵌入式软件开发分层结构
2.1 软件总体架构
车载智能终端的软件总体架构设计采用分级分工程设计模式即为分层式软件架构模式开发。如图1所示,总体架构上可分为3级:平台级(PLAT)、中间件级(PORT)和应用级(APP),采用分层式软件架构模式实现各级之间的软件分离设计,从而使应用软件具备跨平台移植运行特性。
2.2 APP应用级
APP应用级即为业务逻辑层,通过规范性接口与中间件级及平台级进行交互,依赖中间件级及平台级完成数据采集、网络通信、位置信息服务、控制输出等功能。APP应用级将JT/808标准、19056-2012标准业务逻辑,陕汽专有业务逻辑封装成标准性层级。该层运行在中间件级之上。APP应用级内部功能结构如下图所示:
APP应用级包括的功能主要有以下5个方面:
1.满足国标GB19056-2012行车记录仪的标准功能;
2.满足交通部北斗部标(2013修订)的标准功能;
3.满足陕汽天行健系统对应多种发动机、车型等的采集及控制的功能;
4.满足各地不同的专用车业务的功能;
5.满足与中交天健合作的其他合作方要求的功能等。
2.3中间件级
中间件是根据不同的模块平台对平台的硬件驱动进行封装转换的抽象层,用于引导运行应用软件,因而称为中间件。中间件的设计用以保证平台级与应用级的无缝连接,需要以APP应用层级制定的业务逻辑及具体功能模块为制定接口的基准,以平台级的具体物理接口及可编程逻辑器件为制定接口基础。
当硬件平台级更换时,无需变更中间件的接口标准,只需修改平台级的相关驱动代码与之匹配,即可保证整个软件系统能在新平台级上正常运行。
中间件级依据APP应用层级的具体功能模块及模块内部的小项功能接口要求来实现具体标准接口的函数实体,依据平台层级的具体物理接口及可编程逻辑器件的性能及功能实现整个系统功能,已达到中间件级匹配APP应用层级及平台层级的效果,起到承上启下的作用。
2.4 平台级
平台级即为硬件层,即包含具体物理接口及可编程逻辑器件,包括设备的所有可见部件,诸如电路板、电子及组装配件、外壳以及线束等。平台级为系统的定位、采集、控制、网络连接及其他计算和服务提供硬件基础。作为整个系统的基础,该层通过各种电路及模块,为驱动及接口层提供系统启动、重启、时钟、运算、数据保存、定位、网络连接、采集、控制等功能。平台层是整个系统的基础层,在APP应用层的业务逻辑指令下,中间件层驱动平台层执行指令,进而获取平台级的资源,获取信息或输出控制。
3、天行健终端嵌入式软件分层开发技术在实践过程中的优势及问题
●分层开发技术的施行过程中的优势
由车载智能终端生产厂商提供车载智能终端平台级硬件及代码和中间件级功能代码,陕西汽车集团有限责任公司提供车载智能终端APP应用级代码及中间件级功能标准接口。以此方式实现车载智能终端嵌入式软件分层开发,采用该设计方案有以下优点:
1.分层开发从企业长远发展的角度上来说,极大提高了主机厂的自主选择权,降低了对单一供货商的依赖程度。
2.分层开发缩短了软件开发人员的开发周期,提高了开发人员的专注度,进而极大提高整个系统的稳定性;
3. 各层之间采用标准通讯及数据交换接口,层与层之间采用封闭式管理,很大程度上降低了系统的耦合性;
4. 通过分层结构的方式,可以分离开发人员相互之间的关注程度。由于某一层仅仅调用其相邻下一层所提供的服务,所以,只要本层的API和相邻下一层的API定义完整,开发人员在开发某一层时就可以像关注集中于这一层所用的思想、模式、技术,这样,就等同于将分工带来的生产力提高优势引入软件开发。
5. 各层之间采用标准通讯及数据交换接口,在优化及更改应用程序逻辑离散单元的功能的同时不干扰其他程序层级,进而大大的提高优化及维护效率;
6.《车载智能终端软件分层接口标准》订立可减少不同供货商之间针对功能需求理解的差异性;
7. 分层开发极大的提高软件复用性,缩短系统软件开发周期,提高系统的流畅性、稳定性及可维护性。
●分层开发技术的施行过程中的问题
1.分层结构不能保证封装所有的应用程序逻辑离散单元,某些复杂应用程序逻辑离散单元,一旦有功能变动,可能会波及所有的层。这种修改尤其体现在自上而下的方向。比如,如果在APP应用程序层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的驱动接口层增加或修改代码,甚至要修改硬件设计。针对这种问题,主要要通过前期深入讨论,以及相关供应商共同设计验证。
2.效率下降,各层之间的过于频繁数据交换及通讯,将引起系统效率降低,对于优先级水平分布的层级,效率降低较为明显。针对这种情况,一方面必须提升原有硬件设备的整体性能,同时硬件平台必须保证运行驱动接口层和APP应用程序层的基本性能资源,另一方面,可以通过软件的缓存机制来尽量减少对性能的影响。
4、总结
本文通过对陕西中交天健车联网信息技术有限公司天行健终端分层开发技术的研究及实践,创新性的将应用软件分层开发技术引入嵌入式软件开发中。解决了快速遴选供应商,软件跨平台移植,降低嵌入式软件对硬件平台的依赖性等问题。经过首次尝试,成功的完成了天行健终端全功能的开发,并在功能及性能上达到国家标准及企业标准。在开发过程中也认识到了分层开发技术在嵌入式软件应用当中的优势及问题。同时按照设计要求,在最终产品成型后总结出了《天行健嵌入式软件分层接口标准》。该标准的建立,更加简化了后期序列产品的开发周期以及屏蔽了嵌入式软件产品对硬件平台的各项要求,降低了当前使用产品的维护成本。为陕西中交天健车联网信息技术有限公司成为中国车联网技术及应用的引领者和规则制定者,打下了坚实的基础。同时也为陕西汽车集团由制造型企业转型为服务型企业,留下了宝贵的经验。本文希望通过以陕西中交天健车联网信息技术有限公司为鉴,力争为我国重卡车联网技术开发及应用穿针引线,为后续更多的车联网企业创新提供借鉴。为我国车联网行业的蓬勃发展做出贡献!
参考文献
[1]交通部标准《道路运输车辆卫星定位系统平台技术要求》(JT/T796).
[2]交通部标准《道路运输车辆卫星定位系统终端通讯协议及数据格式》(JT/T 808).
[3]交通部标准《道路运输车辆卫星定位系统平台数据交换》(JT/T809).
[4]交通部标准《道路运输车辆卫星定位系统车载终端技术要求》(JT/T794).
[6]国家标准《机动车运行安全技术条件》(GB7258).
[7]国家标准《汽车行驶记录仪》(GB/T 19056).
