tag 标签: 诊断

相关帖子
相关博文
  • 热度 6
    2023-9-7 14:06
    1027 次阅读|
    0 个评论
    C AN oe主要用于汽车总线的开发并广泛被汽车电子工程师们使用。它具有强大的开发、分析、仿真、诊断、测试等功能。一提到C AN oe大家往往都会想到 CAPL ,在使用 CAN oe的过程中相信每位工程师都或多或少的要和“ CAPL ”打交道。学好C APL 的用法可以让我们更加高效、便捷地使用CANoe。本文就C AN oe中关于诊断的C APL 函数进行介绍。 诊断,其实就是服务端和客户端进行一问一答的方式。这里的一问一答指的是发送和接收的方式,Tester端发送一条特定I D 的报文(请求),E CU 接收到以后会相应的回复一条特定I D 的报文(响应)。诊断是一个非常重要的功能,可以读取E CU 的很多信息,比如:版本号,故障信息,状态信息等。 CANoe 是具有诊断功能的 , 如果需要大批量的进行诊断测试就需要使用C APL 来辅助。 如下图所示,C AN oe可以直接加载C DD 文件,加载完C DD 文件后可以 通过CANoe工程的诊断界面 打开诊断台,进行手动的发送诊断报文。 在CANoe中加载CDD文件 如下图所示,在Diagnostic C onsole中我们可以直接发送扩展会话服务(0x1003),E CU 端收到扩展会话服务请求后会给出肯定响应或否定响应。 用 Diagnostic Console发送诊断请求 但是随着测试任务的增加,我们要进行多种方式的诊断测试。如下图所示,加载完C DD 文件后,随之打开C APL Browser ,就可以在C APL 编辑器的 S ymbols栏中找到我们C DD 文件对应的诊断服务。 CAPL Browser 中CDD文件的调用 对于使用C APL 实现诊断功能我们通常有两种方式: (1)通过发送C AN 报文的形式去实现; 针对第一种方式,我们只需要在 CAPL 中定义一条特定I D 的报文,再定义它的D LC 以及每个字节的内容再发出去就可以了,如下图所示: CAPL 代码实现 Trace 中报文的显示 (2)通过调用加载到C AN oe工程中C DD 文件定义好的诊断功能去实现。 针对第二种方式,因为CDD文件中已经定义了ECU支持的诊断服务、通信参数等参数,所以我们只需要把我们在C DD 中定义好的诊断服务发送出去即可,如下图所示: CAPL 代码实现 下面就让我们来学习一下诊断中常用的一些C APL 函数 。 在我们学习常用CAPL函数之前,先来了解一下诊断处理事件: (1) on diagRequest NewRequest :进行ECU仿真时,收到诊断请求时调用。 (2) on diagResponse NewResponse :Tester端收到诊断响应时调用。 (3) on diagRequestSent NewRequestsent :收到Tester端发送的诊断请求时调用。 常用的诊断函数列表及功能描述: (1)通信/设定功能函数 d iagGetCurrentEcu 用于获取当前E CU 名称; d iagGetLastCommunicationError 用于返回上一次诊断请求的错误码 d iagSendRequest 用于发送诊断请求给目标 ECU d iagSetTimeout 用于设定诊断请求的超时时长& d iagSetTimeoutHandler 用于创建一个回调函数,在诊断请求超时时被调用 : (2)安全访问函数 diagSetCurrentSession 设置当前E CU 的会话模式 : diagStartGenerateKeyFromSeed 用于根据种子和密钥算法DLL生成一个密钥&_ Diag_GenerateKeyResult 用于返回使用计算密钥的结果: (3)对象访问函数 diagGetLastResponse 用于保存上一次收到的诊断请求响应: (4)诊断测试函数 函数 功能描述 diagCheckObjectMatch 用于检测诊断响应的 ID 是否与诊断请求相符 diagCheckValidNegResCode 用于检测返回的否定响应是否在诊断描述文件 (CDD文件)中已经定义 diagCheckValidPrimitive 用于检测指定的诊断对象是否符合规范 (CDD 文件) 中的定义 diagCheckValidRespPrimitive 用于检测收到的诊断请求响应是否符合规范(CDD 文件)中的定义 testCollectDiagEculnformation 用于向指定的诊断目标发送诊断请求并将响应写入报告文件 testReportWriteDiagResponse 用于将接收到的诊断响应写入报告 testWaitForDiagRequestSent 用于等待上一次的诊断请求成功发送到 ECU testWaitForDiagResponse 用于等待接收到请求的诊断响应 testWaitForDiagResponseStart 用于等待接收到请求的诊断响应开始,即收到响应的首帧报文 testWaitForUnlockEcu 用于尝试解锁 ECU 拓展小学堂 : VECTOR 对于诊断方面是有许多专业性的工具 , 下图为诊断工具链的V模型,从开发到测试、从供应商到主机厂都会涉及到的诊断工具。 下面就由我来为大家进行简单的介绍: C AN delastudio :CANdelaStudio用于定义ECU的诊断功能,并且生成诊断数据库(CDD文件)来优化整个诊断开发过程。CANdelaStudio支持文档模板(CDDT文件),可以满足不同厂商对同一个标准工具的各种特殊要求。在内容上一个文档模板对应于一种诊断规范,它包含了对ECU所有允许的基本服务和在每个ECU中都必需实现的强制功能的一个正式描述。 O DXStudio :基于ODX的诊断流程并以ODX格式查看、编辑、处理或管理诊断数据的所有用户而设计。它支持单个 ECU 的诊断开发,直至整个车辆平台的水平。它同样适合在汽车 OEM 和供应商工作的用户。ODXStudio处理的是ODX 2.0.1和2.2 .0 版本的数据。 CAN oe. D iva :作为一个生成诊断测试用例的工具,可以支持把CDD文件和ODX文件导入到Diva工程当中,然后去通过一些相应的配置,点一个按钮自动生成诊断相关的一些测试用例,再把生成的测试用例导入到C AN oe中进行诊断的自动化测试,测试完成后会自动生成相应的测试报告。 v Flash :刷写工具,vFlash可以作为一个独立的工具来实现程序刷写。作为一个简单易用的刷写工具,vFlash不需要使用者具有专业的知识。它具有如下的特点:精简的用户操作界面利用模板来实现对于不同Flash刷写规范的支持可通过CAN/LIN/以太网进行刷写在提高刷写速度的同时,可以刷写更大的数据结合VN8810实现远程一键刷写 I ndigo :作为参数化工程诊断仪,支持工程诊断的应用场景。同时,Indigo支持客户定制化,例如集成vFlash工程支持刷写应用场景、通过选择车辆配置参数组支持车型配置、例程控制界面、可执行工程但不可编辑工程配置的Indigo Run、中文界面并且还可以拓展支持远程诊断等功能。 CAN oe作为一个强大的总线开发工具有很多的功能,本文就CANoe中的诊断功能相关的CAPL函数做了讲解并简单的讲解了V ECTOR 旗下的诊断工具,希望本文章可以为大家带来全新的使用体验,如有问题欢迎私信我们北汇信息。 北汇信息作为Vector的合作伙伴, 已为多家OEM/Tier1定制部件级功能测试系统(包括车身域控制器,及传统分布式控制器功能测试开发),提供系统级及实车级测试验证服务,期待交流分享和合作的机会。
  • 热度 19
    2015-10-10 14:03
    2054 次阅读|
    0 个评论
    一、概述 开关系统是任何的测试系统中的关键的部分,它们允许客户通过不用的方式来连接测试仪器和被测件,从而确保了在测试的过程中被测件的不同的部分可以连接到测试仪器中,从而减少了需要用来测试的仪器设备。 很多用户可能会想到开关系统作为系统中的关键的部分,会由于各种原因而损坏,而不是因为开关系统本身不可靠。因为开关系统所处的位置是非常容易受损的,所以,意外的发生的可能性就更大了。 开关系统是基于继电器开关的,是属于机械装置,所以是有一定的使用寿命的,但是高性能的继电器的使用寿命是很长的。典型的电磁继电器(EMR)在小负载的情况下,寿命一般在1000万次,仪器级的簧片继电器拥有超过10亿次的操作次数。影响寿命的主要的因素是测试系统中的负载的特征还有开关的切换的位置的信号特征。不管是电子设备或者是继电器切换的信号是非常高的电压或者是电流,或者是在热切换(切换的时候,开关是带有信号)的情况下,将会产生电弧,从而腐蚀开关触点。 热切换对继电器的使用寿命影响很大,冷切换和热切换的影响往往是想差3个数量级的。研发者尝试着减少热切换的影响,但是事实上,很多测试由于时间方面的限制,是需要进行热切换的,这样可以防止在测试的过程中系统的重新启动或者是确保可以模拟间歇性的故障。热切换是研发者避免不了的。 其实测试系统中很多的故障不是由于继电器的正常寿命已经到了而引起,一些故障是在生产的阶段就无法进行检测而引起的。很多的故障是在测试系统中的一些意外的情况而引起的。一个经常发生的情况是系统的集成而引起的,例如由于不该连接的地方连接,如与电源之间的短路或者是在电容性的负载上进行热切换,从而引起的布线和软件方面的故障,从而影响到继电器。继电器可以阻挡部分的损害,但是随着系统的使用,继电器使用的寿命将会大大地缩短。就算正确地操作系统,但是如果进行一些故障的设备测试,这个也会给开关系统造成很大的压力。 二、开关故障诊断方法 由于开关系统的易损性,这就要求用户采用一些针对开关系统的测试检验的方式。在一些平台上,例如VXI,就曾经提供过一些继电器的检测的方法。这个方法包括了能够一些不太协调的自检方式,有时候它只是检测控制系统,而不是继电器的连接(其实这部分是很容易损坏的)。一些产品也可以检测继电器的连接,但是不能检测隔离继电器。VXI的产品包括了这方面的功能,是因为VXI的主要用户是军工和航空航天方面,这些测试的环境是非常差的,而且很少有空间可以进行自主检测。 其他的产品,如PXI,PCB板的大小有限,就很难提供自检工具。在自检工具的设计研发阶段,这些工具占用了很大的空间,这就减少了模块的密度,同时增加了成本。 由于成本和空间大小的限制,很多继电器的供应商会增加一种工具来解决这个问题,如继电器的操作次数的统计软件。在这个软件中,会统计继电器的操作的次数,从而在将要接近操作寿命的时候,将继电器更换掉。但是这种工具存在着以下的问题: 由于切换的信号的类别的不同,继电器的使用寿命将有3个级别的差距,但是这个软件不知道切换的信号的类型是什么,也就无法进行准确统计; 这个软件没有统计系统故障的能力,如被测件的故障,这个对继电器的寿命的影响很大; 簧片继电器是在不同的批次之中有不同的寿命,这个就增加了使用的不确定性。 根据以上的原因,开关系统就会有比开关的操作寿命相对长一点或者短一点的使用寿命,并且故障会产生数量级的影响而不是单纯的百分点的差别。所以如果用户基于这个软件来判别开关系统的寿命,那么将会带来不良的影响。现代的一些器件一般会比它们的理论的寿命更长。早期的预防性的措施将会替代来自其他部分的影响,特别是在前面接口部分的影响。所以就有一句哲学名言这样说的“如果在它工作的时候,你对它置之不理,那么当你开始怀疑它的时候,问题就出现了”。 三、系统级的测试 系统的集成电路中一般会包括系统水平的自主检测,特别是在系统是用来按照信号路径反馈的时候,自主检测的工具就可以执行了,例如,使用一个万用表来测试不同的路径的时候。在这方面的投入应该是很大的,而且会使系统变得复杂,路径的检测也变得复杂。系统集成商需要理解的路径的选择是在线缆接口和开关内部结合起来实现的。这样的工具可以确定在连接的过程中的故障的数目,但那是它们不能找到间歇性的部分或者故障的隔离,比如那个开关是否在系统中,或者是分辨不出是继电器或者是线缆的故障。 四、BIRST-内置继电器检测工具 自检工具已经发生了很大的变化。Pickering在2009年发布了PXI平台的第一代包括内置继电器自检工具的矩阵模块,名字叫做BIRST(Built In Relay Self Test)。这个工具是一个非常紧凑的PXI平台的计算机附件,它允许通过软件来检测在矩阵中的每个通道的阻抗,是通过不断的测试来完成的,往往是几个毫欧级的分辨率。每一个继电器都可以检测,如果有焊接短路或者是开路的继电器都可以快速地被找到,软件的分辨能力允许连接变量的变化。每一个独立的故障继电器都可以被快速地定位。下面是BIRST的用户界面: 用户需要做的是断开PXI模块,然后打开pickering提供的程序。测试的过程是很快的,每一个继电器大概就需要几十毫秒的时间。然后,软件会用图表来显示检测的结果,上面就是矩阵模块的形状,并且突出故障的继电器(如下图的红色标注的部分),这就方便用户快速地找到继电器的位置,并进行更换。 BIRST工具解决了老式的自检工具和继电器次数统计软件的缺点。它允许用户在没有额外的费用的情况下,快速地找到大量的继电器中的已经损坏的继电器,这可以避免不必要的拆卸或者关闭系统。这个工具也可以在继电器还没有损坏之前,通过检测到它的高阻抗,从而提前进行更换,这样对系统来说是一件好事。 BIRST工具同时支持系统级的测试检测,在运行系统级的测试的时候,可以集中精力与电缆和开关系统的测试。 五、BIRST数据表 用户关心的是怎么样将这个工具的结果跟数据表联系起来。BIRST通过不同的路径来检测故障,有些用户会用到仪表板。这些路径一般拥有比用户本身使用的线缆长度更长的长度,同时也包含了更多的继电器,所以阻抗往往会表现得非常的高。 另外,数据表中制定的路径的阻抗是生产过程中的焊接点的阻抗。跟随着继电器的使用,阻抗会变大,这些也受开关位置和开关类型的影响的,所以,当阻抗变化很大的时候,也就说明了开关已经步入了生命周期的晚期了。 六、使用范围 为什么BIRST只能用在矩阵上呢?因为它依靠的是两端连接(四端,用于双刀开关系统中)到系统中,是通过完整的路径来进行判断的。这个是一个复杂的过程,因为它要求这个工具通过仅有的这几个连接端来判断矩阵中的故障。一些隔离开关将会使得部分开关不能被检测到,这个时候就需要外接设备。配置别的矩阵的时候,由于会需要增加别的开关,也就会增加了一些问题。 在2015年,一种外部的测试工具叫eBIRST发布了,支持更多的矩阵面板,并且还支持非矩阵的模块,如通用的开关模块等。 七、BIRST解决方案 BIRST是在2009年发布的新一代的自检工具,它支持矩阵模块,这些矩阵模块的特点是拥有很多的继电器,有些拥有高达4406个继电器。升级版的是在后缀有一个大写的A字母,而且在未来,大部分的电流矩阵开关也将可以在BIRST中使用,而且不会增加额外的费用,因为旧版的工具可以作为赠品赠送。 在支持BIRST的产品中,它们说明书中会有BIRST的标志的。如下所示: 综上所述,可以看出BIRST作为一种开关模块的内置继电器自主检测工具,大大地提高了系统的自我检测能力,同时减少了故障排除的时间,提高了用户的使用效率,相信未来将会有更多的用户会用上这个工具的。 (本文译者 虹科电子 郑南润 转载请注明出处)
  • 热度 15
    2015-3-16 10:13
    1198 次阅读|
    0 个评论
    Pickering的内置继电器自检工具(Build-In Relay Self-Test)特征: PXI和LXI矩阵模块的完全自主的测试 检测焊接,开路和高阻抗继电器 不需要额外的设备或者是具备特殊的技能 最小的加载和维修时间 在同一个测试系统中进行复杂的测试和诊断,这是一个比较大的难题。Pickering的BIRST工具提供了一个快速而又简单的可以寻找LXI和PXI开关矩阵中的错误的方法。BIRST允许用户通过简单的指令来检测开关系统的操作,从而找出开关模块中的继电器的任何错误。 BIRST自检工具在检测继电器的错误连接方面是很在行的。为了进行这个检测,用户只要断开UUT(被测部件)的开关模块,并运行所提供的应用程序就可以完成了。不需要额外的配套设备,这个测试就可以运行并检测出模块内的任何有问题的继电器的位置。 程控开关模块是自动测试设备(ATE)系统中的一个基本的部分,它为测试设备互相连接的一块或者是更多的被测单元模块提供了一个灵活测试方法。如下图1所示是典型的程控开关矩阵。 图1  典型的程控开关矩阵 矩阵继电器拥有特殊的电压和电流,所以在电压或者是电流过大的时候,继电器会被损坏的--这个一般会在测试或者是调试的过程。损坏的继电器一般会有以下的情况: 永久性或者间歇性的开路/短路 电阻经常变化 这些都是无法忽略的错误,因为它们可能会让总线信号丢失并引起被测部件的预想不到的反应。 一般而言,在VXI或者是Pickering产品平台上的复杂的开关系统都会包括继电器的自主测试的功能。但是在PXI和LXI中,厂家就没有在小型的开关产品中添加自主测试的功能(在大型的高密度矩阵中就添加了该工具),因为密度的限制,还有就是实现自主测试的功能的费用问题。作为一种妥协的方法,一些PXI的开关方案中会包括继电器的部件,以便在继电器发生错误之前就可以预测。但是它有助于发现在没有指示的情况下,继电器模块是有多集中的。缺点如下: 单独的负载会减少使用寿命 使用一个预测性的维护方法(在继电器操作很多次之后就更换了)可以很容易就降低了开关系统的可靠性,因为更换继电器的时候可能会波及到附近的零件,并且还有潜在的对PCB造成损坏的可能性,特别是在继电器是贴片设备 Pickering拥有一个非常大的改进,就是改进测试方法,它现在可能在最少的价格和开关密度中包含了PXI所有的自主测试的功能,这样的做法深受那些习惯在他们的方案之中用到这些测试功能的用户的喜欢。BIRST将会识别开关模块中任何的继电器错误,同样也可以检测一些可能在错误的过程中出现的连接方面的恶化的问题。如图2所示是BIRST检测到的典型的继电器错误信号。 图2  被BIRST检测到典型的继电器错误信号 为了进行测试,用户只需要断开UUT上的开关模块和测试设备,并运行提供的应用程序。不需要额外的设备,测试就可以自动运行,并识别在模块内的继电器的任何错误。如果开关矩阵是直接连接到一个相互连接的接收器中的话(如下图所示),BIRST将会在不用移动任何连接的情况下执行任务。 图3  开关矩阵连接到接收器中的情况 BIRST工具是不可以在部分客户自主研发的位于ATE系统中的自主测试应用中进行更换的。这个系统标准的用法是用一个外部的DMM和回路机械来检测开关和线缆的连接错误的。BIRST在UUT和设备是在没有连接到一个开关系统的时候进行操作的,如果BIRST发现不到开关的错误和一个系统工具没有找到错误的时候,那么这就是线缆系统的问题了。用户不需要设计诊断开关错误的软件,只需要考虑设计系统自检的任务就好。这样大大地减少了测试的时间。 图4  诊断界面 要想了解更多关于BIRST工具的功能,可以跟我联系,大家一起学习探讨。
  • 热度 23
    2014-12-19 14:17
    3701 次阅读|
    2 个评论
      最为实用的Profibus故障诊断仪 “再也不能没有它(Profibus Tester)了” ——谢晓锋 广州虹科电子技术支持工程师         在Deckel Maho Pfronten(德国公司),每一台设备都必须带有合格的详细测试报告,报告内容必须包括总线物理层及通信层,才能够在工业现场正常地使用。而Softing公司的Profibus Tester 4在这一测试过程中扮演着一个至关重要的角色,它保证了设备的运行质量和故障的可探测性。         现代设备的高精度、高可靠性对于设备厂家来说是至关重要的,因为这是他们能够在竞争如此激烈的设备生产领域占有一席之地的资本。所有的设备厂家都知道坚持技术的创新是保持设备高质量和高可靠性的唯一途径,而目前的技术焦点在于现场总线技术。Deckel Maho Pfronten GmbH电气装配部门的部门经理Klaus Asen这么说到:“我们的客户中,特别是来自于汽车工业和设备供应行业的,他们都需要一些可以保证我们公司产品运行质量的证明。以往的做法仅仅就是在设备中加入一个信号示波器,而现在我们用的是Softing公司的Profibus Tester 4,它可以提供我们设备的各种详细信息。”       图1:Profibus Tester 4(BC-600-PB)是一款能够在运行过程中进行总线诊断的强大工具。它不单单能诊断总线,还能随意诊断各个设备,即使没有PLC运行,它也能轻松地完成诊断。 Profibus Tester是最顶级的诊断设备         在Deckel Maho Pfronten GmbH电气装配部门,Profibus Tester已经成为他们的设备和现场服务工程师不可或缺的一部分。一开始Klaus Asen并不觉得总线诊断工具对他们来说很容易上手,因为在还没使用Profibus Tester之前,市场上所有的诊断工具都需要文件配置并应用于特定的环境中,比如测试信号质量,扫描零散故障,或进行最终质量控制,但是Profibus Tester的出现彻底抹平了他的顾虑。他补充到:“Profibus Tester取得成功的因素在于它形象化地提供了现场设备的各种有效数据,而其他厂家的诊断工具仅仅只是以十六进制的格式去显示分析数据。我们最感兴趣的是Profibus Tester能够快速地反馈信号的质量,通过这种方式,我们可以直接得出造成故障的原因,比如是否存在失效的终端电阻,是否存在有缺陷的线缆,或是否存在不正确的连接方式等等。而且Profibus Tester精细的工艺设计更是其锦上添花之处。”另一个至关重要的方面在于Profibus Tester能够在诊断的过程中进行数据记录——可作为设备能够在总线系统中完整正常运行的质量凭证,或用于生成记录文件存放于设备文件资料中。   图2:Profibus Tester 4:信号测试,可存储示波器,协议分析,模拟主站 一个工具可满足所有的诊断         之前一个完整的总线诊断工具至少包含了两个独立的部分,分别用于物理层诊断和通信层面的分析。而现在仅仅一个Profibus Tester 4就包括了信号测量,可存储示波,模拟主站,协议分析等多种功能,这使得它完全可用于设备试车,系统验收,总线排故等。另外,Profibus Tester 4不仅可以手持使用,而且可以连接PC或笔记本并用Profibus Diagnostics Suite软件进行诊断。Klaus Asen还提到Profibus Tester使用起来非常容易上手,测试结果也清晰易懂。您只需一个按钮或点击一下鼠标就可以进行诊断,诊断的结果可以清楚直观地显示在自带的显示屏上,或显示在Profibus Diagnostics Suite软件上,即使使用者没有足够的经验也能够轻松地进行诊断。Profibus Tester 4连接上总线系统之后就可以自动地扫描波特率和开路电压。在手持方式下,Live Mode模式可以简单地实现总线诊断;在PC方式下,Profibus Diagnostics Suite软件提供了更多的选项用于分析和显示诊断结果。例如,Profibus Diagnostics Suite的状态栏可持续地指示当前总线的状态;利用Network Status功能可对总线进行快速诊断或自定义诊断;拓扑功能(Topology Scan)可反映整条总线和各个从站之间的线缆长度;趋势图功能(Trend Test)可及时发现和识别零散的故障。而对于更为专业的用户,Profibus Tester 4提供的示波器功能和报文帧分析功能允许用户进行更为彻底,更为细节的总线分析。 再也不能没有它(Profibus Tester)了        “我们不敢想像要是装配部门没有十二台Profibus Tester的话会是什么样子。我们利用这套工具进行设备的最终验收以保证设备处于完美的工作状态,而当试车过程中有问题出现时也能被及时地发现并解决,”Klaus Asen解释到“在大多数情况下,问题都是零散故障造成的,但一般不会立即导致设备故障,只有当这些故障持续一段时间之后就会导致设备的紧急停机并被断定为Profibus故障。在这种情况下,我们会把Profibus Tester连接到总线系统中实时检查所有Profibus设备的信号电平,一旦信号电平过低,说明一定有问题出现。”Klaus Asen还举了个例子:每一个被错误配置的设备都存在两个终端电阻,一个在内一个在外,这两个电阻造成的零散故障很难被立刻发现的。而Deckel Maho Pfronten GmbH的现场调试服务工程师只需简单地连接Profibus Tester到总线中就能够及时地发现那些信号水平比其它设备低的设备,然后再详细检查一下这些设备,就能快速地发现过剩的终端电阻并解决问题。 总结         Klaus Asen认为使用Profibus Tester 4最为关键的好处在于可以缩短查找总线故障的时间,使故障分析变得更加快速,从而大大节约了公司成本。他在总结与Softing公司的合作中说到:“Softing在各个方面都给他们留下了深刻的印象:从购买决策阶段的面对面演示再到后期的功能分析和广泛应用,他们都尽心尽力,并给我们的团队在评估解析转堵方面提供了专业的技术支持。”
  • 热度 34
    2012-10-25 13:45
    3589 次阅读|
    13 个评论
      公司有系列产品使用一个附件,需要进行有针对性的实验,以验证产品与附件的符合性质量指标。   该专项实验落实在公司品管部属辖的实验室实施。   实验室以成品做为实验样机,安装此附件,产品开机工作,进行室内常规环境下的老化性实验。   关于实验方法上,有一点疑问,特此请教业内各位行家里手,谢谢!   实验方法规定:当实验样机出现故障时,实验室实验人员不能对其断电,就是不能按动产品样机上的电源开关。立刻通知开发部的技术人员来进行处理。   这听起来,似乎合理。这要看对此实验的定义。   严格来讲这是实验,不是试验。   一个“实”字,体现了是站在用户实际使用的角度来验证产品质量的合格与否。   “试”,更多的是体现产品在研发阶段,包括要制定的产品质量合格之标准,此标准正式实验的依据。   问题:既然是实际使用合格与否之验证,为什么产品样机上电源开关都不能使用?   使用中,产品机出现故障了,关机,再开机,这是常见的使用操作,起到所谓上电复位的作用。   试想,这样的产品到用户使用时,出现故障,难道也要不断电?联系售后服务的修理人员来现场分析和修理?   再想,出故障,不准断电。那断电,会出故障吗?   大家怎么看?
相关资源