Stateflow

Stateflow（精选4篇）

Stateflow 篇1

排气阀控制单元简称VCU,它也是CYL-EU的执行器,首先WECS通过曲轴转角传感器送来的曲轴转角信号判断何时发出打开排气阀信号,VDM收到信号后便给共轨电磁阀的下端通电,阀芯在电磁力的作用向下移动,接通共轨电磁阀前等待的控制油,关闭回油通路,伺服油通过排气控制阀内部油路通道作用在VCU排气控制活塞的下部,推动活塞向上运动压缩来自主轴承的滑油,让增压的滑油作用于排气阀顶部,克服空气弹簧的作用力打开排气阀;当WECS发出关闭排气阀信号后,共轨电磁阀上端通电,阀芯在电磁力的作用下迅速关闭伺服油通路,并打开回油通路,双头活塞失去伺服油压立即回落,从而导致作用在排气阀上的滑油压力下降,排气阀在空气弹簧的作用下落座。排气控制阀与上面讲的喷射控制阀的功能类似,排气阀的动作情况由两个位置传感器测定。[1]

1 提取排气阀的运动过程方程

由于条件有限,不可能从柴油机整体地角度考虑排气阀的运动,完成对排气阀的精确控制,只选取排气阀的运动过程作为研究对象,排气阀的运动过程分为打开和关闭过程,打开过程中,伺服油通过共轨电磁阀流到活塞处,使活塞向上运动,使活塞上端产生很高的压力,活塞上端与排气阀上端联通,压力相等,促使排气阀克服空气弹簧阻力向下运动,使排气阀打开,关闭过程中,伺服油共轨压力减小,空气弹簧克服摩擦力与排气阀上端油压,上端油压使活塞向下运动,伺服油通过共轨电子阀流到油箱,排气阀的运动框图如下:

1.1 提取排气阀开启过程的方程

1) 控制活塞芯(piston)的运动方程:

P为共轨压力,Ap控制活塞芯的面积,Pm控制活塞芯上方的压力,mp控制活塞芯的质量,f为摩擦阻尼系数,xp为控制活塞芯的位移。

2) 排气阀芯的运动方程:

由于控制活塞芯上方与排气阀活塞芯是连通的,所以上方的压力也是Pm,Av是排气阀芯上方的面积,Pa是空气弹簧的压力,Aa是下方与空气弹簧接触的阀芯的面积,Xv是排气阀芯的位移,mv是排气阀芯的质量。

3) 由于控制活塞与排气活塞由根油管连接,两端根据连续性方程知:

由(1) 、(2) 、(3) 知

1.2 排气阀关闭过程:

控制活塞芯的运动方程:

排气阀芯的运动方程:

根据连续性状态方程有:代入上面两式得出排气阀的工作过程方程:

由于此时的Xv与开启过程的运动方程相反,而列该公式的时候设定方向与开启过程相反,现已排气阀开启过程方向为正,则上面的公式可变为:

上式即为排气阀的关闭的运动方程式,该排气阀的关闭的运动方程与开启运动方程形式一摸一样,唯一不同的就是轨压P变为了P’,设此时P’为零。

考虑空气弹簧里的空气不泄露,并且也不补充,温度保持不变,将气体看成理想气体,根据理想状态气体方程由:

上式为空气弹簧力的变化率。

2 运用matalb/simulink、stateflow进行数学建模

由于排气阀参数难找,下面的数值只是大致的估计值。模型中代表的参数符号与及各参数数值与上面的公式一一对应。

Stateflow是基于有限状态机上的建模,在matlab/simulink的基础之上通过状态流程和事件驱动对离散系统进行仿真。

2.1运用如上公式所建模型如下[2,3]

运行模型得曲线如下:

3 所建模型及图形曲线结论分析

所建模型将排气阀的开闭过程通关stateflow状态机分成开与关两个状态,打开过程是在140-210度,在打开过程中,触发If ac-tion subsystem动作,产生了排气阀打开曲线,当开到最大值时,排气阀开着一段时间,如图四平稳曲线,当曲轴转角大于210度时,发出信号使排气阀关闭,作用于If action subsystem1系统,产生排气阀关闭的曲线,如图二下降的部分。但其关闭的过程始终在360度之内,即如图始终在两秒内,图五满足条件。

Stateflow 篇2

列车通信网络(TCN, Train Communication Networks)是采用两层拓扑的体系结构,上层连接所有的车厢,称为绞线式列车总线(WTB ,Wire Train Bus),下层连接所有的单个车辆中的设备,称为多功能车辆总线(MVB, Multifunction Vehicle Bus),两者通过节点进行连接。列车总线和车辆总线是两个独立的通信子网,可采用不同的网络协议,通过一个列车总线节点(网关)互连。为了保证数据的快速传输,在列车通信网中采用了实时性协议。在绞线式列车总线上传输的数据格式不同于多功能车辆总线上传输的数据格式,节点对这两种数据格式进行转换。

