我在前面文章仿真軟件的本質是提供服務一文中提到，目前仿真分析還屬于刀耕火種的階段，仿真效率低下，仿真門檻太高；其次是仿真軟件的的本質是提供服務，無論前處理、求解、后處理，均可以看做一種輸入輸出之間的服務本質關系。前者說明仿真分析的工作需要依賴數字化，提高仿真效率，降低仿真門檻，固化仿真經驗，后者說明仿真分析的工作實現數字化本身就是可行的。

1. 唯有數字化才能實現效率的本質改善

主機廠做過汽車仿真工作的小伙伴可能都知道，一款新車型的研發在數字階段主要分為3-4個階段，數據狀態將不斷迭代更新，仿真分析也需要依賴不同的數據狀態進行虛擬性能仿真評估，查找問題要因，提出改善仿真，驅動設計最終實現性能目標。但現實問題是這種虛擬的數字節點是人為規定的，實際上在整個開發過程中，各零部件子系統之間的設計是在不停的變更的，仿真團隊不會一有零件變更就去評估，而是選擇跟隨設計的幾個數字階段，分別評估這幾個設計節點時候汽車的性能狀態。那么，為什么不隨時隨地依據變更的規模，而建模仿真分析呢？我想主要的原因還是仿真效率更不上。當前完成一個數字階段的虛擬性能評估大概是4~6周，之后還要1、2個月的性能優化，如此長的時間開銷，還是在各種不同團隊配合、各種自動化半自動化工具使用之后的結果。但當再想提高整體的仿真效率，卻很難提高了，各種工具的非自動化是一些原因，但我想最主要的還是現在團隊的仿真工作模式問題，即仿真團隊之間工作配合、工作溝通的關系已經很難提高整體的工作效率了，一句話：仿真的工作關系之間影響了仿真的整體效率的提高，而數字化將改變原先的工作關系。

2. 仿真數字化發展的最后是低代碼化

這里提一個論斷，仿真分析的數字化發展的最后必將是一個低代碼化開發的結局。仿真數字化的發展過程中首先將細分仿真分析的流程步驟，并對不同流程步驟中實現的模擬工程師實現自動化、半自動化。前面我們講過，仿真軟件的本質是提供一種服務，而這種服務具體將表現在對各種仿真步驟完成的效果上。最開始的過程是基于過程的，這個時候基本上是一種基于過程的數字化過程，但這種開發應付簡單的仿真工作還能應付，但業務并不是一成不變的，更多的業務、更多的仿真流程的需求，原先的基于流程的數字化將讓開發工作越來越臃腫，越來越疲于應付。那么，基于對象的仿真服務就要開始考慮了，這是必然會到來的，一旦開始基于對象的仿真服務的開發，統一各流程接口就勢在必行。當一個又一個的仿真服務實現，應對復雜的業務場景，無非是不斷完善的鏈條上的各仿真服務，不斷優化代碼適應不同的業務場景。但呈現給仿真工作來講，不同的仿真服務的組合即可實現不同的業務需求，那個時候，服務模塊化、低代碼開發就已經來了。

3. 仿真數字化中切勿為了數字化而數字化

仿真數字化的本質是改變仿真工作團隊合作關系，最終的目標當然是實現仿真效率的提升。我們用一個模型來闡述這個問題。仿真工作在刀耕火種時候，人在完成仿真工作的時候，大部分是人和軟件的交互關系，達成事情，譬如這樣：

一旦引入數字化，必將依賴于系統，那整體的關系將變成如下：

人面的的將不再是仿真軟件，因為這個時候，仿真軟件已經不復存在，取而代之的將是系統，所有和仿真軟件相關的，都將變成人與系統之間的關系，但系統畢竟不是萬能的，或者說要實現人與系統之間的直接交流，必須滿足系統的一些條件，那么，額外的事情需要額外的人去做，而這一部分工作內容是原先的工作狀態中沒有的，屬于引入了數字化之后帶來的額外支出。所以，數字化大范圍上來講是好事，但仿真分析的工作內涵復雜，具體內容還是需要具體分析，不能為了數字化而數字化，表面上看效率是提升了，但這提升的背后反而帶來更多的人力開銷、帶來整個團隊的職責細化工作瑣碎，是不劃算的。

相關閱讀：

1.仿真軟件的本質是提供一種服務

2. CAE軟件二次開發的核心不在代碼

覺得不錯，請關注我，更多分享，盡在itincae