团队作业3--需求改进&系统设计

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/Class34Grade23ComputerScience
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/Class34Grade23ComputerScience/homework/13482
这个作业的目标	需求改进&系统设计&计划
github链接	https://github.com/LeoLeung314/yolo7

一、需求&原型改进：

1.问题及修改

问题1：之前项目设计的目标不明确，过于宽泛，不能解决某个行业或者场景具体的“痛点”

解决1：调整了检测的任务为目标检测（更容易实现，应用范围更广），调整为检测工厂内工人安全的场景（检测工人是否佩戴安全帽，有无违规行为如穿拖鞋，没穿工作服），这样能避免管理人员看监控时因注意力分散而遗漏的情况，这样能有效应用在工厂的监控系统中，并且能解决实际问题。

最近组员有在做相关场景的项目，工厂明确给出先做安全帽，工作服，拖鞋等物品的检测任务，说明了在实际应用中存在这样的需求

2.修改完善上周提交的需求规格说明书

视频算法中台系统：基于 YOLOv8 的工厂安全行为实时检测与告警平台

（一）系统概述

本系统是一个基于 SpringBoot + Docker + CUDA + PyTorch + YOLOv8 + FFmpeg + ZLMediaKit 的 AI 算法中台系统，旨在实现 Java 调用 Python 脚本，在 GPU（Nvidia Tesla T4）上对 YOLOv8 模型进行加速推理。系统专门针对工厂安全生产场景，实时检测工人是否佩戴安全帽、穿着工作服、有无穿拖鞋等违规行为，并将识别结果通过 FFmpeg 推流至 ZLMediaKit 流媒体服务器，实现原始监控画面与实时AI识别画面的同步展示。系统还支持将违规行为告警结果推送至 Minio 文件服务器与 RocketMQ 消息队列，便于安全管理部门及时处理与追溯。

（二）面向用户分析

初期核心用户

工厂安全管理员：需要实时监控车间工人是否遵守安全规定，及时处理违规行为。
生产车间主管：希望了解车间实时安全状况，对工人进行安全管理。
系统集成商：需将安全行为识别能力集成到现有工厂监控系统中。

后期拓展用户

大型制造企业：用于多个厂区的统一安全监控管理。
安全生产监管机构：用于远程抽查企业安全生产情况。
建筑工地安全管理方：用于检测高空作业、危险区域的安全防护。

（三）功能性需求

安全行为识别功能
- 支持 RTSP/RTMP/HTTP/WS 等多种监控视频流输入。
- 基于 YOLOv8 实现安全帽、工作服、拖鞋等目标的实时检测。
- 支持 ONNX 与 TensorRT 两种推理模式，可通过参数切换。
流媒体推送与展示功能
- 将识别结果实时推流至 ZLMediaKit 服务器。
- 在 Web 页面中同时展示原始监控画面与 AI 识别画面。
违规告警与推送
- 检测到违规行为（如未戴安全帽、未穿工作服、穿拖鞋）时，立即生成告警。
- 告警信息包含违规截图、时间、位置等，并推送至 RocketMQ 和保存到 Minio。
- 支持告警信息实时显示在 Web 界面，并通知相关管理人员。
模型管理与任务调度
- 支持模型上传、转换（PT → ONNX → Engine）、部署与启用。
- 支持多个车间监控任务的并行调度与管理。
系统管理功能
- 用户管理、权限控制、日志查看、告警中心等。

（四）技术需求

开发环境

后端：SpringBoot + MyBatis + MySQL + Redis + MongoDB + RocketMQ
前端：Vue + Node.js
AI 推理：Python + PyTorch + OpenCV + ONNX Runtime + TensorRT
部署：Docker + Ubuntu 20.04

硬件需求

CPU：Intel Xeon Gold 5218
GPU：Nvidia Tesla T4 16G
内存：≥ 16GB
存储：≥ 50GB（含模型、视频、日志等）

性能需求

推理速度：支持实时视频流处理，无延迟、无卡顿。
并发能力：支持多路视频同时识别。
稳定性：支持 7x24 小时连续运行。

兼容性需求

支持 Linux / Windows 双平台运行。
支持多种视频格式与流媒体协议。
支持 YOLOv8n / YOLOv8m 等不同规模的模型。

（五）预期的用户数量

初期面向制造企业、工厂、系统集成商，预计 200+ 用户。
后期拓展至安全生产监管、多厂区管理等领域，预计 800+ 用户。

（六）系统的真实性、可用性以及价值所在

系统的真实性

采用主流技术栈，代码开源可复现。
提供完整的前后端代码、模型、数据库脚本，开箱即用。
支持真实监控视频流输入与实时推理输出，具备工业级可用性。

系统的可用性

提供详细的安装教程与 Docker 镜像，支持一键部署。
支持图形化界面操作，降低使用门槛。
提供完整的接口文档，便于系统对接与二次开发。

系统的价值所在

安全生产价值：实时检测工人安全行为，降低安全事故风险。
管理效率提升：自动告警替代人工巡查，提高管理效率。
数据追溯价值：所有违规行为记录在案，便于分析与追责。

（七）USER story

用户故事：王主管的智慧工厂安全管理

人物： 王主管（某大型制造厂安全主管）

