形式化验证用户界面安全

用户界面软件的验证：以可用性相关安全要求和可编程医疗设备为例

一、引言

DESIGN 用户界面软件中的异常是安全关键应用领域（包括航空、电力生产和医疗）中的一个重要问题。在这些领域中，制造商被监管机构要求确保其系统或设备已采用最佳实践进行开发，且与其产品使用相关的风险已降至最低程度或“合理可行的最低程度”。在系统或设备投入安全关键环境使用之前，必须完成此项证明。此类证明通常包括“证明”该设备满足旨在缓解已识别危害的一系列安全要求（参见[1]）。美国食品药品监督管理局（FDA）已在草案文件[2]中制定了一套此类要求，重点关注可编程医疗设备，特别是输液泵。

本文关注如何证明软件设计符合与使用相关的需求。FDA指南提出，此类证明“在很大程度上依赖于在软件开发生命周期各个阶段所执行的全面的软件测试、检查、分析及其他验证任务”[3]。为这类分析所产生的数据通常十分庞大，但并不能证明无合规性违规。

形式化技术提供了额外的信息。它们是简洁的、精确的和详尽的，并且可以在完整实现之前应用。使用形式化技术对系统设计进行分析包含两个主要步骤。第一步是建立设备的形式化（即数学的）模型，以捕获系统的相关特性和功能。第二步是使用机械化工具对所开发的模型进行系统性分析，以检查模型中描述的行为是否符合相关需求。如果模型正确地表示了实际系统，则在模型上验证成立的需求也同样适用于实际系统。当某个需求的分析失败时，形式化技术能够提供信息。该信息通常以反例的形式呈现，识别出设备的设计方面可能违反被分析需求所施加约束的具体场景。开发人员可以建设性地利用反例来探究故障的意义，并决定是否需要重新设计，或是否可以通过考虑其他因素或过程来缓解已识别的故障。

本文使用了三种形式化技术来分析交互式系统的用户界面软件：模型检验、定理证明和仿真。

1) 模型检测用于验证模型，并分析设备界面模式行为是否符合相关的安全要求。该验证技术专注于在状态转换系统上，通过详尽地探索转换系统的状态空间，开发人员可以自动检查模型是否满足某一需求。模型检测的巧妙之处在于构建出分析工具能够处理其复杂性的抽象模型，并恰当地表述需求。

2) 定理证明用于分析无法通过模型检测进行高效分析的设备的详细模型。该验证技术基于自然演绎，通过推理规则的机械化应用来解决逻辑问题。可以处理任意复杂的模型和需求。然而，需求的证明通常不是完全自动的，可能需要分析师的指导。

3) 仿真在整个分析过程中被用来验证所开发的模型与实际系统的一致性。本研究采用的特定仿真技术涉及使用可执行的形式化模型和原型设计。详细的形式化模型指导交互式原型的行为，其功能和特性与实际系统非常相似。这些原型可供领域专家检查形式化模型是否准确模拟了实际设备的行为，也可供人因专家与工程师及形式化方法专家讨论使用相关需求。形式化方法专家可以以其其他团队成员易于理解的方式展示通过模型检测或定理证明获得的结果。最后，工程师可以在较低成本下探索不同的设计方案。该过程对于由开发人员组成的多学科团队所进行的人因中心设计过程至关重要[4]。

迄今为止，几乎没有提供相关指南来证明如何使用形式化方法技术对用户界面软件进行分析。因此，形式化验证在可用性方面的工业应用进展缓慢。我们针对这一挑战，向软件开发者展示了如何运用形式化技术，以高度保证用户界面软件设计符合给定需求，同时探讨了软件工程师、领域专家和人因专家如何协作，确保满足需求的方式能够缓解使用错误。

A. 贡献

我们提出了一种方法论，可供开发人员在将形式化方法技术应用于用户界面软件与使用相关的需求分析时作为指导。本文描述了证明需求得到满足所采取的步骤。这包括证明以下内容： 1）该模型正确描述了设备的交互行为；2）以自然语言给出的需求被正确转换为模型的形式化属性；3）模型满足这些形式化属性；以及 4）如果存在失败，其后果会被考虑，从而可能导致设备的重新设计、性质的修改，或对整体系统进行更改以缓解故障。

基于商用输液泵的案例研究用于说明该方法论。我们推进了美国食品药品监督管理局使用形式化技术[5]所提出的议程。然而，这种分析在开发医疗设备的组织中是否可行是一个重要的考虑因素，这一挑战也是本文讨论的一部分。

B. 组织结构

第二节将本文描述的工作置于使用场景中，讨论相关工作并界定所取得的成果。第三节描述了用于用户界面软件设计的形式化分析的方法论。第四节阐述了医疗器械的用户界面特性。第五节说明了所开发的两种模型形式。第六节讨论了如何针对实际设备对模型进行验证。第七节描述了需求，并说明了如何证明表示这些需求的定理。最后，第八节提供了讨论与结论。

II. 相关工作

其他研究与本文一样，关注如何验证与使用相关的要求。Bolton et al.[6]利用用户任务模型作为生成验证属性的基础，而[7]中提出了一组体现可用性原则的模式。 Bolton和Bass [8],[9]使用SAL [10]对Baxter iPu mp的相关属性进行分析。他们将规范性任务的形式化表示转换为可在输液泵用户界面模型上检查的属性，并系统地分析规范性任务以识别潜在的错误序列。示例任务包括开启和关闭输液泵、停止输注以及输入待输注体积。他们的论文详细讨论了在使用模型检测器对真实系统的模型进行建模和分析时所面临的挑战。Mori et al.[11]和菲尔兹 [12]同样以形式化语言表示任务，并使用模型检测器分析任务。Berstel et al.[13]使用形式化符号对WIMP风格界面进行建模和分析。