1 TCN列车通信网络

列车通信网络[1,2]属于局域网,它采用两层的拓扑结构,上层为绞线式列车总线(WTB),下层为多功能车辆总线(MVB)。列车总线用于连接经常相互连挂和解挂的重联车辆,传输速率为1Mbps,传输介质为屏蔽双绞线。车辆总线用于连接各个车辆内的控制单元和设备,传输速率为1.5Mbps,传输介质分为电气短距离、电气中距离和光纤。一辆列车中只能有一条列车总线,但可以有多条车辆总线。列车总线和车辆总线通过节点来连接,一般每节车辆有一个节点。列车通信网的结构如图1所示。

绞线式列车总线(WTB),是一种串行数据通信总线,它是以列车运行控制计算机为核心,通过列车总线将各个车辆控制计算机节点连接起来,形成上层分布式网络。WTB主要设计用于经常相互连挂和解挂的重联车辆(经常相互连挂和解挂是国际UIC列车经常用到的一种情况)。

MVB[1,2]是专门为铁路车辆内部控制系统所设计的高可靠性实时现场总线。采用冗余的总线连接,采用曼彻斯特编码方式,提高了数据传输的确定性。MVB可使用三种不同的媒体,它们都可以在1.5Mbps速度下进行工作。MVB采用两种访问方式:周期性和偶发性的访问,提高总线的利用率。MVB可最大支持4095个设备。该总线主要用于有互操作性和互换性要求的互联设备之间的串行数据通信总线。

2 TCN列车总线通信仿真模型

运用有限状态机理论,在Matlab/Simulink软件Stateflow仿真环境中建立了TCN网络通信系统的仿真模型[3,4,5,6]。通过运行此仿真模型,求取了如网络传输数据和不同优先级信息平均传输时延等性能指标。最后,文中还研究了TCN网络系统中负载和传输速度对上述性能指标的影响,充分分析了TCN通信网络的高实时性。

按照TCN标准,列车通信网络分为两级,第一级为绞线式列车总线WTB,实现车辆间的数据通信;第二级为多功能车辆总线MVB,主要实现同一车辆内各个功能控制单元之间的数据通信。由于TCN网络系统的这种特殊结构,此次仿真采用模块化和分级建模方法建模。

在Simulink中的TCN通信网络模块,如图2所示。最顶层为WTB总线模块,主要采用MATLAB/Simulink中Stateflow工具箱[3,4,5]分析各个车厢节点的状态。第二层为MVB总线模块,主要设计了报文传输的时延。第三层为设备级,主要调用Simulink中的随机信号来模拟过程数据、消息数据和管理数据。MVB和WTB总线通过总线管理器BA(Bus Administrator)连接。

其中TCN网络模块主要用来确定时间基准和输入输出变量,包括WTB总线模块、MVB总线模块和8个车厢内的设备级。假设有8个车厢,其中2,3,6,7号车厢为动车组,7号车厢为乘务员室,1,4,5,8号车厢为拖车。

根据列车的动车组配置,依次设计各车厢内的MVB总线模块和设备级。其中1,8号车厢为司机室,假设传输信号装置相同。2,3,6,7号车厢为动车组,而7号车厢为乘务员室,因此设计7号车厢信号装置与2,3,6略有不同。4,5号车厢为拖车,假设信号装置相同。其具体情况如图3所示。信息发布节点以广播方式向总线上发送信息,其它节点通过报文滤波来接收数据。

3 WTB仿真模型

WTB总线模型包括一个总线模型块和8个节点模型块,如图4所示。在Stateflow工具箱中,8个车厢节点模型是相同的,为并行结构。主要用来进行时间基准和输入输出变量。在此模型中,设定总的运行时间为0.5s,TCN通信网络的传输速率为1Mbps。为了计算方便,假设每一帧数据长度为500bit,则TCN网络在满负载时可传输1000帧数据。

其中WTB model包括三个部分:节点模块、总线模块和函数模块,如图5所示。

第一部分节点模块,node1～node8结构相同,因为本次仿真主要研究TCN网络的通信性能,所以在建立节点模型时,只考虑了其通信活动所涉及的部分,没有加入节点计算控制活动部分和数据接收部分。p1～p8分别代表第1～8个节点每次运行过程中产生的总帧数,而b1～b8则分别代表第1～8个节点每次运行完成后向总线上成功发送的总帧数。

节点模块由send(节点状态),buffer(缓存器),frame(数据产生)三大部分组成,如图6所示。其中节点状态部分包括:“sleep(无数据需要传输)”,“wait(等待传输)”,“transmission(传输中)”三个状态。缓存器包括:“empty(空)”和“full(满)”两个状态。数据产生包括:“sample(数据采样)”和“shape(数据组装)”两个状态。