背景： 王主管负责整个工厂的生产安全，传统方式是通过保安巡逻和监控室人员盯着几十个监控画面，但人工监控容易疲劳、遗漏，尤其是夜班时段。工厂规定工人必须佩戴安全帽、穿着工作服和劳保鞋，但违规行为仍时有发生。

故事开始：

周二上午 10:00 - 例行检查，发现隐患

王主管在办公室打开 "视频算法中台系统"，查看各车间的实时安全状况。

登录系统： 在浏览器输入 http://ai-safety.com:8080，输入用户名wang和密码，进入了系统管理界面。
查看任务： 他点击 【计算任务】，看到所有车间的监控任务都在运行中，包括"焊接车间"、"装配车间"、"喷涂车间"等。
实时监控： 他点击"装配车间"任务右边的 "视频图标"。画面中，工人们正在流水线上作业，AI实时识别出每个工人，并用绿色框标出"安全帽"、"工作服"，用红色框标出"拖鞋"。他注意到有一个工人被红框标出"拖鞋"，同时系统在画面顶部实时显示告警："检测到拖鞋！"

周二上午 10:05 - 立即处理，消除风险

王主管立即拿起对讲机，呼叫装配车间班组长："小李，你们车间3号工位有工人穿拖鞋，马上让他更换劳保鞋！"

同时，系统已经自动在 【告警中心】 生成了一条告警记录，包括违规截图、时间、工位信息。

周二下午 15:30 - 历史追溯与报告

王主管需要准备本周安全报告。他进入 【告警中心】，筛选出本周所有关于"拖鞋"的告警记录，系统自动生成了统计图表，显示装配车间是拖鞋违规的高发区域。

他将这些数据导出到Excel，并在下午的安全会议上展示，要求装配车间加强管理。

周三夜班 02:00 - 无人值守，自动告警

深夜，系统检测到焊接车间有工人未戴安全帽进入作业区。立即生成告警，并通过RocketMQ将告警信息推送到了值班保安室的电脑和值班手机APP上。保安迅速前往现场处理，避免了可能的安全事故。

故事结尾：

王主管在月底总结中写道："自从用了这个AI安全检测系统，我们的安全管控从被动响应变成了主动预防。系统就像永不疲倦的'安全之眼'，24小时守护着工厂，违规行为无处遁形。安全事故率下降了60%，管理效率提升了好几倍。"

通过这个故事，我们看到了王主管如何将系统的几个核心功能串联起来：
模型管理 → 计算任务调度 → 实时视频识别与推流 → 告警中心 → 消息/文件推送，最终高效地解决了工厂安全管理中的 "监控难、发现慢、处理迟、追溯烦" 四大难题。

3.功能定位和优先级的四象限功能分析

象限	功能类型	核心功能清单	优先级说明
第一象限（高价值+低难度）	核心基础功能	1. YOLOv8模型ONNX推理（CPU/GPU适配）；2. 视频推流（FFmpeg+Zlmediakit）与Web端双画面展示；3. 基础告警中心（识别结果实时告警）；4. 算法模型上传/管理（支持.pt/.onnx/.engine格式）；5. 计算任务启停与状态查看	优先级最高（P0）：满足“实时检测+可视化”核心需求，技术方案成熟（依赖现有Python/Java集成逻辑），无额外技术难点，是系统最小可行产品（MVP）的核心组成
第二象限（高价值+高难度）	增强核心功能	1. TensorRT推理加速（依赖CUDA/Cudnn环境适配）；2. 多环境兼容（Linux/Windows自动识别与脚本调用）；3. 推理结果推送（MinIO文件存储+RocketMQ消息队列）；4. 客户管理与告警定向推送	优先级高（P1）：直接提升系统性能（TensorRT加速）和业务适配能力（多环境、定向推送），但需解决环境依赖冲突、消息队列高可用等问题，技术复杂度高
第三象限（低价值+低难度）	辅助优化功能	1. 推送日志查询与导出；2. 系统监控面板（CPU/GPU内存占用率展示）；3. 字典管理（告警类型/模型类型配置）；4. 前端页面样式优化（如响应式布局）	优先级中（P2）：提升系统易用性和可维护性，但不影响核心检测流程，可在MVP稳定后迭代开发
第四象限（低价值+高难度）	锦上添花功能	1. C++推理代码集成（极限性能优化）；2. 自定义数据集训练可视化工具；3. 多模型并行推理调度；4. 跨平台移动端适配	优先级低（P3）：功能受众窄（仅商业极致性能需求）或投入产出比低（移动端适配需求弱），技术复杂度极高（C++ CUDA编程、多模型调度算法），可作为后期扩展功能

4.调整任务分解WBS及相应的项目进度计划

（1）任务分解 WBS

