当前位置：首页 > 实用文档 > 其他范文> 一种深水网箱鱼群状态监测的数据采集与远程传输技术研究

一种深水网箱鱼群状态监测的数据采集与远程传输技术研究

时间：2022-05-22 01:43:48 其他范文收藏本文下载本文

一种深水网箱鱼群状态监测的数据采集与远程传输技术研究（通用9篇）由网友“柚子快跑”投稿提供，以下是小编收集整理的一种深水网箱鱼群状态监测的数据采集与远程传输技术研究，仅供参考，欢迎大家阅读。

篇1：一种深水网箱鱼群状态监测的数据采集与远程传输技术研究

一种深水网箱鱼群状态监测的数据采集与远程传输技术研究

为了满足抗风浪深水网箱中鱼群远距离监测的要求,本文提出了一种鱼群监测数据采集和基于无线模块的远程传输方案.该方案由海上现场监测系统和岸上控制及显示主机构成.在海上现场监测系统中,单片机把采集到的回波数据存储到扩展存储器62 256,再通过无线模块发送回岸上控制及显示主机,由主机对接收数据进行处理和显示.厦门海域的海上实验结果表明,该方案能够简便、有效地对深水网箱中的鱼群状态进行数据采集,并在距网箱500 m的距离内实现数据的'可靠传输和显示,为正在新兴发展的抗风浪深水网箱养殖提供了一种简单、有效的鱼群状态安全监测技术.

作者：李明磊许肖梅 LI Ming-lei XU Xiao-mei 作者单位：厦门大学海洋学系,福建,厦门,361005 刊名：厦门大学学报（自然科学版） ISTIC PKU英文刊名：JOURNAL OF XIAMEN UNIVERSITY(NATURAL SCIENCE) 年，卷(期)： 46(4) 分类号：P733.23 关键词：深水网箱鱼群监测无线模块数据采集

篇2：网络传输计费系统的数据采集与传输

【摘要】本文扼要地阐述了将交换机上生成的采集文件无丢失地拷贝到直采机上，然后通过网络传输到联机计费平台的文件服务器上实时分拣，同时提供一种实时监测的手段，确保系统运行的安全、稳定，该系统在实际应用中向电信客户提供了客观、公正、准确、及时的计费服务，取得了用户满意的效果。

【关键词】数据传输系统;数据采集;交换技术

对于客户而言，通信子模块提供实际到交换机的物理通道，在已建立的物理通道上可分为命令通道和状态通道等类型，计费命令通过命令通道下达给交换机，交换机报告信息通过状态通道传送出来，对于特定型号的交换机需要采集前置机完成与交换机的交互操作，来屏蔽各种交换机的异构性，从而使采集模块向客户提供一个统一的界面。

计费数据采集负责对交换机数据准确地采集处理是将交换机中的计费数据通过采集传送到计费中心以进行后台数据的集中处理和面向具体业务的综合业务处理。

一方面使得交换机计费数据采集进行集中控制和管理成为可能另一方面也为综合业务的开展提供了操作平台计费数据传输就是把计费数据从数据源传输到数据目的地是数据源和数据目的地之间的计费数据交换。

篇3：网络传输计费系统的数据采集与传输

1.1 通信网络计费数据传输模型。

融合计费数据传输通过统一的接口在规定的时间内完成传送完整、准确的数据到目的地。

其数据格式数据块大小消息描述符的结构格式队列容量消息描述符，消息描述符的标识消息的优先级消息的生命周期消息旧消息体拆分消息体组合往往有其统一的标准和统一的接口规范。

1.1.1 融合计费数据传输模型融合计费数据传输模型是对采集不同网络、不同业务的数据统一传输的模型。

通过信息交换技术传送融合的数据从数据源到数据目的地。

解决计费数据融合后数据传输的问题。

为网络融合提供了计费数据传输方面的支持。[1]

1.1.2 时间无关性计费数据传输模型:时间无关性计费数据传输模型是指数据传输源、数据传输通路、数据传输目的地三者发送、传送和接收时间互不相关各自进行各自的处理互不影响的传输模型。

该模型解决数据发送数据传输和数据接收的时间相关性而影响传输质量和传输速度的问题。

较好的解决了当今网络与通信远距离计费数据的实时、可靠传输的问题。

当网络的数据发送端和数据接收端较远时当网络的传输状况较差时时间无关性计费数据传输模型采取分步传输数据不因网络问题或者机器问题而丢失数据;分布式传输数据允许数据发送端、传输通道和数据接收端各自进行各自的处理而并非必须同步进行。[2]

1.2 通信网络计费数据采集模型。