“send”模块代表节点发送部分,状态“sleep”意味着节点处于无任务状态,即没有信息需要传输。当有数据被采集进来,节点状态转移到“wait”状态,此时节点开始监测总线。只要发现总线处于“idle”状态,节点就开始置标志位参与总线竞争。如果竞争成功,节点转移到“transmission”状态,否则继续处于“wait”状态,等待下一次的发送机会。在“transmission”状态中,当发送过程结束,节点再次转移到“sleep”状态。

“buffer”模块代表节点的缓冲器,这里假设容量为1。每个节点信息都放在各自缓冲器中,当缓冲器中的信息还没发送出去而新的信息到来,则丢弃新的信息。

“frame”模块代表节点中数据产生部分,此仿真数据由设备级输入,数据长度服从随机平均分布。在状态“shape”中,数据被组装成WTB标准帧。在实际系统中,数据可能是节点本身采集的现场检测数据,也可能是节点控制器输出的数据。

节点(send)和缓存器(buffer)的状态首先处于无数据传输(sleep)和空(empty)的状态,而数据产生的部分则产生一个数据,并进入数据组装(shape)的状态。当数据产生部分的状态转移时,触发缓存器和节点的状态转移到满(full)和等待(wait)的状态,节点竞争到总线的使用权以后就会由等待(wait)状态转移到数据传输(transmission)的状态,开始传输数据。当节点传输完数据帧之后,缓冲器转移到空(empty)状态,出发节点转移到无数据传输(sleep)的状态,总线转移到空闲(idle)的状态,等待下一个数据的传输。这样就完成了一个完整的WTB总线通信过程。

第二部分是总线模块fieldbus,如图7所示在上述WTB总线通信系统中,信道(即总线)具有四个状态,当总线上没有信号传输时,总线处于“idle(空闲)”状态。当主设备发送请求信号时,总线处于“listen(侦听)”状态。当有节点要发送信息,首先进行令牌轮询过程;轮询结束后,总线便进入“busy(总线忙,正在传输)”状态,开始传输竞争获胜(即优先级较高)的帧。帧传输完毕,经过一个“Space(帧间隔)”状态后,总线再次回到“idle(空闲)”状态。请求侦听过程由“request函数”来轮询各主设备节点。令牌轮询过程由“polling函数”完成,如图8所示。

第三部分是判别函数,包括request和polling两个函数。2,3,6,7号车厢为动车组,主设备在这四个车厢中。因为侦听这四个节点,如果有请求信号,则发送传送信号。polling为令牌轮询函数,假设节点2为强主节点,则节点3,6,7为弱主节点,节点1,4,5,8为从节点。

以上所述的仿真平台简洁直观地解释了TCN网络的控制机理,并能动态地仿真通信活动。由于平台中设定了时间参数,仿真可以输出与时间有关的参数,这对于分析TCN网络系统的性能提供了很大便利。

4 MVB仿真模型

设电缆传输时延为2μs,双绞线传输时延为20μs,则可在Simulink中建立如下模型。假设1,2,3,6,7,8号车厢主要由四种类型的设备向总线传输信号,则MVB总线模型如图9所示。4,5号车厢为拖车,假设有三种类型设备,其MVB总线模型与上图9相似。

如图10所示,BA总线管理器模块通过Stateflow来实现。总线管理器设备在轮回时间内保持对总线的控制。

5 性能分析

通过仿真可以得出TCN的网络性能,分析如下:

(1)在负载和传输速率变化的情况下,网络传输数据的趋势,如图11所示。

如图12所示,仿真中传输数据的变化是由TCN的信息传输机制决定的。在总线空闲时,任一节点都有发起通信的权力。在负载较低时,低优先级的信息可以竞争到总线权得以发送,并且随着负载的增加,总线利用率提高,总线利用率提高,传输数据也随之变高。当负载提高到一定程度时,只有高优先级的信息得以发送,而低优先级的信息却可能被长时间延迟甚至造成数据丢失,这时总线利用率达到最高,但传输数据却开始下降。同理传输速率变大,传输占用总线时间变短,总线可以传输更多信息,提高了数据传输量。但是,当传输速率较大时,这种情况表现得不再那么明显。

(2)在负载和传输速率变化的情况下,信息平均传输时延的趋势。

由图13可见TCN网络系统中不同优先级信息受负载和传输速率的影响不同,这是总线竞争的结果。当负载较低或传输速率较大时,由于各优先级信息都可以竞争到信道使用权,所以信息发送平均时延差别不大;但随着负载的增加或传输速率降低,信道主要用来发送高优先级的信息,优先级越低的信息延迟越大,有的信息永远得不到发送机会。当负载一定时,随着TCN网络传输速率的增大,信息发送平均延迟被缓解。这个过程和负载增加过程对信息发送平均延迟的影响相反,如图14所示。

6 结束语