鲍恩和里夫斯提出了一些用于建模用户界面的初始设计模式[14],，例如callback模式，表示用于确认用户操作的确认对话框的行为，以及binary choice模式，表示用于获取来自用户的数据的输入对话框的行为。这些模式解决了与使用相关的设计问题。它们的用途与我们的方法正交，因为它们关注的是用户界面软件模型的最佳建模实践，而非给定安全要求的验证。

大多数先前关于安全要求形式化验证的研究都集中在系统控制部分的分析，而非人机界面。例如，一组美国食品药品监督管理局的安全要求也已在[15]中使用 UPPAAL [16]模型检测器进行了形式化。他们的分析侧重于输液泵控制器的设计方面，而非用户界面设计和与使用相关的需求。Li et al.[17]开发了可用于安全联锁机制分析的验证模式互操作性医疗设备。尽管他们使用这些模式来分析与使用相关的属性，例如“当激光手术刀发射激光时，患者的气管氧含量不得超过阈值 ΘO2”，但其目标是将模型检测器集成到安全联锁的实际实现中，作为运行时故障预防机制，而不是对安全联锁的使用相关方面进行分析。这项以及其他类似的研究活动，例如[18]–[20],，并未关注对与使用相关的需求的分析。Heitmeyer团队使用SCR [21]开发了一套成熟的工具，专注于验证具有与本文所述相似特征的需求（尽管并非明确与使用相关）。他们的方法采用表格表示法来描述需求，使该技术相对易于被开发人员接受。

结合仿真与模型检测，如第三节在模型验证中所讨论的，在例如[22]–[24]中也受到了关注。最近关于PVS规范仿真的研究已被用于通过仿真[25]支持本文所述的特定建模过程。

尽管本文以现有设备为起点，但这必须结合将形式化规范作为设计过程一部分的相关工作来理解。为此目标开发了诸如Event B [26]之类的工具。在使用Event B时，首先建立一个初始模型，用于规定设备特性并整合安全要求。然后通过有关特定功能如何实现的细节逐步进行精化。鲍恩和里夫斯 [27]提出了类似的用户界面设计精化方法。他们的工作特别针对用户界面布局的设计。采用呈现交互模型来描述用户界面布局中的组件控件。通过形式化与非形式化精化的结合，将初始规范逐步转化为实现。

III. 建模与分析方法

本文所描述的证明法规要求的过程包含一系列步骤 .如下所示 1）开发用户界面模型：该模型描述了设备用户界面的状态、可用的用户和内部操作，以及这些操作如何改变设备的状态。这些模型以状态机的形式表示。建模语言的具体选择取决于要执行的形式化用户界面分析类型。

2）模型验证：通过模型检测和仿真来进行。验证过程包括为应适用于该设备的性质p生成证据。具体方法是创建形式为always notp的无效断言，并使用模型检测器查找这些无效断言的反例。所生成的反例即为性质p的见证迹，因为它们标识了满足p的操作序列。这些序列可与实际设备的日志进行比较，以评估所识别的操作和设备行为的合理性。该技术类似于在[28]中用于生成测试用例的方法。对模型的仿真提供了机会非形式化方法专家的分析师可以交互式地探索用户界面的行为。这有助于验证模型是否反映了实际系统的设计，或讨论某一特定需求的重要性。使用模型检测还是仿真作为验证方法论，取决于分析师（例如，形式化方法专家可能更倾向于使用模型检测）以及模型本身（例如，复杂的模型可能超出模型检测工具的能力，因此仿真成为唯一选择）。具体示例在第六节中讨论。

3) 需求形式化：这包括两个阶段。第一阶段是对需求进行消歧，以便更易于将其转换为设备特定属性。这在 [29]中有更详细的描述。这些精确的需求旨在与实现无关，可适用于多种设备。第二阶段涉及对每个形式化后的需求进行细化，使其具体针对被分析的设备。这两个阶段通常是交互式的，可能需要与人因专家讨论以验证对需求的解释的正确性，并与监管机构沟通以确保所开发的性质准确捕捉了原始需求的本意。

4) 证明形式化需求：通过模型检测或定理证明，对表示形式化需求的性质在模型上进行证明。在本示例中，所有形式化需求均使用这两种技术进行了证明，但涉及完整数字输入的需求除外，这些需求仅能通过定理证明高效地完成证明。

5) 迭代该过程： 分析过程的步骤可能会随着模型的逐步细化而被反复执行，或者可能触发生成相关论证，说明所建模的设计为何满足或不满足需求。

尽管所述过程假设采用基于模型的视角进行开发，但相同的方法论也可回溯应用于现有设备。对于已经开发完成的设备，构建模型的过程涉及对设备实现进行逆向工程。可以通过逆向工程代码来获得系统的白盒视角，或者通过基于用户手册和设备使用经验建模来建立系统的黑盒视角。在本文中，正是通过该方法论的回溯应用，对示例医疗器械进行了分析。

四、医学实例

静脉输液泵在医院的许多使用场景中被广泛应用，例如重症监护和肿瘤科。这些设备旨在将医生处方规定的药物剂量通过静脉途径在指定时间段内输注。此类设备特别关注使用错误问题。护士通常在压力下根据医生或药房提供的纸质处方对泵进行编程。处方的格式可能在格式呈现、可读性、使用的单位以及处方是否聚焦于体积和速率，或体积和时间——描述处方的两种替代方式。

