路径: 主页 > GB/T > 第297页 > GB/T 9414.5-2018 | 标准编号 | GB/T 9414.5-2018 (GB/T9414.5-2018) | | 中文名称 | 维修性 第5部分：测试性和诊断测试 | | 英文名称 | Maintainability -- Part 5: Testability and diagnostic testing | | 行业 | 国家标准 (推荐) | | 中标分类 | K04 | | 国际标准分类 | 21.020 | | 字数估计 | 54,510 | | 发布日期 | 2018-06-07 | | 实施日期 | 2019-01-01 | | 发布机构 | 国家市场监督管理总局、中国国家标准化管理委员会 | GB/T 9414.5-2018
Maintainability--Part 5: Testability and diagnostic testing
ICS 21.020
K04
中华人民共和国国家标准
代替GB/T 9414.7-2000
维修性 第5部分:测试性和诊断测试
2018-06-07发布
2019-01-01实施
国 家 市 场 监 督 管 理 总 局
中国国家标准化管理委员会 发 布
目次
前言 Ⅲ
引言 Ⅳ
1 范围 1
2 规范性引用文件 1
3 术语和定义、缩略语 1
3.1 术语和定义 1
3.2 缩略语 5
4 测试性描述和诊断测试 5
4.1 概述 5
4.2 测试性目的 6
4.3 诊断测试的目的 8
4.4 用于诊断测试的方法 8
4.5 用于状态监测的方法 8
4.6 测试性的概念 9
5 测试性规范 9
5.1 概述 9
5.2 工作说明 9
5.3 规范 9
5.4 测试性特性 13
5.4.1 测试性的特征 13
5.4.2 运行环境 13
5.4.3 测试任务 13
5.5 测试性评估的特征值 14
5.6 选择诊断设计的评价标准 14
6 开发过程中的测试性 15
6.1 概要 15
6.2 功能分配 17
6.3 测试性工程 17
6.3.1 测试性设计准则 17
6.3.2 测试性设计 17
6.3.3 商用现货(COTS)的使用 18
6.4 测试性研发过程 18
6.4.1 后勤支持 18
6.4.2 可用性和诊断测试 19
7 测试性评估 19
7.1 概述 19
7.2 分析验证 19
7.3 测试验证 19
8 测试性文件 19
附录A(资料性附录) 故障识别和故障定位的特性计算 20
附录B(资料性附录) 可测产品的开发步骤 24
参考文献 47
前言
GB/T 9414《维修性》分为以下几个部分:
---第1部分:应用指南;
---第2部分:设计和开发阶段维修性要求与研究;
---第3部分:验证和数据的收集、分析与表示;
---第5部分:测试性和诊断测试;
---第9部分:维修和维修保障。
本部分为GB/T 9414的第5部分。
本部分按照GB/T 1.1-2009给出的规则起草。
本部分代替GB/T 9414.7-2000《设备维修性导则 第四部分:诊断测试》,与GB/T 9414.7-2000
相比主要变化如下:
--- 规范性引用文件中增加了对IEC 标准的引用;
---第4章修改为“测试性描述和诊断测试”;
---第5章修改为“测试性规范”;
---第6章修改为“开发过程中的测试性”;
---增加了第7章“测试性评估”和第8章“测试性文件”。
本部分使用翻译法等同采用IEC 60706-5:2007《设备维修性 第5部分:测试性和诊断测试》。
与本部分中规范性引用的国际文件有一致性对应关系的我国文件如下:
---GB/T 2900.13-2008 电工术语 可靠性与服务质量(IEC 60050-191:1990,IDT)
---GB/T 9414.1-2008 维修性 第1部分:应用指南(IEC 60300-3-10:2001,IDT)
---GB/T 9414.2-2012 维修性 第2部分:设计和开发阶段维修性要求与研究(IEC 60706-2:
2006,IDT)
---GB/T 9414.3-2012 维修性 第3部分:验证和数据的收集、分析与表示(IEC 60706-3:
2006,IDT)
本部分做了下列编辑性修改:
---修改了标准名称。
本部分由中华人民共和国工业和信息化部提出。
本部分由全国电子电工产品可靠性与维修性标准化技术委员会(SAC/TC24)归口。
本部分主要起草单位:工业和信息化部邮电工业标准化研究所、北京邮电大学。
本部分主要起草人:夏海轮、武冰梅、曾志民、刘银龙、黄正磊、黄蓉。
本部分所代替标准的历次版本发布情况为:
---GB/T 9414.7-2000。
引 言
测试性是系统或设备的使用和维修中的一个重要特性,对系统或设备的可用性和维修性起举足轻
重的作用。诊断测试可以人工进行,也可用具有不同自动化程度的测试设备进行。测试性的优化设计
要求设计、使用和维修组织间的密切协作。本部分旨在强调测试性和诊断测试多方面的要求并有助于
彼此间的及时协调。
在本部分中,合同对象:系统、设备或功能部件,统称为“产品”需要考虑测试性设计。每个产品需
执行其必需的功能,这些功能宜在研发和生产阶段进行校验并在整个寿命周期中得到保持。为保持产
品的功能性,在该产品运行的任何时间都要知道每个子功能的功能状况。如果发生失效,宜采取措施确
保识别故障并定位产生故障的单元。产品测试性的要求可能看来很简单,但是如果在产品开发开始阶
段没有对其考虑,随后的实现将导致工作量的增加和成本的显著提高。如果所有要求在开发开始阶段
都能实现,研发工程师不需要大量额外的工作就可以详细说明功能特性“测试性”,从而可以显著地节约
成本,例如通过减少检验开发结果的测试步骤数节约成本。经验表明,开发阶段的额外成本和工作可以
得到补偿,例如现有的测试设备可用于生产阶段。可靠的故障识别和低廉的运行过程中的维修成本,大
大增加了可测产品的市场价值。
由于本部分适用的产品涉及广泛的技术,本部分采用通用方式对有关工艺和技术内容进行撰写。
因此,本部分只提供对产品估计的评估依据和实现必需的产品测试性的基本方法。产品的故障识别和
故障定位的技术实现是产品开发工程师的任务,该技术的实现依赖于产品开发时的技术水平。因此,所
需的测试任务是以硬件形式或者软件形式来实现并不重要,重要的是所有功能都能通过测试路径来检
查,且已确定的测试性特征值和给定目标值相符。如果与目标值有偏差,宜采用措施以确保目标值得到
满足。这些措施宜在冻结设计前的开发早期阶段进行实施。
维修性 第5部分:测试性和诊断测试
1 范围
GB/T 9414的本部分目的在于:
---为在设计和开发中早期考虑测试性方面的问题提供指南;
---有助于确定有效的测试程序作为运行和维修的组成部分。
本部分适用于包括商用现货在内的所有类型产品,无论是机械、液压、电气还是其他技术。另外,本
部分适用于任何产品的开发,使得产品特性是可验证的(可测的)。
本部分的目标是确保在开发初期就定义好与产品测试性相关的先决条件,使得由客户制定的条件
在开发过程中落实、记录归档和验证。
本部分还提供了作为产品设计一个完整部分的测试性的实现和评估方法,并建议在产品寿命周期
内宜对产品测试性文件不断更新。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文
件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
Part3-10:Applicationguide-Maintainability)
IEC 60706-3 维修性 第 3 部分:验证和数据的收集、分析与表示 (Maintainabilityof
3 术语和定义、缩略语
3.1 术语和定义
IEC 60050-191界定的以及下列术语和定义适用于本文件。
3.1.1
机内测试 built-intest;BIT
产品内在的能自动识别和定位故障的测试。
3.1.2
机内测试设备 built-intestequipment;BITE
用于实现机内测试功能的硬件和/或软件。
3.1.3
商用现货 commercialoff-the-shelf;COTS
标明商用的现成产品。
3.1.4
危害性 criticality
故障的影响程度。
注:危害性用级数来表示,级数越高,故障所引起的预期后果就越严重。
3.1.5
测试深度 depthoftest
一个单元或子单元测试级别的说明和描述。
3.1.6
设计层级 designlevel
在产品分解结构中,对现存的设计要素(功能和/或物理单元)指定的层级。
注:有些情况下,“设计层级”也称作“约定层次”。
3.1.7
诊断正确率 diagnosiscorrectness
产品的故障在给定条件下能被正确诊断的比例。
3.1.8
诊断测试 diagnostictesting
用来进行诊断的测试程序。
3.1.9
虚警 falsealarm
有故障指示时未发现故障的情况。
3.1.10
虚警率 falsealarmrate
故障指示中虚警的百分比。
3.1.11
故障识别时间 faultrecognitiontime
出现失效的时刻到故障被识别之间的时间。
3.1.12
故障模拟 faultsimulation
为检验诊断能力,在硬件单元中采用非破坏性的干预使故障产生和/或通过软件模拟故障。
3.1.13
功能 function
产品所要求具有的能力。
注:在产品分解结构中,功能总是与指定层级相联系。
3.1.14
功能模型 functionalmodel
描述激励与测量(响应)终端之间相互影响、相互依赖关系的概念性表示。
注:产品开发中的功能模型是显示产品功能,并辅以由开发者制定的测试路径的主要框图。
3.1.15
功能测试 functionaltest
测试硬件单元的所有指定功能以检验产品能力。
3.1.16
硬件单元 hardwareunit
以硬件形式实现功能和/或子功能的设计要素,也可能包含软件部分。
3.1.17
现场可更换单元 linereplaceableunit;LRU
可由用户或维修支持方直接在设备上更换的可更换硬件或软件单元。
3.1.18
维修方案 maintenanceconcept
设计水平和用于产品维修的维修水平间的相互关系。
3.1.19
维修策略 maintenancepolicy
基于所有者、使用者和客户的目标和策略所提供维修和维修保障的通用方法。
3.1.20
监测 monitoring
在选定的运行模式下,对其功能自动观测,且不影响运行。
3.1.21
运行环境 operationalcontext
产品运行所期望的环境。
3.1.22
参数 parameter
规范功能的物理量。
3.1.23
产品 product
指定的可交付物品或服务。
注1:从可信性角度讲,产品可能是简单的(例如一个器件,一个软件算法),也可能是复杂的(例如一个系统或一个
包括硬件、软件、人为因素、辅助设施及活动的综合体)。
注2:产品有自己的生命周期阶段。
注3:product和item有相同的定义。
3.1.24
形象表示产品单元和子单元物理构成的树形结构。
3.1.25
车间可更换单元 shopreplaceableunit;SRU
可在用户库房/车间、同等级的维修支持方或在供方车间更换的硬件或软件单元。
3.1.26
信号 signal
表示信息的物理变量。
注:一个信号可由一个或多个参数表示。
3.1.27
规范 specification
在给定等级的产品分解结构下,对产品功能的详细描述。
注:规范一般源自系统需求并且可以验证。
3.1.28
工作说明 statementofwork;SoW
详细说明提供的货物和服务的文件。
注:工作说明由客户提出或接受,定义了合同中提出的工作和由承包者提供的工作。因此,工作说明形成了主要技
术文件,根据该文件投标者提出他们的出价,承包者执行该工作,客户接受提供的货物和服务。
3.1.29
激励 stimulus
用于触发某种功能的具有确定参数的输入信号。
3.1.30
子功能 sub-function
功能的细分(参见3.1.13功能)。
3.1.31
端口 terminal
用于测试产品信号的物理接入点的通称。物理实现或同义的相关术语有:
---插头;
---连接器;
---插头/插头型连接器;
---测试点;
---接口;
---转接口。
注:端口通常是由唯一的标识符来标识。
3.1.32
测试方案 testconcept
系统测试性需求分析结果的描述和如何满足需求方法的规定。
3.1.33
测试覆盖率 testcoverage
在给定测试规程下能诊断出有故障的功能数与总功能数之比。
3.1.34
测试设备 testequipment
实施测试所需的工具(硬件和/或软件)。
注:测试设备根据测试所涉及的技术分为机内测试设备(BITE)和机外测试设备。
3.1.35
测试规程 testinstruction
描述在测试规范中所要求的测试如何实现的文件。
3.1.36
测试路径 testpath
从相关联的硬件单元至端口测试步骤的描述。
注:此外,测试路径定义了激励与响应的(功能)关系。
3.1.37
测试序列 testsequence
一系列的测试步骤。
3.1.38
测试规范 testspecification
详细说明测试序列、参数和功能的文件。
3.1.39
测试步骤 teststep
硬件单元进行测试的最小单位。
3.1.40
测试任务 testtask
满足故障识别和定位说明的所有必需测试的总和。
3.1.41
测试性 testability
确定产品在规定条件下能够被测试的程度的设计特性。
3.2 缩略语
下列缩略语适用于本文件。
BIT:机内测试(built-intest)
BITE:机内测试设备(built-intestequipment)
COTS:商用现货(commercialoff-the-shelf)
DP:数据处理(dataprocessing)
FL:故障定位(faultlocalization)
FT:功能测试(functionaltest)
FTA:故障树分析(faulttreeanalysis)
LCC:寿命周期费用(lifecyclecost)
SoW:工作说明(statementofwork)
SF:子功能(sub-function)
4 测试性描述和诊断测试
4.1 概述
在产品设计及其寿命周期的各个阶段内,都考虑产品的测试性有助于对产品进行高效、经济的运行
和维护。产品维修方案包括适用的诊断测试方法。测试性和诊断测试的实现是在产品的寿命周期内完
成的。
寿命周期费用(LCC)是评价任何设计质量的一个越来越重要的方面。许多顾客除了关心直接采购
费用之外,还要求控制与日常使用、维修及后勤保障相关的费用。这些费用主要受产品可靠性、维修性
和维修保障特性的影响。在这个意义上,诊断测试技术的应用有可能使LCC的一部分费用显著降低。
但在确定诊断测试要求时,应考虑LCC优化所带来的限制。
本部分适用于产品寿命周期的所有阶段,即:从确定产品需求的设计和开发阶段到制造和安装阶
段,最终到运行和维修阶段,见图1,具体包括:
a) 设计和开发阶段
从产品的概念到实现,产品需求应同其应用领域的具体要求相符,必要的情况下,可经历一些
先期阶段。
b) 制造和安装阶段
在此阶段,需要使用当前设备验证诊断技术并评估产品的性能。准备文件并开始对运行和维
修人员进行培训。
c) 运行和维修阶段
由于老化,被测设备可能会产生变化。考虑到诊断测试的连续需求,测试设备的测试功能需要
延续并更换或升级。在后者情况下,测试设备需要在新开发阶段重新设计。
通过使用本部分,产生产品必要数据/信息的前提条件将得到满足,并且这些前提条件在产品整个
寿命周期内可以验证和更新。
附录B给出了根据产品/系统设计如何进行测试性开发、记录归档和验证的例子。
诊断测试包括:
---功能测试,目的是验证功能是否仍然有效。
---状态监测,跟踪设备状态随时间的退化情况。
状态监测同诊断测试的有关概念密切相关,两者密不可分。但是,本部分只包含状态监测的部分
内容。
说明:
TS---测试规范;
CE---并行工程;
M1---确认要求;
M2---分析验证;
M3---测试验证。
图1 寿命周期内的测试性和诊断测试
4.2 测试性目的
设计和开发阶段的测试性与维修性、可用性和安全性密切相关,测试性的主要目的是为每个系统功
能解决以下问题:
a) 诊断测试能否监测到功能故障。由于安全性的限制或测试可能具有破坏性(例如:对转子测试
超速能力),某些功能是无法进行全面测试的。
b) 测试是否可行。功能故障的危险性、测试费用(测试设备的费用,测试设备维修费用及测试费
用)以及使用较好的、较便宜的替代品不一定导致测试经济效益的提高。
注:在a)和b)两种情况下,需采取备选方案来确保这些功能在产品的寿命周期内能够正常运转。同时,这些因素也
会影响测试覆盖率。由于不能在系统寿命周期内通过测试来确定系统的运行运转情况,低测试覆盖率也许是
有害的,但在好的维修性和维修能力下,测试不是必须的。
c) 在寿命周期的哪个阶段进行系统功能测试。应该在寿命周期的每个阶段都考虑测试能力。比
如,功能测试在单元级是可行的,但在系统级测试是不切实际的。这可以通过洗衣机及其排废
水功能的例子进行解释。从用户的角度来说,通过预先运行测试来确认功能可以正常运转是
有益的(运行阶段测试是无用的)。这个功能的设计不需要使用测试设备来对功能进行测试,
这是因为:
1) 抽水机和相关部件的寿命比产品寿命长(其他故障及其维修费用限制了产品的寿命);
2) 能够便捷地使用排除可能故障的维修方法;
3) 能够在单元测试和交付前的系统测试中充分地测试完成排水功能的单元;
4) 哪一个阶段进行测试也会影响寿命周期费用。
d) 测试需要进行到何种深度。测试深度也是一项非常重要的标准,如在上面的例子中,它和维
修观念是密切相关的。测试深度指明了区分单元或子单元的标准。例如:系统测试如果不仅
能识别需要替换的单元,而且能在几乎不影响费用的情况下识别需要更换的子单元。这就能
减小与单元级测试中识别和更换发生故障的子单元相关的测试设备费用。
核实所有开发的功能是测试性设计基本的原则。但需注意,测试覆盖率不必达到100%,
因为测试本身在运行过程中可能产生故障,这比非测试故障,如测试或虚警带来的故障更严
重。若涉及系统安全,无须所有测试覆盖率都达到100%,因为测试本身可能损害系统安全。
在系统运行过程中,测试提供牢靠的保证是很重要的,为了达到这个目的,应精确确定测试覆
盖率与100%的偏移量。
无论如何,测试性目的不应和更高等级的目的相冲突,如可用性。
e) 如何管理虚警和“未发现故障”。在故障并不存在的情况下,系统测试可能检测并向用户发送
故障报告。这样会引起不必要的调查并最终导致虚警报告。当诊断为“未发现故障”(nofault
found)时,也可能导致不必要的维修行为。各种方案的虚警率不能超过已规定标准,且应尽可
能地减小至0。为减小虚警和“未发现故障”的发生可引入反馈系统,该系统将不断地评估环
境并校准自身以适应部件在已规定标准内的损坏。反复测试消除虚警(测试方案可能因未产
生警报而完全改变)会增长测试时间,应尽量避免使用。
当不存在故障时也可能显示故障。这是由于多种原因:
1) 如果在系统中发现了一个故障,且诊断出了发生故障的部件。但拆下该部件对其单独测
试并未发现故障后,应检查同故障部件的测试规范相关的系统测试规范;
2) 诊断不足(测试中不能完全识别发生故障的部分);
3) 接口故障(例如,连接故障可导致移除某个单元后重新连接可以消除故障);
4) 欠佳的测试设备包括BITE(例如,发现的故障并不存在);
5) 间歇性故障(劣质部件在某些特定情况下会出现故障);
6) 设计容差累积故障(单元测试没有故障但系统测试有故障)。劣质部件在容许范围的极端
情况下,会引起叠加的指标超标;
7) 软件故障(使用不当的测试方法所引起的故障);
8) 维修人员和用户......
|