运用MATLAB软件中Stateflow工具箱来对TCN通信网络进行建模仿真切实可行。仿真模型能够完全描述协议的复杂逻辑关系,而且形象直观贴近实际系统,易于理解,也便于修改调试。这种仿真方法为现场总线协议的分析与仿真提供了一个新途径。基于此仿真模型进行扩展,可以对TCN通信网络进行更深一层的研究,探讨TCN通信网络的其它性能。

摘要：对TCN网络的WTB和MVB总线分别进行了介绍。在此基础之上根据各部分的功能要求划分各模块的设计思想及具体的设计实现。在Matlab环境下,利用有限状态机理论对TCN通信网络进行了形式化建模。状态机模型的仿真动态展示了总线系统的通信行为,并为总线控制系统的通信研究提供了一个仿真平台。从节点的角度出发,建立了节点的发送和接收状态机模型。在此仿真模型基础上,研究了TCN网络控制系统的网络性能指标的影响。

关键词：列车通信网络,Stateflow,网络性能

参考文献

[1]国际标准IEC61375-1:铁路电气设备——列车总线[S].国际电工委员会,2001.

[2]Train communication network.International Electrotechnical Commis-sion Std[S].IEC61375-1,1999.

[3]付秀霞,庞彦斌.基于状态模型的CAN总线系统的仿真[J].北京化工大学学报,2005,32(4):100-102.

[4]付秀霞.现场总线协议的建模与仿真[D].北京化工大学硕士学位论文,2005.

[5]杨顶方.网络控制系统的研究与平台建设[D].浙江大学硕士学位论文,2005.

Stateflow 篇3

目前国外对于Simulink和Real-Time Workshop的应用大体可以分为三类:一是直接应用Real-Time Workshop, 根据实际目标硬件直接从Simulink的模型中产生优化的、可移植的和个性化的代码。二是xPC目标环境, 它是一种用于产品原型开发、测试和配置的PC机解决方案。三是第三方厂商开发的基于Real-Time Workshop的代码生成及仿真环境, 如德国dSPACE公司开发的dSPACE实时仿真环境。

本文介绍的是第一类的应用, 并结合车身控制模块的功能需求, 详细介绍系统建模及代码自动生成的过程。

1、开发工具介绍

Simulink是基于MATLAB的图形开发环境, 可以用来对各种动态系统进行建模、分析和仿真。在创建动态系统模型时, 通过Simulink提供的图形界面, 只需单击或拖动鼠标操作就能完成整个模型的创建工作, 大大简化了开发过程[1]。

Stateflow是一个交互式图形开发工具, 它和Simulink一起用于实践动态系统的建模和仿真。它可以用于解决复杂的逻辑问题, 用户可以通过图形化工具实现在不同状态之间的转换。

RTW Embedded Coder是在原有Real-Time Workshop的基础上推出的更加灵活完善的开发环境, 它不仅适合于产品的最终实现, 也可以代替快速原型代码进行控制系统的仿真。它保证了基于处理器的在回路仿真和基于产品硬件的在回路仿真中使用相同的代码, 便于系统的模拟与测试, 缩短了开发周期、减少了开发的中间环节。

2、建立并验证车窗控制模型

车身控制系统包括汽车安全、舒适性控制和信息通信系统, 主要是用于增强汽车的安全性、驾驶的方便性和乘坐的舒适性。车身控制技术发展至今, 已形成模块化和系统化, 即众多的电器控制功能已整合到一个 (或几个) 功能强大的控制模块中, 这就是我们常说的车身控制模块[2]。

下图是一个典型的BCM系统框图, 描述了BCM中包含的主要功能, 实际上随着车型的不同, BCM中包含的功能可能会增加或删减。

2.1 建立车窗控制模型

BCM包括了许多不同的功能模块, 图1中所列的功能都可以用建模来实现, 最后集成到一起, 形成一个完整的车身控制系统。本文将以车窗控制模块为例, 介绍模型创建和代码生成的过程。

在图2的车窗控制模型中, 共有5个并行状态。各个状态模型的功能分别是:

SubFunction:检查点火钥匙、车窗按键、车门的状态。

RightFrontWindowControl:右前窗的控制逻辑。

LeftRearWindowControl:左后窗的控制逻辑。

RightRearWindowControl:右后窗的控制逻辑。

AutoWindowControl:车窗自动升降的控制逻辑。

由于左前窗是由LIN线直接控制的, 所以不必对它进行建模。

对于每个并行状态来说, 其内部还有Stateflow子状态的状态图, 各个并行状态的子状态之间是互斥的, 不可能同时执行。

由图2可以看出, 对于复杂的Stateflow模型来说, 其顶层一般是由多个并行状态组成的。每个状态按照右上角的编号顺序执行, 并且它们之间的功能相互独立。

2.2 验证车窗控制模型

Simulink提供了几个重要的组件来验证Stateflow模型的功能, 用于仿真验证的Simulink车窗模型主要包括三个组成部分:

