1 概述

软件测试是很广的概念。从其贯穿软件生命周期全过程来看，测试可分为模块测试、集成测试、系统测试等阶段。测试还可分为静态检查和动态运行测试两大类。在动态运行测试中，又可有基于程序结构的白盒测试（或称为覆盖测试）和基于功能的黑盒测试。测试不仅关注程序的功能，还有性有测试、强度测试等等。

要达到比较好的测试效果，除了要有周全的测试计划、可控的测试过程、测试人员丰富的经验外，还需要借助一些行之有效的辅助工具，尤其在当今软件规模日益庞大、测试工作量成倍增加的情况下。对应上述的测试分类情况，测试工具可划分为：支持对程序源代码进行静态规则检查和质量评估的静态分析工具、支持对程序单元进行动态覆盖测试的工具、对软件系统的整体运行性能进行测试的工具。另外，还有一些特殊用途的或专用工具，如协议测试仪、内存检测工具等。这些工具都有较为成熟的商业化产品，也可通过自行开发的方式获得。

本文具体讨论了对一类特殊的系统软件——嵌入式实时操作系统——进行覆盖测试的情况。内容涉及对这类软件特性的研究、测试的难点和特点、对现有测试工具的适应性改造和测试实例说明。

2 软件覆盖测试

覆盖是一种白盒测试方法，测试人员必须拥有程序的规格说明和程序清单，以程序的内部结构为基础，来设计测试案例。其基本准则是则测试案例来尽可能多地覆盖程序的内部逻辑结构，发现其中的错误和问题。所以，覆盖测试一般应用在软件测试的早期，即单元测试阶段。

覆盖的几种方法或策略如表1所列。

表1 几种典型的覆盖策略

覆盖策略	定 义
语句覆盖	在制定测试案例时，使程序中的每个语句都至少执行1次。其缺点是不能发现某些逻辑错误
判定覆盖	执行足够的测试案例，使得程序中每个判定都获得一次“真”值和“假”值，或者说使每一个分支都至少通过1次
条件覆盖	执行足够的测试案例，使得判定中的每个条件获得各种可能的结果
判定/条件覆盖	执行足够的测试案例，使得判定中的每个条件取得各种可能的值，并使得每个判定取得各种可能的结果
条件组合覆盖	执行足够的测试案例，使得每个判定中的条件的各种组合都至少出现1次。其特点是覆盖较充分，满足条件组合覆盖的测试案例也一定满足判定覆盖、条件覆盖和判定/条件覆盖。

从以上简要介绍可看出，这几种覆盖策略的严格程序有如下趋势：

其它一些覆盖策略还包括：修改的条件/判断覆盖（通常简称为MCDC）、路径覆盖、函数覆盖、调用覆盖、线性代码顺序和跳转覆盖、数据流覆盖、目标代码分支覆盖、循环覆盖、关系操作符覆盖等。随着软件规模的增长，实现全面的覆盖所需的测试案例的数目也越来越庞大，因此根据被测软件对象的特点选择适当的覆盖策略是非常重要的；同时，要确定合理测试目标，达到100%的覆盖往往要付出很大的代价，应该同形式化评审等方法结合，以发现更多的软件故障。

3 覆盖测试工具

要取得较好的覆盖测试效果，需要借助一定的工具软件。这些工具软件一般具备如下的功能特点，可弥补人为测试的缺陷：

①分析软件内部结构，帮助制定覆盖策略及设计测试案例；

②与适当的编译器结合，对被测软件实施自动插装，以便在其运行过程中生成覆盖信息并收集这些信息；

③根据搜集的覆盖信息计算覆盖率，帮助测试人员找到未被覆盖的软件部位，以改进测试案例提高覆盖率。

在利用工具进行动态覆盖测试时，需要3个要素：测试用例、插装过的被测代码、搜集覆盖信息并进行分析的工具本身。代码插装由工具自动完成，通过执行测试用例，再由工具搜集覆盖信息并进行分析，就可以看到覆盖率指标了。图1展示实现覆盖测试的基本过程。
4 嵌入式软件的覆盖测试原理

嵌入式软件的开发与通用软件很大的不同点在于，需要采用交叉开发的方式：开发工具运行在软硬件配置丰富的宿主机上，而嵌入式应用程序运行在软硬件资源相对缺乏的目标机上。对于这类软件的测试也存在着同样的问题：测试工具运行在宿主机上，测试所需要的信息在目标机上产生，并通过一定的物理/逻辑连接传输到缩主机上，由测试工具接收。因此，嵌入式软件测试的一个重要问题是建立宿主机与目标机之间的物理/逻辑连接，解决数据信息的传输问题。

嵌入式软件覆盖测试的基本原理如图2所示。

在目标机方，插装过的被测应用程序将覆盖信息发送到消息队列中，一个专门的任务负责在适当的时候将这些信息发送到宿主机方。缩主机方有专门的模块负责接收覆盖信息。并交给分析工具分析和在线动态显示覆盖率的增长情况。

支持嵌入式软件覆盖测试的工具应解决如下2方面的关键问题：