AI视频算法中台系统
├─ 阶段一：基础环境与核心功能开发（P0级）
│ ├─ 1.1 开发环境搭建
│ │ ├─ 1.1.1 后端：JDK1.8+Maven+SpringBoot项目初始化
│ │ ├─ 1.1.2 前端：Vue+Nodejs依赖安装与项目骨架搭建
│ │ ├─ 1.1.3 基础环境：MySQL/MongoDB/Redis部署与连接配置
│ │ └─ 1.1.4 流媒体服务：Zlmediakit容器化部署（Docker）
│ ├─ 1.2 核心功能开发
│ │ ├─ 1.2.1 模型管理模块：上传/删除/查询（支持.pt/.onnx/.engine）
│ │ ├─ 1.2.2 视频检测模块：YOLOv8 ONNX推理（CPU/GPU适配）
│ │ ├─ 1.2.3 视频推流模块：FFmpeg封装与Zlmediakit对接
│ │ ├─ 1.2.4 Web可视化模块：原始视频+推理结果双画面展示
│ │ └─ 1.2.5 告警中心模块：基础告警生成与列表展示
├─ 阶段二：增强功能开发（P1级）
│ ├─ 2.1 性能优化
│ │ ├─ 2.1.1 TensorRT环境部署（CUDA11.8+Cudnn8.6适配）
│ │ ├─ 2.1.2 .onnx模型转.engine格式工具开发
│ │ └─ 2.1.3 推理方式动态切换（ONNX/TensorRT参数配置）
│ ├─ 2.2 多环境兼容
│ │ ├─ 2.2.1 Windows/Linux环境自动识别脚本（.bat/.sh）
│ │ └─ 跨环境依赖适配（Python库版本统一、路径配置）
│ ├─ 2.3 数据推送与存储
│ │ ├─ MinIO文件服务器集成（推理结果图片存储）
│ │ ├─ RocketMQ消息队列对接（推理结果推送）
│ │ └─ 定时推送任务开发（1分钟/次）
│ └─ 2.4 业务扩展模块
│ ├─ 客户管理模块：新增/编辑/查询客户信息
│ └─ 告警定向推送配置（按客户分配推送规则）
├─ 阶段三：辅助功能开发（P2级）
│ ├─ 3.1 系统监控模块
│ │ ├─ CPU/GPU内存占用率采集与展示
│ │ └─ 运行任务数量/告警统计面板开发
│ └─ 3.2 日志与配置模块
│ ├─ 推送日志查询/导出功能
│ └─ 字典管理（告警类型/模型类型配置）
└─ 阶段四：测试与部署
├─ 4.1 功能测试
│ ├─ 核心流程测试（模型部署→检测→告警→推送）
│ ├─ 多环境兼容性测试（Windows10/Ubuntu20.04）
│ └─ 性能测试（TensorRT/ONNX推理速度对比）
└─ 4.2 部署上线
├─ 后端服务Docker镜像构建与部署
├─ Nginx前端部署与反向代理配置
└─ 生产环境（GPU服务器）环境配置校验

（2）项目计划

阶段	核心目标	主要任务
第1周	环境准备与镜像构建	安装 ZLMediaKit、MySQL、Redis、MongoDB、RocketMQ、Minio
第2周	后端服务部署	配置 SpringBoot 项目，启动算法中台服务
第3周	前端部署与联调	部署 Vue 前端，对接后端接口
第4周	模型转换与测试	将 YOLOv8 模型转换为 ONNX/TensorRT 格式并测试
第5周	流媒体集成测试	配置 FFmpeg 推流，测试实时识别与画面展示
第6周	告警推送与存储测试	验证 Minio 与 RocketMQ 的告警推送与存储
第7周	系统优化与文档整理	性能调优、日志完善、使用文档撰写

二、系统设计

I.系统架构设计

项目概述

该项目结合了 Java 后端（SpringBoot）、Python AI 推理（PyTorch/ONNX/TensorRT）、前端（Vue.js）、视频处理（FFmpeg）和流媒体（ZLMediaKit），通过 Docker 容器化部署，实现高效的 GPU 加速推理和视频推流。仓库中包含完整的代码、模型、脚本和部署文件，支持Windows 环境。

项目核心目标：通过 Java 调用 Python 脚本，在 NVIDIA GPU（如 Tesla T4）上进行 YOLOv8 的加速推理，将检测结果实时叠加到视频流中，并通过 Web 界面查看。系统每分钟将结果推送至 MinIO（文件存储）和 RocketMQ（消息队列），便于扩展。

技术栈总结：

类别	技术/工具	作用描述
后端框架	SpringBoot, MyBatis 3	REST API、数据库交互
前端框架	Vue.js, Node.js	Web 界面、视频流播放
AI 模型	YOLOv8 (n/m 版本), PyTorch 2.3.0	目标检测模型训练与推理
推理加速	ONNX Runtime 1.16.1, TensorRT 8.5	GPU 加速（支持切换）
视频处理	FFmpeg 4.2.7, OpenCV 4.7.0	视频解码、编码、框绘制
流媒体	ZLMediaKit	RTSP/HTTP-FLV 推流服务器
存储/队列	MySQL, Redis, MongoDB, MinIO, RocketMQ	数据持久化、缓存、文件存储、消息推送
部署环境	Docker, Ubuntu 20.04, CUDA 11.8, cuDNN 8.6	容器化部署，GPU 支持
其他	Nginx (反向代理), Shell/Python 脚本	跨语言调用、环境适配

系统架构设计分析

该项目的架构设计采用分层 + 微服务化 + 容器化的模式，强调跨语言集成（Java + Python）、GPU 加速和实时性。整体设计思路是：后端作为中枢调度，前端提供交互，Python 负责计算密集型任务，外部服务处理存储/流媒体。架构支持高并发视频处理，推理延迟低（实时无延迟）。

