精华内容
下载资源
问答
  • 产品的可靠性设计方法,从表面上看都是技术问题,但实质上包含技术和管理两个... 系统分类: 电子制造 | 用户分类: 可靠性技术 | 来源: 原创 | 【推荐给朋友】 | 【添加到收藏夹】 中小企业提升产品可靠性的几大

     

     产品的可靠性设计方法,从表面上看都是技术问题,但实质上包含技术和管理两个方面,没有技术不行,有了技术,如何把技术贯彻到位也会有好多细节该注意。所以本文的可靠性提升方法中也包含进去一些设计管理方法的内容。

     

    系统分类: 电子制造   |   用户分类: 可靠性技术   |   来源: 原创   |   【推荐给朋友】   |   【添加到收藏夹】

    中小企业提升产品可靠性的几大难题,经过笔者多年来和各类企业的多位技术管理者的交流,不外乎几个问题:
    1可靠性概念太复杂,又是概率又是英文简写的专业词汇,不知道和我的产品有什么直接的联系,不知道这些技术指标如何用于评价产品的可靠性程度;

    2可靠性试验一般要求较多的样本数量,公司规模较不大,生产的是专业化设备,批量很小,小批量设备下如何开展可靠性试验摸不着头绪;

    3公司每年的营业额不过几百万几千万,没有那么多的资金用于可靠性试验费用和设备的购置;

    4公司想提升产品可靠性,也想配备专业技术人员,但这方面技术人员难招到,即使招到大都是外企的背景,要价较高,干了一年多也没什么成效;

    5以上措施都不好使时,那就寄希望于设计人员个人的技术水平比较高,设计出的东西能耐用,但是一台机器不能只靠一个人完成,就像木桶盛水多少取决于最短的那块木板一样,机器的整体水平往往在最薄弱的环节暴露故障,我们也不可能保证每个项目的设计者都是梦之队成员。

    6请专家帮助,如大学、科研院所、华为、中兴等大的机构的人员来进行指导,最后的结果往往不了了之,似乎是在听天书,专家说的全对,就是没办法实施,对中小企业这也是现状,也让人困惑无从下手。

    以上这些问题,有些是我们中小企业管理者的错误认识,有些是我们的企业现状的无奈,还有就是国家整个的产业技术环境造成的,我们不必怨天尤人,在迷茫中立足于企业现实开始我们的产品可靠性提升之旅。

    产品可靠性问题出现的原因分为两个,一个是设计的可靠性(也称固有可靠性)是否好;一个是固有可靠性在生产使用中是否能得到技术管理保障。现在大多数学者的可靠性研究集中在可靠性保障方面,中小企业技术管理者的几点困惑就是这种现象导致的,可靠性保障似乎成了可靠性的全部,但中小企业的现实是产品的固有可靠性设计的就很不好,后面再怎么保障能使可靠性维持在较高水平呢?设计是产品可靠性的基础,对军工企业、大企业,他们的设计可靠性是可以保证的,然后再讲可靠性试验、预计、保障是对的,但中小企业产品的设计可靠性就不好,就该把重心放在产品可靠性设计的技术方法和设计控制管理上才对。以下的方法就是基于这个基本思路展开。

    1基于产品故障的失效分析和失效预防

    产生上面几条感慨的企业一般都有几年的时间了,对于这种企业,其实掌握着一个宝藏,对这个宝藏妥善利用了,产品的可靠性将有非常明显的提升。这个宝藏就是过去几年的投诉记录和质量分析记录。对这些记录统计,组织分析原因,实验确认这些原因确实是导致失效的因素,然后研究出预防措施,余下的就是在公司运营中确保预防措施被执行了。做到了这几点,产品的可靠性提升将是显而易见的。这个分析和试验的过程会涉及一些较高难的技术方法,但依常规80%以上的问题会很容易就被解决的。

    以笔者经历的一个案例来说明,一个液体流量阀,里面有一个靠弹簧顶住的截流板,偶尔有客户投诉我们的产品未开机就漏液,原来在研发实验室的时候,没有发生过这问题,技术人员也没太重视,此时就一直拖下去了,后来公司加了项考核指标“投诉问题解决率”(解决的问题数占总投诉比例数的百分数),研发才真正重视起来,开会分析原因(如下图)。

    然后一项项试验,液体源实验也不用太复杂,塑料桶开个孔,把桶里水的液面抬高,出水管口的管压增大看阀是否漏水,发现不加压就漏,加压漏得更厉害;把截流板拆到另一个阀上试验配合是否紧密,确认了配合没有问题;最后确认换成原来研发用的弹簧,发现不漏液,换回来就又漏;初步确认为弹簧问题,检查弹簧在挂上相同重量的物体后,形变有差异,研发用的弹簧形变小。多次几个不同弹簧验证,确认失效原因是弹簧在多次使用后弹性系数发生变化,而设计图纸上又没有关于这项指标的检验方法,因为没有检测弹簧的工具,并且形变是发生在使用一段时间之后在公司也不好入检。于是找采购人员查厂家的信息,发现研发样件的厂家和批量生产厂家不是同一家,所以就在外购件规格书上对供货厂商进行了指定,制定研发样件的厂家为供应商,并封样,要求厂家按照封样的弹簧的材料、规格和强度等指标供货,公司舍不得买台弹簧拉压测试仪,就通过非技术手段解决,不过后来此类问题也没再发生过。

    从这个事例看出,很多问题的分析其实也并不是很复杂,解决问题的预防措施也未必就是改动设计。只要我们肯静下心来,静心分析,解决也并不难。液压变化的实验装置也是大家集思广益的结果。

    通过这种方法,有了价值50元钱的电快速脉冲群测试仪、有了价值200元的辐射抗扰度测试仪、有了价值300元的盐雾试验箱,有了我们产品的常见失效模式,然后有了针对性措施,产品可靠性有了明显增长。

    这个方法的执行要素有几点:有故障数据和现象记录;有技术分析会议;针对分析的实验;针对试验结论的分析结论;针对结论的预防措施和实施到位。有人说,这么简单,但事实上就是这样简单的事情没做好,最常见问题的两个地方是:针对分析的实验方面不具体;针对试验结论草率下结论。这都是人存在的弱点,不是技术的难度。

    总结到一点:针对故障投诉作失效分析,得出失效机理,针对失效机理制定实施预防措施。

    2加强系统设计技术和系统设计管理

    走访很多公司没有系统设计部门,有的有系统设计人员,但干的事研究的问题不够系统。最常见的模式是一个资深的技术人员当项目经理,带着几个小毛头搞设计,几个这样的项目队伍对一个技术部经理汇报。然后产品出现投诉了,经理的常见解释就是“招水平高的招不到,都怪这帮工程师水平差,就这样还老闹着加薪跳槽”。这些人里头也不是没有几个高手,但都是项目经理,也要承担具体的设计。木桶盛多少水取决于最短的那块木板,项目经理能干也没用,产品该出毛病还是出毛病。这个现象的解决方法就是加强系统设计的管理,对系统设计人员要学点系统设计知识。

    系统设计管理方法也很简单,设置系统设计岗位或部门,让设计水平较高、知识面较宽的人才到这个职位来,如果公司规模较小,就让这个岗位负责系统设计和设计审核,如果研发规模够大,就系统设计和设计审核岗位分开,但一定注意,必须把资深的高人放在这两个岗位上。这样,所有设计人员的设计细节都要被高人审核,不合格则退,最后出去的设计成果基本上就符合了审核人的水平,这样,最短的那块木板就补上来了,原有的人员结构也未发生变化。审核人员和系统设计人员属于同一个团队,系统设计的思路一定要贯彻到审核人员的脑中,审核中确保设计系结执行了系统设计要求。比如系统设计要求工作温度满足-40℃,那审核时器件的温度规格必须都得满足此要求。这是一个管理组织架构上的要求,没有这个审核机制的保证,系统设计思路很难贯彻实施好。

    第二是系统设计方法的问题,这是要系统设计人员掌握的,太多的中小企业,系统设计几乎是缺位的,即使较牛的一些项目经理似乎被冠以系统设计师的title,但没能落到实处,常犯的错误理解就是:
    系统设计=法规标准设计要求+客户功能需求;

    这是很不全面的,仅按照这两种因素设计,就忽视了很多其他的技术要求,并且往往就这两个要求也大都理解得不全面。下面举一些与可靠性设计有关的系统设计知识点,如产品系列规划、目标功能和用户定位、工程计算、历史失效数据分析、法规标准、知识产权、器件选型、生产检验运输过程、安装交付、极限环境条件、可用性、可维修性、模块接地与系统接地、热设计、EMC、震动噪声、盐雾、接口等,这些都是和系统设计有关的技术内容。有人会说“要把你这些要求都做了,那得多少技术人员啊?”,答案是1个,规模小点的企业一个都不用,别被这么多的系统设计要求给吓住,其实每一细项里,常规的技术要求和技术点也就那么几项,非常少的,这几点都不必单独设计,只要在选择设计方案时按照技术点去选,系统设计就被执行了,后面的诸多问题就迎刃而解了。比如电磁兼容EMC,最复杂的一个技术要求,在标准测试上的考察项目是4个EMI指标(RE、CE、Harmonics、Flicker)和7个EMS指标(RS、CS、ESD、EFT/B、DIP/i、PMS、Surge),它的要求主要集中在面膜、机壳的密封接缝方法、机壳材料、机壳开孔的处理、机壳对外的电缆处理、电源模块几个关键地方,在系统设计时面膜的安装方式、面膜的设计上选择防静电处理方式或在面膜后面加块接机壳地的金属背板,金属板上的电接头选择带滤波的插座,这种方式一下就能改善EMC的ESD、RE、CE、RS、CS等几个隐患;再比如模块接地与系统接地的考虑,先画出系统接地图,这样整机的电气安全、接地阻抗、对地漏电流等指标的关键薄弱点就一目了然了,也能估计出板间信号可能造成问题的隐患薄弱环节,哪些地方形成了地环路,哪些地方形成了天线效应,通过系统设计时的地线图就能在整体上解决后面的一系列问题。

    系统设计是综合各方面的知识,综合权衡,得出最优的解决方案,是在不同技术间的平衡,比如对一个采集的信号要进行滤波处理,是采用电路硬件滤波器还是AD后用数字滤波器?对驱动力矩要求较大时,是选大扭矩电机还是增加机械减速器?防盐雾侵蚀是用防锈材料还是涂三防漆还是加强密封?在这些不同技术间平衡的时候,综合的是成本、工期、团队成员对技术掌握的程度、法规、安全、批量供货时加工商的批次稳定性的保障能力等。

    往简单里说,系统设计方法就是把一些外围的技术要求全部涵盖进产品开发里来,用checklist的方式进行检查,而不是先出整机,然后再改,那样机器将不是机器了。国内诸多做产品CE认证的中小厂家,试问有几家把产品真正卖到了欧盟国家,不敢啊,在公司里都有三种机型的说法,分别叫在产机器、CE样机、CE状态的机器,大多中小企业的产品是前两种,为什么出现这种局面?就是没有系统设计,先出整机,然后再改,最后拿个CE证当虎皮唬人去,就是不敢上景阳岗怕遇到真老虎。

    系统设计其实真得不难,有这么类岗位,能作系统设计+审核,再加上点提炼的checklist,基本就可以开工了,剩下的就是系统设计师找到感觉,加强自己的技能训练,让系统设计真正发挥作用了。实在不行,请这方面的专家帮助实施一下也是可以的,辅导上1-2个项目,建立一套体系,将无往而不胜。

    3建立技术平台,建立可靠性保证流程

    百年老店的大公司的产品为什么都比较好呢?他们的技术人员就比我们的资深吗?他们不也都是年轻人吗?百年老店的核心价值除了品牌还有什么?还有他们在专项技术上的积累。也就是说100年的技术经验和教训今天仍然被引用参考,它拿出一百年的积累和我们竞争,这是我们不可能具备的东西,很多事情必须经历过才会发生,发生了解决了才会成为积累。百年老店如何积累下这些东西的,它靠的是什么来传承这些精华?答案是技术平台。再往通俗里说,技术平台的表现形式就是一堆的专业checklist文件,这些检查项是多少代人的深刻总结,到了今天,一个工程师都不必经历什么,他就能得到前人的教训经验,并用于设计中,自然可以避免很多问题。

    我在工作中曾经做过标准法规的checklist、EMC设计的checklist、系统设计的checklist、可用性的checklist、研发控制体系的checklist等等,这些都是很低成本就能实现的东西,但它又有很高的成本,它是一份总结,是汇集了多少代人心血的总结。
    抽取几个出来,如
    “少用分立元件,多用集成电路”、
    “不定制器件”、F2W分析方法、
    “经常要用到的控制器的高度应该在人的肘弯和肩膀之间”、
    “显示界面不要出现同一变量的不同信息”、
    “在正常使用时设备倾斜100不会失去平衡”、
    “不提供热量的应用部件表面温度不得超过410”
    “显示部分高度应位于操作者在操作姿态(考虑站姿和坐姿),距离1米情况下,其水平视角上斜150至下斜450范围”等。

    这些都是多少代人、多少个不同专业的人呕心沥血的结晶,如果一个公司建立了一个属于自己、适用于自己的一个技术平台,并在设计管理中认真执行它,通过审核控制和测评控制它的实施效果,那么公司工程师的水平将飞速提升,即使是很一般的工程和能做出很出色的产品来。

    4研究可靠性设计方法

    作为技术人员,最喜欢的就是技术了,在公司和管理层面把架构搭好了之后,作为技术工程师和系统设计师,可靠性的知识和设计方法就是需要补课的了。可靠性设计方法包括很多方面的内容(有些和系统设计的内容重叠,这不矛盾,系统设计研究的是整体,设计方法是把系统要求具体实现的方法),气候环境防护设计、热设计、EMC/EMI设计、降额设计、裕度设计和稳定性设计、冗余设计、缓冲减震设计、元器件选型、可使用性设计、视觉显示、照明、控制、控制面板布局、控制与显示器关系、安全性设计方法、防电力危害、防机测危害、防辐射危害、防止火灾危害、可维修性设计方法、测试与调整方法、标识、可接近性和可更换性、插头和插座、紧固件、轴承、报警、印制电路板设计方法、可靠性试验验证方法、可靠性测试工具等方面的知识和内容。

    关于每一个技术主题的细节不是本文区区几千字就能写得明白的,其实所谓的设计方法就是一些设计规范和考虑问题的知识点。为了方便,也可以做成checklist,让技术人员在设计初期学习参考,在设计过程中对照,在设计结束时自查,在提交评审是由测评机构或审核岗位对照checklist复查和针对一些关键设计规范做实验验证。

    以降额设计为例来阐述一些具体的设计方法:
    比如对失效率高、重要部件及器件一定要进行降额设计。
    1、电阻器降额外加功率、极限电压、极限应用温度三个指标,功率降额系数0.1—0.5;
    2、电容器降额外加电压、频率范围、温度极限三个指标,普通铝电解电容和无极性电容的电压降额系数0.3—0.7之间,钽电容的电压降额系数0.3以下;
    3、集成电路降额结温、输出负载指标;
    4、晶体三极管降额结温、集电极电流、任何电压指标,晶体二极管降额结温、正向电流及峰值、反向电压三个指标,功率降额0.4以下,反向耐压0.5以下,发光管电压降额0.6以下,功率降额0.6以下,功率开关管电压降额系数在0.6以下,电流降额系数在0.5以下;
    5、线圈扼流圈降额工作电源、电压指标;
    6、变压器降额工作电流、电压、温升(按绝缘等级)指标,电感和变压器的电流降额系数0.6以下;
    7、继电器降额接点电流、温升(按绝缘等级)指标;
    8、接插件降额电流、电压指标,根据触点间隙大小、直流及交流要求降额。接插件嵌入材料和火花发热对接点寿命的影响,在中低频多接点接插件采用两点或多点接地并联方式,降额和增加冗余功能;
    9、电缆导线降额指标:电流(铜线,≤7A/mm2)、电缆电压(尤其多芯电缆),塑料导线的电流降额0.7以下
    10、开关器件降额指标:开关功率、接点电流
    11、电动机降额轴承负载、绕阻功率指标,伺服电机的轴承失效和绕组失效,轴承负载降额和绕组功率降额0.3—0.8;
    12、结构件降额指标:增加负载系数、安全余量
    13、对电子元器件降额系数应随温度的增加而进一步降低。

    对有些指标是不能降额的:
    1、继电器的线包电流不能降额,而应保持在额定值左右(100±5% );否则会影响继电器的可靠吸合。
    2、电阻器降低到10%以下对可靠性提高已经没有效果。
    3、对电容器降额应注意,对某些电容器降额水平太大,常引起低电平失效,交流应用要比直流应用降额幅度要大,随着频率增加降额幅度要随之增加。
    4、结构件设计降额不能增加过大,否则造成设备体积、重量、经费的增加。

    作为设计师,只要把这些设计规范设计进了产品中,产品的可靠性一定会提升的。这样的设计方法,有多个获取的渠道,一是内部交流脑力激荡汇总起来;二是和专家交流,找专业的研究院所、咨询机构、专家个人通过请教的方式汇总起来;三是向供应商学习,机加件供应商与设备厂家相比一定算是工艺加工的专家,芯片的提供厂家在芯片检测应用方面一定是专家,线缆的加工商在线缆技术上一定是专家,通过向这些专家的学习,也能有不少收益。

    可靠性设计方法的研究是长期积累的过程,不要奢望一蹴而就,毕竟十年树木,百年树人,方法不但要有,还要被技术团队消化掉,这自然不能朝起则夕闻道那么快了。

    5加强可靠性管理措施,保证设计的固有可靠性

    无论是可靠性设计过程还是可靠性保障过程,为达到设计规范的被贯彻,都需要一些管理手段来保证,不然再好的技术也发挥不了作用。这就是可靠性管理和评价措施。

    可靠性管理好一定要先有个评价指标,没有指标就没有效果好坏的检查和对比,设计者就没了方向。但这个指标如何定?在过去人们是有误区的。MTBF、MTTB这些指标固然重要,但那是对大企业、对可靠性预计、对大批量有足够样本数统计的产品的评价指标。对中小企业,不必要太研究高深的可靠性预计理论,MTBF没必要,对几千万的企业,甚至ppm(Part Per Million)、fit(Failure In Time)都不必过多研究,而是立足于现实,把质量管理的一些技术指标引入作为可靠性指标即可。如单板的年返修率、电路板加工的一次直通率、设计规范引用率、新机器失效问题预防率等。有了设计指标,统计实施可靠性设计管理之前的量化指标,再有实施后的量化指标,一对比,努力的成果就能摆到桌面上来,只要我们是在一点点进步的,那就很值得欣慰。

    除了设计阶段的考量指标,投产后各环节的管理和指标设定也是必不可少的,如供应商的选择、供应商的认证和评价、物料选型方法、生产现场ESD/MSD防护方法、物料储存方法、电气组装机械组装过程的可靠性保障、制造过程的失效分析都会制约产品可靠性的提升,这些虽然也有可靠性技术的成分,但大都属于可靠性保障的内容,不在本章节的讨论范围之内了,另见相关文章。

    6总结

    本文的思想基础是产品通过设计实现其固有可靠性,通过保障管理实现其制造过程不降低固有可靠性。

    本文在上面思想下讲述了中小企业机电产品的可靠性设计技术和技术管理方法,包括了基于失效机理的实验分析和预防、加强系统设计技术和系统设计管理、建立以技术平台为基础的可靠性设计保证流程、学习具体的可靠性设计方法、设定量化的可靠性设计考量指标并通过管理措施保证产品的高设计可靠性五方面的内容。每个细节内容和方法又都有自己的诸多技术成果作为支撑,设计与管理思想、设计与管理工具、具体的设计知识三部分构成了产品高可靠性的保证基石。

    展开全文
  • 软件可靠性课程复习要点

    千次阅读 2019-01-12 10:33:04
    以下整理来自于Leo,因为Leo不玩博客...软件可靠性概念(定义) –在规定条件下,在规定的时间内,软件不引起系统失效的概率,该概率是系统输入和系统使用的函数,也是软件中存在的错误的函数;系统输入将确定是否会...

    以下整理来自于Leo,因为Leo不玩博客,且网上关于软件可靠性这方面的资料微乎其微
    所以本人厚颜无耻地拿过来标注原创发出,且希望Leo不会看到这篇博文,(逃)
    因为文章整理按点展开,故琐碎难看。各位看客直接Ctrl+F搜索关键字。

    软件可靠性概念(定义)

    –在规定条件下,在规定的时间内,软件不引起系统失效的概率,该概率是系统输入和系统使用的函数,也是软件中存在的错误的函数;系统输入将确定是否会遇到已存在的错误(如果错误存在的话);

    –在规定的时间周期内,在所述条件下程序执行所要求的功能的能力。

    软件可靠性因素相关概念

    可靠度

    –软件可靠度是指软件在规定的条件下、规定的时间段内完成预定的功能的概率。或者说是软件在规定时间内无失效发生的概率。
    Rξ(t)=Pr{ξ>t}=1Fξ(t) R_\xi(t)=P_r\{\xi>t\}=1-F_\xi(t)

    ξFR(t)t\xi为随机变量,F是其分布函数,R(t)表示t时刻的可靠度

    失效率

    –失效率是指软件在 T 时刻没有发生失效的条件下,在 区间T+t内,当t很小时,单位时间内发生失效的概率。

    在指数分布下可靠度 R(t)=eλt1λtR(t)=e^{-\lambda t} 近似于 1-\lambda t

    不可靠度F(t)=1R(t)=1eλtF(t)=1-R(t)=1-e^{-\lambda t}

    平均失效间隔时间MTBF

    MTBF:指两次相邻失效时间间隔的均值

    MTTF(平均失效前时间):可以理解为设备在规定的环境下,正常生产到发生下一次故障的平均时间。公式如下:

    MTTF=0R(t)dt=1λMTTF=\int_0^{\infty}R(t)dt=\frac{1}{\lambda}(有些情况下)

    软件可靠性模型相关概念

    软件可靠性评估模型是随机过程的一种表示形式,将软件可靠性或直接相关的量表示成时间与软件产品的特性或开发过程的函数。将失效过程的一般形式定义为各因素,描述软件失效与软件缺陷之间关系的数学方程

    假设条件原因

    模型是实际情况的理想或简单化,总是包含若干假设

    标准假设

    软件运行方式和进行软件可靠性预计时的软件运行方式相同——确保预计结果的有效性

    当检测到缺陷时,各个失误是独立的——简化推导

    假设的四个公共条件

    1.程序中的各个错误是相互独立的(即标准假设2)

    2.测试过程中检测到的错误,都被排除,每次排错只排除一个,且过程中不会引入新的错误

    3.程序的失效率在每个失效间隔时间内是常数,错误以相等的可能发生

    4.软件的运行方式与预期的方式相似(即标准假设1)

    评估模型的基本原理

    对软件可靠性测试或实际使用中收集的失效数据,利用统计知识分析其规律,建立一个参数模型,在数据的基础上对该统计分布的参数进行估计,从而在此模型基础上对软件可靠性进行定量估计或评价

    定义

    是将软件失效过程的一般形式规定为各因素,例如缺陷引入缺陷移除运行环境等的函数或数学表达式,是描述软件失效与软件缺陷之间关系的数学方程

    模型类型

    指数分布的NHPP模型:JM模型、GO模型

    非指数分布的NHPP模型:MO模型

    可靠性建模过程中的指标因素 失效数据 用到哪些数据 数据类型

    指标因素

    1、错误或者缺陷的排除过程和引入过程
    2、运行环境

    排错引入过程

    在JM、GO模型假设中,检测到的错误都会被立刻排除,排错时间可以忽略不计,每次排错只排除一个错误,在排错过程中不会引进新的错误

    运行环境

    测试环境要与实际运行环境相一致

    失效数据

    失效时间数据(完全失效数据):每一次失效发生的时间构成的失效数据

    失效计数数据(不完全失效数据):由各时间段内发生的失效次数构成的失效数据

    故障树 故障树的定义 故障树的规范化过程中如何简化

    概念

    故障树分析法是在系统设计的过程中,通过对可能造成系统失败的各种因素(包括硬件、软件、环境、人为因素)进行分析,画出逻辑框图(即故障树),从而确定系统失败原因的各种可能组合方式或其发生概率,以计算系统失效概率,采取相应措施,以提高系统可靠性的一种设计分析方法。

    故障树分析方法在系统可靠性分析,安全性分析和风险评价中有重要作用和地位。既可用于定性分析又可用于定量分析。

    对于所研究系统的各类故障或不正常工作情况统称为故障事件,与之对立的是成功事件。

    故障树是一种为研究系统某功能故障而建立的一种倒树状的逻辑因果关系图。

    故障树主要由事件和逻辑门构成,事件用来描述系统或元部件的故障状态,逻辑门把事件联系起来,表示事件间的逻辑因果关系

    特点

    自上而下作层层追踪分析

    事件间的逻辑关系一目了然

    在系统设计阶段有助于判明系统的隐患和潜在故障

    故障树可作为管理维修人员的管理维修指南

    规范化

    仅含有基本事件、中间事件、顶事件以及与或非三种逻辑门的故障树

    简化

    用相同转移符号表示相同子树、相似转移符号表示相似子树

    用布尔代数法化简,去掉明显的逻辑多余事件和逻辑多余门

    可靠度概念公式

    软件可靠度是指软件在规定的条件下、规定的时间段内完成预定的功能的概率。或者说是软件在规定时间内无失效发生的概率。ξFR(t)t\xi为随机变量,F是其分布函数,R(t)表示t时刻的可靠度
    Rξ(t)=Pr{ξ>t}=1Fξ(t)Rξ(t)=Pr{ξ>t}=1Fξ(t) R_\xi(t)=P_r\{\xi>t\}=1-F_\xi(t)R_\xi(t)=P_r\{\xi>t\}=1-F_\xi(t)

    可靠度与不可靠度之间的函数关系

    R(t)+F(t)=1R(t)+F(t)=1

    根据指数分布推断计算系统的寿命

    指数分布是事件的时间间隔的概率

    指数分布:f=eλtf=e^{-\lambda t}

    概率相关:P(X>t)=eλtP(X>t)=e^{-\lambda t}

    割集的性质(重要度影响关系)

    阶数越小的最小割集越重要

    在低阶最小割集中出现的底事件比高阶中的更重要

    在相同阶次下,在不同割集中重复出现次数越多的底事件越重要

    故障树相关过程

    (1)选择顶事件

    (2)建立故障树:规范化、事件逻辑门符号

    (3)故障树的定性分析:简化(布尔表达式化简)和求最小割集

    (4)故障树的定量分析:求顶事件发生的概率、重要度分析

    (5)确定设计上的薄弱环节(找出问题所在)

    (6)采取措施,提高产品的可靠性和安全性

    几何分布性质

    几何分布具有离散性,无记忆性(简单来说就是后面事件发生的概率与前面事件是否发生无关)

    U、Y、PLR 背景原理构造方法

    序列似然比PLR

    用来对两个模型预计质量的相对优劣进行评定的一个指标。

    PLR的总体思路是认为软件发生在软件失效时间的分布函数密度大的地方的可能性较大。预计软件失效时间的分布函数密度大的预计相比较而言更接近真实。

    f为模型的预计概率密度,若 PLR为正无穷,则说明A优于B,为0则说明B优于A,为常数则说明两者差不多。
    PLR=fa(j)fb(j) PLR=\prod{\frac{f_a(j)}{f_b(j)}}

    U图

    U图是用来检测预计和观察的失效行为之间系统而客观的差别。

    U图的目的是用来判断预测预计分布函数是否均匀的接近于实际分布函数。

    ui= Fi( t) ,将n+ 1个 ui的值按升序分类, 用uj表示分类以后的序列( j = 0, 1, 2, …, n) , 把点( uj , j / ( n+ 1) ) 描在图上。

    Y图

    U图能够检测出预计与显示的偏差。但ks距离很小的U图有时也会掩盖了偏差,Y图是通过对序列U进行变换后绘制的。Y图对U作如下变换

    xj=ln(1uj)yj=l=ijxi/l=ii+ntix_j=-ln(1-u_j),y_j=\sum_{l=i}^jx_i/\sum_{l=i}^{i+n}t_i

    作图方法与U图作图法一样, 将 点( yj , j / ( n+ 1) ) 描在图上并作出 45°线。 这时单位斜率线上产生的偏差表示预测中的趋势。

    可靠性测试概念、特点、对比 增长测试 验证测试

    概念

    对软件可靠性进行定量的评估或验证,为了达到和验证软件的可靠性定量要求而对软件进行的测试

    主要特征

    按照用户实际使用软件的方法测试软件

    增长测试

    发现程序中影响软件可靠性的故障,并排除故障实现软件可靠性增长(软件系统测试阶段的末期)

    流程:构造操作剖面->生成测试数据->测试运行->测试结果分析->排错与回归测试/可靠性评估->可靠性进展分析->停止测试

    验证测试

    验证在给定的统计置信度下,软件当前的可靠性是否满足用户要求(软件验收阶段)

    流程:构造操作剖面->生成测试数据->测试运行->测试结果分析->接收/拒收判决->可靠性评估

    可靠性测试与一般测试的对比:
    比较项目 软件可靠性增长测试 一般软件测试
    测试目的 评估软件可靠性水平,有效实现软件可靠性增长 发现软件的故障
    测试效率 达到可靠性要求较快 达到可靠性要求较慢
    测试数据方法生成 基于使用的测试,根据软件的使用状况构造操作剖面然后生成测试用例 基于需求/结构的测试,根据软件的需求或结构生成测试用例
    数据收集 需要收集测试输出结果和失效时间等数据 只需要收集输出结果
    数据分析 通过失效数据进行分析 根据用例执行情况进行需求结构覆盖分析
    测试停止准则 满足可靠性要求 某些要求的结构覆盖率达到100%

    可靠性设计 避错设计简化设计 容错设计 原则 方法

    避错设计

    避错设计是在软件开发设计过程中,针对软件的具体特点,充分应用有效的软件工程技术、方法、工具,加强软件工程管理,避免软件错误的引入,从而保证和提高软件的可靠性。

    方法:

    通用类设计风格: 1.程序编写清楚,不要过分灵巧

    ​ 2.简明直接地说明用意

    ​ 3.尽量使用库函数

    ​ 4.保证特殊情况特殊处理

    结构类设计风格: 1.避免不必要的分支

    ​ 2.使用括号避免二义性

    ​ 3.调用公共函数代替重复的表示

    健壮性设计: 1.模块调用时检测参数合法性

    ​ 2.检查输入数据的数据类型

    监控定时器设计:提供监控定时器或类似措施,确保处理器或计算机系统具有处理程序超时或死循环的能力;监控定时器采用独立时钟源和独立的硬件实现

    异常保护设计:分析软件运行过程中各种可能的异常情况,设计相应的保护措施。异常处理措施必须使系统转入安全状态,并保持计算机处于运行状态。

    简化设计

    应从模块的独立性、扇入扇出以及单入口单出口等采取措施,同时还应综合考虑模块的复杂度和规模等因素。

    独立性准则:提高模块内聚度,降低耦合度,实现独立性

    单入口单出口要求:除中断情形外,模块应使用单入口和单出口控制结构

    扇入扇出原则:将模块在逻辑上构成分层次结构,在不同的层次上允许不同的扇入扇出数

    容错设计

    一定程度上对自身故障具有屏蔽能力,在一定程度上能从故障状态恢复到正常状态、软件故障时能在一定程度上完成预期的功能以及在一定程度上具有容错能力

    基本活动:故障检测(方法:软件自测试)、破坏估计、故障恢复、故障隔离、继续服务

    软件容错技术:为了实现软件容错,一般都要使用某种形式的冗余,这种冗余既可以是设计(算法)冗余,也可以是数据冗余。设计冗余是利用相异的软件模块来实现软件容错。

    分配方法

    等同分配

    串联部件可靠度:Ri=R1nR_i=R^\frac{1}{n}

    并联部件可靠度:Ri=1[1R]1nR_i=1-[1-R]^\frac{1}{n}

    阿林斯分配

    假定软件系统为串联系统,n个部件失效率为常数,系统的容许失效率为λs\lambda_s,各部件的失效率为λi\lambda_i,根据此算得加权因子ωi=λiλi\omega_i=\frac{\lambda_i}{\sum{\lambda_i}},各部件分配的容许失效率λi=ωiλs\lambda^*_i=\omega_i*\lambda_s

    agree分配(主要)

    Rmniiλi=nilnRnωiti 设系统的可靠度为R,若系统由m个分系统组成,各分系有n_i个单元, 则分配给第i个系统的失效率为 \lambda_i=-\frac{n_ilnR}{n\omega_it_i}

    IRi(ti)=1lnRninωi=11Rninωi 分配给第 I 个系统的可靠度 R_i(t_i)=1-\frac{-lnR^\frac{n_i}{n}}{\omega_i}=1-\frac{1-R^\frac{n_i}{n}}{\omega_i}

    故障树相关

    选择顶事件、建立故障树
    故障树的定性分析

    a)故障树的规范化

    b)规范化后的简化

    c)求最小割集

    故障树的定量分析

    a)求顶事件发生的概率(即系统的不可靠度Fs(t)F_s(t)

    设每个事件发生的概率为PiP_i最小割集的发生概率为Ki=PiPiKiK_i=\prod{P_i},其中P_i属于K_i,则顶事件发生的概率为
    P(T)=P(i=1nKi)=()i=1nP(Ki) P(T)=P(∪_{i=1}^nK_i)=(粗略计算或最小割集相互独立)\sum_{i=1}^nP(K_i)
    当最小割集不相互独立且要求精确计算时,应当使用容斥原理。

    b)重要度分析

    1.第i个零件的概率重要度:Δgi(t)=δFs(t)δFi(t)\Delta g_i(t)=\frac{\delta F_s(t)}{\delta F_i(t)},其中Fs(t)F_s(t)为系统不可靠度函数,Fi(t)F_i(t)为第i个元部件的不可靠度,Δgi\Delta g_i即为s对i求偏导的结果

    2.关键重要度:IiCR(t)=Fi(t)Fs(t)Δgi(t)I^{CR}_i(t)=\frac{F_i(t)}{F_s(t)}*\Delta g_i(t)

    3.结构重要度:Iiϕ=12n1niϕI^{\phi}_i=\frac{1}{2^{n-1}}*n^{\phi}_i

    展开全文
  • 软件可靠性

    千次阅读 2009-06-20 22:49:00
    软件的可靠性与硬件的可靠性有许多相似之处,更有许多差别。这种差异是由于软、硬件故障机理的差异造成的,因而使软件可靠性在术语内涵、指标选择、设计分析手段以及提高软件可靠性的方法与途径等方面具有其自身

    转载自http://www.cmaintop.com/UploadFiles/2004121921215700.pdf

    软件可靠性
    软件的可靠性是用以衡量一个软件(指计算机程序)好坏很重要的一个评价指标。软件的
    可靠性与硬件的可靠性有许多相似之处,更有许多差别。这种差异是由于软、硬件故障机理
    的差异造成的,因而使软件可靠性在术语内涵、指标选择、设计分析手段以及提高软件可靠
    性的方法与途径等方面具有其自身的特点。然而,软件可靠性作为一个新的研究领域正在发
    展和应用。
    1 基本概念
    (1) 软件故障及其特征
    对于软件的不正常,常用三个术语来描述:
    ①缺陷(fault):指的是软件的内在缺陷。
    ②错误(error):缺陷在一定环境条件下暴露,导致系统运行中出现可感知的不正常、
    不正确和不按规范执行的状态。
    ③故障(failure):由于对错误未作任何纠正而导致系统的输出不满足预定的要求。
    缺陷可能导致错误并造成系统的故障,因此,缺陷是一切错误的根源,故存在下面的传
    递关系:缺陷→错误→故障。
    但是发生过故障的软件通常仍然是可用的。只有当软件频繁发生故障,或公认已经“陈
    旧”时,软件才被废弃,这一版本软件的寿命也就终结。
    有缺陷的软件只有在特定条件下才能导致出错,而在一般情况下是能够正常工作的。软
    件缺陷一般有以下特征:
    ①软件缺陷的固有性。软件一旦有缺陷,它将潜伏在软件中,直到它被发现和改正。反
    之,在一定的环境下,软件一旦运行是正确的,它将继续保持这种正确性,除非使用环境发
    生了变化。此外,它不像硬件,随时间推移会因使用而不断“耗损”,或产生新的缺陷。因
    此,软件缺陷是“牢靠地”、“无耗损地”潜伏于软件之中。
    ②缺陷对环境的敏感性。对于一个软件来说,它的各部分之间有着密切的联系。软件的
    运行过程实际上是各部分间的一个逻辑组合过程,不同的逻辑组合就可得到不同的程序路
    径,而每一次软件运行或完成某功能都是选择了某一条程序路径。选什么样的程序路径是由
    软件自身确定的输入环境决定的。对于不同的输入环境,软件的运行路径可能有不同。如果
    软件在某些程序路径上含有缺陷,那么在执行这些程序路径时就有可能发生错误。这就是软
    件错误与输入环境的关系。对在一定输入环境下工作出错的软件,当退出该环境后,对于其
    他环境,此软件又可能正常工作。但当再次进入该环境时,软件又会出错。这说明缺陷对环
    境是十分敏感的。
    ③软件错误的传染性。任一软件缺陷,只要未被排除,始终存在于该软件中,一旦暴露,
    处理过程就将产生错误,而这种错误往往是变化的。例如,由于某一处错误处理,使某个处
    理变量C 的值与要求不合,当变量C 继续参加运行时会引起处理过程中的其他错误。故这
    类错误是具有“传染性”的。如果错误不被纠正,也许这种错误就一直存在以至继续“传染”,
    直到引起软件故障。
    (2) 软件可靠性
    软件可靠性是“软件在规定的条件下、规定的时间周期内执行所要求的功能的能力”。
    软件可靠性同样可用可靠度来衡量,而软件的可靠度是“软件在规定的条件下、规定的时间
    周期内不引起系统故障的概率”。该概率是系统输入与系统使用的函数,也是软件中存在的
    缺陷的函数。系统输入将确定是否会遇到已存在的缺陷(如果有缺陷存在的话)。
    软件可靠性的定义虽与硬件可靠性定义貌似类同,但定义中的各要素的含义是不同的。
    环境条件是指软件的使用(运行)环境,它涉及到软件运行所需要的一切支持系统及有关的因
    素。规定的时间t 被定义为软件系统一旦投入运行后的计算机挂起(开机但空闲)和工作的累
    积时间。显然,在使用期间中还有计算机的停机时间,它不包括在运行时间t 内。规定功能
    是指从软件要求上或规格说明书和设计说明书上规定的软件全部功能。
    2 常用参数
    软件的故障与硬件不同,软件一旦出现故障,查明原因后相应的缺陷就可以得到纠正,
    以后不再重复出现。因此这是一个可靠性增长的问题。特定的故障出现是非重复性事件,因
    此不能用频率学派的理论来说明。基于上述分析,可知在一个较长的时间区间内,故障率
    λ (t) 肯定不是常值。但是通过对软件工厂工作质量(包括质保体系质量)的掌握程度,根据
    软件开发(测试)过程的质量可靠性分析,可以建立起对软件质量可靠性的“信念”,用概率
    方法对其进行评估。
    常用的软件可靠性参数有以下一些。
    ①系统平均不工作间隔时间(MTBSD)
    设V T 为软件正常工作总时间,d 为软件系统由于软件故障而停止工作的次数,则定义
    +1
    =
    d
    T TV
    BSD
    式中: BSD T ——系统平均不工作间隔时间(MTBSD)。
    ②系统不工作次数(一定时期内)
    由于软件故障停止工作,必须由操作者介入再起动才能继续工作的次数。
    ③可用度( A )
    设V T 为软件正常工作总时间, D T 为由于软件故障使系统不工作的时间,则定义
    V D
    V
    T T
    A T
    +
    =
    或 BD DT
    BD
    T T
    A T
    +
    =
    式中: BD T ——平均工作时间(h); DT T ——平均不工作时间(h)。
    一般情况下,生产计算机系统要求A ≥99.8%;银行计算机系统要求A ≥99.9%。
    ④初期故障率
    一般以软件交付使用方后的三个月内为初期故障期。初期故障率以每100h 的故障数为
    单位。用它来评价交付使用的软件的质量并预测软件可靠性何时基本稳定。
    ⑤偶然故障率
    一般以软件交付给使用方后的四个月后为偶然故障期。偶然故障率一般以每千小时的故
    障数为单位,它反映了软件处于稳定状态的质量。
    ⑥使用方误用率
    使用方不按照软件规范及说明等文件来使用而造成的错误叫“使用方误用”。在总使用
    次数中,使用方误用次数占的百分率叫“使用方误用率”。造成使用方误用的原因之一是使
    用方对说明理解不深,操作不熟练,但也可能是说明没有讲得非常清楚引起误解等。
    ⑦用户提出补充要求数
    由于软件开发过程中未能充分满足用户需要,或者用户对软件开发时所提要求不全面,
    软件开发使用后用户又提出补充要求,需要生产方对软件进行修改、完善。
    3 软件可靠性模型
    虽然软件可靠性与硬件可靠性有相似之处,都是用出故障的概率来表示的,但由于两者
    间故障机理不同,因此可靠性模型也不一样。软件可靠性模型有很多种,下面介绍常用的三
    类:
    ①从硬件可靠性理论导出的模型;
    ②根据程序内部特性得到的模型;
    ③用已知错误植入软件,经过测试、分析比较建立的可靠性模型。
    第一种可靠性模型所做的假设是:
    ①在两次错误出现之间的调试时间随错误出现率呈现指数分布,而错误出现率和剩余错
    误数成正比;
    ②每个错误一经发现,立即排除,并使错误总数减1;
    ③产生错误的速率是个常数。
    对软件来说,上面假设的合理性可能还有问题,例如,纠正一个错误的同时可能不小心
    而引入另一些错误,这样第②个假设将不成立。
    第二种可靠性模型计算存在于软件中的错误的预期数目,根据软件复杂性度量函数导出
    的定量关系,这种模型建立了程序面向代码的(如操作符的数目)与程序中错误的初始估计数
    字之间的关系。
    奈伯(Naib)在一项利用霍尔斯特德(Halstead)方法对软件出错率估算的研究中发现,环
    境因素对软件出错率的影响最大,并找出了三个起决定作用的随机变量,即:
    ①使用过该软件的总用户数X ;
    ②当前用户人数Y ;
    ③当前用户中有过出错历史的用户数Z 。
    X 、Y 、Z 为随机变量。这样软件出错率可表示为
    X DY B Z
    D
    V
    2 3 + + ⎟⎠

    ⎜⎝

    其中: ( ) ( ) 1 2 1 2 2 2 2 1 2 V = η log η +η log η log η +η , 2
    1 2

    η N D =
    式中: 1 η——操作符个数; 2 η ——操作对象个数; 2 N ——操作对象使用次数; 3 B ——模
    块个数。
    经实验奈伯发现,该式的结果与实验值相关系数达0.92。
    第三种可靠性模型是由D.Mills 首先提出的。这种方法一开始用来估算野外生活的动物
    数或一个池塘内鱼的尾数。比如,要估算池塘内鲢鱼的尾数N ,可以先把带有标记的t N 尾
    鲢鱼放入池塘,过一段时间后,从池塘中捕捉鲢鱼。数一数不带标记的鲢鱼有n 尾,带标记
    的有t n 尾。如果这些带与不带标记的鲢鱼分散均匀,又比较合群,而且捕捉的难易度相同,
    那么就可以求得N 为
    t
    t
    N
    n
    N = n
    植入模型就是在软件中“植入”已知的错误,并计算发现的植入错误数与发现的实际错
    误数之比而开发出的模型。随机将一些已知的带标记的错误植入程序。设程序中尚未发现的
    残留错误总数为N ,植入的错误总数为t N 。在历经一段时间的测试之后,总共发现有程序
    的残留错误n 个和带标记的植入错误t n 个。假定植入错误和程序中的残留错误都可以同等
    难易地被测试到,就可用上式求出程序中尚未发现的残留错误总数N 。但这种模型依赖于
    测试技术。例如,如何判定哪些错误是程序的残留错误,哪些是植入带标记的错误,不是件
    容易的事。而且植入带标记的错误有可能导致新的错误。
    还有其他一些软件可靠性模型,例如外延式。绘制单位时间内已检测到错误数目的关系
    曲线,然后用最小二乘法将曲线外延,以此来估计程序中尚残留的错误数目。
    4 提高软件可靠性的途径
    提高软件可靠性的根本途径是开展软件工程,减少软件缺陷。还应当:
    ①严格的配置管理。软件的配置管理能标识和确定系统中的配置项,在系统整个寿命期
    内控制这些项目的投放与更动,记录并报告配置和更动要求,验证配置项的完备性和正确性。
    它能够完成软件的配置标识,配置控制,配置记录,技术状态审计(审核)四项任务。严格的
    配置管理是保证软件可靠性的重要措施之一。
    ②软件(模块)的标准化。对硬件产品来说,一般地说标准化程度越高,其质量与可靠性
    也越高。软件也一样。软件标准件应由国家至少是部门来组织生产。这样软件的质量与可靠
    性将会有明显的提高。
    ③软件可靠性设计准则。实践证明:总结国内外,特别是本部门、单位的成功或失败的
    经验教训,制订并贯彻产品可靠性设计准则是提高产品可靠性的根本手段。对硬件产品如此,
    软件也相同。硬件可靠性设计的很多思路与方法可用在软件之中。例如:
    ·FMEA,FTA 可以根据软件的特点具体化后加以应用;
    ·冗余技术。软件不能像硬件一样用几个完全相同的单元组成冗余,因为一错皆错。但
    软件可使用具有相同功能,但算法及逻辑上都“相异”的技术,使用多版本编辑结构或恢复
    块结构来构成冗余,提高系统的可靠性。
    ·由于计算机运行及信息传输中可能出错,因此,软件应有一定的抗拒硬件出错能力。
    例如采用信息论中现成的检错码及纠错码;又如对关键及重要信息的编码应与其他信息编码
    有足够的Hamming 距离(两码字X、Y 间的Hamming 距离d(X、Y)是码字X、Y 之间对应位取
    不同值的码元数,如X=1100,Y=1011,则,d(X、Y)=3)。
    ·对以安全性为重点的计算机应有一个叫安全性内核的独立程序监视系统。在出现潜在
    的不安全状态或有可能转移到不安全状态时,转入规定的状态。
    ④软件的设计评审。应像硬件一样建立严格的设计评审制度,使之成为把好软件质量关
    的重要手段。为了防止软件可靠性设计评审走过场,制订“软件可靠性与可维护性的设计评
    审检查单”是必要的,要按检查单逐项评审,审查软件是否严格按可靠性设计准则设计。

    展开全文
  • RabbitMQ可用性和可靠性分析

    千次阅读 2016-12-01 16:15:17
    本文分析一下RabbitMQ的可用性和可靠性。首先,介绍一下RabbitMQ的一些概念。然后分析RabbitMQ如何在可用性和可靠性之间做出平衡

    本文分析一下RabbitMQ的可用性和可靠性。分析一下RabbitMQ如何在可用性和可靠性之间进行权衡的。

    1. 基本概念。

    首先,介绍几个RabbitMQ的重要的基本概念。这些概念是理解RabbitMQ的可用性和可靠性的基础。

    镜像队列(Mirrored Queue)

    RabbitMQ集群的队列(Queue)在默认的情况下只存在单一节点(node)上。但是,我们也可以把队列配置成同时存在在多个节点上,也就是说队列可以被镜像到多个节点上。发布(publish)到镜像队列上的消息(message)会被复制(replicated)到说有的节点上。一个镜像队列包含一个主(master)和多个从(slave)。

    非同步的Slave (unsynchronised slave)

    在很多其他产品中,同步(Synchronation)这个词是和异步(Asynchronation)对立使用。但在RabbitMQ中,同步(synchronised)这个词是和非同步(unsynchronised)这个词对立的。这有什么区别那?在rabbitmq中同步(synchronised)是用来描述master和slave之间的数据状态是否一致的。如果slave包含master中的所有message,则这个slave是synchronised,如果这个slave并没有包含所有master中的message,则这个slave是unsynchronised。同步与异步的对立使用的典型的例子是mysql的主从数据复制,数据复制过程可以分为同步复制和异步复制。

    在什么情况下会出现unsynchronised slave?

    当一个新slave加入到一个镜像队列时,这时这个新slave是空的,而master中这时可能包含之前接收到的消息。假设这时master包含了5条消息,这是第6条消息被添加到这个镜像队列中,这个新slave会从这个第6条消息开始接收。这时这个slave就是unsynchronised slave。随着前5条消息从镜像队列中被消费掉(consumed), 这个slave变成了synchronised。

    另外一种情况,slave 重新加入(rejoin) 到镜像队列时,也会出现非同步的情况。一个slave出于很多情况会重新加入镜像队列,网络分区(network partition)就可能导致这种情况。一个slave要重新加入镜像队列之前,slave可能已经接收了一些消息,它要重新加入镜像队列,就要清空自己之前已经接收的所有消息,好像自己是第一次加入队列一样。

    选主方式

    由于RabbitMQ的slave加入和重新加入队列的方式,我们得出一个结论,越早加入队列的slave,越有更大的机会是同步状态的,所以RabbitMQ通过这种方式选主:但master因为某种原因消失时,最老的slave被提升成master。

    2. RabbitMQ的可用性(Availablity)和数据可靠性(Reliability)

    接下来,我们分析一下RabbitMQ的可用性(Availablity)和数据可靠性(Reliability)。RabbitMQ通过参数配置的方式,在可用性(Availablity)和数据可靠性(Reliability)做出了一定的权衡。下面我们来看看这些参数。

    参数ha-sync-mode

    镜像队列有一个配置参数ha-sync-mode,这个参数有2中取值:automatic, manual。

    manual是默认值。如果镜像队列被设置成munual,当一个slave加入和重新加入队列时的行为,就是我们上面描述的行为,之所以叫manual,就是我们可以通过命令行手工(manually)进行同步。命令如下:
    rabbitmqctl sync_queue name

    如果镜像队列被设置成automatic,当一个新slave加入时,slave会自动同步master中的所有消息,直到所有消息被同步完成之前,所有的操作都会被阻塞(blocking)。

    这个参数是可用性和可靠性的一个平衡,manual不保证数据可靠性,在某些情况会出现丢消息的可能,但是保证了队列的可用性。automatic提高了数据的可靠性,但是当有新slave加入时,可能会出现队列的暂时不可用。

    参数ha-promote-on-shutdown

    镜像队列的另外一个参数ha-promote-on-shutdown,也在可用性和可靠性之间做了一个平衡。ha-promote-on-shutdown有2个取值:when-synced,always。默认是when-synced。ha-promote-on-shutdown是用来控制选主的行为的。

    当取值为when-synced时,在可控的master关闭时(比如停止RabbitMQ服务或者关闭操作系统),RabbitMQ会拒绝故障恢复(fail over)到一个非同步slave,也即拒绝把一个非同步的slave提升成新的master。只有在非可控的master关闭时(比如server crash, 断网),才会故障恢复到一个非同步的slave。

    当取值为always时,则在所有情况下,都不会拒绝故障恢复到非同步的slave。

    很明显,这个参数也是平衡可用性和可靠性的,当when-synced,可靠性更好,可用性降低了,因为如果所有的slave都是非同步状态,那就没有符合条件的slave可以被提升成master,这时队列就处在不可用状态。

    展开全文
  • 上一篇文章介绍了软件可靠性性工程的基本概念软件可靠性工程简介,下面介绍软件可靠性过程SRE的软件可靠性计划如何制定及什么是LRU。 在软件设计之前,为了提高软件可靠性开发的效率,首先要对开发活动进行策划。下...
  • 可靠性参数MTTF、MTBF和MTTR

    千次阅读 2008-11-28 09:26:00
    可靠性是最初是确定一个系统在一个特定的运行时间内有效运行的概率的一个标准。可靠性的衡量需要系统在某段时间内保持正常的运行。 目前,使用最为广泛的一个衡量可靠性的参数是,MTTF(mean time to failure,平均...
  • 可靠性到底是个啥

    千次阅读 2018-04-11 00:00:00
    一、持久性、可用性,傻傻分不清我们一般所说的“可靠性”,其实是个比较模糊的概念,里面包含持久性和可用性两个层面的意思。打开AWS S3的介绍页面(https://aws.amazon.com/cn/s3/details/),会看到这样一句话:...
  • kafka数据可靠性深度解读

    万次阅读 多人点赞 2017-05-02 19:19:32
    本文首先从Kafka的架构着手,先了解下Kafka的基本原理,然后通过对kakfa的存储机制、复制原理、同步原理、可靠性和持久性保证等等一步步对其可靠性进行分析,最后通过benchmark来增强对Kafka高可靠性的认知。...
  • 本书共十二 章,内容包括:可靠性概论、系统可靠性模型、可靠 性预计和分配、失效模式和影响分析、故障 树分析、电子系统和机械结构的可靠性设计、可靠性 试验、单元产品和复杂产品可靠性评估、 软件可靠性以及...
  • 软件可靠性测试及其实践

    千次阅读 2008-04-30 10:18:00
    软件可靠性工程是指为了满足软件的可靠性要求而进行的一系列设计、分析、测试等工作。其中确定软件可靠性要求是软件可靠性工程中要解决的首要问题。软件可靠性要求可以包括定性定及量要求。 软件可靠性测试是在软件...
  • 可靠性测试技术

    千次阅读 2018-07-16 10:58:02
    Security(1)Attribute——可用(Availability)、依赖(Reliability)、安全(Safety)、机密(Confidentiality)、整体、可维护(2)Threats——Faults、Error、Failures(3)Means① Fault Prevention②...
  • 浏览器端可靠性测试的概念和背景 背景 Web 2.0 是一个体现当代网络技术发展趋势的流行概念。它使得基于 Web 的信息交互和用户间协作性更加灵活和丰富。很多的社交网站、博客、wiki,都是 Web 2.0 技术的典型...
  • 需求分析与软件可靠性保证

    千次阅读 2009-09-19 01:07:00
    一、软件可靠性工程与需求工程的关系软件需求分析是软件产品开发设计的第一步,也是最重要的一步。其工作质量的高低,不仅直接影响后续工程的质量,而且决定着所开发软件产品的价值。当然,完整、严密地描述用户需求,并...
  • 可靠性技术在医学仪器中的应用前景分析1 引言 可靠性研究起源于武器系统,经过近半个世纪的发展,已成为一门遍及各学科各行业的工程技术学科,已经从电子产品可靠性发展到机械和非电子产品可靠性,从硬件的...
  • 物料优选与可靠性管理课程背景 产品是企业利润的源泉,研发和生产好的产品会给企业带来更大的发展。在企业发展壮大的过程中难免会遇到以下难题:因为产品的需求不清晰导致设计频繁更改,由于设计失误面临生产上大批...
  • 实时软件的可靠性设计

    万次阅读 2013-11-24 01:33:13
    随着实时软件在可靠性和安全性要求极高的环境和系统中的广泛使用,对软件可靠性的依赖正在以前所未有的速度增长,实时软件的可靠性设计与保证在实时系统中占据着越来越重要的位置。可靠性是实时软件的一个重要指标。 ...
  • 谈谈嵌入式系统的可靠性和安全性

    千次阅读 2015-05-13 16:49:05
     可靠性,是指设备的可信赖程度,即正确地完成设定功能的能力。  安全性,指的是在设备发生故障,或者人为误操作的情况下,确保安全的能力。这可能不好理解,举个例子就明白了,比如汽车要通过碰撞试验,确保在
  • 概念 首先来说说性能测试:性能是软件的一种非功能特性,他关注的不是软件是否完成了特定的功能,而是软件在完成特定功能是展示出来的及时。 及时从不同的视角代表不同的指标: 用户:响应时间系统管理员:...
  • 系统性能评测和可靠性基础

    千次阅读 2012-09-05 17:43:54
    当数据处理部件的可靠性为0.6时,为使整个软件系统的可靠性不小于0.66,则数据存储部件的可靠性至少应为(31)。   (31)A.0.6 B.0.66 C.0.79 D.1.0 分 析:两个数据处理部件...
  • 早期是用来衡量一个产品(尤其是电器等可维修的产品)的可靠性指标。单位为“小时”。它们反映了产品的时间质量,是体现产品在规定时间内保持功能的一种能力。软件系统在某种意义上也是一种产品,所以用这三项指标来...
  • PCB设计的可测试性概念

    千次阅读 2014-12-26 18:07:11
    PCB设计的可测试性概念  品设计的可测试性(De sign For Testability. OFT) 也是产品可制造性的主要内容从生产角度考虑也是设计的工艺性之一.它是指在设计时考虑产品性能能够检测的难易程度,也就是说设计产品时应...
  • 这道题在我面试多家公司时都会问到的一个题目,今天分享一下。学过大数据的同学应该都知道 Kafka,它是分布式消息订阅系统,有非常好的横向扩展,可实时存储海量数据,是流数...
  • 安全基本概念

    千次阅读 2007-04-28 18:48:00
    计算机安全所谓计算机系统安全,是指为计算机系统建立和采取的各种安全保护措施,以保护计算机系统中的硬件、软件及数据,防止其因偶然或恶意的原因使系统遭到破坏,数据遭到更改或泄露等。计算机安全不仅涉及到...
  • 可靠性指标中MTTF MTBF MTTR有什么区别

    千次阅读 2019-11-08 10:05:38
    可靠性与可用性的区别在于: 可靠性与寿命有关, 但是和传统的机械设备寿命概念不同的是, 可靠性并不是笼统的要求长寿命, 而是强调在规定的时间内能否充分发挥其功能, 即产品的可用性(可靠性指标之一); 可靠性...
  • 航空领域中安全相关概念的分析

    千次阅读 2012-03-13 20:25:54
    航空领域中安全相关概念的分析 作者:二丫 撰写日期:2011-09-28 ~ 2011-09-30    随着国家在航空航天领域各种项目中越来越大的投入,航空软件的安全也备受关注。然而目前是行工作中安全与周边概念的...
  • 5.软件可靠性概念 (1)错误,缺陷,故障和失效 错误:指的是软件在生命周期中各个阶段的状态和行为与人们的期待不一致的偏差,不单单是软件系统本身,中间产品的偏差也算是软件错误 缺陷:指的是...
  • 其实在控制领域我们所说的TCP/UDP和串口总线应用非常接近,和普通的互联网网络应用还是有着很大区别的,毕竟绝大部分网络控制产品都是从总线控制产品升级而来或沿袭了可靠的设计而产出的,本质上基本是一样的(这也...
  • 程序员必知的 89 个操作系统核心概念

    万次阅读 多人点赞 2020-03-31 19:13:39
    大型机(mainframes):大型机是一类计算机,通常以其大尺寸,存储量,处理能力和高度的可靠性而著称。它们主要由大型组织用于需要大量数据处理的关键任务应用程序。 批处理(batch system): 批处理操作系统的用户不...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 95,364
精华内容 38,145
关键字:

产品可靠性概念