东进语音记录仪MDR3000E系列实现原理分析

陈堃

摘 要：目的：分析东进记录仪MDR3000E实现原理。方法：通过实际运维经验对系统硬件实现进行分析，通过.net Reflector反编译器、SQL Server Management Studio集成环境对系统软件实现进行分析。结果：分析得出硬件实现部分系统采用典型的客户机/服务器架构.服务器端软件实现部分分为前/后端两部分，前端基于WCF框架实现服务器端与客户机端的交互，后端基于典型关系型数据库实现[1]。结论：系统实现均采用业内标准框架，设计符合规范，存在由于具体现场情况造成传统设计缺陷的问题（长时间运行后系统最后录音功能失效），通过限制被操作数据实体的数据量解决。

关键词：.net framework；SQL Server；WCF；ADO.NET组件

中图分类号：TN912.2 文献标识码：A 文章编号：1671-2064（2017）16-0030-03

空管语音记录系统实现了对空管运行中涉及的各类型语音的录音、监听、数据查询及备份等功能，同时除本机操作要求外提供网络操作数据的功能。为民航空管提供查找事故责任、监督工作质量的重要手段和依据。从而有效地保证飞行的安全可靠。本文集中针对东进MDR3000E语音记录仪系统服务器端软件功能的实现原理进行分析，进而结合其在浦东七年来的运行情况，汇总了系统相关问题。包括长时间运行后系统最后录音功能失效的问题，并提出了相应的解决方案，通过实践操作对方案进行了验证。

1 东进MDR3000E语音记录仪实现原理分析

1.1 硬件部分

东进公司的MDR3000E系列产品解决方案的硬件组成包括服务器，局域网、客户端以及时钟、录音数据源。属于典型的C/S结构系统。服务器汇总处理不同信号源提供的信号，客户端通过网络对服务器处理过的数据进行访问。系统核心服务器硬件简而言之其就是一台基于PC总线的工业电脑。语音记录的关键功能实现即通过在工控机上加装语音记录卡（D080D记录单元）。

1.2 软件部分

软件基于windows操作系统开发，典型采用MVC设计模式进行程序设计，服务器前端基于.net framework开发，后台数据库基于Sql Server数据库系统开发。

1.2.1 服务器前端实现分析

为了深入分析前端代码，我们使用.net Reflector软件对程序进行反编译。它是一个类浏览器和反编译器，可以浏览程序集的类和方法，可以分析由这些类和方法生成的 Microsoft中间语言（MSIL），并且可以反编译这些类和方法并查看C#或Visual Basic.NET中的等价类和方法。通过分析，我们发现前端代码主要包括以下几个程序集：

（1）D80d32。顾名思义，实现记录仪系统D80D记录单元的功能代码，涉及较多非.net托管代码，本文不作解析，通过d080d32.cpp文件将相关接口暴露在业务逻辑处理部分，不影响对系统实现原理的分析。

（2）GPSRCI。顾名思义，实现系统时钟处理功能，包括串口时钟信号处理的类文件（GPSMonitor.cs）、Windows系统时钟处理的类文件（Win32.cs）。

（3）Log4net。包含了代表各类型日志的实体类，优秀的第三方日志框架，引用log4net程序集，通过文件Log.config加载至开发项目，帮助程序员把日志信息输出到各种不同的目标。

（4）MDRCommon。实现服务器端关于初始化服务的通用方法，包括备份记录仪数据库相关方法的类文件（Back UpManager.cs）、读取/写入程序接口 ini文件的通用类文件（IniFile.cs）。

（5）MDRContract。程序集的名称即反映了MDR系统整个C/S架构下程序间的通讯基于WCF框架，通过数据契约的序列化实现。程序集包括以下数据契约：

1）记录信号相关的数据契约：表示语音通道配置的数据契约（ChnlSoundCfg.cs）、表示语音通道状态的数据契约（ChnlSoundState.cs）、表示语音通道数据格式的契约（RecordSound.cs）；2）服务器管理相关的数据契约：表示记录仪系统服务器端当前配置信息的数据契约（SystemCfg.cs）、表示记录仪系统服务器端当前状态信息的数据契约（SystemState.cs），包含大量GPS状态信息、表示记录仪系统服务器网络接口信息的数据契约（HostInfo.cs）、表示记录仪系统服务器硬盘使用情况信息的数据契约（DiskInfo.cs）、表示用户信息及权限的数据契约（UserInfo.cs）、表示系统运行日志的数据契约（LogInfo.cs）；3）服务器管理相关的服务契约：实现系统配置及硬盘管理的服务契约接口（ISystem Manager.cs）、实现用户管理、日志管理、数据库操作的服务契约接口（IDataManager.cs）、实现各类型通道操作的服务契约接口（IChnlController.cs）、通过双程操作实现服务器与客户端关于通道状态及系统配置信息交互的服务契约接口（IRegisterManager.cs）。