数据采集系统主要完成接收从控制计算机的前端送来的控制信号依次读取从传感器中送来的数据并将这些数据以一定的格式保存到计算机中。

1.2.1 融合计费数据采集模型:融合计费数据采集对不同网络或不同业务的话单和统计信息进行采集。

该模型一方面避免了大量的重复劳动.另一方面使网络之间规划更具有合理性。

有利于网络资源共享利用、网络间较好的兼容、网络增多和业务种类增多。

通过融合数据采集较好地解决不同网之间的计费数据集中采集问题。

1.2.2 集中计费数据采集模型:集中计费数据采集对同一网络不同地点的话单和统计信息进行集中采集。

进行统一处理对同一个网络计费数据进行统一规划.集中管理。

有利干网络的迅速膨胀和发展。

集中数据采集较好地解决同一网的计费统一规划和集中管理问题。

篇4：网络传输计费系统的数据采集与传输

2.1 数据安全措施。

计费数据采集与传输中多方面考虑采集与传输的安全性:(1)循环采集与传输计费数据。

如果数据不能采集与传输到目的地，对其一直进行循环采集与传输。

(2)计费数据采集与传输完毕后满足要求如备份计费数据后才删除计费数据。

否者.不能删除计费数据，确保数据安全到达目的地。

(3)对计费数据格式作检查。

如果格式错误，通过多种手段和途径对其告警.并对其重新采集或传输.或者通过其它手段在其他地方获取新的计费数据。

(4)采用程序退出采集时，采集进程确保正在处理的采集程序处理完毕后.采集进程才能退出以保证计费数据完整性。

(5)采集与传输分不同阶段的进行只有后一阶段的任务已经完成.才有可能把前一阶段的计费数据删除。

如出现停电.数据保存完整.确保不会丢失。

(6)计费数据传输采用数据发送、数据传输和接收数据时间分离确保长距离、网络传输状况不好的情况下的计费数据传输安全。[3]

2.2 采用实时的处理。

实时的处理，保证数据实时传送到目的.地有较高的安全性.避免数据的丢失等问题。

在系统选择方面.采用安全性较高的Unix系统。

Unix系统具有良好的安全性和具有能更好地支持用户等级权限。

在国内，计费数据采集与传输往往统一规划，组成一个大的局域网。

计费数据采集与传输利用局域网的防火墙和不透明性更好地与广域网隔离开，保证数据及时、安全而迅速的采集到采集机或传输到目的地。

与国际相连采用专用通道加密手段等保证其安全性。

3 结束语

网络与通信的迅速发展，要求计费数据采集与传输要适应计费的发展。

越来越多的网络，越来越多的交换机种类，越来越多的业务类型，越来越多的服务要求，越来越多的用户终端，要求计费数据采集与传输能够融合多个网络，支持多种类的交换机，支持尽可能多的业务类型，满足尽可能多的服务要求，兼容尽可能多的操作系统以用来满足不同终端的用户。

参考文献

[1] L.Herforth. 通信传输的原理与应用[M].上海:上海科学技术出版社，.2

[2] 于大安. 数据采集技术[M]. 北京：清华大学学报(自然科学版),.6

[3] 田燕.交换机采集技术与应用[M].北京：科学出版社，.10

[4] 李茂山.网络传输计费数据系统[M]. 北京：人民邮电出版社，2004.9

篇5：人才培养工作状态数据采集与管理论文

人才培养工作状态数据采集与管理论文

摘要：《高等职业院校人才培养工作状态数据采集平台》（以下简称“数据平台”）是高职评估的重要组成部分，已被广泛应用于国家优质院校建设和创新发展行动计划等多个领域。“数据平台”研究将有助于高职学院监测学院人才培养工作状况、了解自身优势与存在差距，从而成功应对面临问题与挑战，促进学校健康稳定发展。

关键词：高职院校；数据平台；研究

1高职院校人才培养状态数据采集与管理平台发展与应用现状

