有关FC/FB接口的描述及相关建议，西门子官方已经给出了一些具体且实用的“建议”和“规则”，详细描述参见以下官方文档：

1、ID81318674_Programming_guideline

2、ID109478084_Programming_styleguide

 ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

       关于块接口一些常用知识点有：

        1、接口参数的分类，包括Input/Output/InOut/Temp/Static(仅支持FB）/Constant；

        2、接口参数的传递，包括“传值”/“传址”，与之息息相关的还有块之间“块访问模式"的匹配与兼容问题，涉及到空间和时间两个维度的开销问题，有时还需要使用"Temp"和“InOut"来助其一臂之力；

        3、接口参数的性能优化措施，包括2提到的空间和时间上的开销，以及提高可读性方面的数据组织形式，而数据的重新组织又涉及到结合“PLC数据类型”的应用；

        4、关于性能方面的建议，在上文中的官方文档2-ID1094788084章节10有详细阐述，在此不赘述；

        ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

        上面所提及的内容，已经全部包含在官方手册和相关文档中，下面说一点儿日常工程实践中必须（或者偶尔）考虑的东西：    

        5、接口参数体量大小；

        6、接口参数组织形式；

        接口参数体量大小，笼统地说是由抽象结果决定的，说到抽象划分，功能在逻辑上是否相关联依赖，关联依赖度有多大？谍战片里的特工总是保持单线联系，上线只有一个，下线也只有一个。是否一些有关联的功能拼接成一个稍大的功能？抽象，是否真的抽出了必需的重点细节？是否又抽出了不必需的细节？抽象搞不好，它会抽风！接口要简洁，什么叫做“简洁”呢？个人理解就是能满足功能所必需的最小合集，加一分则太过，减一分则不足。

        参数是采用“一揽子”的形式，还是采用把鸡蛋分放在几个篮子里的形式？数据的组织形式才是编程的根本，这句话真的需要好好品味。如果可以，尽量采用“PLC数据类型”的InOut参数。         ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

        上面就是对理解和应用块接口的一点小理解，水平有限，有不足或者错误之处，还请方家指正指教。