工业软件研发为什么这么“难”
来源:多物理场仿真技术 | 作者:安亚信科技 | 发布时间: 2023-06-21 | 213 次浏览 | 分享到:

工业软件研发的“难”是共识,但是到底有多难,难在哪里,具体表现在什么地方,很少有讲清楚的。


另外关于工业软件“难”的描述,也对应之前关于“卡脖子”技术的定义:

  1. 技术门槛高,起步投入资金多;

  2. 研发耗时费力,需要长期积累,3年起步,成熟5-10年非常正常;

  3. 花钱买不到,买到只能用,无法转成自己的东西;

  4. 保密,专利核心技术点多。简单讲就是即使投入研发也不一定做的出来;

  5. 在行业内具有垄断性,无可替代


工业软件领域的很多技术都是比较透明公开的,只是深入研究打磨的时候很耗费成本,所以很多时候,我们看到讲工业软件的“难”,罗列一大堆知识,都只是主观上的臆测,真正做起来的时候,卡在技术面上的少,点上的多。


以下是之前从笔者研发经历中列举出的一些“难点”,并不只是单纯的技术问题,而是考虑了业务等非技术因素:


1. 如何定位仿真和试验之间的误差:这是个系统问题,一般而言,仿真结果很难和试验完全匹配,原因是多方面的,很多时候仿真也不是追求完全和试验精准匹配,而是得出符合规律的结论


2. 如何提升超大模型的性能:一直以来,超大模型处理是任何一款软件容易出现瓶颈的内容。


3. 软件架构设计:软件架构设计是软件产品的框架性内容,需要经验丰富的软件研发经验。


4. 网格自适应加密相关:自适应网格加密和几何,网格,求解器紧密相关,不同领域的自适应加密重点不尽相同,也是需要长期积累的技术项。


5. 高效生成六面体:目前为止,商业CFD软件可以全自动生成六面体网格,而结构分析中很难全自动生成高质量的六面体网格。


6. 大规模线性方程组求解效率和准确性:大规模线性方程组的高效稳定求解仍然是世界性难题。


7. 高性能计算,分布式/并行计算:这块涉及到各种工具和第三方库的使用,是需要长期试验积累的技术项。


8. 几何清理和修复:现在仍然没有一个工具能够完全高效,自动化进行几何清理和修复。未来也是可以借助AI的内容。


9. 根据业务网格全自动化生成:理想的网格是同时符合几何和物理场分布的网格,包括商业软件在内,一次性生成满足要求的网格目前仍然很难实现,依赖工程师经验。


10. NP问题求解:NP问题在很多优化设计领域仍然缺乏全局最优解


11. 优化算法实现和应用:优化算法的有效性严重依赖实际模型,缺乏统一通用的模板,同时也依赖工程师经验。


12. 理解偏微分方程的解析解和数值解:这个就是基本功,没什么好讲的


13. CFD里湍流模型理解和应用:湍流模型众多,实际项目中选择合适的湍流模型非常依赖经验;湍流模型参数众多,研发中也是需要调参积累经验的工作项。


14. EDA软件虽然小众,但是却是整个半导体行业的基础,而且覆盖面相当广,要有一个全流程的知识体系也需要长期积累。


15. 多物理场中的耦合计算:目前大部分耦合计算为弱耦合和单向耦合,强耦合难有工业应用,但实际上强耦合求解才更符合物理规律。


16. 回归测试功能:工业软件需要建立庞大的回归测试用例,每次新加功能和调整,需要保证所有回归测试正确。


17. FEM/FVM/FDTD/MOM/LBM无网格等数值方法的理解:数值方法的理解是求解器开发的基础,但是复杂的物理和数学提高了求解器开发门槛,这块需要长期的学习应用和经验积累,没有捷径。


18. 工程中的边界条件理解和应用:边界条件处理是偏微分方程中的重中之重,在实际工程应用中决定了仿真的准确性。


19. 各种求解线性方程组库的功能,性能测试:这个需要根据业务选择合适的库,作为基础性功能也是需要长期测试积累的内容。


20. 第三方几何文件交互:全球主流CAD软件有几十家,目前只能借助于第三方商业组件完成交互。


21. 软件架构中的数据结构设计。在工业设计仿真软件中,涉及到了业务模型,几何模型,渲染模型以及网格模型,如何设计好的数据结构将这些数据关联,并方便管理是所有软件架构之初就需要详细设计的

22. 程序中的undo/redo功能,翻遍资料,找不到一篇详细介绍工业设计仿真软件中undo/redo机制的文章。

23. 如何避免“s山”代码。

24. 驱动建模和参数建模技术。这个是三维几何CAD相关的功能

25. 使用迭代法求解线性方程组不收敛。这个在CFD计算时出现比较多,结构和电磁,热等其它多物理场比较少见。另外在一些特殊的结构,比如微观TCAD,TSV结构使用有限元方法也会出现

