嵌入式系统原理与开发(第三版)课件：系统设计技术

基于网络的嵌入式系统设计7.1引言7.2设计流程 7.3需求分析与规格说明7.4系统分析与体系结构设计

7.1引言

多数真正的嵌入式系统的设计实际上是很复杂的，其功能要求非常详细，且必须遵循许多其他要求，如成本、性能、功耗、质量、开发周期等。大多数嵌入式系统的复杂程度使得无法由个人设计和完成，而必须在一个开发团队中相互协作来完成。这样就使得开发人员必须遵循一定的设计过程，明确分工，相互交流并达成一致。

设计过程还会受到内在和外在因素的影响。外在影响包括如消费者的变化、需求的变化、产品的变化以及元器件的变化等。内在影响包括如工作的改进、人员的变动等。

这些都要求嵌入式系统开发人员必须掌握一定的系统设计方面的技术。因此，本章我们将研究设计方法学方面的一些知识；7.2节介绍嵌入式系统的设计流程，内容包括嵌入式系统开发的一般过程和通常采用的一些设计流程；7.3节介绍系统定义过程中进行需求分析和规格说明的方法；7.4节介绍在规格说明的基础上如何进行系统的体系结构设计。

7.2设计流程

7.2.1开发过程

嵌入式系统是专用的计算机系统，运行在特定的目标环境中，需要同时满足功能和性能等方面的要求。在嵌入式系统的开发过程中，要考虑到实时性、可靠性、稳定性、可维护性、可升级、可配置、易于操作、接口规范、抗干扰、物理尺寸、重量、功耗、成本、开发周期等多种因素。良好的设计方法在嵌入式系统的开发过程中是必不可少的。首先，好的方法有助于规划一个清晰的工作进度，避免遗漏重要的工作，例如性能的优化和可靠性测试对于一个合格的嵌入式产品而言是不可或缺的。其次，采用有效的方法可以将整个复杂的开发过程分解成若干可以控制的步骤，通过一些先进计算机辅助设计工具的辅助，我们可以按部就班、有条不紊地完成整个项目。最后，通过定义全面的设计过程，可以使整个开发团队的各个成员更好地理解自身的工作，方便成员之间相互交流与协作。在嵌入式系统的开发过程中，团队的概念至关重要。图7-1嵌入式系统开发的一般过程

1．系统定义阶段

系统定义阶段需要确定系统开发最终实现的目标、实现目标的可行性、实现目标应采用的策略、估计完成系统开发所需的资源和成本、制定工程进度安排计划。这一阶段的工作主要包括了系统定义、可行性分析、需求分析和规格说明这四方面的内容。其中，需求分析是指从用户那里搜集系统的非形式描述。以此为基础进一步提炼，得到系统的规格说明，并以此来设计系统的体系结构和系统构件。

通常，用户仅了解和关心实际使用问题及需要具备的功能，但是往往不能完整、准确地表达这种需求，更不清楚怎样利用计算机去实现所需的功能。为了对系统进行准确无误地定义，就要求开发人员和用户之间充分交流，开发人员需要详细考察，最终得出经用户确认的、明确的系统实现逻辑模型。

需求可分为功能部分和非功能部分。非功能性需求包括性能、价格、物理尺寸和重量、功耗等方面的因素。

确认需求最好的方法是建立模型。模型可以使用原始数据来模拟功能，并可以在计算机上运行。模型还应让用户了解系统是如何工作的，以及用户如何与系统交互。通常，系统的非功能模型可以让用户了解系统的特性。

对一个大型的系统进行系统定义和需求分析是一件繁琐的工作，可以从先获取相对少量的、简单的信息入手。表7-1为一个简单的需求表格的样本。

名称——给项目取一个好的名称，可以使设计目的更加明确，也便于交流、讨论时使用。

目的——用最精炼的语言来描述清楚系统需要满足的需求。

输入和输出——系统的输入和输出包含了大量的细节，如数据类型，包括模拟信号、数字信号、机械输入等；数据特性，包括周期性或非周期性数据、用户的输入、数据位数等；I/O设备类型，包括按键、ADC、显示器等。

功能——功能的描述可以从对输入到输出的分析中得出，如当系统接收到输入时，执行哪些动作；用户通过界面输入的数据如何对该功能产生影响；不同功能之间如何相互作用。

