CommonAPI-SomeIP 使用

想了解SOME/IP协议，可以移步：SOME/IP 协议介绍SOME/IP-SD 深入浅出上一篇，我们已经可以基于vsomeip实现SOME/IP应用，并且服务端和客户端之间进行消息的通信，消息的内容称为Payload。但是设想一下，如果当我们需要传递的消息内容是一个比较复杂的数据结构，比如一个结构体，一两个倒也没事，多了以后，Payload的打包、解析和联调都会是件麻烦的事。这时，我们会想到序列

熊猫眼老阿姨

11838人浏览 · 2021-01-19 08:39:12

熊猫眼老阿姨 · 2021-01-19 08:39:12 发布

想了解SOME/IP协议，可以移步：

SOME/IP 协议介绍

SOME/IP-SD 深入浅出

上一篇，我们已经可以基于vsomeip实现SOME/IP应用，并且服务端和客户端之间进行消息的通信，消息的内容称为Payload。但是设想一下，如果当我们需要传递的消息内容是一个比较复杂的数据结构，比如一个结构体，一两个倒也没事，多了以后，Payload的打包、解析和联调都会是件麻烦的事。

这时，我们会想到序列化，比如用Google Protocol Buffer之类的，是不是可以解决问题呢？对于非AUTOSAR设备之间的通信，是可以解决的，但对于与AUTOSAR设备之间的通信，恐怕就行不通了，因为Payload是需要遵循AUTOSAR规范的，如图：

于是，我们又会想到，如果有人能把符合AUTOSA规范的序列化这一步也帮我们做好那就更好了，这就是RPC(Remote Procedure Call，远程过程调用)可以做到的事了。GENIVI的CommonAPI C++是基于vsomeip实现的RPC框架，今天就让我们一起看一下它是怎么用的吧～

搭建CommonAPI的开发环境，有点费劲的，除了依赖于boost和vsomeip，还有CommonAPI和CommonAPI-SomeIP，以及C++代码生成工具，这里就不一一说明了，我已经整理好，放在Github上，关注公众号，回复“演示代码”，可以获得项目链接。

环境OK了以后，我们可以就创建第一个HelloWorld工程了，按照如图所示CommonAPI的工作流程：

其中，FrancaIDL是一种接口描述语言，和编程语言无关。fidl文件是用IDL写的，它描述了服务提供的接口信息，包括类型(比如method、broadcast、attribute等)、参数、返回值。

创建HelloWorld.fidl文件：

package commonapi

interface HelloWorld {
  version {major 1 minor 0}
  method sayHello {
    in {
      String name
    }
    out {
      String message
    }
  }
}

fdepl文件描述了服务的部署信息，包括Service ID、Instance ID、Method ID、Event ID等。

创建HelloWorld.fdepl文件：

import "platform:/plugin/org.genivi.commonapi.someip/deployment/CommonAPI-SOMEIP_deployment_spec.fdepl"
import "HelloWorld.fidl"

define org.genivi.commonapi.someip.deployment for interface commonapi.HelloWorld {
  SomeIpServiceID = 4660

  method sayHello {
    SomeIpMethodID = 123
  }
}

define org.genivi.commonapi.someip.deployment for provider as MyService {
  instance commonapi.HelloWorld {
    InstanceId = "test"
    SomeIpInstanceID = 22136
  }
}

CommonAPI代码生成工具几乎支持Franca的全部功能。

用准备好的工具生成代码：

commonapi-core-generator-linux-x86_64 -sk ./fidl/HelloWorld.fidl
commonapi-someip-generator-linux-x86_64 ./fidl/HelloWorld.fdepl

在src-gen/v1/commonapi目录里，可以看到如下这些生成的代码文件：

万事俱备，可以开发应用程序咯～

对于服务端，主程序代码如下：

std::shared_ptr<CommonAPI::Runtime> runtime = CommonAPI::Runtime::get();
std::shared_ptr<HelloWorldStubImpl> myService = std::make_shared<HelloWorldStubImpl>();
// 注册服务
runtime->registerService("local", "test", myService);
std::cout << "Successfully Registered Service!" << std::endl;
while (true)
{
  std::cout << "Waiting for calls... (Abort with CTRL+C)" << std::endl;
  std::this_thread::sleep_for(std::chrono::seconds(30));
}
return 0;

其中，HelloWorldStubImpl是继承于工具生成的HelloWorldStubDefault：

class HelloWorldStubImpl: public v1_0::commonapi::HelloWorldStubDefault {
public:
    HelloWorldStubImpl();
    virtual ~HelloWorldStubImpl();
    virtual void sayHello(const std::shared_ptr<CommonAPI::ClientId> _client,
        std::string _name, sayHelloReply_t _return);
};

HelloWorldStubImpl实现了sayHello接口，正如fidl定义的，当客户端发送name，回复“Hello name !”：

void HelloWorldStubImpl::sayHello(const std::shared_ptr<CommonAPI::ClientId> _client,std::string _name, sayHelloReply_t _reply)
{
    std::stringstream messageStream;
    messageStream << "Hello " << _name << "!";
    std::cout << "sayHello('" << _name << "'): '" << messageStream.str() << "'\n";
    _reply(messageStream.str());
};

对于客户端，主程序如下：

std::shared_ptr < CommonAPI::Runtime > runtime = CommonAPI::Runtime::get();
std::shared_ptr<HelloWorldProxy<>> myProxy = runtime->buildProxy<HelloWorldProxy>("local", "test");
std::cout << "Checking availability!" << std::endl;
while (!myProxy->isAvailable()) usleep(10);
std::cout << "Available..." << std::endl;
CommonAPI::CallStatus callStatus;
std::string returnMessage;
// 调用sayHello服务接口
myProxy->sayHello("Bob", callStatus, returnMessage);
std::cout << "Got message: '" << returnMessage << "'\n";
return 0;

客户端不需要实现接口，直接使用工具生成的HelloWorldProxy就可以了。

编译运行的结果如下：

现在再看一下应该选择CommonAPI还是vsomeip呢？用vsomeip的话，依赖的东西少，Payload的打包和解析要自己写，工作量大，自由发挥的空间也大，用CommonAPI的话，依赖的东西多，环境搭建相对复杂，接口可以用IDL描述，这在SOA中非常有用，很多代码由工具生成，基本通信几乎不需要联调，主要的开发工作是实现服务的接口，相当于填充业务逻辑，工作量少，同时可以发挥的空间也小。很多事都是这样吧，获得便利的同时也会损失一些自由，如何选择还是要具体分析。

通过这个示例，我们看到使用RPC通信和上一篇中基于消息的通信是截然不同的编程体验，RPC让客户端可以像调用本地函数一样调用服务端的函数，很显然它们并不在同一个进程中，这是如何做到的呢？下面，我们结合一张经典的RPC原理框图(图片来源：https://www.cs.rutgers.edu/~pxk/417/notes/03-rpc.html)来看一下客户端的sayHello到底是怎么调到服务端的sayHello的：