系统架构设计笔记（64）—— 嵌入式系统设计

嵌入式系统设计的主要任务是定义系统的功能 、 决定系统的架构，并将功能映射到系统实现架构上。这里，系统架构既包括软件系统架构也包括硬件系统架构。一种架构可以映射到各种不同的物理实现，每种实现表示不同的取舍，同时还要满足某些设计指标，并使其他的设计指标也同时达到最佳化。

嵌入式系统的设计方法跟一般的硬件设计 、 软件开发的方法不同，是采用硬件和软件协同设计的方法，开发过程不仅涉及软件领域的知识，还涉及硬件领域的综合知识，甚至还涉及机械等方面的知识。要求设计者必须熟悉并能自如地运用这些领域的各种技术，才能使所设计的系统达到最优。

虽然嵌入式系统应用软件的设计方案随应用领域的不同而不同，但是嵌入式系统的分析与设计方法也遵循软件工程的一般原则，许多成熟的分析和设计方法都可以在嵌入式领域得到应用。嵌入式系统的开发过程同样也包括需求分析 、 系统设计 、 实现和测试几个基本阶段，并且每个阶段都有其独有的特征和重点。

1 嵌入式系统设计概述

进行嵌入式系统设计前，应明确嵌入式系统设计本身的特点及衡量嵌入式系统设计的一些主要的技术指标。

1.1 嵌入式系统设计的特点

与通常的系统设计相比，嵌入式系统设计具有以下特点：

1. 软、硬件协同并行开发；
2. 微处理器的类型多种多样；
3. 实时嵌入式操作系统具有多样性；
4. 与通用系统开发相比，可利用系统资源很少；
5. 应用支持少；
6. 要求特殊的开发工具；
7. 软、硬件都要很健壮；
8. 调试很困难。

1.2 嵌入式系统的技术指标

嵌入式系统设计的常用指标有：
（1） NRE 成本（非重复性工程成本）：设计系统所需要支付的一次性货币成本，即一旦设计完毕，不需要支付额外的设计费用，就可以制造任意数目的产品。

（2）单位成本：生产单个产品所需要支付的货币成本，不包含 NRE 成本。

（3）大小：指系统所占的空间，对软件而言，一般用字节数来衡量；对硬件而言，则用逻辑门或晶体管的数目来衡量。

（4）性能：系统完成规定任务所需要的时间，是设计时最常用的设计指标，主要有两种衡量方式，一是响应时间，即开始执行到任务结束之间的时间。二是完成量，即单位时间内所完成的任务量。

（5）功率：系统所消耗的功率，它决定了电池的寿命或电路的散热需求。

（6）灵活性：在不增加 NRE 成本的前提下，改变系统功能的能力。

（7）样机建立时间：建立系统可运行版本所需的时间，系统样机可能比最终产品更大更昂贵，但可以验证系统的用途和正确性，改进系统的功能。

（8）上市时间：从系统开发到可以上市卖给消费者的时间，最主要的影响因素包括设计时间 、 制造时间和检测时间。

（ 9 ）可维护性：系统推出或上市后进行修改的难易程度，特别是针对非原始开发人员进行的修改。

（ 10 ）正确性：正确实现了系统的功能，可以在整个设计过程中检查系统的功能，也可以插入测试电路检验是否正确。

（ 11 ）安全性：系统不会造成伤害的概率。各个设计指标之间一般是互相竞争的，改良了某个指标常常会导致其他指标的恶化，

为了最好地满足设计最佳化，设计者必须了解各种软 、 硬件的实现技术，并且能够从一种技术转移到另一种技术，以便找到特定约束下的最佳方案。

1.3 嵌入式系统的设计挑战

嵌入式系统设计所面临的挑战有以下几个方面。

（1）需要多少硬件：设计者对用于解决问题的计算能力有较强的控制能力，不仅可以选择使用何种处理器，而且可以选择存储器的数量 、 所使用的外设等，因为设计不仅要满足性能的需求，还要受到制造费用的约束，硬件的选择十分重要，硬件太少，将达不到功能和性能的要求，硬件过多又会使产品过于昂贵。