(1) Signal Builder:用来产生测试用例。测试用例包括两种, 一种是验证车窗模型的功能与系统需求是否相符, 另一种用于测试模型的代码覆盖率。

(2) Subsystem:里面封装了基于Stateflow的车窗模型。

(3) Scope:用于观察模型的输出。

在仿真过程中, 如果模型的输出不正确, 这时可以用Stateflow的调试器对模型进行调试。Stateflow允许对模型设置断点, 或用动画方式观察模型的执行情况。除了全局断点外, 还可以针对对象、状态、转移、事件以及函数等Stateflow对象设置断点。对象的断点设置需要在对象的属性对话框中完成, 也可以通过模型查看器来完成[3]。

除了对模型进行调试外, 仿真模型还可以检查代码的覆盖率, 代码覆盖率检查有助于验证模型的功能。Simulink可以对多种覆盖率进行分析, 主要包括判定覆盖、条件覆盖、修正条件判定覆盖和真值表覆盖四种。为了能达到尽可能高的代码覆盖率, 必须在Signal Builder设计各种针对不同情况的测试用例, 以保证模型中每个条件、每个分支都能被覆盖到。

3、生成定制的嵌入式代码

3.1 目标语言编译器

目标语言编译器 (Target Language Compiler, TLC) 是RealTime Workshop产品的重要组成部分, 主要用它来定制生成的代码。根据个人需求, 通过编写不同的TLC文件, 可以对平台选择、算法性能、代码大小、兼容性等方面作不同的配置。

通常TLC文件分为三类: (1) 系统目标文件:目标语言编译器的入口点, 监控整个代码生成过程。它们提供了大致的代码框架, 决定模块何时被执行, 数据如何记录等。 (2) 模型目标文件:些文件用于通过模型信息生成不同格式的代码文件。 (3) 模块目标文件:这些文件用于控制特定的Simulink模块, 以及其内联代码的生成。一般情况下, 每一个Simulink模块都有一个对应的模块目标文件。

3.2 生成嵌入式代码

使用Real-Time Workshop Embedded Coder将Simulink模型转化成代码的过程中, 会调用一系列的TLC文件, 最终生成经过优化的, 满足嵌入式系统需求的C代码。在这个过程中, 可以通过修改TLC文件, 对生成的代码格式做一些针对性的修改, 使代码的风格符合公司的软件规范, 并且方便后期的代码集成工作。

下面详细描述生成定制的嵌入式代码的三个步骤:

第一步:修改TLC系统目标文件。系统目标文件提供了代码大致的框架, 这里列举2个TLC文件, 一是formatbody.tlc, 这个文件定义了model.c文件中包括的头文件;另一个是formathdr.tlc, 它定义了model.h文件中包括的头文件。通过修改这两个文件, 就可以对所生成C代码中的头文件进行增删。

第二步:配置模型参数。参数配置对话框中包括了许多标签页, 为了能够生成适合特定硬件平台的嵌入式代码, 需要对其中几个标签页进行设置。

(1) Solver:设置Solver类型为离散 (discrete) 固定步长 (Fixedstep) , 步长为0.01秒。

(2) Hardware Implementation:这里选用Freescale HC (S) 12的16位单片机, 这是车身控制模块中常用的一款芯片。

(3) Real-Time Workshop:在这个标签页中主要是选择系统的目标类型, 即调用合适的TLC文件来生成代码。点击Browse按键后在弹出的对话框中选择“ert.tlc Real-Time Workshop Embedded Coder”, 即使用RTW Embedded Coder来生成代码, 并且选择目标语言为C语言。

第三步:生成代码。点击Real-Time Workshop中的Generate Code可以直接生成代码, 但这时RTW Embedded Coder会采用默认的代码生成过程, 许多自定义的配置可能不起作用。为了解决这个问题, 可以使用m脚本文件来生成代码。在m脚本文件中生成代码的命令为“rtwbuild (currentModelName) ;”, 执行这个命令了后, RTW Embedded Coder就开始了生成代码的过程。在这个命令之前还可以加入其他的命令, 对代码的格式做进一步定制。

4、结语

随着越来越多的厂商加入汽车电子的阵营, 如何高质量、高效率的开发汽车电子产品, 迅速占领市场, 成了众厂商共同面临的问题。在这种情况下, 使用Simulink/Stateflow对汽车电子控制模块建模, 并用RTW Embedded Coder生成特定硬件目标的嵌入式代码, 这种开发方式在业内逐渐推广, 并流行起来。本文详细介绍了基于Simulink/Stateflow的软件开发流程, 对于众厂商具有一定的实用价值。

摘要：采用Simulink/Stateflow对车身控制模块进行建模, 再将模型转化成嵌入式代码, 直接运行于硬件平台, 在保证代码质量的同时, 可以极大的缩短软件的开发时间。文中介绍了如何对模型进行调试及检查代码的覆盖率, 并且通过修改TLC文件, 定制代码的格式, 最终生成适用于特定平台的嵌入式代码。