1. 整体架构分层

表示层：Vue 前端 + Nginx。
- Vue 应用负责用户交互：视频源管理、实时流查看（原始视频 vs. 推理视频）、结果查询。
- Nginx 作为反向代理，处理静态资源和负载均衡。
**应用层*：SpringBoot 后端。
- 核心控制器（Controller）接收 HTTP 请求（如上传视频源、启动推理任务）。
- 服务层（Service）封装业务逻辑：调用 Shell/Python 脚本执行推理，监控任务状态。
- 集成 MyBatis 进行数据库 CRUD，Redis 缓存会话/配置，MongoDB 存储非结构化结果（如日志）。
领域层：AI 推理引擎（Python 脚本）。
- YOLOv8 模型加载（.pt -> ONNX -> TensorRT 转换链路）。
- 支持两种推理模式：ONNX（通用，CPU/GPU）、TensorRT（NVIDIA GPU 专属，FP16/INT8 优化）。
- 脚本处理视频帧：解码 -> 推理 -> 非极大值抑制 (NMS) -> 绘制边界框 -> 编码。
基础设施层：
- 视频 I/O：FFmpeg 解码输入流（RTSP/文件），编码输出流。
- 流媒体分发：ZLMediaKit 接收推流，提供多协议输出（Web 可通过 HLS/FLV 播放）。
- 数据持久化：MinIO 存储推理图片/视频片段；RocketMQ 异步推送结果（JSON 格式，便于消费者订阅）。
- 部署：Docker Compose 多容器（后端容器、推理容器、流媒体容器、数据库容器），确保环境隔离和可移植性。

2. 关键设计模式与特性

跨语言集成：Java 通过 ProcessBuilder 或 Shell 脚本调用 Python，自动检测 OS 执行对应文件。
模型管理：算法模型目录支持热更新（.pt 训练模型 -> ONNX 导出 -> TensorRT 引擎构建）。使用 Ultralytics 库自动化转换，减少手动干预。
实时性优化：
- GPU 加速：TensorRT 引擎加载一次、多帧批处理。
- 异步处理：RocketMQ 解耦结果推送，每分钟批次上报，避免阻塞主流程。
- 容错：脚本支持异常重试，Docker 健康检查。
可扩展性：
- 模块化：易替换模型（YOLOv8 -> 其他），添加新检测类（自定义数据集训练）。
- 代码生成：集成 FreeMarker 自动生成 CRUD 代码，加速开发。
安全与性能：
- 权限：Spring Security（未显式，但可扩展）。
- 监控：日志集成，性能指标（如 FPS、延迟）通过 API 暴露。
部署设计：全 Docker 化，单命令启动。

3. 数据流与业务流程

输入：视频源（RTSP 流、文件） -> SpringBoot 调度 -> FFmpeg 解码帧。
处理：Python 脚本加载模型 -> YOLOv8 推理（检测框 + 置信度） -> OpenCV 绘制 -> FFmpeg 合成视频。
输出：推流至 ZLMediaKit -> Vue Web 播放；结果 -> MinIO (图片) + RocketMQ (元数据)。
周期任务：定时器（Spring @Scheduled）每分钟执行结果汇总推送。

II.数据库设计

MySQL——14张表

alarm_data
存储算法任务运行过程中产生的每一条告警（含告警类型、截图、时间、所属任务/模型/客户）。
algorithm_model
平台可下载/部署的算法模型注册信息（名称、模型编号、标签集、引擎文件路径、默认阈值等）。
algorithm_task
在某个视频源上实例化某个模型的“任务”记录（任务编号、推流地址、跳帧/阈值设置、进程 PID、启停状态等）。
customer
租户/客户档案（客户编号、接入密钥、回调地址、任务额度、状态）。
data_dict
全平台统一字典与枚举值，支持无限层级树（算法类型、日志动作、区域类型等）。
permission
菜单、按钮、API 三类权限点的定义（权限字符串、路由、图标、层级）。
role
角色定义（角色名、角色键、排序、状态、删除标记）。
role_model
角色与算法模型的多对多映射，控制“哪些角色能看到哪些模型”。
role_permission
角色与权限的多对多映射，即 RBAC 的核心授权关系。
role_task
角色与算法任务的多对多映射，控制“哪些角色能看到哪些任务”。
rocket_mq_fail_msg
RocketMQ 消费失败的消息日志，用于重试或审计（msg_id、队列、重试次数、消息体）。
sys_user
演示/遗留系统的简单用户表（登录名、用户名、明文密码、性别、邮箱、地址）。
user
正式平台用户账号（用户名、密码、手机号、角色键、注册类型、状态、最后登录 IP/时间等）。
user_role
用户与角色的多对多映射，完成“用户属于哪些角色”的绑定。

MongoDB中3 个 集合（collection）。它们存的都是 运行时产生的非结构化/半结构化数据，与 MySQL 的“业务主数据”形成互补：MySQL 管“配置和状态”，MongoDB 管“日志和大数据量”。

