Franca 随想

周更->双周更->月更->随意乱更来了。

前段时间，我研究了Franca及其周边。什么是“周边”，事物之间是普遍联系的，举个栗子，开始学习A，A基于B，那得先研究下B，B又涉及到C，C和D可能有着某种关联，把C和D了解一波，再回过来理解A，A->B->C->D->A，BCD我称之为A的周边，是不是很贴切呀。今天就来捋一捋Franca及其周边都有些什么吧~

在前面介绍CommonAPI时，简单提过Franca，彼时我以为只是CommonAPI里才用到Franca，就没怎么去看。直到前段时间，我寻思着开发一个IDL代码生成器，需要支持多种中间件通信协议和编程语言，是否可行，想到了CommonAPI的代码生成器或许能提供一些思路，于是去研究了一波生成器的源码，发现CommonAPI的代码生成器是基于Franca实现的。Franca是一个开源的框架，用于定义和转换接口，它的核心是Franca IDL( Interface Definition Language，接口定义语言 )，是一种用于规范接口描述的文本语言。

显然，IDL则是更宽泛的概念，如此也就理解了为什么前面介绍过的FastDDS里用的IDL和CommonAPI里的FIDL，相似却不同，一个是OMG的IDL，一个是Franca的IDL。每一种用于接口描述的语言都可以算作IDL，这样想来，Android的AIDL/HIDL，Protobuf的proto，AUTOSAR的ARXML，不都是一种IDL嘛，只是它们的架构/系统/范畴/规范不同。

那么，为什么要有IDL呢？记得以前我们是怎么做通信应用的吗，通常双方会维护一个协议文档，定义消息头和消息体，消息头中第一个字节是啥，第二个字节是啥，……，定义完了，要开始写代码了，接收一个Buffer，一个个字节，甚至一个个比特位，移动，取数据，塞到结构体里，……，写完了代码，要开始联调了，您这数据不对啊，两边一起查，一起核对，……，以后每次修改协议，都需要重复一遍上面的过程。知道我要说什么了吧，是的，IDL解决了繁琐的序列化问题，让今天的程序员不用再把时间花在检查笔误上了，再也不会出现多移了一个位，后面的数据全都不对的事情了。但仅此而已吗？我觉得不是，IDL除了序列化，更重要的价值在于它为团队实施敏捷开发，提供了基础设施，当我们通过IDL能够把模块之间的接口，甚至服务部署和系统模型，都用一种标准的规范描述了出来，我们是不是自然而然就可以做到文档先行，模块间松耦合，只要服务提供方发布了IDL，服务使用方就可以去开发了，开发完了，由于序列化和传输层是对上层屏蔽的，通信联调的时间甚至可以忽略不计，于是不管是服务提供方还是使用方，都能更专注在各自业务逻辑的实现上，通信就让框架去操心就好啦。但仅此而已吗？还真不是，IDL与编程语言无关，即使不是做开发的同事也能快速看个明白，比如FO、UI设计、PM、PO、架构等团队角色，他们都可以在自己的工作中利用这些IDL，获得到有用的参考信息(当然只是参考哈，开发确认的环节还是省不了滴~)，并且其版本往往要比其他文档要新得多，其他文档，开发要花费额外的时间去更新，而IDL是开发直接用来生成代码的，本身就是持续更新的。个人觉得，IDL可以在开发没(bu)时(xi)间(huan)写文档和团队需要文档之间，或多或少起到调和的作用。这是一次在某个会议上，偶然间看到PM娴熟地使用Notepad++查看IDL文件了解模块间接口信息，我悟到的。

Franca可以实现把不同种类的IDL转换为Franca IDL，这些转换的实现被封装在Franca Connector里，再通过Franca Generator，生成API代码/配置文件/API文档：

Franca transformation and generation framework

Franca IDL是语言中立的，也独立于具体的绑定，也就是说，Franca和CommonAPI，没有半毛钱关系，只不过CommonAPI的代码生成器是基于Franca开发的，同样道理，你也可以基于Franca开发你的代码生成器，通过定义FIDL文件也可以生成你通信框架的桩代码(桩，是RPC中的概念，这里先不展开啦~)。

举个简单的栗子，假设有个计算器的服务，只提供了一个加法的接口：

interface CalculatorAPI {
    method add {
      in {
            Float a
            Float b
      }
      out {
            Float sum
      }
    }
}

