软件设计模式在嵌入式控制系统中的应用

赖炳宇，李言华

（中国电子科技集团第29研究所，成都610000）

引 言

按照传统意义的定义，嵌入式系统为以应用为中心，计算机技术为基础，软硬件可裁剪，适应应用系统对功能、可靠性、成本、体积、功耗等严格要求的专用计算机系统。由于硬件平台的诸多约束以及对应用系统特定功能的适应性要求，一般的嵌入式系统软件设计力求简单、可靠，而软件与硬件的结合非常紧密，极具个性化色彩，软件的可复用性、可扩展性、可移植性等在设计过程中往往不是考虑的主要因素。

然而，随着芯片技术的飞速发展，一方面，目前硬件平台能力已经得到了极大的提高，大多数领域使用的芯片具有更强的处理能力，并且集成了多种接口，使嵌入式系统满足更为复杂的应用需求成为可能，软件实现的功能也更为复杂；另一方面，基于应用的需求，对产品的可靠性、成本、更新换代的要求也在提高，嵌入式软件的可复用性、可扩展性以及可移植性逐渐成为设计时必须要考虑的问题。

参考目前的桌面通用计算机软件可以预见，通过建立可复用面向对象的嵌入式软件架构，能够增强嵌入式软件的可复用性、可扩展性和可移植性，降低研发周期和成本。

1 软件框架和设计模式

软件框架（Software Framework），通常指的是实现某个业界标准或完成特定基本任务的软件组件规范，也指实现某个软件组件规范时提供所要求的基础功能的软件产品。软件框架的功能类似于基础设施，与具体的软件应用无关，只是提供并实现最基础的软件架构和体系。软件设计师通常根据特定的软件框架实现更为复杂的系统应用和业务逻辑。

简而言之，框架就是制定一套规范，使所有程序员在该规范下工作。在软件的研发过程中，框架明确定义软件的模块化规范、模块之间的交互、对外接口方法，以及高层事物的对象操作、逻辑和流程，以便于具体应用实现者能够集中精力于应用本身的特定细节。

显然，无论是对于桌面通用计算机软件还是嵌入式系统软件，软件框架作为软件运行的基础，都是十分重要的。好的软件框架可以使系统具有更好的可复用性、扩展性和移植性，进而提升系统的可靠性并降低成本。良好的软件框架共同的设计决策，十分强调设计复用，因此框架设计中必然使用设计模式。

设计模式（Design Pattern）是由Erich Gamma等人1990年从建筑设计领域引入的概念。设计模式并不直接完成程序代码的编写，而是描述在各种不同的情况下，如何解决问题的一种方案。它是一套被反复使用、多数人知晓、经过分类编目、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码的可靠性。毫无疑问，设计模式使代码编制真正工程化，是软件工程的基石脉络。

2 嵌入式传感器控制系统的特点及软件框架设计考虑

在涉及系统调度控制领域的嵌入式系统中，由于需要实现的功能和接口日趋复杂，总结起来，具有如下特点：

①核心调度控制算法存在多样性。在嵌入式控制系统中，尤其在涉及传感器控制的系统中，为了实现特定的功能需求、针对不同的应用场景，传感器资源的调度和控制，存在多种不同的策略和算法，而某种调度控制策略和算法只与应用有关，而与底层的硬件和所搭载的平台无关。

②硬件接口多样化。由于需要满足不同应用的工程实现环境，不同的嵌入式控制系统所面临的硬件接口差异较大。目前，常用的硬件通信接口包括TCP/IP网络通信接口、RS232/422串口通信接口、光纤总线接口、1553B总线通信接口以及CAN总线通信接口等，各种硬件接口存在一定的差异性。

③数据传输协议多样化。不同的嵌入式传感器控制系统，可能会搭载在不同的平台上，而不同的平台之间，其数据传输协议也存在较大的差异。

④软件模块通信的松耦合性。即不同的嵌入式控制系统一般由相同的各种硬件、软件调度逻辑算法集成，单一软件模块的功能普遍相同，具有很大的可复用性，如何保证该软件模块的松耦合性，是提高软件复用度的关键点之一。而保证软件模块的松耦合性的关键还在于与其他软件模块的通信具有松耦合性。

综上所述，嵌入式传感器控制系统具有算法逻辑、硬件接口和数据传输协议多样的特点，为了提高其可复用性、可扩展性和可移植性，在设计嵌入式软件框架时，必须考虑尽量提高模块的内聚性，降低模块之间的耦合性。