algorithm_log
存算法任务运行时的 stdout/stderr 日志（每条一行，带时间戳、主机、任务编号）。
作用：排障、性能分析、审计；数据量大且无需事务，放 MongoDB 方便水平扩展和 TTL 过期。
alarm_image
存每一次告警的 原始截图/画框图（二进制或 base64，外加任务号、模型号、时间、置信度）。
作用：前端“告警回放”直接根据 _id 拉图片；文件比 MySQL 的 alarm_data.alarm_image 字段更全，也避免把大 blob 塞进关系表。
inference_result
存每帧推理的 完整结构化结果（帧号、检测框数组、类别、置信度、耗时、硬件信息等）。
作用：事后做 模型效果评估、误报分析、再训练采样；数据格式灵活，字段随模型迭代可动态增减，MongoDB 的文档模型正好适用。

MySQL 负责“谁、什么模型、跑什么任务、告警摘要”；MongoDB 负责“日志长文本、告警原图、每帧详细 JSON”，两者结合实现 配置与海量日志/多媒体分离存储，读写性能与扩展性兼得。

III.架构设计图

IV.接口

算法中台接口对接文档

一.接口安全机制

1.Token和参数验签

目前暂不做校验，直接调用

2.请求头

请求头须传入访问键，即accessKey=xxx (xxx的具体值见文末)

二.业务接口列表

序号	请求方式	请求路径	提供方	接口说明
1	POST	/api/customer/updateCustomerHttp	金石	更新HTTP信息
2	POST	/api/algorithmModel/getAlgorithmModelListPageVo	金石	查询模型列表并分页
3	POST	/api/algorithmTask/addAlgorithmTask	金石	添加计算任务
4	POST	/api/algorithmTask/getAlgorithmTaskListPageVo	金石	查询计算任务列表并分页
5	POST	/api/algorithmTask/setAlgorithmTaskStatus	金石	启用/停止计算任务
6	POST	/api/sys/httpPushLog/getHttpPushLogListPageVo	金石	查询HTTP推送日志记录列表
7	POST	http://ip:port/xxx/xxx	客户	客户自定义HTTP回调接口用于接收模型的推理计算结果

三.接口详细信息

1.注册更新客户HTTP接收信息

(1).接口概览

操作	操作名称
协议	HTTP/HTTPS
请求方式	POST(请求参数以json形式封装在body中)
返回格式	JSON
请求地址	serverAddr + /api/customer/updateCustomerHttp

(2).参数说明

a输入参数

请求参数表

序号	名称	请求类型	是否必须	备注
1	customerNo	String	是	客户序列号(见文末)
2	httpReqUrl	String	是	HTTP数据接收地址(数据只支持Post Body 方式的请求)
3	httpReqHeader	String	否	客户自定义的请求头，算法中台将会在请求客户接口时带上该请求头，格式JSON字符串(如 {"key1":"value"})

b返回参数

参数	类型	描述
code	Integer	状态码
msg	String	返回信息
Data	Json	数据

返回结果示例:

{
"code": 200,
"msg":"sucess",
"data":{}
}

2.查询模型列表并分页接口

(1).接口概览

操作	操作名称
协议	HTTP/HTTPS
请求方式	POST(请求参数以json形式封装在body中)
返回格式	JSON
请求地址	serverAddr + /api/algorithmModel/getAlgorithmModelListPageVo

(2).参数说明

a输入参数

请求参数表

序号	名称	请求类型	是否必须	默认值	备注
1	pageNum	Integer	是	1	分页索引
2	pageSize	Integer	是	10	分页大小
3	searchKey	String	否		关键字搜索

b返回参数

参数	类型	描述
code	Integer	状态码
msg	String	返回信息
Data	Json	数据

返回结果示例:

{
"code": 200,
"msg":"sucess",
"data":{}
}

3.添加计算任务接口

(1).接口概览

操作	操作名称
协议	HTTP/HTTPS
请求方式	POST(请求参数以json形式封装在body中)
返回格式	JSON
请求地址	serverAddr + /api/algorithmTask/addAlgorithmTask

(2).参数说明

a输入参数

请求参数表

序号	名称	请求类型	是否必须	默认值	备注
1	modelNo	String	是		模型序列号
2	customerNo	String	是		客户序列号
3	videoPlayUrl	String	是		要计算的视频播放地址
4	taskName	String	否		任务名称(摄像头1)
5	skipFrame	String	否	0(不跳帧计算)	跳帧数量(每隔多少帧检测一次)
6	pushFrequency	String	否	60(60秒推送一次推理计算结果)	推送频率(每隔多少秒推送一次推理计算结果)

b返回参数

参数	类型	描述
code	Integer	状态码
msg	String	返回信息
Data	Json	数据

返回结果示例:

{
"code": 200,
"msg": null,
"data": {}
}

4.查询计算任务列表并分页接口

(1).接口概览

操作	操作名称
协议	HTTP/HTTPS
请求方式	POST(请求参数以json形式封装在body中)
返回格式	JSON
请求地址	serverAddr + /api/algorithmTask/getAlgorithmTaskListPageVo

(2).参数说明

a输入参数

请求参数表

序号	名称	请求类型	是否必须	默认值	备注
1	customerNo	String	是		客户序列号
2	pageNum	Integer	是	1	分页索引
3	pageSize	Integer	是	10	分页大小
4	searchKey	String	否		关键字搜索

b返回参数

参数	类型	描述
code	Integer	状态码
msg	String	返回信息
Data	Json	数据

返回结果示例:

{
"code": 200,
"msg":"sucess",
"data":{}
}

5.启用/停止计算任务接口

(1).接口概览

操作	操作名称
协议	HTTP/HTTPS
请求方式	POST(请求参数以json形式封装在body中)
返回格式	JSON
请求地址	serverAddr + /api/algorithmTask/setAlgorithmTaskStatus

(2).参数说明

a输入参数

请求参数表

序号	名称	请求类型	是否必须	默认值	备注
1	taskNo	String	是		任务序列号
2	taskStatus	String	是		任务状态(0:停止 1:启动)

b返回参数

参数	类型	描述
code	Integer	状态码
msg	String	返回信息
Data	Json	数据

返回结果示例:

{
"code": 200,
"msg":"sucess",
"data":{}
}

6.查询HTTP推送日志记录列表并分页接口

(1).接口概览

操作	操作名称
协议	HTTP/HTTPS
请求方式	POST(请求参数以json形式封装在body中)
返回格式	JSON
请求地址	serverAddr + /api/sys/httpPushLog/getHttpPushLogListPageVo

(2).参数说明

a输入参数

请求参数表

序号	名称	请求类型	是否必须	默认值	备注
1	customerNo	String	是		客户序列号
2	taskNo	String	否		任务序列号
3	status	Byte	否		推送状态
4	startTime	Long	否		推送开始时间(13位时间戳)
5	endTime	Long	否		推送结束时间(13位时间戳)
6	pageNum	Integer	是	1	分页索引
7	pageSize	Integer	是	10	分页大小
8	searchKey	String	否		关键字搜索

b返回参数

参数	类型	描述
code	Integer	状态码
msg	String	返回信息
Data	Json	数据

返回结果示例:

{
"code": 200,
"msg":"sucess",
"data":{}
}

7.客户自定义的HTTP回调接口(用于接收模型的推理计算结果)

(1).接口概览

操作	操作名称
协议	HTTP/HTTPS
请求方式	POST(请求参数以json形式封装在body中)
返回格式	JSON
请求地址	http://ip:port/xxx/xxx

(2).参数说明

a输入参数

请求参数表

序号	名称	请求类型	是否必须	备注
1	taskNo	String	是	任务序列号
2	imgUrl	String	是	图片访问地址
3	clsScore	String	是	目标分类及其对应的评分信息 (Json 字符串)
4	streamServerUrl	String	是	流媒体服务器地址
5	pushVideoPlayUrl	String	是	实时推送的视频流播放地址
6	computingVideoPlayUrl	String	是	实时计算的视频流播放地址
7	videoPlayUrl	String	是	原始视频流播放地址
8	alarmTime	String	是	告警时间

请求参数示例:

{
"taskNo":"AN9LZYvJ",
"imgUrl":"http://192.168.2.241:9001/algcenter-yolov8-sl-fh/AN9LZYvJ_2024-07-10 14:11:01.813995.jpg",
"streamServerUrl":"rtmp://192.168.2.241:11935/stream/live/dec_AN9LZYvJ?sign=41db35390ddad33f83944f44b8b75ded",
"pushVideoPlayUrl":"ws://192.168.2.241:11080/stream/live/ori_AN9LZYvJ.live.flv",
"computingVideoPlayUrl":"ws://192.168.2.241:11080/stream/live/dec_AN9LZYvJ.live.flv",
"videoPlayUrl":"/data/app/yolo/data/sl-fh/10.smoke.mp4",
"alarmTime":"2024-07-10 14:11:01",
"clsScore":"{"smoke":0.705,"fire":0.661}"
}

b返回参数

参数	类型	描述
code	Integer	状态码
msg	String	返回信息
Data	Json	数据

返回结果示例:

{
"code": 200,
"msg":"sucess",
"data":{}
}

返回代码表

返回代码	返回状态描述
200	正常
400	msg中获取具体错误信息
500	服务器异常

服务器地址

env	serverAddr	备注
测试环境	http://scjskj.tpddns.cn:9080
正式环境

必要信息

序号	serverAddr	备注
1	"customerNo" : "hymv8g1b"	客户序列号为hymv8g1b
2	"accessKey" : "kdjn5961"	客户访问键为kdjn5961

三、Alpha任务分配计划

Alpha 目标：
支持上传单张图片，返回带框图片 + 是否违规的人数统计。

3.1 Product Backlog 功能清单

编号	功能	描述	优先级
A	文件上传 + 任务创建页面	支持图片/视频上传，填写检测阈值等可选参数，调用 `/api/tasks` 创建任务。Alpha 可先做简版：上传 + 最近任务列表 + 查看结果。	中
B	任务结果展示页面	展示任务状态，显示图片带框或视频 overlay，提供人数统计及 JSON/CSV 下载。Alpha 可先做图片结果预览。	中
C	任务管理 API	`POST /api/tasks` 创建任务；`GET /api/tasks/{task_id}` 查询任务状态与基本信息，是前后端交互入口。	高
D	结果查询与下载 API	`GET /api/tasks/{task_id}/result` 返回 JSON；`GET /api/tasks/{task_id}/visual` 返回可视化图/视频。	高
E	文件管理模块	保存上传文件到本地（如 `uploads/`），生成唯一文件名并与任务绑定。	高
F	模型加载模块	服务启动时加载 YOLO 模型与配置（输入尺寸、类别列表等）。	高
G	预处理模块	图片 resize/normalize；视频解码逐帧处理，可抽帧。	高
H	推理模块	调用 YOLO 模型 inference，输出原始检测结果。	高
I	后处理模块	NMS，按类别过滤，阈值过滤，person 区域内判断 helmet/workwear，输出结构化结果。	高