关键词：Simulink,Stateflow,车身控制模块,自动生成代码

参考文献

[1]周朝华.基于Simulink和VR工具的Skoda汽车的动力学模型仿真.南昌大学, 2009.

[2]何春鸣.外资企业领跑轿车BCM市场.分布式控制走俏.

[3]张威.Stateflow逻辑系统建模.西安电子科技大学出版社, 2007.

[4]The Mathworks, Inc, Real-Time Workshop Embedded Coder User'sGuide, 2010.

Stateflow 篇4

PCI (Peripheral Component Interconnect:外围设备互联) 总线是一种将系统中外部设备以结构化和可控制方式连接起来的总线标准, 包括系统部件连接的电气特性及行为;它广泛地应用在计算机和嵌入式设备中, 是迄今最为流行的工业控制总线之一。多设备的PCI系统中, 必须为这些设备提供仲裁授权信号以保障系统的正常有序运行。为此, 很多厂家有针对性地发布了PCI仲裁逻辑的专用芯片或者集成了PCI仲裁逻辑的专用芯片, 但使用上一般欠灵活[1];基于可编程逻辑器件CPLD/EPLD/FPGA的PCI总线仲裁器[1～8]就成为必然的选择, 它可以使用户根据具体应用的需求设计合适的总线策略。根据文献, 现有的总线策略包括循环优先级算法[1]、循环优先级与FIFO队列的混合仲裁算法[4]、分组循环优先仲裁算法[8]、总线加权优先循环仲裁算法[9]等。本文针对某视频监控主机系统中PCI设备对总线的需求, 提出了一种基于固定优先级和循环优先级的混合优先级仲裁算法, 并通过Stateflow对该算法进行建模实现。

2 混合优先级PCI主设备的总线仲裁算法

为了充分利用PCI总线效率, PCI仲裁器必须采用特定的优先级仲裁算法, 以便在多个设备同时提出总线请求时能根据仲裁算法判断出哪个设备应得到总线控制权。在选择仲裁算法时, 应遵循公平性、延时限制、总线的最高利用率和易于扩展性等原则[8]。本文从某视频监控主机的PCI总线设备对总线需求的实际出发, 提出了一种混合优先级仲裁算法。

2.1 某视频监控主机的PCI总线系统的描述

某视频监控主机PCI总线上共有7个PCI设备 (如图1所示) , 分别是2个视音频拾取及压缩模块 (Dev1～2) 、1个视音频监控及回放模块 (Dev 3) 和4个SATA硬盘控制器模块 (Dev4～7) 。Dev1～2的视音频数据需要通过PCI总线传输至本地硬盘存储或者供本地/远程用户实时监控, Dev3需要申请总线以传输实时监控视音频数据, Dev4～7记录的视音频文件需要通过PCI总线传输给本地或远程用户回放浏览。该PCI总线的逻辑仲裁用CPLD来实现:PCI总线设备需要使用总线时, 向总线仲裁器发出中断请求信号Req#, 总线仲裁器通过判断各个PCI中断请求状态位和各PCI设备的中断优先级决定哪个设备获得总线使用权, 并向该设备发出允许占用总线的信号Gnt# (图1) 。

2.2 PCI总线设备优先级的混合仲裁算法

目前, 应用于PCI总线总裁的基本算法主要有固定优先级算法和动态优先级算法两种。在固定优先级算法中, 各个设备的优先级是事先确定好的;而动态优先级算法是在每次仲裁授权后动态改变各个设备的优先级。这两种算法的优缺点在其它文献[9]已有充分论述。考虑到视频监控主机PCI总线上7个PCI设备对总线需求上的异同, 混合使用固定和动态两种优先级策略是合理的。总体上, 它们对实时性的要求是不一样的, 据此我们把所有设备分成优先级不同的组:Dev1～3负责实时视频监控和存盘, 为保障监控视频的流畅和存盘视频数据的不丢失, 优先级较高;Dev4～7与视频回放有关, 流畅的视频回放不受时间局限, 优先级可低。第一组的设备Dev1～3和比第二组的设备Dev4～7访问总线的机会多。为体现公平性, 同一固定优先级的几个设备具有循环优先级。

3 混合优先级设备总线仲裁算法的Stateflow○R建模

P C I总线的仲裁除了需要考虑总线请求设备的优先级以外, 还需要考虑P C I总线仲裁的有关规范。本节以Stateflow○R为平台, 建立符合P C I总线规范的总线仲裁模型。

3.1 PCI总线仲裁的原理与基本规则

(1) 仲裁器的仲裁算法必须保证所有的设备都能得到授权的机会, 否则将会出现某个优先级低的设备永远不能占有总线进行事务操作的情况。