所选设备（见图1）是一种现有的商用产品[30]，具有许多控制时间相关过程的设备共有的特性。临床医生用户通过该设备设置输液泵参数并监控输注过程。可以使用函数键和V形键组合来更改数值和设置（见图1）。V形键用于逐步增加（通过指定操作f up或sup），或减少（通过 f down或sdown）输入的数值。按住V形键可加快增量或减量的步长。

由于设备体积较小，因此依赖于模式来有效利用屏幕和可用的操作键。该模式结构首先区分设备处于输注中（即向患者泵入药物）还是暂停中（即已暂停）。设备还提供其他模式用于更改治疗设置和泵配置选项。例如，数据输入模式控制V形键是调节输注速率、待输注体积（ vtbi）或时间，还是允许用户在菜单选项之间移动。在袋模式和查询模式下可通过菜单选择预定义的设置。袋模式允许用户从一组输注袋选项中进行选择，从而将vtbi设置为预定值。通过查询按钮启动的查询模式会生成由制造商配置的一系列选项菜单。这些选项包括锁定输注速率、取消锁定输注速率、设置vtbi和时间而非vtbi和输注速率，以及更改体积和输注速率的单位。设备可通过三个功能键（key1、key2 和 key3）在不同显示屏模式之间切换。每个功能键均关联一个显示屏，用于指示其当前功能（f ndisp1、 f ndisp2 和 f ndisp3）。

在接下来的需求分析中，将根据需要提供有关设备和模式的更多细节，特别是在分析某一需求导致有趣结果时。

V. 开发设备模型

既无法通过开发和细化满足需求的模型，也无法从程序代码生成模型。该设备已经开发完成，且我们无法获得程序代码。因此，该模型是结合用户手册、仿真以及设备本身，通过手工方式开发的。

在本文所述的分析阶段，作为设备可用性属性的一般分析的一部分，特定泵的模型已经建立，但当时并未考虑本文所涉及的特定FDA要求。该模型曾被用于分析交互模式的属性，例如设备模式是否由设备明确呈现。此初始模型使用NuSMV模型检测工具进行了分析。

该模型被进一步扩展，以促进对设备数字输入系统的分析，从而证明各项FDA要求。这种扩展的一个结果是模型规模显著增加，导致使用NuSMV模型检测器变得不可行。因此，我们在分析扩展后的模型时更换了验证技术。我们选择的是定理证明，尽管其自动化程度低于模型检测，但能够处理更复杂模型的分析（参见[8]）。所使用的特定定理证明器是PVS [33],，它提供了一种表达性强的规约语言，便于对初始模型进行转换和扩展。NuSMV采用符号模型检测。其他模型检测技术（例如有界模型检测）也存在，并且在NuSMV工具集中可用，这些技术可能能够高效地分析扩展模型在相关属性上的表现，但可能以牺牲完备性为代价。采用PVS的另一个关键原因是其能够生成原型，从而支持模型的验证以及对需求的更广泛讨论。

A. 设备的初始模型

该设备的模型包含两个主要元素：一个通用的“泵”组件，用于建模由设备控制的泵送机制；另一个是“界面”组件，专用于该设备的特定用户界面。泵组件已在其他模型中重复使用。例如，另一家制造商开发的输液泵也在 [31]中进行了详细研究，该研究使用了此组件。初始模型重点关注涉及与用户交互的设备功能。该模型采用了底层泵流程，但重点在于操作对设备基本模式（输注中、已暂停、关闭）、设备交互模式以及所显示信息的影响。

为了简化建模过程，采用了一种以操作为中心的一阶表示法来描述输液泵提供的用户操作。所使用的表示法[模态动作逻辑（MAL）],及其到SMV的映射，并通过NuSMV进行分析，这些功能由IVY工具[7],[34]支持。MAL是一种简单的状态转换语言，可轻松从状态转换图或SCR表格格式[21]转换而来。采用这种表示法是因为其类型更容易被接受由开发人员完成，使其操作和状态转换在其描述中更加明确。将需求转换为性质的属性使用时态逻辑表达。IVY 和 NuSMV 均支持 CTL 和 LTL 逻辑（见 [35]）。NuS MV 通过 CTL 模型检测实现 LTL 模型检测，通常效率较低 [36]。在实际应用中，除非某性质只能用 LTL 表达，否则均采用 CTL。为了便于使用模型检测进行分析，标记值被用于泵变量 vtbi、输注速率、时间以及输注体积，这些变量被假定为在范围 [0… 7] 内的整数。当分析局限于设备的模态行为时，这些简化被认为是合理的。

以下MAL模态公理描述了key1（参见图1）具有确认设备复位效果的条件（图2显示了此步骤中的泵显示屏）。

顶行=clearsetup →[key1]顶行 ′=暂停中 & middisp[drate] ′ & !middisp[dvtbi] ′ & !middisp[dtime] ′ & middisp[dvol] ′ & !middisp[dbags] ′ & !middisp[dquery] ′ & !middisp[dkvorate] ′ & f ndisp1′=fvol & f ndisp2′=fvtbi & f ndisp3′=f null & 输入模式′=rmode & effect(device.reset) & keep(bagscursor,rlock)