性能——系统控制物理设备或者处理外界输入的数据都需要花费一定的时间。在大部分情况下，嵌入式系统在计算时间上都有要求，因此从系统定义和需求分析开始，这种性能的要求就必须明确，并在执行过程中加以认真考虑，以便随时检查系统能否满足其性能要求。系统的处理速度通常又是系统实用性和成本的主要决定因素。在大多数情况下，软件的性能在很大程度上决定了系统的性能。

生产成本——产品的成本会影响其价格。成本包含两个主要部分：生成成本，包括购买构件以及组装费用等；不可再生的工程成本，包括人力成本以及设计费用等。生产成本主要包括的是硬件成本。通过对硬件成本的估计，可以大略估计产品形成后的价格；或者，基于产品最终的粗略价格来计算构建系统可以使用的硬件构件，因为价格最终会影响系统的体系结构。

功耗——由电池供电的系统必须对功耗问题认真考虑。而系统的功耗需要在设计开始时就至少有一个粗略的了解。通常，基于这种了解可以使开发者决定系统是采用电池供电还是采用市电。

物理尺寸和重量——产品的物理尺寸和重量因使用领域的不同而不同。例如，对飞机上的电子设备，其重量应严格限制。又如，手持设备对系统的物理尺寸和重量都有严格限制。对系统的物理尺寸和重量有一定的了解，有助于系统体系结构的设计。

需求分析需要对其内部一致性进行检查。规格说明可以使设计者花费最少的时间和精力创建一个工作系统。规格说明应该足够明晰，以便别人可以验证它是否符合系统需求并且完全满足客户的期望；亦不能有歧义，设计者应知道什么是他们需要构造的。设计者可能碰到各种不同类型的由于不明确的规格说明而导致的问题。

2．总体设计阶段

总体设计是设计的第一步，其目的是描述系统如何实现由系统定义规定的那些功能。它需要解决嵌入式系统的总体构架，从功能实现上对软硬件进行划分；在此基础上，选定处理器和基本接口器件；根据系统的复杂程度确定是否使用操作系统，以及选择哪种操作系统；此外，还需要选择系统的开发环境。

本阶段应提供系统总体设计报告，推荐一个基本的软硬件配置方案，包括系统中各模块间的接口关系。确立总体方案时，要使用系统流程图或其他工具，描述每一种可能的系统组成，估计每一种方案的成本和效益，最终使总体方案建立在充分权衡各种方案利弊的基础上。总体设计中对系统体系结构的描述必须同时满足功能上和非功能上的需求。一般地，功能约束在构建系统总体框图时集中考虑，而非功能约束在构建硬件和软件体系结构时考虑。在构建体系结构时对非功能约束的估算部分来源于经验，而建造一个简化的模型往往有助于做出更精确的估算。

3．构件设计阶段

构件通常包括硬件和软件两部分。构件设计使得构件、体系结构和规格说明相一致。

一些构件是标准的，可以直接使用，如CPU和存储器。如果采用标准数据库，我们就可以用标准例程对该数据库进行访问。这些数据库中的数据不仅使用预定义的格式，而且被高度压缩以节省存储空间。在这些访问函数中使用标准软件不仅节约设计时间，而且有可能较快地实现如数据解压缩这样的专用函数。

4．系统集成与性能测试阶段

系统集成与性能测试阶段的工作包括将测试完成的软件系统装入制作好的硬件系统中，进行系统综合测试，验证系统功能是否能够准确无误地实现，各方面指标是否符合设计要求，最后将正确无误的软件固化在目标硬件中。在系统集成阶段通常会发现错误。按阶段构建系统并正确运行选好的测试，可以更容易地找出这些错误。如果每次只对一部分模块排错，则可以更容易地发现和识别较简单的错误。也只有在早期修正这些简单的错误，才能发现那些只有在系统高负荷时才能确定的、较复杂、较含混的错误。因此，我们必须确保能够在体系结构和构件设计阶段尽可能容易地按阶段组装系统和相对独立地测试系统功能。7.2.2设计流程

1．瀑布模型图7-2软件开发的瀑布模型

2．螺旋模型

