系统简介

​ 本智能考核评判系统主要用于潜艇操纵训练模拟器下，教练员对学员进行相关科目的训练与考核。

​ 要求潜艇操纵训练模拟器与主操纵台进行数据通信，并将主操纵台发送的数据显示在软件上。考核的相关数据通过界面显示出来。同时软件能够进行语音识别和声纹识别，不仅能识别人员所说的内容，还能识别人员的身份，对指令和人员身份的识别有较高的准确度。结合语音识别功能，软件能够进行智能考核评判，跟据识别的语音和身份，结合考核科目的需求，做到自动进行给学员操作评分的需求。

需求分析

功能性需求：

1.考核人员、管理人员登陆注册功能

2.考核人员信息录入功能（声纹、艇队、战位）

3.权限设置功能：考核人员仅能参与考核评判过程、管理人员可以查看历史记录、进行机器学习、人员修改等操作。

4.考核结果的自动评判功能：系统能够根据指令、传感器参数的变化、考核用时等参数进行准确的自动打分。

5.语音指令的识别以及分句功能：能够通过录音设备，将采集到的语音指令进行语音识别成一句一句话，并将识别结果显示到软件界面中。

6.考核人员身份识别功能：声纹识别，通过录音设备，将采集到的语音进行身份识别，判别是由哪位人员说话，并将其显示到软件界面上。

7.机器学习：系统能够根据录制的语音指令集训练语音识别模型和声纹识别模型，并能保存、调用模型。

8.传感器参数展示：把收到的数据包进行处理以一定形式实时地展现在界面上。

9.历史记录读取功能：能保存潜艇操纵训练历史数据，依据用户需求随时查看之前的考核评判整个过程。

非功能性需求：

1.性能需求：语音指令识别率大于85%，耗时小于1s。

2.性能需求：人员身份识别准确率大于90%，耗时小于1s。

3.性能需求：考核智能综合评判打分正确率大于90%。

4.易用性：系统界面简单、易于操作控制，每个功能操作步骤小于5次。

5.可靠性：系统的平均无故障时间大于30天。

6.安全性：系统在各种突发情况下能够保存当前正在考核的数据。

7.保密性：系统数据加密保护，保证采集、传输、处理过程中不被偷窥窃取篡改。

技术方案

一、在系统的数据通信实现的技术中，采用UDP协议。

1.每一条TCP连接只能是点到点的；而UDP不建立连接，所以可以支持一对一，一对多，多对一和多对多的交互通信，也就是可以同时接受多个人的包。

2.TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流，由于连接的问题，当网络出现波动时，连接可能出现响应问题；UDP是面向报文的，UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低。

3.UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信。

二、在交互界面的实现中，采用QT框架来进行开发。在本项目中，我们使用PyQt5作为前端界面的开发框架。Qt 是一个跨平台的C++应用程序开发框架。

它提供给开发者建立图形用户界面所需的功能。Qt是完全面向对象的，很容易扩展，并且允许真正地组件编程。Qt不但拥有了完备的C++图形库，而且近年来的版本逐渐集成了数据库、OpenGL库、多媒体库、网路、脚本库、XML库、WebKit库等等，其核心库也加入了进程间通信、多线程等模块，极大地丰富了Qt开发大规模复杂跨平台应用程序的能力。而且考虑到可能会有打包成exe可执行文件，画曲线图等等需求，pyqt5显得更加合适。

三、在智能语音识别技术中，声学模型采用DFCNN-BLSTM模型，语言学模型采用Transformer模型，声纹识别模型采用CNN-BLSTM模型，并进行大量的实验验证其识别的可行性。

四、在考核智能评判中，采用SQLite存储历史记录。只是单机上用的，数据量不是很大，需要方便移植或者需要频繁读/写磁盘文件。一个应用使用SQLite时，它的功能直接被集成在其中，应用会直接访问包含数据的文件(即SQLite数据库),而不是通过一些端口(port, socket)来交互，SQLite相对非常快速、简单和高效。

项目周期

2022.06-2022.07

对系统进行需求分析以及系统的建模，考虑到各种功能性、非功能性需求，确定采用的技术方案和整体框架结构。

2022.07-2022.11

进行系统界面的开发，各项功能的开发、对软件的实地测试，中期验收、定期与甲方碰面进行需求的增删修改，最终使得系统可以满足甲方各种需求、成功运行。

2022.11-2022.12

完成系统技术方案、测试文档、使用说明书等相关的撰写，完成系统的验收，准备后续实际投入使用的相关工作。

开发过程中问题

1.曲线图无法长期显示，约10多秒即卡死。（曲线问题）

起初看曲线画大概10几秒图就卡死，画出曲线的形状也不对，觉得可能是Pyqt5的图表控件Qchart问题，搜了一些相关解决方案并尝试，尝试加了一些加速的接口比如openGL（）等等效果不明显。于是觉得不会是控件的问题，应该是接受上位机数据的问题。对发送端进行检测，发现发端机器一秒钟会发1000次左右重复的数据，操纵机器导致相关参数的变化后，每个值都会重复很多次，因此曲线上显示的一个点其实有很多重合在一起，累计十几秒一张图上已经有很多很多的点了，所以才会卡死。实际接受数据的刷新频率大概1s一次即可，但UDP是阻塞发送的，仅仅设置一秒读取一次会一直读取缓冲池里的重复的1000个数据才会读到下一秒的，因此想到一个简单的解决方案，将缓冲池设置为帧长*2-1，保证能接受一个完整帧的同时，不会一直重复读到上一秒的无用重复帧，导致曲线一直是直线。

（还怀疑过是不同语言、操作系统等对帧封装的格式有点问题，虽然都是UDP协议,因为上位机代码猜测应该是C++写的还可能是linux，后面要了一下上位机发的报文段用工具截取一个字节一个字节对，python确实尾部多了个CC，但是后面也实际模拟测试下没有影响。）

2.完善并优化一些相关功能。