用低成本的措施来实现满足可靠性的交付

前两天，跟咸肉大神讨论一个问题：即，如果客户提出苛刻的温度要求，而我们的电路，不能保证每一个器件的都能满足整机的温度范围。那么我们应该如何实现宽温度范围？或者说，我们即不能去承诺这样的整机指标？还是我们通过什么手段，用低成本的措施来实现满足可靠性的交付？

一些军品标准，会要求每台设备都经过筛选试验：也就是说每台设备都经过严格的测试，除了器件做早期的老练筛选。整机也做筛选试验和环境试验。而一些大规模发货的设备：会在研发阶段做HALT试验，然后根据HALT试验的数据设计HASS试验，对生产环节的设备进行测试。HASS应用于产品的生产阶段，以确保所有在HALT中找到的改进措施能够得已实施。HASS还能够确保不会由于生产工艺和元器件的改动而引入新的缺陷。

但是一些没有达到海量发货的设备，在早期是没有条件去做HASS试验的，所以其承诺的整机温度范围如果超过器件的温度范围，又是如何去保证质量的呢？

首先，是通过HALT试验或者环境试验的数据，通过足够多的样本数，在大样本数能够达到测试条件的前提下，对实际场景能否满足要求进行折算和评估。但是这里面有概率性风险：例如，我们一个产品在早期，没有设计HASS试验的前提下，将设备安装到西伯利亚的寒冷世界。当时就发生一块电路板启动失败，反复重启的情况。最后采取更换，故障单板返还的措施。甚至一些大厂，经过大量测试验证，0~70℃的DDR可以用于更低的温度，而认为高温有风险，需要对高温规格进行降额。（不建议小厂这么做，因为没有足够的资源进行试验和验证；没有足够资源进行单板大批量样本验证，以及支持返还进行根因分析。）

其次，一些器件规格不能满足的场景，可以通过整机方案解决，例如换更高性能的风扇、增加风扇、液冷、加热器等等措施，可以弥补器件本身温度范围不能满足要求的情况。例如：曾经在华为设计的一款IP Camera，号称“穷凶极恶”（宽温度范围、宽电压范围、高规格防雷），为了实现无故障超低温启动，原本设计的时候，预留一些加热器、或者一些加热电阻，同时修改IPC的启动策略，由红外灯先工作一段时间，再启动CPU工作，保证工作温度没没那么恶劣，是可接受的范围。

可靠性是一系列方法的整合

可靠性整合是指无缝地、紧密地把不同可靠性方法融合在一起，从而以最小成本得到最佳可靠性。也就是说，可靠性方案是几种方法协调使用的整体，而不是一堆无序的可靠性任务。

产品由各种部件和组件构成。产品的可靠性在设计生产过程中，涉及到学科主要有：机械学、电子学、软件、光学、化学，所有这些学科组成了产品。因此应该重视这些学科之间的关系，和总体的效果。我们设计的过程中也应该是考虑更全面，而不仅仅是从某个部件的角度思考，或者仅仅从某个学科的维度去思考和解决问题。

开发部门往往都是从自己部门的学科出发，去思考可靠性设计；甚至更糟糕的是一些大公司从自己部门的利益和KPI去考虑设计。但是客户要的是完整的产品、并希望产品是各个部件在一起能正常运转。因为可靠性主要由客户和最终用户进行衡量，产品开发人员应该从产品和部件两个方面进行综合考虑，从而开发出可靠的产品。

但是有些设计人员，担心质量事故、担心考评的黑事件，设计的时候，做可靠性堆砌，不计成本的增加可靠性，过设计、过冗余、过度降额。这就需要：一方面，公司在可靠性和成本双方面进行引导，同时，需要设计人员能够具备全面思考产品，能够站在公司角度，站在客户角度去思考和设计产品。

可靠性VS成本

可靠性设计可以减少保修成本、使用成本、可以提高客户满意度；同时可靠性设计也会造成开发成本和生产成本。在生命周期的各个阶段使用合适的方法，我们提高可靠性，到底要实现到什么程度呢？

在保证我们达到业界标准、交付标准、客户需求等前提下，我们应该是运用可靠性设计实现生命周期的总成本（LCC  Life-cycle Costing）的降到最低。

3、软件几乎没有生产成本。因此保修成本和经费几乎全部用于硬件。如果提高软件可靠性不能节约成本，那么我们为什么还要提高软件可靠性呢？

因为：一、事实正面，软件故障率有可能是硬件的10倍甚至更多。客户并不区分是软件故障还是硬件故障。即支持在线升级，任然会造成使用中断、业务中断等问题。

二、软件可靠性方案的好处不在于直接降低成本，而在于减少运作安装返工率、减小故障维修事件、减轻软件人员维护工作量。同时提升客户满意度。

所以提高软件可靠性，必定可以带来成本的节约。

部分文字翻译自《提高可靠性的50种方法》