如何测试关键生命或死亡系统中使用的软件?


51

相对于例如网站,飞机是一种系统,其中某些系统中的任何故障都是完全不能接受的,因为例如飞行监控中的错误会导致自动驾驶仪发生故障并进行潜水。显然,这不会发生,因为波音和空中客车公司的才华横溢的工程师已经在自动驾驶仪中进行了检查,以确保它不会突然决定潜水是一种完全可以接受且安全的动作。或者,也许计算机崩溃了,而新型电传飞行飞机的飞行员实际上无法再驾驶飞机。当然,这些系统中内置了各种安全程序和冗余来防止(软件和飞机)坠毁。

但是,另一方面,很明显,该软件并不是完美的-开源软件和闭源软件都经常崩溃,并且只有最简单的“ Hello World”程序不会失败。在航空,医疗和其他生死攸关的行业中设计软件系统的工程师如何管理他们的软件,以确保软件不会失败(如果失败,至少可以正常地失败)?

我非常希望你们不会全部离开:“哦,我为波音/空中客车公司(或其他公司)工作,但事实并非如此!在您下次的航班/医院访问中玩得开心。”


8
考虑到Therac25和Patriot电池没有啮合的情况,显然还不够好。
洛伦·佩希特尔

@Loren好吧,我毫无疑问没有例外。另一方面,我从未听说过空客A320(电传飞机)经历过重大的软件错误,导致几乎人身伤害/伤害/死亡,并且这种飞机有超过4000架。
waiwai933

3
“ Hello World”也可能失败。大声笑
xandy 2011年

1
@waiwai-实际上,大约在一年前就发生了-传感器故障表明飞机爬得太陡而即将失速。计算机试图返回到水平飞行实际上是一次潜水。没有坠机,但乘客受伤和散落的物品被扔到机舱周围。
汤姆·克拉克森

6
他们不使用有飞行员执照的死囚犯吗?
JeffO 2011年

Answers:


29

我在工业控制方面做了很多工作。它不必像航空航天这样光荣的行业。几乎每台工业机器都具有足够的势能,以致造成严重伤害或死亡。人们受伤时我一直在附近。如果您将大部分时间都花在办公室的办公桌上,您可能会对大多数工厂工作的危险性感到惊讶(当然,直到最近)。现在我们有了更好的机器维护方法。这是它在实践中的工作方式(尽管每个司法管辖区有所不同):

美国有OSHA标准,欧盟有类似(通常更严格)的准则。这些通常从要求您对风险进行分析开始。这意味着您要列出所有危险,然后将这些危险归类,并考虑到诸如某人遭受该风险的频率,避免该风险的难易程度(取决于速度等)等因素。是结果的严重程度(割伤,截肢,死亡等)。

许多分析与防护危害有关。如果在机器上放一个大笼子并用螺栓将其拧紧,则如果机器的组件不能超出防护范围,则认为机器是安全的。如果您需要使用工具,则将其视为维护任务,并且应该对维护人员进行有关如何安全地在机器上工作的培训。但是实际上,大多数机器都需要与操作员进行定期互动,因此我们必须将检修门放在防护装置或光幕等中。这些门和光幕需要进行监控,并应对操作员暴露于危险中的危险提供动力必须以“可靠控制”的方式关闭。

基于该分析,将风险分为各种类别。常见的分类量表是1类到4类(基于EN 954-1标准)。根据这些类别,法律上要求您提供一定级别的机器防护和安全性。

例如,类别4要求:

这些部件中的每一个都不会导致安全功能丧失。

在下一次对安全功能的请求之前或之前检测到单个故障,或者,如果不可能,则故障的累积可能不会导致安全功能的丧失。

