来源：踏雪当歌
与其他工业软件更大的不同是，仿真软件需要大量的工程化验证。写几万行代码，开发出第一套仿真软件其实并不难，难的是这套软件是不是经得住实际工程的考验。软件的评测，内行看门道，外行看热闹。外行喜欢看的往往是软件功能，内行则会钻到深处看性能，底层的算法和引擎决定了软件有多硬核，而它们则需要长时间大量的工程化验证方堪大用。
过去企业一般有两种方法进行工程化验证，一是试验方法，二是用户现场工程应用。不论哪种方法都需要投入大量时间和资金。现阶段，这两个途径在中国仿真软件公司都不具备可行性:
首先，国内仿真开发商没有充足的经费进行试验验证；
其次，即使资金花得起，时间也等不起，开发商现在没有时间等待用户的使用反馈；
第三，新软件用户基数小，反馈数量少，不足以支持工程化验证。
所以一家新创的仿真公司或新开发的仿真软件，在工程化验证方面往往都是大弱项。因此，只会等待试验验证和工程应用反馈的人，基本都冻毙于风雪，走到终点的可能性基本上为零。于是，我们提出了另外一套切实可行的国内的验证方法——用过去的案例验证今天的产品。
我们过去积累各个行业大量的工程案例，形成了拥有上万案例的工程案例库（图1）。案例库的数据经由国外软件应用实践而来，并通过用户试验及工程结果进行过验证，结果确认可靠。现在，每当开发出新的功能或模块，把过去的案例调出，相同的问题，用同样的模型，在新功能或新模块中重新计算一次。与案例库结果进行比对，结果偏差不大则认为新的功能或模块可行，结果偏差较大，则继续优化。利用这个案例库进行工程验证，节约了大量的时间和经费，相当于用过去的时间置换未来的时间，过去曾经投入资源和经费置换未来的资源投入和经费。
图1工程验证的基础：上万例的仿真实践案例
通常，离散的工业品或离散场景不足以验证仿真软件的完整功能。所以，工程化验证需要考虑场景覆盖性，通常需要用系列化的工业品及其子系统进行完整验证，称为系统性验证。我们的工程案例库中，除了案例数量多外，还依据这些案例整理了系列化工业品和子系统的仿真经验、标准和解决方案，总数达到上百个系列，可以解决验证场景的覆盖度问题。
当然，工程化验证并不能替代另外两项验证：解析解验证和标准工程（Benchmark）验证。
如果结构简单，简单杆、简单梁、平板、球壳、正四面体、六面体等，基础理论，譬如固体力学、流体力学、电磁学、化学等，可以在这些结构上直接获得理论解，这种解称为解析解。我们准备了包含大量解析解的案例库，对软件可以进行批量自动验证。
为了有效推动仿真软件在工程中获得标准化验证和对比，有一些非盈利机构（譬如NAFEMS: National Agency for Finite Element Methods and Standards）提供了标准验证案例库（Benchmark）,可以用来对仿真软件进行标准的工程化验证。
某些情况下，特别是政府或非盈利机构主导的项目中，往往需要对软件进行对比评价。一款仿真软件应该从哪些方面来评价，需要一套指标体系。为此，我们设计了如表1所示的评价指标，分享给产业界。通常来说，我们建议将目标市场的需求（刚需）作为对标对象，利用此指标体系与之进行对比来获得评价。但也可以用于在不同软件之间进行比较，其中一个软件作为对标软件，另一个或几个软件作为评测软件，以获得软件之间的比较分析。
表1 通用CAE软件评价指标