自《教育部关于印发<高等职业院校人才培养工作评估方案>的通知》（教高〔〕5号）中要求“所有独立设置的高等职业院校自本评估方案发布起，每学年度必须按要求填报“数据平台”以来，数据采集工作已经开展了十余年，平台已从最初的标准版（见图1）发展为网络版（见图2）。，高职状态数据中心（见图3）的创立实现了国、省、校数十亿条数据相互关联和贯通，标志着“数据平台”由数据采集向应用发展。，教育部印发《高等职业教育创新发展行动计划（-）》，提出了要“稳步推进高等职业院校人才培养工作状态数据管理系统的建设、部署与应用，逐步加强状态数据在宏观管理、行政决策、院校治理、教学改革、年度报告中的基础性作用。”遗憾的是，很多高校虽然开始重视数据平台的应用，但主要集中在数据查询、填写报表、完成年度质量报告等，制约了数据平台使用效率的充分发挥。鉴于此，对“数据平台”的`进行应用研究是很有必要的。

2数据平台数据功能分析与应用研究

2.1数据平台的功能分析

2.1.1统计汇总功能数据平台作为一个数据采集平台，可以统计汇总学院办学条件与教学工作现状的基本信息：院校基本办学条件、院校领导、实践办学条件、办学经费、信息化资源、固定资产、师资队伍、专业设置、课程设置、教学管理与教学研究、社会评价、学生就业信息、他补充信息和案例分析等。这些信息的统计汇总为学院了解自身办学条件与教学工作现状，进行数据查询提供了便利。2.1.2管理监控功能数据平台通过采集反映学校人才培养工作全过程的各项主要状态数据，为学校提供了一种有效管理的工具和方法[1]；教育行政部门通过数据平台能及时准确掌握高职院校人才培养工作现状、发展趋势和存在问题，强化宏观监控和指导的针对性；社会各界通过数据平台能了解高职教育发展状况，监督高职教育发展。[2]2.1.3比较分析功能高职数据中心对每所高职学校自20以来的数据平台数据进行了分析比较，形成高职学校的支持度、置信度、发散度和达标率仪表盘；对学校数据与全国示范中心数据、国家骨干及省示范中位数、同类中位数、省中位数、全国中位数和合格指标进行比较分析，形成“诊改核心指标”“案例分析指标”和“相对分析指标”；对学院数据年以来数据进行对比分析，形成“数据综合应用”等。这些非常有利于学校分析评价自身人才培养工作状态。

2.2数据平台应用研究

2.2.1监测办学现状数据平台数据统计汇总功能使高职学校能了解学院发展现状，尤其是案例分析和新增核心指标汇总数据更是方便学院监测发展优势与短板，扬长补短。例如，某院生均教学科研仪器设备值高于核心指标中评估指标4000元/生，但新增值低于核心指标中设定的10%时，就可监测出其科研仪器设备投入过低，需要适时上调学院科研仪器或实训设备购置预算，以满足学院发展需求。

2.2.2服务内部诊改当前，在大多数学校没有建立“校本数据平台”的情况下，可以通过“数据平台”“校级数据中心”收集数据，开展学校内部诊改工作。首先，按诊改5个层面梳理平台，找出对应关系：学校层面对应平台一级目录基本信息、院校领导、基本办学条件、办学经费、教学管理与教学研究和社会评价；专业层面对应专业和实践教学条件；课程层面对应子目录课程设置；教师层面对应师资队伍，学生层面对应学生信息。其次，扩展每个层面对应平台子目录乃至字段，进行诊改。当然，数据平台因采集数据有限，要更好进行诊断，最好是将数据平台与校级平台结合起来。

2.2.3科学规划发展战略高职院校通过数据中心数据对比分析，可确定学校在同类院校中的地位、与社会需求的符合度、发展的基本走向，从而科学制定发展目标和发展战略。[3]例如，对比分析表2中某校具有研究生学位教师占专任教师的比例，可以发现该校该指标高出同类中位数2.27个百分点，处于中等偏上水平；低于省中位数和全国中位数2.66个百分点，略低；分别低于国家骨干及省示范位数和全国示范中位和全国中位数11.29和17.61个百分点，差距较大。据此，该校就可以确定自身师资发展规划，逐步提高具有研究生学位教师比例，先发展至省级乃至全国中等水平，再发展成为省示范学校和国家骨干学校，将全国示范定为长期发展目标。

2.2.4存在问题数据平台在应用的过程中存在以下问题：一是数据采用报表化采集，真实性没有保证，不利于实施有效管理监测；二是数据一年采集一次，不利于及时监测，及时诊改；三是数据分析法多为对比法，不够深入，有待进一步提高，切实提高数据的应用效率。

3数据平台存在问题解决策略思考

3.1加强采集系统建设，实现源头采集和实时采集

随着智慧校园的普及，高职学校现已普遍建有自己的OA办公系统、教务系统、人事系统、学生系统、财务系统等，积累了大量的原始数据。数据平台可通过加强采集系统建设，建立校本人才培养工作状态数据管理系统，对接院校内部业务管理系统，实现数据源头采集和实时采集，提高数据采集的效率和数据的准确性，满足高职院校教育与教学管理监测、各级教育主管的宏观决策管理、授权教育专家的科学研究和数据分析的需求。

3.2深度加工分析数据，提高数据应用效率

数据的深入加工和分析，会产生更多的有效信息。高职数据中心若能对数据进行更深层的科学加工与分析，形成报表、曲线图或分析报告，将会更进一部提高数据平台的使用价值，扩大数据的应用层面，提升数据的使用效率，规范各项管理工作。

4结语

数据平台采集数据涵盖反映学校人才培养工作的主要信息，是政府监管高职学校和制定政策的有效凭据，也是社会了解高职学校的重要途径。高职学校在做好数据采集、确保数据真实和准确的同时，要充分利用数据平台进行自我监测、自我诊断，通过分析学校发展的优势、劣势和学校所处处地位，科学制定发展规划与策略，促进学校持续健康发展。目前，平台信息采集具有一定的滞后性，需要加强体系建设，实现数据的源头采集和实时采集，并对数据进行深度加工分析，以满足各方对平台应用的需求。

参考文献：

[1]何锡涛.高职评估数据采集平台的建设与使用[J].高教发展与评估，（5）.

[2]周慎.基于V2.11a001人才培养工作状态数据平台的功能与使用研究[J].湖北社会科学，（6）.

[3]郑卫东.构建高职院校教学质量保障体系的研究与探索———从数据采集走向数据管理[J].中国高教研究，（10）.

篇6：超声波测井的井下数据采集与传输系统的实现

超声波测井的井下数据采集与传输系统的实现

摘要：介绍了井下数据采集与传输系统的结构和工作原理，该系统采用先进的CPLD器件ISPLSI1016实现了其中的接口电路，解决了井下数据采集与传输系统的高精度、低功耗和小尺寸等关键问题。

关键词：数据采集与传输复杂可编程逻辑器件高速度低功耗小尺寸

随着石油工业的不断发展，测井技术越来越显示出其重要作用。超声波测井作为测井的一种重要方法得到了广泛的应用。由于测井仪器，特别是井下仪器工作环境的特殊性，使得对其研究和开发也具有特殊的要求。油井下的直径很小，因此对井下仪器的尺寸要求十分严格，一般来说印刷电路板的宽度不能超过4.5cm。体积达不到要求再好的仪器也无法在实际中应用。

本系统采用双CPU和双端口RAM，尤其是采用先进的PLD器件及1553总线技术很好地解决了井下高速数据采集与传输系统的可靠性、低功耗和小尺寸等问题。

(本网网收集整理)

1 系统结构简介

本系统采用两片AT89C52单片机分别作为主、从CPU；采用AD公司的高速A/D芯片AD7821进行井下温度、压力和幅值等参数的实时数据采集；选用两片美国Lattice公司的CPLD芯片isPLS1016实现数字信号采集处理接口电路和数据传输中的串并行转换接口电路；然后通过双口RAM（IDT7232）来传输数据。系统结构如图1所示。

2 系统工作原理与实现

在图1中，主CPU及其相关模块主要完成超声波发生器的控制、工作模式切换和数据采集等功能；从CPU主要完成主CPU所采集信号的上传和地面命令字的下传及命令解释，还包括一些监控功能。CPU对超声波发射装置进行控制，采集回波信号。由于回波信号的尖峰时刻非常窄，一般不超过1.0μs，所以对A/D的采样时间要求在ns级。本系统采用AD公司高速A/D芯片AD7821进行采集。数字信号部分，在启动超声波发生装置的同时产生时延控制信号，以便对回波信号的时间间隔进行计数，进一步测出井下的剩余壁厚等距离参数。所有采集的信号按一定格式存在双口RAM（IDT7132）内，以备从CPU调用和上传。

2.1 数据采集的实现

2.1.1 数字信号的采集

系统所需采集的数字信号的频率相差非常大。其中γ信号的频率在几赫兹到百赫兹之间。此信号直接进入单片机，用单片机的计数器进行计数，计算后得到频率。而超声波回的时间间隔只有几微秒，而且是定时产生，每次只出现一个。这样只能测量其周期。系统直接采用12MHz晶振信号的四分频作为测量周期的计数脉冲。除γ信号外的所有数字信号的采集模块完全集成在一片Lattice公司的isPLSI1016内。这样不仅大大提高了系统的集成度，满足了系统尺寸的特殊要求，而且增强了系统的可靠性和灵活性，方便系统的升级和调整。IsPLSI1016的内部设计框图如图2所示。

2.1.2 模拟信号的采集

对于回波的尖峰值，每次启动超声波发射器后采集一次；而对温度、压力等监控信号，每当7.14Hz的信号对单片机中断后才进行采集。7.14Hz的信号由外部提供。由于对精度要求不高，这里采用8位的转换精度。

2.2 数据的存储与传输

井下的数据采集频率接近2kHz，数据量非常大，不可能被完全存储下来。而且井下所需要的也不是全部数据，当发出数据上传命令后的前一个周期的数据为所要求的数据。这个周期信号即为上面提到的由外部提供的频率为7.14Hz的控制信号。因此在数据存储时，把RAM分成两种，0000～0fff为第一块，1000～1fff为第二块。主CPU对两块存储区进行交替存储。

7.14Hz信号接到中断0口上，并采用边沿触发方式。每次中断后，主CPU将改变各种相关参数。例如改变存储数据的RAM初始地址，即上一次是第一块则这一次为第二块，反之亦然。同时对P1.3口取非，即通知从CPU，主CPU正在写那一块RAM，以避免以CPU读取数据时发生读写冲突。

系统采用双口RAM作为CPU之间传递数据的中介，其结构图如图3所示。由于双口RAM的'高速存取，使大量数据能够及时地传输。

2.3 命令下达与数据上传

当从CPU接收到地面下传的命令之后，进行解释并通知主CPU。考虑到信号传输的可靠性，井下与地面之间的通信使用1553总线协议。1553总线的传输速率能达到1MHz以上。曼切斯特编码作为信道编码，提高信号传输的抗干扰能力。为方便实现曼切斯特编码以及总线接口，系统采用了专用曼切斯特编码/解码芯片HD-6408。HD-6408与CPU的接口用一片Lattice1016来完成。1016主要完成数据的串并行转换，以及6408编码/解码所需的外部时序。1016直接挂在从CPU并行总线上，从CPU通过对外部数据存储空间的读写来完成命令字的接收和数据的上传。

3 实验结果与分析

图4是ispEXPERT SYSTEM的仿真波形图。仿真测出的剩余壁厚为0xbb即187，与预计的结果一致。在系统传输可靠性测试中，误码率在10 -9以下，由于井下条件恶劣，实际应用中会略高。

该系统在与超声波发生器和上位机组合调试中，性能明显优于原来的分离逻辑电路系统。系统采集的参数增多，灵活性增强，可根据用户的要求增强或省云部分功能，以节约成本。

篇7：超声波测井的井下数据采集与传输系统的实现

超声波测井的井下数据采集与传输系统的实现

关键词：数据采集与传输复杂可编程逻辑器件高速度低功耗小尺寸

本系统采用双CPU和双端口RAM，尤其是采用先进的PLD器件及1553总线技术很好地解决了井下高速数据采集与传输系统的可靠性、低功耗和小尺寸等问题。

1 系统结构简介

2 系统工作原理与实现

在图1中，主CPU及其相关模块主要完成超声波发生器的控制、工作模式切换和数据采集等功能；从CPU主要完成主CPU所采集信号的上传和地面命令字的下传及命令解释，还包括一些监控功能。CPU对超声波发射装置进行控制，采集回波信号。由于回波信号的尖峰时刻非常窄，一般不超过1.0μs，所以对A/D的`采样时间要求在ns级。本系统采用AD公司高速A/D芯片AD7821进行采集。数字信号部分，在启动超声波发生装置的同时产生时延控制信号，以便对回波信号的时间间隔进行计数，进一步测出井下的剩余壁厚等距离参数。所有采集的信号按一定格式存在双口RAM（IDT7132）内，以备从CPU调用和上传。