该公理描述了（在[key1]之后）操作key1的效果。操作左侧的表达式，即(topline=clearsetup)，表示启用该操作所描述行为的条件。这说明当显示屏顶行显示“clear setup”时，若触发该操作，则[key1]之后的表达式将描述其行为。该规则描述了可见属性 middisp、topline、f ndisp1、f ndisp2 和 f ndisp3 的变化。topline′ 等属性的加撇符号表示该操作会更改该属性的值。操作 key1 还会更改设备的模式（ entrymode），以允许输入输注速率（rmode）。最后，该规则描述了此操作如何进一步调用泵组件中的操作（ device.reset），以初始化所有泵变量。在可重用的泵组件中，通过 MAL 规范中泵标识符 device 来访问操作 reset。keep(…) 表达式指定了哪些属性不受该操作影响并保持不变。

此示例展示了MAL模型如何聚焦于设备的界面特征和模式，具体描述了操作如何改变设备的显示屏和模式。该模型采用了一个简单的时间离散模型。当输注过程持续进行或设备处于暂停状态时，通过操作tick来增加时间。在后一种情况下，时间值用于确定暂停已持续的时长。即使没有完整的数字输入功能，该模型在NuSMV中的分析仍需要大量处理，对于可处理的属性子集，分析耗时约 90分钟。分析工作是在配备8 GB内存的Apple MacBook Pro 2.9 GHz Intel Core i5上完成的。关于模型检测真实用户界面模型相关挑战的详细讨论，参见[8]。

B. 设备的详细模型

设备的第二个模型，该模型包含了分析各种FDA要求所需的额外细节，是通过将MAL系统地转换为PVS [33]定理证明系统，并进一步扩展与数据输入系统相关的细节而开发的。PVS原则上允许对涉及无限多个状态的模型和属性进行分析。前一节中描述的MAL片段的等效规范是

按键1_情况_clearsetup(st: (每_按键1)): 状态 = st 满足[顶行 :=暂停中, middisp :=LAMBDA (x: imid_类型): (x= drate) 或 (x= dvtbi) 或 (x= dvol), 设备 :=重置(设备(st)), fndisp1 :=fvol, fndisp2 :=fvtbi, fndisp3 :=fnull, 输入模式 :=rmode ]

PVS理论捕捉了MAL模型的所有特性，包括时间，同时还包含完整的数字输入模型及其他具体细节。在规范中可以见到与MAL元素相对应的PVS特性。当条件 topline(st) = clearsetup为真时，会在更通用的key1函数中调用此函数key1_case_clearup。该函数的定义域为 (per_key1)，其中per_key1是一个谓词，用于将函数定义域限制为可执行该操作的状态集合。

VI. 针对实际设备的模型验证

使用NuSMV [32]模型检测器通过证明一系列属性，首次验证了模型对已实现设备的保真度。该模型的验证不可避免地包含了为减小模型检测分析的状态空间所需的状态抽象。生成的见证迹提供了诸如模式转换序列等结构细节，而非输注速率具体值输入的细节。

NuSMV 接受一个有限状态模型（从上述所示的 MAL 模型转换而来），并对其进行详尽分析，以证明或反驳某个性质。此类性质的一个示例是：一旦输入了相关的泵变量，输注将导致进入一个输注体积等于所输入待输注体积的状态： AG(设备.输注速率= 1&设备.待输注体积= 7⇒AG(设备.已输注体积!= 7))

该性质以否定形式表达。它断言，对于所有路径，只要输注速率被设置为1（一个标记值）且待输注体积被设置为7，则不可能达到一个输注体积等于7的状态。这一特定性质是通用的，因为它是任何可编程输液泵都期望具备的特性。它不依赖于设备用户界面的具体细节，仅依赖于通用泵模型，但其结果可用于分析用户界面，从而实现对不同用户界面的比较。正如预期，当检查该性质时，性质不成立，并生成一个步骤轨迹（见证迹），其中输注速率被设置为1，且待输注体积被设置为7。这表明一旦发生这种情况，设备最终会被设置为开始输注，经过更多步骤后，将达到一个已输注体积变为7的状态。该轨迹可与实际设备日志进行比较。

该模型在转换为更完整的PVS模型之前，用于验证一组合理性属性。对于第一个模型中指定的每个操作，都描述了一个转换PVS状态描述的函数，并且对于描述操作启用条件的每个权限，生成了一个PVS谓词。随后添加了纹理，以更详细地描述用户界面行为，特别是与泵的数据输入系统相关的行为。这一转换过程使用了一组非正式规则来实现。然而，该转换的正确性保持属性并未经过形式化验证。此外，还从PVS模型自动生成了一个原型，以获得具有实际设备“外观与操作感受”的交互式仿真（见图2）。

VII. 形式化与验证需求

在本节中，我们演示了形式化和验证与使用相关的安全需求的过程如何促进分析师与参与用户界面开发的其他专家之间的建设性对话。

所开发的设备模型被用于分析两组虽小但具有代表性的需求。首先考虑[5]中描述的FDA要求。这些需求旨在减轻可能导致输液泵误编程的使用危险，从而避免治疗延迟甚至对患者造成伤害。然后，基于[38]和[39]中描述的属性模板，考虑另一组需求。这些附加需求捕捉了用户界面设计中的最佳实践。需要注意的是，尽管该过程是针对特定设备进行演示的，但该方法论具有普遍适用性，有助于设计出更好的用户界面。

A. 形式化过程

为了形式化以自然语言给出的需求，必须考虑其精确的解释（见[29]）。一种建立精确解释的方法是将需求转化为逻辑属性。这些属性使用PVS语言表达，该语言结合了类似于编程语言中使用的函数表示法以及诸如AND（合取）、OR（析取）、IMPLIES（蕴含）等逻辑连接词。通过定义更易于不同利益相关者理解的抽象，可以实现精确性。此外，这一过程有助于构建与需求相匹配的PVS定理。形式化必须准确捕捉最初由监管机构提出的需求本质，同时也需符合人因专家的理解，因为他们能够就需求的用户层面以及设备的具体属性是否满足这些需求进行评述。