瀑布模型假设系统被一次性整体建立，而螺旋模型假设要建立系统的多个版本，早期的版本只是一个简单的实验模型，用于帮助设计者建立对系统的直观认识和积累开发此系统的经验。随着设计的进行，会创建更加复杂的系统，在每一层设计中，设计者都会经过需求、结构设计和测试阶段。后期，当构成更复杂的系统版本时，每一个阶段都会有更多的工作，并需要扩大设计的螺旋。这种逐步求精的方法使得设计者可以通过一系列的设计循环加深对所开发系统的理解。图7-3软件设计的螺旋模型3．逐步求精图7-4逐步求精开发模型

4．分层设计流程

许多复杂的嵌入式系统自身是由更多的小设计组成的。完整的系统可能需要有效的软件构件、专用的集成电路(ASIC)等，而且这些部件又可能由尚需设计的更小的部件组成。从最抽象的完整系统设计到为个别部件的设计，设计流程随着系统中的抽象层次而变化。流程的实现阶段从规格说明到测试，本身是一个完整的流程。在一个大项目中，每一个流程可能会由单独的人或小组来完成，每个组必须依靠其他组的结果。各个分组从上级小组获得要求，同时上级小组依靠各个分组的设计质量和测试性能。充分交流在这样的大项目中非常重要。其设计流程如图7-5所示。图7-5嵌入式系统分层设计工作流程

5．并行工程

当众多的设计者一起设计一个大系统时，非常容易偏离完整的设计流程，导致每个设计者对自己在设计流程中的角色产生狭隘的看法。并行工程试图采用一种更宽的方法，使整个流程优化。对于并行工程而言，缩减设计时间是一个重要的目标，它为设计流程的很多方面提供了捷径，例如可靠性、性能、功耗等。特别需要指出的是，要从并行工程中获得最多收益，通常需要消除设计和制造之间的隔阂。为了获得最优结果，需要注意以下几点：

(1)交叉功能组应包括来自不同学科的成员，包括制造业、硬件/软件设计和市场营销等。

(2)并行产品实现过程的活动是并行工程的中心。同时做几件事，例如同时设计几个不同的子系统，减少设计时间是关键性的。

(3)递增的信息共享和使用将有助于减少并行产品的实现导致意外的可能性。一旦新的信息可用，它就被共享并且集成到设计中。交叉功能组对于及时和高效的信息共享是很重要的。

(4)综合的工程管理保证有人对整个工程负责，而且这种职责决不能在工程的某一方面一旦完成就放弃。

(5)提供商尽早地和不间断地参与，有助于充分利用提供商的能力。

(6)客户尽早地和不间断地关注，有助于确保产品能最好地满足其需要。

6．其他

软件工程的方法直接影响到设计流程。目前，软件开发过程结合了面向对象的方法和第四代工具。该方法针对嵌入式系统还在不断完善。

在基于面向对象的开发过程中，开发组成员可以遵循并行过程的方法，并发地设计组件。例如，一个小组设计设备驱动程序，另一个小组设计错误处理程序，还有一个小组设计应用程序。

第四代软件工具能够根据较高级的设计规范生成代码，例如自动报表生成、自动高级图形生成、创建数据库查询以及在创建网站时自动生成HTML代码等。

总之，不断改进的模型，其过程的生命周期是迭代的，直到进行验证、确认和交付或安装到系统的ROM中为止。 7.3需求分析与规格说明

7.3.1需求分析

创建一个需求文档的目的是使用户和设计者可以有效地交流。设计者应该知道用户期望他们设计什么，而用户应该明白他们将得到什么。

需求有两种类型：功能性需求和非功能性需求。一个功能性需求说明了这个系统必须做什么，例如FFT运算。一个非功能性需求可以是其他属性中的一些性质，包括物理尺寸、价格、功耗、开发周期、可靠性等。

一套好的需求分析应该满足以下测试要求：

(1)正确性。需求不能错误地描述用户的要求。正确性还包括应该避免超出需要的需求，需求不应该加上那些不必要的条件。

(2)无二义性。需求文档应该清晰，并且只用一种明确的语言解释。

(3)完整性。所有的需求都应该被包括。

(4)可检验性。应该有一个有效的方法来确保最后的产品满足每一种需求。例如，在不符合“吸引力”定义的情况下，一个想使系统组装吸引人的需求是很难验证的。

(5)一致性。一个需求不能和另一个需求相矛盾。

(6)可修改性。需求文档应结构化，以便在不影响一致性、可检验性等情况下可以被修改以适应变化的需求。

(7)可追踪性。每个需求应满足以下可追踪性：

