通过丰富设计的混合动力系统的可靠性工程最新的研究成果和目前的方向.docx
《通过丰富设计的混合动力系统的可靠性工程最新的研究成果和目前的方向.docx》由会员分享，可在线阅读，更多相关《通过丰富设计的混合动力系统的可靠性工程最新的研究成果和目前的方向.docx（17页珍藏版）》请在冰豆网上搜索。
通过丰富设计的混合动力系统的可靠性工程最新的研究成果和目前的方向
Parallelanddistributedprocessingsymposium,2006.IPDPS2006.20thinternational
通过丰富设计的混合动力系统的可靠性工程：
最新的研究成果和目前的方向
SomoBanerjee1NenadMedvidovic1
1ComputerScienceDepartmentUniversityofSouthernCaliforniaLosAngeles,CA90089,USA
{sbanerje,lccheung,leana,neno,gaurav}@usc.edu
LeslieCheung1RoshanakRoshandel3
2EE-SystemsDept,IMSCUniversityofSouthernCaliforniaLosAngeles,CA90089,USA
LeanaGolubchik1,2GauravSukhatme1
3Dept.ofComp.Sci.&SoftwareEngr.SeattleUniversitySeattle,WA98122,USAroshanak@seattleu.edu
摘要:
软件可靠性技术的宗旨是减少或消除软件系统故障。
通常，对软件系统的可靠性的测量是在系统运行期间或运行之后进行的。
然而，为了遏制开发和维护的成本，在软件开发周期的早期，软件工程方法论着眼于做“正确的事情”。
本文中，我们从软件架构的层面着手，在整个系统的寿命期内，评估软件系统的可靠性。
我们的研究目标是，在早期设计阶段评估软件系统的可靠性。
这是因为我们认为，在早期设计阶段，设计存在很多的不确定性，其中包括缺乏执行文件的不确定性。
我们提出的解决方法是开发一种技术，将随机可靠性估算模型套件与这种技术一起整合到软件模型架构中，使我们能够解释这些不确定性。
本文中，在软件架构层面，我们使用目前最新的技术对软件组件的可靠性进行评估。
本文另一个重要的组成部分是对这个领域中我们正在进行的研究和开放的研究问题进行讨论。
1.绪论
1.1问题概述
软件可靠性技术的宗旨是减少或消除软件系统故障。
现有的软件可靠性技术一般都起源于硬件的可靠性技术。
他们补充了软件测试的内容，并且假定了工件的可用性。
然而，传统的软件工程学认为：
如果在系统运行时评估软件的可靠性（或软件的其他特性）就太晚了。
如果在系统运行期间才发现问题，我们可能要重新设计系统并重新运行，这是十分昂贵的。
许多有关系统的关键设计方案都是在系统运行之前确定好的。
本文中，我们认为应在整个系统的寿命期内评估软件的可靠性。
举世公认，软件开发过程中的关键是软件架构的开发[13]。
在软件开发之前识别和减少问题，可以帮助我们以符合成本效益的方式提高系统的质量。
为了实现这一目标，我们假定质量属性在软件架构设计阶段就已经植入到软件系统中。
然而，由于许多相关因素的相互影响，在早期设计阶段做出有用的（定量的）预测是很难的。
例如，软件组件的复杂属性，软件上的“固件”（硬件，操作系统，设备驱动）的潜在影响，缺乏执行物，以及潜在的冲突所需的系统属性。
本文中，第一步我们在软件系统中运用丰富的设计模型，在软件架构层面为工程可靠性评估提出一种技术。
目前，我们最新的成果表明我们的方法是有效的和正确的。
1.2动机
虽然存在几个软件可靠性技术，但由于两个原因，在早期设计阶段他们不足以评估可靠性。
首先，现有的技术通常依赖于从正在运行的软件系统中获得的信息。
其次，现有的技术没有考虑能够导致可靠性估计“真空”的软件系统的底层固件的属性。
可靠性评估在早期设计阶段的另一个挑战是开发方案的多重性。
例如，“绿色领域”的开发方案，是整个系统的建模、分析，并重新实施。
然而，许多现代大型软件系统并不是以这种方式开发的。
相反，他们涉及到现成的重复使用的部件，部分被捕捉或过时的模型，需要进行修改的原型实现等。
这些是“棕地”的开发方案。
因此，简单来说，我们需要制定一种可靠性评估的框架，这将为密集型软件尽早在进程中进行可靠性评估提供一套广泛适用的技术。
本文中，我们提出了一个研究方向，这将使工程师能够建立一个多方面，多层次的系统模型。
并且将与发展蓝图一起以一种不断增长的、可衡量的方式来评估其可靠性。
为了实现这一目标，我们将从软件的体系结构出发，对软件架构领域的概念进行必要的补充和延伸。
这将为其所代表的软件系统的结构、行为、和关键特性提供高层次的概念抽象[13]。
软件系统的架构包括一套计算元件（组件），它们之间的相互作用（连接器），以及它们在系统中的组成（配置）。
在我们正在进行的一部分研究中，我们正在为模型开发一种双管齐下的分层方法，并且评估软件系统的可靠性。
在第一步中，我们在个体部件的层面上使用适当的随机模型来建立模型并评估其可靠性。
软件的组件模型增加了预期的固件特性。
请注意，一个给定的（可重复使用的）软件组件可以在多种环境中运行。
因此，为固件特性建立独立的软件属性模型是十分重要的。
与此同时，我们需要模拟软件和硬件元件之间的相互作用。
目前，我们正在研究硬件属性，这直接影响到软件系统的可靠性。
具体来说，我们试图找出适当的抽象描述，例如描述工作量的特点和要求，一台物理主机上的组件驻留（如过流的缓冲区，内存，CPU的速度，电池电源，等）的属性，以及不同的主机之间的通信链路的属性。
我们研究方法的第二个步是组成各个组件的可靠性来计算全系统的可靠性。
我们推测，这种组合有可能提高我们方法的可扩展性。
本文的贡献是我们提出一种技术，利用模型架构，在部件被运行之前，在生成的随机可靠性模型中建立软件部件的可靠度。
另一个重要贡献是，我们用我们的初步成果，开拓了一个具有趣味性和挑战性的研究领域。
目前，在这个领域中我们提出的研究方向和开放性研究问题，推动了国家复杂系统工程技术的重大进展。
1.3.相关工作
软件测试中：
建模，评估和分析软件的可靠性，是一门具有30多年历史的学科。
许多可靠性模型已经提出：
软件可靠性增长模型（SRGMs）是用统计方法预测和评估软件可靠性。
然而，所有这些方法的共同点是实现部件，并在测试过程中评估其可靠性。
在架构层面上，现有的可靠性估算方法只考虑了系统的结构。
唯一的例外是[5,18,22,23]。
然而，这些方法都没有考虑其可靠性的一个组成部分的内部行为的影响。
它们简单地假设组件的可靠性，或它的某些元素（如组件的服务的可靠性）是已知的。
然后，他们使用这些值来获得系统的可靠性。
如果对系统的运行文件的估计存在很大的不确定性，这种不确定性可能体会现在计算软件可靠性上。
因此，传统的软件可靠性评估方法可能是不恰当的，因为他们放弃了任何由于参数的不确定性而导致的方差。
一些方法通过可变的操作文件使用蒙特卡罗模拟来评估可靠性，而其他方法假设一个固定的运行文件和不同部件的可靠性，适用于传统的基于马尔可夫敏感性分析
2.组件的可靠性评估框架
动机:
我们认识到，模型架构及分析，可以为结构的组件和预期的行为提供有意义的见解，因此可用于我们的可靠性评估技术作为构建块。
从不同的角度建立软件模型的组件可以为组件提供互补，这将引起复杂的结构分析，功能和非功能属性的互补性意见。
传统建模软件的组件是从以下四个功能性观点的一个或多个方面建立的：
接口，静态行为，动态行为和互动协议[18]。
组件的观察界面显示了它提供的和需要的服务；静态行为界面谨慎的显示了组件的功能，不同的快照在系统的执行过程中，使用组件与组件业务相关的状态和后置条件的不变量。
动态行为视图显示了一个组件内部执行细节的连续视图，交互协议视图显示了组件运行的一个连续的外部视图，这是通过操作指定的运行路径达成的（通过接口访问）。
在这项工作中，我们利用两种重要的方法衡量这种模型架构。
首先，我们使用动态的行为模式，作为我们在缺乏组件运行文件时的评估技术的基础。
第二，我们在不同的模型架构中使用视图级的不一致，以获得架构的错误（缺陷）。
缺陷可以被用于模拟组件的故障行为。
缺陷量化
分析
模型架构
缺陷
随机模型
模型提取与加工
组件可靠性
可靠性计算
领域知识
人工产品
说明
方法主要步骤
人工产品
说明
数值
功能块
图1组件可靠性评估框架
解决这些挑战的方法，将取决于特别的软件系统的开发情况。
在1.2节，我们已经讨论了“绿色领域”和“褐色领域”的开发方案，。
我们也提到，为了兼容多个开发方案，我们需要有一整套的可靠性评估技术。
我们所提出的组件可靠性评估框架如图1所示。
目前，这个框架包含三个可靠性评估技术，马尔可夫链（MC），隐马尔可夫模型（HMM）和贝叶斯网络（BN）。
本文中，我们阐明使用HMM模型的可靠性评估技术，它一直是我们主要关注的。
其他两种技术将在第4节简要讨论。
缺陷量化
分析
模型架构
缺陷
阶段1
增广隐马尔科夫模型
马尔科夫模型
阶段2
参数评估
可靠性计算
生成
模型提取与加工
阶段3
ITP
组件可靠性
生成数据
领域知识
图2基于HMM的组件可靠性评估技术
架构水平，软件可靠性评估领域的审查可用的研究成果[5,18,22]表明现有的评估系统可靠性的方法是假设部件可靠性或元件的其他可靠性（例如，一个组件的服务可靠性）是已知的。
我们认为这个假设不是合理的。
另外，这些方法都假设组件行为表现出马氏性质1，并且使用马尔可夫模型组件交互作为估算系统级可靠性的基础。
我们还依赖于这一假设，但我们将它作为在组件独立状态之间建立马氏模型交互的基础使用，这是为了评估组件的可靠性。
但是，我们仍然面临着缺乏运行文件的挑战，特别是在“绿色领域”的开发方案上，这将导致在马氏模型中产生未知的参数。
因此，我们认为，一个隐马尔可夫模型（HMM）[15]是一种形式，它可以评估模型中隐藏或未知的参数，因此是一个用来处理缺乏运行文件的合适方法。
我们建议的可靠性评估技术应建立基于组件的模型架构的HMM模型上。
我们应评估HMM的未知参数然后HMM模型的基本马尔可夫模型可以用来解决一个部件的可靠性评估。
组件可靠性估计技术：
作为迄今为止所建立的可靠性评估技术，我们在图2所示的是一个“实例”的可靠性评估框架，如图1所示。
该技术有三个显著的功能阶段。
本文中使用的可行的例子是一个CruiseControl的组件，其动态行为模型，如图3所示。
CruiseControl的组件有三种状态，停止（S1），手动（S2）和巡航（S3）。
正如我们上面所讨论的，HMM模型提供适当的形式，以弥补由于缺乏执行文件而产生的未知参数。
HMM一组状态S={S1，S2...SN定义}，过渡矩阵A表示状态间的转换概率，一组观察值Ø={O1，O2，...OM}和观察值概率矩阵B={bik}，它代表状态中观察事件k的概率。
现在，我们将讨论我们技术的三个功能阶段和HMM模型定义的相关讨论。
第1阶段：
模型提取。
这一阶段使用组件的模型架构，来构造组件个体状态间的HMM交互。
我们绘制的HMM的动态行为模型如下：
动态行为模式的状态转化为相应的HMM下状态，和动态行为对行为模型转化为观察值。
为了填充HMM的矩阵，我们需要观察每个状态的各种事件的概率。
这些概率由于缺乏执行文件是很难获得的。
我们可以假设，一个领域的专家可以提供这些概率，也可以随机分配。
加油/加速
一个组件的动态行为模型，将扩展添加更多的转换，如下所述。
让我们通过一个例子来说明这个。
让我们看看图4，这说明扩展名（例如，额外的转换，由虚线表示）所需的动态行为模式的CruiseControl的组件。
例子包括“eventless”一个校准标签表明系统的当前状态，可能会保持一定的时间间隔，过渡模型的错误（例如，当气体被调用时汽车实际停止），和当一个事件发生的转变（如天然气）会导致意想不到的行为（例如，维护，而不是加快）。
加油/加速
指南
刹车（val+curspeed>0）减速
停止
刹车（val+curspeed>0）减速
巡航/维持
刹车/减速
巡航
加油/加速
图3CruiseControl组件动态行为模型
使用这个扩展的行为模式（图4，无状态F和其过渡将在下面描述），我们假设一个随机的实例，或由该领域的专家做出的转移概率的实例化（即频率的相互作用）。
这些初步的迁移概率（ITPS）成为矩阵HMM的初始元素。
此外，这一阶段还包括架构的错误或缺陷的识别和分类。
我们的多视图构架层次上的组件的建模方法，将引起架构观念上的矛盾，以此来衡量现有的不足。
这种缺陷的例子可以是气界面的信号不匹配，或巡航接口的静态行为水平不匹配。
我们充分利用我们缺陷分类的前期工作[19]模型组件的故障行为。
上面所描述的HMM模型的扩展与失效状态（F），和模型从各种状态到失效状态的转变。
从图中可以看出，一种恢复过渡被添加到指定的组件的恢复状态。
一旦从失效中恢复，这种状态将被指定为组件的活跃状态。
在这里，我们注意到，该技术可以扩展到多个故障状态，分别处理不同的原因，严重程度和类别中的错误。
第2阶段：
参数估计。
第1阶段输出的是一个HMM的初始参数。
在第二阶段，我们使用Baum-Welch算法，根据这些参数的值，使HMM的“了解”这些参数的值目前，我们认为领域专家能够提供修正数据（例如，通过模型模拟）被用来修正的HMM。
我们今后工作的一部分是审核合适的技术来合成修正数据。
图4CruiseControl组件的动态行为扩展模型
一旦HMM被解决和模型的未知参数被估计，我们就利用一个缺陷量化方法，纳入这些参数组件的故障行为。
缺陷定量技术使用成本框架，将结合我们的缺陷分类量化分析得出的架构缺陷。
成本框架使用成本函数，它根据不同缺陷对组件的可靠性的不同影响，建立在以量化缺陷，缓解缺陷相关的成本不同类型的缺陷的基础上。
由成本的一个缺陷和与之对应的一个过渡的频率，我们可以估算与破坏行为有关的未知参数。
这也可以用来计算组件的个别状态的可靠性。
因此，我们在这个阶段，估计模型的未知参数，从而获得HMM的矩阵A和B的最终值。
重要的是，这里要注意缺陷量化和修正数据都是“可插”于我们的技术的，即组件，这两个计算的方法是独立于技术本身的。
第3阶段：
可靠性计算。
解决HMM和估计未知参数后，就获得了一个马尔可夫模型。
涉及数值方法的标准技术应用于评估组件的可靠性的概率，它不会随着时间的推移停止在故障状态。
3.评价
我们的初步结果表明，当评估软件组件可靠性时我们的模型对识别趋势是适合的（例如，比较各种部件的可靠性）。
这种技术尤其适用于“绿色领域”的开发方案，其中的一个组成部分的运行文件可能是未知的或不准确的，或可能不存在组件的状态和事件触发的转换之间的一一对应，因为组件的架构是可任意复杂的。
它也能够提供旨在确定组件的可靠性的各种因素的影响分析。
因此，我们的目的是沿着两个主要方面评估我们的技术：
（1）对实际组件的可靠性测量验证，
（2）有效方法分析的实用性。
我们认识到，充分验证的方法是一个长期目标，并要求核查系统实现的架构模型与真实世界的系统的可用性。
因此，我们必须专注于我们分析方法的第二个角度，并提供了几个例子来说明它的使用。
图5
（一）可靠性状态对组件可靠性的影响
（二）部件的可靠性对恢复概率的影响
例1．我们要找出一个特定的状态是如何影响整体组件的可靠性的。
虽然系统的Markovbased建模只是这样的分析，我们的缺陷分类和成本框架的整合，使我们不仅确定了重要的组件，也确定了对组件的可靠性影响最大的操作。
对一个具有大量状态的组件，这种分析是特别有用的。
改善临界状态的可靠性，可能会导致整个组件的可靠性的改善。
图4（a）显示了巡航控制组件（R1的状态S1的可靠性等），在三种不同情况下的整体组件的可靠性和个别状态组件的可靠性。
从图中可以看出，状态S2和S3比状态S1更重要。
例2.我们希望确定恢复概率的变化是如何影响整体组件的可靠性的。
在一个简单的实验中，我们改变不同的恢复巡航组件，控制从0到1的概率，保持一切不变。
图4（b）图获得部件的可靠性与恢复的概率。
这种分析与容错组件的设计是直接相关的，个别缺陷对整体组件可靠性的影响对确定哪些组件应该首先被恢复是十分关键的。
4.目前方向和开放问题
在本节中，我们将概述我们目前的研究方向。
我们检查开放的研究问题，打算进行处理，并提出解决的办法。
由以上所述的我们最近的结果进行分析，有三大研究问题4.1节中讨论的方案，首先，我们打算用一整套技术取代一个单一的可靠性估计技术，这样可以照顾到不同的软件开发。
第二，我们打算将系统的软件体系架构与固件的相关属性结合。
这将使我们能够有更多的有意义的可靠性评估，考虑到的不仅是软件系统，而且有环境。
这方面我们的研究是在第4.2节讨论。
第三，我们打算在架构水平，建立一个技术套件，评估整个软件系统的可靠性，并利用我们组件的可靠性评估的结果作为实现这一目的的出发点。
这是在4.3节讨论的。
4.4节描述了我们的计划的评估方法。
指南
停止
巡航
F
图6CruiseControl组件的BN模式
4.1发展方案
我们HMM基于组件的可靠性估计技术是一个发展的方案，我们对于组件的动态行为有很好的理解，和足够的信息来合成修正数据。
然而，为了评估组件级和系统级的可靠性，我们应该调整我们的方法，使它应适用于不同的软件开发的情况（回顾1.2节）。
构架层次上的软件可靠性建模框架应足够灵活，以至于能够容纳多个这样的方案。
因此，我们打算建立一整套技术，而不是一个可靠的估计技术。
正如我们已经在第2节中提到，在我们的建议的可靠性评估框架中，包括两个其他的可靠性评估技术。
其中之一是一个基于贝叶斯网络的方法。
关于组件可靠性评估的方法，使我们避免了评估各状态之间的转移概率。
虽然对全部系统和组件的未来使用的细节还了解甚少，但这个方法很早就可以运用在一个新组件的开发中。
在一个可重复使用的组件是由第三方供应商购买的情况下，这也可能是适用的，但目前还不清楚组件的内部结构将如何准备在新的使用环境中的运作的情况影响。
在我们提出的以贝叶斯网络为基础的技术中，我们将利用一个组件的动态行为模式，形成一个图，其中节点表示在动态行为模式下的状态和相互作用状态间所描述的边界。
引入额外的节点来来表示失效。
图6这样的图形是一个简单的例子。
然后，我们建议采取一个标准的贝叶斯网络推理算法，这将产生一个组件的可靠性值作为输入的每一个状态的失效的概率（从获得的上述缺陷定量描述框架）。
这种方法的优点是，它可以建立有很少信息的组件的可靠性评估。
然而，结果可能不准确，因为我们既不知道也无法尝试评估各状态之间的转移概率。
直观地说，我们将预计这将影响可靠性的评估。
我们将在实践中评估这方面的影响，如果需要我们会建议进一步的改善这种技术。
其他技术假设一个组件内的控制转移具有马尔可夫属性（回顾第1.3节）。
因此，组件的行为，可以模拟一个转移概率矩阵P={PIJ}PIJ代表从状态i到状态j的变化的概率在组件中使用离散时间马尔可夫链（DTMC）。
请注意，一个DTMC假设转移概率矩阵是已知的。
在构架层次模型处理时，这可能并非如此。
我们可以在有关于软件组件的不同知识来源的情况下仍然利用DTMCs。
例如，如果某个组件
（1）重复使用过或组件
（2）仍在研发中，但偕同一个详细的需求文档和/或验收测试，我们假定，它会是可能近似组件的未来运行配置文件，也就是其转移概率矩阵。
在第一种情况下，近似的运行时环境中的执行元件中运行文件可以被获得，并可以观察其行为。
在第二种情况下，我们打算充分利用现有的工具（如MATLAB，StateMate）建立可执行模型和模拟组件的预期的行为。
4.2固件模型
另外，一个软件系统模型，应该了解该系统如何与环境相互作用，包括硬件资源，网络，操作系统（为方便本文称为“固件”）是十分重要的。
传统上，硬件和软件已分被分开模拟。
特别的，软件系统设计师往往把重点放在孤立的软件模型上，假设硬件会以某种方式（例如，通过独特的系统实施）符合规定的性能和资源的限制。
另一方面，我们主要关注硬件系统的属性，就如何组织附带的软件没有提供指引。
这两种方法的主要问题是，他们不可能用来分析和验证整个系统
在上面的软件可靠性建模方法，一个共同的硬件/软件协同设计技术的基本问题的情况下，他们对知识系统的执行属性的依赖，无论是在正在运行的系统的统计信息的形式或确切运行文件需要估计的可靠性。
这种依赖性使得这些技术不适合早期的系统设计阶段，因为那时确切的运行文件是未知的，并且任何可以建立的统计模型必然不够精确。
我们建议，以建立一个更加灵活的模型，能够处理早期设计和缺少系统统计操作精确性统计的评估的不确定性。
我们的模式将丰富软件系统的架构规格，硬件系统属性的设置，如硬件主机，主机之间的总线，总线利用率最高，所需的记忆体，最大的CPU负载，操作系统版本等。
实际上，我们建议延长传统的体系结构描述语言（ADL）的结构（集中在一个软件系统的静态，动态结构和行为方面），在一个统一的系统模式中来解决固件的有关属性。
在现有的分析和验证技术下，ADLS可以增强对软件和硬件的统一的模式的验证。
4.3系统级可靠性建模
评估系统级可靠性的方法之一是把整个系统作为一个单独的组件，建立综合的系统级状态机类似于如图7所示的，它适用于建议的组件级技术之一。
显然，这不是一种普遍适用的方法，因为它可能会很难捕捉到许多不同的组件在一个大系统的体系结构中的许多状态之间复杂的相互作用。
此外，可追踪性也有可能成为一个问题：
我们未必能够解决这种规模庞大的模型。
也许最重要的是，采取基于组件的软件架构性质的优势，这种方法可能会失败。
构架层次上的变化往往只需通过添加，删除或替换一个或多个完整的组件就能达到。
在一个单片的可靠性模型，将是很难跟踪复杂结果的FSM的变化。
相反，这将难以追查任何导致组件可靠性问题的原因。
基于这些观察的动机，我们打算建立一个成分和层次系统级的可靠性模型，而不是一个“平”的模型。
这种模式将依赖于我们的组件级可靠性计算。
然而，在我们的评估中，我们仍然打算使用“扁平化”模式作为我们的分层方法的精度评估方法。
实现可扩展性的方法之一是引入分层结构。
这样的结构，一方面适应软件体系结构组件（和连接器）之间的差别，另一方面也适应它们的配置。
我们提出两个层次的分层系统模型。
较低级别的模型是基于各个组件模型的（如上所述）。
更高层次的模型描述组件之间的相互作用，并通过他们的协议是使用最合适的发展方案的技术解决。
就像是有可能使用不同的技术来估计一个系统的不同组成部分的可靠性，我们也可以在系统级使用不同的技术。
此外，两个层次的发展方案需要是不一样的，我们提出的技术应具有足够的灵活性，以适应这一情况。
我们已经开始调查这种观察法的影响。
例如，在一个方案中，我们最近考虑，我们认为我们有一些关于各个组件的知识，所以我们在组件级别使用的基于HMM的方法。
但是在系统级，我们认为，我们正在建设一个新的系统，对如何使用该系统我们的了解还很有限。
因此，基于贝叶斯网络的方法是比较合适的。
图7概念视图的架构级的可靠性估算模型
在非常复杂的系统情况下，由此产生的更高层次的模型仍可能相当复杂。
由于模型的组成性质：
各种更高级别模型的状态的可靠性，在已经较低级别的模型上进行计算，我们可以放心地省略很多内部组件的详细信息。
然而，建设全球互动模式，仍然是一个挑战。
困难是将交互组件植根于一个可伸缩的方式相结合的交互协议。
处理交互状态图的大多数技术（协议子类型，协议的一致性等等），仅仅处理并发状态机。
如果试图考虑到交互状态机的
升级会员 