*与嵌入式操作系统的结合覆盖测试工具与嵌入式操作系统的结合体现在3方面。首先，在目标机方，应用任务与专门负责收集/上传覆盖信息的任务是通过消息队列来传递数据的，该消息队列可使用嵌入式操作系统的相应机制实现。其次，这个专门任务也可以被看作一个特殊的应用任务，也必须有嵌入式操作系统的支持，因为任务管理是后者的基本功能之一。最后，目标机与宿主机之间的通信可以采用串口或以太网方式，对串口的驱动或网络协议均可使用嵌入式操作系统的相应程序组件。

*与其它嵌入式交叉开发工具的关系

嵌入式应用程序的开发通常采用交叉开发方式，几乎所有的开发工具均要解决3部分的问题：宿主机部分的功能、目标机部分的功能、宿主机与目标机的连接问题。其中，宿主机与目标机的连接是个瓶颈，如果不同的工具要使用同一物理线路实现数据传输，则要解决对该物理线路（或者说硬件端口）的正确共享。比如在图3所示的环境中，宿主机方的各种工具通过统一的接口——目标服务器（target server）实现对通信线路的访问，目标机方的调试代理（debug agent）则是各种信息（调试信息、覆盖信息、时间信息、对象信息等）的收集与传递的核心。

5 Logiscope在嵌入式操作系统DeltaCORE测试中的应用

Logiscope是Verilog公司的CASE产品，对软件的编码、测试、维护提供多方面的服务，并且支持嵌入式软件的覆盖测试。

5.1 测试前的准备

测试前的准备即为支持对DeltaCORE的测试所做的移植工作。

目前，Logiscope已经为一些成熟的商用嵌入式操作系统提供了支持，比如pSOS。DeltaCORE是我国自主开发的嵌入式强实时操作系统内核，为了利用Logiscope实现对DeltaCORE的应用程序乃至DeltaCORE本身的测试，我们主要解决了第4节中描述的第1个关键问题。为了支持嵌入式程序的测试，Logiscope提供了运行在目标机方的程序代码（或称为目标机端的支持库），里面包含了：

*1个用来收集和发送覆盖信息的主循环线程，该线程即是嵌入式应用中的特殊任务；

*实现具体数据传输的函数，包括对串口或网络的驱动，它们将被上述线程调用；

*插装函数的实现，这些函数被被测代码调用，向缓冲中放入覆盖消息块；

*对缓冲信息队列的管理；

*初始化代码。

例如，当被测程序运行进入到一条if(……)语句时，整个过程如图4所示。

为了支持对DeltaCORE的测试，将与这些机制相关的代码进行移植，包括以下几方面：

*将收集和发送覆盖信息的主循环线程作为在目标机端运行的应用程序中的特殊任务；

*对串口的驱动采用LambdaTOOL BSP（板级支持包）中的串口驱动代替，对网络的驱动，用DeltaCORE的配套组件DeltaNET中的驱动程序实现；

*利用DeltaCORE的信箱机制实现消息队列的创建和管理，插装代码向这些信箱发送覆盖消息块；

*在DetaCORE应用程序的根任务中调用Logiscope的初始化函数，达到创建特殊任务信箱的目的。

开发DeltaCORE应用程序时，我们使用了其配套开发工具LambdaTOOL。由于所使用的工具版本没有实现目标服务器（target server）的调试方式，因此对物理端口的使用采用的独占方式，即调试工具不能与其它工具共享同一端口。我们可以用网络试上载并启动目标应用程序，而通过串口传送覆盖信息。

5.2 对DeltaCORE的覆盖测试过程及结果

对于函数内部，Logiscope支持的覆盖策略有：

*指令块IBs(Instruction Blocks)

*判断到判断的路径DDPs(Decision-to-Decision Paths)

*MCDC（Modified Condition/Decision）

在项目层次上支持的覆盖策略是：

*过程到过程路径PPP（Procedure-to-Procedure Path）

在DeltaCORE的测试中，我们采用了较为常用的覆盖策略——判断到判断的路径，其含义是：DDP是一个指令序列，它的起点是函数或判断（if，while，……）的入口点，它的出口是下一个函数或判断的退出点，之间不能再有判断，比如在图5中包含了5个DDPs：

测试的具体过程是：

①利用插装分析器对DeltaCORE的源代码进行插装，并生成插装信息文件。

②将移植后的Logiscope目标机端程序与插装后的内核源代码一同编译链接成库，以替代原来的内核库，供应用程序使用。

③编写测试案例，从实现应用的角度使用DeltaCORE的各种系统功能调用，力求遍历内核函数所有的判定分支，并将这些案例编译成可执行程序。

④在宿主机端启动覆盖信息收集和分析程序，用LambdaTOOL的调试器下载并启动应用程序。DeltaCORE的覆盖信息被传递到宿主机上，分析程序动态显示覆盖率的增长情况，并将这些信息记录在一个文件中。

⑤应用程序执行完毕后，启动Logiscope的事后分析工具，将覆盖信息记录文件与插装信息文件（在源代码插装在生成的附属文件）进行比较，帮助测试人员清晰地了解每个被测函数内部的路径覆盖情况，借此可为测试案例的改进提供帮助。

⑥测试人员修改测试案例，并重新进行整个测试过程；各项测试的结果可以叠加，覆盖率将得到增长。

经过2个多月的时间，我们对DeltaCORE 1.1版本79个文件共计115个函数进行了覆盖测试，覆盖率已经达到了70.55%。编写测试用例89个，主要的60个API函数均已获得较高的覆盖，覆盖率达100%的约占51.3%。