3 嵌入式控制系统软件架构方案

针对第2节所描述的嵌入式系统的特点，结合设计模式，对嵌入式控制系统的软件架构设计进行了考虑和设计决策。

3.1 核心调度控制算法多样性问题的解决

为了解决核心调度算法多样性的问题，使用Bridge模式将抽象部分和具体实现部分进行分离。这样，当核心调度算法改变时，嵌入式系统的其余部分不会受到影响。

Bridge模式主要由4种角色组成：

①抽象角色：它定义了抽象类的接口而且维护着一个指向实现角色的引用；

②精确角色：实现并扩充由抽象角色定义的接口；

③实现角色：给出了实现类的接口，这里的接口与抽象角色中的接口可以不一致；

④具体实现角色：给出了实现角色定义接口的具体实现。

Bridge模式下的类图如图1所示。

图1 Bridge模式下的类图

参照使用Bridge模式，将核心调度控制算法进行了抽象和封装，这样即使在系统设计实现的过程中，核心调度控制算法发生了变化，对整个系统的影响也微乎其微。

由此，我们确立了应用节点层的概念。由嵌入式系统软件框架确定应用节点的接口规范，应用开发人员开发并设计各类应用节点，而各类应用节点根据具体的调度控制算法不同，完成不同的具体实现。嵌入式系统软件架构下应用节点层的类图如图2所示。

图2 嵌入式系统软件架构下应用节点层的类图

3.2 硬件接口多样化问题的解决

由于嵌入式系统中涉及的硬件接口多种多样，为了与核心调度算法逻辑进行隔离，结合设计模式，使用Factory模式完成各类硬件接口类的创建。

Factory模式由3部分组成：

①工厂类角色：含有一定的商业逻辑和判断逻辑；

②抽象类产品角色：一般是具体产品继承的父类或者实现的接口；

③具体产品角色：工厂类所创建的对象就是此角色的实例。

Factory模式的类图如图3所示。

图3 Factory模式的类图

参照使用Factory模式，确立了节点管理类，在节点管理中完成了对各种硬件接口的抽象，并根据不同硬件接口，提供硬件接口的生成操作，即对不同的硬件接口进行具体实现。其类图如图4所示。

图4 节点管理类的类图

3.3 数据传输协议多样化问题的解决

数据传输多样化问题的本质同系统核心调度控制算法的多样性一样，仍然使用Birdge模式来解决这一问题，对数据传输解析协议进行了抽象，此处不再赘述。

3.4 软件模块通信的松耦合性问题的解决

为了使各个软件模块在通信过程中具有松耦合性，参照Observer模式，设计了节点通信层，各个软件模块的消息通信通过节点通信层完成传递，避免了相互之间的耦合。

Observer模式的组成部分包括：

①抽象目标角色：目标角色知道它的观察者，可以有任意多个观察者观察同一个目标，并且提供注册和删除观察者对象的接口；

②抽象观察者角色：为那些在目标发生改变时需要获得通知的对象定义一个更新接口；

③具体目标角色：将有关状态存入各个具体观察者角色对象，当它的状态发生改变时，向它的各个观察者发出通知；

④具体观察者角色：存储有关状态，这些状态应与目标的状态保持一致。

Observer模式的类图如图5所示。

图5 Observer模式的类图

参照使用Observer模式，确立了节点通信层，各个应用节点通过在节点通信层进行消息的注册，完成对应消息的获取和发送，从而解决了应用节点之间的通信耦合性问题。

综上所述，考虑到嵌入式控制系统的特点，确立了系统的软件架构。该软件架构如图6所示。

其中软件框架的层次划分及功能描述如下：

①虚拟操作系统层完成对底层操作系统的封装，以屏蔽上层应用对于底层操作系统的依赖；

②节点管理层完成各种节点的创建、维护和管理；

③节点通信层完成上层各个应用节点之间通信的封装和功能实现；

④应用节点层为上层应用提供接口规范，以明确统一上层应用节点的接口规范。

图6 系统软件架构图

结 语

通过建立统一的嵌入式软件架构，并借用成熟的软件设计模式，能够加大软件复用程度、提高开发研制效率、降低研发成本，是嵌入式软件开发的发展趋势。

[1]Erich Gamma，Richard Helm，Ralph Johnson，et al.Design Patterns：Elements of Reusable Object-Oriented Software[M].San Antonio：Pearson Education，2000.

[2]郭峰.深入浅出设计模式[M].北京：中国铁道出版社，2013.