嵌入式系统软件（共12篇）
嵌入式系统软件 篇1
0 引 言
近年来随着数字信息技术和网络技术的高速发展, 计算机的发展走入了“后PC”时代, 嵌入式系统越来越成为这个时代的主流[1]。但随着嵌入式产品的日渐普及, 嵌入式产品, 尤其是消费类电子产品的知识产权保护问题渐渐凸现。著名的如Microsoft的XBox被破解, 从而可以使用盗版游戏光盘;Apple的iPhone被破解, 从而可以使用GSM网络等, 这些事件都给厂商带来巨大的经济损失, 也阻碍了整个嵌入式产业的健康发展。
因此, 对于大多数商用嵌入式产品来说, 有必要引入一些软件保护机制, 来完成产权保护、数据安全的目的。
1 问题分析
首先, 我们需要对嵌入式领域的常见破解手段进行一个简单的分析, 在绝大多数情况下, 破解步骤大致可以分为以下三步:
(1) 定位目标软件镜像 根据破解目的, 定位出需要改写的目标软件镜像, 及其存储位置。
(2) 制作破解镜像 对原始软件镜像进行分析后, 改写甚至重写软件, 并生成相应的破解镜像。
(3) 替换目标软件镜像 使用破解镜像替换掉嵌入式产品上存储的原始镜像, 从而达到破解目的。
其中, 前两个步骤属于软件破解的通用手段, 理论上说, 只要破解者得到了能够运行的软件, 就不能禁止这两个步骤。因此, 我们将重点放在第三步, 也就是如何防止破解者非法替换软件镜像。而破解者进行第三步的常见手段如表1所示。
2 软件方案
2.1 基于单级密钥的软件镜像检查
为防止破解者直接替换目标软件镜像, 一种简单有效又不需添加成本的方式, 就是在嵌入式操作系统中添加对软件镜像的检查, 只有通过了合法性检查的软件镜像, 才允许加载运行。为了完成对软件镜像的检查, 最常用的做法是采用数字签名技术。美国电子签名标准 (DSS, FIPS186-2) 对数字签名作了如下解释:“利用一套规则和一个参数对数据计算所得的结果, 用此结果能够确认签名者的身份和数据的完整性”[2]。
以图1为例 (本文各图示中, 统一用私钥加密, 公钥解密) , 在各应用软件开发完成之后, 需要利用私钥计算出其数字签名, 并附加在软件镜像中。
如图2所示, 操作系统在载入该软件前, 一方面对数据进行哈希运算得到其摘要1;另一方面对签名使用公钥解密, 得到摘要2。接着比较摘要1和摘要2是否一致, 只有摘要一致的软件镜像才允许加载。
2.2 基于多级密钥的软件镜像检查
基于单级密钥的软件保护方案易于理解与实现, 但也有一个致命的缺陷, 就是各软件开发组使用相同的私钥, 那么软件A的开发者就可能生成软件B的镜像。因此, 需要引入多级密钥体系来增强该保护方案的安全性。为方便讨论, 这里以二级密钥为例, 这种情况下, 系统中会用许多密钥对:
· Root Keys
· App1 Keys
· App2 Keys
· …
· Appx Keys
当软件开发完成后, 需要经过签名才能烧写到嵌入式系统中。签名过程如图3所示。
而此时的软件镜像则如图4所示。
根公钥 (Root Public Key) 将硬编码在操作系统代码中, 其验证过程如图5所示。
根据二级密钥体系的原理, 可以很容易扩展到更多层密钥, 其特点是:从第1层开始, 第n层密钥用于处理第n层数据以及第n+1层的密钥, 直到最后一层。当然, 一般情况下, 2-3层密钥就可以满足绝大多数应用的需要。
相比于单级密钥机制, 多级密钥机制的优点是:
· 可以把软件X的私钥和公钥证书交给各软件开发组, 方便开发。
· 各软件使用不同的密钥对, 进一步提高安全性。
2.3 在Bootloader中加入软件镜像检查
以上的讨论中, 我们都是在嵌入式操作系统中添加对软件镜像的检查, 而在实际操作中, 由于操作系统经常需要升级以及多语言化, 往往有过多人员可能生成操作系统镜像, 因此仅将检查机制放在操作系统中不是一个很好的方式。所以, 为确保操作系统的安全, 常见的做法是在Bootloader中也添加对软件镜像的检查。
Bootloader就是在操作系统内核运行之前运行的一段小程序。通过这段小程序可以初始化硬件设备、建立内存空间的映射图, 从而将系统的软硬件环境带到一个合适的状态, 以便为最终运行操作系统内核准备好正确的环境[3]。
在Bootloader中加入软件镜像检查后, 此时的软件模块一般包括:嵌入式系统主程序包、语言包、Logo数据等。
2.4 实现重点难点
由于嵌入式系统与传统PC的不同特点, 在实现上述的保护机制时, 有一些重点需要注意。下面以在Bootloader中实现基于二级密钥的软件保护机制为例进行说明:
(1) 嵌入式环境下哈希算法的选择与实现
数字签名算法包括两部分, 用于计算数据摘要的哈希算法和用于加密摘要的非对称加密算法。
哈希 (Hash) 算法, 又称作摘要算法或散列算法, 是一种将任意长度的输入变换成固定长度的输出串的算法, 由于数据被“浓缩”, 哈希过程是不可逆的。哈希算法种类很多, 而目前使用最广泛的主要是MD5和SHA-1两种算法[4], SHA-1运算强度更高, 而MD5运算速度更快。由于MD5算法目前已被证明是不安全的, 所以一般情况下应优先选用SHA-1算法。
SHA-1 (Secure Hash Algorithm) 是由美国国家安全局 (NSA) 设计, 美国国家标准与技术研究院 (NIST) 发布的一系列密码散列函数SHA家族函数中的一种, 于1994年发布。SHA-1设计时基于和MD4相同原理, 并且模仿了该算法。与MD5 相比, SHA-1生成 160 位的讯息摘要, 虽然执行更慢, 但它的抗穷举性更好, 被认为更安全。SHA-1可以对长度不超过2^64比特的消息进行计算, 输入以512位数据块为单位处理, 产生160比特的消息摘要作为输出[5]。事实上SHA-1目前是全世界使用最为广泛的哈希算法, 已经成为业界的事实标准。
在嵌入式环境中, 实现SHA-1有两种方式, 一是采用纯软件算法实现, 这种方式与普通PC上的实现方式相同, 参考RFC 3174[6]即可实现;另外, 由于现在越来越多的嵌入式处理器提供了对各种常见加密算法的支持 (比如TI公司的OMAP系列芯片就提供了对MD5/SHA-1算法的支持) , 因此, 对于这种硬件环境, 可以调用处理器提供的加密算法, 充分利用硬件性能, 加速算法运算。
(2) 嵌入式环境下非对称密钥算法的选择与实现
非对称密钥算法, 又称作公开密钥算法, 它是用两个数学相关的密钥对信息进行编码。在此系统中, 其中一个密钥是私有密钥, 属于密钥持有者, 该私有密钥对即将发送的信息进行加密。另一个密钥叫公开密钥, 可随意发给期望同密钥持有者进行安全通信的人。公开密钥用于对信息解密[7]。目前常用的非对称密钥算法主要有RSA算法、DSA 算法和ECC 算法 (椭圆曲线算法) 。RSA 算法的安全性与DSA 算法大致相当, 因为两者的算法基础——大整数分解与求离散对数的计算复杂度是近似的, 但RSA 速度比DSA 算法更快。ECC 算法基础是椭圆曲线的对数问题, 这个基础使得它可能比RSA 更快更安全, 但它作为一种新的算法, 还有待进一步的检验和标准化[8]。所以一般情况下应优先选用RSA 算法, 这也是现在最普遍使用的非对称加密算法。
RSA是Ron Rivest, Adi Shamir和Leonard Adleman于1977年提出, 其原理是, 由两个大素数相乘得出的大数, 很难对其进行因子分解。它满足了非对称密钥算法的重要前提——两个密钥之间无法互相推导。由于大数的因子分解是一个公认的数学难题, 因此, RSA从提出到现在已近二十年, 经历了各种攻击的考验, 逐渐被人们接受, 普遍认为是目前最优秀的公钥方案之一。
与SHA-1类似, 在嵌入式环境中同样有两种实现RSA算法的方式, 在条件允许的情况下, 应该选用利用硬件加速的算法实现。
(3) 签名过程与验证过程的实现
在完成了加密算法的实现后, 签名和验证算法程就很容易实现了。需要说明的是, 签名过程将实现在单独的签名服务程序中, 并只需要包含非对称加密部分代码。而验证过程将实现在Bootloader中, 并只需要包含非对称解密部分代码。其中所用的软件镜像数据结构如图6所示。
(4) 密钥的存放位置
如图3所示, 为实现签名过程, 在软件开发完成后, 需要通过某种方式利用私钥生成签名。可以将加密私钥直接提供给软件开发者, 不过更通常的做法是由密钥管理者提供签名服务, 这样各软件开发者就不必直接访问私钥。
而在验证过程中, 如图5所示, 验证程序 (这里是Bootloader) 需要使用根公钥来进行解密。这里选择将该公钥直接硬编码在Bootloader中, 在实际实现中, 该公钥很可能加密后存放在硬件中, 3.1节将对此有进一步的描述。
(5) 验证内容的选择
由于不是所有的数据都需要进行软件保护, Bootloader必须要知道具体哪些软件需要进行验证。为此, 我们在Bootloader中引入Memory Map的概念, 即各软件镜像在目标Flash上的地址范围, 以及该软件模块是否需要进行验证。当然, 由于除操作系统内核外, 其余大部分软件都要被操作系统调用, 因此Memory Map应该由Bootloader开发组与操作系统开发组共同协商确定。比如说对于一个手机来说, Memory Map中很可能包含主程序包、Logo数据、主语言包、Flex包、用户数据等。其中, 除了用户数据的各地址块都需要进行验证。Memory Map的数据结构如图7所示。
(6) 验证点的选择
对于Bootloader来说, 首先应该在使用Bootloader烧写软件镜像时, 对其进行检查, 不允许烧写非法软件镜像;另外, 为了防止用户通过JTAG等低级手段烧写非法软件镜像, 还需要在Bootloader启动操作系统前检查各软件镜像, 如任一镜像非法, 则不允许系统启动。
3 硬件方案
纯软件方案最大的问题是, 它采用核心软件模块 (如Bootloader) 配合核心数据 (如密钥) 来验证其它模块, 而通常这些核心模块/数据与其它数据一样, 都存放于Flash上。一旦破解者采用JTAG等底层手段修改/替换了核心模块/数据, 则整套安全机制都将失效。因此, 在条件允许的情况下, 我们可以再添加一些软硬件结合的安全方案, 进一步保护核心模块/数据的安全性, 从而提高整个安全方案的保护强度。另外, 由于硬件特点的多样性, 合理地使用一些特定硬件, 还可以进一步扩大保护范围, 增添保护手段。
3.1 利用OTP保护核心数据
在基于数字签名的软件方案中, 验证模块中需要使用解密用的密钥, 而该密钥必定将存储在Flash上, 如果破解者替换了这部分数据, 改为使用自己的密钥, 则保护方案将失效。同样的问题也可能出现在一些出厂后就不希望被用户修改的核心数据上。
这时, 就可以使用OTP (One Time Programmable) 来对核心数据进行保护。OTP寄存器一般位于Flash芯片内部, 与普通的Flash数据区域很类似, 但1能被改写为0, 而0永远也不能写成1, 从而实现了只能编程一次的限制。
另外, 与OTP对应的, 还有一种同样只能编程一次的LOCK寄存器。LOCK寄存器的每一位对应于一个OTP寄存器。如果与OTP寄存器对应LOCK寄存器的位 (BIT) 被从1写为0, 就意味着这个被锁住的OTP寄存器再也不能进行写操作了。通过OTP寄存器与LOCK寄存器, 用户可以在OTP里保存一些核心数据, 例如秘钥、硬件版本号等。而这些信息将无法被非法更改。比如说对于2.4节中使用的加密公钥, 就可以将其存放在OTP中, 并锁定相应的LOCK寄存器。
3.2 利用处理器芯片保护核心模块
与核心数据相对应的, 核心软件模块被攻击的可能性更大。破解者往往会试图寻找验证函数的调用点, 并对其进行修改, 从而绕过我们的安全机制。所以, 我们需要一种能够保护核心软件模块不被恶意篡改的方法, 而由于容量的问题, 以及升级的需要, OTP并不适合用于保护软件模块。
针对这样的问题, 现在的主流嵌入式处理器芯片厂商都为此提供了解决方案, 芯片启动后, 在加载软件核心模块 (如Bootloader) 前, 同样可以对其进行数字签名的验证 (如图8所示) 。而芯片内的验证代码是出厂后就无法修改的。这样, 除非破解者替换芯片, 否则就无法修改/替换软件核心模块。采用这种方案时, 将要求处理器芯片厂商针对该款产品进行定制, 采用专用的密钥对。
另外, 在这种方案下, 供Bootloader使用的公钥则不必存放在OTP中, 直接编码在Bootloader镜像中即可。
3.3 利用OTP防止软件降级
由于嵌入式软件的日渐复杂, 即便开发者非常小心, 也仍然可能在软件中留下安全漏洞。为此, 厂商往往会升级软件, 并要求用户升级。而部分用户升级后, 为使用非法功能, 又可以回滚到原有的有漏洞的版本。使用OTP (One Time Programmable) 可以有效避免此类问题。根据3.1节对OTP的介绍, 厂商可以在OTP中存放软件版本, 但不锁定LOCK寄存器, 这样, 在每次升级软件版本时, 将比较当前版本与OTP中软件版本, 只有在当前版本大于OTP中版本的情况下才允许升级。而一旦成功升级, 将对OTP中一位进行编程, 从而升级OTP中的软件版本。加入了版本检查之后的升级过程如图9所示。
这样, 除非用户替换Flash芯片, 否则将再也无法回滚到旧的版本。更进一步, 为防止用户通过JTAG等低级手段强制降级, 可以在Bootloader或操作系统中添加对各软件版本有效性的检查。
3.4 软硬件绑定
以上介绍的保护方案都有一个破解模式, 就是通过替换一个特定硬件来进行破解。而在条件允许的情况下, 嵌入式厂商可以要求硬件厂商针对该产品进行特殊定制, 在硬件中添加该产品专有的属性。而在嵌入式厂商编写的所有软件模块中, 添加对硬件属性的检查, 防止硬件被替换, 该原理与PC上常用的加密狗保护原理类似。这样, 为替换指定硬件, 破解者必须要替换嵌入式厂商编写的全部软件模块, 而这样的破解已经失去意义。
4 方法比较与应用结果
下面对本文中提到的各种保护方案作一个小结。首先列出各种保护方案的适用范围如表2所示。
可以看出, 软件方案是基础, 而各种硬件方案则扩大了保护的范围。各种硬件方案的典型应用与优缺点如表3所示。
实际上, 由于硬件的多样性, 与硬件相关的保护方案可能会有很多种, 为达到比较好的保护效果, 应在实现了软件保护机制的基础上, 再选择几种硬件方案配合使用。例如在本文提出的几种方案中, 如果同时使用方案2、3、4, 应可达到相当强度的保护效果。
5 结 语
为了保护自身知识产权, 嵌入式厂商有必要在其产品中引入一定的软件保护机制。针对这种情况, 本文首先提出了以数字签名技术为基础的纯软件验证方案, 即对软件镜像添加签名, 并在嵌入式操作系统或Bootloader中完成验证机制, 来保证嵌入式软件的安全。在软件方案的基础上, 本文又针对一些常见硬件环境, 提出相应的保护方案, 从而扩展了保护范围并衍生出强度更高的安全机制。这样的一些安全机制, 对于需要进行软件保护的嵌入式厂商有着一定的参考借鉴价值。
摘要：随着嵌入式产品的日渐普及, 嵌入式产品的知识产权保护问题渐渐凸现。对于大多数商用嵌入式产品来说, 有必要引入一些软件保护机制来完成知识产权保护的目的。针对这种情况, 介绍了嵌入式环境下的一些软件保护方案, 包括不需硬件支持的纯软件实现方案, 以及与硬件结合的、强度更高的实现方案。并描述了这些方案各自的优缺点, 以及典型应用场景。
关键词：嵌入式系统,软件保护,Bootloader,数字签名
参考文献
[1]蒋军.电力应用背景下嵌入式安全操作系统的设计与开发[D].镇江:江苏大学, 2006.
[2]电子签名的技术实现[EB/OL].[2009-04-15].http://study.qqcf.com/web/84/10911.htm.
[3]詹荣开.嵌入式系统Boot Loader技术内幕[EB/OL].[2009-04-15].http://www.ibm.com/developerworks/cn/linux/l-btloader/in-dex.html.
[4]Bruce Schneier.应用密码学 (协议算法与C源程序) [M].北京:机械工业出版社, 2000.
[5]SHA-1算法简介及JavaScript实现[EB/OL].[2009-04-15].http://www.blogjava.net/orangelizq/articles/149802.html.
[6]D Eastlake, 3rd.RFC3174-US Secure Hash Algorithm 1 (SHA1) [EB/OL].[2009-04-15].http://www.faqs.org/rfcs/rfc3174.html.
[7]王纯.数字签名安全性研究[J].电脑与电信, 2006, 11:43-45.
[8]数字签名技术及其应用[EB/OL].[2009-04-15].http://www.591up.com/blog/storehouse/?action=DownLoad&code=5050&url=2008/01_24/334_2008012411483682.ppt.
嵌入式系统软件 篇2
DOI:10.16607/j.cnki.1674-6708.2016.03.049
在很多领域中，由于科学技术的不断发展，不可避免的需要使用大量的数据，面对这些算法复杂的数据，传统的图像处理系统已经不能满足要求。嵌入式图像处理系统在通讯、医药等方面都发挥着非常重要的作用，正是因为各个领域获得的图像数据越来越多，如何对图像数据快速准确的进行处理显得格外重要。所以需要设计出更优化的图像处理。
1嵌入式系统概述
1.1嵌入式系统的概念
嵌入式系统是建立在计算机技术基础上的应用型专用计算机系统，其软件和硬件都可以剪裁，系统对成本、功耗、功能都提出了更高的要求，具有可靠性强、体积小等优点，可以实现对其他设备的监视、控制和管理。随着嵌入式系统的不断发展，嵌入式系统已经渗透到人们的生活中，无论是在工业、服务业还是消费电子等领域都得到了广泛的应用。
1.2嵌入式系统的特点
与普通的计算机系统相比，嵌入式系统的专用性更强，一般是面向特定运用的，嵌入式处理器一般应用在用户设计的特定系统中，集成性高、体积小、功耗低，不仅具有方便携带的优点，操作系统更是实时操作的，可以满足实时性较强的场合要求。将嵌入式系统运用到应用程序中，在芯片上直接运行而不需要操作系统，未来可以充分利用更多的系统资源，用户需要选择RTOS开发平台，保障软件的质量。嵌入式系统主要包括硬件系统和软件系统，其中硬件系统是基础，软件系统是灵魂，复杂程度非常高。
2系统软件设计
基于RF5软件系统总体设计：嵌入式图像处理系统和传统处理系统一样，主要包括硬件和软件两个方面，硬件包括系统的硬件平台，软件包括嵌入式操作系统和图像处理算法两个方面。其中硬件平台又包括图像储存模块、通信模块和显示模块等，主要是为系统的软件系统提供支持。在图像处理过程中，硬件系统可以为其提供计算、显示、存储等条件[1]。RF5是以DSP和XDAIS为基础的代码参考框架，在DSP软件的设计和开发中具有重要的作用，参考框架在整个程序中具有非常重要的作用，是整个运用应用程序的蓝本。RF5的数据处理元素包括通道、单元、任务和XDAIS算法，这4个元素之间具有紧密的联系，独立又联系。嵌入式操作系统是整个系统的核心系统，提供了包括图形处理任务管理在内的各项管理，经过硬件的初始化、图像信息存储、图像信息显示等过程实现图像处理和存储。
3软件模块化程序实现
3.1初始化模块
软件系统的初始化模块主要包括处理器、RF5模块化初始化、图像处理算法、视频捕获、视频显示通道等。处理器和系统板初始化是指设备重启之后，通过软件配置的方式对外围设备进行配置和选择。系统在进行工作的时候，初始化模块是其执行的第一个任务，执行完初始化模块之后，程序的控制权将会转变到调度程序中，由调度程序来调度接下来的任务。
3.2视频捕获和显示模块
3.2.1视频捕获的实现
视频捕获主要负责将外部的视频解码器解码生成的数字视频信号采集收集起来，并且这个采集的过程非常方便，可以实现实时采集，最终形成的图形处理也是可以实时处理的，可以随时随地对大数据的图像进行处理，这也是其最大的优点和特点。采集到的数字视频信号进入到系统外扩的.存储器中，从而实现视频的捕获。视频采集可以自动采集，当单元进入自动采集状态，完成了图像的采集之后，视频端口都会向系统自动发出中断请求，中断服务程序便开始发挥自身的功能，对图像的存储区进行连续更新，图像存储区一旦更新之后，图像采集系统就会采集下一个图像数据，最终进入一个循环。当视频端口的FIFO装满了采集的数据之后，会发生中断信息，进入EDMAISR中断服务程序将视频数据送入到SDRAM中[2]。
3.2.2视频显示的实现
视频显示的实现是通过视频图像显示模块来实现的，视频图像处理模块处理后的图像经过显示模块处理，处理之后将图像编码成数字视频流，标准数字视频流经过系统编码转化为虚拟视频信号，经过解码器之后视频流就变成了标准的模拟视频信号，分别经过EDMA控制器和EDMAISR之后最终进入到视频端口的缓冲区中，经过缓冲器之后，信号会使EDMA中断，送入新的图像信号，并在显示器上显示出来，视频显示的流程。输出作用在外部编辑器中。
3.3图像处理模块
图像处理模块比较灵活，是指在嵌入式的环境下实现对图像的处理。在图像处理系统中，又包括系统功能模块和图像增强模块。系统功能中包含图像增强功能，除了图像功能之外，还包括图像的几何变换、形态运输和图像分析。在图像增强模块中又包括图像的预处理和边缘检测、直方图修正、中值滤波、灰度变换调整，而图像预处理又包括图像平滑和图像锐化。图像平滑就是消除噪声对图像造成的影响，图像平滑的处理是通过高斯低通滤波法来实现，这样做虽然可以消除图像受到噪声的影响，但同时也存在着一定的弊端，图像经过处理之后会变得模糊。图像锐化的目的就是让模糊的图像重新变得清晰。图像模糊是由于图像受到平均或积分运算而造成的，图像锐化就是对其进行逆运算，重新使图像变得清晰[3]。
4结论
嵌入式图像处理系统的软件系统主要包括初始化模块、视频捕获模块、视频显示模块和图像处理模块，在确定了整个软件系统的程序流程之后，就可以分别设计纷纷模块的程序，最终完成整个软件系统的设计。
参考文献
[1]吴锡强.探析嵌入式图像处理系统的设计与实现[J].计算机光盘与软件，，12(3)：307-309.
[2]蒋立丰.嵌入式图像处理系统的设计与研究[D].东华大学，，22(21)：11-13.
嵌入式系统软件 篇3
关键词：嵌入式软件；开发模式与软件架构；系统安全
中图分类号：TP311 文献标识码：A 文章编号：1006-8937（2016）06-0064-01
信息社会的互联网在发展过程中面临着越来越复杂的问题，嵌入式软件在开发和架构过程中随着功能需求的加大，嵌入式软件也更加广泛地应用于各种设备上，这种广泛的应用对嵌入式软件操作和运行过程中的稳定性和安全性问题提出了更高的要求，然而受到当前技术水平的制约，在软件开发和研制的过程中还存在着较多的问题，它与其他的软件比如说桌面软件等存在着较大的差异，由于其技术还不够成熟，因此在开发和软件架构的过程仍旧是嵌入式软件需要进行解决的关键问题。
1 嵌入式软件开发开发和架构问题简述
首先，在软件的开发阶段，为了减少系统资源的过度消耗，嵌入式的软件在代码的制作过程中主要针对的是用户使用过程中的问题，其复用度比较低，这就导致了软件在实际使用过程中实现用户多项的应用要求时发生困难，这是在开发过程中必须要进行统筹的问题。
其次，嵌入式软件在具体的应用过程中通过与硬件驱动的接口进行对接操作，由于面对的对象硬件驱动等应用对象的差别比较大，在这个过程中不同的设备之间的差异需要嵌入式软件要有与之比较高的兼容性，这需要在软件的开发过程中对常见的的对接的硬件进行操作系统进行代码的编写。
在软件的使用过程中为了解决使用过程中软件本身存在的问题以及满足新的用户要求需要对软件进行升级扩展其功能，并且保证在使用过程中软件的工作效率和安全性，需要向被嵌入的操作系统进行代码的植入，这个问题降低了软件在使用过程中的效率问题，在研发过程中，这造成软件的开发周期延长和开发效率的降低。
2 开发模式和软件架构
嵌入式软件的开发模式与一般的桌面型软件的开发模式的开发过程存在着较大的差异，它首先表现在开发过程中，它首先要考虑到代码在不同接入的硬件系统的兼容性，同时需要在代码的编译过程中交叉编译，这些问题给软件的研发带来很多问题和要求，导致在软件的研发过程中，无法灵活地适应市场的变化随时发生调整。
利用多平台的研发条件以及套件式交付的方式能够最大限度上利用研发平台和实现资源的共享，有效提高产品的质量和减少研发的时间以适应市场的需求，降低研发成本，这是未来嵌入式软件研发的趋势。
在嵌入式软件的研发过程中，准备阶段包括获取开发套件和与开发环境集成，编码的阶段是一个利用终端模拟器进行反馈的系统，在这个过程中，工程师进行相关的应用程序的编写以及进行运行程序的编译，完成后进行初步的运行和调试，通过自动写入终端模拟器进行反馈，如果有缺陷则会重新进行缺陷的部分程序的重新编写。
集成调试的反馈建立在编码基础，调试正常的编码进行应用程序的归档，归档完成后进行集成的编译，并进行运行和调试，集成的编译通过编入目标系统完成试运行，并完成整个过程的试用报告，在运行过程中如果存在漏洞则会重新进入终端模拟器寻找发生漏洞的编码并进行漏洞的修复。
嵌入式软件在应用架构过程中分为三个层面：接入层、应用层和基础层。用户通常通过三种常见的方式进入软件构架实现多种功能的应用层面，电脑接入、手机接入和遥控接入进入用户的数据管理、节能优化、充值服务以及安全控制等应用层面，应用层面通过控制、采集以及通讯等手段实现对电子锁、电器、仪表等接入系统中的控制实现用户的所要求的功能。嵌入式软件系统结构图，如图1所示。
嵌入式软件的各个层面通过协调完成设备的预定功能，通过接入目标设备的接口以及各个设备之间的实现整个系统的运行。在接口层首先存在着接入的要求，这些要求是实现功能的预设。可以通过接入以及用户的功能要求进行具体的配置制定出符合特定要求的软件系统。
进行功能控制和管理的是内核层，这个层面主要进行任务的管理和分配调度，而其他的应用组件比如网络协议和数据库等可以通过存储实现复用以尽量减少软件的进行系统烧入的时间，同时用户可以根据自己的需求进行配置，这就使得软件的应用范围更加广阔。
设备的操作层中对硬件的功能进行封装，通过提供对各种操作系统的硬件功能提供统一的软件接口能够保证软件在烧入的过程中中成功移植的关键所在，这个过程实际上也是实现了硬件操作过程中代码的复用的过程。这种方式可以应用到其他的嵌入嵌入系统的开发利用中，针对不同的芯片进行对应的编码的编写并进行存放实现对不同系统中同一功能元件的代码复用。
3 嵌入式软件开发模式和架构中有关升级和升级的 效果评估
在软件的开发模式和软件架构过程中必须考虑的关键问题就是在后期用户使用过程中的软件升级问题，嵌入式的软件适用不同类型的设备，但是其自身并不存在升级的功能，因此在使用过程中出现的缺陷和漏洞系统无法进行修复，而且在使用过程中，用户会逐渐产生新的功能需求而这种需求在软件的开发和架构过程中往往是无法预期的，这就需要利用远端进行软件的升级。
目前市场上运用的方式需要在软件在开发和架构过程中就进行控制，远端接收到嵌入软件运行过程中的漏洞以及用户发送的升级要求，针对这些问题进行相关的代码的改写以及增加功能代码的写入，这个过程中主机实现了二进制的解析以及命令的下达，需要升级的软件所在的设备实现了与主机的通信并进行数据包的传送，通过数据的传送进行软件升级的准备以及进行必要的软件漏洞和缺陷地弥补等，目前主要通过多次的数据的传输来保证传输数据的完整，同时也对文件长度进行确定保证软件省局数据的准确。
4 结 语
嵌入式软件目前已经占据了较大的市场份额，但是过高的软件研发的经费阻碍了其研究发展的进程，随着市场对于嵌入式软件功能的需求的扩大以及软件质量要求的提高，这对软件的开发模式和软件架构方式的革新提出更高的要求，这要求在软件靠法过程中实现缩短产品的开发周期和成本，另外软件复用通过在计算机系统中进行控制来实现软件研发过程中的大规模应用问题，这对软件的研发成本的降低以及更好地满足用户更为复杂的功能要求具有非常重要的意义。因此，对于软件的开发模式和软件架构的问题的研究还需要进一步的投资和工程人员投入，以实现其大规模的应用。
参考文献：
[1] 吴慧婷，綦志勇.一种简单可靠的嵌入式软件升级方法[J].信息技术与 信息化，2015，（9）.
嵌入式系统软件设计方法应用分析 篇4
1 嵌入式系统的发展历程
自从在上世纪七十年代最早的嵌入式系统的前身单片机问世之后, 经过无数科学研究人员的不屑努力, 各种各样的嵌入式微处理器和嵌入式微控制器相继出现, 正式标志着嵌入式系统进入了发展阶段, 也成为了时代发展的一部分。到现在, 嵌入式系统的发展已经有了将近四十年的历程, 在这四十年当中, 嵌入式系统已经陆陆续续的渗透到工程设计、科学研究、军事技术以及网络技术中, 成为人们生活所必不可少的一部分。而且, 随着科学技术以及计算机网络技术的不断发展, 对嵌入式系统的功能和运行的可靠性要求也变得越来越高, 使得嵌入式系统的设计和开发也变得越来越困难。
2 嵌入式系统软件设计流程
虽然嵌入式系统软件的整体设计流程跟通用软件的设计没有太大的区别, 但是在具体的性能要求上, 嵌入式系统软件的设计却有着更为严格的要求, 比如, 嵌入式系统软件对系统所具有的实时性能和可控性能就有着十分严格的要求, 设计精度要求也更高。总的来说, 嵌入式系统软件的设计共可以分为五个阶段。
2.1 确定驱动接口
嵌入式系统软件的设计主要都是在硬件驱动层的基础上进行设计的, 也就是说, 在嵌入式系统软件的设计过程中, 当在系统硬件上确定了驱动软件的接口之后, 软件的设计就已经开始了。在嵌入式系统软件的设计过程中, 首要任务就是确定软件驱动接口的有效性, 要能够满足硬件通过驱动接口对软件进行有效操作。
2.2 按照实时性划分软件功能模块
嵌入式系统的软件设计对实时性有着很高的要求, 因此, 在对软件进行设计的过程中, 一定要对软件设计的实时性引起足够重视。软件设计的实时性主要可以分为实时和分时两个部分, 由于这两个部分拥有不同的系统功能, 所以它们对设计也有着不同要求。因此, 针对这种特性, 在软件设计过程中, 可以根据实时性的不同将软件设计分成实时和分时两个部分, 然后分别对两个阶段进行设计。
2.3 生成软件代码
软件代码生成是嵌入式系统软件设计的重要阶段之一, 是根据各个模块的不同功能要求编写具体的代码, 然后通过对功能分析和总结, 确定所编写代码, 最终生成软件代码。
2.4 软件功能集成测试
在根据软件不同功能模块的不同要求编写并生成软件代码实现模块功能之后, 还要对软件中所有的功能模块进行集成测试, 在测试过程中, 仔细观察软件功能集成运行中单个功能模块所存在的问题以及各个模块之间的衔接运行问题, 如果发现问题, 第一时间对有问题的模块进行更改, 更改之后继续运行, 再次检查问题。如此反复, 直到确定整个软件的运行不存在任何问题为止。
2.5 代码固化
在完成以上所有阶段的设计之后, 就要进行最后的代码固化处理。在确定代码和功能集成运行都没有什么问题之后, 将所有的代码移植到目标机上进行固化处理和运行调试。在代码固化和调试之后, 还要让软件脱离调试环境进行试运行。
3 嵌入式系统软件设计方法应用
3.1 对软件的实时性进行设计
跟通用软件设计相比, 嵌入式系统软件设计对系统的实时性具有很高的要求, 只有保证嵌入式系统的实时性, 让系统能够在规定时间内对激励做出反应, 才能够保证嵌入式系统的正常运行。因此, 在软件设计过程中, 一定要按照实时性的不同, 将软件功能分为实时和分时两个部分对软件的实时性能进行严格、合理设计, 保证嵌入式系统软件的实时性能。
3.2 对软件的可靠性进行设计
为了能够有效保证嵌入式系统运行的可靠性, 在对软件进行设计过程中, 还需要对软件的可靠性进行合理设计。在对软件进行设计的过程中, 一定要在充分考虑嵌入式系统运行特点的基础上, 仔细编写功能模块的代码, 尽可能避免错误的出现。同时, 在编写完功能模块的执行代码之后, 一定要立即对其进行试运行, 如果发现问题, 及时进行解决, 以避免集成功能后对系统的运行的可靠性造成影响。
3.3 对软件的可拓展性进行设计
当前, 网络技术和移动网络技术更新换代的极为快速, 对嵌入式系统先进性的要求也比较高, 否则, 如果嵌入式系统跟不上网络技术的发展脚步, 最终就会被淘汰。因此, 在对嵌入式系统软件进行设计的过程中, 一定要对软件的可拓展性进行设计, 最起码, 软件的可拓展性要满足三年到五年之内的发展需求。一旦嵌入式系统软件需要进行升级和更新, 只需要插入新的功能模块或者是简单的对代码进行更改就可以完成, 不必要对原有的软件造成损坏。
3.4 混合编程, 提高软件的执行力
混合编程指的是在软件编程过程中, 同时利用汇编语言和高级语言进行编程, 这也是当前编程发展的一种主要趋势。在编程过程中, 针对不同的编程要求选择不同的编程语言, 比如, 对一些执行能力要求比较高或者是实时性要求比较高的程序的编程, 应该选择严谨性比较好的汇编语言进行编写, 而对于一些对逻辑性要求比较强的程序的编程, 可以选择利用具有一定智能性的高级语言进行编写。如此以来, 就可以同时提高软件的执行力和分析能力, 提高嵌入式系统的智能型。
4 结束语
嵌入式系统已经成为人们生活的重要组成部分之一, 因此, 在日常工作当中, 一定要对嵌入式系统的设计和开发引起足够重视。而在嵌入式系统中, 软件占据着极为重要的组成部分, 也是系统设计、开发的重点、难点, 所以, 在软件设计过程中, 一定要从软件的实时性、可靠性以及可拓展性等方面进行综合考虑, 对软件进行合理设计。
参考文献
[1]吕骏.嵌入式系统设计[M].北京:电子工业出版社, 2012.
[2]郑泽胜.嵌入式系统以及实时软件开发[J].电子科技, 2010 (01) .
嵌入式系统软件 篇5
2.1开发流程
出于保证嵌入式实时软件在计算机软件中充分发挥作用的考虑，在具体设置嵌入式实时软件应用的开发流程时应当基于简易性和优越性出发，科学、合理的规划设计。具体的嵌入式实时软件应用开发流程为：首先是基于计算机软件系统应用要求，分析计算机软件需要具备的功能，进而进一步解析嵌入式实时软件。其次，基于嵌入式实时软件应用需要，科学合理地进行嵌入式软件设计和代码生成。再次，在嵌入式实时软件设计方案完成之后对其应用测试，确定依据此设计方案所设置的嵌入式实时软件的应用效果能否满足计算机软件系统应用需要。最后，在确定嵌入式实时软件设计方案符合应用要求的情况下将嵌入式实时软件有效地应用到计算机软件系统当中。按照以上开发流程来进行计算机软件系统开发，的确能够使嵌入式实时软件有效地应用到计算机软件系统中，并且在系统中充分发挥作用，提高计算机软件系统的应用有效性、可靠性、稳定性[4]。
2.2设计要点
微软嵌入式也要“软件＋服务”化 篇6
“嵌入式产品正在由过去孤立的设备朝着一个连接性、服务导向的设备转变，微软的平台也从过去单纯的软件平台向‘软件+服务’的平台转变。”不久前来到中国的微软嵌入式事业部总经理Kevin Dallas表示。
智能、连接性和服务导向，这是Kevin Dallas反复提到的未来嵌入式终端产品的三大特点。而在构建智能、连接性和服务导向设备的过程中，服务尤其关键，这包括平台与工具服务、设备服务和终端用户服务三大类。
一个OEM厂商向市场投放一个嵌入式设备后，可以对这个产品进行远程技术支持，设备自身可以提供智能化的信息，便于厂商更加有效地管理和监控；一个终端用户可以通过嵌入式终端设备享受到包括位置服务、搜索服务和媒体服务等在内的实时服务，这些就是微软嵌入式系统“服务”的重要内容。
微软的嵌入式产品家族包括三大类: 为手持设备、瘦客户机、逻辑控制器和消费电子产品等小型实时设备定制的Windows Embeded CE、应用于非个人计算机设备的Windows XP Embeded，以及为零售设备外设提供即插即用功能的Windows Embedded for Point of Service（WEPOS）。
目前，微软Windows Embedded已经构造了一个由全球数千家设备制造商和分销商组成的生态系统，全球已有超过450所大学将Windows Embedded应用于课程教学和研究中，使用Windows Embedded集成开发环境工具的开发者也超过了600多家。
今天， 微软嵌入式系统在个人导航设备领域占有35%的市场份额，在瘦客户机、POS机市场分别占有52%和50%的市场份额，在ATM、瘦客户机方面也都占有最大的市场份额，“这个市场地位的取得也是我们要继续向‘软件+服务’平台转型的原因。”Kevin Dallas表示。
嵌入式系统软件 篇7
随着电网的不断发展, 控制中心在电网分析与控制方面的需求也越来越丰富, 这些具体的应用模块往往由不同的开发厂商提供, 并部署在控制中心的能量管理系统 (EMS) 之上, 为此需要各种应用模块与EMS进行有效的集成。在各种集成方案中, 嵌入式集成方案有以下显著优势:①功能分工清晰, 应用模块负责核心计算等功能, 而进程管理、人机交互、数据存储等由EMS平台统一提供;②数据源唯一, 便于维护;③可最大程度减少软硬件投资;④人机界面风格一致, 符合用户使用习惯。
随着未来智能电网调度技术支持系统在国家电网体系内的全面推广, 如何在此平台上实现应用软件的嵌入式集成已经成为业界关注的热点。本文提出了“即插即用”式嵌入式软件开发的框架与方法, 并以嵌入式自动电压控制 (AVC) 主站系统为实际案例进行详细阐述。
1设计思想
“即插即用”概念来源于硬件芯片设计思想, 芯片的核心电路功能可以采用不同方法实现, 只要保证芯片各引脚的功能 (与主板交互的数据) 相同即可。而这种“即插即用”的设计思想也一直是嵌入式软件系统设计所追求的目标。
嵌入式软件系统分为核心模块 (类似于芯片核心电路) 和接口模块 (类似于芯片引脚) 2部分, 针对不同的EMS (类似于外围设备, 如主板等) , 只需要改变相应的接口模块, 相当于构造嵌入式“软件芯片”, 如图1所示。
为实现上述软件框架, 需要解决以下关键问题:
1) 如何封装核心模块
核心模块完成数据处理与计算功能, 封装核心模块的目标是保证其独立于外部EMS。为此, 核心模块必须通过接口模块间接与EMS交互, 并将所有与外部EMS相关的代码在接口模块中实现。
2) 如何实现接口模块
作为核心模块与EMS的唯一交互接口, 需要对交互数据类型和可能的交互方式进行整理, 确保针对不同的EMS, 接口模块的功能定义不变, 改变的只是实现方式, 从而固化核心模块。
为解决上述2个关键问题, 需要对被嵌入的软件系统进行充分的分析和整理, 构建嵌入式接口并应用于实际应用系统。
2构建嵌入式系统接口
结合现场开发经验, 本文对控制中心应用软件与EMS的数据交换进行整理, 构建嵌入式系统接口。
2.1数据交换方式及交换内容
为构建嵌入式系统接口, 首先应明确双方需要交换的数据及可能的交换方式。嵌入式系统接口可以通过标准化、应用程序接口 (API) 、双方约定等3种方式来实现。
1) 标准化
IEC 61970系列标准化接口为实现不同系统间的数据交换提供了一种标准途径[1,2]。典型的标准化接口应用包括使用公共信息模型 (CIM) 标准文件交换模型数据、使用E语言文件格式交换实时数据, 使用组件接口规范 (CIS) 接口交换实时数据等。
使用标准化接口方式是实现系统间数据交换的重要方式, 已经得到了广泛应用[2,3]。但标准化接口只能对特定内容、特定格式的数据进行交互, 而且不同EMS对标准化接口的支持能力、标准化接口的稳定可靠性差别较大, 目前仅依靠标准化接口难以完全满足嵌入式应用数据交换的需要。
2) API
基于EMS提供的API完成相应的数据交换。在这种情况下, 嵌入式系统需要针对不同的EMS开发相应的接口模块。
EMS提供的API接口为EMS所有应用模块服务, 其稳定可靠性可以保障。但这种方式要求EMS本身具有较好的开放性。在这种方式下, 所有开发工作都在嵌入式系统侧完成, 不需要EMS进行改造。
3) 双方约定
受EMS自身平台功能的限制, 难以保证所有接口都可以使用API接口方式来实现, 对一些特殊数据, 需要EMS与嵌入式系统双方约定交换方法及数据格式。在这种情况下, 交换双方均需要进行相应的程序开发工作, 一般采用文件或者TCP/IP报文方式。
表1给出了3种接口方式在灵活性和使用工作量上的对比情况。在实际应用系统中, 应根据EMS功能及现场需要选择最合适的接口方式。
表2整理并分析了嵌入式系统与EMS所需要交互的数据, 同时针对各种数据交换类型提出了建议的接口实现方式。
2.2接口实现方式
接口模块实现的关键是将核心模块与EMS分离, 使它们都可以独立地变化。为此, 采用Bridge模式来设计实现接口模块:将EMS抽象接口和它的实现部分分别放在独立的类层次结构中。其中一个类层次结构针对EMS接口, 另外一个类层次结构针对平台相关的EMS实现部分[3]。图2以数据采集接口为例说明Bridge模式。
其中:类CEMS提供了嵌入式系统与EMS进行交互的接口并维护一个指向虚类CEMSImpl的指针;接口GetData () 用于描述CEMS提供的实时数据采集接口;虚类CEMSImpl定义了实现类的虚接口;CEMS通过调用CEMSImpl提供的接口来完成功能;CEMSImpl各子类 (CEMS1Impl, CEMS2Impl) 负责实现类的具体实现, 该实现通过上文提供的3种数据交换方式完成接口的具体实现。
图3以获取实时数据功能为例描述了嵌入式系统如何与EMS进行交互。
在嵌入式系统中, 专门启动数据采集进程从EMS获取实时数据。该数据采集进程调用CEMS类提供的GetData () 接口;具体的交互实现由CEMSImpl子类的EMSGetData () 接口来完成。
3嵌入式AVC主站实现方案
随着经济的发展和人民生活水平的提高, 电压质量问题日益突出, 使用AVC系统实现电网电压自动控制的需求日益迫切[4,5]。AVC系统最近几年刚刚起步, 并在国内多家网省调得到广泛应用[6,7,8,9]。一般来说, 在建设AVC主站系统时, 控制中心EMS及相关的软硬件条件已经比较成熟, 而且AVC主站系统与EMS往往由不同生产厂商提供, 因此不可避免地要在现有EMS运行环境中实现AVC主站系统的相关功能。在各种AVC主站系统的实现方案中, 嵌入式AVC主站系统由于嵌入式方案的显著优势脱颖而出。下文重点阐述嵌入式AVC主站系统的实现方案。
3.1数据流程
嵌入式AVC系统的数据流程如图4所示。
AVC系统从EMS获取模型类数据 (包括电网模型及AVC控制模型) 和实时数据, 通过控制计算生成实时控制策略;控制策略通过EMS提供的遥控、遥调接口下发给子站系统;AVC计算结果通过EMS人机接口在EMS人机界面上显示;AVC需要长时间保存的历史数据通过EMS提供的商用库访问接口保存在EMS商用数据库中。
3.2嵌入式AVC系统开发实现
AVC主站系统核心模块通过调用类CEMS提供的接口完成与EMS的交互。为提高系统稳定性, 各核心功能模块以独立进程方式运行, 进程间通过基于文件映射机制的实时数据库[10]进行通信, 充分保证了系统的运行速度, 并通过进程锁和流程控制机制对各功能模块进行组织和协调。
对于AVC主站系统, 主要在模型数据获取、实时数据采集、指令下发、历史数据管理、消息处理、结果显示等6个方面涉及与EMS的交互。为此, 在接口模块的类CEMSImpl中对该6大类接口功能进行封装, 并针对不同的EMS在CEMSImpl子类中完成相应的实现。表3描述了类CEMSImpl定义的各接口所交互的数据及接口实现方式。
3.3工程应用实施情况
本文设计的嵌入式AVC主站系统已经在多家网/省级电网得到实际应用, 包括南方电网总调、华东网调、江苏省调和湖北省调等。
从用户使用角度考虑, 嵌入式AVC主站系统相当于EMS应用的一个模块:AVC主站系统核心模块可以部署在EMS的某一应用服务器上 (比如电网应用软件 (PAS) 主机) , 无需新增硬件投资;AVC系统使用EMS提供的人机界面, 已有的EMS工作站都可以根据一定权限浏览和使用AVC功能;采用与EMS风格一致的人机界面, 符合用户使用习惯;维护界面一体化, 极大地减少了维护的难度和工作量;AVC系统使用EMS提供的API来完成历史数据存储, 不需要额外的历史数据服务器、商用数据库软件、磁盘阵列等硬件、软件设备。
从开发角度考虑, 对每一个新的工程项目, AVC系统主体框架和核心程序不需要改动, 只需要重新实现接口模块即可, 减少了程序代码的开发量, 并且各程序版本具有向下兼容性, 减少了程序版本的维护工作。
4结语
本文提出了“即插即用”的嵌入式系统框架和实现方法, 并根据该设计框架研究并实现了嵌入式AVC主站系统, 将EMS的平台优势与AVC系统的控制算法优势相结合, 提高了AVC系统的实用化水平。随着未来控制中心功能的不断扩展和用户需求的不断增加, 嵌入式的软件系统在控制中心调度自动化领域有着广阔的应用前景。
参考文献
[1]IEC61970Energy management system application program interface (EMS-API) :PartⅠCCAPI guidelines preli minary draft.1999.
[2]孙宏斌, 吴文传, 张伯明, 等.IEC61970标准的扩展在调度控制中心集成化中的应用.电网技术, 2003, 29 (16) :21-25.SUN Hongbin, WU Wenchuan, ZHANG Boming, et al.Application of extension of IEC61970standardin control center integration.Power System Technology, 2003, 29 (16) :21-25.
[3]GAMMA E, HELM R, JOHNSON R, et al.Design patterns:elements of reusable object-oriented software.New York, NY, USA:Pearson Education, 2002.
[4]孙宏斌, 张伯明, 郭庆来, 等.基于软分区的全局电压优化控制系统设计.电力系统自动化, 2003, 27 (8) :16-20.SUN Hongbin, ZHANG Boming, GUO Qinglai, et al.Design for global opti mal voltage control system based on soft identification of secondary control zones.Automation of Electric Power Systems, 2003, 27 (8) :16-20.
[5]张伯明.现代能量控制中心概念的扩展与前景展望.电力系统自动化, 2003, 27 (15) :1-6.ZHANG Boming.Concept extension and prospects for modern energy control centers.Automation of Electric Power Systems, 2003, 27 (15) :1-6.
[6]郭庆来, 孙宏斌, 张伯明, 等.江苏电网AVC主站系统的研究和实现.电力系统自动化, 2004, 28 (22) :83-87.GUO Qinglai, SUN Hongbin, ZHANG Boming, et al.Research and development of AVC systemfor power networks of Jiangsu province.Automation of Electric Power Systems, 2004, 28 (22) :83-87.
[7]郭庆来, 王蓓, 宁文元, 等.华北电网自动电压控制与静态电压稳定预警系统应用.电力系统自动化, 2008, 32 (5) :95-98.GUO Qinglai, WANG Bei, NI NG Wenyuan, et al.Applications of automatic voltage control systemin North China power grid.Automation of Electric Power Systems, 2008, 32 (5) :95-98.
[8]丁晓群, 黄伟, 章文俊, 等.基于电压控制区的主导节点电压校正方法.电网技术, 2004, 28 (14) :44-48.DI NG Xiaoqun, HUANG Wei, ZHANG Wenjun, et al.Apilot bus voltage correction method based on voltage control area.Power System Technology, 2004, 28 (14) :44-48.
[9]李端超, 陈实, 吴迪, 等.安徽电网自动电压控制 (AVC) 系统设计及实现.电力系统自动化, 2004, 28 (8) :20-22.LI Duanchao, CHEN Shi, WU Di, et al.Design and i mplementation of AVC system for power networks of Anhui province.Automation of Electric Power Systems, 2004, 28 (8) :20-22.
嵌入式系统软件 篇8
嵌入式Linux电源管理结构
Linux标准内核标准电源管理有ACPI、APM等机制。这些机制依赖于PC机的BIOS功能实现。嵌入式系统一般都没有实现BIOS支持，对其能耗管理机制需要进行其他定义。消费类电子产品联盟—CELF对能耗管理作了定义，其框架如图4所示。
CELF的能耗管理框架分为内核层和用户层。内核层又划分为体系结构无关层和体系结构相关层。体系结构相关层主要提供可管理硬件支持，例如处理器电压和运行频率调节，各种总线运行频率管理，设备的关断管理等。内核体系结构无关层在体系结构相关层的基础上为用户层提供APIs，进行各种能耗管理功能的支持。它包含一个能耗管理 (PM) 引擎，根据系统任务负载选择系统运行状态;提供能耗管理的挂起和恢复方法;提供VST技术，通过估计下次准确唤醒时间来确保在进入深度睡眠时，不被原来固定时间产生的定时器中断唤醒;还包含了各种外部设备关闭/开启的操作逻辑。
用户通过编制具有一定智能的管理策略驻留程序，利用系统提供的能耗管理机制，进行有效的系统能耗管理。
此外，在某些实现中，也可以将ACPI中的BIOS调用进行映射，在内核用软件实现回调函数，用以支持没有BIOS的电源管理。
嵌入式Linux内核电源管理实现分析
2.6内核提供了一个电源管理框架，在其基础之上容易实现各种电源管理规范，例如ACPI和APM规范。2.6内核中的设备驱动模型 (Linux Driver Model, LDM) 是内核对电源管理基础支持。Kobject基本结构嵌入到描述设备模型的组件的bus、devices、drivers结构中。这些容器就是通过kobject连接起来形成树状结构。每个对象的属性 (attribute) 以文件形式输出到kobject对应的sysfs目录下。通过这种文件系统接口，可以对平台进行有效的电源管理。
就嵌入式系统而言，电源管理可以分为静态电源管理，动态电源管理，设备电源管理等三个方面。
·静态电源管理
Linux内核支持ON, Standby, Suspend, 和Hibernate四种电源状态。Standby指“带电挂起”，通过将CPU置于halt状态，将设备置于D1状态来达到节能的目的 (ACPI规范中按能耗从高到低分D0～D3) 。节能效果不明显，但是响应延迟最小。Suspend就是挂起到RAM。在该状态下，所有设备被置于D3状态，整个系统，除主存处于节电的自刷新模式 (self-refresh) 外，全部关闭电源。响应延迟比Standby大。Hibernate是通过将系统状态保存到非易挥发性存储中 (通常是磁盘) ，关闭整个系统的电源。延迟时间最长，但比一次完整启动来得短。通常情况下嵌入式设备都没有支持这种方式。
通过sysfs文件系统接口触发系统级电源状态转化。转换管理是通过注册好的驱动来进行。例如，prepare函数确认系统能够进入所请求的状态，并且进行相应的准备工作。例如通过禁止抢占和“冷冻”所有进程来准备进入所请求的电源状态。Save函数枚举所有注册有电源管理能力的设备，保存系统和处理器的低层状态。接着PM核心禁止了中断，关闭外部设备电源，调用Sleep函数根据挂起级别进入睡眠状态。在嵌入式设备挂起过程中可以通过写入某些特殊的非易失性处理器寄存器来记录挂起的原因和挂起时的代码执行地址。系统上电后引导程序先执行，从特殊寄存器中判断系统是否从深度睡眠 (Hibernation) 中恢复。如果是，则负责从非易挥发性存储介质中恢复所有的硬件上下文。如果不是，系统负责从sleep () 函数处返回。给所有设备上电，恢复中断。Restore函数被用来恢复系统的低层调用，恢复设备上下文。Cleanup函数从sleep状态恢复必须进行的清尾工作，例如抢占重新被允许，系统恢复正常执行。当一次完整的转换完成后，CPU执行权还给之前执行的进程。
·动态电源管理
(1) 动态电源管理原理
如图5所示，系统无任务时进入空闲，可被中断唤醒，处理完后重新进入空闲或者回到任务态。如果系统被挂起到RAM中，进入深度睡眠。可以关闭除了中断控制器和唤醒源之外的所有设备，实现最大限度地省电。根据运行时不同的任务负载，系统应该有对应的不同电源级别。如图示中的任务、任务-、任务+等代表电源需求的状态。在完成任务的同时，进行最大化的节能。
(2) 动态电源管理设计
在Linux架构下实现动态电源管理，需要 (1) 用户层的管理策略; (2) 内核模块需要为应用层提供的接口; (3) 硬件无关的通用电源管理逻辑控制框架; (4) 管理特定硬件的平台相关电源控制层。
用户层策略通过sysfs文件系统接口 (或p r o c文件系统接口) 以及系统调用接口 (APIs) 来进行电源管理。内核硬件无关层提供电源管理逻辑控制，针对任务负载情况选择反映当前任务电源状态的电源操作点 (相关可控的硬件参数) 。内核硬件相关层主要对应系统的各种总线和设备时钟电源参数管理，并管理多种设备的参数约束。
·设备驱动电源管理
在某些设备闲置时可以被主动关闭，从而节电。在2.6内核中需要实现总线以及设备的电源管理支持，在驱动中需要实现设备驱动的suspend/resume函数。
关闭一个设备，其驱动的suspend方法需要两个不同的调用，一个用来保存状，另外一个用来关闭设备电源。相反，resume方法需要一个调用用来给设备供电，另一个调用来恢复设备的状态。在关闭一个总线设备时必须关闭所有的下一级子设备。相反地，重新使能总线设备时，必须先使能根设备，然后再使能子设备。
·用户层电源管理策略
嵌入式系统如何做到有效的平台级能耗管理需要在内核提供的机制上实现一个智能化的管理软件，监控系统电源状态，处理相应电源事件，执行针对特定应用制定的管理策略。现有的Linux ACPI和APM的后台驻留进程，可以供嵌入式系统实现参考。商业的嵌入式linux公司MontaVista在其Moblinux 4.0以后的版本也提供一个用户态的电源管理策略和界面。
嵌入式操作系统电源管理实现比较
嵌入式操作系统的电源管理功能实现结构中，主要可以分为核心层、接口层、应用策略管理层。核心层需要提供一个体系结构无关的电源管理框架，感知系统负载，进行系统电源状态管理。核心层还需要一个体系结构相关层，提供硬件相关的电源状态管理，例如进行电压/频率调节及相应的约束管理。核心层还需要提供一个用户编程接口，用户层通过编程来利用系统提供的电源管理机制。并且根据不同的应用需求编制智能化的管理策略。
在电源管理功能上大致可以分为 (1) 系统级电源管理， (2) 动态电源管理， (3) 设备电源管理等三类。操作系统检查任务负载情况，如果没有需要运行的任务，则一般进入空闲等节能状态，等待唤醒。可以在空闲一段时间后进入深度睡眠，挂起到RAM中或者硬盘上。在运行任务期间，操作系统还可以利用硬件提供的电源管理功能动态调节芯片运行电压和频率，对系统进行更加细致的电源管理。操作系统还应该能够管理闲置的设备，关闭设备并提供恢复手段。
上面我们分析的三种典型的嵌入式操作系统在电源管理方面是各有特色;TinyOS简练小巧有基本的内核态和系统级的电源管理功能，但是相对比较简单;WindowsCE电源管理模块结构清楚，特别有提供了应用程序的接口，但是到目前看到的为止Windows CE/Mobile开放给用户的电源管理功能还待提升;Linux是开源代码，具有丰富的硬件电源管理支持，策略和动态的电源管理功能，但是相当实现的零散和分散，应用软件的接口不清晰和标准，需要用户作的工作比较多。
总结和展望
嵌入式系统软件 篇9
近年来计算机在各行各业的应用迅速发展,各种应用系统软件趋于全面、成熟和完善。但随着计算机技术的迅猛发展,新的软、硬件产品不断面世,对于应用系统的相对稳定和计算机应用平台的不断提高,实际中要求原来的应用系统要在新的环境下运行,这就使得应用系统的移植工作显得愈来愈重要。
在嵌入式系统领域,软件移植的情况很多,主要是基于基于嵌入式处理器的原因和基于操作系统的原因[1]。在嵌入式系统领域,由于硬件的更新换代和软件技术的不断发展,经常需要将遗留系统进行软件移植以适应新的软硬件平台。嵌入式系统的软件移植分为裸机系统的嵌入式系统软件移植,基于嵌入式操作系统的应用软件移植和裸机软件移植到嵌入式操作系统上3种情况。
1 软件移植问题和方法
裸机系统,即没有操作系统支持的软件系统[1]。裸机系统在嵌入式微处理器发生变化时,软件需要在新的体系结构不同的嵌入式处理器硬件平台上运行,这时就只能进行软件移植。将没有操作系统的嵌入式系统运行在新的嵌入式处理器硬件平台上,如果软件的设计采用汇编语言,那么移植就等于重新开发,而且难度往往高于新系统开发。当然,如果软件主要由C语言开发,是可以考虑软件移植问题的。下面将从几个角度来分析软件移植问题。
1.1 程序理解
程序理解包括在各种抽象层析上,建立基本软件的思维模型,抽象的层次从代码的模型到基本应用领域的模型各有不同。程序理解技术可以包含代码结构、功能和架构3个抽象层次[2]。
代码结构表示包括源代码和制品,例如通过解析和例程分析活动所获得的抽象语法树和流程图。要恢复一个系统架构,首先要理解源代码和其他现有制品。在这个过程中,可以应用很多活动,如手工代码阅读,通过逆向工程工具解析源代码,产生各种报表,包括调用图,数据和控制流、结构图、交叉引用信息,以及数据类型和变量实例的定义和使用。功能层表示即为描述程序函数、数据和文件的关系,通过理解得出程序的功能模块划分和模块间调用关系。架构层表示更加抽象,把函数层和代码层装配成相关组件或者概念的子系统。
1.2 开发工具
嵌入式软件开发工具包括编译器、汇编器、链接器和调试器。嵌入式开发工具运行在一个与目标硬件平台不同的主机上,对于裸机系统,用户必须提供自己的硬件平台知识给这些工具,这样才能生成在具体硬件平台上运行的二进制映像文件。
嵌入式软件开发工具往往因开发厂商、支持语言标准和工具版本而出现很大差异,这些差别主要体现在如下几个方面。
1.2.1 数据长度
标准C语言的数据类型是不可移植的,如int类型,在不同编译器中长度不同。在移植的过程中,为了兼容性,要正对编译器改写数据类型以保持程序的数据宽度与原系统相同。为了程序有个很好的移植性,应尽量使用可移植的数据类型,或者自定义数据类型。例如自定义数据类型:
typedef unsigned char UINT8;
typedef unsigned char BOOLEAN;
typedef unsigned char UINT8;
typedef signed char INT8;
typedef unsigned short UINT16;
typedef signed short INT16;
typedef unsigned int UINT32;
typedef signed int INT32;
typedef float FP32;
typedef double FP64;
如果使用较新C99编译器,则可以使用C99标准建立的一套有符号和无符号的定长整型数据类型,这些定义包括在新的头文件stdint.h中。最新定义的类型名字是:
8位 int8_t,uint8_t
16位 int16_t,uint16_t
32位 int32_t,uint32_t
64位 int64_t,uint64_t
1.2.2 变量的作用域和类型转换
不同的编译器对变量作用域的表现可能出现差异,编译的过程中有可能出现重复定义错误,对于这种错误,可通过加条件分支予以解决;不同的编译器对类型转换的表现也会可能存在差异。对于较老的编译器,不匹配类型转换可能会提示警告信息,而新的编译器可能会出现编译错误。对于编译时出现的类型不匹配错误,可强制加上类型转换予以解决。
1.2.3 关键字和内建函数
嵌入式软件有时会使用特定编译器定义的过时或者非标准的关键字,例如far关键字,是C/C++语言在16位系统中用以标明指针是个远指针的修饰符,在32位系统中已经废止不用了;interrupt关键字,是CL编译器用于声明中断服务子程序的,而RealView编译器使用的是_irq关键字。
内建函数是与编译器相关,作用应该跟关键字一样的函数,所以内建函数也会有移植问题。例如CL编译器的中断使能内建函数_enable、中断禁止内建函数_disable,而RealView编译器对应的内建函数为_enable_irq和_disable_irq。如果显式申明的函数与内建函数同名,内建函数将会被覆盖。所以,当原系统使用的内建函数在新的编译器中不存在时,可以声明定义与内建函数同名的函数,实现内建函数功能。
1.2.4 汇编指令
汇编指令是汇编语言中使用的一些操作符(如MOV,INC,LOOP)和助记符,还包括一些伪指令(如assume,end)。不同架构的CPU汇编指令会用很大差异,即使是针对相同架构CPU不同的汇编器,对汇编代码的处理也是不同的。所以,对于系统中使用汇编程序的地方,需要在理解的基础上针对新的硬件平台和编译器重新实现。实现的过程中,除了启动代码,尽量使用高级语言,以提高可移植性和可维护性。
1.2.5 链接器脚本
用于执行从可重定位程序到可执行的二进制映像转换的工具称作为定位器[3]。在一些情况下,定位器作为链接器的一部分。定位器所需要的内存信息一般以链接器脚本的形式传递给它。这样的脚本用于控制重定位程序中的代码和数据段的准确顺序,以及每部分的物理地址信息。通常链接器也提供附加命令选项来指示链接器去执行定位操作。
由于不同的开发工具的链接器脚本的语法和格式不尽相同,对于软件移植来说,通常需要参考工具文档或者实例重新编写链接器脚本文件。
1.2.6 依赖库
使用C/C++语言编写的嵌入式软件,会依赖标准程序库,也会可能依赖第三方程序库。编译器会配套提供标准程序库,但也可能提供比较实用的非标准程序库。如果程序使用了非标准程序库,在移植的过程中,需要替换或重新实现这类函数调用。由于使用标准库时最终生成的映像文件会比较大,对于存储有限的嵌入式系统,可以自己实现用到的标准函数,这样链接器会自动链接用户自己实现的标准函数。
1.3 CPU架构
CPU架构是CPU厂商给属于同一系列的CPU产品定的一个规范,主要目的是为了区分不同类型CPU的重要标示。主流的CPU架构有X86架构、ARM架构(ARM架构有细分V4、V5等多个指令体系,不同体系在架构上也是不同的)、PowerPC架构、MIPS架构和SPARC架构等。不同CPU架构的差异对软件移植的影响主要体现在中断系统、I/O空间映射和字节序问题三个方面。
1.3.1 中断系统
中断是指CPU中止正在执行的程序,转去执行请求CPU为之服务的内、外部事件的服务程序,待该服务程序执行完成后,又返回到被中止的程序继续运行的过程[4]。不同CPU架构,中断处理的基本过程是一样的:申请中断,中断判优,中断响应,中断处理及中断返回。但由于中断系统硬件设计上的差异,中断实现细节上有很大区别。
1.3.1.1 异常类型差异
不同CPU架构所支持的异常类型不同,例如X86系统的异常类型按中断源分类可分为内部中断(软件中断)和外部中断(硬件中断),其中内部中断有除法出错、溢出中断、INT n指令中断、单步中断、断点中断,外部中断分为可屏蔽中断INTR和非屏蔽中断NMI;ARM体系结构所支持的异常类型与X86系统有很大不同,支持7种异常类型的异常处理:复位、未定义指令、软件中断、指令预取中止、数据中止、外部中断和快速中断。
1.3.1.2 中断向量表差异
不同CPU架构的中断向量表也可能存在差异,例如X86中断向量表中存放的是ISR中断服务程序的地址CS:IP,中断响应时会根据中断类型号把相应的CS:IP加载到CPU中,实现跳转到ISR中断服务程序中;ARM中断向量表中存放的是一条跳转指令,实现跳转到ISR中断服务程序中。X86前1Kb用作中断向量表,每个中断占用4B用于存放CS:IP,因此可存放256个中断;每个外部中断的中断向量终端类型号未固定,可通过初始化8259进行设置;ARM中断向量已经固定,只存放了7个异常中断和1个保留向量,具体硬件的中断向量都是保存在中断控制器的某个寄存器中。当硬件产生中断时,CPU查询中断控制器完成中断服务跳转。
1.3.1.3 中断处理过程
中断处理过程大致分为两个阶段,体系统一的处理过程和体系独立的处理过程[5]。所谓体系统一的处理过程指的是同一系列芯片的中断处理方法是一致的,而体系独立的处理过程则是指不同款芯片的处理方法完全不同。
体系统一的处理过程又可分为硬件控制部分和软件控制部分。当一种异常发生时,硬件自动执行的动作即为硬件控制部分,如ARM处理器在异常发生时执行的返回地址、标志位的保存,模式的切换,PC的跳转等操作。完成硬件控制部分后,就进入了软件控制部分,这部分工作全权交给了程序员。软件控制部分主要是中断进入时的保护现场和中断离开时的恢复现场操作。
体系独立的处理过程主要包括设备寄存器和中断控制器的操作,如清除设备寄存器相关位以避免中断重复触发,读设备状态寄存器判断中断请求原因,写中断控制器回复中断应答信号。
由于不同架构CPU在异常类型、中断向量表以及中断处理的体系统一处理过程中的软件控制部分和体系独立处理过程的差异,程序在实现中断过程时需要针对具体的CPU平台,建立、配置中断向量表,并为每个类型中断安装中断服务子程序,编写体系统一处理过程中的软件控制部分和体系独立处理过程的程序。
对于体系统一处理过程中软件控制部分的保护现场和恢复现场这部分的程序,有些编译器包含中断关键字或者一些类似的机制,标记中断服务程序使之在编译时自动添加保护现场和恢复现场的代码。带有中断关键字的实例代码如下:
interrupt void interruptServiceRoutine(void)
{
/* 检测中断原因 */
/* 应答中断 */
/* 处理中断 */
}
RealView编译器使用_irq关键字声明的函数自动添加的汇编代码示例如下:
STMFD {r0-r3,r12,lr};保护现场
……
LDMFD {r0-r3,r12,lr};恢复现场
SUBS pc, lr, #4;中断返回
有些编译器不支持类似关键字,可能会要求一个特定编译器的#pragma来声明中断服务程序。GNU编译器GCC使用第三种方法,包含特定编译器关键字_attribute_,作为可选参数,如下所示:
void interruptServiceRoutine() _attribute_((interrupt ("IRQ")));
如果编译器不支持自动添加保护现场和恢复现场代码,或者编译器自动添加的代码不能满足实际系统需要时,如一般ARM编译器自动生成中断代码不支持中断嵌套等复杂中断处理过程,则需要自定义、添加中断进入和退出汇编代码。
1.3.1.4 全局中断使能与禁用
裸机系统必然涉及全局中断使能和禁用,特别在实现数据在处理中断服务程序和主程序之间的共享,例如主函数和中断服务函数都使用了gIndex变量,实例代码如下:
int gIndex = 0;
interrupt void interruptServiceRoutine(void)
{
gIndex++;
}
int main(void)
{
while(1)
{
interruptDisable();
if(gIndex)
gIndex--;
interruptEnable();
}
}
一般处理器会有一个寄存器控制全局中断,如ARM在当前程序状态寄存器(CPSR)中有两个禁用所有中断的全局位。由于一般不能使用C语言直接访问全局中断标志,所以需要编写汇编代码来使全局中断可用或者禁用。有些编译器已经提供中断使能和禁用内建函数,直接调用即可。但是在使用时要注意使用条件,例如RealView编译器对应的内建函数_enable_irq和_disable_irq只能在非用户模式/特权模式下才有效。因为中断使能和禁用操作需要修改程序状态寄存器的控制位,而对程序状态寄存器的控制位操作只能在非用户模式下才能完成。
1.3.1.5 中断嵌套问题
中断嵌套问题的实现细节也是因不同CPU而异的。例如X86系统的定时器中断程序:
void interrupt timer()
{
//应答中断
outpw(INT_PIC_BASE,TIMER_EOI_VAL);
_enable(); //开中断
//执行时间较长的代码
//…
_disable();//关中断
}
对于使用interrupt关键字标记的函数,函数的开始和结束位置会嵌入中断进入时的保护现场代码和中断离开时的恢复现场和中断返回代码,整个函数运行在中断禁止环境下,所以如果中断函数的逻辑占用时间较长的话,会影响下一次中断请求的响应时间。所以上面timer中断函数中使用_enable和_disable函数在执行时间较长的代码之前使能中断,允许中断嵌套,待执行完后再关闭中断,这样就解决了中断嵌套问题。
对于X86处理器,在使用指令CALL进行子程序调用时或者是中断时,CPU硬件自动将返回地址或中断处地址压栈到堆栈区(由SP指向),在执行RET或IRET指令(中断返回指令),又自动地把返回地址或中断处地址弹回到程序寄存器PC中。而ARM处理器使用R14寄存器保存子程序调用和程序中断时存储程序变化处的地址。由此可见,X86处理器是通过堆栈来完成程序的链接,而ARM是通过R14来完成程序的链接。
对于ARM处理器,中断程序运行在中断模式下,寄存器R14_irq作为私有寄存器,保存着被中断处的返回地址。将它保存到堆栈当中去,目的是当中断模式发生函数调用时,该寄存器可以用开保存函数返回值。但如果此时另一个中断恰好发生,R14_irq就有要保存新的中断处理程序返回的地址,原来的返回值便会丢失,导致系统紊乱。所以,X86的中断嵌套方法必须进行响应的适应性改造才能移植到ARM平台上。改造的主要思路是将运行在中断模式下的中断服务程序切换到主程序运行所处的模式(为了能使能、禁止全局中断,主程序一般运行在SYS模式)或者是SVC模式。实例代码如下:
timer_asm_irq_handler
;保护现场
SUB lr, lr, #4
STMFD sp!, {lr}
MRS lr, SPSR
STMFD sp!, {r0,r1,lr}
;切换至SYS模式
MSR CPSR_c, #SYS_MOD:OR:I_BIT
;保存SYS模式主程序已用寄存器值
STMFD sp!, {r1-r4, r12, lr}
;跳转至中断处理代码
BL timer_c_irq_handler
;恢复SYS模式主程序已用寄存器值
LDMIA sp!, {r1-r4, r12, lr}
;切换回中断模式
MSR CPSR_c, #IRQ_MOD:OR:I_BIT
;恢复现场,返回主程序
LDMIA sp!, {r0,r1,lr}
MSR SPSR_cxsf, lr
LDMIA sp!, {pc}^
对于待移植系统平台存在而系统目标平台不存在的异常,系统目标平台可不作处理,若是程序可避免异常,可以通过增加程序校验分支代码。例如X86架构存在而ARM架构不存在的除法出错异常,在ARM程序中不需要增加这类异常的中断服务子程序,只在进行除法计算时,嵌入除数判0逻辑,除数为0则中止程序(ARM的RealView编译器会自动在除法计算指令后嵌入除数判0逻辑,不需要用户处理)。
1.3.2 I/O空间映射
外设中的寄存器(包括数据寄存器、状态寄存器和控制寄存器)被称为I/O端口,外设中的内存被称为I/O内存。二者合起来统称为I/O空间[6]。根据访问外设寄存器的不同方式,可以把 CPU分成两大类。
一类CPU(如M68K,Power PC,ARM等)把这些寄存器看作内存的一部分,寄存器参与内存统一编址,访问寄存器就通过访问一般的内存指令进行,所以这种CPU没有专门用于设备I/O的指令。这就是所谓的“I/O内存”方式。
另一类CPU(如X86)将外设的寄存器看成一个独立的地址空间,所以访问内存的指令不能用来访问这些寄存器,而要为对外设寄存器的读写设置专用指令,如IN和OUT指令。这就是所谓的“I/O端口”方式。
运行在使用I/O端口方式的处理器平台上的软件使用IN和OUT指令实现I/O访问,对于这类代码,要移植到使用I/O内存方式的处理器平台,需要在外设内存映射完成后,替换为C语言的直接内存访问代码。
1.3.3 字节序问题
字节序是一个系统属性[3],该属性指出处理器存储内部数据的方式:小端方式和大端方式。采用大、小端方式对数据进行存放的主要区别在于存放的字节顺序,大端方式将高位字节存放在低地址,小端方式将低位字节存放在低地址。采用大端方式进行数据存放符合人类的正常思维,而采用小端方式进行数据存放利于计算机处理。X86系列处理器都是使用小端方式。Sun的SPARC、Motorola的68K和PowerPC家族都是大端方式。一些处理器甚至在寄存器里有一个比特位,该比特位允许程序员选择期望的字节序。
单一的系统中不会涉及字节序的问题。它只有在两个计算机试图通信的情况下才涉及到。每一个处理器和通信协议必须选择一种类型的字节序。因而,如果具有不同字节序的两个处理器通过存储器设备进行通信,那么他们将会发生冲突。
为了避免字节序问题,移植的原系统和目标系统的处理器要尽量使用同一种字节序,实在无法保持一致,就只能编写程序对需要传递的数据进行模式转换。
1.4 总线和外设
总线是CPU与存储器,不同外部设备之间通信,或不同系统之间通信的机制,是数据、地址和控制信息传达的公共通道[7]。对总线的评价主要依赖3个参数:总线宽度、总线频率和总线带宽,所以移植目标平台与原平台在总线上应保持这3个参数的兼容性才符合移植条件。
由于嵌入式处理器在一个芯片上集成了多种I/O设备接口,这使得以嵌入式处理器为核心的嵌入式系统外设的接口方式主要是直接利用嵌入式处理器芯片内集成的现有接口,配合少量简单的外围接口电路实现外设的硬件接口功能;或是采用嵌入式处理器芯片的GPIO(General Purpose I/O)口,利用GPIO的可编程性,实现某种外设的接口扩展。但是对于比较复杂的嵌入式系统,需要使用嵌入式处理器芯片未集成或者利用GPIO扩展不太方便的外设接口,必须通过外部扩展总线技术利用系统总线对I/O接口进行扩展。
对于片内设备或者是片内设备接口,软件移植过程中只需要针对移植目标平台的特点替换掉外设的配置和操作函数;而对于通过外部总线扩展的片外设备或者外设板卡,由于使用到了外部扩展总线技术,需要在嵌入式处理器提供扩展总线控制器的条件基础上,配置扩展总线控制器,完成地址映射。这样嵌入式处理器才可通过地址直接访问片外设备或者外设板卡。
2 在叶式准直仪控制系统中的应用
多页准直器系统(MLC, Multileaf Collimator),也称叶式准直仪控制(LCC, Leaf Collimator Control)系统,是医用电子直线加速器的标准配置,主要用于适形放疗中,也可部分取代普通放疗的挡铅。移植项目要求更换原系统80186主板和SMP16总线以及基于SMP16总线技术的外设板卡,使用基于ARM920T内核的AT91RM9200微控制器和基于PC104总线的外设板卡实现原系统功能。将原系统的软件部分由16位80186平台迁移到32位的ARM9平台上,实现定时器、看门狗、串口以及PC104外设板卡等设备的配置、操作和中断处理,使得整个系统能够按照原系统的逻辑正常工作。
移植主要有以下几个关键过程:
a. 注释掉所有汇编或者混合编程代码,通过比较16位CL编译器和ARM的RealView编译器的区别,针对区别修改软件的数据类型、关键字、函数依赖等,使软件在RealView编译器下能顺利编译;
b. 编写启动代码,在开发板上能顺利运行并引导主程序后,对软件的中断管理、I/O访问和外设访问等关键部分进行改写、测试和运行;硬件设备相关的代码,在不改变API的前提下重新实现;
c. 对注释掉的汇编或者混合编程代码进行理解,使用C语言进行改写非硬件逻辑;
d. 移植后的软件经过配置、编译运行到最终生产环境,实施系统测试,与原系统的运行状态比较、分析,解决移植后的兼容性问题以及新硬件环境带来的新问题。
3 结束语
对于嵌入式系统移植工作的开发者来说,需要对原系统和移植目标系统的软硬件环境有个非常充分的认识,然后结合软件移植的一般问题和方法,逐步解决。移植的过程中,需要应用软件工程的思想和方法,管理工作过程,保证移植软件质量,提高软件的可移植性,自下而上,循序渐进,增量地开发、测试和部署。如果毫无章法,在出现问题时会很难快速定位,影响项目进度。
裸机嵌入式系统的软件移植问题和方法,不仅能够指导裸机软件的移植过程,而且对与嵌入式操作系统的移植工作也有一定的指导意义。但是。若要将基于裸机开发的嵌入式系统移植到操作系统环境,则需要针对操作系统带来的硬件无法直接访问限制对裸机软件进行再工程改造,分离应用和硬件逻辑。移植裸机软件到操作系统环境,有利于降低软件系统的维护成本,所以移植裸机软件到操作系统环境这一方面的研究同样具有很高的理论研究价值和应用价值。
参考文献
[1]郭荣佐,王霖.嵌入式系统原理[M].北京:北京航空航天大学出版社,2008.
[2]罗伯特.C.塞克德著,梁海华译.遗留系统的现代化改造——软件技术、工程过程和业务实践[M].北京:清华大学出版社,2003.
[3]巴尔安,马萨.嵌入式系统编程——使用C和GNU开发工具[M].O'Reilly Media,Inc,2006.
[4]陈继红,徐晨,王春明,等.微机原理及应用[M].北京:高等教育出版社,2011.
[5]李无言.一步一步写嵌入式操作系统——ARM编程的方法与实践[M].北京:电子工业出版社,2011.
[6]戴梅萼,史嘉权.微型计算机技术及应用[M].北京:清华大学出版社,2008.
嵌入式系统软件 篇10
目前为止,有些厂商采取先预先加密软件代码,写入存储器中,执行时,通过软件解码来实现对代码的保护,但是这种方法效率低,成本高,实用性比较低;现有的一些硬件加解密系统,只能保护有限类型的NAND-Flash存储器中的代码,并且系统中的密匙一旦固化就无法改变。针对这些局限性,本文提出了一种全新的嵌入式产品软件代码保护系统,该系统适用于目前通用的基于I2C、SPI总线的EEPROM和Flash;以及主流厂商的NAND-Flash。
1 嵌入式软件代码保护系统构成
嵌入式软件代码保护系统由两部分组成:PC机上运行的TDES加密软件和硬件电路中隔离处理器与软件代码存储器直接通路的代码保护芯片组成,如图1所示。PC机上的TDES程序对嵌入式软件代码进行加密,生成密文形式的数据,并写入软件代码存储器中,供嵌入式系统使用;同时通过GPIO口模拟I2C或者SPI通信协议,对代码保护芯片中,存放相关重要数据的EERPOM区域进行配置:达到诸如更改代码保护芯片中TDES的密匙的目的。
代码保护芯片内嵌于嵌入式系统的硬件电路中,用户可以选择隔离处理器和指令代码存储器之间的通路:所有写入存储器的数据将被加密后才写入其中; 所有从存储器中读出的数据将被解密后才送回给CPU执行;用户也可以选择不隔离处理器和存储器之间的通路:读写操作将不会进行任何加密和解密。
2 代码保护芯片设计
2.1 内部结构简介
代码保护芯片隔断了原有嵌入式系统处理器和软件代码存储器之间的直接通路,如图2所示。该系统主要分成主从I2C总线接口模块、主从SPI总线接口模块、Nand-Flash通信模块以及核心控制模块。
如果用户选择I2C接口,芯片将通过I2C总线和存储器进行通信,如果用户选择SPI接口,芯片将通过SPI总线和存储器进行通信,否则芯片将通过NAND-Flash模块和存储器进行通信。
如果用户选择加密模式,那么处理器和存储器之间的通路将被隔断,所有准备写入存储器的数据经过TDES加密后才写入其中,所有从存储器读入的数据经过TDES解密后才送回至处理器执行;如果用户选择不加密模式,那么处理器将直接和存储器进行通信,代码保护芯片将不启动任何加密/解密操作。这种设计方式,使得芯片可以适用于更多的嵌入式系统,同时也给予用户最大限度的灵活性。
2.2 核心处理模块
核心处理模块是整个系统的核心部分,如图2所示:主要完成指令译码、控制FIFO的读写、控制TDES加密/解密的运行,控制I2C、SPI、通用Nand-Flash模块和外界的数据接收和传送以及对内部EEPROM进行操作。当代码保护芯片接收到处理器发出的读数据命令后,将从存储器中预取64字节的数据,然后进行TDES解密。解密的同时,芯片再次从存储器预取64字节的数据,写入内部的另外的64字节FIFO中:乒乓FIFO架构的设计以及采用流水线技术的TDES加密/解密,大大提高了代码保护芯片的效率。
2.3 芯片内部EEPROM存储数据内容介绍
由于存储器出自不同的厂商,因此对于存储器的读写等命令存在着一定的差异,为了满足系统对不同厂商芯片的适用性,该代码保护芯片内部内嵌了一个64字节的可读写EEPROM,用来存放一些特殊的数据,用户可以通过特殊的命令,达到对相关地址的写操作。相关地址存放数据如下所示:
地址0x00至0x05:分别代表SPI读操作指令代码、SPI写操作指令代码、SPI写状态寄存器指令代码、SPI读状态寄存器指令代码、SPI关闭写操作指令代码、SPI允许写操作指令代码。
地址0x06至0x07:分别代表I2C器件地址、I2C有效地址字节数。
地址0x08至0x0D:分别代表NAND-Flash读操作指令代码1、NAND-FLASH读操作指令代码2、NAND-FLASH读操作指令代码3 、NAND-FLASH页编程操作指令代码1、NAND-FLASH页编程操作指令代码2、NAND-FLASH有效地址字节数。
地址0x0E至0x25: 分别代表24字节的TDES密匙。
地址0x25以后的区域为保留区域,预留给将来使用。
3 代码保护芯片设计实现
3.1 综合结果
本文设计的嵌入式软件代码安全保护芯片,使用Verilog语言进行编程,并进行了功能验证,使用Quartus-7.2进行了综合及布局布线,并完成了后仿真。实验结果表明,整个系统适用的时钟工作频率介于4MHz和96MHz之间,满足目前主流的嵌入式系统的数据读写速度。使用Stratix II系列的EP2S15F484C3器件进行了综合,综合结果见图3:
3.2 系统性能分析
3.2.1 基于I2C/SPI接口的存储器
当代码保护芯片第一次从处理器接收连续读操作指令后,由于代码保护芯片需要从存储器预取64字节,所以必须等待1.28ms(和存储器通信的频率为400K);因为代码保护芯片采取流水线技术的TDES,所以第51个时钟周期后[3],解密后的数据就可以传送回处理器,由于在向处理器传送数据的同时,代码保护芯片也同时从存储器接受数据,因此,处理器不需再等待额外的时间,就可以连续的从代码保护芯片接受解密后的指令。因此当系统时钟工作频率为4MHz,处理器必须等待1.29275ms后,才可接收数据;当系统始终工作频率为96MHz,处理器只须等待1.28053ms后,就可接收数据。
3.2.2 Nand-Flash存储器
目前主流的Nand-Flash器件,其最大的串行读出数据时间为50ns,预取64字节,必须等待3200ns,TDES解密时间同节3.1.1,因此当系统时钟工作频率为4MHz,处理器必须等待15.95us后,才可接收数据;而当系统时钟工作频率为96MHz,处理器只须等待3.73125us后,就可接收数据。
本文设计的嵌入式软件代码保护系统,已经成功地对国家半导体公司的CAT1026芯片存储器进行解/加密读写操作,虽然基于TDES的加密和解密的过程降低了嵌入式系统的运行速度,但是以少量降低性能换取更高的产品安全性,对于用户来说,是完全可以接受的。它对于保护公司的知识产权、提高产品的市场寿命有着重要的、积极的意义,有着极为广泛的应用前景。
参考文献
[1]National institute of standards and technology.Data Encryption Standard(DES).FIPS PUB 46-3,1999.
[2]SCHAFFER T,GLASER A,FRANZONP D.Chip-package co-implementation of the triple-DES processor,advanced Packa-ging.IEEE Transaction 2004,27(1):194-202.
[3]王莆莉,陈健,郭晋亮.3-DES IP核的VerilogHDL设计[J].电子技术应用,2007,(1)
[4]君凯,吴延军.嵌入式计算机加密存储系统研究.电子技术应用.2007,(10)
[5]KiSeun Kwon,YoungMinYi.Embedded Software Generation from System Level Specification for Multi-tasking Embedded Sys-tems.ASP-DAC,2005.
嵌入式软件可靠性模型研究 篇11
【关键词】嵌入式软件；可靠性模型
由于嵌入式软件自身具有诸多优势，因此在社会的各个领域得到了广泛应用，但是，如何根据嵌入式软件的基本特征，建立起可靠模型是目前研究工作的核心问题。在一些涉及国防以及国家安全的领域，例如航空航海导航软件，必须保证其安全可靠的运行，因此通过构建嵌入式软件可靠性模型来提高软件系统的稳定性是研究的重点问题。
一、软件可靠性模型概述
软件可靠性模型最初在上个世纪七十年代出现，在这个阶段，出现了很多比较具有研究意义的软件可靠性模型，对于其发展有深刻的影响。在最早的时候，软件可靠性就是指特定的软件可以准确无误地实现其基本功能，最大程度降低误差。美国的标准化研究院最初采纳“软件可靠性”的定义作为相关概念的国家标准。我国于1989年采用了这个定义，即软件可靠性指在特定的条件下，在要求的时间限度内，软件不发生失效的概率，这是概率中的一种函数，进行系统数据的输入以及使用，同时也是软件中自身存在的缺陷函数。系统的数据输入会确定能否遇到已经存在的缺陷。
二、软件可靠性模型的分类
1.根据建模对象进行分类
（1）静态模型
根据建模对象进行分类，当建模对象与运行的时间毫无关联时，这时候产生的数据以及信息，就被称为静态模型，例如软件复杂的参数。静态模型的基本特点是可以直接对软件的缺陷进行估计，而省去了进行软件测试的程序，这种模型主要应用于最初的软件开发时期。当软件可靠性设计逐步成为研究的热点，静态模型的优势也凸现出来。
（2）动态模型
建模对象是与运行时间有关联的数据以及信息，这种模型成为动态模型。例如Shooman模型和Schick-Wolverton模型。
2.根据模型假设进行分类
（1）随机过程模型
随机过程模型主要内容为马尔科夫过程模型。所谓马尔科夫过程，就是代指一个软件系统失去功效的过程，其代表模型为Jelinski-Moranda模型以及Schick-Wolverton模型。其次是非齐次泊松过程模型，通过对于时间的间隔划分，每个间隔内的数值变化即为随机变量。除了以上的两种，典型的随机过程模型还有MUSA时间改写模型，通过对于CPU时间为衡量标准，建立不同时间，并实现软件程序的可靠性以及测试的整个过程。
（2）非随机过程模型
非随机过程模型主要包括了lv模型为典型的贝叶斯雷模型，以及在特定的软件中，设置固定数值的缺陷值，并通过之间的数量关系来估测软件的缺陷范围的种子法模型，包括NELSON模型，都是属于非随机过程的模型。
三、嵌入式软件可靠性模型研究
关于嵌入式软件可靠性的研究，至今还没有专门的模型，在各个领域中应用的仍然是目前以及开发出来的模型，即选择特点最趋近于嵌入式软件的基本特征的模型。因此，在嵌入式软件可靠性模型研究中，要从以下方面展开。
1.基于假设条件的嵌入式软件可靠性模型
嵌入式软件区别于其他类型的软件最大的特征就在于测试环境以及运行环境。嵌入式软件模型的相关内容研究发展比较晚，但是由于在现实生活中的需求比较迫切，因此也逐步研究出一些可行的方法。
首先是通过环境因子来改变软件的测试环境以及运行环境，以此来最大程度提高软件可靠性评估的准确性，利用一种与环境因子联系比较密切的软件可靠性模型，将环境因子设为一个不确定的变量，由此观测在软件模型运行的各个阶段，对运行产生影响的各种因素。
除此之外，还有一种方式，通过对于加速因子的测试，来调解测试环境和运行环境之间的差异性，并将测试环境和运行环境因为各种因素而失效的具体数值记为一个有效参数，在这个方法中，需要将测试加速因子视为与时间没有关联的常数量。
第三种方式是通过移动点技术，来分段评估嵌入式软件的可靠性。这种方法在测试中，极其容易受到各种因素的影响，其中包括软件运行环境、测试的方式以及内部资源的配置等等。无论哪个因素发生变化，都会导致软件的可靠性改变。由此可见，移动点方法的核心就是通过对于数据变化的分析，来进行数据的分段整合。
2.基于智能算法的嵌入式软件可靠性模型
经上文叙述，可见嵌入式软件可靠性的意义十分重大，因此对于可靠性的预测需要达到一个比较精确的标准。在上个世纪九十年代，有学者成功利用神经网络，来整合多个数据集合的嵌入式测试软件，并极大地提高了可靠性。在这项研究中，他们在对于软件的可靠性进行测试的整个过程里，通过神经网络的相关理论来建立的嵌入式软件可靠性模型的预测精确度，明显高于其他类型的的模型。因此，在基于条件假设的嵌入式软件可靠性模式研究，逐步与神经网络相结合，共同来提升软件的可靠性。目前，神经网络已经应用在各个领域，解决预测相关问题，其中包括预测销售、预测有价证券变化、预测市场行情等等。因此，在嵌入式软件可靠性模型的研究中，结合神经网络技术来进行模型构建以及可靠性提升，具有广阔的发展空间。
结束语
软件可靠性模型可以有效实现对于软件的可靠性评估与管理，而嵌入式软件因为自身具有比较高的安全性以及实时性，尤其在比较典型的基于假设条件的嵌入式软件可靠性模型和基于智能算法的嵌入式软件可靠性模型中，通过改变软件的运行环境、测试环境、移动点技术，而且结合了神经网络技术进行预测，多方面提升了嵌入式软件模型的可靠性，具有广阔的发展空间。
参考文献
[1]闫雪丽.嵌入式软件可靠性模型研究[D].哈尔滨工程大学，2011，12.
[2]王洪鹏.基于UML的嵌入式软件可靠性和安全性研究[D].华东理工大学，2010，12.
[3]刘斌，高小鹏，陆民燕，阮镰.嵌入式软件可靠性仿真测试系统研究[J].北京航空航天大学学报，2010，08（30）.
[4]王荧.嵌入式软件可靠性测试工具的研究与实现[D].电子科技大学，2009，04.
[5]王世明.基于NHPP的软件可靠性模型研究[D].武汉理工大学，2011，05.
[6]蒋炎坤，愈强，许健.船用嵌入式软件可靠性及其参数研究[J].电子产品可靠性与环境试验，2011，01（08）.
嵌入式测姿系统软件的模块化 篇12
英文引用格式：Tian Anqi,Jin Tian.The modularization of embedded attitude determination system software[J].Application of Electronic Technique,2015,41(7):26-29.
0 引言
随着全球定位系统的发展，姿态测量技术逐渐成为卫星导航应用领域研究的热点。姿态测量一般应用于卫星、航天器、载人机、无人机等高动态的载体上，这些载体要求姿态测量系统具有精度高、实时性强、安装方便等特点。嵌入式系统是一种完全嵌入到受控器件内部，为特定应用而设计的专用计算机系统，具有响应时间短、系统内核小、可扩充、可移植、实时和可靠性较强等优点。ARM处理器体积小，功耗低，成本低，性能高，执行效率高。目前，嵌入式测姿系统软件趋于成熟，但由于功能复杂，程序冗长，可操作性低。
近年来，利用全球导航卫星系统（Global Navigation Satellite System,GNSS）接收机载体进行姿态测量的技术已经逐步成熟，但随着接收机板卡种类、导航系统种类、姿态算法种类的增加，对嵌入式测姿软件的实时性、可用性以及可扩展性提出了更高的要求。2008年，荷兰代尔伏特理工大学实现了GPS单频单历元姿态解算系统[1]。2012年，该大学实现了多天线GNSS测姿系统[2]。2012年，澳大利亚科廷大学进行了多星座测姿试验[3]。2008年，北京理工大学设计了单基线测姿系统，并进行静态和动态试验[4,5,6]。2007年～2009年，上海交通大学完成姿态测量系统样机的研制[7,8,9]。2012年，中国卫星导航定位应用管理中心与54所联合研制了GPS卫星导航系统多频姿态测量系统[10]。
此外，国内外几大GNSS厂商均有相应的测姿产品。美国Trimble公司的BX982利用GPS/GLONASS/BD进行测姿，加拿大Novatel公司、比利时Septentrio公司利用GPS/GLONASS测姿。中国星网宇达研发BDS/GPS定向接收机，东方联星的TOAS100D利用双天线进行测向、PNS200-BGI利用BD/GPS/INS进行定位测姿。
综上所述，国内外针对姿态测量技术已经开展了较为深入的研究，相关姿态测量方法已经在姿态测量样机上开展了静态及动态实验验证，而本文将在之前的研究基础上重点进行嵌入式测姿软件模块化方法介绍并对其可用性进行实验验证。
1 软件模块化
由于程序需实现不同导航系统、不同接收机板卡、不同姿态解算算法的选择，且要求程序具有通用性及可扩展性，因此将其模块化。模块化即根据程序的流程和调用的顺序等将程序以功能为单位划分为一个个单元的形式，模块化后每一部分的功能划分很清晰，模块之间通过接口传递参数和变量，操作简单，可有效提高工作效率和程序的运行效率。
1.1 模块划分
测姿软件模块化后可设计为由1个主程序和7模块组成，主程序声明如何调用各个模块及界面显示；模块分别为：读数模块、解码模块、预处理模块、单点定位模块、RTK定位模块、模块测姿模块、结果处理模块。
1.2 模块功能
主程序的功能为调用各个模块并进行导航系统、接收机板卡、频点的选择以及界面的显示。读取二进制数据流模块可进行二进制文件数据以及二进制串口数据的读取，此模块需使用多线程模式处理多个终端的数据流。解码模块将二进制数据流进行解码，可兼容OEMStar、BDM605、BDM670等型号接收机板卡，且此模块可进行扩展。预处理模块进行各通道数据对齐及参考星的选择。单点定位模块可计算卫星位置以及利用最小二乘法实现单点定位。RTK模块利用实时载波相位差分技术得到载体的精确位置。姿态解算模块实现3种姿态解算算法，分别为GNSS单历元CLAMBDA算法、GNSS递推多历元姿态解算算法以及GNSS卡尔曼滤波算法，此模块可扩展其他算法。结果处理模块将定位定姿的结果进行整合处理，并返回至主程序。
1.3 模块接口
每个模块具有4个接口（Get Default、Init、Process、Un Init），分别完成接口信息查询、初始化、信号处理和退出功能。其中，Get Default函数将返回本模块功能、配置参数接口、配置参数默认数值和配置参数说明等内容；Init函数将完成全局变量指针的传递工作，Process函数具体实现模块信息的处理，Un Init函数实现退出功能。各模块间输入、输出接口如表1所述。
1.4 主程序
主程序读取配置文件，配置文件可对频点、基线长度等进行设置。读取配置文件后根据读取到的参数进行各模块的初始化，再分别进入每个模块的process函数，按照图1所示流程依次完成各部分功能，最后进行界面更新。
主程序对每个模块的功能函数循环调用，每次循环解出一个历元姿态、定位结果。
2 实验性能分析
2.1 RTK定位测试结果
为验证嵌入式测姿软件模块化后系统的RTK定位效果，现将基站架设于北京航空航天大学新主楼F座楼顶，流动站位于北航田径场看台北侧，流动站接收机选用支持的OEMStar L1单频板卡，天线选用NovAtel ANT-35C2GA-TW外置天线。解算结果如图2～图4所示。
为测试系统RTK定位性能，特统计解算的流动站位置坐标的均值与标准差结果，统计结果如表2所示。
由此可见，嵌入式测姿系统模块化后RTK定位结果可以达到毫米级。
2.2 测姿测试结果
为验证嵌入式测姿系统的测姿结果，在北京航空航天大学操场看台上，选用3个全频天线以及北斗星通公司GPSBD双系统接收机进行试验。基线长度均为1 m。使用3种定姿算法，分别为CLAMBDA算法、递推多历元算法、卡尔曼滤波算法，实验结果如图5所示。
3 结论及建议
本文探讨利用嵌入式软件模块化的方法，通过不同GNSS姿态测量算法，解决可操作性、可扩展性等问题，实现对GNSS测姿软件的模块化。实际数据验证表明嵌入式软件模块化后：(1)可移植性强；(2)扩展性强；(3)可用性高；(4)适合在一般载体上使用；(5)资源利用率高。
由于GNSS测姿算法复杂度较高，需进一步探讨其在嵌入式ARM平台上实现时遇到的问题。
参考文献
[1]BUIST P.The baseline constrained LAMBDA method for single epoch,single frequency attitude determination applications[C].Proceedings of the 20th International Technical Meeting of the Satellite Division of the Institute of Navigation.Fort Worth Convention Center,Fort Worth,TX ION GPS,2007:2962-2973.
[2]GIORGI G,TEUNISSEN P J G,VERHAGEN S,et al.Testing a new multivariate GNSS carrier phase attitude determination method for remote sensing platforms[J].Advances in Space Research,2010,46(2):118-129.
[3]NADARAJAH N,TEUNISSEN P J G,BUIST P J,et al.First results of instantaneous GPS/Galileo/COMPASS attitude determination[C].Proceedings of the 6th ESA Workshop on Satellite Navigation User Equipment Technologies(NAVITEC′12),Noordwijk,ESA,2012:22-29.
[4]王博.GPS姿态测量系统中的关键技术研究[D].北京:北京理工大学,2009.
[5]WANG B,MIAO L,WANG S,et al.An integer ambiguity resolution method for the global positioning system(GPS)-based land vehicle attitude determination[J].Meas.Sci.Technol.,2009(20):075108.
[6]WANG B,MIAO L,WANG S,et al.A constrained LAMBDA method for GPS attitude determination[J].GPS Solutions,2009,13(2):97-107.
[7]王永泉.长航时高动态条件下GPS/GLONASS姿态测量研究[D].上海:上海交通大学,2008.
[8]JIN W,ZHAI C,WANG L.Hybrid analytical resolution approach based on ambiguity function for attitude determination[J].Journal of Zhejiang University SCIENCE A,2009,10(7):1038-1048.
[9]靳文瑞.基于GNSS的多传感器融合实时姿态测量技术研究[D].上海:上海交通大学,2009.