6 小结

我们借助Logiscope工具对嵌入式实时操作系统DeltaCORE进行了覆盖测试，达到了较好的覆盖率；发现并处理了一些缺陷，提高了软件的质量和可靠性，但同时也存在不足之处：

①测试应好好规划，包括测试顺序的选择、测试案例的设计、测试文档的管理等等。

②由于该测试手段依赖于操作系统的有关机制，而被测对象又是操作系统本身，因此与这些机制有关的部分代码未被插装和测试，否则就会出错。比如，操作系统的初始化函数os_init，在这个函数运行完毕之前，操作系统的相应机制尚未建立起来，因此对它进行插装就会造成问题，不能正确地得到覆盖信息。又比如，出于效率方面的考虑，与系统时钟相关的部分函数未被插装，因为在程序运行过程中，时钟是最频繁产生的一种外部事件，如果插装，就会产生大量的覆盖信息，会对信息缓存、传递、收集和处理造成压力。另外，所用的工具不支持对汇编函数的插装和测试。综合上述各种原因，DeltaCORE 1.1的总体覆盖率还显得比较低，需要采用其它的方法来提高它。对于非操作系统组件及应用的测试，由于不存在操作系统本身的问题，因此可望达到较高的覆盖率。

③该方法不能用于时间性能测试。因此它属于纯软件的测试方式，大量数据信息的产生、传递与收集对被测程序的干扰大，只能做白盒性的功能结构验证。如果做性能测试，应采用某些软硬结合方式的工具，比如CodeTEST。

对嵌入式软件产品的测试是多方面的，除覆盖测试外，还有时间性能测试、内存使用测试与分析等，也是我们研究的重要课题。

    嵌入式系统通常是一个包含微处理器的特殊计算机系统，是一个较大系统或设备的组成部分，它在很大程度上决定了设备的功能特性。许多具备数字接口的设备如微波设备、录像机(VCR)和汽车等都会用到嵌入式系统。有些嵌入式系统需要使用操作系统，有些则用单个程序实现整个逻辑，但所有嵌入式系统提供的功能都要比通用计算系统更专业些。嵌入式系统功能包括：
1. 监视环境－从输入传感器读取数据,然后处理数据并显示结果。
2. 控制环境－产生并向激励器发送命令。
3. 转换信息－转换并处理收集到的数据。

    虽然通过传感器和激励器完成与外部世界的交互是嵌入式系统的重要特点，但这些嵌入式系统还提供适合它们所在设备的特殊功能。嵌入式系统一般用来执行控制程序、有限状态机和信号处理算法。这些系统还必须检测内部计算环境和周围电磁系统中发生的故障并对此做出响应。

嵌入式系统特性

    嵌入式系统的设计挑战是使嵌入式系统的独特性能与设备的特殊约束条件相一致。以下是一些嵌入式系统的重要特性：
    1. 特殊应用系统－嵌入式系统不同于通用处理器，它针对特殊应用进行了优化。
    2. 反应性系统－反应性计算的意思是系统(主要是软件部分)根据传感器信息对环境作出响应，并利用激励器控制环境，同时系统速度能与环境速度同步。
    3. 分布式－嵌入式系统的一般特征是多个通信进程在多个通过通信链路链接的CPU或ASIC上运行。
    4. 异类性－不同的嵌入式系统一般具有不同的结构，以便在处理严格设计约束的嵌入式系统时能够提供更好的设计便利性。
    5. 苛刻环境－许多嵌入式系统并不工作在受控的环境中，因此它们必须能够经受过热、振动、冲击、电源波动和其它恶劣的物理环境条件的考验。
    6. 系统安全性和可靠性－由于嵌入式系统复杂度和运算量的不断增长，需要更多地考虑系统安全因素。
    7. 小型化、重量轻－为了达到便携目的，许多嵌入式系统的重量必须设计得很轻。
    8. 成本敏感性－不同的嵌入式系统对成本的敏感性有很大的不同。

实时系统的特性

    实时系统要求在外部环境指定的时间间隔内对来自环境的激励信号作出响应(包括物理时间的过渡)。从输入时间到输出时间的延迟必须足够小，以满足可以接受的时间值。通常实时系统需要对环境作出连续及时的响应。

    计算的正确性不仅依赖于结果，而且取决于输出发生的时间。一个实时系统必须满足有限响应时间约束条件，否则会产生严重的后果。如果后果是性能的劣化而不是故障，那么这种系统可以看作是一个软实时系统。如果后果是系统发生故障，那么这种系统就是一种硬实时系统。

    实时系统有反应式和嵌入式两种类型。反应式实时系统会与环境发生连续的互作用，而嵌入式实时系统主要用于控制大型系统中安装的特殊硬件。