2.1 数据采集的实现

2.1.1 数字信号的采集

2.1.2 模拟信号的采集

对于回波的尖峰值，每次启动超声波发射

[1] [2]

篇8：高职状态数据采集与管理平台的构建的论文

高职状态数据采集与管理平台的构建的论文

摘要：本文在深入对比高职状态数据采集与管理平台网络版和标准版各自优缺点的基础上，得出了在高职状态数据采集与管理过程中，网络版更具优势这一结论，探讨了网络版的程序开发模型、功能特点以及今后的发展方向。

关键词：状态数据；网络；数据源；数据检测

中图分类号：TP315.69 文献标识码:A 文章编号：1671―144001―0112―04

4月，《教育部关于印发<高等职业院校人才培养工作评估方案>的通知》（教高〔〕5号），推动高等职业院校人才培养工作跨入了一个崭新的阶段，其核心要点之一就是要求各院校建立“高等职业院校人才培养工作状态数据采集平台”（以下简称“状态数据采集平台”）。初期，状态数据采集平台采用单机Excel版的形式（以下简称“标准版”），各院校均采用单机版采集数据。由于单机版的局限，，教育部批准了“高等职业院校人才培养工作状态数据采集平台优化研究”的课题立项（教高司函〔〕234号），推荐部分省市陆续开始使用网络版，使得平台不仅成为采集状态数据的主要工具，而且逐步成为教育主管部门和学校日常管理、宏观调控、社会监督的重要工具，得到了有关方面的关注与重视。当前，状态数据采集与管理平台存在标准版以及网络版两个子平台。虽然教育部相关部门一直推荐和鼓励各院校使用网络版，但根据截止初的一个调查结果显示，全国仍有约700多所高职院校使用标准版采集状态数据。可见，网络版的推广普及仍需下苦功夫花大力气。自以来，在课题组系统研究与开发小组的努力下，网络版在原来的基础上进行了进一步的优化升级，使之在结构以及功能上都得到了全方位的提升。本文主要探讨该版本的构建思路。

