C0726K16-中期报告

1）开题时拟定的研究方案、进度计划；若开题时的研究方案已经调整，应说明调整的原因、调整后该领域的国内外研究状况分析、研究内容、研究方法、进度计划等；
2）学位论文的研究进展完成情况、阶段性成果和创新点论述；
3）后续工作的设想、可能遇到的困难和问题及条件保障措施；

上一阶段计划

点击查看上一阶段计划方案

进度计划

开题时的研究方案总体思路未调整。上一阶段的全部既定目标均以完成。但接下来添加了单帧静态图像识别模式升级到实时视频流识别模式的功能升级。

当前阶段成果

1. 完成了系统总体设计和模块设计
2. 完成了后端核心服务API规范开发
3. 完成了图像识别模块的核心API封装和规范开发
4. 完成了完成了管理员UI（Web端）
5. 完成了作业人员端小程序UI（Web端）
6. 完成了DevOps持续部署以保障CICD
7. 完成了所有支持云原生组件的部署和集成工具

创新点论述

针对传统工件型号识别效率低、人工依赖强、信息化程度不足等问题，系统在架构设计、工程落地以及部署方式等方面进行了系统性的创新，主要的三方面如下。

1. 基于前后端分离架构的系统设计创新

传统工业信息系统多采用前后端强耦合的开发模式，系统扩展性和维护性较差，难以适应多终端、多场景的应用需求。本文创新性地采用前后端分离的软件架构设计思想，以现代 Web 技术为基础，实现了系统的高内聚、低耦合。

前端方面，系统基于 Vue 框架 构建 Web 可视化界面，负责用户交互、图像上传、识别结果展示以及维修调度信息的可视化呈现；后端方面，采用 FastAPI 框架构建高性能 RESTful API 服务，独立承担图像识别请求处理、业务逻辑调度以及数据交互等核心功能。前后端通过标准化 HTTP 接口进行通信，使系统结构更加清晰，功能模块边界更加明确。

在前后端分离架构的基础上，本文进一步扩展了微信小程序客户端，实现了 Web 端与移动端的统一后端服务支持，使系统能够覆盖现场巡检、移动拍照识别等实际工业应用场景。

2. 面向邮轮穿舱件的图像识别技术实际落地创新

与仅停留在算法验证阶段的图像识别研究不同，系统重点关注图像识别技术在邮轮工业场景中的工程化应用与实际落地。针对邮轮穿舱件型号多样、外观相似度高、现场拍摄环境复杂等特点，系统将图像识别技术与具体业务流程深度融合，实现了从“图像采集—型号识别—维修检查—调度决策”的完整闭环。

系统支持现场拍照或图像上传方式，对穿舱件进行自动识别，并输出对应的型号信息，为后续的维修检查、工单分配和资源调度提供可靠的数据基础。通过将识别结果直接嵌入到维修管理流程中，减少了人工查阅图纸和手动录入信息的环节，有效降低了人为错误率，提高了邮轮维修与运维管理的整体效率。

该创新点不仅体现了图像识别技术在复杂工业场景中的可行性，也验证了其在邮轮制造与运维领域的实际应用价值，具有明显的工程实践意义。

3. 基于云原生理念的系统部署与运行模式创新

在系统部署与运行方面，本文引入云原生（Cloud-Native）设计理念，实现了系统的现代化、标准化部署。系统所有核心组件均采用 Docker 容器化技术进行封装，包括前端 Web 服务、后端 FastAPI 服务以及相关依赖环境，从而有效解决了传统部署过程中环境不一致、迁移困难等问题。

通过容器化部署方式，系统具备良好的可移植性和可复现性，能够快速部署到不同服务器或云平台环境中。同时，基于现代 Web 技术与 API 服务架构，系统天然支持横向扩展和模块升级，为后续引入更复杂的识别模型、调度算法或多系统协同奠定了良好基础。

该云原生部署方案使图像识别系统从单一实验环境走向可持续运行的工程系统，提升了系统的稳定性、运维效率与实际应用价值，体现了本文在工程实现层面的创新性。

下一阶段目标

主要功能性升级

1. 单帧静态图像识别模式升级到实时视频流识别模式（为了方便，后续称为”单帧模式“和”流模式“）

当前属于静态图像识别模式：系统在用户触发拍摄后，采集一帧高分辨率静态图像，并基于该图像执行完整的工件识别与特征分析流程。该模式适用于对识别精度要求较高、工件姿态相对稳定的应用场景。

将微信小程序中的图像识别迁移到安卓应用中并自动识别（不再一张一张拍摄）

新系统功能基于摄像头实时采集的视频流，对连续帧图像进行在线分析与工件检测，并动态更新识别结果。该模式支持用户在移动设备的情况下自动识别视野中的工件，适用于快速定位与连续扫描场景。