嵌入式系统开发生命周期

    许多系统设计工程师都会经历硬件/软件协同设计的过程(图1)，此过程中硬件与软件将同时进行开发。理解硬件与软件功能相互之间的关系及界限有助于确保设计要求得到完整正确的理解和实现。

    早在设计要求的定义与分析阶段，系统开发人员就必须与设计工程师协同分配硬件或/和软件方面的要求。这种分配的依据是早期系统仿真、原型设计和行为建模结果、工程师自己的经验以及上文提及的各种因素权衡结果(图2)。一旦分配结束，就可以立即着手具体的设计和实现。实时系统开发中软硬件的并行设计会使用到各种分析技术，包括：
    1. 硬件与软件仿真；
    2. 硬件/软件协同仿真；
    3. 可调度的建模技术，如速率恒定分析；
    4. 原型设计和渐进式开发。

    可以在各种抽象层次使用的仿真技术主要用于开展早期的性能评估。低层仿真可以用来为总线宽度和数据流程建模，这对性能评估是非常有用的。高层仿真可以满足功能的交互，并促成硬件/软件权衡研究及有效性设计。利用仿真可以将一个复杂的系统向下抽象成基础组件和行为。仿真还助于解决功能性问题(数据与算法)、行为(进程排序)或性能问题(资源利用、吞吐量和时序)。

理解设计要求

    在作执行任何类型的处理器评估时，首先要详细理解用户的功能和非功能性要求。功能性要求通常比较容易获得，而非功能性要求较难定量测量。但对于实时系统来说，定义响应时间这样的要求是非常重要的。实时要求可以有以下几种：
    1. 激励－激励(S-S)：到系统去的两个激励之间的实时关系；
    2. 激励-响应(S-R)：一个激励与来自系统的一个后序响应之间的实时关系；
    3. 响应-激励(R-S)：一个响应与到系统去的一个后序激励之间的实时关系；
    4. 响应-响应(R-R)：来自系统的两个响应之间的实时关系。

    S-R和R-R关系定义了对指定系统的时序要求。这种情况下所实现的功能必须足够快(或足够慢)才能满足时序要求。S-S和R-S约束暗示系统必须能够从环境(可能是一个用户或另外一个系统)中检测出特定时序约束的破坏。这些约束与功能的快慢没有关系，相反它们能够检测出某些遭到破坏的时序约束并采取必要的措施。

    因此要从最初系统要求设计时就很好地理解这一点，因为S-R和R-R约束可以引导设计工程师进行代码优化，而S-S和R-S约束需要用额外的软件来检测和响应时序冲突。

处理器选择

    嵌入式实时系统比较适合用于系统优化。由于这些系统主要用来解决范围相对较窄的问题，因此硬件和软件能够得到最佳优化，并很好地应用于单一设备。这样做的目的是要在软硬件最佳折衷状态下开展系统设计。影响这一阶段设计的主要因素是处理器的选择、软硬件的分割和总体系统集成。

    在为嵌入式实时系统选择处理器时需要考虑以下几个方面：

    1. 性能：处理器必须有足够的性能执行任务和支持产品生命周期。

    2. 实现：根据具体应用情况，处理器可能需要被高度集成。在DSP应用中可以有好几种选择，专用集成电路(ASIC)就是其中的一种。这些器件可以被用作DSP协处理器，但对于许多通用信号处理来说显得不够灵活。另外可以选择精简指令集计算机(RISC)处理器。这些处理器的时钟速度特别快，但可扩展性不是很强，而且会发生其它实时(可预测性)问题。现场可编程阵列(FPGA)是一种快速器件，能够快速高效地完成某些DSP功能，但与DSP相比开发难度比较大，因为在DSP中一个简单的程序就能完成相同的功能。如果是主信号处理应用，则最好采用性能强大功耗也较大的通用处理器。如果需要快速升级信号处理应用，采用DSP等可编程器件比定制的硬件方案要更好些。

    3. 工具支持：支持软件创建、调试、系统集成、代码调整和优化工具对整体项目成功与否非常关键。

    4. 操作系统支持：嵌入式系统应用需要使用有帮助的抽象来减少其复杂性。针对处理器系列产品作过优化的商用操作系统(OS)能够缩短设备开发周期和上市时间。

    5. 过去的经验：拥有处理器或处理器系列产品的开发经验可以减少可观的学习新处理器、工具和技术的时间。

    6. 仿真支持：循环精确仿真对某些类型的应用来说非常重要，特别是数字信号处理应用中许多功能正确性验证都是采用仿真技术完成的。嵌入式系统的软硬件协同设计模型也促使处理器仿真器成为开发流程中一个非常有用的工具。

    7. 应用支持：应用支持有多种方式，从通过热线或网站取得的应用专家支持，到预打包的软件和应用框架，甚至完好的测试平台。一些DSP处理器能够提供外围器件的驱动器、板级支持包和其它“启动帮助组件”。有了这些软件组件后，应用开发师就无需再编写器件驱动器等“无附加值”的软件，相反，他们可以把精力放在具有附加值的功能开发上，使他们的产品能独树一帜。

    8. 成本：嵌入式应用对成本特别敏感，而产品成本的稍许差别都可能导致市场的失败。

    9. 功耗：市场上有许多依靠电池工作的便携嵌入式实时系统，此时电池寿命将成为系统的重要参数。这种情况下应该考虑使用针对便携式应用优化的低功耗器件。

    10. 传统代码：如果选中的处理器需要设计人员编写与现存代码的接口，将会导致整个设计流程的严重滞后。因此需要选择一款代码兼容的器件来避免或减少这一步骤造成的影响。

    11. 算法复杂性：某些处理器能够非常高效地处理某类算法，因此最好选择能够与应用最佳匹配的处理器。例如，具有许多控制代码的有限状态机应用应该映射为类似ARM处理器的RISC器件。编码、解码和回波抵消等信号处理应用应该映射为数字信号处理器，或具有信号处理加速器的某种器件。

    12. 上市时间：项目的完成时间会加快处理器的选择过程，这一过程与先前讲述的几个关键事项密切相关，如OS的可用性、其它软件组件以及便携性问题。