B. FDA要求

FDA要求针对输液泵的安全性。对于每项需求，提供以下信息：FDA文档中描述的原始表述、该需求所解决的安全问题、需求的形式化描述，以及针对示例设备对该需求的合规证明。

R1：清除泵设置和重置泵需要确认。

• 安全问题 ：此需求旨在检查是否存在障碍（在此情况下为确认）以降低输注设置被意外清除或恢复到预设设置的风险。
• 形式化 ：为了形式化该需求，需要构建一个逻辑性质，要求在确认操作发生之前，相关的泵变量不得被清除。该性质还需说明，任何其他操作（非确认操作）均不会改变指定的泵变量。为了清晰起见，形式化描述将针对每个泵变量分别进行。对于泵变量vtbi，该需求可表述如下：
  就绪_以_清除(vtbi)(st) 蕴含 (清除_设置(vtbi)(st) =x 且 确认_操作(清除_设置(vtbi)(st)) = 0 且 无 _确认(清除_设置(vtbi)(st)) =x)
  在上述公式中， ready_to_clear(vtbi) 是一个谓词，用于标识设备处于就绪状态以清除待输注体积值的状态。操作 clear_setting(vtbi) 指定了在可能的确认操作之前清除设置的第一步。此操作本身并不清除设置，但必须先于确认操作执行。
• 针对特定泵的解释 ：进一步细化抽象性质中术语的过程，对于就需求如何适用于特定泵达成一致具有重要意义。该过程促使人们思考，例如，当设备“准备清除”时，其状态应为何种状态，以及应如何向用户传达设备的状态。此外，还需考虑确认的方式以及如何向用户发出确认信号。由 no_confirm 所捕获的操作也同样值得关注，因为它们定义了哪些操作可以用于放弃清除设置。例如，在示例设备中，当设备开机并处于暂停中状态时，可以清除待输注体积。仅当泵变量的值非零时，才允许执行清除该泵变量的操作。用于表示泵是否正在输注和是否开机的相关状态属性分别为 infusing? 和 powered_on 。因此，谓词 ready_to_clear 可以表达为
  就绪_到_清零(待输注体积)(状态) = 非 设备（状态）正在输注? 且 设备（状态）已通电_? 且 设备（状态）剩余输液量 = x 且 x /= 0
  其中x是一个参数，表示一个通用但特定的待输注体积值。通常需要对就绪_到_清除进行规范说明，并包含用户界面的视觉属性。例如，在本例中，除非显示屏顶行显示“输注中”，否则设备应处于可清除状态。然而，我们认为在公式化表达中无需包含这一点——分析中已考虑了其他需求，用以证明用户界面中操作模式的可视性。通过将泵关闭后再重新开启，即可实现对泵变量的必要清除。以这种方式清除设置时，当设备重新开启后，系统会请求确认。用户可通过操作键1提供该确认。确认请求通过顶行显示“清除设置”来提示。
• 证明需求 ：该需求可在PVS中通过使用预定义的证明策略grind（执行量词消去、定义展开和命题简化）对每个子目标进行证明，且无需人工干预。

R2：如果输液泵暂停超过t分钟，则应发出警报。

• 安全问题 ：此需求旨在确保在设备无人看管时向用户发出警报。
• 形式化 ：该需求可以使用谓词 user_input_strictly_overdue 进行形式化，该谓词用于指示设备是否因无操作而暂停超过指定时间段，以及谓词 alert ，用于描述设备产生的适当警报：
  用户_输入_严格_超期(st) 蕴含 警报（状态）
• 针对具体泵的解释 ：通用表述可以进一步细化，以捕捉与设备相关的具体场景，例如当设备在已暂停状态下无人看管时。在这种情况下，谓词 user_input_strictly_overdue 可以更详细地表述为
  user_input_strictly_overdue(st)= paused(st) AND elapsed(st)> timeout
  其中， paused 和 elapsed 对特定的输液泵具有特定含义。在这种情况下，当设备已开机但未处于输注中时，输液泵为已暂停状态： pause(st)=设备(st)‘powered_on? AND NOT 设备 (st)‘正在输注? 属性 elapse 指定设备在待机模式下自上次使用以来经过的时间。当设备处于已暂停状态时，每次滴答操作（模拟所构建模型中的时间推移）都会对该属性进行增量。
• 证明需求 ：该需求可以通过结构归纳法对所有可达状态进行证明。即，PVS 定理包含以下两部分：第一部分证明形式化的需求（在定理中表示为R2assertion）在初始设备状态成立；第二部分证明，对于任意一个满足需求的通用状态pre，该需求在后续状态中仍然成立。
  为真时，对于通过任何可用操作从转换前状态到达的任何转换后状态，该需求也始终为真：
  R2：定理 对于所有（转换前状态，转换后状态：状态）： （初始?(转换前状态) 蕴含 R2断言(转换前状态)）并且 （R2断言(转换前状态) 与 状态_转换(转换前状态, 转换后状态) 蕴含 R2断言(转换后状态)）
  在该定理中，谓词 state_transitions 用于表示状态 st1 与 st2 之间的关系，即如果 st2 可以通过从 st1 出发的任意可用操作到达，则二者相关。此需求可在 PVS 中通过将定理按可用操作拆分为子目标，并使用归约完成每个子目标的证明来加以验证。

