编号：10-C-210328
【摘要：几年前曾就如何选择自主的系统仿真模型开发技术路线展开过一轮讨论，涉及建模方法、工具选型等内容，本期摘录部分交流内容来分享，仅供参考】
当前关键技术“自主可控”在各行各业刮起了一阵阵政策风。系统仿真技术/平台软件作为支撑信息化和工业化融合的内容之一，也早已纳入到相关课题的研究计划中，同时也在相关单位的信息化建设项目里占据了一席之地。此外，又恰逢“自主创新”的工业数字化转型，复杂产品研制的有效支撑范式——MBSE也需要系统仿真技术的支撑来实现性能指标的分析和验证。可以说，系统仿真技术这个点逐渐“火起来”了！
系统仿真技术相关的自主可控可以归纳为两大类：一类是围绕编译器和求解器的软件工具的自主可控；另一类是工程上直接使用的模型库的自主可控。两种类型的自主可控是有区别的，软件工具作为通用数学软件，需要比较深的数学和软件开发能力的支撑；模型库作为工业设计知识的载体，则需要除了数学建模能力之外的工业知识、经验和试验数据的支撑。有了好的软件工具，但是没有可信的模型库，在工程上应用起来也无法得心应手，甚至很可能在不同的软件工具上重复“造轮子”。
本篇收录的几个问题聚焦在模型库的自主可控开发方面。选择市面上最主流的“键合图建模原理和AMESet模型二次开发软件” 与 “Modelica面向对象的非因果建模原理和TypeDesigner模型二次开发软件” 展开对比介绍。具体如下：
1问题：面向过程、面向对象和实例化的探讨
小A：
Amesim目前模型二次开发还是过程式建模的思想，优点是，根据键合图理论和代码封装技术，从纯代码的建模进化到模块化拖拽建模。但这和面向对象的建模或者编程的标准定义是有比较大的区别的。面向对象的建模或编程的解释可以百度查到。其中还有一个关键词就是“实例化”，这是和面向对象技术相对应的一个“词”或技术，百度解释是：在面向对象的编程中，通常把用类创建对象的过程称为实例化。
类的一个优点是，所有基于类的实例化的建模便于重构模型。假如发现需要批量修改多个已建立模型中的某个元件，只需要修改一次对应的类定义，那么其它所有实例化此类的模型就会自动变更。这是面向对象技术的特点之一。
老W：
首先，AMESet用的是C或者Fortran语言编写进行模型二次开发，本身没有类的概念。Modelica开发肯定是要比过程式的语言要好，这个毫无疑问。而且，在处理一些数学运算操作（如矩阵、迭代等）和微分变量处理方面，Modelica要好很多。AMESet定义微分量是首先要定义x和x的导数，然后再赋值运算，而Modelica中直接der(x)即可。
另一方面，AMESet也并不是一无是处，结合多年的使用感觉，最有用的其实是软件里自带的一些库函数，它们可以直接被调用。比如，计算气动库（pneumatic）元件时，虽然它的商业库是封装的，但是通过库函数的调用还是能够享受到一些便利（感觉有点像走后门的感觉）。例如，可以直接调用某密度计算库函数rho_(*p,*temp)（可通过软件的帮助文档查阅到）。
最后，Modelica语言肯定比C语言更方便使用，但目前将Modelica（特指在TypeDesigner下）和C语言（特指在AMESet下）相比较没什么意义，毕竟AMESet（AMESim）发展好多年了，两个软件不在一个起点上，如果再过些年的话，也许Modelica可被免费使用的模型库丰富了，那么就有可能达到与AMESet一样好用的效果。
2问题：建模理论的探讨
两种建模理论对应到以下的表格也是有区别的，如下图：
图1功率键合图
图2 Modelica的广义基尔霍夫定律
老W：
目前我能发现的最重要区别：在键合图理论中，力（扭矩）是势，位移（转角）是流；而在Modelica规则下，力（扭矩）是流，位移（转角）是势。
从建模仿真角度来看，两种规则而已，弄明白就好，无所谓对错。
从真实物理原理来看，两者都有道理，但都是错误的，都没有真实反应物理现象。
牛顿第一定律——力是物体运动状态改变的原因。先有因（势），后有果（流）。Modelica规则的错误在于，颠倒因果，之所以会有位移必定是先有力。键合图理论的错误在于，因果的量没问题（力是势，位移是流），但是键合图理论存在两种因果关系——积分因果关系和微分因果关系，翻译过来讲就是既允许势变量作为边界条件，也允许流变量作为边界条件。事实上，自然界中的真实边界条件（因）都只可能是势变量，就像说存在电流必然是有电压驱动，存在加速度必然是有力在驱动一个道理。
最后，两种规则用作建模的话都无所谓，我们明白区别就好。
小A：
站在因果的角度，先有因（势），后有果（流）是没问题的。不妨换个思路，将势变量翻译成横跨变量，将流变量翻译成穿越变量。这时再去理解Modelica规则下的力（扭矩）是穿越变量就容易多了，因为它是可以“穿越”物理部件的一种存在。
3问题：根据原理图，是先有键合图还是先得到微分代数方程？
老W：
一般来说，是先画出键合图，再细化写方程。
可以想象一款软件，先按照仿真对象画出键合图，然后双击每一个键图元里面写方程、定义变量等等，最后点击求解进行计算。
以上步骤中，画出键合图之后，等于系统的状态方程der(X)=AX+Bf(t)中的A就完全确定了，详细填写每个键图元则是添加额外的细节信息，如：非线性、变系数、差值、外部调用等。
4问题：Modelica因果建模特性+键合图理论
小A：
使用Modelica的因果建模特性，并基于键合图理论建模，不知道操作是否方便，看国外论文，有挺多人使用“Modelica+键合图”这种应用组合开展建模与仿真应用。
老W：
是的。怎么应用都是看个人习惯，如果经验丰富的话，用任何工具或理论都方便。
关于建模，尤其是利用二次开发建模，首先应该厘清几个问题，即：建模思想、建模方法、建模语言及工具。
总的来讲，总结为以下几条：
一、建模思想、建模方法、建模语言及工具是不同层面上的东西，不在一个层面不能比较；
二、门派无好坏，功夫有深浅；
三、不能孤立的看某个工具、某个语言或者某个方法理论，应该放在系统仿真技术整个发展历程中去看其产生的原因和条件，用历史的眼光辨证去看。比如基于物理接口的多学科仿真一定是比信号流框图式建模好，但是在上世纪九十年代没有人会用C语言基于物理接口构建仿真模型库，因为工作量太大，得不偿失。同样，我们现在也不能架空历史去谈论信号流和多学科物理接口哪个好，例如有很多遗留的历史代码模型，经过长期的工程验证，可信度极高，是宝贵的知识财富。
小A：
是的，同一层级上才有可比性。对比项应该是：
而且两者不一定对立，如果能证明使用“Modelica+键合图理论建模”比“C语言+键合图理论建模”方便，那就说明Modelica建模技术理念与AMESim建模技术理念在基于键合图理论建模范畴内不是冲突的，也许是包容互补的关系。
5问题：模型库中模型的多与少探讨
小A：
举例来说，某C软件中有液压库，如果考虑热的影响，还有热液压库。而某M软件中只有一个液压库，直观上比较是少了一个模型库。但实际是，根据面向对象建模技术，一般会把同类元件的不同属性在一个元件中实现。所以，M软件中的液压元件，既是不考虑热的液压元件，也是考虑热的液压元件，区别就在建模的时候是否勾选“考虑热”的一个选项。
老W：
感觉把模型做多了便于多卖钱是真的！
6问题：商业库接口规则开放情况探讨
小A：
商业库如果不开放接口源代码和相关规则说明，那么在模型二次开发应用时就会是一个很大的缺点。当然，这可能是工具原厂商对商业库采取的商业策略（尽量买商业库搭建模型，不鼓励二次开发模型）。
当然，也有一些商业工具比较人性化，有限开放了商业库的模型接口。通过直接给出商业库的接口部分源码，便于用户在商业库的基础上进行一定的模型改造二次开发，也可实现用户完全二次开发的模型与商业库模型的接口匹配，进而实现混合应用。
老W：
衡量一款工具是否能较好地支持模型二次开发，主要看三点：
一、接口关系明晰、唯一、可操作。
二、所用到的商业库比较丰富且可用性较好。
三、软件开放，愿意为用户提供便利的二次开发功能。
综上，如果基于某接口规则的商业库都做不好，那么很有可能是商业库的接口规则设定不合理；即使开放了接口规则，也不太可能容易的实现自主模型二次开发，并与商业模型的混合使用。所以工具厂商（软件开发公司）需要树立友好和开放的心态，多开放接口源码，在保护IP的情况下，尽量给有模型二次开发能力的用户提供便利。毕竟工业用户根据自己的产品特点和数据开发并积累自主模型是刚需。商业库也不是万能的，更不能依仗工具对中国用户趾高气昂，当然，国内用户也不要崇洋媚外，要相信核心模型库是买不来的，靠人不如靠自己。
（补充：核心模型库就是工业设计知识的载体，没有人比产品设计工程师更懂自己设计的产品！）
【您的支持就是我分享知识的动力，欢迎点“赞”和“在看”】