设计还是购买？

    是自己设计还是购买成品呢?如果有可能不重新设计，价格也比较合理的话，购买要比自己开发更有利。由于嵌入式系统预算的缩减、实时操作系统(RTOS)和TCP/IP堆栈等商用技术的改进、嵌入式系统要求的扩展，采用商业性现成(COTS)技术正变得越来越普遍。采用COTS技术能够缩短开发周期中编码、调试、单元测试和代码检查阶段的时间。

    然而，作出购买而非设计的决定会改变一个组织的基础开发流程。一个组织希望实现的新业务有：供应商调研和评估、产品评估以及实时的供应商交流与关系建立。产品开发的其它活动不会取消，但会作出一些改变。这些变化包括更关注如何将系统硬件与软件更好地组合在一起，而不再把重点放在模块自己内部的运作上。另外必须更侧重于兼容性、可配置性和可集成性等结构上的问题。

    必须很好的理解和高效地管理由于决定采用“购买”而非“设计创建”方式所导致的结果。首先，自然是对供应商提出产品要求、产品可靠性、计划和产品文档等依赖请求。这种情况下产品要求中的灵活性会打些折扣。购买商用产品意味着接受现有的产品要求，但这种要求也许不能完美地匹配自身产品的要求，这就需要设计人员把这种缺点与COTS技术提供的成本与上市时间优势作一个理智的权衡。

    因此重要的是最终用户与技术人员必须参与COTS供应商的选择，考虑的重点要放在业务需求上而非技术本身。性价比分析所要考虑的因素应包括易学性、易用性、供应商名声和长期稳定性、许可方式和培训。所有与性能有关的声明必须尽可能采用内部或外部基准或演示来到得有效性认证。为了避免可能出现的偏差，评估标准应该在收到供应商建议前就制定好。选择供应商的主要工作包括研究和理解技术标准和相当的文件、采用类似建议请求(RFP)的标准模式征求供应商的建议、对供应商建议进行评估和排序、选择供应商并签署合同。

    除了评估技术外，还应对供应商本身进行评审。要充分了解供应商开业时间的长短、供应商的背景和名声、供应商的其它用户对它的评价和意见、供应商人力资源的投入和对你的计划或项目的支持情况，以及供应商对你业务和要求的理解程度，甚至对未来项目的承诺。以前软件团队认为软件开发方案遵循类似于创建架构的特定模式。提供符合一般模式的抽象方法能够使软件团队定制符合他们特殊要求的方案，同时遵循被前人证明是高效和正确的模式。

    嵌入式系统供应商已经认识到需要通过提供软件组件和类似于设计模式的框架来加快软件开发进程。在DSP领域，供应商向DSP设计工程师提供包括参考框架(RF)在内的上百个以DSP为核心的软件组件用于产品和系统开发。设计完好的参考框架能够在设备开发的早期阶段让设计人员快速入门。RF内含方便易用并且适合多种应用的源代码。由此可以取消许多早期的低层设计决策，使开发人员能有更多的时间用在真正显示产品特色的代码开发上。设计人员可以选择能够最大程度满足他们系统需要的专业RF，然后集成适配的算法(可以是其它供应商出售的DSP COTS算法，或供应商自己的算法)生成适合各种终端设备的特殊应用，如宽带、语音、视频图像、生物测量和无线设施。这些RF提供百分之百的C语言源码，并且没有版税要求。RF源代码可以从www.ti.com/downloadrfnow网站下载。

软件性能工程

    许多嵌入式实时系统必须满足一系列性能目标。一般来讲，性能是一个软件系统或组件对时间要求满足程度的一种指示。这里的时间指标可以用响应时间和吞吐量来衡量，该时间值是指响应某种要求所需的时间，而吞吐量用以指示系统在特定时间间隔内能够处理的请求数量。可扩展性是嵌入式实时系统的另外一个重要指标，可以用它来衡量系统要求提高时系统能够继续满足响应时间或吞吐量要求的能力。

    如果在整个开发生命周期内得不到正确的性能管理，那么即使选择了正确的处理器和软件也是徒劳的。性能故障的后果是非常严重的，它可能损伤与客户的关系，造成收入下降，甚至导致整个项目失败。因此在整个生命周期内需要随时关注性能问题。性能管理可以被动或主动完成。被动方式需要采用一个较大的处理器解决性能问题，它只在系统完成构架、设计和实现后处理性能问题，在解决问题前一直处于等待状态，直到实际需要测量的事件发生。主动方式是指整个生命周期内一直在跟踪和交流性能问题，同时开发用以识别性能劣化的进程，并在性能处理中培养团队成员。

本文小结

    显然开发嵌入式实时系统是一个相当复杂的过程，本文旨在启发设计人员在分析初始要求时如何权衡硬件与软件之间的关系，要时刻在系统灵活性、速度、成本、计划和可用工具之间作出权衡，并充分考虑各个供应商提供长期可靠支持的可能性。

