嵌入式系统软件架构设计

 嵌入式系统软件架构设计

目录

1. 前言 4

2. 决定架构的因素和架构的影响 4

2.1. 常见的误解 5

2.1.1. 小型的系统不需要架构 5

2.1.2. 敏捷开发不需要架构 7

3. 嵌入式环境下软件设计的特点 7

3.1. 和硬件密切相关 7

3.2. 稳定性要求高 8

3.3. 内存不足 8

3.3.1. 虚拟内存技术 8

3.3.2. 两段式构造 9

3.3.3. 内存分配器 10

3.3.4. 内存泄漏 11

3.4. 处理器能力有限，性能要求高 11

3.4.1. 抵御新技术的诱惑 11

3.4.2. 不要有太多的层次 11

3.5. 存储设备易损坏，速度较慢 12

3.5.1. 损耗均衡 12

3.5.2. 错误恢复 12

3.6. 故障成本高昂 13

4. 软件框架 14

4.1. 嵌入式软件架构面临的问题 14

4.2. 什么是框架 14

4.2.1. 软件复用的层次 14

4.2.2. 针对高度特定领域的抽象 15

4.2.3. 解除耦合和应对变化 16

4.2.4. 框架可以实现和规定非功能性需求 16

4.3. 一个框架设计的实例 17

4.3.1. 基本架构 17

4.3.2. 功能特点 17

4.3.3. 分析 18

4.3.4. 实际效果 23

4.4. 框架设计中的常用模式 23

4.4.1. 模板方法模式 23

4.4.2. 创建型模式 23

4.4.3. 消息订阅模式 24

4.4.4. 装饰器模式 24

4.5. 框架的缺点 25

5. 自动代码生成 26

5.1. 机器能做的事就不要让人来做 26

5.2. 举例 26

5.2.1. 消息的编码和解码 26

5.2.2. GUI

嵌入式是软件设计领域的一个分支，它自身的诸多特点决定了系统架构师的选择，同时它的一些问题又具有相当的通用性，可以推广到其他的领域。本课程试图从嵌入式软件架构设计出发，启发大家对软件架构设计的理解。本课程的很多内容是对谢老师课程在嵌入式领域的具体阐述。

提起嵌入式软件设计，传统的印象是单片机，汇编，高度依赖硬件。传统的嵌入式软件开发者往往只关注实现功能本身，而忽视诸如代码复用，数据和界面分离，可测试性等因素。从而导致嵌入式软件的质量高度依赖开发者的水平，成败系之一身。随着嵌入式软硬件的飞速发展，今天的嵌入式系统在功能，规模和复杂度各方面都有了极大的提升。比如，

2. 通过传感器自动采集测试数据，并显示在屏幕上。

3. 记录所有的测试结果，并提供统计功能。比如次品率。

如果你是这个设备的架构师，哪些问题是在设计架构的时候应该关注的呢/p>

1.1. 常见的误解

1.1.1. 小型的系统不需要架构

有相当多的嵌入式系统规模都较小，一般是为了某些特定的目的而设计的。受工程师认识，客户规模和项目进度的影响，经常不做任何架构设计，直接以实现功能为目标进行编码。这种行为表面上看满足了进度，成本，功能各方面的需求，但是从长远来看，在扩展和维护上付出的成本，要远远高于最初节约的成本。如果系统的最初开发者继续留在组织内并负责这个项目，那么可能一切都会正常，一旦他离开，后续者因为对系统细节的理解不足，就可能引入更多的错误。要注意，嵌入式系统的变更成本要远远高于一般的软件系统。好的软件架构，可以从宏观和微观的不同层次上描述系统，并将各个部分隔离，从而使新特性的添加和后续维护变得相对简单。

举一个城铁刷卡机的例子，这个例子在前面的课程中出现过。简单的城铁刷卡机只需要实现如下功能：

一个