（2）如何满足时限：使用提高处理器速度的方法使程序运行速度加快来解决时间约束的方法是不可取的，因为这样会使系统的价格上升。同时，提高了处理器的时钟频率，有时并不能提高执行速度，因为程序的速度有可能受存储系统的限制。

（3）如何减少系统的功耗：对采用电池供电的系统，功耗是一个十分敏感的问题。对于非电池供电的系统，高功率意味着高散热。降低系统功耗的一种方法是降低它的运算速度，但是单纯地降低运算速度显然会导致性能不能满足，因此，必须认真设计在降低功耗的同时满足性能的约束。

（4）如何保证系统的可升级性：系统的硬件平台可能使用几代，或者使用同一代的不同级别的产品，这些仅需要一些简单的改变，设计者必须通过改变软件来改变系统的特性，设计一种机器使它能够提供现在仍未开发的软件的性能。

（5）如何保证系统的可靠性：可靠性是产品销售时一项重要的指标，产品能够很好地工作是消费者的合理要求，可靠性在一些系统中尤为重要，如安全控制系统。

（6）测试的复杂性：测试一个嵌入式系统比仅仅输入一些数据困难得多，所以不得不运行整台机器以产生正确的数据，数据产生的时间是十分重要的，即不能离开嵌入式系统工作的整个环境来测试嵌入式系统。

（7）可视性和可控制性有限：嵌入式系统通常没有显示设备和键盘，这将导致开发者很难了解系统内部发生了什么，也不能响应系统的动作，有时候不得不通过观察微处理器的信号来了解。在实时系统中，一般无法为了观察而让系统停机。

（8）开发环境受限：嵌入式系统的开发环境，如开发软件 、 硬件工具通常比通用计算机或工作站上的可用环境更为有限，故只能采用交叉式开发，给开发进度带来很大影响。

2 开发模型与设计流程

与通用系统的开发类似，嵌入式系统的开发也可以采用软件工程中常见的开发模型，主要包括瀑布模型 、 螺旋模型 、 逐步求精模型及层次模型。

2.1 常用开发模型

（1）瀑布模型

瀑布模型由五个主要阶段构成：需求分析阶段确定目标系统的基本特点；系统结构设计阶段将系统的功能分解为主要的构架；编码阶段主要进行程序的编写和调试；测试阶段检测错误；最后一个是维护阶段，主要负责修改代码以适应环境的变化，并改正错误 、 升级。各个阶段的工作和信息总是由高级的抽象到较详细的设计步骤单向流动，是一个理想的自顶向下的设计模型。

（2）螺旋模型

螺旋模型假定要建立系统的多个版本，早期的版本是一个简单的试验模型，用于帮助设计者建立对系统的直觉和积累开发此系统的经验，随着设计的进展，会创建更加复杂的系统。在每一层设计中，设计者都会经过需求分析 、 结构设计 、 测试三个阶段。在后期，当构成更复杂的系统版本时，每一个阶段都会有更多的工作，并需要扩大设计的螺旋，这种逐步求精的方法使设计者可以通过一系列的设计循环加深对所开发的系统的理解。螺旋的顶部第一个循环是很小很短的，而螺旋底部的最后的循环加入了对螺旋模型的早期循环的细节补充，螺旋模型比瀑布模型更加符合实际。

（3）逐步求精模型

逐步求精模型是一个系统被建立多次，第一个系统被作为原型，其后逐个将系统进一步求精。当设计者对正在建造的系统的应用领域不是很熟悉时，这个方法很有意义。通过建造几个越来越复杂的系统，从而精炼系统，使设计者能检验架构和设计技术。此外，各种迭代技术也可仅被局部完成，直到系统最终完成。

（4）层次模型