嵌入式系统定义
       嵌入式系统是以应用为中心，以计算机技术为基础，并且软硬件可裁剪，适用于应用系统对功能、可靠性、成本、体积、功耗有严格要求的专用计算机系统。它一般由嵌入式微处理器、外围硬件设备、嵌入式操作系统以及用户的应用程序等四个部分组成，用于实现对其他设备的控制、监视或管理等功能。
　　嵌入式系统一般指非PC系统，它包括硬件和软件两部分。硬件包括处理器／微处理器、存储器及外设器件和I／O端口、图形控制器等。软件部分包括操作系统软件（OS）（要求实时和多任务操作）和应用程序编程。有时设计人员把这两种软件组合在一起。应用程序控制着系统的运作和行为；而操作系统控制着应用程序编程与硬件的交互作用。
　　嵌入式系统的核心是嵌入式微处理器。嵌入式微处理器一般就具备以下4个特点：
　　1）对实时多任务有很强的支持能力，能完成多任务并且有较短的中断响应时间，从而使内部的代码和实时内核心的执行时间减少到最低限度。
　　2）具有功能很强的存储区保护功能。这是由于嵌入式系统的软件结构已模块化，而为了避免在软件模块之间出现错误的交叉作用，需要设计强大的存储区保护功能，同时也有利于软件诊断。
　　3）可扩展的处理器结构，以能最迅速地开展出满足应的最高性能的嵌入式微处理器。
　　4）嵌入式微处理器必须功耗很低，尤其是用于便携式的无线及移动的计算和通信设备中靠电池供电的嵌入式系统更是如此，如需要功耗只有mW甚至μW级。
　　嵌入式计算机系统同通用型计算机系统相比具有以下特点：　
　　1.嵌入式系统通常是面向特定应用的嵌入式CPU与通用型的最大不同就是嵌入式CPU大多工作在为特定用户群设计的系统中，它通常都具有低功耗、体积小、集成度高等特点，能够把通用CPU中许多由板卡完成的任务集成在芯片内部，从而有利于嵌入式系统设计趋于小型化，移动能力大大增强，跟网络的耦合也越来越紧密。
　　2.嵌入式系统是将先进的计算机技术、半导体技术和电子技术与各个行业的具体应用相结合后的产物。这一点就决定了它必然是一个技术密集、资金密集、高度分散、不断创新的知识集成系统。
　　3.嵌入式系统的硬件和软件都必须高效率地设计，量体裁衣、去除冗余，力争在同样的硅片面积上实现更高的性能，这样才能在具体应用中对处理器的选择更具有竞争力
　　4.嵌入式系统和具体应用有机地结合在一起，它的升级换代也是和具体产品同步进行，因此嵌入式系统产品一旦进入市场，具有较长的生命周期。
　　5.为了提高执行速度和系统可靠性，嵌入式系统中的软件一般都固化在存储器芯片或单片机本身中，而不是存贮于磁盘等载体中。
　　6.嵌入式系统本身不具备自举开发能力，即使设计完成以后用户通常也是不能对其中的程序功能进行修改的，必须有一套开发工具和环境才能进行开发。
嵌入式系统发展历史
       目前，在嵌入式系统应用领域中，不少人对什么是嵌入式系统不甚了解。有些人搞了十多年的单片机应用，不知道单片机就是一个最典型的嵌入式系统；也有些人在解释什么是嵌入式系统时，不是从定义出发，而是列举了嵌入式系统的一些特点，往往不知所云。因此，有必要从现代计算的发展历史，了解嵌入式系统的由来，从学科建设的角度来探讨嵌入式系统较为准确的定义。
