实时性能（精选九篇）
实时性能 篇1
实时性能监控作为网络监控的辅助支撑手段, 弥补告警监控的不足, 能够实时提供网络运行质量情况, 便于监控人员及重点通信保障人员及时发现网络隐性故障、服务质量下降等问题 (尤其是春节、中秋等重大节日应急通信保障和集中调度的需要) 。适时采取应急措施, 控制和消除拥塞、过载等情况的发生, 从而保障网络安全、稳定运行。
实时性能监控系统是实时性要求高、用于网络保障和通信调度的监控类KPI的实时监控。实时性能监控系统基于地市公司人员及时发现、快速处理网络故障需求。采用命令通道的方式, 以更加实时的 (5-15分钟刷新周期, 1-3分钟时延) 和更贴近网络保障KPI指标, 实时呈现网络告警。
2 规范要求的指标及完成情况
实时性能监控子系统根据规范, 按照功能及指标实现情况, 已经全部完成。实时性能监控还可以对监控网元的性能指标做相关的门限设置, 网元的阀值可以以色谱的形式矩阵显示、能够监控同一指标不同网元或同一网元不同指标的图形显示。矩阵下方会显示门限告警的流水窗口, 并以短信的方式通知运维人员, 性能告警可转发至告警监控平台进行告警统一呈现。并可通过告警监控平台实现性能告警的自动短信、工单派发。
3 KPI设置的主界面 (图1)
(1) 左侧的树图是设置KPI的作用范围, 小区粒度;
(2) KPI作用时间周期设置;选择周末、节假日和平时设置时间的类型和设置时间的作用周期, 可以设定多个。设置后可以在左侧显示时间周期的设置;
(3) KPI阀值设置:设定在此周期和网元范围内, 产生KPI告警的门限和级别, 可以设定多个;设置后可以在左侧显示门限阀值的设置;
(4) 选择结束后, 点击“提交”完成本次KPI修改操作。
4 告警流水窗口 (图2)
显示产生KPI门限的流水告警, 告警内容为网元、告警时间、告警级别、告警类型、告警标题、可能原因、可能原因正文、地区、厂家、告警正文。
告警短信息通知:
在告警正文中的可以点击查看链接, 查看告警的详细信息。在告警详细信息窗口中, 通过短信的方式发送给运维人员。
5 呈现方式
实时性能监控呈现方式主要有矩阵监控和数据呈现。矩阵监控用矩阵方式以网元为单位、以颜色为区分标志呈现网元的性能状态;数据呈现用列表的方式以网元为单位、以颜色为区分标志呈现网元的性能状态。
6 实时性能监控系统的应用
从全国使用情况以及该模块的自身定位上, 多使用于如下的情形:重大节假日, 如春节, 中秋这种传统节日;重大事件, 如乌洽会, 重大灾难, 能够实时提供网络运行质量情况, 便于监控人员及重点通信保障人员及时发现网络隐性故障、服务质量下降等问题。实时性能监控还包括VIP基站管理功能, 是对VIP基站资源数据的管理与维护, 以地理和网元的形式呈现基站子系统树图, 呈现出该基站的所有告警 (包括KPI告警、性能告警、设备告警) , 并能对所显示的基站子系统的某些属性进行修改。方便维护人员对重点小区进行重点监控, 给特殊时间的网络保障工作一个方便快捷的途径。
通过增加培训次数, 培训方式可以为:电视电话培训或现场培训, 参加人员为全疆各地州维护人员, 培训过的人员负责对本地其他维护人员进行培训, 从培训中加深了对实时性能监控系统的了解和如何应用。在有重大通信保障任务时, 后台支撑优先选择实时性能监控系统, 关注交换性能指标。在重大通信保障任务结束后, 通过实时性能监控系统呈现的交换设备的运行情况, 将技术人员从传统的手工统计中解放出来, 更好的关注系统运行和设备操作。
摘要：实时性能监控系统是一种支撑手段, 弥补告警监控的不足, 本文对实时性能监控系统的应用进行了介绍, 通过实时性能监控系统能保障网络安全和稳定运行。
实时性能 篇2
摘要：分析了Linux的实时性，针对其在实时应用中的技术障碍，在参考了与此相关研究基础上，从三方面提出了改善Linux实时性能的改进措施。为提高嵌入式应用响应时间精度,提出两种细化Linux时钟粒度方法；为增强系统内核对实时任务的响应能力,采用插入抢占点和修改内核法增强Linux内核的可抢占性；为保证硬实时任务的时限要求，把原Linux的单运行队列改为双运行队列,硬实时任务单独被放在一个队列中,并采用MLF调度算法代替原内核的FIFO调度算法。
关键词：Linux；实时性；调度策略；抢占 1 引言
目前，无论是在日常生活，还是在工业控制，航空航天，军事等方面，嵌入式系统都有着非常广泛的应用。嵌入式系统目前主要有：Windows CE、VxWorks、QNX等，它们都具有较好的实时性、系统可靠性、任务处理随机性等优点,但是它们的价格普遍偏高。而嵌入式Linux以其非常低廉的价格，可以大大的降低成本，逐渐成为嵌入式操作系统的首选。但是,作为通用操作系统的Linux，由于其在实时应用领域的技术障碍，要应用在嵌入式领域，还必须对Linux内核作必要的改进。许多嵌入式设备都要求与外部环境有硬实时的交互能力，将最初按照分时系统目标设计的Linux 改造成能支持硬实时性的操作系统显得十分重要。幸运的是, Linux 及其相关项目的开放源码特征为深入研究其内核并加以改造提供了可行性, 可以修改Linux 内核中的各个模块以达到满足嵌入式应用的需求，提高软件方面的开发速度。目前，改善Linux内核的设计与实现，使其适用于实时领域吸引了许多研究和开发人员的注意力[1-4]。常用的实时性改造方法是采用双核方法，这种方法的弊端在于实时任务的开发是直接面向提供精确实时服务的小实时核心的，而不是功能强大的常规Linux核心。基于此，近年来修改核的方法越来越受到科研人员的重视，这种方法是基于已有Linux系统对于软件开发的支持，进行源代码级修改而使Linux变成一个真正的实时操作系统。本文分析了标准Linux在实时应用中的技术障碍，参考了修改核方法的思想，从内核时钟管理、内核的抢占性、内核调度算法三方面论述了改善标准Linux实时性能的方法。2 Linux 在实时应用中的技术障碍 2.1 Linux的实时性分析
Linux作为一个通用操作系统，主要考虑的是调度的公平性和吞吐量等指标。然而，在实时方面它还不能很好地满足实时系统方面的需要，其本身仅仅提供了一些实时处理的支持，这包括支持大部分POSIX标准中的实时功能，支持多任务、多线程，具有丰富的通信机制等；同时也提供了符合POSIX标准的调度策略，包括FIFO调度策略、时间片轮转调度策略和静态优先级抢占式调度策略。Linux区分实时进程和普通进程，并采用不同的调度策略。为了同时支持实时和非实时两种进程，Linux的调度策略简单讲就是优先级加上时间片。当系统中有实时进程到来时，系统赋予它最高的优先级。体现在实时性上，Linux采用了两种简单的调度策略，即先来先服务调度（SCHED-FIFO）和时间片轮转调度（SCHED-RR）。具体是将所有处于运行状态的任务挂接在一个run-queue 队列中,并将任务分成实时和非实时
用心
爱心
专心 任务，对不同的任务，在其任务控制块task-struct中用一个policy属性来确定其调度策略。对实时性要求较严的硬实时任务采用SCHED-FIFO调度，使之在一次调度后运行完毕。对普通非实时进程，Linux采用基于优先级的轮转策略。2.2 Linux在实时应用中的技术障碍
尽管Linux本身提供了一些支持实时性的机制，然而，由于Linux系统是以高的吞吐量和公平性为追求目标，基本上没有考虑实时应用所要满足的时间约束，它只是提供了一些相对简单的任务调度策略。因此，实时性问题是将Linux应用于嵌入式系统开发的一大障碍,无法在硬实时系统中得到应用。Linux在实时应用中的技术障碍具体表现在:（1）Linux系统时钟精度太过粗糙，时钟中断周期为10ms，使得其时间粒度过大，加大了任务响应延迟。
（2）Linux的内核是不可抢占的, 当一个任务通过系统调用进入内核态运行时,一个具有更高优先级的进程，只有等待处于核心态的系统调用返回后方能执行，这将导致优先级逆转。实时任务执行时间的不确定性，显然不能满足硬实时应用的要求。
（3）Linux采用对临界区操作时屏蔽中断的方式，在中断处理中是不允许进行任务调度的，从而抑制了系统及时响应外部操作的能力。（4）缺乏有效的实时任务调度机制和调度算法。
针对这些问题，利用Linux作为底层操作系统，必须增强其内核的实时性能，从而构建出一个具有实时处理能力的嵌入式系统，适应嵌入式领域应用的需要。2.3 当前增强Linux内核实时性的主流技术
近年来，人们对于Linux内核实时性改造提出了一些方法和设想，它们采用了不同的思路和技术方案。归纳总结，支持Linux的硬实时性一般有两种策略：一种是直接修改Linux内核,重新编写一个由优先级驱动的实时调度器（Real-time Scheduler），替换原有内核中的进程调度器sched.c，KURT是采用这一方案较为成功的实时Linux操作系统；另外一种是在Linux内核之外, 以可加载内核模块（Loadable Kernel Module）的形式添加实时内核，确保其高响应特性，实时内核接管来自硬件的所有中断，并依据是否是实时任务决定是否直接响应。新墨西哥科技大学的RT-Linux，就是基于这种策略而开发的。以上两种策略有其借鉴之处，但如果综合考虑任务响应、内核抢占性、实时调度策略等几个影响操作系统实时性能的重要方面，它们还不能很好的满足实时性问题。为了增强嵌入式Linux实时性能，下文将就内核时钟精度、内核的抢占性以及内核调度算法等相关问题重点研究相应的解决方法。3 改善嵌入式Linux实时性能的方法
针对Linux在实时应用中的技术障碍，将Linux改造成为支持实时任务的嵌入式操作系统, 主要从下面三个方面进行着手。
[5]
用心
爱心
实时性能 篇3
摘要：传统的绝缘电阻监测方法不具备实时检测的功能，特定条件下无法监测，且抗干扰能力差。具有一定的局限性。本文在分析传统绝缘电阻监测方法的基础上，提出一种注入低频交流信号的有源式绝缘电阻监测方法，基本实现了绝缘电阻的故障实时监测.该检测方法分为两个阶段：故障检测、绝缘电阻计算。其中，故障检测：通过测量“测量电阻”两端电压，计算出正、负绝缘电阻的并联电阻值，并由此判断绝缘电阻故障状态；检测出绝缘电阻故障后，进行绝缘电阻的精确测量：断开负载、交流信号源，分别与正负极绝缘电阻并联接入两个电阻并测量其两端电压，计算出正负极绝缘电阻值。仿真结果表明，故障误报率小于2.15%，基本实现了绝缘电阻的故障实时监测。这项技术能够有效保证微电网蓄电池储能电站的绝缘性能，一旦事故发生，能够及时的发现故障，排除隐患，继续安全、稳定的运行。因此对高压电池组在实际生产中有较大的应用价值和意义。
关键词：绝缘电阻；绝缘检测；电池管理系统
中图分类号：TP29 文献标识码：A
1引言
为使微电网储能电站的动力电池达到高功率输出的要求，常常需要将多个电池通过“串并联”的方式构成高压电池组。电池组的直流电压普遍高于300V，因而电池的绝缘性能至关重要。由于直流高压电池组的工况复杂，应用环境恶劣。其绝缘电阻容易受到温度（冷热交替）、湿度（潮湿）、振动、撞击、电池腐蚀性液体等影响，造成高压动力电池组的正负母线对地的绝缘性能下降，影响储能系统的安全运行。如电池组的绝缘电阻降低到某个阈值，则不仅会影响电站的正常运行，严重时还会造成安全灾难。因此，绝缘电阻检测是高电压动力电池组的电池管理系统（BMS）安全监测的重要任务。
传统的直流系统的绝缘电阻检测方法有：外接电阻切换法、直流漏电电流检测法、平衡电桥法等。外接电阻切换法通过并联接入电阻来计算出绝缘端正负极的绝缘电阻。这种方法的不足在于并联接入的电阻会降低设备的绝缘性能。直流漏电电流检测法，其检测电路的结构与外接电阻切换法相似，只是在两个与正负极绝缘电阻并联的电阻中间增加了一个电流传感器，测量该直流漏电电流值。在实际应用中，由于外部干扰，判断当电流传感器测量电流大于某个阈值时，认为绝缘电阻故障。在检测绝缘电阻状态时会降低其绝缘电阻性能，同时在正负极绝缘电阻同时下降时存在漏报情况。平衡电桥法是在电池组接入正、负极对地，分别并联接入电阻，通过测量其两端电压是否相等，来判定绝缘电阻是否正常。平衡电桥法因为同时并联接入电阻，也会降低设备的绝缘性能；在正负极绝缘电阻同时降低相同值时，检测不到绝缘电阻故障。值得指出的是，以上常用的三种直流系统的绝缘电阻检测方法均不具有绝缘电阻的实时监测功能。一旦发生故障，电池组的绝缘性能将会降低。如果无法及时发现并排除隐患，将会造成生命财产损失，甚至引发严重灾难。
本文通过注入低频交流信号的方式，提出一种有源式直流系统绝缘电阻检测方法，能够实现对电池组的实时监测，适用于直流高电压储能电池。该方法的绝缘电阻检测分为两个检测等级：故障检测、绝缘电阻计算。前阶段为在线过程，后阶段为离线过程。这种方法能够很好地解决在线检测问题，且对其负载回路没有任何影响。
2总体思路
本文提出了一种有源式直流系统绝缘电阻检测方法。高压动力电池组绝缘性能监测的等效电路如图1所示，其中虚线框内为实际的运行电路部分，U为高电压的储能电站电池组的电压源，RL为等效负载，Rp、Rn分别为直流电压源的正极、负极对地的绝缘电阻（下文称之为正、负极绝缘电阻）。Rp、Rn常因环境而发生变化，影响电路的安全运行。为了实现对正、负极绝缘电阻的实时监测，我们提出了一种如图中虚框以外部分的辅助有源测量电路，其中Us为低频率的交流信号源，R为“测量电阻”，C为隔离电容（大功率电容）。
监测时，打开K1、K2，在电路中注入低频交流信号源Us。通过测量“测量电阻R”两端的电压，则可计算出正、负绝缘电阻的并联电阻值，并由该值来判断系统的正、负极绝缘电阻的故障状态；如出现异常，断开负载、交流信号源，即系统处于离线状态，接通K1、K2，分别测量“接入电阻R1、R2”两端电压值，可计算出正、负极绝缘电阻Rp、Rn值的大小，为系统的故障诊断提供可靠依据。
这种有源式直流系统绝缘电阻检测方法针对复杂环境下的直流系统绝缘电阻故障可实时监测，且对整个负载没有影响；绝缘电阻故障后，离线测量，并计算绝缘电阻Rp、Rn值的大小，以对整个系统的故障诊断提供依据。在线检测和离线检测相结合，增加了监测的可靠性。
本文中绝缘电阻检测方法分为故障检测和绝缘电阻计算两个阶段。整个检测模块的流程框图如图2所示。
3绝缘电阻故障在线检测
绝缘电阻故障的在线检测方法：在线路中接入交流信号Us，测量电阻R两端的电压，则可计算出正、负极绝缘电阻的并联电阻值Rpn，并由该值来判断系统的正、负极绝缘电阻是否出现故障。
断开K1、K2，注入信号Us，由图1可计算出电阻R两端的电压为：
其中，Us为交流信号源的电压，为交流信号源的频率，且满足，Rpn为Rp、Rn的并联电阻：且Rp、Rn均为被监测的未知量，同时，由式（1）可得：
由计算出的Rp、Rn的并联电阻Ppn与设定的阈值Rth比较即可判断绝缘电阻是否存在故障。
在正常情况下，绝缘电阻值Rp=Rn，由式（2）可知，Rpn小于绝缘阻值Rp、Rn：
因此，判断Rpn是否小于阈值Rth，若是，则绝缘电阻故障，否则，绝缘电阻正常。
阈值Rth是通过相关技术标准（由于暂无储能电站电池组绝缘电阻安全标准，这里参考了电动汽车的技术标准）及直流电压源的电压值的大小而设置。例如：电动汽车电池组直流电压源的电压为U=350V，并参考国家技术标准：《GB/T 18384.1电动汽车安全要求第1部分：车载储能安全》，该标准要求参数大于500Ω/V。则电动汽车电池包直流电压源的绝缘电阻Rp、Rn均要大于175KΩ。由此可设定阈值Rih=175KΩ。
从图1可看出，由于在线检测时，因K1、K2是断开的，故交流信号源对整个负载回路没有影响，这样可以实时监测绝缘电阻的故障状况。
4绝缘电阻计算
在检测到绝缘电阻故障后，断开负载RL及交流信号源Us（即系统处于离线状态）。接通K1、K2，将正、负极绝缘电阻Rp、Rn分别与“接入电阻”R1、R2并联，其等效电路图，如图3所示：
因为正、负极绝缘电阻Pp、Rn处于悬空状态，很难测量到其两端电压值，接入电阻R1、R2是为了方便的测出Rp、Rn的电压值。分别测量电阻R1、R2两端电压Up、Un以及故障检测数据，则可计算出正、负极绝缘电阻值。由此可得下式：
式（5）与式（2）联立组成方程组，可计算得到正、负极绝缘电阻Rp、Rn的大小为：
因此，通过上述在线绝缘故障检测和离线绝缘电阻测量两个过程，形成切实可行的绝缘电阻检测方案，以实现绝缘电阻的故障实时监测。在实时监测绝缘电阻时，对整个负载电路没有任何的影响，而且检测到故障后，系统进行离线测量，使数据真实有效，为整个系统故障诊断提供依据。
5仿真验证及误差分析
为了验证有源式直流系统绝缘电阻检测方法的有效性，有必要对方案进行仿真模拟。由于这套有源式直流高压电池组绝缘性能检测方案的离线测量部分检测原理清晰，电路设计简单。故这里的仿真验证只针对在线故障检测环节。
5.1参数配置
根据相关技术标准要求储能电池组的绝缘电阻大于500Ω/V，及动力电池组的总电压U=350V，则相对应的正、负极绝缘电阻均要大于175KΩ，即x>175KΩ（x∈{Rp，Rn}）。由此可设定电阻阈值Rth=175KΩ。
考虑到绝缘电阻故障检测电路测量精度、测量周期、稳定时问及阈值大小等因素，选取仿真配置参数如表1所示。
由表1给出的配置参数可知低频交流信号源的周期为T=0.1s，由此可求得稳定时间ts≈4（R+Rpn）C。即在正常情况下，Rpn在之间1MΩ～10MΩ，则稳定时间在几秒到几十秒之间；在存在故障情况下，稳定时间则在1秒以下。在式（1）中，由于参数Rpn与1/Cω在同一数量级，因此，该类参数配置不会影响测量精度。
然而，在绝缘电阻检测时注入低频交流信号源，其电阻R的端电压Um滞后于交流信号源Us，因此采用其平均值计算。
故障检测的SIMULINK仿真模型如图4。
图4中下部分为故障检测电路；上半部分为故障检测的测量与计算，模块Mean是计算交流信号源Us、测量电阻R的端电压Um的有效值；模块Calculation是计算正、负极绝缘电阻的并联电阻值Rpn。其内部的封装如图5所示：
Mean模块由两个通道，分别对交流信号源Us、测量电阻R的端电压Um进行采样、积分求得各个电压平均值Mean_Um、Mean_Us。其中，采样模块Sampling和Sampling_sub以及积分模块In-tegration和Integration_sub均由SIMULINK软件S函数编程实现。
Calculation模块是实现公式（3）的计算，Mean模块计算得到交流信号源、测量电阻的端电压的平均值，再根据公式（3）计算得到正、负极绝缘的并联电阻值。为了验证对正、负极绝缘的并联电阻值Rpn测量的准确性，设置6组数据进行实验，并统计其测量误差。其包括：绝缘电阻正常、不同故障情况下的数据。正、负极绝缘电阻值的数据设置如表2所示：
实验结果说明：
由表2可以看出，前3组实验随着绝缘电阻的下降（但未低于阈值Rth=175KΩ，仿真结果误差增大。后3组实验是Rp和Rn中至少有一个低于阈值，即绝缘电阻出现故障的仿真结果。正、负极绝缘电阻并联的计算测量误差在4.4%以内。经过分析，误差主要原因来自求其有效的计算时的积分。因此，通过计算正负极绝缘电阻Rpn的并联值，则可提取绝缘电阻变化状态特征。
5.2故障误报率分析
故障报警是在线监测的必备环节。当Rp≠Rn或Rp、Rn任何一个值小于设定阈值Rth（本文阈值设为Rth=175 KΩ）时，系统将会报警。考虑到测量Rpn时存在4.4%以内的误差，因此，有必要分析故障报警率。
图6是故障率误报分析图。曲线Rpn=RpRn/RP+Rn（图中实曲线）的左下方区域（A、B、C、D、E、F区域）为故障报警区域。由于故障报警条件及测量误差，区域E为绝缘电阻故障误报区域。其区域占故障报警区域小于2.15%，并绝缘电阻故障并不是突变的过程，绝缘电阻完全正常情况下，正、负极绝缘电阻Rp、Rn均大于10Rth，因此，本套绝缘电阻检测方法能够满足实际应用。
6结语
车辆空调性能实时检测系统研究 篇4
汽车工业中车内的空调能否随着周围空气质量的变化调节车内的环境,使驾驶员始终感到舒服是衡量汽车舒适性的一项重要指标。汽车空调检测是鉴定空调装置性能及汽车空调匹配性能,保证汽车舒适性的重要环节,也是使汽车空调发挥出最大功用的重要保证[1,2]。车辆空调性能实时检测系统主要对轿车内空调的温度、湿度、风速进行实时检测。
检测过程是在整车上进行,因汽车在检测线上移动,为现场布线带来了很大困难。因此,本研究采用无线传输方式进行实时采集,并在系统设计时优选检测传感器、数据处理机。在数据处理上,笔者采用多种复合方式进行处理,以期达到理想效果。
1 检测系统构成
系统的硬件构成方框图,如图1、图2所示。一般轿车上安装的空调,在正副驾驶位的正前方各有一个出风口,分别称左、右出风口。正副驾驶位之间有2个出风口,其中一个向车前方送风称为中出风口,一个向车后方送风称为后出风口[3]。设计时选择了4个风速传感器和温度传感器分别测量这4个出风口的风速、温度。对于车内湿度的测量,选用了一个湿度传感器。
2 系统结构
2.1 系统硬件
对于车内温度的测量,本研究所采用的是LTM8301温度测量模块,由于模块要求与上位机采用RS485通讯,而饼干电脑的串口为RS232通讯,在将模块接入电脑前,必须得进行两种通讯形式的转换。本系统使用的是RS232/RS485转换器。
本研究应用LTM-8301模块,配合LTM8802测湿探头对车内湿度进行测量。
测量风速的仪器QDF型热球风速计由热球式测头和测量仪表两部分组成,在这里只用了热球测头。
信号的无线传输是由抗干扰能力强、收/发一体的PTR2000模块实现的[4]。由于RS232是用正负电压来表示逻辑状态,而PTR2000以高低电平表示逻辑状态。在本系统中,采用MAX232芯片完成TTL与RS232之间的双向电平转换[5]。
2.2 系统软件
本研究对发送部分和接收部分分别进行编程,对于饼干电脑,笔者采用C语言对其编程并用于数据的发送,程序框图,如图3所示。对于工控机,采用Visual Basic对其编程,负责数据的接收、处理,其过程为:先设置波特率,初始化串口,再输入汽车VIN码,检验VIN码正确否,不正确再重新输入,如果正确,接收端接收信号。检验接收信号完成否,未完成则继续接收,完成则检验接收的数据正确否,不正确则从输入汽车VIN码重新开始,正确则读出风速、湿度、温度值并存入数据库,显示、画出曲线并打印,结束接收过程[6]。
在无线通讯中,为提高系统的稳定性以及信号传输的可靠性,必须从硬件和软件上提高系统的抗干扰性[7]。在本系统中,主要采用软件来抗干扰。在所要传送的数据前后分别加上标识符,接收时,只有检测到标识符才对数据进行处理,否则认为数据无效[8]。本系统中采用了多次平均滤波算法用于信号的平滑加工,具体做法是连续采样n次,并将第1点直至第n点依次连接,求出第1点与第2点的平均值(a10),第2点与第3点的平均值(a11)…第n-1点与第n点的平均值(a1n),然后求a10与a11的平均值…,依次类推。
通过滤波(计算平均值)使不规则点变成较为平稳的数据。信号的平滑程度取决于平均次数的选择,随着平均次数的增大,平滑度随之提高,而灵敏度降低。
在接收端采用循环冗余码差错检测法(CRC)进行差错检测。接收方如果发现错误,则回一信息,通知发送端该数据以前的信息均正确收到,要求重发该数据及其之后的信息;若没有发现错误,则不回送信息,由此来提高收/发效率[9]。
3 实时检测
系统主要测量轿车空调的4个出风口的温度、风速值和湿度值;在车间的温度26.5 ℃,湿度18.9%的条件下检测车内空调的制冷能力。启动发动机,使转速稳定在2 000 r/min,打开空调调至风速最大档处,关闭车窗,开始测量,检测时间为5 min。此时左、右出风口处用风速计测得的空气流速不少于4 m/s,左、右出风口风量偏差不超过2%。
在5 min的测试时间内,每隔30 s接收一组数据,每个性能指标测出10组数据。在测量出被测量(xi,yi)后,由待定系数法求得一简单拟合曲线y=φ(x),使:
由此,可以由Matlab绘制空调各性能指标的拟合曲线。
3.1 空调温度调节拟合曲线
空调温度调节拟合曲线,如图4所示。
左出风口温度拟合方程为:
φ(x)=7e-0.5x2-0.061 2x+21.215(2阶拟合)R2
=0.997 3 (2)
右出风口温度拟合方程为:
φ(x)=5e-0.5x2-0.043 4x+17.661(2阶拟合)R2
=0.990 1 (3)
后出风口温度拟合方程为:
φ(x)=-0.017 6x+13.812(线性拟合)R2
=0.958 (4)
中出风口温度拟合方程为:
φ(x)=0.000 1 x2-0.067 7x+20.629(2阶拟合)R2
=0.986 9 (5)
3.2 空调湿度拟合曲线
空调湿度拟合曲线,如图5所示。
湿度拟合方程为:
φ(x)=0.000 1x2-0.064 7x+41.857(2阶拟合)R2
=0.9762 (6)
3.3 风速曲线的测量值
由于在测量过程中,风速档打到最大值,故只得出风速测量值。
空调的合格标准为:在上述条件下,5 min规定时间内温度降到9～14 ℃范围内,湿度达到30%～40%范围内。由图4、图5的拟合曲线可知,在上述的测量条件下,空调在3 min左右即可达到标准,也说明了研制的检测系统满足使用要求。
4 结束语
为满足生产实际中空调性能在线检测的要求,笔者研制了一套车辆空调性能实时检测系统。实际应用表明,本研究研制的检测系统使用方便,性价比高,在汽车行业中有很好的应用前景。然而本研究所提出的系统只对空调的温度、湿度、风速3个最为重要的指标作了检测,在以后的研究中,笔者拟对空调的其他性能进行研究并作检测,使系统逐步完善起来。
摘要：为满足生产实际中空调性能在线检测的要求,针对车辆空调性能的检测进行了研究,研制了一套在检测线上实时快速测量空调温度、湿度、风速等性能指标的系统。详细阐述了整个检测系统的硬件设计、软件设计、数据处理方法等,并在实地测量的基础上,得出了测量数据,绘制了相应的拟合曲线。实际应用表明,该系统使用方便、性价比高,具有广阔的推广应用前景。
关键词：汽车空调,串行通信,无线通信,CRC校验法
参考文献
[1]方贵银,李辉.汽车空调技术[M].北京:电子工业出版社,1999.
[2]郑明华.汽车空调原理、结构与维修[M].北京:机械工业出版社,1993.
[3]陈孟湘.汽车空调新世纪版[M].北京:北京航空航天大学出版社,1999.
[4]毋昌明,辛肖明.无线数据传输系统的设计[J].北京理工大学学报,1994,14(1):59-63.
[5]李朝青.PC机及单片机数据通信技术[M].北京:北京航空航天大学出版社,2000.
[6]邓善熙.在线检测技术[M].北京:北京航空航天大学出版社,1996.
[7]REPPAPORTTS.无线通信原理与应用[M].蔡涛,李旭,杜振民,译.北京:电子工业出版社,1999.
[8]孙艳蕊,刘运妙.无线通讯网络可靠度的计算[J].计算机工程与应用,2001,37(6):32-34.
EPA的实时性能分析与计算 篇5
关键词：EPA网络,实时性,周期数据,通信延迟
0 引言
目前, 以太网技术在工业控制领域的应用越来越广泛。由于工业控制的最基本要求是实时性, 因此, 工业以太网技术首先需要解决的问题是改造以太网的传输不确定性。目前, 已有的工业以太网技术包括EtherNet/IP、HSE (High Speed Ethernet) 、Profinet、Modbus-IDA以及我国自主研发的EPA (Ethernet for Plant Automation) , 它们都是在不破坏以太网工作特征的情况下, 或通过令牌技术, 或通过时分复用技术, 将以太网的CSMA/CD (带冲突检测的载波侦听多路访问) 改造为CSMA/CA (带冲突避免的载波侦听多路访问) , 从而将以太网的不确定通信变为可确定的实时通信。
EPA通过时分复用的方法, 将通信时间划分为一个个通信周期, 在通信周期内为每个通信设备分配1个时隙, 并将工业控制网上传输的信息数据划分为周期数据和非周期数据两大类。周期数据是对传输延时有严格要求的数据, 也称为实时数据;非周期数据则是对传输延时无严格要求的数据。通信周期是根据现场I/O数据 (周期数据) 从采集到输出控制的实时性要求在系统初始化时确定的, 所有数据的传输都在该通信周期内进行。周期数据传输对通信周期时间的占用取决于周期数据的信息量大小, 非周期数据只能在该通信周期内无周期数据传输的空闲时间内传输, 因此, 非周期数据的传输是无保障的。
本文通过对EPA网络中周期数据在端点的处理及其在端点间的传输过程的分析, 讨论了周期数据从产生到作用结束之间的时间构成, 并以一个典型的EPA网络为例, 计算了该时间的大小, 从而确定出EPA网络的实时性能。
1 EPA的周期数据传输原理
EPA将整个网络根据现场环境和检测及控制需要划分为一个个微网段, 每个微网段拥有1个独立的通信周期, 网段内所有的数据传输都在该通信周期内进行。完成1个通信周期所需的时间T称为1个通信宏周期 (Communication Macro Periodic) 。T的大小应能满足该微网段内最短时间响应要求的周期数据的传输。在1个EPA微网段内, 所有EPA设备的通信均周期性地进行, 且所有EPA设备的周期数据必须在1个T周期内传输完毕。每个EPA设备分配有1个时隙, 该时隙的大小由每个EPA设备传送的报文大小确定, 时隙在通信周期中的位置由初始化时的时间偏移量给定;而EPA设备发送周期数据报文的时间偏移量则根据EPA设备传送的报文的信息量大小确定。
1个通信宏周期T分为2个阶段:周期报文传输阶段Tp、非周期报文传输阶段Tn (如图1所示) , 分别供微网段内的EPA设备传输周期数据报文和非周期数据报文。不同EPA设备的周期数据报文按预先设定的时间偏移量的大小先后发送, 而非周期数据报文按其优先级高低、IP地址以及时间有效方式发送, 因此, 非周期数据报文在发送前, 要在其周期数据报文发完之后, 先发1个非周期数据声明报文以判断其优先级。
由于T的大小能够满足微网段内最快响应要求的EPA设备, 因此, T能够满足微网段内所有EPA设备的实时性要求。此外, 微网段内所有EPA设备周期数据报文的信息量总和 (包括非周期数据声明报文信息量) 应能在1个通信宏周期T内传输完毕。因此, 受通信宏周期T (也即最快响应EPA设备的延时时间要求) 的限制, 一个微网段内所能容纳的EPA设备的数量不能太多。
每个EPA设备的非周期报文只能在一个非周期阶段到来时, 根据其优先级以及宏周期剩余的时间决定其在本周期内能否发送。如果非周期报文太大, 在本周期的非周期报文发送时段不能发送完毕, 则应将其分割成多个报文, 在随后的一个或紧邻的连续多个或非紧接的非连续多个非周期内继续发送。
2 EPA的周期数据通信延迟构成
2.1 EPA网络端到端的通信延迟
EPA网络中从信息发送到信息接收之间延迟的全部时间, 称作端到端的通信延迟, 主要包括以下3个部分:
(1) 排队延迟:从信息进入排队队列到该信息获取通信网络、接触到通信介质所经历的时间。排队延迟主要由通信网络的媒体存取控制协议和相应的信息调度算法以及缓存空间的大小决定。
(2) 发送延迟:从信息的第一个字节开始发送到信息最后一个字节发送结束所需的时间。发送延迟取决于信息的大小和通信网络的通信速率。
(3) 传输延迟:信息在现场设备间传输所需的时间。传输延迟取决于通信网络在现场设备间的物理长度及传输速率。
设通信延迟、排队延迟、发送延迟和传输延迟分别为Tdelay、Tqueue、Tsend和Ttrans, 则:
端到端的通信延迟是构成整个控制系统响应时间的重要部分, 若端到端的通信延迟不能满足实时要求, 则无法保证控制系统的实时性。EPA的周期数据通信可发生在传感器节点、执行器节点、控制器节点任意二者之间。
EPA网络的排队延迟主要由宏周期等待时间Tc (μs) 和缓存空间限制造成的等待时间Tb (μs) 构成;其发送延迟由信息量的大小M (Mb) 和网络的通信速率Vb (Mb/μs) 构成;其传输速率由传输距离S (m) 和传输速率V (m/μs) 构成。因此, EPA网络端到端的通信延迟为
2.2 EPA网络信息的端点处理
系统实时性是指系统对某事件响应时间的可预测性;系统的响应时间是指在规定条件下, 从信息转换开始到系统开始作出有效反应的那一瞬时之间的间隔时间。在网络化工业控制系统中, 系统的响应时间除了端到端的通信延迟之外, 还包括信息在端点的处理时间。以下为EPA网络信息在端点的处理过程。
EPA通信发起方首先根据与所发送的参数对象相对应的链接对象标识, 查找与其相对应的EPA链接对象, 并查找本次通信所需的EPA链路信息;然后, EPA应用进程根据EPA服务标识, 调用相应的EPA应用访问实体或系统管理实体服务, 将需要传送的数据编码为EPA服务请求原语报文, 并对请求报文标识加1, 之后将EPA服务请求原语报文传送给EPA套接字映射实体;EPA套接字映射实体将该请求原语报文按UDP/IP协议进行封装, 并传递给EPA通信调度管理实体;EPA通信调度管理实体按初始化时候的宏周期及其时隙偏移量, 在时隙到来时将EPA报文发送到网络上。
对于EPA证实服务请求原语报文, 自报文发送到EPA网络上起, 启动超时计时器, 根据请求原语报文标识建立报文响应维护列表, 对响应报文进行维护, 并由EPA用户应用程序对EPA响应报文进行处理。
而在EPA通信接收方, EPA通信控制器从EPA网络上接收到报文后, 由EPA通信调度管理实体直接将报文发送给EPA套接字映射实体, 由EPA套接字映射实体将接收到的报文进行缓冲;由EPA套接字映射实体根据服务标识对EPA报文过滤, 并根据EPA应用访问实体或EPA网络管理实体报文服务号调用相应的服务对报文进行解码, 解码后的数据提交给EPA功能块实例进行处理。
EPA功能块实例对解码后的EPA应用访问实体服务报文的处理分2种情况:对于无证实EPA报文, 查找到相应变量并用接收到的数据更新相应变量;对于有证实EPA报文, 则将本地源信息与相应的响应数据一起发送给EPA通信请求发送方。
信息在端点的处理时间主要取决于端点CPU的处理速度、执行代码的多少、操作系统对处理器、存储器和I/O的管理机制等。
设EPA设备采用嵌入式Linux操作系统, 其平均分时时间片为ΔT (μs) , 允许最多并行任务数为N, CPU速度为I (MIPS) , 相继执行的程序块的指令代码总长度为U (MI) , 则EPA信息在端点的处理时间Tend为
若EPA设备采用抢占式多任务操作系统, 如μC/OS等, 则任务是按照优先级分配CPU资源的, 可用平均等待时间Tw表示功能程序得到执行前的等待时间, 则式 (3) 变为
3 EPA网络的信息数据通信实时延迟计算
图2为典型的EPA网络的微网段构成图。从实时性角度来说, 每个EPA微网段拥有完整独立的实时性。在该EPA微网段中, 实时响应时间是从启动事件信息 (传感器数据) 进入EPA输入模块, 经过处理后发送到EPA控制器模块, 再经EPA控制器模块运算处理后传送到EPA输出模块, 经过一定的处理后, 输出控制信息, 驱动执行机构动作这一过程所用的时间。该时间包括从EPA输入代理到EPA控制器, 再从EPA控制器到EPA输出代理这2段端到端的延迟, 加上参与通信及信息处理的3个EPA设备的信息处理时间, 即
T总=Tdelay1+Tdelay2+Tend1+Tend2+Tend3 (5)
此外, EPA网络中还有一个实时响应时间, 是指现场传感数据从产生到通过人机交互界面-显示器呈现给用户所经历的时间。由于该信息数据的传输经历二级网络, 跨过2个EPA微网段, 因此, 其实时响应时间比现场的驱动行为响应时间长。通常将该实时响应称为显示实时响应, 记作T响, 包括从EPA输入设备到EPA网桥, 再从EPA网桥到操作站这2段端到端的延迟, 加上参与通信及信息处理的3个EPA设备的信息处理时间。该3个EPA设备 (EPA输入设备、EPA网桥和操作站) 的功能及内部构成各不相同, 信息在其中的处理过程也不同, 但T响的组成成分和微网段内操作实时响应时间的组成成分相同, 同样可用式 (5) 表示。
以图2所示的EPA网络为例, 假设其中所有传输介质均为五类双绞线, 双绞线的信号传播速度为1 000 m/5.5 μs, 网络速率为10 Mbps或100 Mbps自适应, 节点间最大传输距离为100 m。
以太网MAC帧中的最大负载允许长度为1 500 B。为了实现“E网到底”, 目前设计完成的EPA网络输入模块均为单点输入, EPA输出模块均为单点输出。传输1个数据, 即使是双精度数最大也不过64位 (8 B) , 加上LLC帧头4 B, UDP报头8 B, IP报头20 B, EPA应用层协议报头固定部分长度8 B, 对于周期数据, 其服务说明等有8 B, 对于非周期数据, 其服务说明等根据不同情况有多个长度, 在此不予讨论。对于周期数据, 上述各部分长度之和远小于1 500 B, 因此, 用1个以太网MAC帧即可完成1次完整的EPA周期数据的传输。1个以太网MAC帧的协议帧头18 B加上7 B的同步引导序列和1 B的起始标志, 附加长度总共为26 B, 因此, 1个EPA设备每次发往传输线上的数据包最大长度为1 526 B (注:这里没有考虑1 Gbps速率以上的以太网带有扩展字段的MAC帧) 。
根据上述参数, 并设EPA设备的缓存空间充分够用, 可计算出10 Mbps的EPA网络在传输周期数据时的一段端到端的最大延迟为
对于100 Mbps的EPA网络, 其端到端的最大延迟为
式中:Tc为微网段内的宏周期等待时间, 是任何EPA设备发送数据前必须等待的最长时间, 由微网段内最严格的实时响应要求决定。
图2所示的微网段内所有的EPA现场设备所用CPU均为嵌入式ARM7, 其指令执行速度为0.9×64 MIPS。EPA全部功能程序编译后占用空间为200 KB左右, 其中代码所占空间约为120 KB, ARM7的指令长度为4 B, 因此, 可得出全部EPA功能程序指令代码总长度大约为160 K/4=40 K=0.03 MI (兆条数) 。EPA全部功能程序分为4个独立的任务, 分别由中断事件触发。程序设计采用非嵌套中断方式, 操作系统选用μC/OS, 即任务执行采取排他式 (剥夺式占用资源) , 只对同时发生的中断按照优先级选择响应。EPA功能程序中最长中断任务的执行时间约为全部功能程序执行时间的2/3。
根据上述条件, 可计算出EPA设备的一个端机处理时间为
对于微网段内周期数据传输, 可认为所有EPA设备间端到端的延迟是一样的, 所有EPA设备内的处理时间也是一样的, 则可计算出总的延迟为
当EPA工作在100 Mbps时, 其周期数据通信总延迟为
从式 (9) 、式 (10) 可看出, EPA不论工作在10 Mbps还是工作在100 Mbps, 其数据通信延迟都是几个毫秒级的, 因此, 工作在该2种速率下的EPA网络的实时性是毫秒级的。
4 结语
EPA的实时性能取决于EPA网络的MAC调度机制、EPA设备的软、硬件构成和传输介质。通过以上分析可看出, 目前已经实现的EPA网络能够达到的实时性能是毫秒级的, 可满足除运动控制之外的大部分工业自动化应用的要求。
该结论是在最极端运行条件下得出的, 比如, 本文设每次传输的周期数据包均为1 526 B, 实际应用中EPA数据可直接调用MAC层封装, 仅形成几十个字节 (大于64 B) 的数据包在EPA设备间传输, 传输距离也只有几十米。每次EPA设备并非全部运行所有可执行代码, 仅部分代码被调用执行, 所需时间可能在1个毫秒以内。因此, 上述结论只具有普遍意义, 不具有特殊性。也就是说, 在某些特殊情况下, 可根据控制需要将EPA的实时性能提高到毫秒级以下的水平。
进一步提高EPA实时性能的直接措施是采用速度更快的嵌入式系统用CPU, 进一步减少EPA功能程序中的冗余, 或进一步细化EPA的功能程序模块, 供用户进一步选择配置, 使实际运行的程序代码数量减少, 从而大大降低信息数据在EPA设备中的处理时间;另一个有效措施是EPA通信接口采用1 Gbps或10 Gbps的以太网芯片, 让EPA工作在1 Gbps或10 Gbps的速率上;最后一个有效措施就是在传输周期数据时, EPA应用层直接调用MAC层, 甩掉中间层次, 甚至还可进一步压缩MAC层的帧头, 只留下必要的字段, 将在微网段传输的周期数据帧的大小压缩到最小程度。
通过上述措施可将EPA的实时性能至少提高百倍以上, 达到微秒级的实时速度。若进一步结合高速单模光纤的使用, 在短距离内还可将EPA的实时性能提高到微秒级以下 (小于1 μs) 。
参考文献
[1]国家质量技术监督局.GB/T 20171-2006, 用于工业测量与控制系统的EPA系统结构与通信规范 (报批稿) [S], 2005.
[2]冯东芹, 金建祥, 褚健.基于EPA的分布式网络控制系统结构[J].自动化仪表, 2003, 24 (9) :68~70.
[3]冯东芹, 金建祥, 褚健.智能工厂核心技术——EPA实时以太网[J].国内外机电一体化技术, 2004, 7 (6) :47~50.
中心计算机性能实时监测需求与实现 篇6
运行在中心计算机上的实时测控软件实时性和可靠性要求较高［1 －2］,因此需要对软件的实时性和资源占用率等性能进行有效测试。由于测控软件系统是多进程多线程并发运行的［3］,故增加了定量测试的难度。
本文通过研究中心计算机实时测控软件系统进程和线程模块级时间开销的测试方法和软件集成技术, 构造软件资源监测环境,设计出中心计算机实时测控软件系统专用的性能测试软件,使得在测控软件调试、 维护以及飞行器试验任务中,软件编程人员和试验指挥人员能够实时掌握中心计算机系统的运行情况,为保障中心计算机系统完成飞行器试验任务提供技术支持。
1 性能监测需求分析
中心计算机实时测控软件系统在设计时采用多进程多线程体系结构,其特点是实时性强、可靠性高、数据量大、接口关系复杂［3］。通常,中心计算机软件设计人员对研制的测控软件系统不仅要完成软件功能测试,且要进行性能测试,尤其是对软件的实时性、资源占用率等性能进行必要测试,以确定所研制的测控软件系统能否满足设计任务书的性能指标要求。其次, 在飞行器试验任务中,软件编程人员和试验指挥人员要实时掌握中心计算机系统的工作情况,包括硬件和软件的工作状态,若无实时监测手段,便不能及时了解程序的运行情况。另外,中心计算机实时测控软件是自研软件,经常需要根据不同任务需求进行适应性修改,所做的维护工作需要监测手段来确认其正确性,靠大量的测控系统联试来验证维护工作是否正确,必然要消耗大量的时间、人力和物力,且不可能做到精细。 因此,需要设计一个通用高效、直观可靠的监测软件, 对中心计算机系统进行性能监测。
通常,系统性能监测包括硬件资源、软件资源、软件运行状态和效率监测等。因此,针对中心计算机系统的性能监测内容应包括: 内存、I/O端口、网络接口等硬件监测,以及CPU使用率、系统资源使用情况、多人合作联机静态监测,实时测控软件进程和线程模块运行效率和运行状态监测等。
以上监测内容按照功能划分为通用监测和专用监测两部分,其中通用监测包括: ( 1) 多用户静态监测。 ( 2) CPU运行效率监测。( 3) Threads资源监测。( 4) 存储器、I/O端口、网络监测。
专用监测包括: ( 1) 测控软件实时性定量测试。 ( 2) 系统运行状态测试。
2 监测功能实现方法
2. 1 集成通用监测环境
对于通用性能的监测,目前有较多的商品化监测软件可供选用,可根据测控软件的需要集成到中心计算机系统中,构造成一个适用的通用监测环境,用来支持对硬件和应用软件进行的测试。该环境包括以下软件包:
( 1 ) Prestoserve I/O Accelerator、Profiler、Heap Analyzer、Porting Assistant等软件包实现对中心计算机硬件资源的监测。
( 2) 多用户静态监测包Source Insight。其能用于多用户源代码设计,能在多台仿真终端上多人合作进行源程序静态检测,用来完成对测控软件系统的所有进程和线程源程序的静态检查。其为测控软件系统多人进行合作开发提供了高效的静态监测工具。
( 3) 运行效率动态监测包CPU View。主要功能是以可视化方法实现应用软件的CPU使用效率的监测［4］。该软件可在中心计算机系统控制台上运行,也可在仿真终端上操作运行。使用CPU View能够动态监测中心计算机测控软件系统占用的CPU时间。通过这种测试可粗略监测系统的机时开销是否满足任务书的总体设计指标。
( 4) 资源开销监测包Visual Threads。其能够对多进程多线程占用的操作系统资源,如消息队列、信号灯、条件变量锁、实时调度策略、调度优先级、系统事件、时钟、存储开销等进行动态监测。中心计算机测控软件系统资源的开销情况可用其进行监测。
2. 2 专用监测实现方法
专用监测需要完成对测控软件系统在进程和线程模块级的实时性和功能性的精确度量,该技术有利于软件设计人员对软件各模块功能和性能进行的分析与改进,并可有效预防由于软件错误导致测控失利。
本文在不影响测控软件性能的情况下,采用“软件模块嵌入”技术,将所开发的监测功能程序嵌入到中心计算机测控软件系统中,实现了对中心计算机测控软件系统进程和线程模块级时间开销的测试。另外,采用特征提取技术设计出“监测模型”,实现了对中心计算机实时测控软件系统运行状态的可视化监测。
2. 2. 1 实时性测试软件模块嵌入技术
采用测试软件模块嵌入技术实现各模块系统实时性的定量测试需考虑两个关键因素: ( 1) 嵌入的软件不能影响系统的实时性,要考虑运行效率。( 2) 软件嵌入的位置恰当,才能保证测试结果的可信度。
基于以上因素,考虑到线程每个周期的运行时间不均匀,需要通过统计得到平均值,作为线程平均周期消耗时间。因此,提出了一种基于统计原理的时间开销测试方法。
该方法的基本原理是: 在外时统的配合下,在中心计算机各进程的线程入口记录时间,在线程出口上设置线程状态记录程序,统计每个时间周期内各线程执行消耗时间和线程结束的原因,计算出平均时间和任务完成率。从而判断进程线程模块级动态运行效率。
通过这种方法完成中心计算机测控软件系统的实时性测试,测得的结果与设计指标相比较,便可得到测控软件实时性是否满足任务书要求的结论。
2. 2. 2 监测模型设计
在测控软件调试、维护以及在飞行器试验过程中, 需要对中心计算机测控软件系统的工作状态进行实时监测,这对于中心计算机系统岗位的软件开发人员和操作人员较为重要。
为达到对系统运行状态的有效跟踪、报警和预测, 增强信息表达效果,应在系统运行时进行直观的可视化监测［5］。要监测到中心计算机测控软件内部模块的运行状态,可对其中的软部件运行过程进行特征抽取, 采用模型化方法,构造抽象的监测模型。基于这种抽象的模型设计监测软件,通过该软件实现对测控软件系统运行状况的监测。
监测模型的设计原理是根据测控软件模块结构化设计特点,统一将部件体划分成若干监测单元,每种监测单元被定义了状态,状态反映了单元的运行结果,定义数据对象表示监测单元状态值,监测单元的状态信息被存储在测控软件系统的共享区中。
数据对象模型定义及含义说明形式如下:
该对象模型用来获取和存储软部件的状态,由监测单元相关的部件体根据各自运行情况送出状态值,状态发生变换时及时更新。中心计算机任一作业启动后就开始形成状态数据,直到作业结束时为止。其中读写锁在进程初始化时初始化为PTHREAD _ RWLOCK _ INITIALIZER,通过控制本对象的rwlock读写锁,实现各部件读写同步,避免破坏对象中的状态信息。status的值由本结构对象的写入者根据情况设置。JCi( i =1,2, …,5) /XCi( i =6,7,…,24) 的取值含义由表1 定义。
中心计算机测控软件中的监测数据接口程序,将上述模型数据对象实时发送到监管工作站上,并由实时过程监测软件接收和处理,同时在屏幕上以可视化的方式将其显示。各监测单元被模型化为如图1 所示的形式。
图1 中各框表示部件的状态,根据数据对象模型中的状态值,定义不同色彩显示监测单元的状态。通过监测状态的变化,能够得知中心计算机测控软件系统中的进程和线程模块的运行状况。图2 为采用监测模型建立的中心计算机实时测控软件运行状态可视化监测画面。由图可知,通过这种监测模型化方法,能够及时了解软部件的运行状况,迅速判断软件故障的位置。
3 结束语
为探索实时测控软件系统实时性测试途径和方法,对多进程多线程并发运行性能测试的问题进行了深入的研究,研制出多进程多线程时间开销测试的软件,并利用外时统和借助中心计算机实时测控软件的操作控制机制,实现了中心计算机测控软件系统实时性的定量测试。通过构造进程/线程监测模型的方法, 实现了中心计算机实时测控软件运行状态的实时监测。有效地解决了实时测控软件系统测试和运行状态监测的问题。
摘要：针对中心计算机实时测控软件系统实时性和可靠性的要求,分析了其系统性能监测软件的设计需求。通过设计通用监测环境和研究多进程多线程模块级专用监测方法,实现了对多进程、多线程、高并发系统实时性的定量测试,以及对中心计算机实时测控软件系统运行状态的可视化监测。实际应用证明,建立的实时监测软件系统能满足中心计算机系统性能实时监测需求,同时也为保证系统的可靠运行提供了工具支持。
实时性能 篇7
1 常规性能分析
在以前的常规性能研究中, 人们倾向于对DCF方式竞争机制的探讨来进行建模分析, 来获取在饱和状态时, 其最大的吞吐量以及终端所发送数据帧的碰撞频率。对于实时业务性能, 数据帧的传输延迟和丢失才是问题的关键。虽然有研究证明信道访问延迟MAC竞争是关键, 但其研究背景是假设终端具有相同的MAC参数, 有条件限制, 研究结果并不明确。也有数据显示, 终端所发送的业务性能受MAC参数影响, 且性能受参数影响波动较大, 具体数据概念模糊。说明原有方法在研究过程中有其弊端, 无法分析不同类型终端共存时的业务性能, 而具有不同MAC协议参数和多终端无线局域网的应用已然成为关注的热点, 急需着性能研究的新突破。
2 成熟模式分析
IEEE802.11网络通常是由基本服务集BSS (Basic service set) 所构成。IEEE802.11标准提出以下两种MAC层接方式来满足不同应用, 一种是分布式协调模式DCF (distribute coordination function) , 一种是点协调模式PCF (point coordination function) 。IEEE802.1标准的DCF模式下, 多个网络节点共享无线媒介, 所建立的模型能够准确地衡定给定网络状态下的媒介服务时间。在PCF模式下, 引入协作通信机制, 能够在一定条件下提高系统吞吐量, 改善系统性能。无线局域网的基本访问方法是DCF, DCF采用载频侦听多址访问、碰撞回避 (CSMA/CA) 机制接入信道。无线局域网中的每个站点都必须实现DCF。PCF只能用于基础网络结构。两者提供的服务类型不同。DCF方式使用RTS (request t seed) 和CTS (clear to send) 消息来预留信道, 但其存在发送延迟的弊端。PCF在竞争周期中对特定终端业务的占用以及对实时业务服务质量的保证都由于DCF, 体现在其对CFP (contention free period) 的引入。但从另一方面讲, 因为PCF的操作复杂, 在数据业务中支持不佳, 应用不多。现代局域网主要研究在无线网中被广泛应用的DCF模式, 从其实时业务的性能入手。
3 关于DCF
在IEEE802.11标准下的DCF模式, 主要采用具有冲突检测的载波帧听多路访问方法提供访问方式, 利用竞争窗口的二进制指数回退机制协调多个终端对共享链路的访问, 减少竞争信道中无法通信的状态。具体操作为:终端数据发送后, 等待信道空闲DIFS (DCF interframe space) 断过后启动回退窗口计数器, 它的初始值为[0, w-1]之间的任意数。经过一个空闲时隙, 计数器自动减1。当计数器数据为0时终端发送数据就是在信道上;接受端如正确接受数字, 直接发送下一个数据帧。当两个终端计数同时为0, 则重新开始一次竞争回退过程, 这时初始值改变为[0, 2W-1]之间的随机值, W为上次计数初始值。重传数据在达到最大重传数据后还碰撞, 为废用帧, 直接发送下一个。另外, 为避免信道被某终端长时间占用, 在两次连续的数据分组发送之间也必须进行随机延迟。
综上所述, 本文通过资料的整合, 对在信道饱和状态时, IEEE802.11下两种标准模式下DCF和PCF的市场及利弊和对以DFC为主模式的具体操作进行分析。为了保证业务的质量, 扩大网络的容量, 分析模式旨在探讨无线区域网中实时业务性能的有效方法, 保持实时业务上满意的延迟性。此小结在一定程度上反映出MAC与业务性能的关系, 确保了无线局域网中实时业务的容量和提供服务的质量, 在多终端无线局域网研究中具有一定价值。
参考文献
[1]李超杰.基于网络感知的可用宽带评估机制研究[J].电视技术, 2011 (13) .
[2]陈昊成.基于网络计算的资源管理与分配系统的设计与实现[D].哈尔滨工业大学, 2010.
实时性能 篇8
随着互联网技术的发展, 用户对Web服务器的可靠性要求越来越高。使用Web服务器负载均衡集群应对集中并发访问, 确保网络应用的服务质量, 得到了越来越广泛的应用。负载均衡集群所使用的负载均衡调度算法, 是影响集群系统性能的关键。算法必须能够确保集群中各服务器负载分摊合理, 集群的对外响应时间相对较短[1]。本文对常用负载均衡算法进行了分析, 并基于动态负载均衡技术, 提出了算法的改进。
1 常用负载均衡算法
1.1 静态负载均衡算法
静态负载均衡算法是依照事先确定的策略, 来实现用户连接分配的负载均衡技术。常用的静态负载均衡算法有简单轮询负载均衡算法和加权轮询负载均衡算法两种[2]。
简单轮询负载均衡算法, 假定后台服务器具备同样的性能且均处于正常在线状态, 依次将用户连接请求分发到各后台服务器, 实现的是一种无状态的调度。这种算法虽然实现起来简单, 但是其实现的前提, 制约了该算法的使用范围。
加权轮询负载均衡算法以顺序的方式, 按照“事先被设定的表示服务器性能的权重比例”, 来进行用户连接请求的分发。这种算法, 考虑了集群中不同服务器性能的差异, 克服了简单轮询负载均衡算法的不足。
但是, 上述两种调度算法均没有考虑到实际运行过程中各服务器的实际负载情况。由于不同的用户连接所要求的数据处理任务的运行时间存在差异, 必然会导致运行一段时间后各服务器的实际性能状态和启动之初相比有明显的变化。因此静态负载均衡算法不能很好地实现服务器集群系统的负载均衡。
1.2 动态负载均衡算法
动态负载均衡算法, 即根据对后台服务器实时运行情况的收集和分析, 把用户连接请求均匀地分配至各具体服务器的算法。常用的动态负载均衡算法有最小连接负载均衡算法及加权最小连接负载均衡算法两种[3]。
最小连接负载均衡算法, 简单的将新的用户连接请求发送到当前连接进程最少的服务器, 该算法没有考虑到服务器之间性能的差异。
加权最小连接负载均衡算法, 弥补了最小连接负载均衡算法的不足。算法为每一台服务器赋予了一个代表其性能的权重值, 均衡调度器将新用户连接始终分配给“服务器连接数除其权重值所得数值最小”的那台服务器。
实验表明, 通常情况下, 动态负载均衡较静态负载均衡有30%~40%的性能提高[4]。但最常用的加权最小连接负载均衡方法也存在一些不足。因为即便是同样的用户连接, 要在服务器上所执行的数据处理任务所消耗的系统资源也是不同的。即便是负载均衡调度到各后台服务器上的连接数是均衡的, 随着时间的推移, 各服务器的性能状态肯定产生差距。因此说加权最小连接负载均衡方法依然不能很好地解决服务器间的负载均衡问题。
因此, 本文提出一种基于服务器实时性能状态的动态负载均衡调度算法, 使负载调度系统能及时读取到服务器集群中各服务器的负载量及服务器实时性能情况, 并根据数据的变化作出任务分发方案调整。
2 基于服务器实时性能状态的动态负载均衡算法
2.1 运行原理
基于服务器的实时性能状态和对连接请求的响应情况, 负载均衡调度器动态地调整负载的分配, 避免服务器在过载时候仍然被分配较多的连接请求, 从而提升整个服务器集群系统的稳定性和数据处理能力。
2.2 服务器实时性能状态指标选取
CPU、内存、硬盘及网络这四个方面的性能决定服务器的整体数据处理性能, 因此CPU主频、CPU利用率、逻辑CPU个数;内存大小及内存使用率;磁盘平均读写速率;平均网络速度可作为服务器实时性能的衡量指标。
2.3 服务器实时性能的计算
假定服务器集群中存在n台服务器, S1, S2, S3……Sn;第i台服务器的CPU主频与逻辑CPU个数的乘积用Ci表示;内存大小用Mi表示;磁盘平均读写速率用Di 表示, 平均网络速度用Ni表示。
第一步, 分别取服务器集群中四个性能指标的最大值, 计算方法如表1所示
第二步, 将服务器集群中, 每个服务器相应的性能指标除以服务器集群中相应性能指标的最大值, 得到一个介于0到1之间的性能比值, 计算方法如表2所示
第三步, 根据服务器四个性能指标对服务器整体数据处理性能的影响程度, 为每个服务器的性能比值赋予一个用于进行加权平均的系数Q1, Q2, Q3, Q4。
要求Q1, Q2, Q3, Q4均大于0小于1, 且0< (Q1+Q2+Q3+Q4) <1。
据此, 我们得到每个服务器性能指标XPi的具体计算公式
XPi = (Q1* CPi + Q2* MPi + Q3* DPi + Q4* NPi) /4
具体的Q1, Q2, Q3, Q4设置方案, 系统管理员可以根据服务器所运行的实际任务的类型, 进行确定。
第四步, 计算每个服务器的具体负载
假定每个服务器的CPU利用率、内存使用率、磁盘读写速度使用率及网络带宽使用率分别用CUi, MUi, DUi, NUi表示, 则第i台服务器在任意时刻的综合负载均衡Ti可表示为:
Ti = (Q1* CPi *CUi + Q2* MPi* MUi + Q3* DPi * DUi + Q4*NPi*NUi) /4
第五步, 每个服务器权重值的计算
每服务器的总体性能减去实时负载, 即为相应服务器的剩余数据处理性能。每服务器的剩余性能占服务器集群所有服务器剩余性能之和的比例, 即为相应服务器在服务器集群中的权重。
第i台服务器权重Wi 计算公示如下
2.4 调度策略
调度器依据业务服务器的实时性能及服务器权重, 优先将新连接转发至集群中当前权重最高的服务器上。
3 性能验证及分析
将上文所述负载均衡调度算法, 在某高校教务系统网上选课过程中进行测试。测试服务器集群中有实际数据处理服务器5台, 其中CPU为至强E3服务器1台、CPU为鹅服务器3台、CPU为至强E7服务器1台, 内存均为16G。将基于服务器实时性能状态的动态负载均衡算法 (简称:新算法) 和加权最小连接负载均衡算法 (简称:原算法) 进行比对。
从测试数据分析来看, 基于服务器实时性能状态的动态负载均衡算法有效地降低了系统延时。在连接数比较小的时候, 基于服务器实时性能状态的动态负载均衡算法优势并不明显, 但是随着连接数的增大, 与加权最小连接负载均衡方法相比, 效果较为明显。
4 结语
本文分析了常用负载均衡算法的不足, 提出了一种基于服务器实时性能状态的调度算法。实验结果显示, 新算法能够切实提高服务器集群的综合性能。
参考文献
[1]Rakumar B.High Performance Cluster Computing Architectures and System[M].:Prentice Hall, 2000.
[2]胡子昂, 王立.算法、网络拓扑及调度频率与动态负载平衡的关系[J].计算机工程与科学, 2000, 22 (1) :104-107.
[3]陆静波, 陈志刚.一种LVS服务器权值的动态调节方案[J].计算机工程, 2006, 32 (14) :104-106.
实时性能 篇9
文献[1]给出了一种优化调度模型,建立了资源提供方和用户之间的“交易”,以满足用户用尽可能低的费用进行计算任务的最低要求;文献[2]采用了一种基于Class Ad匹配的集中式方案,以形成资源调度器;文献[3]提出了一个高度结构化的可扩展的调度方案。但该方案考虑的不够周全,比如没有从网格服务的角度去考虑。文献[4,5,6]提出了一种基于遗传算法的调度算法,改进了传统的遗传算法,该算法的收敛性好,同时也提高了资源选择的效率,由于未考虑到网格的动态性,从而无法保障工作流的顺利执行。文献[7]首先定义了应用程序优先级,采用优先级调度算法使得优先级较高的应用程序能够被优先调度和运行,但它不能实时的获取资源的信息,不能保证工作流执行的健壮性。
本文提出了一种基于性能驱动的实时调度方法。调度器接收到用户的请求后,通过实时获取各资源结点的性能信息,为每个任务选择一个最佳的服务资源,整体上缩短了工作流的执行时间,提高了系统的吞吐量,在一定程度上保证了工作流执行的健壮性。
1 基于性能驱动的调度模型
1.1 工作流调度系统模型
文中的网格系统是建立在OGSA(Open Grid System Architecture)基础上的多层结构的网格服务工作流管理系统。在系统中,将“工作流”理解为一个规则集,这些规则定义了服务之间的交互作用及次序,这样工作流的业务处理就可以分解成一个个的服务,整个业务的完成过程,就形成了一系列的服务请求与满足的过程,工作流变成了一种服务流,这种方式正好与以“服务”为中心的OG-SA架构相吻合[8]。工作流系统结构图如图1所示。
1.2 资源实时性能值的获取
服务网格环境中服务资源隶属于某个资源结点,因而结点的性能在很大程度上决定了服务资源的服务质量,比如服务执行时间的长短,服务执行结果的正确与错误等。
一方面,结点的性能越高,其包含的服务资源的性能也越高,表现在执行时间越短,执行结果越准确,执行错误率越来越低。相反,性能差的结点,其上的服务资源的执行时间较长,服务在执行过程中发生错误的概率更大。另一方面,结点的性能又是动态变化的,当它的负载达到一定程度时,它的性能就会变得很差,如果再把过多的任务分配给它,就容易造成负载过重,导致服务的执行失败。对于调度器来说,它不再是最佳的选择,而一些性能稍差但负载很低的资源结点则可作为最佳的选择。
要做到每次调度都可以选到最佳的服务,就要获取资源的实时信息。决定一个结点的性能优劣主要表现在两个参数上,CPU的空闲率和网络速度。CPU空闲率越高,则表明用户可以使用的CPU资源越多;网络的延迟对于网格服务工作流的执行也有一定的影响,因为在某些服务之间存在着数据约束,彼此需要传输大量的数据,网络的优劣直接影响到数据的传输时间。
因此本文选择了CPU空闲率和网络负载来反映资源的实时性能。但在实际情况中经常会出现下列情况:
资源结点X:CPU空闲率是0.7,而网络负载是0.4
资源结点Y:CPU空闲率是0.8,而网络负载是0.3
资源结点Z:CPU空闲率是0.5,而网络负载是0.1
调度器在为当前任务请求选择服务资源时,该作出怎样的选择,作出的选择能否顾及到系统的负载,达到一种最佳选择?为此本文通过公式(1)来体现资源目前的性能。
其中CPUfree表示CPU空闲率;NETload则代表了该网络的负载。ρ代表了权重,是一个经验值(通过实验来获得)。可以看到,P重要考虑了系统负载均衡,在选择资源时选择总体负载较轻的作为资源。回顾一下上面的问题,可以得到(假定ρ取0.7),对于资源X,其性能值P(X)=0.67;对于资源Y,其性能值P(Y)=0.65;对于资源Z,其性能值P(Z)=0.38。因此,调度器会把当前的请求分配给资源结点X。
2 实验验证
2.1 实验环境
实验在真实的网格环境下进行测试。1个主机作为调度结点,8个性能不同的主机作为资源结点,并且每个结点上都部署了分词服务、人名识别服务、地名识别服务、机构名识别服务和词性标注服务。
其中,结点213,222,223,224,225的CPU频率为P4 3.0GHz,内存为512MB;结点235的CPU频率为P4 1.4GHz,内存为128MB;node237的CPU频率为Celeron 801MHz,内存为256MB;node238的CPU频率为P4 2.0GHz,内存为128MB。
2.2 实验方案及结果
为了验证ρ在不同取值情况下,调度性能的优劣。根据ρ的不同取值,进行了9组实验,每组实验运行10次,每次提交工作流任务4个,每个工作流包含成员服务5个。
2.2.1 工作流执行时间和错误发生次数的比较
在真实环境中,ρ的不同取值代表了CPUfree和NETload在获取P值时所占的比值的情况。ρ值越大,表示CPUfree所占的比重越大,是影响P值的主导因素;相反ρ值越小,则表示NETload是影响P值的关键因素。图2是实验获取的数据的分析,分析了ρ值在不同取值下工作流执行时间和错误错误发生次数的比较。
在图2中,X轴代表了ρ的不同取值,左侧的Y轴代表了提交的服务工作流的平均执行时间,右侧Y轴代表了发生错误的次数。随着ρ值的增大,CPUfree逐渐成为影响P值的主导因素,并在ρ取0.7的时候,执行时间和错误个数同时达到最低。
分析原因可知,在局域网环境中,网络相对稳定,因而网络不是影响P值的主导因素,实验数据也证实了这一点,图3中很好了反映了ρ不同取值下各资源结点处理的服务请求数。ρ取值小的时候,各个结点的负载比较均衡,导致一些资源性能差的结点接收到超过自己负荷的任务,使得工作流的总体执行时间提高,同时发生的错误次数也相应增加。
随着ρ值的增大,P值的计算更多的依赖结点的CPUfree,从而任务被更多的分配到资源性能好的结点上,而差的结点仅仅处理了为数不多的任务,从而工作流的执行时间缩短,错误发生次数也相应减少。
当ρ值很大的时候,又会发现执行时间和错误发生次数都逐渐增加,这是因为当ρ值很大的时候,CPUfree决定了P值的大小,工作流在提交之后,任务在开始的时候会大量的分配给资源性能比较好的结点,导致这些结点的负载变得过重,从而导致后续的任务绝大多数分配到一些性能较差的结点,导致执行时间提高。
2.2.2 两种调度策略性能的比较
为了验证调度策略的性能,与随机调度进行了比较。共进行了15组实验,每组实验进行10次,每次提交5个工作流,每个工作流包含5个成员服务。实验数据分析如图4所示。
从图4可以看出,基于性能驱动的实时工作流调度明显优于随机调度策略,工作流的执行时间有明显的缩短。随机调度实际上一种均衡调度,它的特点是最终达到一种系统的均衡负载。在一个资源异构,资源性能本身存在差别的环境中,随机调度表现了比较差的性能。相反,基于性能驱动的实时工作流调度策略则根据资源的实时资源性能来进行资源的选择,让一些好的资源尽可能的发挥作用,同时也可以兼顾一些性能较差的资源结点,使其能够协助好的资源结点来共同完成用户的任务。
同时可以发现,随机调度下工作流的执行时间波动很大,而基于性能驱动的实时调度则表现出了较好的平稳性,这是因为在随机调度算法下错误的发生概率很大,错误发生的次数越多,工作流的执行时间就变得越长。
3 总结与展望
针对服务网格环境中资源的动态性,该文提出了一种基于性能驱动的实时调度方法,经过实验验证,该调度方法一方面提高了工作流的执行时间,减少了工作流在执行时发生错误的次数;另一方面能够充分发挥性能好的资源结点的作用,协调性能相对较差的结点来共同完成任务,在一定程度上提高了系统的整体吞吐量。下一步工作的重点和难点:从用户的Qos以及系统多层次的Qos来考虑网格工作流调度,从而找到一种能够保障工作流安全执行的容错机制。
参考文献
[1]BUYYA R,ABRAMSON D,GIDDY J.An economy driven resource management architecture for a global computational power grid[C]//Int’1 Conf on Parallel and Distributed Processing Techniques and Applications.Las Vegas,2000.
[2]FREY J,TANNENBAUM T,FOSTER I,et al.Condor-G:A computation management agent for multi institutional grids[J].Cluster Comput ing,2002(5):237-246.
[3]CHAPIN S,KARPOVICH J,GRMSHAW A.The Legion resource management system[C]//In 5thWorkshop on Job Scheduling Strategies forParallel Processing.2000.
[4]郭文彩,杨扬.基于遗传算法的网格服务工作流调度的研究[J].计算机应用,2006,26(1):54-56.
[5]王勇,胡春明,杜宗霞.服务质量感知的网格工作流调度[J].软件学报,2006,17(11):2341-2351.
[6]郭文彩,杨扬.一种面向服务的网格工作流调度算法[J].计算机科学,2006,33(6):132-134.
[7]刘洋,桂小林,徐玉文.网格工作流中基于优先级的调度方法研究[J].西安交通大学学报,2006,40(4):411-414.