基于事件驱动的智能仪表嵌入式系统架构设计

2015/9/14 15:39:42

基于事件驱动的智能仪表嵌入式系统架构设计

靳苗、郭月明、卫乾、唐杰

（1. 北京中油瑞飞信息技术有限责任公司，北京昌平，102200）

摘要：本文介绍了一种基于事件驱动的嵌入式系统架构设计方法，该架构采用模块化分层设计原则，系统架构由硬件抽象层、应用支持子层、应用层、事件驱动核心等部分组成，各层间逐级调用，可以广泛运行在MSP430、M3、ARM、X86等架构上，具备普遍的通用性；该架构充分考虑智能仪表的需求特点，可有效提高仪表的稳定性及简化后期的维护工作。

关键词：事件驱动；分层设计；模块化；函数库

Embedded Systems Architecture Design of Intelligentinstrument based on Event driven

Abstract：您是不是要找:shining

This article is to introduce an eventdriven based frame design for embedded system, which employs classified modulesdesign. This design consists of Hardware Abstract Layer, Application SupportSub-Layer, Application Support Layer, and Core of Event Driven. It responds tothe command layer by layer and that promises its wide availability on MSP430,M3, ARM, and X86 frames. This frame is designed particularly for intelligentinstruments and it is very challenging to have constant control and simplifiedmaintenance.

Keys: event driven, layereddesign, modularity, function library

0 引言

随着油气生产物联网的迅猛发展，智能仪表设备被广泛应用在国内外自动化领域^[1]。但由于自动化行业所使用仪表的开发环境差异较大、产品技术分支多，导致嵌入式代码接口不统一，代码重用性较差，增加了后期技术沟通的难度。同时，随着仪表类产品行业的需求细化、硬件模块化接口的标准化，对仪表类产品进行统一的嵌入式系统架构设计是可行且必要的。

本文介绍的基于事件驱动的嵌入式系统架构设计方法采用分层设计原则，实现功能模块化封装，以最大程度保证系统的稳定和接口的统一，可以方便的移植至其它MCU及仪表平台，用户通过简单宏定义即可实现产品必要的功能选择，抽象各功能组件的接口并实现统一，可以方便的扩展其它功能组件或增加事件处理任务^[2-4]。

1 系统架构功能组件及分层设计

1.1 系统架构功能需求

根据目前智能仪表的行业需求，智能仪表需要实现设备管理、人机交互、数据上传等功能，按照功能模块化划分，具体系统功能组件如图1-1所示。

图1-1 智能仪表系统功能组件图

1.2 系统架构的分层设计

早在1979年，国际标准化组织ISO下设的一个专门委员会为制定“开放系统互联”（OSI）的有关标准，提出了基于功能分层概念的网络结构七层模型-开放系统互连参考模型（OSI/RM）。尽管OSI/RM是为网络中系统互连所建立的，但是其分层的设计思想完全可以为智能仪表嵌入式系统架构的设计所借鉴^[5]。

根据工业自动化行业智能仪表的功能需求，将代码进行分层设计，为用户（嵌入式应用层工程师）提供设备管理接口集、数据上传接口集、人机交互接口集、历史数据管理接口集、传感器参数管理接口集、传感器实时数据采集及周边外设数据采集接口集、设备功能模块电源管理接口集、通讯协议接口集、校验算法接口集及滤波算法接口集，同时提供数据类型及错误码组件，以缩短产品开发时间、提高产品开发效率和质量。如图1-2所示，将整个系统由硬件层、硬件驱动层、硬件抽象层，应用支持子层、仪表组函数库、事件驱动核心、应用层共计7个部分组成。每一层中，又可以分为多个独立的模块，这些模块之间耦合较少，共同为上层提供服务。

图1-2 嵌入式系统架构分层图

2 系统各层的工作原理分析与设计

由系统分层的设计思想可知，系统中每层都对下一层进行了封装，因此在代码执行过程中需要逐级调用，而不能隔层调用。具体各层间的调用流程如2-1所示。

随着仪表硬件模块化和接口标准化的落实，为软件分层模块化设计奠定了基础。根据仪表功能需求，硬件层分为主控模块、传感器模块、HMI模块及通讯模块等基本单元。

图2-1 系统各层间调用流程图

2.1 硬件抽象层（HAL）

2.1.1 硬件抽象层工作原理

硬件抽象层（HAL）完成了对硬件模块接口的进一步封装，其中包括MCU内部总线类设备及MCU外部设备，硬件抽象层(HAL)作为BSP的上一层，及应用支持子层的下一层，是整个系统架构非常关键的一层，HAL实现了对底层设备的封装，为应用支持子层及系统架构中其它功能模块提供统一的接口。为实现该功能及代码的通用性，需要对每一个软硬件模块进行唯一编码，通过设备编码实现对不同设备的区别，根据设备编码通过回调函数的动态映射实现同一设备不同的操作。