——可以追踪需求知道每个需求存在的价值。

——可以追踪需求之前创建的文档来理解它们如何与最终的需求相关联。

——可以向前追踪来理解每个需求在实现中如何被满足。

——可以向后追踪以便知道哪一个需求是用户满意的。7.3.2规格说明

1．SDL

SDL(SystemDescriptiveLanguage，系统描述语言)是一种广泛使用的状态机规格说明语言，这种语言是通信产业为通信协议、电话系统等开发的。如图7-6所示，SDL规格说明包括状态、操作以及状态间有条件的和非条件的转换。SDL是一个面向事件的状态机模型，状态间的转换由内部或外部事件引发。图7-6SDL规格说明语言

2．状态图表

状态图表是一种常用的基于状态的规格说明的方法，它基于一种事件驱动模型建立。状态图表允许状态被组合在一起表示普通的功能。两种基本的组合是OR(或)和AND(与)。图7-7通过用OR状态描述的状态图表与传统的状态转换图的比较演示了一个OR状态的例子。该状态机描述了当s1、s2、s3收到输入i2时，机器将从s1、s2、s3的任一状态转换到状态s4。状态图表也可以通过在s1、s2、s3周围标出OR状态来表示这种特性。s123是OR状态的名字，在状态上方的小方块中给出。从OR状态s123出来的唯一转换表明了状态机处于s123包括的任意一个状态时，若接收到i2输入，状态机都会进入状态s4。OR状态不但允许成员状态间的相互转换，还允许内部状态间的相互转换(例如从s1到s3、从s2到s3)。OR状态仅仅是表明与这些状态相关的转换的一种工具。图7-7状态图表中的OR状态图7-8状态图表中的AND状态

3．AND/OR表

图7-9演示了一个AND/OR表的例子及其所描述的布尔表达式。AND/OR表中的每一行用表达式中的基本变量标记。每一列相当于表达式中的一个AND项。例如，AND项(条件2与非条件3)在第二列中用使条件2为真、条件3为假、条件1忽略来表示，这就相当于AND条件要为真时，必须有条件2为真且条件3为假。我们用这种表来估计一个给定的条件在系统中是否有效。变量的当前状态与表中的元素相比较，如果所有当前变量的值与该列中给定的要求的值相等，则该列的值就为真。当我们期望一个AND/OR表达时，若列中任一值为真，则这个表为真。这个符号表和状态图表最大的不同在于“否”的情况在表中明确地表示了出来。实践证明，这样的表示对在一个规格说明表中寻找问题有很大帮助。图7-9AND/OR表

7.4系统分析与体系结构设计

把一个规格说明变成一种体系结构设计，这对于理解一个复杂系统的整体结构是一种非常有用的方法。

CRC卡方法是帮助分析一个系统结构的一种普遍、实用的方法。由于它支持封装数据和功能，因此特别适用于面向对象的设计。

缩写CRC代表此方法所要确认的以下三个主要项目：

类(Class)——定义了数据和功能的逻辑分组。

责任(Responsibility)——描述类所要做的工作。

协作者(Collaborator)——与给定类相关的其他类。图7-10CRC卡示意图

对于计算机系统设计而言，CRC卡方法似乎是一种比较原始的方法。然而，它有一些重要的优点。首先，它很容易让非计算机专业人员来创建CRC卡。在系统设计中，获得领域专家的忠告是非常重要的，这些专家可能是擅长汽车电子设备方面的汽车设计人员，也可能是从事PDA设计的人类遗传因子研究方面的权威人士。CRC卡方法很简便，所以它对非计算机领域的专家使用此方法并不产生影响，而且还允许收集他们的输入信息。其次，通过鼓励领域专家分组工作和分析情况，可以很好地帮助计算机专家进行工作。在CRC卡方法中运用的预排过程对于明确设计范围和决定系统的哪一部分未被充分地理解是非常有用的。在基于工具的设计和编码中这种简便方法很有价值。而软件工程工具对自动创建CRC卡非常有效。

在CRC卡方法中，类的应用实际上更像面向对象编程语言中的对象—— CRC卡类习惯于表示系统中的一个实体，CRC卡类可以很容易变为面向对象设计中的类定义。

用CRC卡分析系统时，应该按下列步骤进行：

(1)设计类的初始清单。写下类的名称和一些