(2) PCI主设备把R E Q#电平拉低, 表示向仲裁器请求占用总线。如果一个主设备只希望做一次总线传输, 则它应当在经仲裁获准后发出F R A M E (拉低F R A M E#电平开始总线操作) 的同一时钟周期撤消R E Q (REQ#信号变为高电平号) ;如果该主设备需要多次总线访问, 它可以保持REQ信号一直有效, 仲裁器会按照特定的仲裁算法来决定是否仍判给该主设备。当它不再使用总线时, 拉高REQ#信号电平撤消REQ;REQ信号一旦撤消, 仲裁器将认为该设备不再请求使用总线, 将不再给它分配总线资源, 因而撤消其G N T信号。

(3) 经仲裁获准后, 仲裁器把这个设备的G N T#电平拉低 (发出G N T#信号) , 表示请求获准, 该设备就可以使用总线了。GNT#信号的每次发出, 只意味着相应的PCI主设备可以使用总线进行一次总线操作 (一个FRAME发出到撤销) 。如果当前的主设备在它的G N T#信号发出后, 持续16个空闲周期还没有开始总线操作, 则仲裁器视其为超时, 此时, F R A M E实际上一直保持无效 (FRAME#为高电平) , 仲裁器可以在此之后的任意时刻撤消G N T#信号 (仲裁器把这个设备的G N T#电平拉高) , 以便服务嵌入式系统中PCI总线仲裁器的设计与实现。

(4) 如果G N T#信号被撤消时F R A M E处于有效状态, 表示当前的总线正在传输数据, 且根据规则该传输数据的操作合法。

(5) 如果总线不处于空闲状态, 则允许一个G N T#的撤消和另一个G N T#的发生在同一个周期。如果处在空闲状态, 则要求一个G N T#撤消到下一个G N T#的发出之间必须有一个时钟周期间隔, 否则可能会在A D线和P A R线上出现冲突。

(6) 当PCI总线空闲时, 一个设备从申请总线到被授权使用, 最少也需要2个时钟周期, 这对于PCI总线是一种浪费。因此仲裁器通常选中一个最经常占用总线的设备, 在P C I总线空闲时将GNT#赋予它, 这叫做总线停靠。当总线空闲时, 该设备需要占用总线时可马上得到批准。

3.2 视频监控主机的PCI总线系统模型分析以及总线仲裁算法的Stateflow○R建模

P C I总线仲裁的有关规范可由表1的仲裁器接口信号表达, 接口信号之间的关系构成了如图2所示的PCI总线仲裁器系统模型。该模型包括三个模块:总线状态查询、总线设备状态查询、总线请求仲裁等。总线状态查询主要对PCI的数据线的当前状态进行查询并标志;总线设备状态查询主要对当前获得总线使用权的设备的总线使用进程进行查询, 该进程受总线状态的控制;总线请求仲裁则根据当前授权设备的状态、当前总线请求设备的状态及其动态变化的优先级等决定下一个获取总线使用权的设备。这三个模块在总线仲裁器系统的Stateflow○R模型中则对应三个并行的线程。

3.2.1 总线状态查询及标识

总线状态查询及标志线程用于记录总线事务的状态, 需要标识的总线状态包括Idle, Busy, TransferLastData, Finish等四个, 分别表示总线空闲、忙、最后一个数据传输期以及传输完成, 在模型中它们用布尔量BusBusy进行标识。总线状态之间的转移由Frame_n和Irdy_n等两个信号驱动。该线程各状态及其转移的方式和条件如图3所示。

3.2.2 总线设备状态查询

总线设备状态查询 (如图4) 用来标识授权设备的总线服务进程以及决定当前是否需要重新指定一个授权设备。总线设备状态包括N o G n t、Gnt_to_Be_Activated、Gnt_in_Bus、和W a i t N e w G n t G r a n t e d等四个, 分别标识无总线授权设备、总线服务待启动、总线服务、等待新授权等。该线程状态之间的转移由总线状态的状态标识量BusBusy、授权命令字Gnt_n、授权撤销信号Req_n、时钟计数器Count等驱动, 并提供进程标识SearchMasterDevEn控制总线请求仲裁和授权线程。命令字G n t_n、Req_n均为8位, 其中低七位分别表示对设备D e v 1～7的总线授权或者来自设备D e v 1～7的总线请求 (均以位电平低有效) , 第八位始终为1。

重新指定一个设备的条件是: (1) 当前被授权的设备已开始传输 (由条件BusBusy==1标识) ; (2) 当前被授权的设备没有开始传输但是等待超时, 即当总线上某个设备被授权, 但16个周期仍然没有开始操作则被视为超时 (由函数Time_Counter实现) , 仲裁器可以撤销其仲裁授权, 并转授其它设备。