许多嵌入式系统本身是由更多的小设计组成的，完整的系统可能需要各种软件构件 、 硬件构件。这些部件可能由尚需设计的更小部件组成，因此从最初的完整系统设计到为个别部件的设计，设计的流程随着系统的抽象层次的变化而变化，从最高抽象层次的整体设计到中间抽象层次的详细设计，再到每个具体模块的设计，都是逐层展开的，其中每个流程可能由单个设计人员或设计小组来承担，每个小组依靠其他小组的结果，各个小组从上级小组获得要求，同时上级小组依赖于各个分组设计的质量和性能。而且，流程的每个实现阶段都是一个从规格说明到测试的完整流程。

2.2 嵌入式系统的设计方法

一个良好的嵌入式系统设计方法是十分重要的，这是因为：
（1）良好的设计方法可以使设计者清楚地了解他们所做工作的进度，这样可以确保不遗漏其中的任何一项工作。
（2）允许使用计算机辅助工具帮助设计者进行工作，将整个过程分成几个可控的步骤进行。
（3）良好的设计方法方便设计团队的成员之间相互交流，通过定义全面的设计过程，使团队里的每个成员可以很好地理解他们所要做的工作及完成分配给他们的任务时所达到的目标。

嵌入式系统软件的开发过程可以分为项目计划 、 可行性分析 、 需求分析 、 概要设计 、 详细设计 、 程序建立 、 下载 、 调试 、 固化 、 测试及运行等几个阶段。

项目计划 、 可行性分析 、 需求分析 、 概要设计及详细设计等几个阶段，与通用软件的开发过程基本一致，都可按照软件工程方法进行，如采用原型化方法 、 结构化方法等。

由于嵌入式软件的运行和开发环境不同，开发工作是交叉进行的， 所以每一步都要考虑到这一点。

程序建立阶段的工作是根据详细设计阶段产生的文档进行的。这一阶段的工作主要是源代码编写 、 编译 、 链接等几个子过程，这些工作都是在宿主机进行的，不需要用到目标机。

产生应用程序的可执行文件后，就要用到交叉开发环境进行调试，根据实际情况可以选用可用的几种调试方法之一或它们的有效组合来进行。

嵌入式系统设计不同于传统的软件设计，如图 1 所示。经常包含硬件设计和软件设计，其中前端活动，如规格说明和系统架构，需要同时考虑硬件和软件两个方面。

当 FSM 被用于嵌入式系统设计时，其输入和输出的数据类型都是布尔类型，而函数表示含有布尔运算的布尔函数，这种模型对于没有数据输入或输出的很多纯控制系统而言已经足够。

如果要处理数据，则将 FSM 扩展为带有数据路径的状态机（ FSM with Datapath， FSMD）。另外，对状态机模型可以进一步扩展以支持分级和并发，这种模型称为分级 / 并发 FSM （Hierarchical / Concurrent FSM ，HCFSM ）模型。

5.2 数据流模型

数据流模型是并发多任务模型派生出的一种模型，该模型将系统的行为描述为一组结点和边，其中结点表示变换，边表示从一个结点到另一个结点的数据流向。每个结点使用来自其输入边的数据，执行变换并在其输出边上产生数据。每条边可能有或没有数据，出现在边上的数据称为令牌，当某个结点的所有输入边都至少有一个令牌时，该结点可触发。结点触发后，将使用来自每条输入边的一个令牌，对所有使用的令牌进行数据变换，并在输出边上产生一个令牌，结点的触发仅决定于令牌出现的情况。

图 4 所示是计算 z=(a+b)×(c-d) 的数据流模型。目前，已有若干商业化的工具支持用图形化语言表达数据流模型，这些工具可以自动将数据流模型转换为并发多任务模型，以便在微处理器上实现。其转换方法为将每个结点转换为一个任务，每条边转换为一个通道，其中并发多任务模型的实现方法是使用实时操作系统对并发任务进行映射。

来源：Deniro Lee