在实践中,这可能很难实现,但是由于获得了经过类别4认证的标准组件,因此变得更简单。例如,这些系统中的一个常见组件是安全继电器。这些不仅仅是机械继电器:

  • 它们旨在监视双冗余输入通道,因此,如果您有一个检测故障情况的传感器(例如防护门打开),则该传感器通常具有两个带冗余电路的触点。继电器监视两个通道,如果其中一个通道断开,则会断开执行器的电源,但是如果两个通道都不同时断开,则会进入故障状态,并且只有在维修后才能重新启动机器。
  • 继电器还使用这些线路上的电脉冲,并使用这些信号监视导线的交叉或短路,因此它可以检测到接线故障。
  • 在输出侧,它使用一组双电路来驱动输出线圈,因此,如果一个故障进入“导通”状态,则另一个故障应防止输出通电。此外,还对这些进行监视,并且如果检测到故障,则会阻止操作。线圈本身实际上是双力导向继电器,这意味着输出上具有冗余的物理继电器,并确保每个单个继电器上的触点都物理链接在一起,从而使得4个触点中的一个不会被自身粘住。这些也受到监视。
  • 它还包括一个输入,用于监视辅助常闭触点,以控制您要控制的负载。如果关闭输出,则必须看到常闭触点已接合,这意味着在再次允许电动机接触器再次进入导通状态之前,它已验证是否已关闭电动机接触器或它所处的状态。

如您所知,它们是复杂的设备。每个安全继电器的典型成本在200到600美元之间。显然,这些设备中有软件。为了获得安全继电器的认证,通常必须遵循以下设计:

  • 两个冗余处理器,通常基于不同的设计,这些处理器通常来自不同的供应商。
  • 每个处理器上运行的代码必须由两个在隔离条件下工作的团队开发。这样可以防止单个软件错误成为单个故障点。
  • 两个处理器的输出必须一致,否则安全继电器故障。

使用安全额定组件为机器设计安全系统后,必须让专业工程师审查设计并盖章。然后,您构建机器。然后是体育 将检查机器的结构,以确保它是按设计制造的。他们将对其进行记录,并将对其进行一些测试以确保其按预期工作。这称为启动前审查(PSR),并非在每个辖区都进行。PSR通过之后,您就可以让操作员运行机器。

近年来,安全系统发生了一些革命。一段时间以来,没有人信任通过网络传输安全数据,因此系统的安全部分不允许使用通常称为“分布式I / O系统”的设备,如DeviceNET和EtherCAT。但是,最近的协议现在允许安全设备在这些工业网络上运行。协议利用带时间戳的消息以及连接两端的双重冗余处理。

安全继电器正慢慢发展为渡渡鸟,已由更复杂的安全PLC取代,这就像以功能框图语言构建安全逻辑的方式一样。同样,这些安全PLC使用多余的一切。程序获得批准后,在机器投入使用之前,应先进行P.Eng。将标记程序,并且将使用密码锁定程序/ PLC。它还需要对程序进行哈希处理,并将该哈希记录在文档中(这是P.Eng。真正加盖标记的内容)。

现在,一旦您设计了安全系统,为控制机器本身而编写的逻辑就很容易发生了。程序员经常使机器崩溃,造成数千美元的损失,但至少没有人会受伤。


20

目前正朝着正式验证而非随机功能测试的方向发展。

美国国家航空航天局(NASA)等政府机构和一些国防组织在这些技术上的支出越来越多。

对于普通程序员来说,它们仍然是PITA,但是它们在测试关键系统上通常更有效。

还有一种趋势是尝试从学术界尝试更多技术,例如验证多线程代码。


6
编写了用于NASA任务控制的地面支持软件,并查看了新旧飞行代码的摘要,因此无需特别强调。好的,由于数量的增加,也许美国国家航空航天局在质量控制上的支出比以往任何时候都要多,但是对每个应用程序的关注却远远低于太空计划刚开始时的情况。仍然存在一些对安全至关重要的事情的关注,但是关键任务只需要一个不太全面的测试套件,甚至安全关键性验证似乎也随着时间而下降。
Ben Voigt

7
请注意,我不同意正式验证会非常有效,并且对于产生最高级别的可靠性至关重要。仅仅是经理们了解了它的成本,并且面对越来越复杂的软件,原因是他们不再能够为每个需求和每行代码花费那么多钱。正确的方法是对系统进行分区,并使关键部分保持较小,但是我没有看到有效的解决方案,结果是管理层宣布整个正式验证过程非常昂贵。
Ben Voigt

2
@本·沃伊特(Ben Voight):如果我是一名宇航员,您的报告将令我非常震惊。
2011年

1
@Orbling:宇航员可能应该为这个问题加些重担,但他们首先是一群极度冒险的人。在某种程度上,您已将可控制的风险降低到比您无法控制的风险低一个数量级,并且继续花钱不是很有效,而且我所用的方法是否能解决这一问题尚待商bat点。一些位置很高的经理当然相信他们做到了。
Ben Voigt