　　1 现代计算机的技术发展史
　　(1)始于微型机时代的嵌入式应用
　　电子数字计算机诞生于1946年，在其后漫长的历史进程中，计算机始终是供养在特殊的机房中，实现数值计算的大型昂贵设备。直到20世纪70年代，微处理器的出现，计算机才出现了历史性的变化。以微处理器为核心的微型计算机以其小型、价廉、高可靠性特点，迅速走出机房；基于高速数值解算能力的微型机，表现出的智能化水平引起了控制专业人士的兴趣，要求将微型机嵌入到一个对象体系中，实现对象体系的智能化控制。例如，将微型计算机经电气加固、机械加固，并配置各种外围接口电路，安装到大型舰船中构成自动驾驶仪或轮机状态监测系统。这样一来，计算机便失去了原来的形态与通用的计算机功能。为了区别于原有的通用计算机系统，把嵌入到对象体系中，实现对象体系智能化控制的计算机，称作嵌入式计算机系统。因此，嵌入式系统诞生于微型机时代，嵌入式系统的嵌入性本质是将一个计算机嵌入到一个对象体系中去，这些是理解嵌入式系统的基本出发点。
　　(2)现代计算机技术的两大分支
　　由于嵌入式计算机系统要嵌入到对象体系中，实现的是对象的智能化控制，因此，它有着与通用计算机系统完全不同的技术要求与技术发展方向。
　　通用计算机系统的技术要求是高速、海量的数值计算；技术发展方向是总线速度的无限提升，存储容量的无限扩大。 而嵌入式计算机系统的技术要求则是对象的智能化控制能力；技术发展方向是与对象系统密切相关的嵌入性能、控制能力与控制的可靠性。
　　早期，人们勉为其难地将通用计算机系统进行改装，在大型设备中实现嵌入式应用。然而，对于众多的对象系统（如家用电器、仪器仪表、工控单元……），无法嵌入通用计算机系统，况且嵌入式系统与通用计算机系统的技术发展方向完全不同，因此，必须独立地发展通用计算机系统与嵌入式计算机系统，这就形成了现代计算机技术发展的两大分支。
　　如果说微型机的出现，使计算机进入到现代计算机发展阶段，那么嵌入式计算机系统的诞生，则标志了计算机进入了通用计算机系统与嵌入式计算机系统两大分支并行发展时代，从而导致20世纪末，计算机的高速发展时期。
　　(3) 两大分支发展的里程碑事件
　　通用计算机系统与嵌入式计算机系统的专业化分工发展，导致20世纪末、21世纪初，计算机技术的飞速发展。计算机专业领域集中精力发展通用计算机系统的软、硬件技术，不必兼顾嵌入式应用要求，通用微处理器迅速从286、386、486到奔腾系列；操作系统则迅速扩张计算机基于高速海量的数据文件处理能力，使通用计算机系统进入到尽善尽美阶段。
　　嵌入式计算机系统则走上了一条完全不同的道路，这条独立发展的道路就是单芯片化道路。它动员了原有的传统电子系统领域的厂家与专业人士，接过起源于计算机领域的嵌入式系统，承担起发展与普及嵌入式系统的历史任务，迅速地将传统的电子系统发展到智能化的现代电子系统时代。
　　因此，现代计算机技术发展的两大分支的里程碑意义在于：它不仅形成了计算机发展的专业化分工，而且将发展计算机技术的任务扩展到传统的电子系统领域，使计算机成为进入人类社会全面智能化时代的有力工具。
　　2 嵌入式系统的定义与特点
　　如果我们了解了嵌入式（计算机）系统的由来与发展，对嵌入式系统就不会产生过多的误解，而能历史地、本质地、普遍适用地定义嵌入式系统。
　　(1) 嵌入式系统的定义
　　按照历史性、本质性、普遍性要求，嵌入式系统应定义为：“嵌入到对象体系中的专用计算机系统”。“嵌入性”、“专用性”与“计算机系统”是嵌入式系统的三个基本要素。对象系统则是指嵌入式系统所嵌入的宿主系统。
　　(2) 嵌入式系统的特点
　　嵌入式系统的特点与定义不同，它是由定义中的三个基本要素衍生出来的。不同的嵌入式系统其特点会有所差异。
　　与“嵌入性”的相关特点：由于是嵌入到对象系统中，必须满足对象系统的环境要求，如物理环境（小型）、电气/气氛环境（可靠）、成本（价廉）等要求。
　　与“专用性”的相关特点：软、硬件的裁剪性；满足对象要求的最小软、硬件配置等。
　　与“计算机系统”的相关特点：嵌入式系统必须是能满足对象系统控制要求的计算机系统。与上两个特点相呼应，这样的计算机必须配置有与对象系统相适应的接口电路。
　　另外，在理解嵌入式系统定义时，不要与嵌入式设备相混淆。嵌入式设备是指内部有嵌入式系统的产品、设备，例如，内含单片机的家用电器、仪器仪表、工控单元、机器人、手机、PDA等。
　　(3)嵌入式系统的种类与发展
　　按照上述嵌入式系统的定义，只要满足定义中三要素的计算机系统，都可称为嵌入式系统。嵌入式系统按形态可分为设备级（工控机）、板级（单板、模块）、芯片级（MCU、SoC）。
　　有些人把嵌入式处理器当作嵌入式系统，但由于嵌入式系统是一个嵌入式计算机系统，因此，只有将嵌入式处理器构成一个计算机系统，并作为嵌入式应用时，这样的计算机系统才可称作嵌入式系统。
　　嵌入式系统与对象系统密切相关，其主要技术发展方向是满足嵌入式应用要求，不断扩展对象系统要求的外围电路（如ADC、DAC、PWM、日历时钟、电源监测、程序运行监测电路等），形成满足对象系统要求的应用系统。因此，嵌入式系统作为一个专用计算机系统，要不断向计算机应用系统发展。因此，可以把定义中的专用计算机系统引伸成，满足对象系统要求的计算机应用系统。
　　3 嵌入式系统的独立发展道路
　　(1)单片机开创了嵌入式系统独立发展道路
　　嵌入式系统虽然起源于微型计算机时代，然而，微型计算机的体积、价位、可靠性都无法满足广大对象系统的嵌入式应用要求，因此，嵌入式系统必须走独立发展道路。这条道路就是芯片化道路。将计算机做在一个芯片上，从而开创了嵌入式系统独立发展的单片机时代。
　　在探索单片机的发展道路时，有过两种模式，即“Σ模式”与“创新模式”。“Σ模式”本质上是通用计算机直接芯片化的模式，它将通用计算机系统中的基本单元进行裁剪后，集成在一个芯片上，构成单片微型计算机；“创新模式”则完全按嵌入式应用要求设计全新的，满足嵌入式应用要求的体系结构、微处理器、指令系统、总线方式、管理模式等。Intel公司的MCS-48、MCS-51就是按照创新模式发展起来的单片形态的嵌入式系统（单片微型计算机）。MCS-51是在MCS-48探索基础上，进行全面完善的嵌入式系统。历史证明，“创新模式”是嵌入式系统独立发展的正确道路，MCS-51的体系结构也因此成为单片嵌入式系统的典型结构体系。
　　(2)单片机的技术发展史
　　单片机诞生于20世纪70年代末，经历了SCM、MCU、SoC三大阶段。
　　SCM即单片微型计算机（Single Chip Microcomputer）阶段，主要是寻求最佳的单片形态嵌入式系统的最佳体系结构。“创新模式”获得成功，奠定了SCM与通用计算机完全不同的发展道路。在开创嵌入式系统独立发展道路上，Intel公司功不可没。
　　MCU即微控制器（Micro Controller Unit）阶段，主要的技术发展方向是：不断扩展满足嵌入式应用时，对象系统要求的各种外围电路与接口电路，突显其对象的智能化控制能力。它所涉及的领域都与对象系统相关，因此，发展MCU的重任不可避免地落在电气、电子技术厂家。从这一角度来看，Intel逐渐淡出MCU的发展也有其客观因素。在发展MCU方面，最著名的厂家当数Philips公司。
　　Philips公司以其在嵌入式应用方面的巨大优势，将MCS-51从单片微型计算机迅速发展到微控制器。因此，当我们回顾嵌入式系统发展道路时，不要忘记Intel和Philips的历史功绩。
　　单片机是嵌入式系统的独立发展之路，向MCU阶段发展的重要因素，就是寻求应用系统在芯片上的最大化解决；因此，专用单片机的发展自然形成了SoC化趋势。随着微电子技术、IC设计、EDA工具的发展，基于SoC的单片机应用系统设计会有较大的发展。因此，对单片机的理解可以从单片微型计算机、单片微控制器延伸到单片应用系统。
　　4 嵌入式系统的两种应用模式
　　嵌入式系统的嵌入式应用特点，决定了它的多学科交叉特点。作为计算机的内含，要求计算机领域人员介入其体系结构、软件技术、工程应用方面的研究。然而，了解对象系统的控制要求，实现系统控制模式必须具备对象领域的专业知识。因此，从嵌入式系统发展的历史过程，以及嵌入式应用的多样性中，可以了解到客观上形成的两种应用模式。
　　(1) 客观存在的两种应用模式
　　嵌入式计算机系统起源于微型机时代，但很快就进入到独立发展的单片机时代。在单片机时代，嵌入式系统以器件形态迅速进入到传统电子技术领域中，以电子技术应用工程师为主体，实现传统电子系统的智能化，而计算机专业队伍并没有真正进入单片机应用领域。因此，电子技术应用工程师以自己习惯性的电子技术应用模式，从事单片机的应用开发。这种应用模式最重要的特点是：软、硬件的底层性和随意性；对象系统专业技术的密切相关性；缺少计算机工程设计方法。
　　虽然在单片机时代，计算机专业淡出了嵌入式系统领域，但随着后PC时代的到来，网络、通信技术得以发展；同时，嵌入式系统软、硬件技术有了很大的提升，为计算机专业人士介入嵌入式系统应用开辟了广阔天地。计算机专业人士的介入，形成的计算机应用模式带有明显的计算机的工程应用特点，即基于嵌入式系统软、硬件平台，以网络、通信为主的非嵌入式底层应用。
　　(2)两种应用模式的并存与互补
　　由于嵌入式系统最大、最广、最底层的应用是传统电子技术领域的智能化改造，因此，以通晓对象专业的电子技术队伍为主，用最少的嵌入式系统软、硬件开销，以8位机为主，带有浓重的电子系统设计色彩的电子系统应用模式会长期存在下去。另外，计算机专业人士会愈来愈多地介入嵌入式系统应用，但囿于对象专业知识的隔阂，其应用领域会集中在网络、通信、多媒体、商务电子等方面，不可能替代原来电子工程师在控制、仪器仪表、机械电子等方面的嵌入式应用。因此，客观存在的两种应用模式会长期并存下去，在不同的领域中相互补充。电子系统设计模式应从计算机应用设计模式中，学习计算机工程方法和嵌入式系统软件技术；计算机应用设计模式应从电子系统设计模式中，了解嵌入式系统应用的电路系统特性、基本的外围电路设计方法和对象系统的基本要求等。
　　(3) 嵌入式系统应用的高低端
　　由于嵌入式系统有过很长的一段单片机的独立发展道路，大多是基于8位单片机，实现最底层的嵌入式系统应用，带有明显的电子系统设计模式特点。大多数从事单片机应用开发人员，都是对象系统领域中的电子系统工程师，加之单片机的出现，立即脱离了计算机专业领域，以“智能化”器件身份进入电子系统领域，没有带入“嵌入式系统”概念。因此，不少从事单片机应用的人，不了解单片机与嵌入式系统的关系，在谈到“嵌入式系统”领域时，往往理解成计算机专业领域的，基于32位嵌入式处理器，从事网络、通信、多媒体等的应用。这样，“单片机”与“嵌入式系统”形成了嵌入式系统中常见的两个独立的名词。但由于“单片机”是典型的、独立发展起来的嵌入式系统，从学科建设的角度出发，应该把它统一成“嵌入式系统”。考虑到原来单片机的电子系统底层应用特点，可以把嵌入式系统应用分成高端与低端，把原来的单片机应用理解成嵌入式系统的低端应用，含义为它的底层性以及与对象系统的紧耦合。