该线程的模型中, 嵌入式函数CompuDe vNum (Gnt_nt) 根据新周期的命令字Gnt_n计算被授权获取总线的设备编号;块函数Co mpuLastDev (currentDevNum) 则用来记录上一次使用总线的设备, 系统据此进行局部设备优先级的循环。

3.2.3 总线请求的仲裁以及授权

总线请求仲裁及授权线程 (如图5) 标识总线仲裁器的状态以及状态之间的转移条件和方式。仲裁器的状态包括Idle、Park、ReqfromDevLevel1和ReqfromDevLevel2等, 分别标识空授权、停靠、固定优先级1的设备授权和固定优先级2的设备授权。该线程状态之间的转移主要由设备请求状态字R e q_n、总线设备状态查询进程标识SearchMasterDevEn等驱动, 并标识设备授权字Gnt_n以为总线设备状态查询进程提供驱动。在状态ReqfromDevLevel1 (如图6) 和ReqfromDevLevel2内部分别完成组内设备优先级的循环。

4 仿真结果及其结论

为了所建立的P C I总线仲裁模型的有效性, 这一节设计了一个总线请求的任务进程, 该任务基本覆盖了各种可能的请求状态, 因而结果具有代表性。设备的总线申请以及仲裁结果 (总线仲裁仿真波形如图7所示) 如下:

(1) 系统启动后, 总线处于停靠状态, 由于设置的是设备1为停靠设备, 3个时钟周期后, 该设备申请总线, G n t_1立即有效, 经过5个时钟周期, 设备申请撤销Req_1, Gnt_1无效。

(2) 再经过7个时钟周期, 分属两个固定优先级的设备3、4同时申请总线, 即Req_3、Req_4有效, PCI_clk上升沿采样。

(3) 经过2个时钟, 仲裁器已经判定设备3可以拥有总线, 故使Gnt_1、Gnt_4无效, 使Gnt_3有效。

(4) 设备3检测到Gnt_3有效, 总线空闲, 使Frame_n有效, 传输开始。

(5) Req_4在Req_3传输过程中保持有效, 1 5个时钟周期后, 设备3传输完成, Irdy_n变为无效, 总线的拥有者为设备4, 即Gnt_4有效, 7个时钟周期后, 设备4传输完成。

(6) 设备4和5在又7个时钟周期后开始同时总线申请, 即Req_4、Req_5有效, 由于优先级的循环效应, 此时设备5的优先级较高, 仲裁器判定下个总线的拥有者为设备5。

(7) 设备5获得总线使用权后, 使Frame_n有效, 传输开始。45个时钟周期后, 设备5传输完成。

(8) 1 0个时钟周期后, 属于同一固定优先级的设备4、5再次同时申请总线, 即R e q_4、Req_5有效, 由于此时设备4的优先级因优先级的循环效应比设备5的高, 仲裁器判定下个总线的拥有者为设备4。

(9) 设备4获得总线使用权后, 7个时钟周期后, 设备4传输完成。

根据以上分析, 所建立的总线仲裁器模型遵循PCI总线仲裁器的规范, 仿真实验证明了设计可行性。

摘要：提出了一种PCI总线的混合优先级仲裁算法, 并将该算法应用于某视频监控主机的PCI总线系统, 建立了其基于Stateflow的模型。该算法是固定和循环优先策略的有机结合, 因而它既继承了前者的设备优先级属性的存在差异化的事实也体现了后者的设备优先级属性获取上公平性。仿真试验表明了该PCI总线策略的可行性和模型的正确性。

关键词：PCI,总线仲裁器,仲裁算法,Stateflow建模

参考文献

[1]李德升, 罗玉平.“嵌入式系统中PCI总线仲裁器的设计与实现”, 电子技术应用, 2006年第6期, P.57～60.

[2]宋杨, 刘振宇, 汪东升.“基于两优先级轮转法的PCI仲裁器的设计与实现”, 微电子学, 2004年第12期, P.663～666.

[3]聂鑫, 田建生, 梁远灯.“基于FPGA的PCI总线仲裁器设计”, 计算机测量与控制, 2005, 13 (8) , P.817～820.

[4]周先谱, 仝晓梅.“基于FIFO队列的PCI总线仲裁器的设计与FPGA实现”, 现代电子技术, 2007年第22期总第261期, P.157～160.

[5]史美萍, 窦文华.“基于EPLD的总线仲裁器的设计与实现”, 电子技术应用, 2000年第3期, P.52～54.

[6]孙方, 代作晓, 华建文, 窦秀明.“基于CPLD/FPGA的PCI仲裁器实现”, 科学技术与工程, 2006年第11期, P.3634～3636.

[7]于万瑞.“PCI总线仲裁逻辑及其在嵌入式设备中的应用”, 测控技术, 2004年第23卷第8期, P.47～50.

[8]王良清, 沈绪榜.“PCI总线分组循环仲裁算法的实现”, 微电子学与计算机, 2001年第1期, P.1～4.