1
而且这是可悲的认为没有多少人听过的Dijkstra谁已经持续地谈论自1960年以来正式验证。正如尼采所说:“有些人是死后出生的。”
2011年

12

这取决于软件是什么。例如,在飞机上,通常对关键系统进行双冗余处理。在极端情况下,可能会使用2种不同的硬件设计,以及两套独立开发的软件,每套都可以运行。他们都相互计算和交叉检查。这不是万无一失的,而且非常昂贵。

在进行飞机系统测试之类的事情时,需要进行一系列测试-与飞行相关的系统测试需要花费数月的时间,如果您进行了任何更改,都需要进行一系列的重新测试。这通常是在模拟器中完成的,模拟器可能实际上充满了带有模拟引擎或类似引擎的真实飞机部件(例如,驾驶舱)。正如您可能想象的那样,这也非常昂贵。根据正式的测试程序评估更改,然后在实际飞机上进行试飞。在进行“扰乱功能”测试之类的过程中,允许已更改的项目执行其正常工作,并检查/测试所有内容以查看没有有害影响。这也要花费很多钱,并且可能需要数周时间。

我知道一个例子,其中需要对飞行系统进行非常简单的更改-如此简单,您会惊讶于它的微小之处。但是,重新测试要花费3个月以上的时间,费用约为100万美元。

当您进入医学领域时,将会遇到一系列的监管障碍,这不仅与测试有关,而且与开发流程和文档有关。

所有这些领域都比为网站准备一些PHP代码的地方迈出了一大步。它缓慢,艰苦,困难,无聊,乏味,细致且非常昂贵。以正常的开发/测试成本乘以100左右,您将接近标准。


“使用2个不同的硬件设计,以及两个独立开发的软件,每个软件要运行一个”的示例将很有趣。没有不同意,只是好奇。
Brian Carlton

1
@Brian:2个不同硬件的熟悉示例,例如在防抱死制动系统控制器中可以找到2个独立开发的软件。参见例如infineon.com/cms/jp/product/applications/automotive/safety/…,它在单个IC上使用两种不同的CPU架构(8位和16位)。
谢德勒2011年

4
三个更好。有两个,您只会知道其中之一是错误的。与三个,您可以投票。AFAIK,空中客车A380具有来自两家制造商的三架飞行计算机。
约尔格W¯¯米塔格

多年前,我遇到了一些以这种方式设计的平视显示器。我的主意是,由于成本的原因,这些技术中有许多没有像以前那样被广泛使用。
quick_now 2011年


3

既然您已经获得了足够多的有用信息,这就是我的看法。

很简单-第一次测试总是在程序员自己身上完成的。它倾向于使错误计数保持在较低水平,并确保仅将高质量的程序员保留在工资单上。


3

至关重要的软件除了经过“似乎有效”的测试外,没有经过任何标准的测试,因为它已经遍及整个地方。

所有的投资都投入到了以前看来可行的项目上,或者用于使非程序员可以生产更好的软件的项目。

ps 对第一个没有评论-1,但我很乐意接受-1与我的陈述相反的每个参考。

我可以为发现不正确设计或测试的关键软件的每个参考文献都加+1?Simson Garfinkel 在WIRED上的一篇文章中记录了十个案例


不幸的是,这太准确了。
Ben Voigt

当然,我接受了您提出的-1的报价。
Brian Carlton

@Brian Carlton您没有提供参考...
Apalala 2011年

那么DO-178,用于GPS的MOPS呢?至少我的工作测试可能需要一年多的时间。请注意,测试不能确保代码没有错误,并且在任何可能的情况下都符合规范。
jinawee

2

对于所有情况,都没有一个答案。由各个制造商决定如何设计和测试他们的软件。但是整个软件开发过程必须符合正式规范。

例如,当创建用于医疗设备的软件时,您必须遵循用于医疗设备的IEC 62304标准。(不幸的是,我只能链接到维基百科,因为它不是免费的)。世界上几乎每个国家都要求遵守此标准。

这些要求的严格程度取决于受到伤害的风险。例如,生命支持设备遭受伤害的风险最大(如果系统发生故障,则肯定会导致死亡),而使用疾病诊断程序运行的系统的风险则较低(如果系统发生故障而无法正确诊断出绝症,则可能导致死亡)。