Franca IDL支持定义三种类型的接口方法：method，broadcast，attribute。在CommonAPI中，它们恰巧对应了SOME/IP中三种类型的消息：Method，Event，Field。Franca IDL支持基本数据类型(比如Int32，String，…)，也支持自定义的数据类型(比如数组，结构体，枚举，映射，…)，其中一些还支持嵌套。

Franca IDL还支持定义API的动态行为，通过指定一个contract来实现。contract基本会由一个PSM(Protocol State Machine)组成，PSM定义了接口的状态以及这些状态之间的转换，方法调用、广播或属性更改都可能触发转换。讲真，我也是刚知道有这么个东西，实际没有用过，不多作介绍了，感兴趣可以看看《Franca User Guide》，对Franca有非常全面详细的介绍，包括所有API的说明，相当于用户手册吧。

前面分别介绍了IDL和Franca IDL，还有一个我饶有兴趣的问题是Franca IDL和ARXML是怎么融合的？通过FIDL序列化的SOME/IP可以被AUTOSAR的SOME/IP反序列化吗？在AUTOSAR规范中说明了Payload的序列化规范，但仅是基本数据类型的序列化，而Payload本身是可变的，它可能是一个简单的基本数据类型，也可能是一个包含了多种数据类型的结构体，从目前的规范中，我们无法明确这个结构体会被怎么序列化？那凭什么确保可以兼容呢？我查找了很多的资料，希望能找到一些比较明确的论证以说服自己，即GENIVI能够兼容AUTOSAR。那么不管是Android，还是QNX或者Linux，只要能够集成GENIVI的CommonAPI，开发中间件，理论上就能和AUTOSAR系统进行SOME/IP通信。

在《AUTOSAR_TR_FrancaIntegration》中，详细说明了Franca IDL与ARXML是可以相互转化的。Franca提供了针对AUTOSAR的Connector和Generator。

Franca-to-AUTOSAR Translation

以上是CP，那么AP呢？ARXML肯定不一样了，在《AUTOSAR_EXP_ARAComAPI》中，提到了CommonAPI，都没有提到Franca，更没有提到兼容性。虽然ARA::COM和CommonAPI的架构几乎如出一辙，都是RPC模型，只不过ARA::COM的服务接口定义的格式是ARXML，CommonAPI是FIDL，即使如此，ARXML和FIDL兼容与否，还是要打个问号。我预感这应该不会是一件特别明确的事情~

Proxy Skeleton Pattern

在GENIVI官网，翻看了近年来一些资讯，其中2019年有一场讨论会的主题便是《FRANCA to Adaptive AUTOSAR》，从讨论会的PPT，还有一些其他收集的资料，综合来看，我觉得目前的Franca IDL并不能确定100%兼容AP的ARXML，CommonAPI也不能确定100%兼容AP的ARA::COM(我没有AP的环境，只能通过资料略知一二了，如果有说得不对的地方，欢迎随意怼~)。有个开源项目franca_ara_tools，应该是以此作为目标开发的，根据最新报告显示，已经做到了95%以上的兼容：

Mapping Franca/AUTOSAR

去Github看了franca_ara_tools，尽管这是个开源项目，但编译仍需要AUTOSAR会员，我没有，又一次玩不下去了。发现每次研究CP或者AP相关的东西，都会在某一步戛然而止。因为没有环境，没有亲眼看到，即使再多的资料表明可以，还是会觉得很悬乎，完全没有底气得出结论。既然没有结论，为什么又写了一堆分析呢？主要是过程中确实看了不少的资料，想说分享出来，万一以后有机会得以进一步研究下去，说不定这些还能派上用场呢~

Franca的应用，真不只有CommonAPI，最近发现，另一个开源项目BMW的Joynr也是用的它(Joynr的设计理念和架构，我都炒鸡喜欢，居然找不到一篇像样的介绍，有空一定要好好写一下它~)。所以啊，不知道的不代表就没有，不用的不代表就不好。

鉴于众所周知的原因，Franca的相关资料，其实不是很好找，我会把本篇文章里提到的一些资料，一起放到百度网盘分享出来，公众号回复“Franca资料”，可以得到链接。

最近因为个人工作上的变动，就有点忙，然后就好久没更新了，然后么，就有点掉粉。感谢火焰鸟同学给我提的patch，上一篇里porting的验证做得真是太不充分。但是也很吃惊啊，居然真的有人在用，哇，第一次切实感受到开源的意义，分享，让更多人看到，让更多人去用，让更多问题被暴露出来，然后，变得更好~