可靠性设计

简介:   假定要设计一个系统,这个系统由若干个以串联方式连接在一起的不同设备所组成(图6.1所示)。设ri是设备Di的可靠性(即ri是Di正常运转的概率),则整个系统的可靠性就是Πri。即便这些单个设备是非常可靠的(每个ri都非常接近于1),该系统的可靠性也不一定很高。

  假定要设计一个系统,这个系统由若干个以串联方式连接在一起的不同设备所组成(图6.1所示)。设ri是设备Di的可靠性(即ri是Di正常运转的概率),则整个系统的可靠性就是Πri。即便这些单个设备是非常可靠的(每个ri都非常接近于1),该系统的可靠性也不一定很高。

  为了提高系统可靠性,最好是增加一些重复设备,并通过开关线路把数个同类设备并联在一起(见图6.2)。由开关线路来判明其中的设备的运行情况,并将能正常运行的某台投入使用.

  若第i级的设备Di的台数为mi,那么这mi台设备同时出现故障的概率为(1-ri)mi。从而第i级的可靠性就变成1-(1-ri)mi。在任何实际系统中,每一级的可靠性要比1-(1-ri)mi小一些,这是因为开关线路本身并不是完全可靠的,而且同一类设备的失误率也不可能是完全独立的,基于以上分析,不妨假设第i级的可靠性由函数φi(mi)给定,l≤i≤n。并且可以看出,开始时φi(mi)随mi值的增大而增大,在到达mi的某个取值以后φi(mi)的值则可能下降。这个多级系统的可靠性是Πφi(mi)[1<=i<=n].

  所谓可靠性设计最优化问题是在可容许最大成本C的约束下,如何使系统的可靠性达到最优的问题。假设cj是一台设备j的成本,由于系统中每种设备至少有一台,故设备j允许配置的台数至多为:uj=[(c+cj-Σck)/cj](1<k<n). 

于是,整个系统的可靠性设计问题由RELI(l,n,c)表示。它的一个最优解是对m1, …, mn的一系列决策的结果。每得到一个mi都要对其取值进行一次决策。设fi(X)是在容许成本值X约束下对前i种设备组成的子系统可靠性设计的最优值,即fi(X)=maxΠφj(mj) ,1≤j≤i。那么,最优解的可靠性是fn(c)。所作的最后决策要求从(1,2, …, un)中选择一个元素作为mn。一旦选出了mn的值,则下阶段的决策就应使剩余资金c-cnmn按最优的方式使用。于是,有

  显然,当0≤X≤c时,对于所有的X,有f0(X)=1。使用类似于解0/l背包问的方法可以解出(6.3)式。设Si由(f,X)形式的序偶所组成,其中f=fi(X)。
  由m1,…,mn的决策序列所得出的每一个不同的X都至多只有一个序偶。支配规则对这个问题也适用,即当且仅当f1≥f2而X1≤X2时,(f1,X1)支配(f2,X2)。那些受支配的序偶可从Si中舍去。

 

相关文章
|
6月前
|
JavaScript Java 测试技术
基于SpringBoot+Vue+uniapp的校园二手交易平台的详细设计和实现(源码+lw+部署文档+讲解等)
基于SpringBoot+Vue+uniapp的校园二手交易平台的详细设计和实现(源码+lw+部署文档+讲解等)
109 0
|
7月前
|
设计模式 运维 Docker
深入浅出:使用Docker容器化部署微服务架构
本文旨在为读者提供一个全面且易于理解的指南,介绍如何使用Docker技术来容器化部署微服务架构。随着云计算和微服务架构的普及,Docker作为一种轻量级的容器解决方案,已经成为开发和运维领域的热门技术。本文将从Docker的基本概念出发,详细讲解如何将传统的应用服务转化为容器化的微服务,包括Dockerfile的编写、镜像构建、容器部署以及服务编排等关键步骤。此外,文章还会探讨使用Docker部署微服务架构的最佳实践和常见问题,帮助读者有效地管理和优化其微服务系统。
198 1
|
存储 应用服务中间件 API
高效C++项目实战:秋招简历项目解析(提供源码下载)
高效C++项目实战:秋招简历项目解析(提供源码下载)
|
7月前
|
运维 监控 Cloud Native
构建高效稳定的云原生运维体系
【4月更文挑战第20天】在数字化转型的浪潮下,企业纷纷拥抱云原生技术以提高敏捷性和弹性。然而,随着系统复杂性的增加,传统的运维模式已难以满足快速迭代和持续部署的需求。本文将探讨如何构建一个高效且稳定的云原生运维体系,涵盖自动化工具的选择、监控策略的制定以及故障恢复流程的优化。通过引入先进的技术和最佳实践,我们旨在帮助运维团队提升效率,确保系统的可靠性和业务的连续性。
123 14
|
7月前
|
Shell C语言 SoC
计基2—RISCV指令集介绍与汇编
计基2—RISCV指令集介绍与汇编
152 1
|
存储 运维 架构师
云环境下的灾难恢复解决方案
因此,本文旨在向读者介绍AWS云计算下的灾难恢复架构的诸多相关知识点,希望读者可以通过本文了解到云上的灾难恢复计划的基本原理、最佳实践和工具,并掌握如何设计和实施云上的可靠灾难恢复计划。当然各大云厂商的服务个人使用下来,感觉基本思想都是互通的,所以这里面灾难恢复架构是不限定具体云的设计的。
779 0
|
监控 网络协议 Cloud Native
《云原生网络数据面可观测性最佳实践》——三、容器网络常见观测工具及特点——1.常见网络排查工具
《云原生网络数据面可观测性最佳实践》——三、容器网络常见观测工具及特点——1.常见网络排查工具
|
机器学习/深度学习 数据库 C语言
一分钟明白IO密集型与CPU密集型的区别
CPU密集型 CPU密集型也叫计算密集型,指的是系统的硬盘、内存性能相对CPU要好很多,此时,系统运作CPU读写IO(硬盘/内存)时,IO可以在很短的时间内完成,而CPU还有许多运算要处理,因此,CPU负载很高。
|
存储 数据采集 消息中间件
日志数据入湖的设计与实践
SLS 的队列功能及上下游生态可以为日志入湖提供端到端的支持,要修高速公路(PaaS/SaaS 数据源),也要去做“村村通”(端、开源软件)。 SLS 入湖支持包括四个部分: ● 可靠的采集能力覆盖 ● 弹性的写入与存储能力 ● 日志 ETL 与入湖准备工作 ● 围绕湖生态的模板支持与一键入湖
801 0
|
Java API
可能导致CPU占用率过高的场景与解决方案
尽量减少无限循环、让循环执行得慢一点(sleep)