一、网络版与标准版的区别

网络版是基于网络环境进行状态数据采集与管理的平台。数据范围包含标准版的所有内容，同时具有数据采集管理、用户管理、权限管理、数据备份以及数据恢复等功能，采用网络环境下的协同报表化采集方式。在使用及功能上，网络版与标准版存在如下差异（如表1所示）：总之，在使用及功能上，网络版比标准版具有较大的优势。

二、网络版开发采用的程序设计模型

状态数据采集与管理平台涉及十二个大项，七十多个小项目，共一千多个字段，数据项丰富，但每个页面的风格基本相同。如果按照传统的程序开发模型，页面与数据项一一对应，会导致开发工作量大，程序难以重用。并且，当数据项调整时，需调整相应的页面，从而容易导致回归错误。为此设计了一个可以根据预定义的数据项对平台进行动态调整的程序开发模型。该模型采用如下形式构建（如图1所示）。（一）定义采集数据项定义每个字段的属性，包括：字段名、字段类型、字段长度以及是否允许为空、是否必填等条件约束。（二）定义平台数据中心定义符合预定义数据项要求的数据中心，它将成为平台数据存储交换的中心。（三）设计转换器转换器负责将预定义的数据项加载程序WEB页面，并且将WEB页面提交的数据交换传输至平台数据中心。它是平台数据处理的核心，包括：1.根据页面请求加载相应数据项及标准；2.将加载的数据项及标准生成用户操作的WEB页面；3.将页面提交的数据对比数据标准要求进行数据校验；4.将页面采集的数据转换、生成到平台数据中心。（四）设计采集的WEB页面设计平台与用户进行交互的页面：

