基于CAN总线的嵌入式RPC机制的设计与实现

何用辉

(福建信息职业技术学院机电工程系，福建福州350003)

许多嵌入式环境下的分布式系统是基于进程间的显式消息进行信息交换的，其发送和接收过程无法隐藏通信过程.这种方式的缺点是开发者需要了解网络接口及使用方式，通信过程对开发者来说不透明，必须亲自关心数据的发送和接收，极大影响了程序的开发效率.鉴于CAN总线在嵌入式系统中的广泛应用，设计并实现了一种可运行于嵌入式CAN网络的RPC协议及其实现方法，通过使用一致的协议和提供基础性的底层服务，使得开发人员不必为如何实现通信而烦恼，从而可以把注意力集中到如何解决问题上，有效地改进现有工业控制系统的开发效率.

1 RPC原理及其在CAN总线上的实现

1.1 RPC实现原理

RPC可分为异步RPC和同步RPC，在调用方发出RPC请求后，调用进程会被挂起的为同步RPC，反之为异步RPC，这里所描述的RPC为同步RPC.RPC通过如下基本过程实现对开发者隐藏通信细节的目的.节点A调用节点B上的进程时，节点A上的调用进程将被挂起，而B上被调用的进程开始执行.调用方使用参数将信息提供给被调用方，然后被调用方用返回值的形式将结果传回调用方.

在这种方式下，客户端的开发者可以以正常的方式调用某个函数.当这个函数的实现被放在远程服务器时，在本机的函数体中放入RPC调用的实现版本，称之为客户存根(client).这个客户存根首先阻塞源程序，同时对接口函数的参数类型和字节数进行统一封装，调用网络接口函数，发送RPC请求包到远程服务器.远程服务器接收到这个数据包后，将它传递给一个称作服务器存根(server stub)的进程.服务器存根对这个包进行解析并提取需要的参数，同时调用相应的函数实体，并返回相应的执行结果.然后，服务器存根返回这个结果给客户端，客户端重新唤醒相应的进程，使原程序继续运行.这样，对开发者来讲，整个过程就好像是本地调用一样.

RPC的另一个关键是设计一个通信绑定过程.图1所示为基于TCP/IP协议栈的RPC协议所采用的方法示意图.首先，服务进程向本机守护程序注册一个端口号，然后服务进程向目录机器的目录服务进程注册一个服务名称.之后，客户进程就可以调用服务进程了.客户端首先把需要的服务名称传给目录服务器，目录服务器返回具有此服务的服务器网络地址，客户进程随后向该机器的守护进程(它具有公开的端口号)发出请求，目标服务器守护进程查询端口表并返回相应服务的端口号，客户进程最后通过获得的网络地址和服务端口号进行RPC连接.

图1 RPC服务绑定过程

1.2 嵌入式环境下的分层RPC模型

通过上面分析可知，在嵌入式环境下(特别是在非以太网的网络环境下)，由于系统对资源有着严格的限制，用上述一般方法实现RPC是很困难的，甚至无法实现.因此，设计了一个适用于嵌入式环境下的简单、分层RPC协议，根据RPC协议原理，将RPC协议的嵌入式实现分成了如下3个部分:客户存根处理模块、服务器存根处理模块和协议数据格式.

1)客户存根处理模块.模块处理过程如图2所示.

图2 RPC客户存根处理模块

这个模块实现了客户端的RPC处理过程.在每个RPC客户机器上实现一个客户存根处理进程，这个进程负责处理本机的各个RPC调用，维护一个全局的消息队列.当用户进程调用一个RPC函数时，本地函数的实现部分会打包相关消息(这个消息包含有RPC调用号、创建的接收邮箱地址、参数组编等信息)，然后发送到这个消息队列中.客户存根处理进程将提取、解析这些消息包，然后通过网络发送询问帧以查找具有相应服务的主机.找到后再将这个消息包打包发送到对应主机，并接收主机的返回结果.最后将结果发送到用户进程的邮箱中，从而唤醒用户进程.同时，客户存根处理进程还维护一个RPC处理状态表，以方便客户处理这些消息包.这个状态表保存有RPC调用处理过程的一些状态信息(比如状态表保存了RPC调用的开始状态、调用主机查询状态、消息返回、处理成功、超时时间等状态).

2)服务器存根处理模块.模块处理过程如图3所示.

图3 服务存根处理模块

这个模块实现了服务器端的RPC处理过程，本机的RPC服务均在这个模块中实现.首先，客户机器的一个RPC调用将会触发服务器的RPC中断，RPC中断处理函数将网络消息放到服务器存根的全局消息队列中.服务器存根处理进程进行消息提取、消息解析、调用服务函数表中的相应服务函数、发送RPC结果等操作.同时，类似于客户端处理进程，服务器存根处理进程也维护一个RPC处理状态表，用以标志处理过程的相应状态.

3)协议数据格式模块.这个模块分2个部分，一部分是用户进程向客户端处理进程发送的处理消息格式，另一部分是网络传输的数据格式.

1.3 CAN总线链路层协议

CAN总线是一种有效支持分布式控制或实时控制的串行通讯网络，其总线规范已被ISO国际标准化组织制定为国际标准.根据国际CAN 2.0B的技术规范，CAN2.0B含有标准数据帧和扩展数据帧，两者区别是帧的仲裁长度不一样，其格式如图4所示.此设计采用标准数据帧格式，以减少网络传输量.

图4 CAN链路层协议格式