R3：如果输液泵处于需要用户输入的状态，输液泵应每t分钟发出周期性警报/指示，直到提供所需的输入。

• 安全问题 ：此需求旨在缓解临床医生输入不完整输注参数的情况。例如，当临床医生在对设备进行编程时被中断，就可能发生这种情况。
• 形式化 ：形式化的需求包含以下元素： alert ，描述设备产生的适当警报的谓词； ready ，识别警报发出前设备状态的谓词；以及 user_confirm ，清除警报的操作：
  用户_输入_严格_超期(st) 蕴含 (警报（状态） AND 就绪(用户 _确认(st)))
• 针对特定泵的解释 ：为这些抽象术语提供解释，要求设计者和人因专家考虑在需求中需要关注的设计特性。例如，当设备因无操作而暂停超过指定时间时（参见需求 R2）， user_input_strictly_overdue 应为真。该形式化还促使分析团队思考如何向用户传达此设备状态，以及使用哪个键作为确认键。在该特定泵中，警报通过适当的顶行显示（提示）表示，同时伴有可听见的报警声。操作 user_confirm 定义为键3。注意，如果键3未启用，则确认操作无效。最后，需定义谓词 ready 。它检查设备是否返回到 已暂停状态，并且经过时间被设置为小于超时值。
• 证明需求 ：该需求可以在PVS中通过结构归纳法进行证明，类似于前面的例子，仅需最少的人工干预。

R4：该输液泵的流速应为可编程。

• 安全问题 ：该需求旨在确保临床医生能够根据药房提供的处方中指示的流速值对输液泵进行编程。
• 形式化 ：这一需求较难做到精确。它需要解释在此使用场景中“可编程”的含义。该需求旨在确保处方中指示的任何流速值都可以在输液泵中进行编程。一个合理的解释是，当处于相关模式时，总存在一个可用的操作，能够使泵中设定的流速更接近目标流速。因此，该需求可以重新表述如下：“如果设备处于就绪状态以输入流速，则总存在一个操作可使设定的流速更接近预期流速，并最终达到目标流速。” 这一重新表述可转化为以下逻辑属性：
  entry_ready(rate)(st) AND (rate(st)> e IMPLIES rate(st)- e>= rate(a1(st))- e) AND (rate(st)< e IMPLIES e- rate(st)>= e- rate(a2(st)))
  其中，e 是流速的目标值，a1 是降低流速的操作，a2 是增加流速的操作。
• 针对特定泵的解释 ：该需求在表述上引发了关于操作 a1和a2的性质、目标流速如何向用户显示，以及设备如何指示接近目标的进度等问题。对于该特定泵，当满足以下条件时，设备处于可接受流速值（rate_entry_ready）的状态：设备已开启、输注流速未被锁定，且顶行显示为“暂停中”或“输注中”。提供预期可编程性的两个操作是单个向上V形键（sup）和单个向下V形键（sdown）。请注意，该需求不涉及可编程性的效率问题，其目的是验证是否存在一系列操作可用于输入指定值。关于编程效率的问题需通过另一项独立的需求来定义。
• 证明需求 R4 ：PVS证明器在无需辅助的情况下使用归约完成此定理的证明。

R5：为避免对输液泵的设置（如流速/待输注体积）发生意外篡改，更改设置应至少需要两个步骤。

• 安全问题 ：该需求旨在缓解由于意外篡改泵的设置而引发的危害，例如因单次错误的按钮点击所导致的问题。
• 形式化 ：该需求有助于进一步说明抽象在与不同利益相关者进行沟通时所起的作用。尽管此需求与需求R1有相似之处，但值得注意的是，该需求中指出的安全机制有所不同：R1要求“确认操作”，而R5要求“至少两个步骤”。这是有意为之，因为确认操作可能由用户在无需深入思考的情况下自动完成，例如在超时后。而在R5中，要求执行两次用户操作；基于超时的安全机制在发生误按键时很容易被绕过。为了便于形式化，该需求可重新表述如下： “对于给定泵设置的任意值 x，如果数据输入就绪” (待输注体积_entry_就绪)，对于该泵设置（在本示例中为待输注体积），则无法通过单步操作将泵设置更新为x 。” 此性质需要针对所有可能的操作（state_transitions_xkey1）进行证明，但 按键1 除外，因为该按键确实会更新泵的设置：
  (vtbi_entry_ready(pre) 且 vtbi_value(pre) =x 且 newvtbi(pre) /=x 且 state_transitions_ xkey1(pre, post)) 蕴含 vtbi_value(post) =x
• 针对特定泵的解释 ：当示例泵开启并处于相关的数据输入模式时，该泵即可接受vtbi值。具体而言，顶行显示应为dispvtbi（即输入vtbi和速率时）或vtbitime（即输入vtbi和时间时）。
• 证明需求 ：PVS 能够在未受干预的情况下，使用归约方法针对待输注体积和时间证明该需求。然而，对于输注速率，该需求 无法满足。根据 PVS 提供的反例可知，只有假设临床医生在开始输注前始终锁定输注速率，该需求才能满足。尽管在开始输注时总会有提醒锁定速率，但该假设需要结合输液泵所使用的医院中采用的临床实践进行验证。

C. 来自属性模板的需求

生成以使用为中心的安全需求的第二种途径是采用基于可用性设计原则的一组属性模板。这些模板旨在帮助开发人员构建适用于用户界面特性分析的需求。它们可以实例化为设备的具体细节，并提供如何开发更易使用、更能透明显示操作效果的用户界面的指导。