根据仪表的特征，可以将对设备的操作抽象成一些子操作接口，将这些子操作统一到一个结构中去来实现对上层接口的统一。如对常规设备的操作可以抽象成打开、读、写、休眠、诊断、关闭6个子操作接口，硬件抽象层常规设备接口设计如图2-2所示，在编写设备抽象层代码时，必须将BSP层接口抽象出以上6种接口供应用支持子层及其它功能模块使用，设备操作结构设计如下：

Struct Hal_Dev{.DEV_CODE,.read,.write,.open,.close,.diagnostic,.sleep}

图2-2 硬件抽象层常规设备结构接口设计图

在实际编写硬件抽象层驱动式，可通过open函数来挂载不同的操作接口。例如应用支持子层如果需要对硬件抽象层传感器模块中的某一子设备进行操作时，首先将该子设备的编码（设备编码是全局唯一的）传入open函数，open函数则根据唯一编码查找到该设备的操作接口并将其地址赋值给结构中的接口。

2.1.2 硬件抽象层中断处理接口

为及时响应用户需求，硬件抽象层可对红外接口、通讯模块接口提供了中断处理机制，涉及中断处理的模块有红外通讯模块、本地通讯模块及远程通信模块等。在本次系统架构设计中，中断只有定时器中断和UART数据接收中断两种，定时器中断用于驱动事件运转，UART中断发生时用于搬运UART缓冲区中的数据至数据区。RTC中断触发时和UART中断触发时的事件流程图分别如图2-3、2-4所示。

图2-3 RTC中断触发时事件流程图

图2-4 UART中断触发时事件流程图

2.2 应用支持子层

应用支持子层是整个系统的第二枢纽，应用支持子层提供了设备硬件抽象层与应用层之间及仪表组函数库之间的连接，在层级职能上该层对硬件抽象做了进一步的封装，以便于应用层封装事件操作接口时调用，主要由传感器操作相关操作接口、数据存取相关操作接口、数据展示相关操作接口及数据传输相关操作接口组成。与仪表组函数库提供的接口相比，该层级接口偏重于硬件接口封装，它作为一个桥梁建立了系统其它功能组件与事件驱动核心之间的联系，为应用层和事件驱动核心提供更加易于使用的设备接口。

以传感器模块接口为例。整个系统运转过程中，传感器操作是最频繁的一个任务，整个系统基本上是围绕着传感器进行的，根据硬件模块化设计的方案可以确定传感器的操作涉及到实时数据读取、传感器信息读取、传感器诊断共计3个方面，对于MCU来讲其实是对SPI接口的一些读写操作，而这些读写基本操作在HAL中已经实现，本处需要设计一个接口，用来封装对传感器实时数据读取、传感器信息读取、工况诊断等操作，如图2-5所示。

图2-5 传感器模块应用支持子层接口

2.3 仪表函数库

仪表函数库实现了对仪表类产品软件模块的封装，主要包含通讯协议模块、文件系统、设备管理模块、算法模块、智能电源管理模块等，同时包含C语言部分标准函数，该套系统架构支持标准C函数库中的输入、输出函数及数学函数。仪表函数库的架构如图2-6所示。

图2-6 仪表代码库建设架构图

通过代码库建设，可以统一代码规范，统一常用函数接口，并避免重用性，提高嵌入式软件工程师的效率。

2.4 应用层

不同的设备有不同的应用场景，相同的设备又有不同的应用需求，如何系统架构的统一，尽量将程序员的工作量集中在实际问题处理上，而不是整个系统上？这要依赖于应用层的设计，应用层将实例化出人机交互事件、设备远程管理事件、数据上传事件、数据展示事件、实时数据采集事件、外部设备数据采集事件及历史数据存取事件等操作接口。在事件驱动中心中将执行上述事件处理函数，应用层及各层之间的关系如图2-7所示。如传感器数据上传事件，该事件工作主要粉两个方面，一是被动上传，即上位机有需求时启动上传，这种方式主要是应用于总分架构的总线中；另一方面是主动上传，这要根据具体的通讯协议，如A11通讯协议。同时在该事件中完成数据的合包与发送，该事件将调用通讯协议接口及通讯模块数据发送接口。

图2-7 应用层与各层之间的关系图

2.5 事件驱动核心

事件驱动核心的主要功能是仲裁系统中各个任务的先后顺序。事件驱动核心的“心跳”在硬件抽象层完成，通过RTC时钟滴答进行判断或触发事件，设计这一部分目的是让应用层工程师专注于用户需求，因为大多数情况下，事件驱动核心及相关子层的设计是整个系统的核心任务，可以通过定期的维护和更新这个“内核”对产品进行升级。事件驱动核心与各层之间的关系如图2-8所示。