三、网络版的功能特点

（一）操作界面与标准版一致。鉴于网络版的用户大多数都使用过标准版，且评审专家大多熟悉标准版，因此，从方便用户出发，网络版的操作界面应尽量与标准版一致。（二）三大用户角色及其工作分配。在网络版中，设置了如下三种不同的用户角色：状态数据负责人：负责整个状态数据采集与管理工作，通常可由该负责人负责分配其他用户角色以及相对应的工作任务；数据表负责人：负责特定的数据表的数据管理工作，通常可由该负责人负责特定的数据表中其所属部门数据的审核工作；数据表采集人：负责特定的数据表的数据采集工作，通常可由该负责人负责特定的数据表中其所属部门数据的采集工作。默认地，教师是其本人基本情况、授课情况以及其他情况的数据表采集人；（三）灵活多变的开关设置。为了适应不同地区及不同管理模式的差异，网络版应同时兼容多种采集模式。为此，在后台中设计了多个开关设置供用户选择（如图2所示），以方便各院校使用开关的不同组合形成各种不同的采集模式。（四）统一的数据源管理。为了保持数据的一致性，将机构设置、部门领导设置、开设专业、教师情况（教师的基本情况、教师的授课情况、教师的其他情况）作为数据源统一管理（如图3所示）。并且，一旦某个教师的性质发生改变，则该教师的所有相关的数据记录在平台中的位置将会自动进行切换。例如当一名教师由校内专任教师调整为校内兼课教师时，该教师的基本情况记录、授课情况记录以及其他情况记录将从6.1表自动移至6.2表。（五）二大数据检测机制。为了保持数据的合理性，设置了二大检测机制：1.数据合理范围检测：检测关键数据值是否属于合理值区间内，以尽量避免奇异数据的出现；2.数据逻辑校验：采取与标准版一致的数据逻辑校验机制。（六）数据的导入与导出。网络版数据中心的数据可通过以下途径与Excel文件的数据进行交换：1.将Excel中多记录数据表的数据导入至网络版相应的数据表中，以充分利用Excel在多记录数据输入时的优势；2.将网络版的数据导出成标准版，以方便用户存档。（七）统一的任务提醒以及任务监测。由于网络版需多人在网络环境下协同进行状态数据采集与管理，因此，它内嵌了一个任务推送机制。一旦工作任务分配后，相关的任务承接人将会在平台中得到任务提醒。此外，各任务执行者当前的工作状态以及工作业绩均会在平台任务监测栏目中得以显示。（八）内嵌数据智能同步。它将网络版数据中心的的数据上传至云端的国家高职数据监测中心。上传前，它会自动对数据进行案例分析操作。（九）数据一键备份。它对网络版数据中心的`数据执行全量备份操作。（十）数据万能查询。它提供对已采集的状态数据的万能查询。

四、网络版今后的发展方向

今后，基于以下的原因，网络版必将会成为各高职院校人才培养工作状态数据采集与管理的主流平台。

（一）它与当前“互联网+”思维相适应。（二）它能与各高职院校当前使用的业务系统（如教务系统、学工系统、科研系统等）对接，实现源头实时采集状态数据的目标。为此，需在网络版数据中心的外围封装数据交换总线，并设计数据交换接口，以实现与其他业务系统的数据交换。目前，状态数据采集仍采用按年采集的形式。当网络版的普及使用达到一定程度时，将逐步从以年度为周期的数据采集形式过渡到以季度、月为周期的数据采集形式，并最终实现实时的数据采集，从而将由业务系统自动生成平台数据，达到“采集数据于无形”的效果。（三）可将网络版进一步扩展至移动采集模式，如移动APP或微信等，以方便各高职院校的师生进行数据采集。（四）可进一步实现多平台共享。目前仅高职系统内部就有“状态数据采集平台”、“专业建设平台”（即中央财政提升高职专业服务产业发展能力项目配套的专业建设与职业发展管理平台）以及高基报表等多个平台分立运行。由于各平台采集的数据存在大面积的交集，从而导致各高职院校大量数据重复采集现象的出现。今后，应首先确定高职的数据标准，然后基于数据标准对网络版的进行调整，实现状态数据采集与管理平台与其他平台的对接，使采集的数据实现“一次采集，重复使用”。

参考文献

[1]杨应菘.高职高专院校人才培养工作水平评估实践回顾与思考[J].中国职业技术教育,,(16).DOI:10.3969/J.ISSN.1004-9290.2006.16.003.

[2]陈易宇.高职院校数字化校园建设实践与思考[J].福建电脑,,(10).

篇9：Protocol Buffers在数据采集与传输系统建设方式论文

Protocol Buffers在数据采集与传输系统建设方式论文

随着通信技术和传感器技术的不断发展，数据采集与传输系统得到了越来越广泛的应用。而Google Protocol Buffers是Google公司开发是一款非常优秀的库，其定义了紧凑的、可扩展的二进制消息格式，特别适合用于数据传输。本文着重介绍了使用Protocol Buffers的对数据的封装和其反射机制来实现数据采集与传输系统的快速扩展采集数据类型。

1 Protocol Buffers概述

1.1 简介

Protocol Buffers（以下简称ProtoBuf）是由Google开发的一种数据描述语言。ProtoBuf定义了一种紧凑的可扩展二进制消息格式，能对结构化的数据进行灵活的、高效的、自动的机制来进行序列化。ProtoBuf可扩展方式的序列化结构数据被广泛应用在通信协议、数据存储等领域。

1.2 ProtoBuf的性能

一条消息数据，用ProtoBuf序列化后的大小是JSON的十分之一，是XML格式的二十分之一，是二进制序列化的十分之一。总体看来ProtoBuf的优势还是非常明显的。

2 应用在数据采集与传输系统中

这里所设计的数据采集与传输系统采用Slave-Master结构。其中Slave负责采集数据并将数据发送给Master；Master接收所采集的数据并做进一步处理。Slave可以支持多种数据类型（如GPS、图像等）的采集。

2.1 根据不同的采集数据类型，编写proto文件

在ProtoBuf中，所有的对象都被视为消息。消息的每个属性描述都可以使用required、optional、repeated来进行描述。ProtoBuf数据描述语言中也支持一些基本的数据类型如string、int32、double等等。

设Slave的采集数据类型有Type1、Type2。这两种类型的Proto描述命名为MsgType1和MsgType2（图1所示）。

经proto编译后，生成的消息类为MsgType1和MsgType2，它们均继承自google：：protobuf：：Message类。

2.2 设计支持不同采集数据类型的数据传输格式

在数据传输中使用ProtoBuf需要解决两个问题，一是数据的.长度：ProtoBuf打包的数据没有自带长度信息或终结符，这就需要由应用程序自己在发生和接收的时候做正确的分割；二是消息类型：ProtoBuf打包的数据没有自带的类型信息，在消息传输过程中，发送方需要将消息类型告诉接收方，接收方根据消息类型再做反序列化。对于长度问题，可以将长度信息作为消息的一个段来解决。而对于消息类型问题，可以使用ProtoBuf根据消息的类型名反射自动创建对应的消息对象的机制来解决。因此，可以设计基本传输格式的格式如图2所示：

ProtoBuf Message的序列化数据封装在message_data中，且称这种数据格式为Message Package（消息包）。

2.3 消息打包器的设计

消息包格式设计完后，首先要对不同的采集数据类型编写封装函数，以便将相应类型的数据封装到对应的ProtoBuf Message中。然后使用消息打包器将Slave所采集的某种类型的数据信息打包成上图的消息包。消息打包器先通过ProtoBuf将特定类型的采集数据进行序列化，并生填充Message Data。最后再填充Message Package中的Length 、Message Name等字段，完成消息的打包操作。消息打包器代码如下：

std：：string CreateMsgPackage（ const google：：protobuf：：Message& msg ）

{

std：：string msg_pack；

msg_pack.resize（ sizeof（ int32_t ））；

string& msg_name = msg.GetTypeName（）；

int32_t name_len = msg_name.size（）+1；

msg_pack.append（（char*）&name_len，sizeof（name_len））；

msg_pack.append（msg_name.c_str（），name_len）；

Msg.AppendToString（&msg_pack）；

char* begin = msg_pack.c_str（）+sizeof（ int32_t ）；

int32_t length = msg_pack.size（）-sizeof（int32_t）；

std：：copy（（char*）（ &length ），（char*）（ Length ） +

sizeof（ Length ）， msg_pack.begin ）；

return msg_pack；

}

2.4 消息解包器的设计

接收到消息包之后要进行解封装，分解出消息包中的各个字段，这里不再详述。ProtoBuf本身具有很强的反射机制，ProtoBuf可以能根据Message Name创建一个该类型的消息，然后使用Message Data来反序列化该消息，从而在Message Package中恢复出相应类型的Message，由此完成对消息的识别。由消息包来还原相应的消息的代码如下：

Message* CreateMsg（ std：：string& msg_pack ）

{

// 从msg_pack中分离msg_name、msg_data等的代码从略

Message* msg = NULL；

Descriptor* desc = DescriptorPool：：generated_pool（）->FindMessageTypeByName（msg_name）；

Message* prototype = MessageFactory：：generated_factory（）->GetPrototype（desc）；

msg = prototype->New（）；

msg->ParseFromArray（msg_data， msg_data_len）；

return msg；

}

2.5 消息分发器的设计

Master在得到相应类型的采集数据消息后，需要传递给相应的消息处理方法，这就涉及到消息的分发。消息分发器可以使用map来实现，由于每个具体消息类型都有一个全局的Descriptor对象，其地址是唯一的，可作为key；value为针对特定采集数据类型消息的处理函数，即std：：map，其中MessageCallBack为 boost：：function。由于消息分发器传给处理函数的参数是Message*类型，处理函数需要对其进行向下转型后才能使用。消息分发器在接收到某一消息后，在map中查找对应的处理函数，并执行该函数。

2.6 整体结构

在Slave端，用户需要使用proto数据描述语言描述该类型的数据，并产生相应的Message类型，此外用户还要编写相应数据类型消息封装方法。在Master端，由于与Slave使用相同的proto文件，消息解包器可以分辨出相应类型的Message。用户在Master端需要编写针对某具体类型采集数据的处理方法，并向消息分发器注册。消息分发器将消息解包器解出的消息作为参数调用对应的处理方法。

3 结束语

在Slave-Master结构的系统中通过编写proto文件来描述各种类型的采集数据；在Slav e端进行采集数据的序列化和封装；在Master端编写对应的采集数据处理方法，并将该方法注册到Master的消息分发器中，完成对采集数据类型的快速扩展。

Protocol Buffers .https：//developers.google.com/protocol-buffers/docs/overview.

陈硕.Linux多线程服务端编程——使用muduo C++网络库.北京：电子工业出版社.2013：220-236.

李纪欣，王康，周立法，章军.Google Protobuf在Linux Socket通讯中的应用.电脑开发与应用.2013，26（4）.

田源，潘晨光，丁杰.Protocol Buffers在即时通讯系统中的应用研究 .现代电子技术.2013，37（5）