（6）MDRServerImpl。該程序集为记录仪系统业务逻辑处理的核心，通过对前述及本程序集包含的各个实体类以及核心处理方法的调用，封装成服务行为（MDR ServiceImpl.cs），从而实现系统业务逻辑，主要包括以下实体类：

1）D08D32程序集：该程序集引用了所有D80D记录单元对外的程序方法接口（D80d32程序集），因为相关硬件代码通过C++程序段暴露接口，所以该项目大量使用MarshalAs方法，使.net framework在托管代码和非托管代码之间封送数据（nativeMethod.cs）；2）基于数据访问层的系统数据库操作通用方法（MDRDB.cs）：功能针对语音通道数据格式的契约实体提供了增、改的基础操作。针对语音通道配置的数据契约实体、语音通道数据格式的契约实体分别提供了查询基础操作。查询基础操作中大量调用了序列化方法（FuncHelper.cs）将数据库记录映射为实体对象；3）实现系统配置及硬盘管理的实体类（SystemManager.cs）：实现了系统配置参数的读取与设置、通道电压状态的读取方法；4）基于数据访问层实现用户管理、日志管理、语音通道数据格式的契约实体查询及统计操作的实体类（DataManager.cs）；5）实现服务器与客户端关于通道状态及系统配置信息交互的实体类（RegisterManager.cs）；6）实现监听和雷达、语音综合回放功能的业务逻辑实体类（ChnlController.cs）；7）调用D80D32程序集实现监听和雷达、语音综合回放功能的实体类（ChnlWorker.cs）；8）实现语音记录功能的业务逻辑实体类（ChnlSound.cs）：包括通道采用语音激活方式的业务逻辑处理、采用压控方式的业务逻辑处理。处理中调用了录音文件生成和相关数据库操作（MDRDB.cs）通用方法；9）实现语音记录存储区域自动清理功能的实体类（DiskClearManager.cs）：过程中引用MDRCommon程序集中的IniFile实体类方法，读取键值（RemoveInfo）中语音记录存储区域剩余空间要求（DiskLimit）和自动清理功能运行时间间隔（DiskClearCheckInterval），如果自动清理功能运行检查发现语音记录存储区域剩余空间小于要求，则执行最早语音记录删除程序，删除语音记录存储区域对应最早一日的原始语音记录文件夹及相应数据库记录；10）实现封装系统服务器端服务行为的实体类（MDR ServiceImpl.cs）：该服务行为支持并发、且采用全局所有会话单服务实例的single模式。通过调用程序集中相关实体类（ChnlController、Data Manager、SystemManager、RegisterManager）实现MDRContract程序集中相关接口（IChnlController、IDataManager、ISystemManager、IRegisterManager）。endprint

（7）MDRHost。基于WCF框架的服务本身不能够单独运行，因此该程序集即为封装的服务行为（MDR ServiceImpl.cs）寄宿的宿主程序。主要包括以下实体类：

封装的服务行为（MDR ServiceImpl.cs）寄宿的宿主程序的实体类（MDRHost.cs）：由内部类中的线程类Thread Work实现，通过读取Server.ini文件相关数据库连接内容初始化后端数据库连接、读取相关记录卡类型信息初始化相关板卡驱动，宿主程序启动后，监听相关停止、暂停控制指令并执行。

1.2.2 服务器后端实现分析

数据库的逻辑设计符合3NF，虽然关系模式未能规范至更高的等级，却是最合适的[2]。记录仪系统大量业务集中于语音通道数据（RecordSound）的查询，假使数据库的逻辑设计规范化至4NF，则大量的语音通道数据查询使系统必须进行连接运算，而连接运算的代价是相当高的，可以说关系模型低效的主要原因即做连接运算引起的。

数据库的物理结构设计中仅对极少属性设计了索引。以语音通道数据表（RecordSound）为例，仅针对列（RTime）设计了非聚集索引（IX_RecordSound）。因为该列的值存在大数目的不同值以及频繁被更新的情况，因此不适合建立聚集索引。虽然后端的逻辑设计和物理设计并无缺陷，但前后端结合后的程序设计通过实际运行后确实存在问题。2014年-2015年期间浦东地区东进记录仪系统在使用4年后发生“最后录音”功能失效及语音记录查询响应缓慢的情况。我们分析系统故障日志，发现以下故障记录：

