嵌入式系统的通信规约管理平台设计
扫描二维码
随时随地手机看文章
关键词:平台 规约说明书 CPCB 动态描述静态描述 逻辑描述
引言
众所周知,通信的双方必须遵守相同的协议,报文才能互相识别。目前,不同行业间的通信协议千差万别。为解决不同通信协议间的计算机系统通信问题,人们普遍采用的措施是一个具体规约对应一段程序。如果出现新规约,只能由通信双方共同配合,由一方按另一方的标准修改或增加通信规约来解决问题。这种解决措施使得通信系统的适应能力不强、可维护性差,难以兼容不同规约的设备。
笔者借鉴操作系统进程控制块PCB的思想,通过对各种通信规约的认真分析研究,提出了自己的通信规约管理平台的核心设计思想——用户填写指定格式的静态规约说明书。规约管理平台根据规约书生成通信规约控制块,由规约控制块统一控制、管理,并适应千差万别规约程序的运行。
该平台的设计使得系统能够适应千差万别的通信规约,不用修改程序就能够保证通信系统在线运行情况下,接入各种新设备,以不变的程序应对万变的规约,维护真正做到傻瓜化、智能化。
1 设计通信规约管理平台的可行性
1.1 统一的通信模型
任何两台计算机上的两个应用程序通信,都遵从如图1所示的通信模型。数据流动可以用收到发两个动作来描述。把提出数据请求服务的应用程序称为控制方向、即命令的下行;把提供数据服务的应用程序称为监测方向,即数据的上行。这样,一个完整的规约有控制方和监测方两个方面。控制方向下发送命令,并解析监测方发来的应答或主动上报的数据或状态指示报文;监测方解析命令,根据请求命令组织应答报文并上传。
1.2 通信规约的共性
任何通信规约都具有如下共同特征;帧结构的相似性、数据对象种类和报文长度的有限性、报文流的粒子性、逻辑过程的有穷性、传送原因的可分类性。
(1)帧结构的相似性
每帧报文都有图2所示的传输控制部分。
传输控制部分的目的之一是保证要传输的数据最终能够正确到达目的地。传输控制部分包括同步字对象、长度对象、传输方向对象、源地址对象、目的地址对象、帧号对象、功能符对象、结束符对象、其它对象及校验码十种对象构成。任何具体的规约都是上述对象的全部或基子集的一个具体排列。
数据部分就是用传输控制元素封装起来的传输数据。
(2)数据对象种类和报文长度的有限性
数据对象是通信规约真正要传输的对象。任何一个具体应用,要传输数据对象的种类是有限的,因而人们能够通过具体的通信规约将其进行描述。通信规允管理平台同样也能被描述出来。
任何规约一帧报文的最大长度都是有限的,这样不但可以遏制通信线路上长期被个别设备独占,也减少了错误传的次数与重传时间。一旦要传输的数据超过规定帧长,要分帧发送,接收方根据帧号来组装源数据。
(3)报文流的粒子性
更重要的是任何报文流的最小单位都是一个二进制位,相应报文的最小定义单元也是一个二进制位,这是所有通信规约的共性,不同的是各位间含义不同。任何规约的不同定义都在报文流有不同的确定位置(对位而言),数据发送是以字节为单位的。所以,引入顺序号的概念来描述并指示定义在不同报文中的起始位置(相对于合法报文的第一个同步字)和位数,顺序号属性就成了所有对象的共同属性。描述如下:
*字节序号——定义在一个以字节为单位,合法帧中数据成员占有的逻辑序号,第一个起始符为逻辑序号0(C、C++下标从0开始),根据在数据流中出现的先后顺序递增;
*字节内的起始位号——字节内的开始位号,取值范围0~7;
*位数——用几位表示。
struct CommSerial
{unsigned int SerialByte;
unsigned char ByteStartBit,ByteEndBit}my={2,0,8};
字节顺序号为2,字节内起始位号为0,位数为8,说明是帧中的第三个字节。如果规约用已有定义的字节的空位来定义,顺序号可以重复,但位号不能重复,用累加实现。
(4)逻辑规则的有穷性
逻辑规则包含以下四个方面。
①命令应答关系规则:包括通信双方中,控制方发送的命令和监测方的应答数据对应关系,以及监测方的状态指示和控制方的发送命令关系两个方面。这种对应关系是确定的、有限的和可描述的。
②双方数据发送的时间规则:控制方的自动轮询时间规则、监视方主动上报的时间规则及人工随机干预的控制命令,以上都是有限的与确定的。
③优先级规则:控制方同时出现多种要发送的命令,应按优先级规则进行传送。
④在帧结构的各控制元素一级封装下,数据对象本身又进行了二级封装。这种二级封可按一级封装的方式解决。
(5)传送原因的可分类性
控制方的传输原因有自动轮询、人工随机干预、监视方出现需优先处理的状态或指示;监视方向的传输原因有受召唤与主动上报两种。
综上所述,通信规约管理平台的设计是完全可行的。
图2 通信报文统一抽象格式
2 通信规约管理平台的基本组织方式
管理平台组织方式是将规约按照统一格式分解,以形成规约说明书或规约描述文件,将之放在外存,启动注册命令,管理平台将规约说明书进行系统注册,填入规约注册控制表。运行时,管理平台从规约注意表中提取指定的规约说明书,并找到一个空白规约控制块CPCB,根据规约说明文件填写CPCB,再由CPCB控制管理这个具体规约的运行。空白规约控制块的个数是有限的。一个进程按照CPCB的内容来运行,同时一个进程管理一个硬件通信端口资源,即通信端口的数量决定通信进程的数量。平台可根据运行各规约的实现性要求,来安排一个进程运行CPCB的数量。当然,一个进程依照一个CPCB运行是容易实现的。
2.1 规约说明书
规约说明书由基本情况表、静态描述表、动态描述表、逻辑规则表构成。静态描述表由控制元素对象中不随时间变化而变化的属性信息及其它信息组成;动态描述表用于描述随时间不断变化的控制元素和数据元素信息及其它信息;逻辑描述表由命令应答关系表、应答命令表、时间规则表、优先级规则表、筛选规则表和二级封装规则表组成。
(1)基本情况表
包括规约名称、最大帧长、数据对象个数、命令对象个数和状态指示对象个数,如图3(a)所示。
(2)静态描述
由同步字、传输方向、源地址、结束符及其它6种数据对象构成,如图3(b)所示。同步字标志一帧数据的开始;传输方向说明当前是工作在控制方向还是标志测方向;源地址说明报文的发送设备地址;结束符标志一帧报文的尾;其它对象指向所有不在上述静态描述之中的控制元素对象链的队首。静态描述中的每个控制元素对象都有本规约内全局统一的标识号(ID)。
(3)动态描述
用于描述随时间具体因素控制而不断变化的信息,它包括帧号对象、校验码对象、报文长度对象、数据对象、请求命令对象、应答命令对象、目的地址对象及其它对象,如图3(c)所示。帧号是完整报文的分帧传送,规约规定的报文帧的帧长是有限的;超限时分帧传送,发送方指明帧号,接受方按帧号重新组装。校验码对象用于传输差错控制,检验一帧报文的合法性。报文长度对象管理并指明有效数据的长度。数据对象按应答命令对象指明的类型组织该类数据。目的地址对于控制方向,指明服务的设备地址,它可能向多个设备轮流请求;对于监测方向,指明请求服务的设备地址。数据对象取决于具体规约的定义。应答命令对换快捷指明应答数据对象的类型。请求命令对象指明控制方向,向目的设备下发请求数据状态对象命令,并组织报文帧。应答命令对象和请求命令对象管理的措施与数据状态对象相同。当然,应答数据状态表和请求命令表是静态的,在此便于说明;而数据状态对象表是动态的。
动态描述中的控制元素对象和数据元素对象也都由本规约内全局统一的ID号来识别;ID号由ID注册管理程序生成,填写规约自己所赂的ID注册表。
(4)静态对象和动态对象公有的属性
①顺序号对象:如前所述,它指明某一元素对象在报文流中的起始位置和所占的连续二进制位数。
②ID号对象是全局统一的,它由六段依次连接而成,即一段、二段、三段、四段、五段、六段。根据ID可以识别提取不同的元素对象,它是各控制元素和数据元素的唯一标识。
一段是注册后的规约ID号,高段的位数由规约ID号位数决定。二段是区分上行与下行,用一位二进制位就可区分。三段用于说明具体的规约是否含有对应的元素对象,它说明的是有与无。四段用于区分源地址、目的地址、传输方向、同步字、其它静态对象、帧号、校验码、报文长度、请求命令符、应答命令符、其它动态对象和数据对象,共12种,用4位二进制位就可区分。五段用于说明四段之中的每一种是否具有原子性,比如同步字就具有原子性。当子种类多于一个同步字时,也相当于一个,要发就全发,不可分割;而请求命令符就不具有原子性,只能发出其子种类之中的一种。原子性是个布尔量,一位二进制就可描述。六段用于说明当上述12种之中任一种超过一个时,就可用第5段描述,比如同步字6个,就得用三位,选取上述12种之中子种类最多的一个和为第五段的位数。
③拷贝、赋值、被拷贝:在报文流中的其它类元素对象中,当出现与已有定义的控制元素对象表示值重复时,引进对象的拷贝与被拷贝属性。赋值属性说明该元素指的是已独立的定义值。相应的,引入拷贝与赋值操作。
(5)逻辑描述信息
逻辑描述信息由下列表构成:
①控制方发送的命令被监测方收到后,监测方予以应答的数据对象ID对应关系表;
②控制方收到监测方的状态指示后,控制方应响应的发送命令ID对应关系表;
③控制方发送轮询命令ID时间间隔表;
④控制方的人工干预控制命令ID表;
⑤监测方的主动上报数据表、状态ID表;
⑥控制方发送命令ID优先级的规则表;
⑦监测方应答数据与主动上报的ID优先级规则表;
⑧二级封装规则表。
2.2 规约控制埠CPCB
通信平台的某一通信进程在运行时,如未匹配通信规约,则运行空规约。如收到控制台发来的匹配命令,则从规约注册表中提取规约说明书,并从空白CPCB链表中摘下一个,将它链入运行CPCB链表,按照规约说明书的内容填写该CPCB,填写完毕即投入运行。这样,在逻辑规则的控制下,各静态对象和动态对象各司其职而又发送消息协同工作,整个平台就会有条不紊地动作。