【系统架构设计】嵌入式系统设计（2）

本文主要是介绍【系统架构设计】嵌入式系统设计（2），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

嵌入式系统概论

嵌入式系统的组成

嵌入式开发平台与调试环境

嵌入式网络系统

嵌入式 Internet 的接入方式

• 嵌入式设备上集成了 TCP/IP 协议栈及相关软件，这类设备可以作为 Internet 的一个节点，分配有 IP 地址，与 Internet 直接互联。
• 通过网关接入 Internet，即采用瘦设备方案，设备不直接接入 Internet，不需要复杂的TCP/IP 协议全集，而是通过接入设备接入 Internet。

嵌入式 TCP/IP 协议栈

嵌入式 TCP/IP 协议栈完成的功能与完整的 TCP/IP 协议栈是相同的，但是由于嵌入式系统的资源限制，嵌入式协议栈的一些指标和接口等与普通的协议栈可能有所不同。

1. 嵌入式协议栈的调用接口与普通的协议栈不同。普通协议栈的套接字接口是标准的，应用软件的兼容性好，但是，实现标准化接口的代码开销、处理和存储开销都是巨大的。因此，多数厂商在将标准的协议栈接口移植到嵌入式系统上的时候，都做了不同程度的修改简化，建立了高效率的专用协议栈，它们所提供的 API 与通用协议栈的 API 不一定完全一致。
2. 嵌入式协议栈的可裁剪性。嵌入式协议栈多数是模块化的，如果存储器的空间有限，可以在需要时进行动态安装，并且都省去了接口转发、全套的 Internet 服务工具等几个针对嵌入式系统非必需的部分。
3. 嵌入式协议栈的平台兼容性。一般协议栈与操作系统的结合紧密，大多数协议栈是在操作系统内核中实现的。协议栈的实现依赖于操作系统提供的服务，移植性较差。嵌入式协议栈的实现一般对操作系统的依赖性不大，便于移植。许多商业化的嵌入式协议栈支持多种操作系统平台。
4. 嵌入式协议栈的高效率。嵌入式协议栈的实现通常占用更少的空间，需要的数据存储器更小，代码效率高，从而降低了对处理器性能的要求。

嵌入式数据库管理系统

引入嵌入式数据库管理系统 是因为，如果直接在嵌入式操作系统或裸机之上开发信息管理应用程序，会存在以下缺点：

• 所有的应用都要重复进行数据的管理工作，增加了开发难度和代价；
• 各应用之间的数据共享性差；
• 应用软件的独立性、可移植性差，可重用度低。

一个完整的嵌入式数据库管理系统由若干子系统组成，包括主数据库管理系统、同步服务器、嵌入式数据库管理系统、连接网络等几个子系统。

嵌入式移动数据库在实际应用中必须解决好数据的一致性（复制性）、高效的事务处理和数据的安全性等问题。

数据的一致性

嵌入式移动数据库的一个显著特点是，移动数据终端之间及与同步服务器之间的连接是一种弱连接，即低带宽、长延迟、不稳定和经常性断接。为了支持用户在弱环境下对数据库的操作，现在普遍采用乐观复制方法允许用户对本地缓存上的数据副本进行操作。待网络重新连接后再与数据库服务器或其他移动数据终端交换数据修改信息，并通过冲突检测和协调来恢复数据的一致性。

高效的事务处理

移动事务处理要在移动环境中频繁的、可预见的断接情况下进行。为了保证活动事务的顺利完成，必须设计和实现新的事务管理策略和算法。可以考虑以下几方面：

• 根据网络连接情况来确定事务处理的优先级，网络连接速度高的事务请求优先处理；
• 根据操作时间来确定事务是否迁移，即长时间的事务操作将全部迁移到服务器上执行，无须保证网络的一直畅通；
• 根据数据量的大小来确定事务是上载执行还是下载数据副本执行后上载；
• 完善的日志记录策略；
• 事务处理过程中，网络断接处理时采用服务器发现机制还是采用客户端声明机制；
• 事务移动（如：位置相关查询）过程中的用户位置属性的实时更新。

数据的安全性