（1）MDRServerImpl.DiskClearManager.GetSubDirMinDate（DirectoryInfo dirRoot） 位置 J：＼MDR源程序＼2011_2_18 V2.1正式版＼MDR NET RADAR 2010 0805＼MDRServerImpl＼DiskClearManager.cs：行号 143

（2）[2015-03-28 10：29：41，345][MDRServerImpl.DataManager.DeleteRecord（J：＼MDR源程序＼2011_2_18 V2.1正式版＼MDR NET RADAR 2010 0805＼MDR ServerImpl＼DataManager.cs：147）][ERROR]数据库删除记录信息失败

（3）[2015-03-28 10：29：41，345][MDRServerImpl.DataManager.DeleteRecord（J：＼MDR源程序＼2011_2_18 V2.1正式版＼MDR NET RADAR 2010 0805＼MDR ServerImpl＼DataManager.cs：148）][ERROR]超时时间已到。在操作完成之前超时时间已过或服务器未响应。

基于服务器的前端实现分析，相关故障情况的直接原因为：记录仪语音通道数据量较大，平均每日为60，000条左右，在长时间运行后系统记录存储区域剩余空间已达上限，须执行语音记录存储区域自动清理功能，即程序集（MDRServerImpl）中的实体类（DiskClearManager.cs）所实现的功能，功能中相关语音通道数据的删除操作由程序集（MDRServerImpl）中的实体类（DataManager.cs）实现，采用了ADO.NET组件库提供的方法。默认超时时间为30s，如果在CommandTimeout属性中设置的时间间隔内没有完成命令执行，将产生错误，ADO将取消该命令。显然长时间运行已造成系统数据库及语音数据存储负荷过大，即记录查找时间过长，进而造成删除操作的超时情况。为避免这类情况的发生，有以下方案供选择：

（1）取消相关实体类数据库操作的超时设置，将属性CommandTimeout设置为零，ADO 组件将无限期等待直到命令执行完毕。以Command对象为例，调整Command.CommandTimeout属性为0即可，但數据库的删除操作（Delete）除删除操作本身外，包含大量事务日志的生成。基于数据库性能，系统目前事务日志文件大小上限为1G。经实际环境测算，当删除的数据库记录超过1，300，000条后，事务日志文件容量将达到上限。如果出现系统记录存储区域剩余空间达到上限的情况后，系统会不断执行语音记录存储区域自动清理操作，反复执行势必造成大量事务日志的生成，即使数据库删除操作无超时限制，数据库最终仍会产生“数据库MDR的事务日志已满”的异常，造成自动清理功能的失效，因此该方案不可取。

（2）限制被操作数据实体的数据量以达到缩短SQL SERVER操作执行时间的目的，这不仅满足上位法的要求（保留1个月的语音通道数据），同时节省系统存储空间、提高系统运行效率，因此我们选择通过该方式解决。解决的方式有以下两个原则：在不影响数据库记录查询时间的条件下，存储语音通道数据量尽可能最大（充分利用存储空间）；达到系统记录存储区域剩余空间的上限后，自动清理功能删除的记录尽量少（减少事务日志记录生成，提高数据库效率）。通过实际环境测试，我们得出结果：限制被操作数据实体的数据量为5个月内的数据生成量的条件下，能使系统运行达到最优效果。使用脚本删除系统多余语音通道数据后，“最后录音”功能失效及语音记录查询响应缓慢的故障恢复。在系统记录存储区域剩余空间达到上限条件下，系统每隔10分钟执行清理功能。

2 结语

本文从硬件及软件两个方面分析了东进MDR3000E系列记录仪系统服务器端功能的实现原理。硬件部分集中说明了系统拓扑及服务器硬件配置。软件部分分为前后端分别说明。前端包含程序设计框架、设计思路及具体代码设计逻辑。后端包含系统数据库的逻辑设计及物理设计分析。通过分析提出了导致2014年-2015年期间浦东地区东进记录仪系统相关故障的设计缺陷，最终确定一种最优的方案，实现限制被操作数据实体的数据量从而解决相关缺陷。

参考文献

[1]Juual Lowy.Programming WCF Services[M].武汉：华中科技大学出版社，2011.

[2]孟祥瑞.数据库原理及应用[M].上海：华东理工大学出版社，2005.endprint