工程硕士专业工程硕士毕业论文范文精选十篇.docx
《工程硕士专业工程硕士毕业论文范文精选十篇.docx》由会员分享，可在线阅读，更多相关《工程硕士专业工程硕士毕业论文范文精选十篇.docx（43页珍藏版）》请在冰豆网上搜索。
工程硕士专业工程硕士毕业论文范文精选十篇
工程硕士：
专业工程硕士毕业论文范文精选十篇
本文是一篇工程硕士论文，工程硕士论文只能有一个主题（不能是几块工作拼凑在一起），这个主题要具体到问题的基层（即此问题基本再也无法向更低的层次细分为子问题），而不是问题所属的领域，更不是问题所在的学科，换言之，研究的主题切忌过大。
（以上内容来自XX百科）今天为大家推荐一篇工程硕士论文，供大家参考。
专业工程硕士毕业论文范文精选篇一
第1章绪论
1．1数字复合信号传输设备的发展
随着国家对数字信息化大力推进与发展，模拟信号已经不能满足人们对内容互动、多样化、个性化的要求，于是基于多种数字复合信号技术的传输流传输设备应运而生，有国家制定的标准，还有企业标准，并利用新的标准开发出各种产品，为模拟转数字提供了夯实的物理基础，并提供了从通道到内容的各种实时监测接口协议，为数字复合信号传输设备的提供了很好的基础，数字复合信号传输设备的的优点主要体现在：
数字复合信号传输设备的将传统的模拟信号转换成数字信号后，提供了高清晰度的数字内容，比模拟时收看到的内容更加清晰；采用此技术，可以利用原有模拟通道不变的情况下，能传输6-12套经过压缩解码过的数字流媒体，提高了资源的利用率；由于采用数字信号进行传输，所以可以方便的对信号进行加密和解密，从而实现通信的安全性；数字复合信号传输设备的还可以提供大量的多媒体信息，用户可选择收看个性化的内容。
正是因为多路调制和解调、激光技术、光电转换、模数转换在数字信号的发生革命性的发展，使得数字复合信号的传输设备厂家应运而生，2012年国家广电总局大力投入，做模数转换工作和普及数字复合信号传输设备的，广播电视数字化已被国家列入重点计划，并被纳入正在制定的国家中长期科技发展规划，2015年随着物联网的快速发展，这些技术得到了飞速发展。
………
1．2对数字信号的分析监测的必要性
随着数字复合传输技术的应用日渐成熟，我国各种传输网络的数字化也正在进行中快速的网改，以广播电视为例，计划是2019年完成全部数字化，原则上取消模拟信号的传输，了保证数字复合信号传输设备的及网络的正常运转和传输质量，必须采取相应的监测设备作为辅助手段，实时在线监测分析；因此需求而开发的码流监测和分析设备，数字多画面实时监播系统，信号防范系统；监测系统对整个前端系统进行实时监测，能快速定位到的设备包括：
多路调制、解调、编解码、复用、加扰、解扰、混频和传输等多个环节；整个系统涉及的各项技术指标比较多，其中的关键参数直接影响着数字信号质量和整个系统的稳定性，所以必须对关键的技术参数进行测试和实时在线监测。
在数字复合信号传输设备的系统建设过程中，模拟信号是按照MPEGII标准经过抽样、量化、分析及压缩编码形成基本码流ES（原始）流，ES流是连续码流，不可分段，把基本码流分割成子块，并加上相应的头文件数据封包形成封包的基本码流PES流，PES包和包之间可以是不连续的，在传输时将PES包再分段打成有固定长度188字节或204字节的传送包码流叫传输（TS）流；传输流经复用单元加入标准的PSI表／SI表以及加密信息形成多路PS传输流，最后上传混频器，进入HFC混合网中，在传输过程中，有的会用OTT或OTI及IPQAM等各种设备，这些设备的实时信息也是监测的重点。
……..
第2章数字复合信号的实时监测系统
2．1数字复合信号传输流的复用
MPEGII标准是ISO／IEC组织推出的音视频压缩的国际标准，目前全球70%的国家都在采用这一标准，图像质量达到了广播级，MPEG4已经达到高清和超高清级别了，被广泛应用于数字多媒体通信、数字复合信号传输设备的、高标清视频点播、会议系统、互联网视频会议、远程医疗、互联网高清教学等领域，MPEGII的传输TS流主要用于远程通信、有线广播，目前也有部分用户在用H264、H265等的编解码设备，数字信号监测系统是兼容这几个标准的，对于在DVB数字广播电视系统中，也是用数字复用技术复用后传输传送PS的。
MPEGII标准可分为三部分：
视频、音频、操作系统（通常是嵌入式操作系统），视音频编码是针对每单路信号的图像和伴频进行，视音频编码后的包是ES码流基本包（又叫原始包）,ES流经过复用封包后的包是PES基本流，PES基本流的包长度是不确定的，视频一般是单帧包，音频包长度一般为一个音频帧，被封包的视、音频基本码流再经过复用封包后，成为两种不同的码流，即（PS）节目信息流和传输流，在MPEGII系统中，数字信息复合、分离的过程又被称为系统复接、分接，由视音频的ES码流及数据复接生成的用于实际传输的标准信息流称为MPEGII传送流（TS：
TransportStream），根据传输媒体的质量区别，MPEGII中规定了两种复合信息流：
传送流（TS：
TransportStream）和PS流（PS：
ProgramStream）。
……..
2．2数字传输流的比特流要求
传输流是基于数据包（Packet）的位流格式而存在，每个数据包大小是188字节或204字节，204字节的格式仅仅在188字节的包后部加上16字节的CRC数据，其他格式全部是一样的；传输流的系统层是由系统层信息和有效数据负载信息构成；传输流系统层信息就是在基本数据（PES）包信息组成传输（TS）流的过程中，为了适用于信道传输和接收端单元恢复数据而添加的TS包头和其他相关控制信息的码流，传输流分组包是以一个4字节{0x47}前缀开始的，后面有一个13位的分组标识PID号信息值，PID号信息值通过PSl／SD表指定包含在传输流分组中的数据内容里，具有相同PID值的传输流数据包分组携带仅来自同一个基本流的数据，随后是适应字段数据信息值控制字段数据信息值值，连续性计数器字段数据信息值等信息；适应字段数据信息值控制字段数据信息值表示当前包携带调整字段数据信息值和有效负载的情况时，连续性计数器字段数据信息值是具有同PID值的TS流数据包之间的连续计数值。
从系统层的角度来看，TS包的结构一般有以下几种：
有调整字段数据信息值部分又有有效负载，只有调整字段数据信息值没有有效负载，只有有效负载没有调整字段数据信息值。
这就是所说的有效负载指的是原来PES包所包含的信息，携带有系统层信息（如PSl和Sl表）的数据包不含有效负载信息。
空包可以用于填充传输流，也可以再复合处理中被插入或删除，所以并不能假定空的分组会作为有效负载数据而被传送到解码单元，在此部分，有的设计厂商开发了TS流字幕广告插播器，见图2.2.1B单一传输TS流与混合TS的区别，当然这也是数字监测重点监测的部分。
…….
第3章码流监测的具体分析与实现.....20
3．1基本信息........20
3．2电子节目指南EPG分析.........35
3．3TRl01．290错误信息值监测.......38
3．4PS信息......42
3．5带宽信息........44
3．6视音视频信息......45
3．7数字信号的信息复用........46
3．8数字传输流的PCR分析....46
3．9软件设计与实现..........47
第4章总结.....65
第3章码流监测的具体分析与实现
3．1基本信息
传输流的基本信息实时监测包括码流传输速率、PID实时数量、网络名称、网络节点指标、传输流所包含的PS数量、每个PS的PS号和PS名称、PS是否被加密信息等信息；监测系统不但能实现普通的监测业务，还需具有智能布防技术实现智能布防和专业的数据库管理，并具有较高的码流采样精度，并有效的降低误报率，可实现以下功能：
RF信号分析、监测：
对射频信号的性能参数（通过电平，符号率，MER,EVM,星座图和RS前后的BER等）进行实时监视、监测、分析和报警。
TS码流，TS加扰流分析、监测：
对TS码流（SPTS和MPTS）进行专业级分析，监测内容包括复用带宽的监测、TR101290的监测、包间隔的监测、PCR的监测、节目的监测、图象质量的监测，SI/PSI的实时解表监测等等，通过具体的对信源的监测，可以让我们及时发现DVB平台出现错误的位置所在。
ES码流分析、监测：
对数字电视独有的ES（原始编码流）进行监测、监视，彻底解决DTV信源监测。
数据业务分析、监测：
如EPG（电子节目指南）、游戏、股票信息、和VOD等，满足开展MHP等数据业务的分析项目，可以开展更多的分析业务的“模板操作”。
……..
总结
本文主要讨论了关于数字复合信号在传输流中的实时监测与分析，同时也实现了多画面的实时报警与监测；系统性的分析与阐述了关键参数、整体结构和软件部分的设计，并详细分析了核心代码。
在数字信号实时监测与分析项目中，本人负责的调研与研发任务己基本完成；该码流分析软件主要完成以下几个重要功能：
目前该软件已经和数字多画面实时监测与分析联调成功，可以把实时获取的信息导入到数据库，可以实现远程实时监测，画面可以远程调度和回播。
通过这次课题的认真研究，我加深了对软件编程的熟练应用技巧，对数字信号传输流的特性及数字传输网也有了更加深入透彻的了解，同时意识到码流的分析监测对数字复合信号传输设备的推广的重要性，我也有信心研制出适合我国国情的数字复合信号传输设备的监测分析设备，推动数字信息化进程。
............
参考文献（略）
专业工程硕士毕业论文范文精选篇二
第1章概述
1.1项目来源
本项目来源于某个研究所的实际项目。
本课题主要负责实现分布式网络环境下的服务器状态监测，保证用户对分布式网络环境中所有服务器运行状态的实时监测，支持用户个性化定制服务器监测管理参数。
1.2项目开发目的和意义
分布式网络是由多个终端节点组成的，而且各个节点相互连接，网络中的每一个节点都有两条线与其相连，当其中的一条发生故障时，网络的通信传输可以通过另外一条路径完成，网络传输的可靠性较好。
因为该种网络没有网络控制中心等，所以不会因为网络中心被攻击而出现问题[1]。
分布式网络的优点是节点中相互连接，数据传输可以通过不同的路径进行，可靠性较好，但是不利于管理，而且因为节点多，所以安全性有待提高。
甲骨文白皮书《OracleContactCenterAnywhere分布式网络架构》中提到分布式软件架构的重要性在于它支持镜像过程和镜像数据库等故障保险机制，进而支持热备份功能[2]。
分布式网络环境下对监测服务器状态进行监测，是为了实现对分布式网络环境下服务器以及网络资源的统一管理和有效监测，能够实时获取分布式网络环境下各个节点服务器状态信息，满足对网络管理和突发事件及时应对的需要。
如果忽略了网络监测的环节，将会出现很多类似XX以各种方式外发文件、上班时间利用网络做不应该做的事等违规违法事件发生，这些都是非常严重的安全隐患。
所以在分布式网络环境下对监测服务器状态进行监测是非常必要的。
本项目的目的是在linux环境下将大规模分布式部署的Linux/Unix服务器作为监测目标，实现对服务器基本性能及状态指标的监测，主要包括CPU使用率、CPU负载、内存使用率、磁盘空间使用率、磁盘I/O、网络流量和系统特定进程等；同时支持用户级别的监测内容定制，如服务器特定运行信息参数设定，周期性获取服务器状态以及动态调整个服务器监测状态信息。
项目的意义在于构建了一种适合于分布式网络环境下数据传输的模型，着重解决分布式服务器状态管理系统中配置的下发策略，数据一致性的校验与维护，全双工通信网络组建，业务子系统间高效信息交换等问题。
为当前分布式环境下服务器监测领域提供了一个范例。
……..
第2章系统需求分析
2.1功能性需求
本项目来构建了一个面向分布式网络的服务器监测系统。
通过使用该系统，系统管理员能够实时掌控系统所在分布式网络环境下所有被监测服务器的信息，并且能够根据服务器信息对突发情况做出及时的应对处理。
系统的用户主要包含三类：
配置生成人、配置审核人、系统管理员，根据上述不同的用户可以进行系统用例设计，系统具体的用例图如图2-1所示。
配置审核人可以对所有等待审核的下发配置指令进行审核，决定是否放行。
（3）系统管理员系统管理员可以进行用户管理和系统管理两方面的工作。
用户管理包括对配置生成人和配置审核人信息进行管理的功能，系统管理包括系统监测、系统参数配置、查看日志和历史信息查询等功能。
为了实现上述不同系统角色所对应的系统功能，将系统划分为七个模块和一个前台系统。
其中，七个模块分别是通信模块、解析模块、数据镜像/加载模块、可靠性保证模块、日志模块、数据库操作封装模块、服务器状态获取模块。
每个功能模块的具体功能需求概述如下：
通信模块功能需求:
服务器在运行过程中，无论是人工操作还是系统自动发送消息，都能实现相邻节点间的数据发送、接收等操作。
解析模块功能需求服务器基于网络接收数据时，会收到上一个节点的服务器发过来的封装成固定格式的消息，需要根据消息类型按照对应的方式解析数据包并获取消息内容。
数据镜像/加载模块功能需求当服务器数据管理系统发送故障时，可以通过数据镜像/加载模块对最新的服务器数据镜像文件进行恢复。
可靠性保障模块功能需求在设备故障或重启等情况导致静态表或动态表丢失的情况下，可以从上游节点或同级节点获取最新备份。
并且在设备故障或重启后，需要定时保活机制和重传机制保证数据的正确传输。
被监测的服务器可以通过执行下发的配置指令进行服务器状态的获取以及用户级别的服务器监测内容的定制。
前台系统的需求是实现用户管理模块、配置生成模块、配置审核模块和系统管理模块。
其中，用户管理模块实现对用户信息管理的功能，配置生成模块实现人工生成配置的功能，配置审核模块实现对下发配置先机器审核后人工的审核的功能，系统管理模块实现将服务器信息进行图表等方式展示的功能。
…….
2.2非功能性需求
本条将由性能需求和运维和稳定性需求两个方面的需求来阐述非功能性需求。
（1）性能需求性能需求应包含如下几个需求：
服务器信息获取的时间误差小于2s。
程序内存使用率不差过50%，保证程序的正常运行。
（2）运维和稳定性需求运维和稳定性需求应包含如下几个需求：
配置策略下发的总成功率达到90%。
策略有效下发的总成功率=成功服务器数/目标服务器数*100%，只有高成功率才能保证系统运行的稳定性。
数据库入库成功率大于90%。
本系统关键程序重启次数不超过3次/周。
……..
2.3本章小结
章对面向分布式网络环境的服务器监测系统进行需求分析。
在需求分析方面，将整个系统进行功能性和非功能性分析。
在功能性分析方面，将系统分为多个模块和一个前台系统，并分别进行需求分析，使工作的模块性更鲜明，减少系统的耦合度，为系统后续的更新等工作提供了更大的便利。
在非功能性分析方面，提出了性能需求和运维和稳定性需求，要求系统具有更好的性能。
按照功能进行需求的划分，为后续开发研究工作奠定了基础。
……..
第3章系统总体设计.....7
3.1系统总体设计....7
3.2系统开发环境和工具........12
3.2.1开发语言........12
3.2.2开发工具........12
3.2.3开发环境........12
3.3本章小结..........12
第4章系统详细设计与实现.........13
4.1系统详细设计...........13
4.1.1数据库详细设计.....13
4.1.2模块功能详细设计..........15
4.1.3关键流程设计.........23
4.2系统实现..........29
4.3本章小结..........40
第5章系统测试与性能分析.........42
5.1后台模块测试...........42
5.2前台系统测试...........48
5.3系统性能分析...........50
5.4本章小结..........52
第5章系统测试与性能分析
5.1后台模块测试
系统后台部分由通信模块、解析模块、数据镜像/加载模块、可靠性保证模块、日志模块、数据库操作封装模块、服务器状态获取模块等七大模块组成。
不同模块之间相互独立同时又具有一定联系，对不同模块可以进行独立的测试。
表5-1是通信模块测试用例表。
其中，测试项包括了中心节点与二级节点通信，二级节点与三级节点通信，三级节点与二级节点通信以及二级节点与一级节点通信。
经过测试后，实际结果与预期结果一致，说明了后台运行的通信模块能够正常运行。
在测试这部分模块代码时，通过对h码表进行处理来测试，其中，h码表中的数据量为258113。
图5-1是未处理的h码表，图5-2是处理后的h码表。
write.txt中格式是“号码段+归属地+运营商+区号+身份证”，经过h码表重新整理后输出的结果是“号码段+归属地+运营商+区号”，并且，相邻两个字段之间的距离也重新处理为定长。
经过测试，hashtable构造的insert（）等函数功能正常，即数据镜像/加载模块功能正常。
………
结论
本文针对分布式网络环境下的服务器监测问题，基于需求分析、总体设计、详细设计、系统实现、系统测试等一系列软件工程方法，设计并完成了面向分布式网络环境的服务器监测系统。
本文取得的成果如下：
（1）支持分布式网络环境下的服务器监测的功能。
直接通过操作中心节点服务器上的服务器监测系统，在网络通信正常的情况下，可以获取当前分布式网络环境下所有其他服务器的信息。
（2）实现了服务器监测的高效运转。
分布式网络可以将负载由单个节点转移到多个，从而提高效率。
（3）代码模块之间的耦合度小，代码具有很强的复用性。
其中部分模块代码如日志模块，数据库操作封装模块等可以被其他系统开发使用。
当需要作出功能改动时，可以比较方便的进行修改。
（4）系统使用长链路保活技术保障系统的长期，高效运行。
同时也能降低因为通信中断而造成的网络丢包率。
（5）在数据镜像/加载模块使用hashtable保障程序快速高效运行。
（6）程序中加入了大量的日志信息跟踪程序的运行，可以及时，准确的跟踪程序运行路径。
遗憾的是系统前台做的比较简陋，由于开发环境的限制，不能开发真实分布式网络环境下的面向大规模分布式网络环境的服务器监测系统。
而且系统不是工作项目，由我个人完成，项目中难免有部分隐藏bug存在。
............
参考文献（略）
专业工程硕士毕业论文范文精选篇三
第一章绪论
1.1研究背景与意义
为指导银行的企业信息化建设方向和具体实施，推动银行业务良性、快速发展，支撑企业发展与战略目标的实现，2009年制定了中国邮政金融IT总体规划。
IT规划根据邮政金融业务的信息化战略，提出了适合邮政金融业务未来发展的IT建设重点和建设原则，设计了邮政金融信息系统应用架构、数据架构、基础设施架构、信息安全架构、IT治理与运维模式等，确定了总体实施演进策略与步骤、目标系统实施方案及系统改造整合方案。
………..
1.2渠道管理平台的研究进展
在渠道管理上，国外银行越来越重视网点与其他业务渠道之间的信息共享、服务对接和统一管理。
一方面突出网点在增进与客户互动交流方面的独特优势，另一方面充分利用其他服务渠道拓展网点的服务半径，寻求更多业务楊会⑴。
国内银行业受科技条件和经营理念的限制，不同业务渠道间的衔接性往往不够理想，银行网点与其他业务渠道之间相互割裂，各自为战的问题仍十分普遍，严重制约了银行的整体客户服务能力和对业务机会的挖掘能力[2]。
一些银行在解答客户业务咨询时，网点与电话银行的答复不一致的情况也时有发生，不利于向客户树立专业化的品牌形象[3]。
按照中国邮政金融IT总体规划，渠道管理平台为各渠道建立统一的数据标准和服务规范，实现流程和信息整合，降低各渠道整体的维护和开发成本为目标，将人工渠道、自助渠道以及外部渠道纳入其中，作为各类渠道的后台接入系统，实现渠道交易信息的统一传递和交易数据的统一分发，以及统一的安全认证和授权、统一的系统接入、统一的信息模型及转换、统一的流程管理、便捷的监控管理等，以满足新业务的快速部署、产品一次开发多渠道发布、产品主动营销、向客户提供一致的信息、为客户提供多渠道个性化服务等市场需求，实现所有渠道统一接入，屏蔽各渠道与各系统之间通讯方式、报文格式等接口的差异，实现各渠道应用业务逻辑的整合、机构人员的统一认证管理和安全管理，在各个不同的服务渠道上提供统一客户体验，实现渠道服务标准化管理功能。
………..
1.3本文主要研究内容
系统上线初期，柜员信息管理系统建立渠道管理平台系统所需后台人员（柜员）信息，渠道管理平台系统向柜员信息管理系统提供后台人员所需角色的标准数据，由柜员信息管理系统进行初始数据导入，并将人员信息（含对应角色信息）提供给渠道管理平台系统，渠道管理平台系统进行初始数据导入。
实现人员登录，进行相关参数维护，可以对柜面、柜员以及自助渠道进行异常监控预警。
本文一共分为七章，其结构安排如下。
第一章绪论。
本章简要介绍本论文的背景与意义、渠道管理平台的研究进展和本文的主要研究内容。
第二章对后台管理子系统实现所用到的关键技术进行总体描述，介绍了系统实现所用到的工作流引擎、通讯引擎、交易引擎以及SocketServer観讯配置。
第三章主要描述后台管理子系统的需求分析，包括系统的总体架构、整体功能模块划分、具体模块的功能需求分析、系统建设原则以及与其他系统关系。
第四章主要描述后台管理子系统的概要设计和数据库设计，总体描述系统的应用分层结构和总体交易流程，针对每个不同的模块划分设计表结构。
第五章主要描述后台管理子系统的详细设计与实现，对各个具_功能进行详细功能设计、类设计和业务流程设计。
第六章主要描述后台管理子系统的实现与异常处理，详细展现各个子模块的表现形式，对于运行过程的异常处理流程进行了描述。
第七章对本文的工作进行
升级会员 