许多应用领域的嵌入式设备是系统中数据管理或处理的关键设备，因此嵌入式设备上的数据库系统对存取权限的控制较严格。同时，许多嵌入式设备具有较高的移动性、便携性和非固定的工作环境，也带来潜在的不安全因素。此外，某些数据的个人隐私性又很高，因此在防止碰撞、磁场干扰、遗失、盗窃等方面对个人数据的安全性需要提供充分的保证。保证数据安全的主要措施是：

• 对移动终端进行认证，防止非法终端的欺骗性接入；
• 对无线通信进行加密，防止数据信息泄漏；
• 对下载的数据副本加密存储，以防移动终端物理丢失后的数据泄密。

实时系统与嵌入式操作系统

现实世界中，并非所有的嵌入式系统都具有实时特性，所有的实时系统也不一定都是嵌入式的。但这两种系统并不互相排斥，兼有这两种系统特性的系统称为实时嵌入式系统。

对实时系统划分

根据实时性的强弱

即系统必须对外部事件做出响应的时间长短，将实时系统分为：

• 强实时系统，其系统的响应时间非常短，通常在毫秒或微秒级；
• 一般实时系统，其系统响应时间比强实时系统要求要低，通常在秒级；
• 弱实时系统，其系统响应时间可以更长，也可以随系统负载的轻重而变化。

根据对错失时限的容忍程度或后果的严重性

可以将实时系统分为软实时系统和硬实时系统：

ps：死线（Deadline）或时限、死限、截止时间，是指系统必须对外部事件进行处理的最迟时间界限，错过此界限可能产生严重的后果。通常，计算必须在到达时限前完成。

实时嵌入式操作系统

整体上看，一个嵌入式系统的实时性能是由硬件、实时操作系统及应用程序共同决定的，其中，嵌入式实时操作系统内核的性能起着关键的作用。通常，有两种类型的实时嵌入式操作系统：实时内核型的 RTEOS 与通用型的 RTEOS。

• 实时内核型的 RTEOS：这类操作系统，驱动程序传统嵌在内核之中，应用程序和中间件实现在标准的应用程序接口之上；
• 实时通用型的 RTEOS：这类操作系统，驱动程序并非深度嵌入到内核中，而是在内核之上实现，并且仅包含少数必要的驱动程序，应用程序和中间件可以直接在驱动程序之上实现，而不必在标准的 APIs 实现。
  

1. 中断延迟时间，是指从中断发生到系统获知中断的时间，主要受系统最大关中断时间的影响，关中断时间越长，中断延迟也就越长；
2. 中断处理执行时间，该时间由具体的应用决定；
3. 中断响应时间，是指从中断发生到开始执行用户中断服务例程的时间；
4. 中断恢复时间，是指用户中断服务例程结束回到被中断的代码之间的时间。对于可抢占式调度，中断恢复的时间还要加上进行任务切换和恢复新的任务上下文的时间；
5. 最大关中断时间，包含两个方面：一是内核最大关中断时间，即内核在执行临界区代码时关中断；二是应用关中断时间。关中断最大时间是这两种关中断时间的最大值；
6. 任务响应时间，是指从任务对应的中断产生到该任务真正开始运行的时间。

ps： 一定要注意中断恢复时间是执行中断服务实例后才开始计算的，不是开始执行中断服务实例。

嵌入式系统开发设计

常用开发模型

在嵌入式系统领域，有如下几种常用开发过程模型：

瀑布模型

瀑布模型由五个主要阶段构成：

• 需求分析阶段确定目标系统的基本特点；
• 系统结构设计阶段将系统的功能分解为主要的构架；
• 编码阶段主要进行程序的编写和调试；
• 测试阶段检测错误；
• 最后一个是维护阶段，主要负责修改代码以适应环境的变化，并改正错误、升级。

各个阶段的工作和信息总是由高级的抽象到较详细的设计步骤单向流动，是一个理想的自顶向下的设计模型。

螺旋模型

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

ps：由小到大

逐步求精模型

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

ps：由繁到精

层次模型

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

核心技术

主要有三种核心技术：处理器技术、IC （Integrated Circuits，集成电路）技术、设计/ 验证技术

这篇关于【系统架构设计】嵌入式系统设计（2）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---