26. 数值精度问题。几何建模,网格生成以及求解器,需要高精度计算,数值扰动在算法中造成的问题很多,而且还很难调试

27. 自动化测试。前面讲过回归测试,其主要方法就是自动化测试。自动化测试的核心是利用脚本,所以需要开发脚本系统,好的脚本系统包含了GUI的自动化测试

28. H单元混合单元形函数。高阶单元中如果使用混合单元,进一步增加了刚度矩阵的生成难度

29. 调试大中规模模型。大中规模的模型一旦出错,调试是非常困难的,往往需要开发一些独立的功能强大的调试工具

30. 并行计算中的切分问题。这个在矩阵计算,模型分块中广泛存在。切分规模和策略,切分处几何,计算数据同步,决定并行的效率

31. 新技术的引入。新工具,新技术日新月异,如何保持技术敏感度,在项目开始前做一些前瞻性的预研和设计,对产品做一些战略规划也很重要

32. 如何在一个庞大的老工程上加新功能。不管是开源还是商业软件,都是一件非常棘手的工作。大部分成熟的工业设计仿真软件都可以认为是庞大的老工程

33. 对于基础组件,如何在第三方商业库和自研之间做选择和平衡,具体情况具体处理

34. 多平台支持。Linux平台版本比较多,基础库和显卡驱动都不太一样,很容易出问题,维护成本也比较高

35. 异构开发平台选择。现在异构平台开发工具很多,如果缺乏全面认识,在技术选型上很容易走弯路

36. 如何将优化算法应用到实际工程和项目。这个非常依赖工程经验,不是算法可以解决的问题

37. 经验丰富的研发人员匮乏。这是个老问题,也希望能从各个层面重视人才,关注人才,切实提高技术研发人员的待遇。


38. 算法研发和软件工程的矛盾。这个在求解器开发中最为明显,一般做算法的研发人员没有软件工程背景,反过来也一样。这就容易导致算法方面的内容工程化比较困难。这块除了积累经验提升研发水平,似乎也没什么好的办法 


39. 前沿技术和工程化的矛盾。每年都有新的技术出来,有些可能还是稍微有颠覆性的。如何将这些前沿技术低成本的融入软件中,也是比较棘手的问题


40. 不同产品线融合问题。这个通常出现在产品各方面都成熟后。比如做流体的和做结构的产品需要做成平台产品。各个产品如何交互,如何定义接口,这个涉及到软件和业务两方面的融合。


41. 如何确定通用模块和专业模块。以最简单的日志系统为例,一个软件,一套产品,或者产品线都希望能用一套日志系统,而事实上因为历史,开发人员水平等客观原因,这种基础模块在同一个产品都很难统一。看过一篇文章,一位大厂新人吐槽产品中有四套JSON解析代码,不统一,想要自己写一套新的,而后来实际情况也很打脸。简单的日志,JSON尚且如此,其它模块功能就更不用说了,非常依赖研发人员的经验


42. 如何调试用户案例。很多用户案例保密,不让带出。只能驻场开发调试,限制约束多,工作效率不高


43. 缺乏资深的应用工程师。工业软件最终需要应用在实际项目中,里面覆盖了大量的行业应用技术知识。软件研发中需要把这些应用技术知识考虑在内。缺乏资深应用工程师是工业软件研发一大硬伤


44. 客户端安装软件。和普通安装软件不同,有些工业软件安装流程不仅限制多,有些还依赖硬件系统。有些模块需要在硬件上编译后才能安装。看起来属于售后市场,实际也是研发的内容


45. 技术选型如何避免大炮打蚊子。之前有做研发公司咨询,研发中需要某个基础模块,因为缺乏资深研发人员,技术选型上不定,最开始打算用商用。如果购买商用,实际业务5%的功能都用不到


46. 几何修复清理。目前没有哪个工具能一键修复或者快速清理几何


47.模型参数系统。实际案例中,经常要确定几类核心参数,这些参数一方面依赖软件算法,也依赖实际试验


48.调整网格质量,密度和分布,建立网格参数和仿真结果之间的关联关系,这个一直以来比较依赖业务,不同物理场没有统一的规律和法则,只能靠实践积累


49.多种计算方法的混合使用,包括依赖网格数值计算方法,解析解,无网格法等,这个需要理解不同数值计算方法的特点,有较深的数值计算功底和业务经验


50.早期软件需求分析和确定,市场定位。这些直接决定了技术路线,技术选型,人员投入,研发流程等一系列内容。最常的比方就是盖楼,盖多高的楼就挖多深的地基,一旦地基确定,再改楼层需求就不太可能了。


需要说明的是,以上只是研发经历中一些点上的难点,有些比较深入具体,有些偏应用业务,正是这些点上的细节,积少成多,在广度和深度上,体现出工作量大,技术点多,系统工程复杂等特性,也是工业软件真正的难点所在。


来源:多物理场仿真技术(侵联删)