CAN总线的应用范围遍及高速网络到低成本的多线路网络，并广泛应用于车载系统、控制系统等领域，在工业控制领域占据着主导地位.此处只介绍与本设计密切相关的仲裁字段、控制字段和数据字段的格式.仲裁字段包含一个数据帧的帧ID，和以太网不同，CAN总线的数据包是面向帧消息的，而以太网是面向节点的.因此，CAN数据包只包含一个帧ID，而不包含目的地址和源地址信息，控制字段包含由数据字段的长度信息(数据字段长度只能为0－8B)，数据字段则包含相应要传输的数据.

1.4 基于CAN的RPC机制的协议模块

如上所述，RPC数据协议模块包含2个部分.一部分是用户进程向客户存根处理进程发送的处理消息格式;另一部分是网络传输的数据格式.基于CAN总线的RPC协议格式如图5所示.

图5 RPC数据格式

数据帧的几点说明:

1)邮箱地址.RPC客户存根处理进程收到远程服务器的返回结果后，将获得的数据放入这个邮箱地址，以便唤醒相应用户进程.

2)唯一调用号.这是一个全局唯一的调用号，占据1个字节.系统必须保证所有的服务在全局仅有唯一的一个调用号码.

3)参数组编.设计中对参数和返回值有如下规定.

①假设在函数参数列表中的参数从左到右分别是param l，param2，…，paramN，它们对应地放在调用数据包的“参1…参数N”，那么，参数组编格式为“参数数目+参数1组编+参数2组编+…参数N组编”.参数的组编则有2种形式:非指针型和指针型.非指针型参数的组编方法为“类型编号(4 bit)+实参数据”;指针型参数的组编方法为“类型编号(4 bit)+长度(12 bit)+实参数据”.本设计参数组编方法详见表1和表2所示.

②函数的返回值组编方法和参数组编方法一样，只不过它是保存在服务器传给客户机的数据包中.

③简单RPC只接收C语言的简单数据类型(不包含浮点数据类型)，支持1维指针，不支持2维以上的指针，也不支持struct类型.

④数据的存放表示一律使用little endian.

⑤传递指针时，需要把指针指向的数据放入报文中.

4)帧类型.占2个位(2 bit)，其中“00”表示RPC结果返回帧，帧携带RPC的调用结果数据;“01”表示调用查询帧，帧携带调用请求数据.客户端用这种帧查询哪台服务器拥有相关调用号的服务;“02”传输出错报文帧，用于服务器和客户端的传输信息协调.这个字段和上面提到的“唯一调用号”字段组成了仲裁字段的ID字段(11 bit).

表1 非指针型组编编码

表2 指针型组编编码

5)剩余字节数(占用1B).如果一个帧无法传输完整的数据，那么需要将要传输的数据分成多个数据帧来传输.这个字段保存剩余需要传输的数据字节数目，用以完成整个数据包的完整传输.

6)识别号(占用1B).这个号的作用是区分不同进程对同一个服务的调用，并标志调用进程.

1.5 重要函数

2 RPC测试与分析

采用ARM 7－Lpc2290处理器(本身带有CAN接口)，μC/OS－II为底层操作系统，CAN总线网络为网络环境.设定系统所使用的总线速率为125 kbps.一般来说，同步RPC设计目标主要有2个:高吞吐量和低延时，但二者不可兼得.由于在嵌入式环境下，特别是控制环境下，节点间通信的数据量比较小，对实时性有一定的要求，因此在所述的设计中以低延时作为主要目标.

测试主要考察在RPC调用过程中，RPC相关操作对调用时间的影响.测试所使用的过程接口为unsigned char W ritedata1(u8 data，u8 len).该过程中将首地址为data，长度为len的数据从客户端发送到服务器端.如果调用成功，服务器返回接收到的数据长度，否则返回0.作为对比，本测试使用了不同大小的数据，并得到所使用的时间.由于嵌入式环境下数据量比较小，因此规定最大数据长度为256B，这个长度可以满足大多数进程通信的要求，具体测试结果见表3.

从测试结果可以看出，RPC相关操作对调用时间的影响较低，基本实现了低延时的设计目标.RPC方式与直接使用消息的传递方式在时间消耗方面相差不大.

表3 RPC时间测试ms

3 结语

分层RPC协议可以在多个嵌入式系统之间顺利地完成函数调用，从而提供了一定的互操作性.分层的RPC协议把进程间调用和网络连接调用分开，方便了不同系统、不同网络的编程.简单的说，这个分层协议为客户端和服务器之间建立统一的底层通信机制，使得系统开发者可以把精力集中到如何实现功能以及解决实际问题上来.

［1］ 袁菲，陆洋，海深.嵌入式环境下RPC的设计与实现［J］.计算机工程，2007(9):266－268.

［2］ Vinoski S.RPC Under Fire［J］.IEEE Internet Computing，2005，9(5):93－95.

［3］ Dissanaike S，W ijkman P，W ijkman M.Utilizing XMLRPC or SOAP on an Embedded System［C］//Proc.of Distributed Computing SystemsWorkshops.2004:438－440.

［4］ 郑丽英，李全兵.一种新的基于RPC的分布式开发模型［J］.兰州交通大学学报:自然科学版，2004(1):83－86.

［5］ 肖政东.基于CAN总线的RPC远程监控系统的研究与实现［D］.南京:南京航空航天大学，2009.

［6］ 何用辉.基于CAN总线的啤酒发酵监控系统研究与设计［D］.福州:福州大学，2006.