由于工业现场总线在工业控制、智能仪器仪表、数据采集等方面得到了广泛的应用，因此对于总线集成的需求也应运而生。不同种类的现场总线协议" title="总线协议">总线协议侧重于各自的应用领域，导致基于各种现场总线的产品由于协议的不同而无法相互通信。而一些传统的总线集成方法采用总线桥级连的方式来完成协议之间的通信，存在通信延时大、稳定性差、节点通信困难等缺点。针对以上问题，本文提出一套总线集成器的设计方案。该系统同时支持LonWorks、PPI、CANOpen和TCP/IP协议， C8051F120作为主控制芯片，采用模块化结构，提供实时监测数据功能，具有成本低、实时性高、可移植能力强等特点，有较高的组态性和灵活性^[1～2]。
1 系统总体设计与工作流程
1.1 系统的总体设计
　　系统结构框图如图1所示。C8051F120是整个系统的主控制芯片，负责对数据的处理和交换，包括通过RTL8019与以态网的通信，通过UART口与PPI总线通信，通过RS232口与LonWorks总线通信以及和CAN总线控制器SJA1000通信等。CAN模块和LON模块分别完成对CAN和LON数据的收发处理。一方面，系统分别作为LonWorks、PPI、CANOpen总线的一个节点，完成相应通信协议的通信及数据解析;另一方面，系统又要能够完成各总线之间的数据转发与共享。同时，为了支持远程监控能力,系统必须提供以太网接口以支持Internet功能。为了在现场提供监测环境，系统设计了人机界面^[3]。

1.2 各模块工作流程
　　主控制芯片C8051F120与RTL8019之间的接口是通过并行方式扩展的，为避免RTL8019A在C8051F120上的映射地址空间与 C8051F120内部的8KB RAM地址空间 (0X0000～0X3FFF)重迭，扩展的外部设备被放到最高端(0X8000～0XFFFF)，并采用非复用方式连接。模块中还包括RS232与RS485之间的转换。SN75LBC176是RS485差分总线收发器芯片。RS232数据由TX0通过光隔传送到SN75LBC176的发送端 ，同时驱动发送控制端，数据就由SN75LBC176发送到RS485总线。当SN75LBC176接收数据时，数据传送" title="数据传送">数据传送到RS232的RX0端。这样就完成RS485到RS232的转换。在系统中，为了提供人机交互的功能，设计了T6963C点阵式液晶图形显示控制器，在设计时，需要用一根地址线来实现液晶的数据通道和指令通道的区分。T6963C外接114×64的液晶显示屏，可以提供监测数据显示的实例。
　　CAN总线模块由SJA1000、82C250、6N137等芯片组成。SJA1000是并行接口的CAN控制器。82C250是CAN控制器接口芯片。当C8051F120要向某节点发送数据时，它向SJA1000的一些缓冲器写数据和命令。数据通过SJA1000处理后，合成CAN帧格式，通过6N137至82C250，由82C250的差分端CANH和CANL传送到物理总线。外部节点发送过来的数据通过82C250经光电隔离器6N137后被SJA1000接收，存放在SJA1000相应的寄存器中。C8051F120就可以读取这些CAN帧格式数据。
　　LON模块由MC143150、FTT-10A、MC145407以及外扩SRAM储存器IS61C256AH-15N和外扩Flash存储器AT29C512组成。MC143150是LonWorks控制芯片，含有Lontalk协议的固态软件，主要用于LonWorks数据的处理。FTT-10A 是LonWorks收发器，它是一种变压器耦合收发器，支持网络的自由拓扑结构，作为LON网的网络介质的接口。MC145407是电平转换芯片，负责MC143150与RS232之间的电平转换。当C8051F120要向MC143150发送数据时，C8051F120把数据发送到串口缓冲区，通过MC145407将I/O引脚输入的TTL 电平和输出的CMOS 电平转换为EIA232C电平。MC143150收到数据信息后，将数据读入储存于MC143150的缓冲区中，然后由MC143150 打包为LonWorks网络变量,通过不同节点、相同类型的网络变量的互联, 即可实现LON 节点之间的数据传送。另外，还外扩SRAM储存器IS61C256AH-15N和Flash存储器AT29C512，让用户能编制使用较大的程序。
2 软件设计
2.1 系统的分层结构
　　整个系统采用分层方式完成各协议间的通信。系统分为硬件驱动层、协议层及其应用层,如图2所示。

　　由于下层模块只向上层提供一个软件接口,屏蔽了下层的具体实现细节。上层软件只有通过该接口才能与下层软件发生联系,这样就保证了各层之间的独立性。系统根据硬件接口、总线协议的不同，分为三个大的分层功能模块，它们分别是LonWorks模块、PPI模块、 CANOPEN模块。这些模块又各自提供了硬件接收缓冲区、硬件发送缓冲区、协议接收缓冲区、协议发送缓冲区^[4～5]。
2.2 软件实现的框架
　　系统的软件分为系统初始化模块、系统配置模块、协议通信总调度模块、三个协议实现模块及硬件驱动模块" title="驱动模块">驱动模块。它们分别对应系统软件的不同分层。其中，系统配置模块、协议间通信总调度模块为应用层程序。协议实现模块（LonWorks协议模块、PPI协议模块、CANOpen协议模块）为协议层程序。硬件驱动模块为硬件驱动层程序。其流程图如图3所示。