如果直接以上面的流程图编码，当出现变更后，有多少代码可以复用/p>

不过，也不要因此产生过度的设计。架构应当立足满足当前需求，并适当的考虑重用和变更。

1.1.2. 敏捷开发不需要架构

极限编程，敏捷开发的出现使一些人误以为软件开发无需再做架构了。这是一个很大的误解。敏捷开发是在传统瀑布式开发流程出现明显弊端后提出的解决方案，所以它必然有一个更高的起点和对开发更严格的要求。而不是倒退到石器时代。事实上，架构是敏捷开发的一部分，只不过在形式上，敏捷开发推荐使用更高效，简单的方式来做设计。比如画在白板上然后用数码相机拍下的

11. 软件不能离开硬件单独测试和验证，往往需要和硬件验证同步进行，造成进度前松后紧，错误定位范围扩大。

针对这些问题，有几方面的解决思路：

1. 用软件实现硬件功能。选用更强大的处理器，用软件来实现部分硬件功能，不仅可以降低对硬件的依赖，在响应变化，避免对特定型号和厂商的依赖方面都很有好处。这在一些行业里已经成为了趋势。在

13. Watch Dog, Heart beat

有一些嵌入式设备需要处理巨大的数据量，而这些数据不可能全部装入内存中。一些嵌入式操作系统不提供虚拟内存技术，比如

5. 快速的持久化和装载。

下图是一个全国电信机房管理系统的界面示意图：

每个节点下都有大量的数据需要装载，可以使用上述技术将内存占用降到最低。

2.3.2. 两段式构造

在内存有限的系统里，对象构造失败是必须要处理的问题

      iSimpleClass = new CMySimpleClass; 

 }

当创建CMyCompoundClass

一切看起来都很简单，但是如果第三步创建

不同的系统有着不同的内存分配的特点。有些要求分配很多小内存，有的则需要经常增长已经分配的内存。一个好的内存分配器对嵌入式的软件的性能有时具有重大的意义。应该在系统设计时保证整个系统使用统一的内存分配器，并且可以随时更换。

2.3.4. 内存泄漏

内存泄漏对嵌入式系统有限的内存是非常严重的。通过使用自己的内存分配器，可以很容易的跟踪内存的分配释放情况，从而检测出内存泄漏的情况。

2.4. 处理器能力有限，性能要求高

这里不讨论实时系统，那是一块很大的专业话题。对一般的嵌入式系统而言，由于处理器能力有限，要特别注意性能的问题。一些很好的架构设计由于不能满足性能要求，最终导致整个项目的失败。

2.4.1. 抵御新技术的诱惑

架构师必须明白，新技术常常意味着复杂和更低的性能。即使这不是绝对的，由于嵌入式系统硬件性能所限，弹性较低。一旦发现新技术有和当初设想不同之处，就更难通过修改来适应。比如

受体积和成本的限制，大部分的嵌入式设备使用诸如

损耗均衡的基本思路是平均地使用存储器上的各个区块。需要维护一张存储器区块使用情况的表，这个表包括区块的偏移位置，当前是否可用，以及已经擦写地次数。当有新的擦写请求的时候，根据以下原则选择区块：

1. 尽量连续

20. 擦写次数最少

即使是更新已经存在的数据，也会使用以上原则分配新的区块。同样，这张表的存放位置也不能是固定不变的，否则这张表所占据的区块就会最先损坏。当要更新这张表的时候，同样要使用以上算法分配区块。

如果存储器上有大量的静态数据，那么上述算法就只能针对剩下的空间生效，这种情况下还要实现对这些静态数据的搬运的算法。但是这种算法会降低写操作的性能，也增加了算法的复杂度。一般都只使用动态均衡算法。

目前比较成熟的损耗均衡的文件系统有

双备份的思路更简单，所有的数据都写两份。每次交替使用。文件分区表也必须是双备份的。假设有数据块来源：恐惧本身不可怕