Alpha 阶段待实现功能（MVP）
    •	F/G/H/I（YOLO 推理全流程）
    •	C/D/E（最小的后端 API + 文件管理）
    •	A/B（一个简单网页）
    •	K（简单文件存储）

3.2任务分解

模块	功能	负责人	预估时间
A-01 上传页面	实现单页前端：选择/预览图片、点击“开始检测”，调用后端 API	a	4h
A-02 上传校验与状态提示	校验文件类型/大小，显示“上传中/检测中/完成/失败”等基础状态	a	3h
B-01 结果展示布局	前端展示检测结果：原图 + 叠加框的图片区域 + 文本区域	a	3h
B-02 统计结果展示	展示总人数、未戴安全帽人数、未穿工作服人数、合规率等	a	3h
C-01 上传任务 API	`POST /api/tasks`：接收图片文件，基础参数校验，生成 task_id	b	4h
C-02 同步调用推理	在 C-01 中直接调用推理入口函数，等待推理完成后返回结果	b	4h
D-01 结构化结果封装	定义后端统一返回结构：检测框列表 + 每类人数统计，用 JSON 返回前端	b	3h
D-02 错误处理与返回	处理模型错误/文件错误/内部异常，返回统一错误码与错误信息	b	3h
E-01 文件保存逻辑	将上传图片保存到本地目录（如 `uploads/`），生成唯一文件名	b	3h
E-02 文件路径管理	约定并实现图片/结果文件的路径规则（按 task_id 存放），提供查询接口	b	3h
F-01 YOLO 环境与权重加载	配置依赖环境，加载安全帽/工作服 YOLO 权重，封装模型初始化函数	c	5h
F-02 模型健康检查	用几张样例图片跑通推理，确认模型输出维度/类别与预期一致	c	3h
G-01 图片预处理	实现：读取 image_path → resize/normalize → 转成模型输入 tensor	c	4h
H-01 单图推理函数	实现 `run_inference(image_tensor)`，调用 YOLO，返回原始预测结果	c	4h
I-01 后处理与 NMS	实现 NMS、置信度过滤，将原始输出转为 bbox + class + score 的列表	c	4h
I-02 类别映射与违规统计	将模型类别映射为“戴帽/未戴帽/穿工装/未穿工装”，统计各类人数	c	4h
I-03 结果可视化绘制	在原图上画框（按类别区分颜色），生成带框图片供前端展示	c	4h
K-01 结果文件存储	保存结构化结果 JSON、可视化图片到 `results/` 目录，并记录对应 task_id	d	3h
K-02 简单清理策略	设计并实现简单清理逻辑（如超过 N 天的任务文件可删除）（可先手动脚本）	d	3h
K-03 Alpha 集成测试	以任务为单位：从上传图片 → 获取返回结果 → 检查文件落盘/统计是否正确	d	5h

3.3甘特图

时间表

时间范围	主要任务说明	涉及模块编号	负责人
Week 1 Mon–Tue	YOLO 环境搭建、权重加载、样例推理跑通；完成图片预处理与单图推理链路	F-01, F-02, G-01, H-01	c
Week 1 Mon–Tue	后端基础：文件保存、路径管理、task_id 规范	E-01, E-02	b
Week 1 Wed–Thu	模型后处理（NMS/过滤）、类别映射、违规统计；结果可视化输出（画框）	I-01, I-02, I-03	c
Week 1 Wed–Thu	后端主流程：上传任务 API、同步推理调度、结构化 JSON 返回、错误处理	C-01, C-02, D-01, D-02	b
Week 1 Thu–Fri	前端开发：上传页面、状态提示、结果展示布局、统计信息可视化	A-01, A-02, B-01, B-02	a
Week 1 Fri–Sat	结果文件落盘、清理策略；首次端到端联调（上传 → 推理 → 展示）	K-01, K-02, C/D/E/F/G/H/I	d + 全员
Week 1 Sunday	Alpha 中期检查：主要链路是否跑通，修复关键 bug	全模块	全员
Week 2 Mon–Wed	深入优化：前端交互增强、后端返回结构稳定化、模型输出一致性检查	A/B 系列、D 系列、I 系列	a / b / c
Week 2 Wed–Thu	扩展测试：多样化图片、异常输入、模型边界情况	K-03, F/G/H/I	d / c
Week 2 Fri	全链路回归 + 性能检查（处理时间、响应格式、文件落盘）	C/D/E/F/G/H/I/K	全员
Week 2 Saturday	文档整理：接口文档、模块说明、部署说明；准备演示材料（截图/视频）	K-03, A/B/I	d / a / c
Week 2 Sunday	最终 Alpha 验收：Checklist 自查、演示排练、修复剩余问题	全模块	全员

四、测试计划

AI 视频算法中台系统测试计划

一、项目介绍

1. 项目背景