但这基本上意味着从需求到软件必须具有可追溯性。您必须执行软件单元验证。那没有指定验证是什么。可以是单元测试,可以是代码审查。对于风险较高的设备,您必须手动检查软件单元之间的接口(据我了解并记得)。当然还有很多其他规则。哦,您必须写很多文档才能记录您的工作。

该标准并未禁止敏捷开发,尽管在阅读时似乎是在考虑瀑布式开发的情况下编写的。

我不了解软件开发的其他领域,例如航空,火车,汽车等。但是我认为还存在其他类似的正式指南。


1

使用了许多技术,包括但不限于:

  • 正式设计和/或验证
  • 严格的编码标准,避免花哨的编程,例如动态分配内存
  • 质量要求很高的工程师
  • 许多静态分析技术,例如代码审查,故障树,FMECA,...

但是第一技术是:

  • 测试中

首先,与设计和编码相比,航天器的软件需要更多的测试工作。

飞机经过数年的飞行测试,使飞机进入极端状态。这不仅测试物理结构,还测试软件。


1

杰克·甘斯尔(Jack Ganssle)在EETimes上于2009年3月1日美国东部时间上午12:00发表了一篇文章“ Perfect software”。从那里几点:

  • “从理论上讲,软件是唯一可以完美的组件,这应该永远是我们的出发点。” -杰西·普尔(Jesse Poore)这么说。在他的网页上,您将发现如何以比普通软件高得多的成本制作出完美的软件。
  • 有高度可靠的操作系统的工业提供商。文章提到了Mircrium和Green Hills。在Micrium的网页之后,有认证标准的列表。这些必须是行业遵循的流程和规则。那是基于形式上的验证,但与理论却大相径庭。

有趣的是,关于商业软件,Capers Jones收集的数据表明“一般而言,软件的缺陷清除效率(在运输前被清除的错误的百分比)为87%。固件的评分要好得多,为94%。” 对我来说,这些都不是完美的。较早的答复者提到的那篇文章指出,NASA航天飞机团队实现了99%的错误清除率,但每年要花费3500万,花费约40万行代码。

同一作者在2009年1月1日发表的一篇更有趣的文章“用于可靠系统的软件”似乎更有意义。可以这样总结:

  • 关于开发过程,业界遵循DO-178B或IEC61508。它强调覆盖范围最大的测试。但是,几乎没有证据表明这样做的有效性。
  • 认证机构,可信赖软件系统委员会,已出版了一本书,标题为“可信赖系统软件-充分证据”。这是一个很好的参考。
  • 该书主要要求三件事:[1]为可靠性测试制定明确的规则。[2]根据规则进行测试,但还要确保普通客户或监管机构可以理解这些测试,并且花费的时间比开发人员花费的时间少。[3]确保由软件工程和问题领域的专家来进行开发和测试。
  • 软件供应商必须对任何软件故障承担保证或其他补救措施。
  • 使用安全的语言,尤其不要使用C。建议使用SPARK。
  • 合同方式设计是SPARK的优势之一。合同设计是一项将测试嵌入到每个函数/方法调用中并始终在运行时执行的重要技术。合同不仅仅是过去的一个简单的assert(),它还可以嵌入针对结构意图的测试,并确保在原始开发人员大多转而从事其他项目时,在维护周期的稍后时间不会违反任何规定。有证据表明,合同设计已经产生了非常可靠的软件产品。SPARK及其工具可用于协助生成认证测试用例,以简化认证过程。

根据我的记忆,HP大约十年前就实践了合同设计。在一个小型团队中,有50万行代码,交付后仅报告了2个错误。非常令人印象深刻。

在我看来,只有在成本不高的情况下才能获得可靠或完善的软件。框架或自动化是必须具备的。


0

它们通常具有用作故障保护的硬件互锁

例如,用于杀手机器人的标准邪恶文本框设计始终带有一个kill-switch:P


0

每个行业都有自己的一套监管机构,对与安全相关的硬件和软件有测试和文档要求。请考虑来自Underwriters Laboratory(UL)的PDF,该PDF引入了UL 1998标准:http : //www.ul.com/global/documents/offerings/industries/hightech/software/UL_softwareconformityassesssment.pdf

该文档中引用了UL,CSA和IEC的许多其他相关参考。

通常,与安全相关的软件将具有冗余硬件电路,或者需要具有其他冗余控制功能以确保安全操作和安全故障模式。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.