　　系统配置模块主要完成系统的配置。它包括总线各端口是配置为主模式还是从模式、各通信协议的波特率等。系统可以通过两种方式配置：一种为硬件方式配置，另一种是通过互连网进行软件配置。协议间通信总调度模块主要是驱动不同协议之间进行相互通信。各总线协议的格式解析分别由相应的协议模块完成。硬件驱动模块主要完成把各硬件缓冲区中的数据发送到总线，同时把从总线接收来的数据存放到协议缓冲区中。
2.3 缓冲区结构
　　本系统的缓冲区采用改进的循环队列结构，采用了三个指针Bp.In、Bp.Out、Bp.Try。其中，Bp.In是队头指针。当队列接收一数据时,如果队列缓冲区尚有空间,则数据入队,同时Bp.In加1。Bp.Out是队尾指针。当数据要出队时, 如果队列缓冲区非空,则Bp.Out加1。队列缓冲区空或满的判定方法可以用下面的伪C语言描述:
　　if(Bp.In++== Bp.Out)
　　{队列缓冲区已满};//如队头加1等于队尾指针，则表示该队列已满
　　if(Bp.Out== Bp.In)
　　{队列缓冲区已空};//如果队尾指针赶上队头则表示该队列已空
　　Bp.Try是为通信时重发而准备的。当要发送数据时，Bp.Try向前移动(Bp.Try++)，但Bp.Out不动(数据不出队)。当Bp.Try=Bp.In时，表示队列缓冲区已没有数据要发送。如果要求数据重发，仅仅把Bp.Try重新指回Bp.Out(Bp.Try=Bp.Out)再次发送。只有当发送成功时，才允许数据出队(Bp.Out= Bp.Try)。由于一次发送数据的多少由Bp.Try决定(一次不一定把队列缓冲区数据都发送完)，这样给数据的发送提供了极大的方便。
2.4 硬件缓冲区
　　系统要发送数据时把发送协议缓冲区的数据拷贝到发送硬件缓冲区，并驱动一次发送后退出。硬件发送缓冲区中的数据是由发送中断自动完成的。硬件发送中断驱动完一次数据发送就退出。当硬件发送完数据后就会产生中断标志并重新进入中断，重复上面的过程直到数据发送完。同样，发送中断只负责发送完硬件发送缓冲区中的数据而不关心这些数据代表的意义。中断程序流程图如图4所示。

2.5 各总线协议间的通信方法
　　各总线协议间通信是采用周期轮询方式下的实地址共享。其基本思想就是系统定时地由配置为主模式的端口向其对应总线的每个从机发送请求读数命令包。从机接收到命令后就把它的数据传送给主机（总线集成器）。主机把接收到的数据存放在对应的协议地址中。当配置为从机的端口所对应的总线上的主机向总线集成器请求数据时，总线集成器只是简单地把前一个周期轮询的数据应答过去。由于轮询总线的周期比较短，因此应答的数据稍微滞后。但对总线采集的数据的真实性影响不大。

　　下面以图5中 CANOpen总线的节点B向LonWorks节点A请求数据为例来说明这种方式的通信过程。首先，系统周期性地改变从机号、通信命令、通信状态，向LonWorks所有的从机请求数据，从机应答的数据存放在其协议地址中。然后CANOpen主节点B向总线集成器请求LonWorks总线A节点中的数据。最后，总线集成器收到该命令，把刚采集到的协议地址上的值传送给节点B。这一次通信至此结束。
　　该多协议总线集成器目前提供了对LonWorks、PPI、CANOpen的支持，并且还对上面三种协议提供了利用TCP/IP远程监控和配置的接口，人机界面使系统有较好的监测能力。由于该集成器采用了较高性能的处理器，使各个协议之间通讯实时性得到保证。为了有利于系统以后的扩展，整个总线集成器系统严格按照模块化来进行硬件设计和软件编程，使系统软件的移植性大大提高。
参考文献
1 孙 荣, 徐江华, 邵惠鹤.基于嵌入式模块工业以太网的实现[M].计算机工程,2003；(2)
2苑明哲,柳长春,周 悦等.多总线集成方法研究[M].工业仪表与自动化装置,2002；(1)
3邹益仁，马增良，蒲 维.现场总线控制系统的设计和开发[M].北京：国防工业出版社，2003
4 顾洪军. 工业企业网与现场总线技术及应用[M]. 北京：人民邮电出版社，2002
5 Richard P.,Ken Y.,Richard M. The current fieldbus standards situation-a European view[J].Assembly Automation,1999;19(4)