2. 其他可忽略或不重要的工作

可能的问题

可能用到的背景知识

图像识别模块的工作原理是对计算机视觉技术对图像进行处理，将图片进行剪切、归一、分析、向量对比计算等操作后通过计算得出结果，对某一张图片的处理流程复杂且串行过程无法加速，只能通过并行加速，即增加工作单元流水线。并行加速将显著增加模型的运行成本。

WebSocket：WebSocket是新一代基于TCP长连接的通信协议，与HTTP协议不同的是，WebSocket可以保持长时间的链接和数据传输，适合视频、直播和实时通信。

计算密集型和IO密集型：在计算机中，CPU是计算元件，磁盘与内存是存储数据的元件。当某个任务需要大量CPU参与时（例如计算复杂方程，对数据进行编解码，则称这种任务是CPU密集型），如果是需要读写硬盘、进行数据流转、增删改查，则称这种任务为IO密集型。之所以需要区分IO密集型和CPU密集型，是因为CPU的处理速度相对于硬盘来说速度极快，如果CPU的一个计算周期是1秒，相对应的磁盘数据就会是1千万秒，相当于CPU每次计算1秒的任务，就需要等待两千多小时的磁盘数据。为了避免浪费，系统要么对CPU密集型进行优化，要么对IO密集型进行优化。

1. 速度限制问题

系统的模型是按照单帧模式设计的，QPS为每秒1帧，即每秒只允许一张图片进入系统处理，其他处理任务需要排队，这种模式无法串行加速，只能并行加速。

2. 系统重构问题

由于系统当前底层是按照单帧模式进行的，上述将单帧模式转为流模式的升级需求需要对系统底层进行重构，原因如下：

1. 连续性原因：对于单帧模式来说，图片可以被包装为一个HTTP请求，这个网络数据包大小约为1MB-10MB量级，因此系统可以正常和后台服务器进行HTTP通信。但如果数据切换为流模式，则需要采用WebSocket技术作为底层通信协议，这需要对系统底层进行重构。
2. 数据流转原因：在当前系统中，图片是通过对象存储（OSS）服务进行加速的，OSS对单文件处理能力优秀，因此作为整个系统的通用数据存储仓，但一旦切换到流模式，系统中便不存在单一文件，而是以视频流进行处理的，流文件对对象存储平台并不友好，需要的更多的是块存储方案。因此系统当前的存储层也需要重构。
3. 编解码原因：由于从处理图片转到了处理视频，原有的基于图像处理的模式无法应对视频，每段视频是经过编解码操作的，例如H.264编码解码，这就需要编码解码器或调制解调器参与，而编解码工作是强计算密集型场景，系统是按照强IO密集型场景进行设计优化的，因此需要重构。

2. 安卓应用的迁移问题

上述将单帧模式转为流模式的升级需求需要安卓平台的原生能力支持，由于微信小程序自《个人信息保护法》实施后不允许未取得广电牌照的单位或组织调用微信摄像头的持续录制权限，因此需要额外增加安卓的平台支持。

面对安卓应用的迁移问题，我们提出了如下几个可行方案，按兼容性排序，最前面的方案对系统改动最小，成本最低。

1. 切割方案：本质上是将视频流的某个时刻帧截取下来，作为图像切片，继续沿用当前系统。方案要点如下：

   • 不每帧都发 HTTP：持续识别≠每帧识别。一般做成：节流：每 200-500ms 发一次（2-5Hz）或 队列只保留最新：如果上一请求没回来，就丢掉中间帧，只发最新帧（避免“排队延迟越来越大”）
   • 压缩再上传：摄像头帧很大，直接传很慢。做法是把帧缩到比如 640px-960px 宽JPEG 压缩质量 60-80
   • 并发控制：保证“同一时间最多 1 个请求在飞”（或者最多 2 个），避免网络抖一下就卡爆
   • 坐标映射：把识别框画到屏幕上，利用UI绘制或者canvas图层叠加。

2. 推流方案：本质上是让客户端作为一个直播推流源，利用现有的RTMP协议和其他协议将运算逻辑搬到云端完成，客户端作为云端的一个结果控制台，方案要点如下：

   • 利用目前的三大推流协议：RTMP、SRT、WebRTC协议构建一个直播分发中心，将摄像头作为直播视频流的源头，把视频流发送到云端处理，避免本地CPU运算压力。
   • 对于云端来说，分成两个层切（Shard），一个是视频处理层，复刻第一个方案的截流方案，对本地压力很小，但对网络压力很大，需要边缘计算业务。
   • 再通过同样的协议将数据包传回客户端进行渲染。

3. 并行优化方案：增加多模型的方案，最直接也最昂贵，不推荐使用。