彩超框架EchoSight开发日志记录
EchoSight开发记录
作者：蒋志强
不定期更新EchoSight开发日志记录，最近更新于2024年02月02日
1.背景
由于某些不可抗逆的原因，离开了以前的彩超大厂，竞业在家，难得有空闲的时间。我计划利用这段时间 自己独立 从零开始 搭建一套 彩超系统的软件工程框架。这个框架的设计水准力求达到目前商业级产品中 第一梯队 的水平。
这套工程框架，我暂时取名为EchoSight。Echo表示声音/回声，Sight本意为视野/看见的意思，所以EchoSight就是通过超声成像的意思，非常务实；开发基本完成后，如果没有什么特别原因，我会把程序分享出来（可执行程序），请各位业内大牛指教。
作为目标达到商业级 优秀的工程框架，EchoSight需要满足很多的要求，包括：
1. 框架的可扩展性；
2. 框架的高度灵活配置性；
3. 后续扩展开发的模块独立性与低耦合，以及模块的封装；
4. CPU线程调度的安全高效与透明简单；
5. CPU SIMD与GPU执行的高效实时性；
6. 离线仿真配置与在线运行配置的近似性与可替换性；
7. 彩超链路分析与输出的便捷接口；
8. 工程框架与matlab良好的联调机制；
其它更多 TBD...
因此，这会是一个满大的挑战，特别是对我自己一个人独立开发而言。自己最终在这段时间内能做什么程度，我自己也不知道。这样挑战的单人项目，已经处于我个人能力圈的边缘地带，能做成什么样，实践是检验能力的唯一标准。干，就得了，生死看淡，不服就干！
随着项目的推进，也许自身在系统上的短板或工程的短板就暴露出来了，补上了，自己能力圈也就扩大了。
2.开发进展记录
2.0 初步构思
（难以记时）
基本框架思路成型，然后又推倒几次，目前觉得基本可行。
2.1开发环境搭建 服务器搭建完成
（2023年12月15日）
工程代码，开发设计文档，系统仿真内容 SVN服务器搭建完成。
Q：为啥不用GIT ?
A：GIT用得不熟，SVN用得多。开发的辅助工具，不在这些无关紧要的东西上本末倒置。
开发环境选择为VS2022，纯C++不使用依赖任何基础框架。
其实QT提供了很多库，.NET也提供很多不错的框架。但我是做底层框架开发，纯C++的开发完成后，可以做到几乎零依赖零绑定，与几乎任何框架集成匹配，在几乎任何操作系统上运行。而VS在底层复杂问题上的调试工具比QT Creator丰富强大，QT更擅长于UI开发，包括QT对OpenGL的封装，对我来说也没有必要，原生底层调用才是我需要的。
系统仿真工具为Matlab2022,没啥说的，也没有备选工具。
仿真平台Field II, KWave, Focus与MUST。这几个仿真工具各有特点，看各个阶段的需求交替使用。
2.2 基础类的设计与多线程策略
（2023年12月25日）
基础类框架的设计开发第2次推倒重构，C++从ISO C++11改为C++20，以便使用C++最新特性设计。各模块空转情况下，多线程运行正常；
2.3 离线数据模块工作正常与多模块配置正常
（2023年12月30日）
通道数据仿真模块连线，注入数据正常，与其它各模块多线程配合未见异常。
扫查序列定义解析 正常，链路多模块配置与运行时自动搭建正常，XML解析正常；
2.4 Matlab仿真数据与工程匹配
（2024年01月09日）
仿真数据不能完美符合自己的需求，重新实验多种仿真工具field II, KWave, Focus,PField,MUST等。顺便还发现了某仿真平台里的又一个BUG，与作者联系（这是我发现他的第二个BUG了）。
更新开发设计文档。更新标准IQ波束合成模块，B模式模块。软件连线工作正常，图像结果异常，调试进行中...
2.5 数据解包模块重构与波束合成更新
（2024年01月15日）
解包模块重构，支持任意FPGA打包策略。matlab仿真找到折中方案，满足需求，更新离线数据。
标准IQ波束合成模块调试，解决若干BUG（调试脱了一层皮），更新MLA支持，更新变迹计算的更优策略。
标准IQ波束合成 工程输出 与 matlab输出 基本匹配，未见明显异常。节前 重要 阶段性节点！
2.6 B模式处理更新与RTB IQ波束合成模块
（2024年01月19日）
系统仿真导入数据更新，B模式链路更新基本处理，分离单独线程。
RTB IQ波束合成基础软件模块完成，程序调试跑通，目前结果未见异常。
但毕竟是仿真数据，我也不能完全确信是否正确，例如靶点太粗。如果有同仁手上有真实硬件通道数据方便分享，请后台留言，不胜感激。仿真的scatter太少，有些结果不能完全确认，
即使比较少的scatter产生一次通道数据都要跑10个小时，如果要达到我期望的精度，matlab仿一次通道数据，一周过去了。
正在重构基础类，内存管理思考中，目前内存爆表，各个子线程内部的子线程池策略思考重构中， 合成孔径开发进行中。
目前调试结果，均需要dump文件，甚是不便，后面我看能不能把OpenGL加进来，作个简单的显示和扫描转换，用作后面调试使用。哎，事情太多，都得自己搞，感觉忙不过来。
2.7 RTB 与 相位计算 问题BUG解决
（2024年01月21日）
波束合成继续Debug，发现并修正计算与量化重大问题，靶点大小终于正常了。
完成波束相位修正计算，加入软件链路中，结果未见异常。
根据自己的经验，目前已基本能确认计算正确，即使没有真实的通道数据，也能确信结果，置信程度颇高（即便达不到6西格玛也有4西格玛以上）。
提高了通道数据底噪，便于下一步与合成孔径后的软件链路结果对比；
下一步工作，计划先完成合成孔径，然后开始一次大的框架重构，软件重构的思路构思中。
2.8 合成孔径初始调试正确 与 其它
（2024年01月25日）
合成孔径调试通过（调试费了不少劲），连接其它软件模块后，目前工作正常，图像输出未见异常。与上次的输出进行对比，近/中/远场 信噪比 穿透 对比分辨率 提升，完全符合预期。
上面右图是在MLA为64，开启RTB回溯，搭配多次合成孔径，使用相同的MOCK通道数据输入，与上一次的图像相比提升明显。调试虽然辛苦，总算是调通了，内存暂时没有爆掉。
我之所以先做聚焦波，后面再加平面波的支持，不光是因为聚焦波的情况比平面波难做，包括是焦区处的处理与调试等，还因为就图像品质而言，由于Grating Lobe的干扰，聚焦波综合图像质量优于平面波。当然，平面波的大声场覆盖有利于HFPS，大孔径有利于更细的靶点。作为一名系统工程师的工程框架设计，不会是选择题，我需要全都支持，以便给IQ调图工程师更大的选择范围。
下一步，我计划加个模块作为显示（说了好久了没做，哎，没办法，一个人干活得一步一步来），因为现在每次检查结果都是Dump写到文件，很是麻烦。而且几何关系也不对，做凸阵和相控阵时肯定是不行的，我也计划顺带在GPU端把扫描转换做了。这些前期准备工作完成后，暂停一下，其间好好构思一下重构的事，春节后将会做一次比较大的软件重构。
2.9 显示模块添加 与 扫描转换
（2024年01月29日）
这次总算把显示模块加上了，以后检查结果，就不用dump到文件了。为了确保几何关系正确，在GPU端把扫描转换也做了。
常规的软件一般把显示放主线程，计算在子线程。但对我来说，EchoSight是核心C位，显示是次要的Debug工具，所以显示被我排挤到子线程里，中间导致各种奇葩工程问题若干。幸好我坚持没有妥协，这些工程问题我都搞定了，目前显示模块搭配工作正常，扫描转换GPU计算看上去几何关系也应该没问题。
下一步，我想把 线阵偏转的情况先做 还是 把相控阵探头先做。两者类似，但我都要mock up一下数据，满花时间的。另外，我有一种工程师直觉，预感我波束合成计算 的代码里 存在一个 不可接受的 量化误差。
I believe in Murphy's Law，需要想一想问题可能在哪里。
2.10 线阵的偏转
（2024年02月02日）
线阵探头的斜扫完成了，斜扫下的波束合成，以及相关处理。不出意外，又遇到一堆BUG，好消息是，都解决了。斜扫是常规操作，在空间复合，穿刺增强都要用，波束合成部分肯定要支持。处理结果没什么好说的，如下图
截屏视频做了个GIF动图，展示实际EchoSight软件框架运行时多角度扫查的运行状态
上次怀疑的波束合成问题，我已经找到并确认了，果然Murphy's Law从来没让工程师失望过。
那是一个非常重要，但往往被忽略的点，后期我想想怎么做。应该不能说是BUG，而是设计思路。每个厂家的系统工程师不同，系统方案也可能大相径庭，没有标准统一的做法，我就不多废话了。那个点在凸阵斜扫时，我预期会变得比较明显。后期，我比较期待，能看到相对明显一些的artifact，然后找到合适又便宜的工程方案处理它。
另外，我还有感觉目前的斜扫质量还是比预期的差一丢丢，我担心哪里还有问题。Murphy's Law still,我再思考思考。最近，春节前赶进度，开发得有点激进，先怼这个问题，还是继续往后做相控阵？待定吧。。。
To be continued ...