嵌入式系统设计的主要任务是定义系统的功能 、 决定系统的架构，并将功能映射到系统实现架构上。这里，系统架构既包括软件系统架构也包括硬件系统架构。一种架构可以映射到各种不同的物理实现，每种实现表示不同的取舍，同时还要满足某些设计指标，并使其他的设计指标也同时达到最佳化。
嵌入式系统的设计方法跟一般的硬件设计 、 软件开发的方法不同，是采用硬件和软件协同设计的方法，开发过程不仅涉及软件领域的知识，还涉及硬件领域的综合知识，甚至还涉及机械等方面的知识。要求设计者必须熟悉并能自如地运用这些领域的各种技术，才能使所设计的系统达到最优。
虽然嵌入式系统应用软件的设计方案随应用领域的不同而不同，但是嵌入式系统的分析与设计方法也遵循软件工程的一般原则，许多成熟的分析和设计方法都可以在嵌入式领域得到应用。嵌入式系统的开发过程同样也包括需求分析 、 系统设计 、 实现和测试几个基本阶段，并且每个阶段都有其独有的特征和重点。
1 嵌入式系统设计概述
进行嵌入式系统设计前，应明确嵌入式系统设计本身的特点及衡量嵌入式系统设计的一些主要的技术指标。
1.1 嵌入式系统设计的特点
与通常的系统设计相比，嵌入式系统设计具有以下特点：
- 软、硬件协同并行开发；
- 微处理器的类型多种多样；
- 实时嵌入式操作系统具有多样性；
- 与通用系统开发相比，可利用系统资源很少；
- 应用支持少；
- 要求特殊的开发工具；
- 软、硬件都要很健壮；
- 调试很困难。
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 所示。经常包含硬件设计和软件设计，其中前端活动，如规格说明和系统架构，需要同时考虑硬件和软件两个方面。
类似的，后端设计，如系统集成和测试要考虑整个系统。在中间阶段中，软件和硬件构件的开发彼此相互独立，并且大多数的硬件和软件的工作能够相对独立地进行。最后，要将经调试后正确无误的可执行程序固化到目标机上。
根据嵌入式系统硬件上配置的不同，固化有几种方式，可以固化在 EPROM 和 FLASH 等存储器中，也可固化在 DOC 和 DOM 等电子盘中。通常还要借助一些专用编程器进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高，所以在对嵌入式系统进行白盒测试时，要求有更高的代码复盖率。
在系统开发流程的各个阶段，分别要进行系统的确认和性能评估 、 安全性评估及风险性评价，并对系统的实现进行测试验证。
3 嵌入式系统设计的核心技术
嵌入式系统的开发是软 、 硬件综合开发，与通用系统的开发存在巨大差异，一方面是因为每个嵌入式系统都是一个软硬件的结合体；另一方面，嵌入式系统一旦研制完成，软件便随着硬件固化到产品中，具有很强的专用性。在这些特点的影响下，必然要有一种不同于通用软件开发过程的工程方法学来支持嵌入式系统的开发过程，同时，这些特点也决定了嵌入式系统开发所采用的独特的核心技术。
总体来看，在嵌入式开发领域，主要有三种核心技术：处理器技术 、 IC 技术 、 设计 / 验证技术。
3.1 处理器技术
处理器技术与实现系统功能的计算引擎结构有关，很多不可编程的数字系统也可以视为处理器，这些处理器的差别在于其面向特定功能的专用化程度，导致其设计指标与其他处理器不同。
（1）通用处理器
这类处理器可用于不同类型的应用，一个重要的特征就是存储程序，由于设计者不知道处理器将会运行何种运算，所以无法用数字电路建立程序。另一个特征就是通用的数据路径，为了处理各类不同的计算，数据路径是通用的，其数据路径一般有大量的寄存器及一个或多个通用的算术逻辑单元。设计者只需要对处理器的存储器编程来执行所需的功能，即设计相关的软件。
在嵌入式系统中使用通用处理器具有设计指标上的一些优势。上市时间和 NRE 成本较低，因为设计者只需编写程序，而不需做任何数字设计，灵活性高，功能的改变通过修改程序进行即可。与自行设计处理器相比，数量少时单位成本较低。
当然，这种方式也有一些设计指标上的缺陷，数量大时单位成本相对较高，因为数量大时，自行设计的 NRE 成本分摊下来，可降低单位成本。同时，对于某些应用，性能可能很差。由于包含了非必要的处理器硬件，系统的体积和功耗可能变大。
NRE是Non-Recurring Engineering的缩写，NRE费用即一次性工程费用，是指集成电路生产成本中非经常性发生的开支，明确地说就是新的集成电路产品的研制开发费。新产品开发过程中的设计人工费，设计用计算机软硬件设备折旧费以及试制过程中所需的制版，工艺加工，测试分析等费用都是研发过程中的一次性开支，称为NRE。这些费用有赖大量生产后的利润赚回。
（2）单用途处理器
单用途处理器是设计用于执行特定程序的数字电路，也指协处理器 、 加速器 、 外设等。如 JPEG 编码解码器执行单一程序，压缩或解压视频信息。嵌入式系统设计者可通过设计特定的数字电路来建立单用途的处理器。
设计者也可以采用预先设计好的商品化的单用途处理器。在嵌入式系统中使用单用途处理器，在指标上有一些优缺点。这些优缺点与通用处理器基本相反，性能可能更好，体积与功率可能较小，数量大时单位成本可能较低，而设计时间与 NRE 成本可能较高，灵活性较差，数量小时单位成本较高，对于某些应用，性能不如通用处理器。
（3）专用处理器
专用指令集处理器是一个可编程处理器，针对某一特定类型的应用进行最优化。这类特定应用具有相同的特征，如嵌入式控制 、 数字信号处理等。在嵌入式系统中使用专用处理器可以在保证良好的性能 、 功率和大小的情况下，提供更大的灵活性，但这类处理器仍需要昂贵的成本建立处理器本身和编译器。单片机和数字信号处理器是两类应用广泛的专用处理器，数字信号处理器是一种针对数字信号进行常见运算的微处理器，而单片机是一种针对嵌入式控制应用进行最佳化的微处理器。
3.2 IC 技术
从系统的集成电路设计描述得到实际芯片的物理映射过程的实现技术便是 IC （ Integrated Circuits ，集成电路）技术，当前在半导体领域的三类实现技术，即全定制 、 半定制和可编程技术均可应用于嵌入式系统的硬件设计。
（1）全定制 / VLSI （ Very Large Scale Integrated Circuites ，超大规模集成电路）。在全定制 IC 技术中，需要根据特定的嵌入式系统的数字实现来优化各层设计人员从晶体管的版图尺寸 、 位置 、 连线开始设计以达到芯片面积利用率高 、 速度快 、 功耗低的最优化性能。利用掩膜在制造厂生产实际芯片，全定制的 IC 设计也常称为 VLSI ，具有很高的 NRE 成本 、 很长的制造时间，适用于大量或对性能要求严格的应用。
（2）半定制/ASIC （ Application Specific Integrated Circuit ，专用集成电路）。半定制ASIC 是一种约束型设计方法，包括门阵列设计法和标准单元设计法。它是在芯片制作好一些具有通用性的单元元件和元件组的半成品硬件，设计者仅需要考虑电路的逻辑功能和各功能模块之间的合理连接即可。这种设计方法灵活方便 、 性价比高，缩短了设计周期，提高了成品率。
（3）可编程/ASIC 。可编程器件中所有各层都已经存在，设计完成后，在实验室里即可烧制出设计的芯片，不需要 IC 厂家参与，开发周期显着缩短。可编程ASIC 具有较低的 NRE 成本，单位成本较高，功耗较大，速度较慢。
3.3 设计/ 验证技术
嵌入式系统的设计技术主要包括硬件设计技术和软件设计技术两大类。其中，硬件设计领域的技术主要包括芯片级设计技术和电路板级设计技术两个方面。芯片级设计技术的核心是编译 / 综合 、 库 / IP（ Intellectual Property ，知识产权） 、 测试 / 验证。
编译 / 综合技术使设计者用抽象的方式描述所需的功能，并自动分析和插入实现细节。库 / IP技术将预先设计好的低抽象级实现用于高级抽象。测试 / 验证技术确保每级功能正确，减少各级之间反复设计的成本。
软件设计技术的核心是软件语言。软件语言经历了从低级语言（机器语言 、 汇编语言）到高级语言（例如，结构化设计语言 、 面向对象设计语言）的发展历程，推动其发展的是汇编技术 、 分析技术 、 编译 / 解释技术等诸多相关技术。软件语言的级别也从实现级 、 设计级 、 功能级逐渐向需求级语言发展过渡。
早期，随着通用处理器概念的逐渐形成，软件技术迅速发展，软件的复杂度也开始增加，软件设计和硬件设计的技术和领域完全分开。设计技术和工具在这两个领域同步得到发展，也使得行为描述可以在越来越抽象的级别上进行，以适应设计复杂度不断增长的需要。这种同步发展如今又使得这两个领域都使用同样的时序模型来描述行为，因而这两个领域即将可能再度统一为一个领域。
鉴于大多数嵌入式系统都是实时的反应式系统，反应式系统具有多任务并发 、 时间约束严格与可靠性高的特点，针对反应式系统的设计和描述，人们相继提出了多种描述语言和验证方法学。例如，采用时序逻辑用来刻画反应式系统的性质及推理反应式系统的行为，采用模型检验技术验证反应式系统设计的正确性等，这些技术已逐步在嵌入式开发过程中发挥着重要的作用。
4 嵌入式开发设计环境
嵌入式系统的开发环境种类很多，大体可以把它们分为如下几类：
（1）与嵌入式操作系统配套的开发环境，属于这一类的开发环境较多，如 PalmOS、THOS、VxWorks、WindowsCE 等商业嵌入式操作系统都有与其配套的功能齐全的开发环境。
（2）与处理器芯片配套的开发环境。这类开发环境一般由处理器厂商提供，如 EPSON 公司推出的一个专门为基于 S1C33 系列微控制器芯片的嵌入式系统开发的工具包便是这一类型的开发环境。
（3）与具体应用平台配套的开发环境。这类开发环境针对性较强，如高通公司的 BrewSDK 等。
（4）其他类的开发环境。这类开发环境主要指一些嵌入式系统供应商在 GNU 开源工具的基础上开发或定制的较为通用的开发环境。这类工具可以免费获得，而且支持的处理器类型繁多，功能齐全，但在技术支持方面比专业化商业工具略逊一些。
5 嵌入式软件设计模型
随着嵌入式系统的功能日益复杂，要描述这些功能复杂的系统的行为也越来越困难，实践证明通过采用计算模型的方法来对系统进行描述和分析是一种具有工程价值的方法。计算模型提供一组用简单对象来组合复杂行为的方法，可以帮助设计者理解和描述系统行为。嵌入式系统常用的计算模型有如下几种：时序计算模型 、 通信进程模型 、 状态机模型 、 数据流模型 、 面向对象模型 、 并发进程模型。这些模型分别在不同的应用领域使用，如状态机模型特别适合描述以控制为主的系统，数据流模型可以很好地描述数据处理和转换问题。目前使用最广泛的是并发进程模型。
这些模型分别在不同的应用领域使用，如状态机模型特别适合描述以控制为主的系统，数据流模型可以很好地描述数据处理和转换问题。目前使用最广泛的是并发进程模型。
5.1 状态机模型
有限状态机（ Finite- State Machine ， FSM ）是一个基本的状态模型，可以用一组可能的状态来描述系统的行为，系统在任何时刻只能处于其中一个状态，也可以描述由输入确定的状态转移，最后可以描述在某个状态下或状态转移期间可能发生的操作。
假设当电梯上升或下降到所请求的楼层时，会开门 10 s，但在移动中不会打开且不会改变移动方向。
图 3 是电梯的控制单元的状态机描述。在初始 “ 空闲 ” 态，将 up 和 down 设置为 0 ， open 设置为 1。 在所请求的楼层不同于当前楼层之前，状态机一直停留在 “ 空闲 ” 状态。如果所请求的楼层大于当前楼层，则状态机转移到 “ 上升 ” 状态，并将 up 设置为 1。 如果所请求的楼层小于当前楼层，则状态机转移到 “ 下降 ” 状态，并将 down 设置为 1。 在当前楼层等于所请求的楼层之前，状态机一直留在 “ 下降 ” 或 “ 上升 ” 状态，然后状态转移到 “ 开门 ” 状态，并将 open 设置为 1。 通常，系统有一个计时器 timer ，因此，当状态机转移到 “ 开门 ” 状态时，还要将计时器启动，状态机停留在 “ 开门 ” 态，直到计时器超时，最后转移到 “ 空闲 ” 态。
当 FSM 被用于嵌入式系统设计时，其输入和输出的数据类型都是布尔类型，而函数表示含有布尔运算的布尔函数，这种模型对于没有数据输入或输出的很多纯控制系统而言已经足够。
如果要处理数据，则将 FSM 扩展为带有数据路径的状态机（ FSM with Datapath， FSMD）。另外，对状态机模型可以进一步扩展以支持分级和并发，这种模型称为分级 / 并发 FSM （Hierarchical / Concurrent FSM ，HCFSM ）模型。
5.2 数据流模型
数据流模型是并发多任务模型派生出的一种模型，该模型将系统的行为描述为一组结点和边，其中结点表示变换，边表示从一个结点到另一个结点的数据流向。每个结点使用来自其输入边的数据，执行变换并在其输出边上产生数据。每条边可能有或没有数据，出现在边上的数据称为令牌，当某个结点的所有输入边都至少有一个令牌时，该结点可触发。结点触发后，将使用来自每条输入边的一个令牌，对所有使用的令牌进行数据变换，并在输出边上产生一个令牌，结点的触发仅决定于令牌出现的情况。
图 4 所示是计算 z=(a+b)×(c-d) 的数据流模型。目前，已有若干商业化的工具支持用图形化语言表达数据流模型，这些工具可以自动将数据流模型转换为并发多任务模型，以便在微处理器上实现。其转换方法为将每个结点转换为一个任务，每条边转换为一个通道，其中并发多任务模型的实现方法是使用实时操作系统对并发任务进行映射。
5.3 并发进程模型
并发进程模型是由一组进程构成，每个进程是一个顺序执行的过程，各进程间可以并发执行。并发进程模型提供创建 、 终止 、 暂停 、 恢复和连接进程的操作。进程在执行中可以相互通信，交换数据。
进程间通信可以采用两种方式：共享变量和消息传递。信号量 、 临界区 、 管程和路径表达式等用来对并发进程的操作进行同步。通常，实时系统可以看成是由许多并发执行的进程构成的系统，其中每个进程都有时间要求。这样，很多嵌入式系统更容易用一组并发执行的任务来描述，因为这些系统本身就是多任务系统，并发进程模型便自然地可以由实时操作系统的多任务来实现。
5.4 面向对象模型
传统的并发进程模型是围绕进程的概念进行设计的，进程是一个实现级的概念，它是对客观世界活动的一种间接模拟，因此，采用进程模型来解决客观世界中的并发问题就显得极不自然，并且也使得并发程序难以设计和理解。
面向对象模型以一种更加直接的方式刻画客观世界中的活动，模型中存在着潜在的并发执行能力。一个对象向另一个对象发送消息后，若不需要或不立即需要消息的处理结果，前者不必等待后者处理消息，消息发送者和消息接受者可以并发执行。对象不都是处于被动的提供服务状态，它们中的一些除了能通过接收消息向外提供服务外，还可以有自己的事务处理。一个对象往往可以同时处理多个消息。对象是数据和操作的封装体，数据存放在对象的局部变量中，对象的状态由对象所有的局部变量在某一时刻的取值来表示。在并发环境中，还要考虑对象并发状态的描述问题，因为对象的并发控制是根据对象的并发状态来进行的。
把并发与面向对象相结合，归结起来可分为两条途径：
（1）在面向对象模型中引进并发机制，充分利用面向对象技术刻画客观世界的良好模型能力和面向对象的各个重要特性，同时把其潜在的并发能力描述出来，使其适合于描述并发计算。
（2）在传统并发模型中引进面向对象思想。
面向对象的并发模型可以分为两种类型：隐式并发模型和显式并发模型。
（1）隐式并发模型。这种模型的特点是推迟并发设计，将对象建模作为建模基础。在进入运行阶段之前，将对象看成自主单元，各种对象的活动看成理想并发方式完成的特定工作。就像每个对象拥有一个自己的处理器，这个处理器可以为对象提供一个执行线程。进入系统的外部事件被看成一个处理请求，以广播方式传给一些对象，这些对象接着向其他对象进一步提出处理请求。理论上，对应一个请求，可以有任意多个对象执行相应的处理。在实现时，由调度程序最终决定其对象的操作顺序。
（2）显式并发模型。这种模型的特点是首先考虑并发，应先把并发概念和对象概念分开。在建立对象以后，用实时操作系统支持的进程概念来表示并发，形成对象和进程两个抽象层次，即先将系统分解为准并发进程作为开始，而在每个进程的内部采用面向对象的技术。对象间交互表示成嵌套的函数调用，通过加入锁 、 监视器 、 信号量等显式同步机制，来保证对象的完整。该模型将进程置于对象之上，对象中不必考虑并发 、 对象串行化。
早期，实时系统的设计方法主要是结构化设计方法，采用结构化方法的系统在复用性 、 可修改性等方面有很大的局限性。面向对象的实时系统设计方法显然在这些问题上具有明显的优势。
6 需求分析
在设计之前，设计者必须知道要设计什么。通常人们用需求和规格说明来描述设计过程的这两个相关而不同的步骤。需求是用户所想要的非形式化的描述，而规格说明是可以用来创建系统架构的更详尽 、 更精确 、 更一致的描述。当然，需求和规格说明都是指导系统的外部表示，而非内部表示。
需求有两种类型：功能性需求和非功能性需求，功能性需求说明这个系统必须做什么，而非功能性需求说明系统的其他属性，如物理尺寸 、 价格 、 功耗 、 设计时间 、 可靠性等。对一个大系统进行需求分析是一项复杂而费时的工作，但是，获取少量格式清晰 、 简单明了的信息是理解系统需求的一个良好开端。
下表是在某项工程开始时填写的需求表格，在考虑系统的基本特征时可将该表格作为检查表。
名称 | 说明 | GPS 地图系统 |
目的 | 该项可以简单地列举一些有关将要满足的需求描述或主要特征 | 该系统为车辆驾驶员提供用户级移动地图 |
输入与输出 | 对系统输入输出包含了大量的细节 : 1. 数据类型 : 模拟信号 、 数字信号 、 机械输入；2.数据特征 : 周期性到达的数据，每个数据元素的位数；3. 输入 / 输出设备的类型 : 按键 、 模数转换器 、 视频显示。 | 输入 : 一个电源按钮，两个控制按钮；输出 : 逆光液晶显示屏，分辨率 400x600 。 |
功能 | 该项对系统所做的工作详细地描述，从输入到输出进行分析是提出功能的一种好方法 :当系统接收到输入时，执行哪些动作，输入的数据如何对该功能产生影响；不同的功能之间如何相互作用。 | 使用5种接收器的 GPS 系统，三种用户可选的分辨率，总是显示当前的经纬度。 |
性能 | 许多嵌入式系统都要花费一定的时间来控制物理设备，或从外界性能输入数据。多数情况下，这些计算必须在一定的时间内完成，因此对性能的要求必须尽早明确。 | 每 0.25s 更新一次屏幕显示 |
生产成本 | 主要指硬件的费用 | 100 美元 |
功耗 | 该项对功耗做一个粗略的估计，靠电池供电的系统需认真考虑 | 100 MW(兆瓦) |
物理尺寸和重量 | 对物理尺寸和质量有一定的了解有助于对系统架构的设计 | 不大于 2英寸 x 16 英寸， 12 盎司 |
这份需求表格内容是以 GPS （ Global Position System ，移动地图系统）为例编写的。移动地图系统是一种手持设备，针对在高速公路开车的用户或类似的用户而设计，该设备可从 GPS 上得到位置信息，为用户显示当前所在的位置及周围的地形图，地图的内容随着用户及设备所在位置的改变而改变。
需求分析阶段最重要的文档输出就是系统的规格说明。规格说明是精确反映客户需求并且作为设计时必须遵循的要求的一种技术文档。
在软件开发的过程中，规格说明非常重要。系统分析人员接受用户需求产生目标软件系统的规格说明，设计与编码人员根据规格说明，进行模块设计并最终产生程序代码，测试和验收人员验证最终软件是否符合规格说明。
规格说明应该是清晰的 、 无歧义的，否则由该规格说明建造系统可能不符合实际要求。目前，业界较为流行的方法是采用 UML 进行规格说明的描述。 UML 是一个通用的标准建模语言，可以对任何具有静态结构和动态行为的系统进行建模。 UML 适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。
在需求分析阶段，通过用例来捕获用户需求。通过用例建模，描述对系统感兴趣的外部角色及其对系统（用例）的功能要求。
分析阶段主要关心问题域中的主要概念（如抽象 、 类和对象等）和机制，需要识别这些类及它们相互间的关系，并用 UML 类图来描述。在分析阶段，只对问题域的对象（现实世界的概念）建模，而不考虑定义软件系统中技术细节的类（如处理用户接口 、 数据库 、 通信和并行性等问题的类）。
7 系统设计
7.1 设计工具
目前，嵌入式系统的设计工具可以分为两类：协同合成工具和协同模拟工具。
7.1.1 协同合成工具
当前，用于嵌入式开发的主要的协同合成工具有 POLIS 、 COSYMA 和 Chinook 等 。
POLIS ： POLIS 是 UC-Berkeley 开发的交互式嵌入式系统的软 、 硬件协同设计框架，它适用于小型控制系统的设计，系统描述支持基于 FSM （ Finite State Machine ）的语言。由于软 、 硬件均可透明地从同一 CFSM 描述中取得，设计空间的灵活性也相应增加，支持使用 PTOLEMY 的协同模拟，在描述及实现层均支持正式的验证，架构的支持受限，即硬件 CFSM 所包围的只有一个处理器，而且不支持共享内存 。
COSYMA ： COSYMA 是由德国 IDA 公司开发的一种探索硬件与软件协同设计合成进程的平台，它面向软件系统的描述较简单，支持自动分割和协同处理器合成，在合成时期可以对设计空间进行探索，系统合成取决于硬件限制，不支持并发模块，即一次只能有一个线程执行，架构同样受限，不支持正式验证，设计的成功与否取决于分割及开销估计技术。
Chinook ： Chinook 是为控制系统而设计的，整个系统的描述作为一个输入提供给 Chinook ，它的内部模式基于类似等级状态的模式，它不对代码进行分割，它为整个设计提供单一的模拟环境， Chinook 支持多种系统架构，尤其是多处理器结构。同样支持定时限制的描述，它能合成多种接口，包括系统之间的软 、 硬件接口，能直接从定时图表中合成设备驱动器，可以控制处理器之间的通信。
7.1.2 协同模拟工具
协同模拟是嵌入式系统设计中至关重要的一个方面，在整个系统设计完成后，在统一框架下模拟不同种类的成分是必要的，协同模拟不仅提供检验，而且为用户提供各系统的性能信息，这有助于在系统的早期提出变更方案，不至于造成重大损失。
目前，主要的协同模拟工具有如下两种 。
PTOLEMY ： PTOLEMY 的关键思想是混合使用面向对象内核的计算模型，可用于模拟多种的系统，在各种应用中被广泛地使用，但不适合于系统合成，硬件模拟也是它的一项功能 。
TSS ： TSS （ Tool for System Simulation ）是模拟复杂硬件的工具，采用 C 语言编写，单个模块的提取可由用户控制，可以方便地进行添加与删除模块。但不支持分级模块，没有用于同步各处理器存取共享数据结构的机制，模块间的通信通过端口和总线进行。并且， TSS 支持多核系统的模拟。
8 系统集成与测试
通常嵌入式系统测试主要包括软件测试 、 硬件测试 、 单元测试三个部分。
一般系统的硬件测试包括可靠性测试和电磁兼容性测试，关于电磁兼容性目前已经有了强制性国内和国际标准。嵌入式系统软件测试方法和原理跟通用软件的测试基本一致，软件测试时，一般需要测试实例或测试序列，序列有两种来源：一种是需要用户进行设计，另一种是标准的测试序列。无论哪种测试实例，都要求实例能够高概率发现更多的错误，但在测试的内容上有些差别：
（1）嵌入式软件必须长时间稳定运行。
（2）嵌入式软件一般不会频繁地版本升级。
（3）嵌入式软件通常使用在关键性的应用中。
（4）嵌入式软件必须和嵌入式硬件一起对产品的故障和可靠性负责。
（5）现实世界的条件是异步和不可预测的，使得模拟测试非常困难。
由于这些差别，使得嵌入式系统软件测试主要集中在以下4个不同的方面：
（1）因为实时性和同时性很难同时满足，所以大多数测试集中于实时测试。
（2）大多数实时系统都有资源约束，因此需要更多的性能和可用性测试。
（3）可以使用专用实时跟踪工具对代码复盖率进行测试。（4）对可靠性的测试级别比通用软件要高得多。
另外，性能测试也是设计嵌入式系统中需要完成的最主要的测试活动之一，对嵌入式系统有决定性的影响。由于嵌入式系统的专用性特点，系统的硬件平台和软件平台多种多样，每种都针对不同的应用而专门设计，因此，应用软件在各个平台之间很少具有通用性，并且嵌入式系统的更新换代速度相对较快。为了保护已有的投资 、 充分利用现有的软件资源和加快产品研制速度，软件的移植在嵌入式领域变得非常频繁。
