故障检测软件范文（精选10篇）
故障检测软件 第1篇
软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。出现软件故障时若无适当措施加以及时处理,便产生软件失效。显然,软件故障是一种动态行为。软件开发的各个阶段都需要人的参与。因为人的工作和通信都不可能完美无缺,出现错误是难免的。与此同时,随着计算机所控制的对象的复杂程度不断提高和软件功能的不断增强,软件的规模也在不断增大。例如,Windows NT操作系统的代码大约有3200万行。这使得错误更可能发生。人们在软件的设计阶段所犯的错误是导致软件失效的主要原因。软件复杂性是产生软件缺陷的极其重要的根源。
1 软件基本测试理论与原则
软件测试是保障软件可靠性的重要手段,它贯穿于软件开发的整个过程中。与其说软件测试理论是研究性结果,还不如说软件测试理论是一些实践中总结的工程性原则。
1.1 软件测试的基本理论
1)软件缺陷是不可避免的。
2)软件测试是不完全的,即通过软件测试不可能发现所有的软件缺陷。
3)软件测试具有免疫性,即伴随着软件测试的进行,发现软件缺陷会越来越困难,这内在的要求了测试方法的多样性。
4)软件测试是全程的,即软件测试贯穿于整个软件开发过程。
5)软件测试中的社会学理论:80-20原则。如:“80%的软件缺陷常常生存在软件20%的空间里。”,这样的数值规律广泛的存在于软件测试中。
1.2 软件测试的一些工程性原则
最有代表性的就是Myers软件测试十大原则:
1)程序员应避免测试自己编制的程序。
2)测试用例的设计必须包括预期的输出结果。
3)测试用例应包括有效的和期望的输入情况,也要包括无效的和不期望的输入情况。
4)彻底检查每个测试结果。
5)只检查程序是否做了它应该做的事仅仅完成了测试工作的一半,另一半则是要检查程序是否做了它不该做的事。
6)避免不可重复的即兴测试,保留全部测试用例。
7)一段程序中存在错误的概率与在这段程序中已发现的错误数成正比。
8)测试是一项非常复杂、创造性的和需要高度智慧的挑战性任务。
9)不要为了便于测试擅自修改程序。
10)测试工作必须有明确的目标。
2 软件故障检测
软件故障检测是软件故障诊断的前提,只有当检测出软件出现故障后才能进行故障定位工作。软件故障检测是指采集软件系统运行参数,获取系统状态信息,从系统可测量或不可测量变量的估计中,判断被诊断系统是否发生了故障。软件故障检测是通过研究故障与其症状之间的关系来判断被检测软件的状态。由于软件的复杂性以及故障证据可能是模棱两可的、不一致的和不完全的,故障与征兆之间的关系很难用精确的数学模型来表示。现有的软件故障检测主要采用测试、形式化验证及运行时验证等技术手段。
2.1 测试
软件测试是为了发现程序中的错误而执行程序的过程,通过定义各种测试充分性,可以提高我们对被测软件质量的信心,但无法回答系统一定没有错误这样一类问题,因而无法从根本上确保系统的可靠性。传统的测试作为软件开发的一个必要组成部分,一般包括单元测试与集成测试,主要用于软件开发阶段的错误发现,属于一种静态的检测方式。与程序切片形式化验证等技术相结合的测试手段现在得到了较好的应用。
2.2 形式化验证
形式化验证则通过基于数学的形式化方法,揭示系统的不一致性、歧义性和不完备性,可以从某一个角度回答系统一定没有错误这样一类问题,提高我们对系统可靠性的信心,往往被应用于一些关键领域的软件系统。由于其验证对象一般为系统的模型,所以形式化验证一般也属于一种静态检测技术。文献提出利用定理证明的手段来保证软件产品可靠性和正确性。定理证明以逻辑推理为基础,根据公理和形式推演规则来验证设计实现是否满足要求,由于需要人工干预,能处理的软件规模较小。Clarke EM等率先将模型验证技术引入软件故障诊断领域,用某种形式化方法说明系统应拥有的性质和应满足的属性,通过对模型进行检测,判断软件系统是否拥有这些期望的属性。软件模型验证技术可以分为对系统说明(需求分析)的模型检测和针对源代码的模型检测。针对于不同的应用己经开发出来了一些较为成熟的软件模型检测工具,其中比较典型的有加州大学伯克利分校的BLAST系统和MOPS原型系统、卡内基梅隆大学开发的MAGIC系统、美国国家航空航天局开发的JPF、微软的SLAM和Zing项目。
2.3 运行时验证
鉴于现代分布式软件系统具有松散聚合及开放动态等特性,以及软件故障除了由软件本身的错误和缺陷造成外,也可能由运行环境所导致,因此不仅需关注开发期的静态检测,还需注重运行期的在线检测。运行时验证简单地说可以看作软件测试和形式化方法的结合,它是一种保证程序可靠性的轻量化方法,其基本思想是收集软件运行中的相关信息并与软件需求规约进行比照,如不满足预定义的相关需求,则提示检测到故障;或者在软件中设定一些阀值,当软件运行过程中超过阀值设定的范围时,则提示检测到故障。目前的运行时验证技术主要有基于AOP的技术、基于截获器的技术、基于构件包装器的技术及基于框架的技术四种。其中基于框架的技术是目前的热点研究领域,如Monitoring-oriented programming(Mo P)、Javwith Assertions(Jass)、Java Path Explorer(JPa X)、Java Run-tim Timing-constraint Monitor(JRTM)、基于程序运行形式化分析的软件故障监控模型等框架。
3 软件故障定位
故障定位是软件故障诊断中的关键问题,它的难点是如何在大量的相关故障事件中找到故障源。国内外学者针对故障定位问题,进行了深入的研究,提出了很多行之有效的理论和方法,它们都来源于计算机科学的不同领域,包括人工智能、图形理论等。故障定位技术一般归为三类。第一类是基于人工智能的技术,包括专家系统、神经网络、决策树。专家系统又可以细分为基于规则的系统、基于模型的系统和基于范例的系统。第二类是模式穿越技术。这种技术使用形式化的方法描述分布系统实体之间的关系。故障会依照这种关系在实体间传播,通过探测这些关系,从发生故障的实体开始回溯,即可找到其它相关故障的实体和原因实体。第三类是故障传播模型。这种模型企图在故障之间建立一种因果关系,通过这种因果关系,根据现象和传播模型推测故障原因,也可以用这种模型来预测故障的发生,故障传播模型包括贝叶斯网络、因果关系图和依赖关系图等。在软件故障定位领域目前得到应用的的主要技术是基于模型的定位技术、模式穿越技术等。
当软件发生故障时,需要进行故障定位,深入代码的内部找出故障模块和故障代码。在软件故障定位中一般根据是否需要系统内部结构及行为知识分为白盒技术和黑盒技术[2]。白盒技术需要系统内部构件结构及行为知识,基于模型的故障定位技术是一种典型的白盒技术。在基于模型的定位推理中,它建立系统的形式化模型,从运行时监测器获得运行信息,通过逻辑推理定位故障源。模型反映了实际系统的结构和行为,由于基于模型的方法能够反映系统底层的详细细节,因此这种方法可以用来解决一些新出现的故障;它的诊断知识可以被组织成可扩展的形式,而且容易升级和模块化。不过,由于模型的知识难以获得,这种诊断需要详细的系统底层知识,对于不同的目标系统,它们的模型基本都不相同;同时由于软件系统规模越来越庞大、复杂,系统模型也变得十分复杂,模型的维护将更加困难。易昭湘等提出的基于代码检测的软件故障定位方法也属于白盒定位技术,获取软件发生故障时的模块运行序列,分析出软件故障可疑模块集,在此基础上对故障模块进行代码的分类检测[3]。
黑盒定位技术由于不需要系统内部构件结构及行为知识,得到了更加广泛的应用。基于程序谱的定位技术是一种重要的黑盒技术。基于程序谱的故障定位一般不依赖于输入结构知识,而依赖于程序中能够和源码某个位置关联的程序执行特征,这些特征的整体可被称为程序谱。程序谱特征化程序行为、或者提供了程序行为的信号,如路径谱、分枝谱等,它可为故障定位提供重要知识。Tarantual和AMPLE都是利用程序谱来进行故障定位。黑盒定位中用到的技术还包括动态程序切片技术及近邻模型技术等。
4 软件故障检测技术的发展趋势
4.1 软件的易测试性设计
Voas将软件的易测试性定义为一定测试策略迫使软件中存在的故障被暴露的概率[4]。软件的易测试性包括可观察、可控制、可理解等几个方面[5]。软件易测试性设计即是在软件的设计和编码中考虑测试问题,它借鉴了硬件易测试性设计的思想。软件易测试性设计的目的是在不增加或者少增加软件复杂性的基础上,将易于测试的原则融合到设计和编码之中[6]。软件易测试性设计符合软件测试的一个原则:尽早开始软件测试工作,不断进行软件测试工作。软件易测试性设计体现软件测试的如下观点:软件产品的质量是生产(包括分析、设计、编码、测试)出来的,而不是仅仅依靠软件测试来保障。软件易测试性设计也体现了软件测试的一个发展趋势:向软件开发的前期发展,与软件开发的设计和编码阶段相融合。
4.2 构件测试
当前社会的信息化过程对软件的开发方法与生产能力提出了新的要求,软件复用是提高软件产品质量与生产效率的关键技术。软件构件概念的提出为软件复用提供了技术基础[7]。构件的高可靠性是构件能被成功复用的前提。构件测试是保障和提高构件的可靠性的重要手段。构件的开发者和复用者必须对构件进行充分的测试,以确保它在新的环境中工作正常。国际上于20世纪90年代后期对构件测试开展了研究[8]。构件测试成为当前软件工程学术界和工业界的热点问题之一。
构件测试一个重要的发展方向是基于合约的构件易测试性设计。合约可以在运行时被检查,便于捕获构件执行过程中的一些故障,提高构件的易测试性。因此,基于合约的构件易测试性设计不仅为构件开发者开发高质量的构件提供帮助,而且在构件开发者与复用者之间架起一座桥梁,为构件复用者的测试提供支持,也为构件开发者捕获错误提供便利,便于区分构件开发者与复用者的责任。如果众多的构件开发者都采用合约式设计方法生产构件,那么失效时很容易定位到构件和其中的方法。为使基于合约的构件易测试性设计方法能够实用,需要研究解决以下问题:构件合约的描述、表达,构件中合约的获取,对构件合约的自动检查,以及针对构件合约的软件测试。
4.3 Web Services测试
随着软件产业模式从以产品为中心的制造业转变为以客户为中心的服务业,WWW从2层体系转变为3层体系,B2B从复杂专用的连接转变为简单通用的连接,分布计算中间件从Intranet扩展到Internet,CORBA、COM及EJB等中间件技术已不能适应这些发展需求,因而导致了新型中间件技术Web Services的产生[9]。
当前,Web Services越来越受到人们的关注,它使用了包括SOAP、WSDL和UDDI在内的标准协议。这些标准协议体现了互操作性,并用于应用的开发及运行时Web Services的选择和调用。Web Services的测试和评估对服务提供者和服务使用者来说都是相当重要的。Web Services的测试相当于黑盒测试,可以获得规约,却不能得到设计或源代码。文献[10]从输入和输出的依赖关系、调用顺序、层次功能描述和并发顺序规范四个方面对WSDL进行了扩展,提高了Web Services的易测试性,并提出了一个支持测试执行和测试脚本管理的测试框架。
5 结束语
软件测试是一项费时、费力并且单调乏味的活动,测试人员需要设计、执行、分析大量的测试用例。软件测试的自动化将有效地减轻测试人员的劳动强度,提高测试的效率和质量,从而节省软件开发的成本,提高软件的质量。随着软件技术的不断向前发展,构件、Web Services等新技术的应用为软件测试带来新的问题和挑战,也为软件测试的发展带来新的机遇。软件测试技术自身的不断发展对软件开发方法学将产生重要影响。
在今后的工作中,我们将进一步深入研究软件故障的特点和软件故障诊断技术,并且应用于软件故障诊断实践。
摘要：软件在国民经济和社会生活中发挥着重要作用。软件出现故障给人们的工作、生活带来不便,甚至造成严重危害。文中简要介绍了软件基本测试理论与原则,讨论了软件故障检测和定位中所采用的方法及相应的过程,对软件故障检测技术的发展趋势进行了探讨。
关键词：软件故障,故障检测,故障定位,检测技术
参考文献
[1]单锦辉,徐克俊.软件故障诊断探讨[J].北京化工大学学报,2007,34(SI):5-8.
[2]Zoeteweij P,Abreu R,Van Gemund A J C.Software Fault Diagnosis[C].Tallinn,Estonia:19th IFIP International Conference on Testing ofCommunicating Systems,2007.
[3]易昭湘,慕晓冬,赵鹏,等.基于代码检测的软件故障定位方法[J].计算机工程,2007,33(12),82-83.
[4]Voas J M.Software Testability Measurement for Assertion Placement and Fault Localization[C]//Saint-Malo:Proceedings of the Automat-ed and Algorithmic Debugging1995:133-144.
[5]Martins E,Toyota C M,Yanagawa R L.Constructing Self-Testable Software Components[C]//Goteborg:Proceedings of the InternationalConference on Dependable Systems and Networks,2001:151-160.
[6]宫云战,刘海燕,万琳,等.软件测试性的分析与设计技术研究[C].北京:2000年全国测试学术会议(CTC'2000),2000:271-274.
[7]杨芙清,王千祥,梅宏,等.基于复用的软件生产技术[J].中国科学(E辑),2001,31(4):363-371.
[8]Voas J M.Certifying Off-the-shelf Software Components[J].IEEE Computer,1998,31(6):53-59.
[9]杨芙清,梅宏,吕建,等.浅论软件技术发展[J].电子学报,2002,30(12A):1901-1906.
软件安全故障的真正根源 第2篇
当然，我不会像“OWASP Top 10”（OWASP：开放式web应用程序安全项目）那样做一个具体的列表来告诉你答案，因为在我看来，安全问题的发生最主要来源于两大方面：一是软件开发人员过于专注软件的功能规格，另一个则是过于信任软件的安全系数。
我遇见过的软件开发人员大多数都很聪明、很上进，而他们总是在压力极大的环境下工作，总是在看似不可能完工的最后期限内将产品做出来。在这样的情况下，开发人员往往只关注产品的功能，而对其他方面，比如安全，则欠缺考虑。因为“客户需要什么样的功能”的问题显然比“哪里可能出岔子”或“攻击者如何诱骗软件出现异常行为”来得更为迫切。
另一方面，开发人员普遍低估了软件隐藏的安全威胁。因为开发人员往往过于信任用户及用户在代码中所使用的应用编程接口（API）。
一旦开发人员一味注重开发功能，而不事先做足准备来防止潜在攻击，那么软件经常出现故障，也是理所当然的事了。
当然，功能的开发也相当重要，但是防止代码出现异常的准备是必不可少的。然而，做好这点并非易事。
两件事情或许对于做好这点有所帮助。首先，积极主动地通过应用软件对数据进行编排处理。前期要严格验证数据的输入，后期则要确保数据的输出不会给预期环境造成任何破坏。第二，预测异常情况，并采取合理的处理措施。只要有可能，就要积极验证所有输入的数据。比如，如果你要求的数据是整数，那么不是整数的任何数字都将是危险的，这被称为积极验证；有别于消极验证，消极验证是指通过寻找已知的危险的输入内容，并阻止那些内容输入。但我建议最好避免采用消极验证，因为我已看到过无数个消极验证失败的例子。
接下来，在输出数据时，你需要编排处理该数据，防止数据在你输出时的任何地方引起问题。比如，要是输出上下文是XML格式化的，那么你的用户数据绝对不能含有“<”或“>”之类的元素。倘若没有做到这一点，每次输入都会受到攻击。
对于专业人员来说，软件就好比是小孩，安全人员则是第一看护人，他们会注意到潜伏的危险，并习惯于最先考虑哪些方面会出岔子；开发人员则更像第二看护人，他们尽量不在交通高峰期带孩子出去散步，尽量避免出岔子。安全人员和开发人员如果能卓有成效地协同工作，大家就能够从中受益。
最近，我与一群软件开发人员进行合作，他们接受了我的这些建议，并且很快便心领神会。事后，我的客户告诉我，在这个项目完工后的一天内，他数次接到了开发人员和安全团队提出的请求，要求探讨两个部门如何能够更好地协同工作。（编译沈建苗）
故障检测软件 第3篇
异步电动机因其结构简单、成本低廉、可靠性高等特点而广泛应用于国民经济各个领域。目前,国内对异步电动机的维护主要采用定期维护或故障后维护,这种维护方式会影响工农业的正常生产,缩短电动机使用寿命,加大生产成本[1]。另外,定期维护时电动机的停止和启动也会增加能量消耗。我们自主研发的电机故障检测管理系统通过对电动机进行在线检测,可实时监测电动机运行状态,采集运行数据进行分析,判断电机故障类型、故障原因和故障严重程度,再根据判断结果来确定电机的维修计划,从而减少了定期维护次数,节省了能源,降低了维修成本,最大限度地避免了临时性故障的发生。
在电机故障检测管理系统中,由于便携性的要求和硬件资源的限制,单单采用下位机并不能很好地存储和处理故障数据,因此开发上位机和下位机之间的通信接口,将一部分功能转移到上位机来实现是很有必要的。本系统下位机采用DSP+MCU的双CPU结构,负责现场数据的采集、处理、判断、显示和上传;采用通用型PC机作为上位机,负责对上传数据的接收、存储和高级管理。上位机和下位机之间还可以交换存储电机铭牌数据。基于这些设计需求,本文设计了电机故障检测管理系统的上位机软件。
1 总体方案设计
串行通信具有连接简单、使用灵活、数据传递可靠等优点,在工业监控、数据采集和实时控制系统中得到了广泛应用。本系统上位机和下位机之间的通信采用RS-232串行通信方式。在通信程序设计时,考虑到通信事件的偶然性和传送的实时性,下位机采用中断和查询的方式,上位机软件在Windows系统下采用事件驱动I/O的方式,以缩短程序的响应时间,提高通信的响应速度。由于本系统涉及到的数据量很大、数据种类很多,因此上位机采用常用的关系型桌面数据库Access来存储数据。Visual Basic作为一种可视化的编程语言,具有开发简便、功能强大、完全可视化编程等优点,本文正是基于VB6.0编程环境开发了上位机软件。本文将从通信协议的制定、串行通信程序的设计、与Access数据库的连接和最终人机界面的开发等几个方面来详细说明电机故障检测管理系统上位机软件的开发流程。
2 通信协议
首先约定本系统通信采用全双工异步串行通信方式,波特率为9 600 bps;一个数据帧包括1位起始位,8位数据位,1位停止位。
在电机故障检测管理统中,下位机需上传的数据包括测量数据、故障检测数据、电机铭牌数据和实时采集的电压电流数据。下位机上传数据前首先发送一个8位数据表明数据类型,然后再依次发送对应数据,其中,若数据为2个字节,则先发低8位,后发高8位。发送的数据格式为:数据类型、数据1、数据2……数据n、累加校验和,如图1所示。
图1 数据的发送格式
数据类型规定为:11H——电机铭牌数据,22H——实时测量数据,33H——电机故障参量,44H——实时采集的电压电流数据。累加校验和规定为双字节数,为数据类型、数据1、数据2……数据n这n+1个字节的算术累加和,用作校验。
下位机发送完数据后,将程序挂起,等待上位机的确认数据。上位机接收到数据后,首先根据前两个字节来判断数据的类型,然后根据所接收到的总字节数来判断是否有丢失字节的情况,最后再根据累加校验和来判断接收到的数据是否正确。若接收正确,则向下位机发送通信成功确认数据0FH,否则发送通信失败确认数据F0H。若下位机收到0FH,则本次通信成功,接着发送下一组数据;若下位机收到F0H,则本次通信失败,重发当前数据。一次数据发送接收流程如图2所示。
上位机需下传的数据只有电机铭牌数据,也采取相似的发送格式和握手信号。
3 上位机软件编程
上位机软件编程主要包括以下三部分工作:串行通信程序的设计、与数据库的连接和人机界面的设计,其中串行通信程序的设计是开发过程中的难点,也是本文所要重点阐述的内容。
3.1 串行通信程序设计
在Visual Basic中,与下位机的串行通信可由三种方法实现:一是使用Win32 API函数,这种方法使用灵活,移植性强,但编程较为困难;二是通过直接读取或写入文件的形式实现对串行口信息的发送与接收,这种方法有很大的局限性,一般不推荐使用;三是使用ActiveX控件,这种方法虽不太灵活,但使用简便,功能较强[2]。本文使用Microsoft提供的专门用于串行通信的ActiveX控件MSComm32.ocx以缩短开发时间。MSComm控件实际上是Win32 API函数的有机集成,它以属性和事件的形式提供了对Windows通信驱动程序的API函数接口,为应用程序提供了通过串行口收发数据的简便方法。
MSComm控件提供了两种处理通信的方式,即事件驱动方式和查询方式[3]。本文采用事件驱动方式以提高通信的实时性。OnComm事件是MSComm控件提供的唯一事件,当有数据到达串行口或串行口状态发生变化或有通信错误发生时都将触发OnComm事件。
MSComm控件的主要属性如表1所示。
使用前需要在“Project”→“Components”菜单下勾选Microsoft Comm Control 6.0来导入MSComm控件,再将其添加到窗体上。本文首先在属性窗口里设置该控件的Name属性为MSComm1,CommPort属性为1(默认使用串口通道1),Settings属性为“9600,n,8,1”(波特率为9600bps,数据位为8位,停止位为1位,无奇偶校验),InputLen 属性为0(一次Input命令读取接收缓冲区所有的数据),RThreshold属性为1(只要接收到大于等于1个字节的数据就触发一个OnComm事件),SThreshold属性为0(发送数据时不触发OnComm事件)。
本文采用MSComm控件的OnComm事件来接收串行数据,方法是在OnComm事件里判断事件类型,当为串行口接收事件时,再跳转到串行口接收程序。在串行口接收程序中,首先定义一个字节型数组DataRecieve(100)、变体型变量Input、整型变量StrLen和i。具体代码如下(括号内为代码的含义):
Private Sub MSComm1OnComm()
Select Case MSComm1.CommEvent'(判断事件类型)
Case ComEvReceive'(当本次事件为串行口接收事件时)
StrLen=MSComm1.InBufferCount'(获得接收缓冲区的字符数)
'(将接收缓冲区里的数据读取到Input变量里并清空接收缓冲区)
Input=MSComm1.Input
'(将Input变量里的数据逐字节地移到DataRecieve数组里等待处理)
For i=0 To StrLen-1
DataRecieve (i)=Input(i)
Next i
此时一次串行口接收事件完毕,接收到的数据存放在DataRecieve数组里,接下来就可以按照上文所制定的通信协议对其进行处理。
值得注意的是,由于本系统中上位机接收数据的长度不一,在实验中经常出现下位机发送一次数据却触发两次OnComm事件的情况,导致一次数据被分成两段接收,从而导致通信失败。经分析,这是由于RS-232传输速率较低,而上位机程序执行得很快,一次数据还没有完全传送到接收缓冲区就被读取走,余下的字节又会触发一次OnComm事件。为了避免这种情况,本文采用定时器固定延时的方法接收数据,即在串行口接收事件中先开启定时器,延时一段时间,保证一次数据完整地发送完毕后再读取接收缓冲区并清空。具体做法是在窗体上添加一个Timer控件,设置其Interval属性为60,即将延时时间设置为60ms。在串行口接收事件到来时先设置Timer控件的Enabled属性为True,然后将程序挂起;经过60ms,在Timer控件的Timer事件到来时先设置其Enabled属性为False,再进行串行数据的接收。
本文采用命令按钮的Click事件发送串行数据,由MSComm1的Output属性来实现。如MSComm1.Output=0FH语句的作用是把数据0FH传送到发送缓冲区。
由上面的分析还可以看到,使用MSComm控件时,串行数据的接收和发送分别由两个不同的事件来触发,这样就保证了通信的实时性。
3.2 与数据库的连接
Visual Basic下的数据访问接口有三种:DAO(数据访问对象)、RDO(远程数据对象)和ADO(ActiveX数据对象),每个数据访问接口代表了数据访问技术的不同发展阶段。作为DAO和RDO的继任者,ADO是一种完全面向对象的编程接口,它封装并实际上实现了OLE DB(Object Linking and Embedding Database,对象链接和嵌入数据库)的所有功能。ADO简化了DAO和RDO中的对象模型,包含较少的对象但具有更多的属性、方法和事件,因此具有更强大的功能和灵活性[4]。本软件就是使用ADO接口方式实现了与Access数据库的连接。
ADO主要包括以下几个对象:(1)Connection对象:用于连接数据源;(2)Recordset对象:用于存储数据操作返回的记录集;(3)Command对象:用于执行对数据源操作命令。使用这些对象配合SQL语句就可以实现对数据库的查询、添加、修改和删除等操作。应用ADO技术操作数据库的流程可表示为:导入ADO库文件→创建Connection对象并连接数据库→创建Recordset对象或Command对象并定义其属性→执行SQL命令,取得结果记录集→关闭记录集和连接。
3.3 人机界面设计
本文设计的软件界面是一个基于MDI窗体的多重文档界面,主窗体采用标准的Windows窗口样式,自上而下依次为:菜单栏、工具条、工作区和状态栏。它有四个主要的应用菜单:电机参数、实时监测、故障记录和故障分析,如图3所示。通过该软件可以同时管理多达500台电机的铭牌数据,可以实时监测电机的运行状态,也可以查看所有已储存电机的故障记录,还可以对实时采集的电机的电压电流数据进行故障分析并绘制频谱图,这样就实现了在上位机层面对电机故障数据强大的管理功能。其中频谱图是利用PictureBox控件的Pset方法和Line方法来绘制的。此外,我们设置了系统密码以增强数据的安全性,在程序中还引用了Excel对象库以生成故障记录的Excel报表。至此,电机故障检测管理系统上位机软件开发完毕,并在Windows 2000NT2003XP系统下测试通过。
4 结束语
本文具体阐述了电机故障检测管理系统上位机软件的开发流程,详细说明了在Visual Basic下使用MSComm控件实现PC机和微控制器之间串行通信的过程,在实际工程应用中有着一定的借鉴意义。在上位机用Visual Basic来开发专用软件可明显降低开发难度,缩短开发周期。经半年多来的运行试验证明,虽然本系统中上位机和下位机交换的数据量很大,但通过以上合理的程序设计可满足实时性要求。
参考文献
(1)牛生勇.异步电动机故障诊断技术(J).甘肃冶金,2001,(03).
(2)赵海燕.用VisualBasic实现串口通信的三种方法(J).通信世界,1997,(01).
(3)侯志军,高媛媛,沙楠.基于VB6.0的多方式串口通信实现(J).计算机与数字工程,2006,(02).
检测电子作业被抄袭的软件研究 第4篇
关键词：电子作业 检测抄袭 关键字 截屏 距离计算
【中图分类号】G434
1引言
随着计算机应用的普及，高校正在逐步实现作业的电子化和网络化。这种作业形式的改革有效减少了教育资源浪费，教师工作任务量，提高了效率，使教与学得到了互动。作业的电子化是高校教学改革发展趋势，同时带来的负面影响则是加重抄袭现象，这就成为作业改革受到严重困扰的主要因素。所以研究一款减少抄袭现象发生的技术对作业质量的提高具有重要意义
2 国内外现状分析
大学作业抄袭在国内外已十分常见。中国青年报在调查中对2340人进行的一项调查显示，82.7%的人认为大学生作业抄袭现象普遍，45.5%的人感觉“非常普遍”。在国外，Cramster.com网站中包含数百本教科书附加答案，学生仅需月付少量金钱，便能轻松解决作业。
中国学者付兵在《基于信息隐藏技术的电子作业防抄袭研究》《网络环境与机房环境下电子作业反抄袭策略》这些篇论文中提到，他采用了信息隐藏算法对作业文本嵌入原创信息，对作业进行片段拷贝检测，从而准确定位抄袭源。西米苏里州立大学的J. Evan Noynaert教授在论文《Plagiarism Detection Software》中指出“Plagiarism detectionsoftware is a powerful tool in the fight against plagiarism.”并提出软件从三个方面来检测抄袭：Quiz methods ，Writing style methods以及Comparison with original sources。
在这些理论和实践的基础上，探究出一个方便直接的防抄袭系统，对大学生未来可持续发展都有积极的作用。
3 系统设计的主要设计思路
3.1设计方向
两个主要的设计方向：动态截屏和检查关键字个数。
3.2具体设计思路
3.2.1采用QT软件设计两个独立的客户端，分别为教师与学生使用。
3.2.2 教师端的采用QT的file读取技术，任意选择两个文件读入软件，统计文件中指定关键字的个数，利用算法得出两篇作业关键字个数的相似度，若相似度过高则可大体判断为抄袭。
3.2.3 学生端采用QT的图像截取技术，用定时器自动将电脑整个屏幕截图以图片格式保存在一个文件夹中。通过截图可判断做作业过程中学生是否出现异常操作。若短时间内截图中作业内容变化大或者截图中出现正在用浏览器搜索网络上的作业等，则可能存在抄袭。
4 研究过程
4.1图片定时记录以及存储
由于图像信息修改较为麻烦，能较真实的还原事物本质，则在研究过程中，着重利用Qt Creater中现有的针对图形图像处理的QPixmap类，运用其已有的grabWindow（）函数，通过参数的设定，最终对学生电脑在作业时的整个屏幕进行捕捉记录，并利用saveScreen（）函数将捕捉到的圖像信息以系统时间为命名方式存储在文件夹中，较为真实的还原了学生的作业过程。为了提高记录效率，后期利用Qtimer类以1min/张的频率进行图像信息的存储。
4.2内容对比检测
在数学中，空间向量的模越短，则两点坐标越相近。基于这一性质，系统罗列了电子作业中大部分可能用到的关键词，并按照其字符串长度进行排序，形成一个n维数组arr[n]。其次，对需进行比较的电子作业进行关键词的提取，记录各个关键词的数量，并按照数组arr[n]中元素的排列方式形成两组n维数组a[n]和b[n]。那么就等同于得到了2个三维坐标，在空间向量中，我们可以利用数学公式（1）求出二个向量之间的模，从而得到两点间的距离，为了增加检测结果的可信度检测程序中录入了50余个关键字。
公式1 计算距离的公式
根据d的数值大小来判定相对比的两份电子作业相似性。我们设定了一个指定的阙值，当得到的结果d的数值小于等于该指定阙值5时，则可判定为疑似抄袭。
结束语
现如今的中国高等教育的教育模式基本类似于“师傅领进门，修行靠个人”，在经历过快节奏的高中生涯后，自由的大学生活给大学生带来巨大的心理反差，许多人不再专心于专业课程学习，渐渐荒废学业，致使毕业时前途迷茫，遗憾蹉跎。
本项目的研究主要以检测大学生是否抄袭作业，使大学生独立自主完成专业作业，培养个人良好素质习惯。为社会输送更多学而有成的专业能手。提高高等教育培养出优秀人才的比例。对自身以及社会都有良好的影响。
本研究的特点，它是具有一定实用性的检测软件。可以从多个方面来判断抄袭，容易操作，简单，可行性大。
参考文献：
[1]付兵.基于信息隐藏技术的电子作业防抄袭研究.长江大学计算机科学学院：1-5.
[2]祁俊.王晓英.抄袭检测系统对计算机类电子作业的影响分析.青海大学：1-3.
[3]化柏林.抄袭检测系统将给中国学术界带来的变化.科技导报， 2009，27（12），107.
[4]胡秋芬.电子作业防拷贝技术比较研究.浙江越秀外国语学院， 2013，34（6）：59-60.
[5]李建军.反抄袭软件的局限及学术打假之策.编辑之友·术业，2010，6：87-91.
[6]罗国辉.反抄袭系统的设计与实现.开发研究与设计技术，2007，1615-1616.
DCS软件故障排除实例 第5篇
山东华宇学院过程控制实训室采用的和利时HOLLIAS-MACS系统完全和实际工程应用相同, 系统结构见图1。工程师站和操作员站计算机被人非授权使用后, 两站监控画面不能显示现场数据变化, 无法控制现场设备。
2. 故障分析与排除
(1) 判断是硬件故障还是软件故障。开机, 观察现场主控模块FM801的状态指示灯, 发现CNET灯常亮, 说明PROFIBUS-DP现场总线工作正常, SNET1、SNET2灯不亮, 说明系统网 (工业以太网) 故障, 即FM801和工程师站、操作员站不能通信, 可能原因有: (1) 工程师站和操作员站IP地址错误或者硬件连接故障 (如网线插错) 。 (2) 硬件连接正确, 但逻辑连接错误, 通信相关软件故障。依次进入工程师站计算机“开始”、“运行”, 输入ping 130.0.0.10 (FM801的IP) , 结果可在工程师站连接到FM801, 说明工程师站至FM801的网络硬件线路良好, 表明故障原因是 (2) 。
(2) 软件故障和FM801系统软件以及用户应用软件错误有关, 鉴于系统软件错误可能性很小, 一般不要求重新安装 (用CuteFTP软件传送) , 因此首先检查用户应用程序, 具体方法是:依次进入Windows操作系统“开始”、“程序”、“MACSV组态软件”, 单击“控制器算法组态”, 选择工程HYXY1, 选择站号为10, 进入算法组态程序界面 (图2) , 在“在线”菜单下, 点击“登录”后, 依次选择“退出”、“保存”, 这时SNET1灯亮, 系统网络连接正常, FM801可与工程师站、操作员站通信。但是操作员站、工程师站监控画面仍没有监控数据, 且均显示离线状态, 检查发现工程师站IP地址130.0.0.1和操作员站IP地址130.0.0.2分别被人篡改为172.16.23.22和172.16.23.24 (注意, 此时网络图标仍显示网络连接正常) , 改为正确值后, 故障依旧。
(3) 检查D盘和利时组态软件中的工程文件默认目录MACSV-ENG发现建立了许多非法工程文件, 这必须要在“数据库总控界面删除, 具体方法是:依次进入工程师站计算机“开始”、“程序”“MACSV组态软件”, 单击“数据库总控”, 进入总控界面 (图3) 选择删除工程, 将其删除, 然后在此界面导入备份的工程文件HYXY1, 进行基本编译、联编, 形成所有下装文件, 依次进入工程师站“开始”、“程序”、“MACSV组态软件”, 单击“工程师在线下装”, 进入工程师在线下装软件界面 (图4) 。
(4) 需要下装的文件有服务器下装文件和操作员站下装文件。
(1) 服务器下装文件的传输。这类文件要分别下装到工程师站和操作员站, 具体方法是:在图4“系统命令”菜单下选择“下装”命令, 在出现对话框中选择“服务器”, 选择站号为10号, 选择工程为HYXY1, 选择工程师站IP地址130.0.0.1, 并双击 (注意, 单击无法下装) , 勾选“下装后自动注销并重启动服务器”项, 按下“下一步”, 即可实施下装。接着再进行下装到各个操作员站的操作, 方法同上, 只是每次选择的IP地址是各个操作员站的IP地址, 下装完成后, 发现被下装计算机自动注销并重启。
(2) 操作员站下装文件的传输。这类文件一般只下装到操作员站, 但是若工程师站兼做操作员站, 也需向工程师站下装。具体操作是:在图4“系统命令”菜单下选择“下装”命令, 选择“操作员站”, 选择站号为10号, 选择工程为HYXY1, 选择操作员站IP地址130.0.0.2, 并单击, 按下“下一步”, 即可实施下装。该实训设备的工程师站兼做操作员站, 因此也实施了下装 (IP地址为130.0.0.1) 。
上述工作完成后, 在操作员站和工程师站计算机, 依次进入“开始”、“程序”、“MACSV操作员站软件”, 单击“操作员在线”, 调出监控界面, 发现网络此时处于在线状态, 现场数据可正常显示, 故障排除。
3. 建议
(1) 软件故障是DCS最常见的故障, 因此软件维护须专人负责, 不得随意使用系统上的计算机, 要屏蔽操作员站和工程师站的USB接口。
(2) 熟练使用PING工具、上传工具、网络工具等工具软件可极大提高工作效率。
(3) 要做好重要工程文件的备份, 以便故障诊断时使用。
(4) 为迅速查找故障原因, 实施维修, 平时要熟悉系统各种文件的安装位置、文件数目、文件作用等, 能熟练安装系统软件、组态软件, 熟悉系统中常用协议的基本知识, 系统体系结构, 组态软件的应用。
参考文献
[1]王常力.分布式控制系统设计与应用实例.北京:电子工业出版社, 2004
简论软件故障暴露率 第6篇
随着计算机的普及, 人们对软件质量的要求也越来越高, 作为软件质量中最重要的一项内容—软件可靠性, 自然也受到人们的重视。要度量软件的可靠性, 软件可靠性参数是必须要考虑的。所以研究软件故障暴露率有非常重要的意义。
软件故障暴露率[1]K表示了导致故障的“程序段”所占的时间比。这说明:第一, 程序不是以直线的方式执行的, 程序本身有许多的循环和分支。第二, 机器状态是变化的, 因此当执行到某个指令时, 与此执行相关的缺陷可能不会暴露出来。机器在故障暴露时的作用示意图 (见图1) 。
从图1中我们可以看到, 当X>25时, 则含有缺陷的程序通过完成y=A而得到正确执行;X≤20时, 含有缺陷的程序通过完成y=B也可以得到正确的执行。只有当20<X≤25时, 故障才会发生, 并暴露含有不正确条件的语句。由于这样的缺陷可覆盖很小的一个数据范围, 因此K值很小是不足为奇的。K的平均值为4.2×10-7。Li和Malaiya的研究表明:
在K已知的情况下, 可以对软件中存在的故障的测试情况和软件的可靠性进行有效的评估。如可以估计软件的初始故障率、总的故障数等。以下将故障暴露率与故障检测率和故障排除效率相结合, 给出在一次性测试中软件故障数及软件的故障排除效率的计算方法。最后提出了在三角形模糊数算术运算下的基于组件的软件故障暴露率的计算方法。
1 故障暴露率与故障数的关系
定义1 (故障暴露率K) 软件故障暴露率K是指在整个软件测试期间, 一次性测试存在于软件中的所有故障被暴露的概率。可以被形式地描述如下[2]:设S是待测软件, F={F1, F2, …, Fn}是存在于S中的n个故障, C是测试用例, 则软件故障暴露率可以用K表示为K=f (S, F, C) 。
定义2 (故障检测率b) 在软件测试中, 软件中潜伏的每个故障单位时间内被检测到的概率。
假设不同的软件故障是相互独立的。则
1) 若软件中只有一个故障, 其检测率为b, 则故障暴露率
2) 若软件中有n个故障f1, f2, …, fn, 且每个故障的检测率都为b, 则故障暴露率
K=1- (1-b) n;
3) 若这n个故障f1, f2, …, fn是相互独立的, 每个故障的检测率为b1, b2, …, bn, 则
软件的故障检测率b和故障暴露率K通常为经验值, 或者可以根据PIE方法计算得到, 而知道了b和K以后就可以在软件多次测试中给出在不降低验证测试结果可信性水平的前提下, 有效减少验证次数的方法[3]。
若n个故障相互独立, 并且被检测的概率都是相等的, 则一次检测n个存在的故障就相当于一个故障被检测了n次。当故障未被完全检测出来时, 实际检测率b必定小于计算值, 因此, 实际检测率b≤ (1-K) 1/n, 由此得到n≤lg 1-b (1-k) 。于是, 若已知故障检测率和故障暴露率, 就可以近似估计一次性测试中最多检测了多少个故障。
例如 若待测软件S一次测试中每个故障的检测率都为b=0.001, 故障暴露率为K=0.015 9, 则此时n≤lg 1-0.001 (1-0.015 9) ≈16。所以在这一次测试中, 至少检测到16个故障。
以上是软件故障暴露率的第一个应用, 下面给出软件故障暴露率与故障排除效率之间的关系。
2 故障暴露率与故障排除效率的关系
现今大多数软件可靠性度量模型中都假设故障被100%排除, 这是很不符合实际的。事实上, 故障排除是软件开发人员的工作, 由于人为因素及软件的复杂性, 从实际软件测试结果来看, 当软件交付时, 故障排除效率并非100%[4], 有很少一部分软件开发公司的软件故障排除效率也只能达到99%。如果软件交付时, 故障排除效率在85%以下, 那么这样的软件是不会被客户接受的, 因为它太不可靠了。
定义3 (故障排除效率p) 在软件可靠性增长测试中, 检测到的故障被完全排除的概率。
为使软件可靠性测试更符合实际, 就必须考虑软件故障排除效率。有的文献假设故障排除效率是一个常数[5], 而在测试实践中, 排除不同类型的故障的时间延迟是不同的, 正是因为某种类型的故障在测试排错结束时仍保留在当前软件中, 所以故障排除效率并非100%。故障排除效率一般随测试时间发生变化, 是测试时间的函数。
假设软件中故障的平均排错时间为α, 每个故障的检测率为b, 则包含x个系统的软件故障排除效率[6]为
1) 若被测软件中只有一个故障, 则包含x个系统的软件的故障排除效率为
2) 若被测软件中有n个故障, 则包含x个系统的软件的故障排除效率为
综上, 在软件可靠性增长测试中, 只要知道软件的故障检测率和故障暴露率, 就可以大概估计出软件故障排除效率, 从而可以评估被测软件的可靠性, 因为故障排除效率越高, 软件可靠性也越高。
例如 某待测软件中由3个系统组成, 有8个故障, 一次测试用了30天, 故障暴露率为2×10-6, 则此软件的故障排除效率为
3 软件系统的模糊故障暴露率
由于一般待测软件通常存在多个模块, 所以需考虑待测软件组件的故障暴露率。我们知道, 事件的模糊性与随机性是反应事件属性的两个不同的概念, 也是研究不确定性问题的两种方法。在软件测试中, 实际输出的数据往往是不确定和不精确的, 且故障暴露率和故障检测率等一系列参数大多数是由专家经验和其他领域的参考数据来估计, 由于环境、人为因素及收集数据困难等一系列因素的影响, 获得的这些参考数据都带有主观性和模糊性。而模糊数学正好提供了一种解决主观性和模糊性问题的数学方法。硬件系统的模糊可靠性已经研究的很多, 软件和硬件有相似的地方, 下面给出如何利用三角形模糊数来计算基于组件的软件故障暴露率的计算方法。
3.1 基本概念
定义4 (三角形模糊数[7]) 通常把模糊数看成数集的一个模糊子集, 取论域U为实数集, 则
定义5 (三角形模糊数运算法则)
1) a1 (α1, β1) ±a2 (α2, β2) = (a1+a2) (α1+α2, β1+β2) ,
2) c[a (α, β) ]=ca[ (cα, cβ) ],
3)
3.2 软件系统模糊故障暴露率计算方法
3.2.1 串联系统的故障暴露率
软件系统S由n个子系统串联而成, 系统只有“正常”和“失效”两种状态。设串联软件系统中n个子系统的模糊故障暴露率分别为k1, k2, …, kn, 若这n个子系统相互独立, 则整个软件系统的故障暴露率为
KS=1 (1, 1) -[ (1 (1, 1) -k1) (1 (1, 1) -k2) ,
…, (1 (1, 1) -kn) ]。
若这n个子系统不相互独立, 则整个软件系统的故障暴露率为
KS=max (k1, k2, …, kn) 。
3.2.2 并联系统的故障暴露率
软件系统S由n个子系统并联而成, 系统只有“正常”和“失效”两种状态。设并联软件系统中n个子系统的模糊故障暴露率分别为k1, k2, …, kn, 若这n个子系统相互独立, 则整个软件系统的故障暴露率为
KS=k1×k2×…×kn,
若这n个子系统不相互独立, 则整个软件系统的故障暴露率为
KS=min (k1, k2, …, kn) 。
3.2.3 串-并联系统的故障暴露率
软件系统S由nm个子系统串-并联而成, 系统只有“正常”和“失效”两种状态。串-并联软件系统中每个子系统的模糊故障暴露率为kij, i=1, 2, …n, j=1, 2, …mi, 若每个子系统相互独立, 则整个软件系统的故障暴露率为
若每个子系统不相互独立, 则整个软件系统的故障暴露率为
3.2.4 并-串联系统的故障暴露率
软件系统S由mn个子系统并-串联而成, 系统只有“正常”和“失效”两种状态。设并-串联软件系统中每个子系统的模糊故障暴露率为kij, i=1, 2, …n, j=1, 2, …mi, 若每个子系统相互独立, 则整个软件系统的故障暴露率为
若每个子系统不相互独立, 则整个软件系统的故障暴露率为
例如 某软件系统由两个子系统S1与S2组成。其模糊故障暴露率分别为
K1=“0.006 98左右”=0.006 98 (0.007, 0.008) ;
K2=“0.001 99左右”=0.001 99 (0.001, 0.002) 。
若S1与S2串联而成, 如果S1与S2相互独立, 则软件系统的模糊故障暴露率为
如果S1与S2不相互独立, 则软件系统的模糊故障暴露率为
若S1与S2并联而成, 如果S1与S2相互独立, 则软件系统的模糊故障暴露率为
如果S1与S2不相互独立, 则软件系统的模糊故障暴露率为
4 结论
软件故障暴露率是软件可靠性测试中的一个重要参数, 通过引入其它参数如故障检测率和故障排除效率及基于组件的软件系统故障暴露率的计算方法。显示了故障暴露率的重要地位, 并用实例证明了给出的结论是正确的。
摘要：分析了一次性软件测试中软件故障暴露率与检测的故障数和故障排除效率之间的关系, 给出了三角形模糊数算术运算下组件软件故障暴露率的计算方法。
关键词：软件故障暴露率,故障检测率,故障排除效率,模糊故障暴露率
参考文献
[1]穆莎J D, 艾里诺A, 奥本K.软件可靠性—度量、预计和应用.姚一平, 林典伦, 裘忠侯, 等译.北京:机械工业出版社.1992
[2]宫云战, 高文玲, 李晓维.软件故障暴露率的计算方法.计算机辅助设计与图形学学报, 2003;15 (6) :751—754
[3]刘晓娟, 温冠华, 李建军, 等.软件可靠性度量方法.计算机工程, 2009;35 (3) :57—59
[4] Jones C.Software defect-removal efficiency.Computer, 1996;29 (4) :94—95
[5] Zhang X M, Teng X L, Pham H.Considering fault removal efficiencyin software reliability assessment.IEEE Transaction on Systems, Man, and Cybernetics-Part A:Systems and Humans, 2003;33 (1) :114—120
[6] Jeske D R, Zhang X, Pham L.Accounting for realities when estima-ting the field failure rate of software.In:Proceedings, 12th Interna-tional Symposium on Software Reliability Engineering, 2001.ISSRE2001.Hong Kong:2001:332—339
柯达CR950软件故障的检修 第7篇
1 故障现象
CR950使用中突然关机,重开机后工作状态正常,扫描IP板时,传送至条码扫描位置就停止运行,显示屏没有提示信息,打开扫描器柜门时也没有提示信息,正常时应有信息提示。说明系统软件有故障,不能接收反馈信息。
2 故障处理
经检查,是UPS不间断电源插头接触不良,引起突然断电关机,处理后接着检修软件故障问题。因设备已过保修期,没有维修密码,也没有相应的安装软件,无法进行系统软件安装。以前每次出现故障,或是添加激光相机、PACS工作站,都是由柯达工程师带笔记本电脑连接本机进行会话,打开维修模式处理。通过观察,发现利用关键操作员功能可以进入系统进行参数设置。因此,在机器正常使用状态时,自己事先用GHOST软件做了系统C盘的镜像备份。在检修前,先进入关键操作员功能,用数码相机记录系统当前的配置。打开CR机柜门,把键盘(把条码扫描器的插头拔下接上键盘)、鼠标连接到电脑主机,再进入系统硬盘(方法在后面介绍),打开Logs(E:)区,复制Backup文件夹及Add On.bag文件到U盘中备用,把装有GHOST软件的启动光盘放进光驱进行系统还原,还原后重启系统,进入关键操作员功能还原其配置,把备份的Backup文件夹及Add On.bag文件覆盖到原来位置,然后退出程序重新启动机器。系统启动完成后,这时从Worklist调用患者信息正常,装载IP板后能进行扫描,扫描出的图像正常,但无法传送图像到PACS服务器,也不能打印胶片。查看系统状态,发现网络通信中的激光打印机、PACS服务器,连接均是中断的。原因是作系统的GHOST镜像备份后,该设备进行了搬迁,新址的IP地址已改变,连接的设备也有变化,需要进入系统进行重新配置。方法:用关键操作员口令进入关键操作员功能,点系统配置,点SMPTE测定模式,鼠标指针移至屏幕左上角,隐藏的4个图标会显示,点右边第1个Open My Pictures folder图标,会跳出1个错误提示,同时会显示底部的任务栏,再点Open My Pictures folder图标,会弹出图片收藏窗口,从这个窗口可进入硬盘及退到桌面,在桌面上双击MIMDUI图标,打开1个窗口界面,在其菜单栏点connect选connect to MIM,再到菜单栏点Configure选Network,在打开的窗口中设置本机现在的IP地址等参数,再到菜单栏点Configure选Destination,在打开的窗口中增加或修改激光打印机、PACS服务器等参数,设置完成后,退出程序重启系统,再观察系统状态,这时连接一切正常,故障修复。
3 小结
本机自2005年使用至今,因机器死机、计算机CPU散热不良突然关机等,已出现过几次软件故障,每次都是柯达工程师来检修,耗时长,维修成本高,影响了科室的正常运作。现在大部分数字化设备都用到电脑进行控制及数据处理,平时多留意做好相应的备份,维修时可有事半功倍的效果。
参考文献
[1]黄桃,李平安,徐钦.GHOST软件在医疗设备计算机系统维护中的应用[J].医疗设备信息,2007,22(4):38-39.
[2]宋天一.医疗设备软件备份方法小结[J].医疗卫生装备,2006,27(6):99.
[3]王绪凯,张立军,徐小光.GHOST在大型医疗设备维修中的应用[J].中国医疗设备,2009,24(5):83.
传输设备软件版本故障处理经验一则 第8篇
某运营商的城域网由于点对点之间的直连业务较多, 为更加有效地提高网络容量, 所以传输网组网方式使用了二纤双向复用段共享保护环, 其网络结构如图1所示。
图1中, NE1、NE2、NE3、NE4为华为OPTIX2500+设备, 组成城域网2.5G骨干环;NE5为华为OPTIX 155/622H设备, 配置为622M, 以支链的形式挂接在节点NE3上。
以节点NE2至NE5之间的业务为例, 以上网络简化等效后, 如图2所示。
其中, A为2.5G骨干设备, 第2槽位配置ET1单板;B为接入设备, 第4槽位配置ET1单板, 与A设备第二槽位的ET1单板之间有业务开通。
2 涉及的几个概念
(1) 软件版本配套:一台电子设备内部各个模块之间或者多台电子设备之间进行信息交换互连时, 在软件方面各模块或设备之间必须满足的版本协议需求。
(2) ET1单板:提供DDN的业务透明传输能力, 将10M/100M端口转换成N个2M, 提供局域网用户的互连。OPTIX 2500+设备的ET1单板完成1～8个10M/100M以太网业务的接入, 将以太网数据帧通过1至48个E1进行远距离传输, 并且每块单板最多提供48个E1。
(3) EXCS单板:用于华为OPTIX 2500+设备的增强型交叉时钟板。
3 故障的起因及现象
某日, 由于某些不可抗拒的原因, 该运营商对A设备进行了一次搬迁割接。在割接中, 为使业务尽量少中断, 维护人员使用一端新的OPTIX 2500+子框对老子框进行了开环并行替换。割接完成后, 所有的TDM业务均恢复正常, 只有一条至设备B的普通以太网业务一直不能恢复。维护人员在网管侧同步并查看A、B设备的告警, 没有发现任何告警信息上报。
那么, 问题到底出在哪里呢?
4 故障的分析及处理
首先, 故障有可能出在业务没能完全下发、激活上。维护人员将该条业务在设备A和B上去激活、删除, 然后重新生成并下发, 最后, 业务还是没能恢复正常。
第二, 故障可能是因为ET1端口协议设置与接入设备不相符, 因此, 维护人员将该条以太网业务的端口协议进行重新设置, 全部改为透传模式, 并将其工作模式由“自协商”改为“100M全双工”, 但业务仍未恢复正常。
随后, 维护人员将以太网接入设备断开, 使用两台笔记本直连在A、B两设备的对应ET1端口上对PING, 结果也不能PING通。维护人员开始怀疑是不是A设备上的ET1单板出现了其他硬件故障, 从而导致了该条以太网业务不通。但这种猜测马上又被否定了, 因为该ET1单板是其他设备正在使用的, 并经过测试是正常的。
那么, 应该如何定位故障点并解决呢?
既然故障是因割接替换而起, 那就从割接替换入手, 看看问题到底出在哪里。首先查看新的OPTIX2500+子框的单板槽位配置与旧的子框有什么不同。经过检查, 新子框的单板槽位配置信息除了第7、8槽位的交叉板由原来的普通交叉时钟板XCS变为增强型交叉时钟板EXCS外, 没有其他任何变化。难道问题出在EXCS上?因为除此之外, 再也没有任何可能的地方了。
于是, 维护人员进一步查看了EXCS以及ET1单板的软件版本, 分别为:8.12和1.96。为确认该故障是否与此有关, 维护人员联系了华为公司的800客户服务热线, 得到的答复为:可能与此有关, 因为软件版本为8.12的增强型交叉时钟板EXCS需要软件版本为1.98的ET1与之配套。随后, 维护人员马上对A设备上的ET1单板进行了软件升级。升级完成后, 故障排除, 业务恢复正常。
5 结束语
在传输设备的日常维护中, 维护人员一般都非常注意单板的性能及特点, 但很少注意各单板之间的软件版本配套问题, 这就很有可能在故障单板的替换以及设备的割接中造成很大的麻烦。它提示我们:作为一名维护人员, 不仅需要扎实的理论基础, 还应具有把握全局的能力。
摘要：本文通过一则以太网业务不通问题的处理实例, 说明了各单板软件版本的配套在传输设备日常维护中的作用, 为部分疑难故障的解决提供了一条思路。
关键词：传输设备,ET1单板,以太网业务,EXCS单板,软件版本,版本配套
参考文献
汽车发动故障检测与维修 第9篇
关键词：汽车发动故障检测与维修
0引言
随着社会的发展，随着科技的不断进步，汽车已进入家庭，进入了许多领域，随着汽车数量的增加，汽车维修也随着不断发展壮大起来，汽车的故障也多种多样，五花八门。发动机作为汽车的心脏是多种零件中的重中之重，我就发动机故障的维修与检测，发表几点想法：
1发动机失速故障
1.1故障现象：发动机工作时，转速忽高忽低，这现象即为发动机失速现象，其故障被称为发动机失速故障。
1.2故障原因：造成发动机转速忽高忽低的原因有燃油喷盘系统的故障，也有点火控制系统的故障，还有进气系统的故障。常见的故障原因有以下几点：①空气滤清器滤芯过脏；②空气流量计工作不正常；③燃油喷射系统供油压力不稳。如油管变形，系统线路连接接触不良，燃油泵泵油压力不足，燃油压力调节器工作不稳定，燃油滤清器过脏，断路继电器触点抖动等；④点火正时不正确；⑤冷起动喷油器和温度正时开关工作不良
2动机不能发动
2.1故障现象：打开点火开关，将点火开关拨到起动位置，发动机发动不着。
2.2故障产生的可能原因：
2.2.1起动系统故障使发动机不能转动或转动太慢：①蓄电池存电不足、电极桩柱夹松动或电极桩柱氧化严重；②电路总保险丝断；③点火开关故障：④起动机故障；⑤起动线路断路或线路连接器接触不良。2.2.2点火系统故障：①点火线圈工作不良，造成高压火花弱或没有高压火花；②点火器故障；③点火时间不正确。
2.2.3燃油喷射系统故障：①油箱内没有燃油；②燃油泵不工作或泵油压力过低；⑨燃油管泄漏变形；④断路继电器断开；⑤燃油压力调节器工作不良；⑥燃油滤清器过脏。
2.2.4进气系统故障：①怠速控制阀或其控制线路故障；②怠速控制发阀空气管破裂或接头漏气；③空气流量计故障。
3发动机烧机油
3.1故障现象：汽车行驶时，低、中、高速都有蓝烟。且机油压力低，起动困难，行驶乏力。动力性能和经济性能大大下降，燃油和机油损耗增加，机油约5天时间补加一次，废气排放超标。打开机油加注口察看，有一定的脉动烟雾冒出；检查曲轴和进气口，有刺激气味烟雾窜出；看排气管口，有油湿现象，检查火嘴，积炭明显。以上特征表明发动机窜油现象突出。
3.2故障产生的可能原因发动机在正常温度下运转，要取得动力性和经济性，工作时就必须要使进入燃烧室的混合气的压缩力符合设计要求，而且保证进气充分并且燃烧彻底，因为只有压缩压力达到最大要求和进气充分，才能保证发动机做功时能产生足够的爆破力，从而产生足够的动力，带动发动机曲轴高速运转。而要保证发动机气缸压缩力达到最大要求，则要求发动机配气机构以及曲轴连杆机构等各配合部件密封配合良好。保证密封配合良好，则要求各配合间隙符合技术要求。一旦发动机各密封配合件磨损过大，将会影响其密封性，使发动机出现窜烧机油的故障，最终令其输出功率下降且不能正常行驶。造成发动机窜烧机油有以下几个原因：
3.2.1由配气机构引起。气机构的气门、气门杆、气门导管的磨损，令其配合间隙增大。当气门杆和气门导管由于修理工艺及磨损不均匀时。会造成密封配合不良，产生漏油现象。配气机构出现上述故障，将使机油窜入燃烧室燃烧，从而影响发动机的动力性和经济性。
3.2.2由曲柄连杆机构引起①活塞环磨损或失效、各环环口对口。活塞环是活塞连杆组中磨损最快的零件，尤其是第一道活塞环的磨损更为剧烈。在燃烧的作用下，环背产生很大的压力，当然大的环背压力有助于密封，但另一方面也加速了环背的磨损。活塞环磨损或失效后，弹力减弱，开口间隙、边隙以及背隙增大，令活塞环与气缸体的配合间隙增大，使气缸内密封性变差而出现窜油，造成发动机的动力性能降低，机油消耗升高，引致通风系统严重冒烟，排气冒蓝烟和燃烧室表面积炭。②活塞磨损引起的窜油。活塞磨损最快的部位，是活塞环槽与活塞销座孔环槽的磨损，其中第一道环槽磨损最严重，由上至下，依此减轻，环槽的磨损，使活塞环槽中配合间隙增大，结果容易引起窜油现象。
3.2.3由气缸磨损引起气缸的工作表面，在正常情况下一般是在活塞环运动的区域形成不均匀的磨损，沿气缸轴线方向磨成上大下小的圆锥形，磨损产生圆柱度误差，最大的磨损部位是活塞在上止点位置时，第一道环所对应的缸壁处，而沿横向截面是磨成不规则的椭圆形，磨损产生圆度误差。最大的磨损在进气门对面的气缸壁上，由于此处受新鲜混合气流较强冲袭作用，导致润滑油膜稀释磨料增多，温度降低，使该部位磨损严重。
检测波形数据综合分析展示软件 第10篇
检测技术发展初期, 一般通过各种记录仪以图纸形式记录数据, 检测结束后分发给现场维修部门进行分析, 查找问题分析变化, 很难实现数据的对比分析和长期保存。
随着检测技术和计算机技术的发展, 现在的检测车大多采用波形文件方式存储波形数据, 并开发了相应的波形显示软件, 不但可以在检测过程中即时显示波形检测数据, 而且通常具有历史对比、参数测量等分析功能。波形显示软件还可以用于离线数据分析, 通过与前次检测数据对比找出设备质量恶化之处。
随着高速综合检测列车的应用, 需要对不同检测系统的相关数据进行综合分析, 传统波形显示软件已不能适应新的需求。依托国家863重点项目“最高试验速度400 km/h高速检测列车关键技术研究与装备研制”, 针对近年来对波形数据分析的新需求, 在原轨道检测波形展示软件基础上进行功能扩展, 研发了全新的检测数据波形综合分析展示软件。
1 系统概况
检测数据波形综合分析展示软件采用.Net技术开发, 可在Windows操作系统环境下应用, 实现多专业检测波形综合分析、检测数据多次历史对比、设备台账综合展示及无效数据区段标识和文字标注, 而且创造性地实现了基于线路特征点的里程校核功能, 解决了困扰动态检测多年的大难题。
整个系统软件架构采用基于C/S体系架构, 系统设计采用框架式结构, 结构上包括数据处理层、网络接口层和前端展示层, 所有业务服务采用服务组件方式提供, 保证了系统的高扩展性。数据处理层是软件系统实现数据高效访问和各种分析功能的核心, 包括数据文件读取解析模块、数据库访问模块和数据分析处理模块。数据文件读取解析模块负责对实体数据文件的读取;数据库访问模块封装了对设备台账数据、偏差数据、索引及标注数据等记录类数据的访问接口;数据分析处理模块实现了里程修正处理和基于表达式的计算通道动态生成, 且实现了与Matlab数值计算模块的交互组件, 可实现对波形文件的复杂处理分析, 目前已实现的算法包括相关性计算、轨道谱计算、偏差动态评判和区段特征值计算。
2 功能特点及实际应用
检测波形数据包含大量对指导设备养护维修具有重要意义的内容, 但目前对于波形数据的分析应用还很不充分, 其中原有波形查看软件在展示和分析功能方面的欠缺也是波形数据分析应用不够的主要因素之一。新的波形综合分析展示软件在多专业检测波形综合分析、里程后期校核、多次历史数据比对等方面取得了突破。
2.1 里程后期校核功能
无论是综合检测列车还是各专业检测车, 都是在动态运行条件下完成基础设施状态检测, 各检测系统必须通过LKJ、GPS等信息源获取线路上定位点的实际里程, 并利用轴头编码器的脉冲信号等方式实现定位点间的里程记距。实际应用中受到各种因素影响, 如GPS信号不良、轮径测量误差等, 检测数据中的里程往往与实际里程存在一定误差, 且这种误差很难通过检测系统的改进在动态检测过程中在线完全消除。里程方面的误差给维修部门查找现场病害带来了很大难度, 尤其是目前高速铁路普遍设备质量较高, 且维修天窗往往在夜间, 里程信息的准确性成为提高检测数据应用水平的关键之一。
通过分析可知, 检测数据中里程误差的来源主要有2个方面:定位点里程的不准确和脉冲记距带来的累计误差。目前在高速铁路推广的基于RFID射频标签的里程精确定位系统可以很好地解决定位点里程的精确性问题, 但里程精确定位系统的全面推广还需较长时间, 很难推广到所有线路, 同时也无法解决由于长断链、定位点错失及记距方面带来的误差。因此, 研究通过后处理手段修正检测数据中的里程误差是当前较为可行的方法。
该软件系统创造性的采用动态索引技术, 可在不对检测波形文件进行任何修改的前提下, 利用检测波形本身所具有与设备台账相关的特征点, 如弓网检测的接触线支柱、轨道检测的曲线头尾, 通过数据分析人员设定的关键点索引, 对检测波形数据进行里程后期校核。应用动态索引的里程修正机制还可以利用现场反馈的偏差实际里程不断提高里程修正精度。
图1是软件实际应用的演示, 红色 (层1) 和蓝色 (层2) 分别为同一次检测修正后和修正前的波形数据展示, 设备台账显示曲线起点应为K683+013, 修正后的检测数据里程为K683+10.7, 修正前里程为K683+465。目前采用利用曲线特征点获取修正定位, 通过大量测试, 利用这样的方式每40 km打一个索引点大约能够保证全线各点里程精度在10 m范围内, 可以满足实际工程需求。
目前软件还开发实现了对相应检测导出文件中偏差数据的里程信息进行修正, 并对轨道质量指数重新计算, 在进行后期数据分析中能够更加准确的掌握轨道质量变化趋势, 避免由于里程偏差带来的分析误差。
利用模式识别等数据处理技术, 里程修正还实现了自动化对历史检测数据的修正, 经过多次调试, 基本可满足日常数据管理应用需要。为了进一步满足数据精细化分析, 如偏差处幅值变化分析等应用需要, 在数据处理层还实现了局部数据精确对齐的功能, 可以将分析目标附近的检测数据进一步对齐, 达到采样点精度。通过一系列解决方案, 实现了检测数据里程修正功能, 为工程应用和科研分析提供了可靠的数据支持。
2.2 多专业检测数据综合分析功能
综合检测列车上包括轨道、供电、信号、通信及车辆动态响应等多个检测系统, 各检测系统分布在不同车厢内, 即同一时刻各检测系统实际的里程范围不同。综合检测列车通过时间里程同步系统实现了不同车厢内各检测系统检测结果在时间和里程上的同步。
在检测波形数据综合分析展示软件中, 借鉴了图像处理软件中图层的概念, 利用数据处理层的数据解析和抽象能力, 将不同检测波形文件各自作为一个单独图层, 各层均为透明显示, 享有同等绘图空间, 通过在通道配置文件中设置通道基线偏移值确定各通道绘制位置。各层间可以进行里程方向平移, 并实现自动里程同步功能。采用这样的解决方案, 结合后台数据访问和解析模块, 不但实现了同样采样间隔、不同检测系统检测数据的同屏展示, 而且能够实现不同采样方式 (定时和定距) 、不同采样间隔检测数据的综合展示。
图2是轨道检测与弓网检测的综合展示, 通过2个专业的同屏综合展示, 弓网检测可以利用轨道检测中的轨道几何和线形等信息, 辅助硬点、接触压力等参数的评判。
2.3 多次历史数据比对功能
基础设施状态的变化往往是一个渐进的过程, 通过发现检测参数在历史上的变化, 不仅可以得到指标的变化, 有时还能揭示出更深层次的原因。通过多次尤其是时间跨度较大的几次检测波形数据对比, 很容易发现持续发生变化的地段, 结合现场检查, 分析其发展原因, 有针对性地进行整治, 才能彻底消除病害。
图3是对同一线路区段采用4次检测数据进行对比的示例, 可清晰发现K358+230处轨道高低发生明显渐变现象, 这样的区域就需要进行重点检查、监控。
2.4 其他功能特点
设备台账是记录线路中各种设备详细信息的重要资源, 检测和分析过程中如果能够经常性参考台账中的设备要素信息, 对于提高检测质量、正确评价设备状态均有重要意义。
通过对常用设备台账信息的适度抽象, 波形综合展示分析软件还实现了设备台账的同步展示功能 (见图4) , 为满足各种应用需要, 可以采用图形化和表格化2种展示方式。
软件系统数据分析处理模块是一个扩展性很强的功能模块, 尤其是实现了与Matlab计算模块的交互组件后, 可以利用Matlab的计算功能, 可在Matlab中开发复杂的波形分析算法, 如轨道谱、时频分析等, 通过组件调用, 波形分析软件就能直接实现相应的计算功能。
传统波形查看软件都是面对单一文件, 都是通过人工识别文件名找出需要分析处理的文件。基于地面数据中心强大的数据管理能力, 检测波形数据综合分析展示软件不但具有打开本地数据文件的能力, 而且可以在网络模式下, 远程打开数据中心存储的各种数据, 提高数据分析效率。
软件还具有其他一些实用功能, 如多通道测量、多次历史测量、自动化截图、人工标注等, 这些功能在实现过程中都根据用户反馈的建议进行反复调整和完善, 保证用户应用的便捷性。
3 结论
检测波形数据综合展示分析软件是一个系统性软件工程, 目前主要功能均已实现。但仍有一些好的设计需要在下一阶段开发中实现, 如根据设备台账自动化进行里程校核、基于多次历史检测数据自动化提取轨道几何发生渐变的区段等。
【故障检测软件】相关文章：
故障诊断与检测06-01
故障检测与隔离07-04
异常故障检测算法06-02
非线性故障检测05-21
电缆故障检测系统06-19
故障检测建筑电气论文04-27
电缆故障检测仪器07-07
手机故障检测与维修10-18
故障检测建筑电气论文提纲10-02
汽车检测故障诊断论文05-16