将使用三个属性模板来说明该方法：“反馈”、“一致性”和“可逆性”。更多属性模板和详细示例见[39]。

D. 反馈模板

当执行某些重要操作时，用户需要了解所产生的设备状态是否适当或存在问题 [40]。反馈可以方便地分为操作反馈，要求任何操作都必须对用户可见其效果，以及 状态反馈，要求状态的变化（通常是状态的特定属性而非整个状态）对用户可见。接下来将基于此模板说明两个示例需求。

R6：每当输入泵变量时，应明确标识该变量，并使用户能够看到其当前值。

实例化操作反馈的通用形式（如 [39] 中所述）要求相关变量的数据输入已启用（即设备处于适当的数据输入模式），并且与模式相关的变量是可见的。该要求可以形式化如下：
输入_就绪(输入模式)(st) 蕴含 visible_variable(mode)(st)
* 证明需求 ：该需求可通过结构归纳法在 PVS中对所有可达状态自动证明（参见需求R2）。

R7：当前模式应被明确标识，且模式的变更应具有可感知的反馈。

该需求是状态反馈的一个示例。它要求在任何情况下，如果模式发生切换，则该模式必须可见。对于所考虑的泵，顶行是输入模式的指示器。因此，该表述可进一步细化如下：“当输入模式发生变化时，顶行也随之变化。” 以逻辑公式表达的需求为
入口模式（预） /=输入模式(转换后状态) 蕴含 顶行(转换前状态) /=顶行(转换后状态)
* 证明需求 ：该需求的证明说明了在完成交互式证明尝试时所需的人工干预类型。定理证明器未能证明该定理，并在设备处于袋模式时的失败点生成了第一个反例，该模式允许将标准袋容量分配给待输注体积。该反例表明 1）顶行显示“待输注量”，2）操作key1可用于退出该模式，以及3）执行操作key1后进入的新模式中，顶行同样显示“待输注量”，但在该模式下，V形键通过上下调节改变待输注体积的值，而不是通过导航输液袋菜单进行更改。证明器识别出这一反例的事实，促使分析人员与领域专家及人因专家共同考虑这种歧义是否可能成为一个问题。进一步的讨论可能会表明，两种模式下显示屏整体的格式存在显著差异，因而足以防止模式混淆。因此，可以通过在定理中引入以下保护条件来排除此情况：
入口模式（预） /=袋模式
当再次使用保护条件进行证明时，定理证明器又提出了另一个类似的情况，涉及另一种数据输入模式，其中顶行显示了两种不同模式下的“vtbi over time”。与之前的情况一样，由于这两个显示屏的整体格式有显著差异，该反例可被视为误报。因此，在定理中添加了额外的保护条件以排除这一新情况：
入口模式（预） /=TT模式
该定理的进一步细化足以完成对需求的证明。

E. 一致性模板

用户会迅速形成一种心理模型，体现其对如何与用户界面进行交互的预期。因此，用户界面的整体结构应在布局、屏幕结构、导航、术语和控制元素 [40] 方面保持一致。一致性模板被表述为一组操作的性质，或者是在不同模式下的同一操作，要求该组中的所有操作对特定状态属性产生类似的影响。例如，可基于此模板构建以下需求。

R8：输入数字时，给定的操作将始终确认输入的值。

该需求旨在验证同一按键是否可在不同的数据输入模式中用于确认用户输入。此需求的一般表述包含以下要素：谓词 guard_em_ok 限定了一组相关的输入模式，在这些模式中可使用特定的确认操作 confirm ；谓词 temp_em_filter 提取由于该模式而“临时”更改的状态属性；谓词 real_em_filter 提取因退出该模式而导致更改的状态属性。所有谓词均以设备数据输入模式 em 作为参数，因为这些谓词的精确定义在一般情况下取决于具体的数据输入模式。
保护条件_em_ok(em, st) 蕴含 temp_em_ filter(em, st)=real_em_filter(em, confirm(st))
对于示例泵，在数据输入期间，key1通常与功能 ok 相关联。因此，验证工作旨在确保在所有数据输入模式下，当 key1被启用并关联到功能显示屏 ok时，确认操作的行为保持一致。
* 证明需求 ：在PVS中尝试进行证明时，定理证明器发现了一个反例。在“时间内的待输注体积”数据输入模式下，确认键的使用不一致。这种特定的数据输入模式涉及设置vtbi和时间。该定理之所以失败，是因为当输入vtbi后，按下按键1并显示ok功能时，泵的vtbi值并未改变，而只有在下一步修改时间后才会更改。在证明定理过程中发现的这一失败情况，可能需要进一步审查，以证明系统的安全性未受影响。事实上，设备假设vtbi和输注速率是设置输注速率的标准机制。因此，当接收到包含vtbi和时间的处方时，可能会出现问题。

F. 可逆性模板

用户可能会执行错误的操作，设备需要为其提供相应的函数，使其能够通过撤销错误操作的影响来恢复。在 [41],中已表明，不遵守此需求可能导致数据输入错误。基于此模板的一个示例需求如下所示。

R9：任何数据输入操作都应该是可逆的。