本项目是基于 SpringBoot+Docker+Cuda+Cudnn+Pythorch+Onnx+Tensorrt+Yolov8+ffmpeg+zlmediakit 的 AI 视频算法中台系统，支持人、车、火灾烟雾等目标的实时识别与视频推流，提供模型管理、计算任务调度、告警推送等核心功能，需通过全面测试保障系统稳定运行。

2. 参考资料

项目技术文档、YOLOv8 官方文档、TensorRT 推理手册、Docker 部署指南、系统需求规格说明书、《现代软件工程讲义 - 测试的计划和执行》。

二、任务概述

1. 测试范围

功能测试：模型管理（上传 / 修改 / 删除）、计算任务调度（新增 / 启用 / 停用）、告警中心、推送日志、客户管理等核心模块；
性能测试：模型推理速度、视频推流延迟、并发任务处理能力；
兼容性测试：Windows/Linux/Docker 环境、不同推理方式（ONNX/TensorRT）；
稳定性测试：长时间高负载运行下的系统稳定性；
接口测试：系统内部模块接口及外部对接接口（如 Minio、RocketMQ）。

2. 测试目标

功能：核心模块功能通过率 100%，次要功能通过率≥95%；
性能：单任务 TensorRT 推理延迟≤50ms，并发 10 个任务无卡顿；
兼容性：全支持目标运行环境，无环境适配 Bug；
稳定性：72 小时高负载运行无崩溃、无数据丢失；
接口：接口响应成功率 100%，响应时间≤1s。

三、测试策略

1. 测试人员分工

功能测试组：负责核心功能用例设计与执行、Bug 提交；
性能测试组：负责推理速度、并发量等性能指标测试；
兼容性测试组：负责多环境、多推理方式的适配测试；
接口测试组：负责内部及外部接口测试。

2. 测试方法

功能测试：采用黑盒测试，结合场景化用例覆盖核心流程；
性能测试：使用 Jmeter 模拟并发任务，监控 GPU/CPU 占用率；
兼容性测试：搭建 Windows、Linux、Docker 三种测试环境，分别验证 ONNX 和 TensorRT 推理方式；
稳定性测试：持续运行高并发任务，记录系统运行状态与日志；
接口测试：通过 Postman 调用接口，验证参数合法性与响应正确性。

3. 工具引用

功能测试：Selenium（前端交互）、Excel（用例管理）；
性能测试：Jmeter、GPU-Z（GPU 监控）；
接口测试：Postman；
缺陷管理：Jira；
日志分析：ELK 日志分析工具。

4. 测试阶段计划

测试阶段	工作内容	起止时间
测试准备	环境搭建、用例设计、工具配置	第 1-2 天
单元测试	核心模块单元功能验证	第 3-4 天
集成测试	模块间交互及接口测试	第 5-6 天
系统测试	全功能、兼容性、稳定性测试	第 7-10 天
性能测试	推理速度、并发、负载测试	第 11-12 天
验收测试	核心场景验证、用户体验测试	第 13 天

5. 测试停止及恢复条件

停止条件：核心功能 Bug 未修复导致测试无法推进；环境崩溃且 2 小时内无法恢复；
恢复条件：核心 Bug 修复完成；测试环境恢复正常并验证可用。

posted @ 2025-11-22 20:21 刘江浩阅读(19) 评论(0) 收藏举报

geigaogaofen

团队作业3--需求改进&系统设计

一、需求&原型改进：

1.问题及修改

2.修改完善上周提交的需求规格说明书

视频算法中台系统：基于 YOLOv8 的工厂安全行为实时检测与告警平台

（一）系统概述

（二）面向用户分析

初期核心用户

后期拓展用户

（三）功能性需求

（四）技术需求

开发环境

硬件需求

性能需求

兼容性需求

（五）预期的用户数量

（六）系统的真实性、可用性以及价值所在

系统的真实性

系统的可用性

系统的价值所在

（七）USER story

用户故事：王主管的智慧工厂安全管理

故事开始：

故事结尾：

3.功能定位和优先级的四象限功能分析

4.调整任务分解WBS及相应的项目进度计划

（1）任务分解 WBS

（2）项目计划

二、系统设计

I.系统架构设计

项目概述

系统架构设计分析

1. 整体架构分层

2. 关键设计模式与特性

3. 数据流与业务流程

II.数据库设计

III.架构设计图

IV.接口

算法中台接口对接文档

一.接口安全机制

二.业务接口列表

三.接口详细信息

1.注册更新客户HTTP接收信息

(1).接口概览

(2).参数说明

a输入参数

b返回参数

2.查询模型列表并分页接口

(1).接口概览

(2).参数说明

a输入参数

b返回参数

3.添加计算任务接口

(1).接口概览

(2).参数说明

a输入参数

b返回参数

4.查询计算任务列表并分页接口

(1).接口概览

(2).参数说明

a输入参数

b返回参数

5.启用/停止计算任务接口

(1).接口概览

(2).参数说明

a输入参数

b返回参数

6.查询HTTP推送日志记录列表并分页接口

(1).接口概览

(2).参数说明

a输入参数

b返回参数

7.客户自定义的HTTP回调接口(用于接收模型的推理计算结果)

(1).接口概览

(2).参数说明

a输入参数

三、Alpha任务分配计划

3.1 Product Backlog 功能清单

3.2任务分解