仿真分析在数字化的浪潮中的几点思考

我在前面文章仿真软件的本质是提供服务一文中提到,目前仿真分析还属于刀耕火种的阶段,仿真效率低下,仿真门槛太高;其次是仿真软件的的本质是提供服务,无论前处理、求解、后处理,均可以看做一种输入输出之间的服务本质关系。前者说明仿真分析的工作需要依赖数字化,提高仿真效率,降低仿真门槛,固化仿真经验,后者说明仿真分析的工作实现数字化本身就是可行的。

仿真分析在数字化的浪潮中的几点思考的图1

1. 唯有数字化才能实现效率的本质改善

主机厂做过汽车仿真工作的小伙伴可能都知道,一款新车型的研发在数字阶段主要分为3-4个阶段,数据状态将不断迭代更新,仿真分析也需要依赖不同的数据状态进行虚拟性能仿真评估,查找问题要因,提出改善仿真,驱动设计最终实现性能目标。但现实问题是这种虚拟的数字节点是人为规定的,实际上在整个开发过程中,各零部件子系统之间的设计是在不停的变更的,仿真团队不会一有零件变更就去评估,而是选择跟随设计的几个数字阶段,分别评估这几个设计节点时候汽车的性能状态。那么,为什么不随时随地依据变更的规模,而建模仿真分析呢?我想主要的原因还是仿真效率更不上。当前完成一个数字阶段的虚拟性能评估大概是4~6周,之后还要1、2个月的性能优化,如此长的时间开销,还是在各种不同团队配合、各种自动化半自动化工具使用之后的结果。但当再想提高整体的仿真效率,却很难提高了,各种工具的非自动化是一些原因,但我想最主要的还是现在团队的仿真工作模式问题,即仿真团队之间工作配合、工作沟通的关系已经很难提高整体的工作效率了,一句话:仿真的工作关系之间影响了仿真的整体效率的提高,而数字化将改变原先的工作关系。

仿真分析在数字化的浪潮中的几点思考的图2

2. 仿真数字化发展的最后是低代码化

这里提一个论断,仿真分析的数字化发展的最后必将是一个低代码化开发的结局。仿真数字化的发展过程中首先将细分仿真分析的流程步骤,并对不同流程步骤中实现的模拟工程师实现自动化、半自动化。前面我们讲过,仿真软件的本质是提供一种服务,而这种服务具体将表现在对各种仿真步骤完成的效果上。最开始的过程是基于过程的,这个时候基本上是一种基于过程的数字化过程,但这种开发应付简单的仿真工作还能应付,但业务并不是一成不变的,更多的业务、更多的仿真流程的需求,原先的基于流程的数字化将让开发工作越来越臃肿,越来越疲于应付。那么,基于对象的仿真服务就要开始考虑了,这是必然会到来的,一旦开始基于对象的仿真服务的开发,统一各流程接口就势在必行。当一个又一个的仿真服务实现,应对复杂的业务场景,无非是不断完善的链条上的各仿真服务,不断优化代码适应不同的业务场景。但呈现给仿真工作来讲,不同的仿真服务的组合即可实现不同的业务需求,那个时候,服务模块化、低代码开发就已经来了。

仿真分析在数字化的浪潮中的几点思考的图3

3. 仿真数字化中切勿为了数字化而数字化

仿真数字化的本质是改变仿真工作团队合作关系,最终的目标当然是实现仿真效率的提升。我们用一个模型来阐述这个问题。仿真工作在刀耕火种时候,人在完成仿真工作的时候,大部分是人和软件的交互关系,达成事情,譬如这样:

仿真分析在数字化的浪潮中的几点思考的图4

一旦引入数字化,必将依赖于系统,那整体的关系将变成如下:

仿真分析在数字化的浪潮中的几点思考的图5

人面的的将不再是仿真软件,因为这个时候,仿真软件已经不复存在,取而代之的将是系统,所有和仿真软件相关的,都将变成人与系统之间的关系,但系统毕竟不是万能的,或者说要实现人与系统之间的直接交流,必须满足系统的一些条件,那么,额外的事情需要额外的人去做,而这一部分工作内容是原先的工作状态中没有的,属于引入了数字化之后带来的额外支出。所以,数字化大范围上来讲是好事,但仿真分析的工作内涵复杂,具体内容还是需要具体分析,不能为了数字化而数字化,表面上看效率是提升了,但这提升的背后反而带来更多的人力开销、带来整个团队的职责细化工作琐碎,是不划算的。


相关阅读:
1.仿真软件的本质是提供一种服务
2. CAE软件二次开发的核心不在代码


觉得不错,请关注我,更多分享,尽在itincae
仿真分析在数字化的浪潮中的几点思考的图6
(2条)
默认 最新
未来的趋势,任重而道远
评论 点赞
感谢分享
评论 点赞
点赞 3 评论 2 收藏 6
关注