为便于形式化过程，该需求可重新表述如下：“对于任何特定操作 a1，存在一个反向操作 a2 ，可使设备返回其原始状态。” 这一重新表述可轻松转换为以下通用公式：
数据_输入_就绪(st) 蕴含 泵_变量 (a2(a1(st))) = 泵_变量(st)
对于示例泵，该公式需要考虑所有V形键以及输注速率、时间和待输注体积的输入。为了清晰起见，此处仅以输入输注速率和单个向上V形键（sup）与反向单个向下V形键（sdown）的情况为例进行说明。示例泵的设计允许用户通过按住V形键来加快增量的调整幅度。这一功能在规范中有体现，但在此为便于说明而进行了简化。
click_sdown(st: 状态): 状态=release_ sdown(sdown(st)) click_sup(st: 状态): 状态 =release_sup(sup(st))
其他V形键和数据输入模式的表述是相同的。因此，该需求的通用版本实例化如下：
rate_entry_就绪(st) 蕴含 infusion_rate(click_ sdown(click_sup(st)))= infusion_rate(st)
* 证明需求 ：这个最终的证明示例进一步说明了如何建设性地利用定理证明器的反馈来完善对设备交互设计的理解。该定理的证明失败，定理证明器返回了反例，揭示了某些特定值下的异常情况。定理证明器识别出的一个反例出现在99.9：按下sup然后按sdown得到的结果是99（而不是99.9）。这是由于“步长边界”导致增量或减量的大小发生变化所致。在小于但不包括100的范围内，单个向上V形键和单个向下V形键的步长均为0.1；而从100开始向上（至1000为止），增量变为1。因此，为了证明sup操作可由sdown操作逆转，定理必须考虑这些步长边界。以下展示了为在0到100的范围内针对sup和sdown键证明该定理所需的附加条件。第一个条件确保分析是在保持相同增量步长（此处为0.1）的数值范围内进行的：
输注_速率(device(st)) >= 0 AND 输注_速率 (device(st)) + 0.1< 100
第二个条件是必要的，用于进一步限制在证明中考虑的值域为那些被处理的值该设备：小于100的数值只能有一位小数。
infusion_rate(st)=(向下取整(10 ∗infusion_ rate(st))/10) AND infusion_rate(st)=(向上取整_ rate(10 ∗infusion_rate(st))/10)
其中， floor 返回小于或等于指定数字的最大整数， ceil 返回大于或等于给定数字的最小整数。将所有步长边界的约束以及所有 V 形键的约束综合在一起后，针对需求 R9需要证明的性质变得复杂得多。对该需求及其各种限定条件进行证明，仅能有限地保证数字输入操作对用户而言是易于可逆的。显然，这一过程在理解数字输入系统的特性方面具有重要价值，并能够精确地识别出设计空间中该性质失效的位置。定理的提出与证明引发了关于设备数据输入系统是否可接受、或是否可能导致使用错误的实际问题。应注意的是，该设备后续发布的固件版本已修复了步长边界的相关问题。

八、讨论与结论

证明医疗器械设计符合相关的安全性和可用性需求是一个严峻的问题。本文所述的技术旨在解决这一问题。据估计，在2005年至2009年期间，美国共报告了约56,000 例与输液泵相关的不良事件报告，其中包括至少500例死亡[42]。根据美国食品药品监督管理局的数据，这导致了 87次输液泵召回，以应对已识别的安全问题。在这些不良事件报告中，使用错误是一个重要因素。制造商向监管机构提供的用于安全论证的文档通常非常庞大。论证的规模不可避免地使得监管机构难以全面理解，并难以确信所提供的证据质量令人满意。采用形式化技术具有优势。1) 它精确且简洁，可能避免了典型文档化所产生的文档爆炸问题。2) 像模型检测工具和定理证明工具这样的工具能够实现机械化的详尽验证。3) 仿真技术与形式化建模相结合的使用可以清楚地展示如何解决潜在问题，这对监管机构、人因工程以及领域专家具有价值。

这些技术的广泛应用面临着众所周知的障碍。它们通常不是典型开发人员工具套件的常规组成部分，也未在产品开发中常规使用。然而，已有迹象表明人们对这些技术产生了兴趣。例如，美国食品药品监督管理局已使用 Simulink开发了通用PCA模型[43]。然而，期望监管机构在事后才构建模型并不可行。一个理想的选择是制造商在设计过程中生成模型，以证明所提交的产品符合安全要求。随后，监管机构将使用工具来验证开发者提交材料中所提供的模型。

我们已使用模型检测结合仿真来支持通过生成可在设备上验证的轨迹进行模型验证的过程。然而，制造商能够访问源代码，即使他们未使用模型开发其设备，也可以系统地创建精确模型。另一个重要问题（本文未涉及）是如何验证所考虑的安全要求是否正确地解决了设备在其使用场景中的可用性和安全性。该问题与本文介绍的技术相互独立。可以采用人因工程的方法，结合危害分析（如[44]中所述）来解决安全方面的问题。

我们已经说明了需求形式化除了能够对其进行证明之外所带来的诸多益处。相比非正式的自然语言描述，需求形式化促使人们对需求的精确性质（无论是总体上还是针对特定设备）进行了更为深入细致的思考。模型检测与定理证明这种实用且非正式的结合方式为分析提供了强有力的工具。通过灵活地将每种方法应用于其适合的需求，而不是教条式地偏好某一种方法用于所有需求，或试图将二者合并为一个同时应用两种技术的单一工具，我们得以以相对较低的工作量完成需求的证明。该方法的一个潜在缺点是需要掌握这两种验证技术。事实上，目前这两种验证方法在分析时均需要较高的专业技能。然而，我们观察到不同制造商的设备形式化模型在结构上存在重复出现的模式，且在完成多种类型安全要求的验证时所需策略也具有相似性。因此，显然有机会开发出可重用的自动化证明策略，以降低分析工作量。