Inout就是参数实例的形参。它可以对外部的实参实例，进行引用和内外操作传递。通常是UDT或FB类型。

CodeSys中的FB，既有IN、OUT、InOut（简称参数），也有对象的Property（称为属性）。

三种接口参数是符合人们对函数的直觉认知的，使用比较简单。但它没有面向对象语言的底层特性支撑。

而Property属性，类似InOUT。但本质上它的get和set，是通过方法实现的。微软的.Net提供了面向对象特性的底层支撑。

如果是在CodeSys中建立FB，个人建议不要再使用三种参数了。全部走属性，这样就完全利用面向对象语言的特点，手法上也完整统一。

博图为什么没有采用面向对象特性，而是采用简单的三种参数形式？

抽象、封装、继承、多态，这些面向对象的形式特性，它们共同指向的本质就是：把共性与个性分开，以获得各自独立的纯度，和各自独立的变化灵活性。

但是在工控领域的实际各行业场景中，多态不一定能取得更为优越的效果。通过参数的数据变化，同样可以获得多态效果。

西门子应该是仔细权衡过现实场景的性价比，也参考过大量一线人员的意见。因为它毕竟是全球覆盖工控业务最广的公司，最了解实际细节。所以选择走了最直白的道路。很明显博图是以数据结构为核心设计出来的。

用数据变化来驱动，选择不同的逻辑路径。两者都是要经过场景的判定，殊途同归，只是形式不同。在OT业务的具体场景中，很难分高低优劣。

本质上，程序设计最关键的是看清长远稳定的可以精确落地的场景内蕴规则集合。数据结构设计和算法设计，都是因对此的认知不同导致的。

而这些规则元素，往往是表面不可见、潜藏的、甚至很多时候是长时间难以看清的。尤其是处在空间和时间复杂度的持续演变之中的，关于需求与解决的选择和边界的认定。

事情往往是随着收益越多，也越来越积重难返。

我没用过Codesys做实际业务。如果哪位有经验的 ，对于codesys中的采用继承多态实现的OT业务，在博图中无法用数据结构的设计来实现，欢迎分享指正。