医疗超声成像系统设计建议2
2025-12-20 22:33 ahuige 阅读(295) 评论(0) 收藏 举报注:
- 前篇 成像系统开发一点感想 ,主要简要罗列超声成像系统软件开发所涉及的关键技术领域;
- 本篇主要根据日常开发积累概要叙述从需求,设计到实现各阶段重要工作内容;
一、需求分析
1.1 功能需求
1.1.1 探头选择
- 支持的探头类型
- 执行探头选择重置系统(成像)参数的逻辑
- 执行探头选择从影像回放中返回实时
- 执行探头选择从其他系统工作模式返回B模式
1.1.2 工作模式
- 支持的工作模式
- 基础模式
B,C - 频谱模式
PW,CW - 组合模式
PW from C
- 按下工作模式按键重置系统工作状态的逻辑
- 按下工作模式按键从影像回放中返回实时
1.1.3 参数调节
- 不同系统工作模式可调参数,尤其为组合工作模式时
1.1.4 影像回放
- 冻结、离线回放公用的功能和流程
- 冻结回放专属的功能和流程
- 离线回放专属的功能和流程
- 支持系统离线模式(开发调试用途)
1.1.5 用户输入接口
- 键盘
- 触摸屏
- 其他
1.2 性能需求
1.2.1 系统启动(初始化)
- 初始化时序
- 硬件模块状态自检
- 通信失败重试机制
1.2.2 系统关机(退出机制)
- 关机时序
- 硬件保护逻辑
- 通信失败重试机制
1.2.3 探头选择
- 探头识别
- 切换耗时
1.2.4 模式切换
- 切换质量
- 切换耗时
1.2.5 成像流水线
1.2.5.1 FPS相关
- 不同roi,尤其典型尺寸(最大最小)时的系统帧率
1.2.5.2 图像分辨力
1.2.6 参数调节
- 对实时影像显示影响
1.2.7 影像回放
- 回放时帧率调节支持
二、系统设计
2.1 功能取舍,性能权衡
2.1.1 产品、功能组合
- 打法:远射VS泛光VS远泛兼顾
2.1.2 系统维护性、扩展性
2.2 API设计
成像流水线
2.3 对接流程与日常沟通
2.3.1 与算法
2.3.2 与硬件
- 与外协
- 与硬件团队
2.4 成像质量的保证
2.4.1 如如何防止版本迭代造成对成像质量的退化
- 应用
- 算法
- 硬件
- 其他
三、软件设计
3.1 架构选型
3.1.1 问题领域
- 成像系统的特征
采集,解析,显示
3.1.2 团队组成
- 应用与算法团队一起工作
- 应用与算法团队独立工作
3.1.3 架构模式
3.1.3.1 DDD
3.1.3.2 vs MVC
- 模型包含成像流水线;
- 单独成为一个模块如Communication;负责抓帧与解析;对成像算法的封装调用也在其中;
- 控制器负责协调它以及完成各种状态,模式切换;
如参数调节时View更新->控制器协调->模型校验->控制器决定是否通知硬件更新,算法更新->控制器决定是否通知UI->UI响应;
3.1.3.3 vs 插件
将什么(业务逻辑、公共服务、算法库)作为插件;
3.1.3.4 vs 微服务
3.2 模块设计
3.2.1 系统配置参数管理
3.2.1.1 参数分类管理
- 用户参数、系统参数、默认参数、可调参数
3.2.1.2 实现方式选型
-
用户参数:txt
-
系统参数:xml
支持多探头,多种成像模式等 -
可调参数:json
更新,传输
3.2.2 支持多种工作模式成像,调参并易于扩展
-
影像控制器负责核心采集,帧解析工作;
通过调用模型层的核心依赖(Communication);
对成像算法的封装调用也在其中; -
采集控制器负责除上述影像控制器之外的协调工作:探头选择、系统工作模式切换;
3.2.3 成像流水线独立封装,甚至作为SDK提供的能力
- 对抓帧,帧解析模块的依赖
3.2.4 参数调节
- 和实时成像流水线解构??
3.2.5 影像回放
- 冻结,离线回放公用功能和流程
- 冻结,离线回放各自专属功能和流程
- 系统离线模式(开发调试用途)与实时采集模块的耦合与解耦
- 影像回放机制与实时采集模块的耦合与解构
3.3 API设计
3.3.1 系统工作模式切换
- 封装各种系统状态的组合,耦合;
3.3.2 成像流水线独立封装,甚至作为SDK提供的能力;
- 商业价值的另一种体现
- 影像采集模块APIs
init
start
stop
release
- 输出一帧2D Image的APIs
frameReceived
appendInputData
prepareInputData
setInputData
checkInputData
transformData
imageResolved
3.3.3 参数调节
- 对接各种用户输入设备(多功能键盘、触摸屏等)
3.3.4 影像回放
- 冻结,离线回放公用的API设计
- 冻结,离线回放各自专属的API设计
- 影像回放机制与实时采集模块交互的API设计
3.4 算法设计
3.4.1 业务逻辑模块
3.4.1.1 成像流水线
3.4.1.1.1 步骤
- 抓帧,
- 解析,
- 显示
3.4.1.1.2 关键实现
1 抓帧
-
超时重试、
-
校验完整帧、 -
此外,参数调节响应、
2 解析
-
待处理帧缓存
-
校验完整帧
-
每帧处理耗时统计
支持不同工作模式分别统计 -
丢帧逻辑
-
异常处理
3 显示
-
发送UI模块之前的缓存
-
格式转换(适配UI显示)
3.4.1.1.3 协调上述
- 实现抓帧,解析,显示三个工作线程的通信,
- 考虑可能的通信延迟,成像流水线执行中的数据一致性;
3.4.1.2 探头选择
- 重读系统配置参数的设计
- 选择探头从回放中返回实时;通知其他业务模块,UI分别响应的逻辑;
3.4.1.3 模式切换
- 状态切换采用暂停而不是完全停止各依赖模块线程的好处;
- 按下模式键从回放中返回实时;通知其他业务模块,UI分别响应的逻辑;
- 影像控制器需要更新、存储系统工作模式,包括频谱准备状态;
3.4.1.4 参数调节
- 闭环响应
参数调节系统响应处理逻辑:UI->业务模块(含异常处理)->UI;
- “不更新,不响应”的基本原则:与硬件,与算法等模块;
- 对其他业务模块的影响:实时帧解析、冻结帧缓存重置、
3.4.1.5 影像回放
- 进出冻结流程实现
- 从实时采集状态进入离线回放状态流程实现
- 影像回放选帧逻辑
- 频谱影像回放的特殊性与设计实现
1 存储帧
铺满一屏幕
未满一屏幕
2 回放帧
3.4.1.6 其他系统基础设施
- 系统初始化校验流程
3.4.2 成像算法与封装
- 经算法APIs处理,输出一帧2D Image的成像流程
3.4.2.1 对接流程与日常沟通
- 与算法输入输出打印
配合FPS计算时
3.4.2.2 成像流水线的异常处理
- 丢帧逻辑
3.5 IO设计
3.5.1 网络通信
-
通信方式(串口、USB,PCIE等)选型:结合硬件设计,系统设计;
-
同步或异步发送方式:综合功能需求和性能需求;
3.5.2 文件存储
- 文件分类、
- 性能考虑、
3.5.3 数据库访问
- 工作线程处理与Gui响应
3.5.4 进程间
- 单进程 VS 多进程
3.5.5 线程间
- 采集,解析,显示工作线程之间的通信
3.6 性能设计
3.6.1 成像流水线
3.6.1.1 一帧整体处理耗时与优化
-
丢帧逻辑
-
莫忘了硬件约束
GPU(成像算法),
USB/PCIE(抓帧),
3.6.1.2 抓帧,解析,与显示各环节通信及处理延迟测量
- 使用帧号索引协调
3.6.2 探头选择
3.6.3 实时工作模式切换
- 如经串口通信发送的参数的系统响应性,效率问题;
- 切换过程耗时优化关键点:抓帧,解析,与显示;
- 状态切换采用暂停而不是完全停止各依赖模块线程的好处;
3.6.4 参数调节与系统响应性
- 多线程运行管理,如与实时帧处理的耦合、对冻结帧缓存的重置;
- 调节响应时长
- 对实时影像显示影响
影像卡顿(尤其当快速调节如CROI,B深度时)或屏幕瞬间黑一下;
3.6.5 影像回放
3.6.5.1 冻结回放
- 进出冻结切换性能
- 冻结回放选帧性能调优
对实时帧解析模块缓存清理的逻辑
3.6.5.2 离线回放
- 毕竟基于rawData
3.6.6 数据保存
3.6.6.1 源数据保存
- 至少不对实时采集影像如卡顿,影像更新显示延迟等;
3.7 其他系统基础设施设计
3.7.1 数据库设计
- 支持多线程访问,尤其写入操作;
3.7.2 日志机制
- 支持多线程并发访问日志、防止递归写入,日志文件轮转时的并发错误(重复记录;
3.7.3 内存管理:
- 算法使用内存的管理:应用端分配和回收VS算法内部管理;
3.7.4 多线程程序设计
3.7.4.1 支持高帧率的成像流水线
- 采集,解析,显示工作线程之间的间通信
- 用户线程(GUI)与采集,解析,显示工作线程之间的通信
- 采集工作线程的设计
- 解析工作线程的设计
- 显示工作线程的设计
3.7.4.2 系统工作模式切换、
- 对采集,解析,显示工作线程的暂停与恢复逻辑;
3.7.4.3 成像参数调节、
- 用户线程与算法API共享资源的访问冲突解决;
- 用户线程与采集,解析,显示工作线程之间的资源访问冲突解决
3.7.4.4 影像回放
- 进出冻结状态对采集,解析,显示工作线程运行状态的控制
- 冻结回放选帧对实时帧解析工作线程的缓存清理逻辑
3.7.5 系统异常处理机制
- 对算法模块独立为一个进程进行管理防止其异常导致主程序退出甚至
浙公网安备 33010602011771号