在启动和关闭期间操作医疗装置的制作方法

1.本发明涉及医疗装置领域，并且更具体地涉及用于在启动和关闭期间操作自动化医疗装置的技术。


背景技术：

2.自动化医疗装置是制造商打算出于医疗目的用于人或动物的机器，无论是单独使用还是组合使用。这样的目的可以包括对疾病、伤害或残障的诊断、预防、监测、治疗或缓解。
3.自动化医疗装置经常在医疗保健领域中使用，并受到严格的规章制度的约束，以确保其安全性和有效性。
4.通常，自动化医疗装置通过软件系统操作，该软件系统是需要仔细设计以减轻可能影响健康的故障风险的复杂系统。
5.可能需要将软件系统设计为由两个或更多个独立的子系统或模块组成。构造成套的独立的子系统使医疗装置的产品设计人员和制造商能够创建和部署执行特定功能的子系统，这些特定功能是完整医疗装置的功能的子集。通过在例如位于一个或多个集成电路或芯片上的不同处理器上执行的不同的子系统，这种软件的模块化也可以与硬件的模块化配对。
6.尽管通常在软件系统的设计上付出很多努力，以确保医疗装置在执行医疗目的时能够以受控、安全和可靠的方式运行，但通常忽略医疗装置的启动和关闭，并且通过假定用于各个过程的标称启动时间并使用对应的计时器来执行医疗装置的启动和关闭。这可能导致较长的启动时间，并且如果由于某种原因应延迟过程启动而超过标称启动时间，则容易出现故障。无论软件系统中内置的安全措施如何，在启动或关闭期间发生的故障仍可能对医疗装置执行的后续医疗程序造成严重影响。在模块化成两个或更多个子系统的软件系统中，启动和关闭可能特别容易发生故障。
7.通常需要提供一种用于医疗装置的软件系统，该软件系统确保医疗装置的确定性、安全和可靠的启动和关闭。
8.现有技术包括stanczyk等人的文章“logical architecture of medical telediagnostic robotic system(医学远程诊断机器人系统的逻辑体系结构)”，该文章出版在21st international conference on methods and models in automation and robotics(第21届自动化和机器人技术方法与模型国际会议，mmar)，第200
‑
205页(2016)。这篇文章提出了一种允许进行远程身体检查的多功能机器人系统。患者侧控制系统包括机器人中央控制系统(rccs)，其连接到较低级别的组件，例如分别用于机器人头部、机器人臂和移动机器人基座的低级别的控制装置。基于传感器信号、助手或医生的逻辑需求以及来自所有低级别的组件的状态信号，rccs决定是否可以操作低级别的组件。所有通信都经过rccs。开启电源后，rccs进入启动状态以开始启动程序。当所有较低级别的组件都被识别为活动时，rccs进入活动状态。相反，当按下电源关闭按钮时，rccs进入关闭状态以启动关闭
程序。当所有较低级别的组件完成关闭程序后，rccs进入关机状态。
9.尽管这种现有技术的控制系统使得能够在较高级别上安全且可靠地启动机器人系统的硬件组件，但是它不能确保控制系统的所有过程的确定性启动。
10.现有技术还包括us2014/0121509，其公开了多模态医疗处理系统中的基于依存关系的启动方法。系统控制器被布置为协调多个可执行组件的启动和关闭，这些可执行组件是用于与耦接到处理系统的相应的医疗装置通信的特定于模态的组件。对于每个可执行组件，系统控制器获取依存关系信息，该依存关系信息包括可执行组件所依赖的其他可执行组件的列表。系统控制器基于依存关系信息动态地导出多个可执行组件的启动顺序，并根据该启动顺序来启动可执行组件。在以启动顺序启动下一个组件之前，系统控制器要等待直到相应的组件公开了其所有接口并有选择地广播了过程准备就绪消息为止。
11.该启动方法仅考虑可执行组件的级别的启动。因此，它不能确保系统中的所有过程的确定性启动，例如，由一个或多个可执行组件中的软件应用执行的过程的确定性启动。此外，所提出的启动方法很复杂，因为它需要交换依存关系信息并需要由系统控制器集中确定启动顺序。


技术实现要素：

12.本发明的目的是至少部分地克服现有技术的一个或多个限制。
13.另一个目的是使得能够确定性启动用于操作医疗装置的软件系统的所有相关过程。
14.另一个目的是使得能够确定性关闭用于操作医疗装置的软件系统的所有相关过程。
15.这些目的中的一个或多个以及可能从以下描述中显现的其他目的至少部分地通过操作医疗装置的方法、医疗装置和计算机可读介质来实现，操作医疗装置的方法、医疗装置和计算机可读介质的实施例由从属权利要求限定。
16.本发明的第一方面是一种操作医疗装置的方法。该医疗装置被配置为执行医疗程序，并且包括处理器集合和存储用于由处理器集合执行的软件系统的存储器单元集合。该软件系统限定多个子系统，包括主子系统和辅子系统集合。每个子系统包括在医疗程序期间医疗装置的操作中涉及的软件应用。该方法包括，在医疗装置的启动期间：启始(initiate)每个软件应用；在准备好启动时，由相应的辅子系统中的每个软件应用提供应用准备就绪通知；当相应的辅子系统的所有软件应用都已经提供了应用准备就绪通知时，由相应的辅子系统提供子系统准备就绪通知；以及在接收到子系统准备就绪通知时由主子系统协调辅子系统集合的启动。
17.本发明的第二方面是一种用于执行医疗程序的医疗装置。该医疗装置包括处理器集合和存储用于由处理器集合执行的软件系统的存储器单元集合。该软件系统在由处理器集合执行时，操作医疗装置以执行医疗程序。该软件系统限定多个子系统，其包括主子系统和辅子系统集合。每个子系统包括在医疗程序期间医疗装置的操作中涉及的软件应用。该软件系统在由处理器集合执行时，执行根据第一方面或其任何实施例的方法。
18.第三方面是一种计算机可读介质，其包括用于操作医疗装置以执行医疗程序的软件系统。该软件系统限定多个子系统，其包括主子系统和辅子系统集合。每个子系统包括在
医疗程序期间医疗装置的操作中涉及的软件应用。该软件系统在由医疗装置的处理器集合执行时，执行根据第一方面或其任何实施例的方法。
19.这些方面使得能够确定性地启动医疗装置中软件系统的所有相关软件应用。确定性启动是通过将启动程序分为通过使用应用准备就绪通知和子系统准备就绪通知的子系统级别的启动的准备和系统级别的启动的准备来实现的，在系统级别的启动准备中，主子系统协调各个子系统的启动。此外，前述方面使得能够将确保软件应用准备好启动的责任委托给相应的子系统。因此，启动程序可以与软件系统相对应地被模块化，使得每个子系统可操作为独立于其他子系统为启动做准备。这样的模块化是有利的，因为它允许在子系统上分别执行启动程序，可以在开发和部署期间单独测试子系统的启动。
20.此外，使用通知使医疗装置能够安全且可靠地启动。例如，当发生阻止提供通知的故障时，可以防止启动软件系统。使用通知还使得能够在医疗装置的启动期间简单且有效地检测和定位软件系统中的故障。此外，与如上所述的使用计时器和标称启动时间相比，使用通知还可以缩短启动医疗装置所需的时间。
21.对应的模块化可以通过使用通知在关闭程序中实现，从而以确定性、安全且可靠的方式使医疗装置中的所有相关的执行的软件应用准备好失去电力(power loss)。
22.在下面限定第一方面的一些实施例，并且这些实施例可以用于启用、实现或改善用于操作医疗装置的软件系统的所有相关过程的确定性启动和/或关闭的目的，或本领域技术人员所理解的其他目的。
23.在一个实施例中，该方法还包括，在相应的子系统中：在获得子系统准备就绪通知时，由相应的辅子系统的软件应用启用相应的辅子系统的软件应用之间的通信。
24.在一个实施例中，协调包括：由主子系统生成系统准备就绪通知，以供辅子系统集合接收。
25.在一个实施例中，协调还包括：在获得系统准备就绪通知时，由相应的辅子系统启用多个子系统中不同子系统的至少一个子集的软件应用之间的通信，从而医疗装置准备好执行至少部分的医疗程序。
26.在一个实施例中，该方法还包括：当准备好启动时，由主子系统中的相应的软件应用提供应用准备就绪通知，其中，协调由主子系统在从相应的辅子系统接收到子系统准备就绪通知以及从主子系统中的相应的软件应用接收到应用准备就绪通知时执行。
27.在一个实施例中，主子系统中的管理器从相应的辅子系统接收子系统准备就绪通知，并从主子系统中的相应的软件应用接收应用准备就绪通知，并执行协调。
28.在一个实施例中，相应的辅子系统还包括管理器，其中，相应的辅子系统的管理器在从相应的辅子系统的所有软件应用获得应用准备就绪通知时提供子系统准备就绪通知。
29.在一个实施例中，协调包括：在从主子系统的每个软件应用获得应用准备就绪通知以及从相应的辅子系统获得子系统准备就绪通知时，由主子系统的管理器为相应的辅子系统提供系统准备就绪通知。
30.在一个实施例中，该方法还包括：在获得系统准备就绪通知时由相应的辅子系统的管理器并且由主子系统的管理器启用多个子系统中不同子系统的软件应用的至少一个子集之间的通信，从而医疗装置准备好执行至少部分的医疗程序。
31.在一个实施例中，软件系统限定至少两个辅子系统，并且启用不同子系统的软件
应用的至少一个子集之间的通信包括：启用至少两个辅子系统中的软件应用的至少一个子集之间的直接通信。
32.在一个实施例中，子系统在处理器集合中的不同处理器上执行。
33.在一个实施例中，两个或更多个子系统对于由医疗装置执行的医疗程序至关重要，并且包括相应的管理器，并且该方法还包括，在所述启动期间：操作所述两个或更多个子系统的每个管理器以发送外部心跳信号；以及开始在所述两个或更多个子系统的管理器之间相互监测外部心跳信号以检测操作故障。
34.在一个实施例中，该方法还包括，在所述启动期间：当在第一预定时间段内未从主子系统的相应的软件应用接收到应用准备就绪通知时，由主子系统中的管理器报告第一错误；以及当在第二预定时间段内未从相应的辅子系统接收到子系统准备就绪通知时，由主子系统中的管理器报告第二错误。
35.在一个实施例中，该方法包括，在医疗装置的关闭期间：由主子系统的管理器为辅子系统集合提供关闭通知；由主子系统的管理器请求终止主子系统的软件应用；以及在获得关闭通知后，由相应的辅子系统的管理器请求终止相应的辅子系统的软件应用。
36.在一个实施例中，请求终止相应的辅子系统的软件应用包括，对于至少一个辅子系统：由管理器为辅子系统的软件应用提供子系统未准备就绪通知；在获得子系统未准备就绪通知时，由辅子系统的软件应用的至少一个子集为终止做准备；在准备好终止时，由所述软件应用的至少一个子集提供应用关闭准备就绪通知；以及在从所述软件应用的至少一个子集获得应用关闭准备就绪通知时，由辅子系统的管理器为主子系统的管理器提供子系统关闭准备就绪通知。
37.在一个实施例中，请求终止主子系统的软件应用包括：由主子系统的管理器为主子系统的软件应用提供子系统未准备就绪通知；在获得子系统未准备就绪通知时，由主子系统的软件应用的至少一个子集为终止做准备；以及在准备好终止时，由主子系统的软件应用的所述至少一个子集提供应用关闭准备就绪通知。
38.在一个实施例中，该方法还包括：在从所述至少一个辅子系统获得子系统关闭准备就绪通知并且从主子系统的软件应用的所述至少一个子集获得应用关闭准备就绪通知时，由主子系统的管理器启始医疗装置的电力失去。
39.在一个实施例中，该方法包括：在所述关闭期间没有错误的情况下，由至少一个管理器设置用于指示正常关闭的关闭原因参数，并将关闭原因参数存储在存储器单元集合中；以及在所述启动期间，由所述至少一个管理器设置用于指示关闭错误的关闭原因参数，并将关闭原因参数存储在存储器单元集合中。
40.在一个实施例中，该方法包括：在所述关闭期间没有错误的情况下，由至少一个管理器设置用于指示正常关闭的关闭原因参数，并将所述关闭原因参数存储在所述存储器单元集合中；以及在所述启动期间，由所述至少一个管理器设置用于指示关闭错误的关闭原因参数，并将所述关闭原因参数存储在所述存储器单元集合中。
41.在一个实施例中，软件应用包括一个或多个关键软件应用，其对于由医疗装置执行的医疗程序至关重要，并且该方法还包括，在医疗装置的关闭期间并且在为辅子系统集合提供关闭通知之前：由主子系统的管理器为所述一个或多个关键软件应用提供关闭请求；由一个或多个关键软件应用基于医疗装置的操作验证关闭请求；以及如果关闭是可接
受的，则由一个或多个关键软件应用中的至少一个提供应用关闭准备就绪通知；其中，主子系统的管理器在从一个或多个关键软件应用中的所述至少一个获得应用关闭准备就绪通知时，为辅子系统集合提供关闭通知。
42.在一个实施例中，多个子系统包括具有用于控制医疗装置执行医疗程序的软件应用的第一子系统，以及具有用于与医疗装置的致动器和/或传感器进行通信的软件应用的第二子系统，协调启用用于控制医疗装置的软件应用和用于通信的软件应用之间的通信。
43.在一个实施例中，多个子系统还包括具有用于监督医疗程序以检测偏差的软件应用的第三子系统，以及具有用于与医疗装置的辅助传感器进行通信的软件应用的第四子系统，并且协调还启用用于监督医疗程序的软件应用和用于与辅助传感器进行通信的软件应用之间的通信，以及用于控制医疗装置的软件应用和用于监督医疗程序的软件应用之间的通信。
44.本发明的另一方面是一种操作医疗装置的方法。该医疗装置被配置为执行医疗程序，并且包括处理器集合和存储用于由处理器集合执行的软件系统的存储器单元集合。该软件系统限定多个子系统，其包括主子系统和辅子系统集合。每个子系统包括在医疗程序期间医疗装置的操作中涉及的软件应用。该方法包括，在医疗装置的启动期间：启始每个软件应用；在准备好启动时，由每个软件应用提供应用准备就绪通知；当相应的辅子系统的所有软件应用都已经提供了应用准备就绪通知时，由相应的辅子系统提供子系统准备就绪通知；以及在接收到子系统准备就绪通知时由主子系统协调子系统的启动。该方法可以被部署在与第二方面相对应的医疗装置上，并且可以在与第三方面相对应的计算机可读介质上实现。前述实施例同样适用于其他方面的方法。
45.本发明的其他目的和方面以及实施例、特征、技术效果和优点可以从以下详细描述、所附权利要求书以及附图中显现。
附图说明
46.现在将参考附图更详细地描述本发明的实施例。
47.图1a
‑
1c示出了可以实现本发明的实施例的医疗装置的示例。
48.图2是连接到信号通信结构的医疗装置的硬件组件的示意性框图。
49.图3是用于操作医疗装置的软件系统的示意性框图。
50.图4a
‑
4b是根据本发明实施例的用于启动医疗装置而执行的方法的流程图。
51.图5a
‑
5d是根据本发明实施例的用于关闭医疗装置而执行的方法的流程图。
52.图6示出了根据本发明实施例的图3中的软件系统在被操作时的状态。
53.图7a
‑
7e是根据本发明实施例的图3中的软件程序用于启动医疗装置的操作的序列图。
54.图8a
‑
8c是根据本发明实施例的图3中的软件程序用于关闭医疗装置的操作的序列图。
具体实施方式
55.现在将在下文中参考附图更全面地描述本发明的实施例，在附图中示出了本发明的一些但不是全部实施例。实际上，本发明的方案可以以许多不同的形式来体现，并且不应
被解释为限于本文阐述的实施例；相反，提供这些实施例是为了使本公开可以满足适用的法律要求。相同的数字在全文中表示相同的元件。
56.而且，将理解，在可能的情况下，本文描述和/或构思的本发明的任何实施例的任何优点、特征、功能、设备和/或操作方面可以包括在本文描述和/或构思的本发明的任何其他实施例中，和/或反之亦然。另外，除非另有明确说明，否则在可能的情况下，本文中以单数形式表达的任何术语也意在包括复数形式，和/或反之亦然。如本文所使用的，“至少一个”应表示“一个或多个”，并且这些短语旨在是可互换的。因此，术语“一”和/或“一个”应表示“至少一个”或“一个或多个”，尽管本文也使用了短语“一个或多个”或“至少一个”。如本文中所使用的，除非上下文因表达语言或必要的暗示而另有要求，否则词语“包括”或诸如“包含”或“含有”等变型以包括性含义使用，即，指定存在所述的特征，但不排除在本发明的各种实施例中其他特征的存在或增加。如本文所使用的，项目的“集合(set)”旨在暗示提供一个或多个项目。
57.还将理解的是，尽管本文可能使用术语第一、第二等来描述各种元素，但是这些元素不应受到这些术语的限制。这些术语仅用于将一个元素与另一个元素区分开。例如，在不脱离本发明的范围的情况下，第一元素可以被称为第二元素，类似地，第二元素可以被称为第一元素。如本文所使用的，术语“和/或”包括一个或多个相关列出的项目的任意和所有组合。
58.为了简洁和/或清楚起见，可能没有详细描述公知的功能或构造。除非另有限定，否则本文中使用的所有术语(包括技术术语和科学术语)具有与本发明所属领域的普通技术人员通常所理解的相同含义。
59.本发明的实施例针对使得能够确定性启动和/或关闭用于操作医疗装置的医疗软件系统的所有相关过程的技术。该医疗装置是自动化设备或机器，其被配置为操作、可选地与一个或多个其他医疗装置组合操作以执行关于人或动物对象的医疗程序。如本文中所使用的，医疗程序可以涉及疾病、损伤或残障的诊断、预防、监测、治疗或减轻或者监测以对这些进行检测中的一种或多种。在下文中，假定医疗软件系统包括两个或更多个子系统，这些子系统在一个或多个处理器上执行以控制医疗装置执行医疗程序。子系统可以被看作是计算机可执行指令的软件模块，其可以被独立地开发和测试以在执行医疗程序时提供与医疗装置的操作相关的特定功能。相应的子系统包括软件应用的集合，其中，每个软件应用对应于在相应的子系统的上下文内执行的过程或任务。因此，子系统内的软件应用可以被设计为执行成组的协调的过程以提供子系统的特定功能。然而，可以想到的是，子系统包括医疗装置的操作中不涉及的一个或多个软件应用。此外，子系统可以包括其他软件组件，例如在软件系统中执行基本功能或服务的中间件和/或低级别的软件组件，例如用于管理与其他子系统的通信的通信堆栈、用于管理技术性错误的错误管理器、用于管理通知的通知管理器等。一个或多个子系统可以在一个或多个操作系统之上运行，以利用由操作系统提供的有关硬件和软件资源的服务。取决于实现方式，操作系统可以例如包括实时操作系统、嵌入式操作系统、单任务操作系统或多任务操作系统或其任意组合。还可以想到的是，一个或多个子系统被配置为在没有操作系统的情况下运行，并且直接与医疗装置的硬件资源接口。
60.图1a
‑
1c是直接或间接地与对象流体连通地连接的示例医疗装置的示意图。应当注意，所示出的示例是高度示意性的，仅出于示出本发明的实施例的不同实现背景的目的
而给出。
61.图1a示出了医疗装置10，该医疗装置10可操作以受控方式将医疗液输送到对象100的体内，例如，输送到对象100的循环系统中，如箭头所示。医疗液可以是任何合适的液体，包括但不限于药物和/或营养物。这种类型的医疗装置10通常被称为“输液泵”。在所示的简化示例中，医疗装置10包括用于连接到对象100的流体管线11、显示器12、控制按钮13(示出了一个)、指示灯14、扬声器15、控制系统16、用于经由流体管线11将医疗液受控地输送到对象100的一个或多个致动器17、以及用于提供指示由输液泵执行的输液过程的传感器数据的一个或多个传感器18。致动器17和传感器18可包括医疗装置10的内部组件(如虚线所示)或外部组件，或内部组件和外部组件两者。控制系统16被配置为协调致动器17和传感器18的操作以执行输液泵的预期医疗程序，以及结合医疗程序在必要时操作显示器12、指示灯14和扬声器15，并经由控制按钮13获得用户输入。例如，显示器12可以被操作为向医疗装置10的用户呈现指令，指示灯14可以被操作为指示装置状态，扬声器15可以被操作为生成警报信号等。
62.图1b示出了医疗装置10，该医疗装置10可操作以受控方式将透析液输送到对象100的腹腔，并随后从其去除透析液，如双头箭头所示。该医疗程序通常被称为自动腹膜透析，并且医疗装置10通常被称为“pd循环仪”。在图示的详细程度上，图1b中的医疗装置10可以具有与图1a中的医疗装置10类似的组件集合，因此将不再进一步描述。
63.图1c示出了两个医疗装置10、10'，它们可以在执行例如作为肾脏替代疗法(例如，血液透析、血液透析滤过、血液滤过或超滤)的部分的体外血液处理的医疗程序中涉及到。标记为10的医疗装置是血液处理设备，其包括用于例如在血管入口处连接到对象100的循环系统的血液抽取管线11a和血液返回管线11b。如箭头所指示，医疗装置10可操作为以受控方式从对象100抽取血液，处理血液并且将经处理的血液返回至对象100。标记为10'的医疗装置可操作为准备供血液处理设备10使用的流体，并且包括用于将流体供应至血液处理设备10的流体管线11。在一个示例中，医疗装置10'为水制备设备，并且流体是纯净水。例如，如本领域中已知的，水处理设备10'可以通过反渗透来过滤进入的水。在图示的详细程度上，图1c中的医疗装置10、10'中的每一个可具有与图1a中的医疗装置10相似的组件集合，因此将不进一步描述。
64.图2示出了可以在(例如，如图1a
‑
1c所示的)医疗装置的操作期间处于活动的硬件组件以及这些硬件组件的互连的示例。在所示的示例中，硬件组件被连接以通过信号通信结构20进行信号交换，该信号通信结构20可以包括任何形式的总线结构或交换光纤结构和/或单独的布线。还可以想到的是，一个或多个组件位于的公共基板上，例如位于集成电路(ic)等中，并且通过公共基板上的信号导电轨迹互连，该公共基板又通过信号通信结构20连接到其他组件。在图2的示例中，除了显示器12、控制按钮13、指示灯14、扬声器15、致动器17和传感器18之外，医疗装置还包括四个单独的处理器p1
‑
p4、两个单独的存储器单元m1
‑
m2。处理器p1
‑
p4和存储器单元m1
‑
m2是“单独的”的含义是它们是可单独操作的单元，而它们可以以任何组合的形式或者可以不以任何组合的形式位于公共基板上，例如位于ic中。相应的处理器p1
‑
p4可以是任何可商购的处理装置，例如cpu、dsp、微处理器、fpga、asic或任何其他电子可编程逻辑器件，或其组合。相应的存储器单元m1
‑
m2可以包括非易失性存储器或易失性存储器或其组合，包括但不限于rom、prom、eeprom、闪存、可移动存储器、ram、
dram、sram、高速缓冲存储器、硬盘驱动器、存储介质等。
65.在图2的示例中，上述软件系统可以存储在存储器单元m1
‑
m2的一个或多个上，以由处理器p1
‑
p4中的一个或多个执行。由此，图1a
‑
1c中的控制系统16可以由软件系统在由处理器p1
‑
p4的一个或多个执行时实现。
66.可以在任何合适的计算机可读介质(crm)上提供软件系统以用于安装在医疗装置上。crm可以包括非暂时性存储或存储器介质，无论是易失性还是非易失性的，例如电子、磁性或光学介质。可替代地或附加地，crm可以包括诸如电、电磁或数字的传播信号之类的暂时性介质，该传播信号可以经由诸如网络和/或无线链路之类的通信介质来传送。
67.图2中的硬件组件仅作为示例给出。医疗装置10、10'可以包括任意数量的每种类型的组件，并且可以根据医疗装置的期望功能省略或替换图2中的一些组件。例如，如果显示器12是触敏的，则控制按钮13可以由显示器12上的虚拟按钮代替。还应当意识到，图2中的示例不是穷举性的，医疗装置可以包括在其操作过程中处于活动的其他类型的组件，例如键盘、计算机鼠标、电源等。
68.通常，医疗装置10、10'包括至少一个处理器、至少一个存储器单元以及致动器和传感器中的至少一个。图1a
‑
1c中的医疗装置10、10'通常包括至少一个致动器17，并且还可以包括至少一个传感器18。被设计用于监测的医疗装置可以原则上包括至少一个传感器18，但是不需要包括致动器17。在图1a
‑
1c的示例中，致动器17可包括流体泵、阀、加热器、清洁系统等中的一个或多个，并且传感器18可以被配置为生成表示温度、电导率、浓度、压力、流速等中的一个或多个的传感器数据。
69.图3是根据非限制性示例用于在医疗装置(例如，前述医疗装置中的任何一个)中执行的软件系统的框图。如图所示，软件系统包括四个子系统ss1
‑
ss4。在下文中，假设子系统ss1
‑
ss4在一个或多个单独的处理器上执行。在图2的示例中，子系统ss1
‑
ss4可以在相应的处理器p1
‑
p4上执行。换句话说，在一些实施例中，子系统ss1可以在处理器p1上执行，子系统ss2可以在处理器p2上执行，子系统ss3可以在处理器p3上执行，和/或子系统ss4可以在处理器p4上执行。每个子系统ss1
‑
ss4包括软件应用的集合，这些软件应用在医疗装置执行医疗程序时在医疗装置的操作中涉及到。子系统ss1、ss2、ss3、ss4中的软件应用集合分别由sw1、sw2、sw3、sw4共同指定。子系统ss1、ss2、ss3、ss4中的单个软件应用分别由软件应用sw1x、sw2x、sw3x、sw4x指定。此外，每个子系统ss1
‑
ss4包括表示为isc1
‑
isc4的相应的通信模块，其包括上述通信堆栈，并负责管理与一个或多个其他子系统的通信。在所示示例中，isc1
‑
isc4被配置为在子系统ss1和ss3之间、子系统ss1和ss2之间以及子系统ss3和ss4之间建立通信。根据实施例，每个子系统ss1
‑
ss4还包括由shm1
‑
shm4表示的管理器模块，并在下文中称为“管理器”。相应的管理器shm1
‑
shm4负责在启动和关闭期间管理其子系统ss1
‑
ss4的操作。相应的管理器shm1
‑
shm4可以访问要管理的软件应用的列表。管理器shm1
‑
shm4还可以负责在操作期间监测软件系统的健康，例如通过相应的管理器shm1
‑
shm4监测其软件应用sw1
‑
sw4如所期望地运行。管理器shm1
‑
shm4中的一个或多个也可以包含引导代码(boot code)，该引导代码在启动时执行，以使系统准备好在处理器p1
‑
p4中的一个或多个上加载和运行操作系统。
70.在图3的示例中，子系统ss1包括由sw1c指定的软件应用，子系统ss3包括由sw3c指定的软件应用。软件应用sw1c和sw3c与其他软件应用不同，它们对于医疗装置执行医疗程
序时的操作是关键的。在此上下文中，“关键”表示例如考虑到减轻对象100的健康风险，相应的软件应用sw1c、sw3c的正确操作对于根据要求规范执行医疗程序而言是必需的，该要求规范可以由制造商和/或由监管机构设置。包括至少一个关键软件应用的子系统在本文中也被称为“关键子系统”。在一个示例中，关键软件应用可以被配置为控制由医疗装置执行的医疗程序，例如，通过生成用于操作一个或多个致动器17以及可选地操作一个或多个传感器18的控制命令或信号的有序序列。在另一示例中，关键软件应用可以被配置为监督由医疗装置执行的医疗程序的操作，例如，通过生成用于操作一个或多个传感器18的控制命令或信号的有序序列。
71.在一个特定示例中，sw1c被配置为控制医疗程序，sw3c被配置为监督医疗程序的操作。许多执行医疗程序(该医疗程序在控制医疗程序的主系统或这样的主系统使用的任何硬件组件中发生操作故障的情况下对对象造成健康风险)的医疗装置被要求包括保护系统，该保护系统与主系统并行运行且独立于主系统。每当保护系统检测到潜在的操作故障时，医疗装置就被切换到安全操作状态。因此，回到图3，子系统ss1可以对应于主系统，而子系统ss3可以对应于保护系统。子系统ss2和ss4可以被配置为分别基于子系统ss1和子系统ss3生成的命令/信号与不同的致动器和/或传感器的集合通信。为此，子系统ss2、ss4中的每一个可以包括用于提供对连接到相应的子系统ss2、ss4的外围装置(例如，致动器和/或传感器)的访问的软件应用。为了实现主系统和保护系统之间的独立性，ss2可以连接到主传感器的集合，ss4可以连接到辅助传感器的单独的集合。子系统ss1
‑
ss4也可以在分别的处理器(例如，图2中的p1
‑
p4)上实现以实现独立性。在变型中，子系统ss2和/或子系统ss4可以分别包括在子系统ss1和子系统ss3内。
72.因此，在一种实现方式中，软件系统可以至少包括主系统(子系统ss1)和保护系统(子系统ss3)，保护系统可以是监测和故障安全组件，完全冗余于子系统ss1以帮助一直确保患者的安全。子系统ss3可以被设计为使得对患者造成危害的子系统ss1的任何单点故障可以由子系统ss3检测到并且被避免。在正常状况下，子系统ss1将读取hw和/或sw组件的当前状态，根据所选的操作模式确定下一个状态，并根据需要将新状态写入hw和/或sw组件。由于这三个操作阶段中的每一个固有的错误风险，子系统ss3被实现为在发生故障的情况下通过停止系统并通知操作者故障状况来保护患者。可能的故障可以包括数据丢失或错误表示、软件计算错误或故障、或者例如换能器、开关或处理器的硬件故障。子系统ss3通过监测系统中发送的命令和状态信息来防范此类风险。子系统ss3也可以连接到一个或多个专用传感器以提供冗余的测量。应当注意，子系统之间的链接不必是单个连接，而是可以包括一系列链接，例如集成电路、数字逻辑、i/o总线和软件中的一个或多个。
73.下面是子系统ss3中可以包括的软件应用的示例。应该理解的是，这仅仅是为了增加理解并提供附加的背景而给出的示例。因此，子系统ss3可以包含更多、更少或其他软件应用。还应该清楚的是，下面的示例结构或其部分也可以在系统的其他子系统(例如，子系统ss1)中实现。在一个特定示例中，子系统ss3包括i/o应用(“i/o”)，该i/o应用程序负责实现除了串行通信之外的低级别的sw到hw。因此，i/o向客户端提供i/o数据，并且还可以执行i/o数据的crc。警报处理应用负责管理警报，并在警报激活时通过i/o请求重置。在医疗装置的运行期间，警报处理应用与模式管理应用(如下)和i/o进行交互。配置处理应用负责向子系统ss3中的客户端提供治疗设置。在医疗装置的运行期间，配置处理应用经由系统间处
理(如下)与子系统ss1进行交互。数据记录器应用负责从子系统ss3内的其他软件应用接收基于文本的日志数据，并将日志数据提供给客户端。在医疗装置的运行期间，数据记录器应用程序还与时间处理应用(如下)进行交互。模式管理应用负责向客户端提供当前系统状态和治疗状态。经由系统间处理(如下)和i/o从子系统ss1接收状态。时间处理应用向客户端提供当前系统时间。装置监督应用负责使用从i/o取得的值来监测正在进行的治疗。如果子系统ss1没有及时采取预防措施，则装置监督应用负责将警报报告给警报处理应用。在医疗装置的运行期间，装置监督应用还与配置处理应用、模式管理应用、时间处理应用以及软件健康监测软件模块(如下)进行交互。装置监督应用可以监测子系统ss1中的状态和状态改变。在医疗装置(例如，参考图1a
‑
1c举例说明的医疗装置)的背景下，装置监督应用还可以监测一个或多个血液泄漏检测器、一个或多个体重秤、一个或多个夹具、一个或多个气泡检测器、一个或多个泵(注射泵、血液泵、透析液泵、污物泵、更换泵等)、一个或多个夹管阀、一个或多个控制面板、一个或多个液体泄漏检测器、一个或多个压力传感器等的操作(值、命令、状态、定时等)。子系统ss3还包括对应于图3中的shm3的软件健康监测软件模块，其负责监测子系统ss3中软件的健康，从而监测子系统ss1处于活动并正在运行。示例包括检查软件的完整性，检查ram，监测子系统ss3中的所有软件应用正在按预期运行，监测子系统ss1以验证其已启动并正在运行，以及开启(kick)硬件(hw)看门狗。子系统ss3还包括与图3中的isc3相对应的系统间通信软件模块，其负责管理与包括子系统ss1的其他子系统的串行通信。系统间通信可以细分为用于高级别通信的系统间处理和用于低级别通信的系统间传送。在一个实现示例中，警报处理、配置处理、数据记录器、模式管理和时间处理是在客户端的上下文中执行的线程安全库，并且软件健康监测作为任务执行，并且受事件驱动以作用于传入事件。软件健康监测任务还具有预定时间周期(例如，50毫秒)的周期性事件，以处理超时。软件健康监测任务具有最高优先级，以避免其他任务阻挡任务监督。装置监督作为任务执行，并具有例如50ms的执行周期和高优先级以按所要求的定时执行。i/o作为任务执行，并受事件驱动以服务i/o事件，并具有例如5ms的执行周期，以进行独立的信号读取和总线缓冲区清空。i/o任务具有中等优先级，以便能够在短时间内为事件提供服务，同时避免阻挡装置监督任务。系统间通信作为任务执行，并且受事件驱动，因为系统间通信的职责是处理传入和传出的通信事件。系统间通信任务还具有例如100ms的执行周期，以监督系统状态消息。系统间通信任务具有低优先级，因为该任务的实时性要求最低。任务之间的通信是无阻塞的；较高优先级的任务可以通过与较低优先级的任务进行通信而不被阻挡。
74.图4a是用于启动包括图3中的软件系统的医疗装置的方法400的实施例的流程图。方法400假定子系统之一是“主子系统”，其协调子系统的启动，而其余子系统被称为“辅子系统”。该方法通常适用于包括一个主子系统和至少一个辅子系统的任何软件系统。在以下示例中，ss1是主子系统，ss2
‑
ss4是辅子系统。在以下示例中，还假定管理器shm1
‑
shm4是用于系统启动的控制器，如下所述。
75.方法400包括启始所有子系统ss1
‑
ss4中的各个软件应用sw1x
‑
sw4x的步骤401。步骤401可以在常规引导程序(boot procedure)之后或作为其一部分来执行，该常规引导程序启始软件系统内的系统功能和系统通信，包括启动子系统ss1
‑
ss4的管理器shm1
‑
shm4和通信模块isc1
‑
isc4。步骤401可以在医疗装置加电时自动执行。在步骤401的一个实施例中，相应的子系统中的软件应用sw1
‑
sw4在接收到启动命令/信号时启始，该启动命令/信号
可以由相应的子系统ss1
‑
ss4的管理器shm1
‑
shm4或在软件系统中的其他地方生成。在步骤401中的初始化期间，相应的软件应用sw1
‑
sw4可以完成相应的预定的启始动作序列，例如从存储器(参见图2中的存储器单元m1、m2)进行读取、初始化(initiate)一个或多个参数、启动通信接口等。可以注意到，本公开假定图3所示的所有软件应用sw1
‑
sw4将由启动方法400来启动。然而，可以想到子系统ss1
‑
ss4中的一个或多个包括一个或多个软件应用，这些软件应用在用于执行医疗程序的医疗装置的操作中涉及到，但在另一时间启动，即与启动方法400分开启动。
76.在步骤402中，当已经根据步骤401启始了相应的软件应用sw1x
‑
sw4x时，软件应用在其相应的子系统ss1
‑
ss4内提供指示软件应用已准备好启动的“应用准备就绪”通知。在这种背景下，软件应用在准备好执行其指定的任务或过程并与其他软件应用交互时为“准备好启动”。在一个实施例中，每当软件应用操作为准备好从其他软件应用接收传入的通信信号的程度，软件应用就提供“应用准备就绪”通知。在一些实施例中，软件应用还准备好例如通过请求
‑
响应消息交换模式将通信信号发送到其他软件应用。因此，软件应用在提供“应用准备就绪”通知时，不必完全可操作。
77.每个子系统ss1
‑
ss4分别执行步骤403。当相应的子系统ss1
‑
ss4的管理器shm1
‑
shm4已经从相应的子系统ss1
‑
ss4中的所有软件应用sw1
‑
sw4获得“应用准备就绪”通知时，管理器shm1
‑
shm4提供在软件系统内的“子系统准备就绪”通知，既在相应的子系统ss1
‑
ss4内内部地提供，又在外部提供以由主子系统ss1接收(在下面的步骤405中)。
78.步骤404也由每个子系统ss1
‑
ss4分别执行。当子系统ss1
‑
ss4中的每个软件应用sw1
‑
sw4已获得由子系统ss1
‑
ss4的管理器shm1
‑
shm4提供的“子系统准备就绪”通知时，软件应用sw1
‑
sw4启用它们之间(即，在相应的子系统ss1
‑
ss4内)的通信。因此，步骤404允许在相应的子系统ss1
‑
ss4内进行应用级别的“内部通信”。当步骤404完成时，子系统中的所有软件应用已经启动，从而子系统准备好与软件系统中的其他子系统进行交互。
79.步骤405仅由主子系统ss1执行。当管理器shm1已获得所有辅子系统的“子系统准备就绪”通知时，管理器shm1协调子系统ss1
‑
ss4的启动。
80.方法400通过将启动分为子系统级别和系统级别，并在继续启动之前，首先确保所有软件应用准备好子系统级别的启动，然后确保所有子系统准备好系统级别的启动，使得能够实现医疗装置的软件系统的确定性启动。在图6中进一步示出了该原理，该图6示出了软件系统在启动和关闭期间在子系统级别(顶部)和系统级别(底部)的状态。重要的是要注意，图6并不意味着软件系统必须实现为状态机，而仅是为了解释软件系统的启动和关闭期间的总体控制机制。当医疗装置开启并通电时(图6中的转变ia和ib)，软件系统处于状态“系统未准备就绪”，并且每个子系统ss1
‑
ss4均处于状态“子系统未准备就绪”。作为步骤401
‑
404的结果，对应于图6中的转变ii，相应的子系统ss1
‑
ss4进入状态“子系统准备就绪”(在从其软件应用接收到“应用准备就绪”通知之后)。在系统级别，软件系统仍处于“系统未准备就绪”状态。作为步骤405的结果，对应于图6中的转变iii，软件系统进入状态“系统准备就绪”(在从辅子系统接收到“子系统准备就绪”通知之后)，因此软件系统现在准备好进行操作医疗装置以执行医疗程序。应当理解，“应用准备就绪”通知和“子系统准备就绪”通知的使用确保了医疗装置安全且可靠的启动。例如，通知防止每当发生阻止提供通知的故障时软件系统被启动。使用通知使得能够简单且有效地检测和定位软件系统中的故障。此
外，相比于背景技术部分中讨论的使用计时器和标称启动时间，使用通知还可以缩短启动医疗装置所需的时间，因为标称启动时间通常被设置为相对于实际启动时间具有明显的裕度。
81.还值得注意的是，共同的“子系统准备就绪”通知在步骤404中由子系统内的所有软件应用接收，并且该通知触发各个软件应用启用该子系统内的应用级别的内部通信。通过步骤401
‑
404，启动方法400提供了相应的子系统的分布式但确定性的启动。这又意味着，方法400省去了对相应的子系统内的各个软件应用的启动顺序进行集中控制的任何需要，而是允许所有这些软件应用每当接收到“子系统准备就绪”通知时就启动。本领域技术人员意识到，软件应用的这种分布式启动不仅促进了启动程序的控制和故障排除，而且还通过便于软件应用的添加和移除而促进了软件系统的维护和更新。
82.通知可以通过本领域公知的推送机制或拉动机制(pull mechanism)在软件系统中分发。通过推送机制，通知或指示通知可用的消息从始发方发送，以供接收方接收或拦截。通过轮询机制，接收方从始发方请求通知。
83.返回到图4a，可以注意到，“应用准备就绪”通知不需要在相应的子系统ss1
‑
ss4内从相应的软件应用直接向管理器shm1
‑
shm4提供。而是，子系统内的软件应用可以按照预定的序列从一个软件应用到下一个软件应用提供其“应用准备就绪”通知。然后，当序列中的最后的软件应用向管理器提供其“应用准备就绪”通知时，管理器得出结论，子系统中已提供了所有“应用准备就绪”通知。
84.也可以想到的是用中央管理器代替图3中的分布式管理器shm1
‑
shm4，中央管理器获得如上所述的“应用准备就绪”通知和“子系统准备就绪通知”。但是，分布式管理器shm1
‑
shm4提供了子系统ss1
‑
ss4严格模块化的优势，这又使得能够独立开发和/或测试和/或部署子系统ss1
‑
ss4。
85.在另一变型中，管理器shm1
‑
shm4的功能由相应的子系统ss1
‑
ss4中的软件应用之一代替执行。
86.还应注意，尽管图4a中的步骤404提供了以下优势：确保在子系统进入状态“子系统准备就绪”时，子系统中的软件应用能够相互通信并且子系统真正准备好启动，但是可以想到的是，子系统的这种内部通信在稍后的阶段(例如，当软件系统进入状态“系统准备就绪”时(例如，在下面的步骤408中))启用。
87.在又一个变型中，仅辅子系统ss2
‑
ss4中的软件应用被配置为提供“应用准备就绪”通知并从其相应的管理器shm2
‑
shm4接收“子系统准备就绪”通知，而主子系统ss1中的软件应用不是这样。
88.图4b是用于协调子系统ss1
‑
ss4的启动的方法405'的实施例的流程图，该方法405'可以作为图4a中的步骤405的部分来执行。在步骤406，主子系统ss1为相应的辅子系统ss2
‑
ss4提供“系统准备就绪”通知。返回到图4a，应该理解，当主子系统ss1已经既从其所有软件应用sw1获得了“应用准备就绪”通知(步骤403)又从所有辅子系统ss2
‑
ss4获得了“子系统准备就绪”通知(步骤405)时，生成“系统准备就绪”通知。在步骤407中，相应的辅子系统ss2
‑
ss4获得“系统准备就绪”通知。通过获得“系统准备就绪”通知，使管理器shm2
‑
shm4知道所有子系统ss1
‑
ss4都已准备好启动。同样，管理器shm1知道所有子系统都已准备好启动。从前述内容可以理解，当子系统的软件应用已经启动并且被允许彼此通信时，该子系统
准备好启动。
89.在随后的步骤408中，所有子系统ss1
‑
ss4的管理器shm1
‑
shm4启用子系统之间应用级别的通信，使得一个子系统中的软件应用能够与另一子系统中的软件应用进行通信。因此，步骤408启用子系统ss1
‑
ss4之间的“互相通信”。在图3的示例中，启用ss1和ss2之间、ss1和ss3之间以及ss3和ss4之间的通信。因此，步骤408不仅使得能够进行集中通信，即，主子系统和一个或多个辅子系统之间的通信，而且还能够进行辅子系统之间的直接通信。当步骤408完成时，软件系统已经启动并且医疗装置准备好执行至少部分的医疗程序，例如，通过向操作者提供指令，允许操作者输入用于医疗程序的控制参数值等。
90.方法405'确保所有子系统ss1
‑
ss4的确定性启动。提供“系统准备就绪”通知的优点类似于如上所述的提供“应用准备就绪”和“子系统准备就绪”通知的优点。例如，可以注意到，在步骤407中，软件系统内的所有辅子系统接收共同的“系统准备就绪”通知，并且该通知触发各个辅子系统启用软件系统内的子系统间通信。通过步骤406
‑
408，启动方法400提供了软件系统的分布式但确定性的启动。这又意味着方法400省去了对软件系统内的各个子系统的启动顺序进行集中控制的任何需要，而是允许所有子系统每当接收到“系统准备就绪”通知时就启动。本领域技术人员意识到，子系统的这种分布式启动不仅促进了启动程序的控制和故障排除，而且还通过便于子系统的添加和移除而促进了软件系统的维护和更新。
91.图5a是用于关闭由图3中的软件系统操作的医疗装置的方法500的实施例的流程图。关闭可以由操作者产生的关闭命令(例如，当操作者按下控制按钮时(参见图1a
‑
1c中的13))来触发，或通过医疗装置中的过程来触发。
92.在步骤501中，向主子系统ss1的管理器shm1通知关闭命令，并且管理器shm1通过为所有辅子系统ss2
‑
ss4提供“关闭”通知来进行开始关闭。在步骤502中，管理器shm1请求终止主子系统ss1中的软件应用sw1。在这种背景下，“终止”表示每个软件应用停止其活动性到使其准备好失去电力的程度。步骤503由每个辅子系统ss2
‑
ss4分别执行。管理器shm2
‑
shm4获得“关闭”通知，然后请求终止辅子系统ss2
‑
ss4的软件应用sw2
‑
sw4。然后，在步骤504中，主子系统ss1的管理器shm1开始医疗装置的电力失去，例如，通过通知医疗装置中的电源管理器切断电力。
93.步骤501
‑
503的组合通过将关闭分为系统级别和子系统级别确保医疗装置的确定性关闭。该原理在图6中进一步示出。当要关闭医疗装置时，软件系统处于“系统准备就绪”状态，并且每个子系统ss1
‑
ss4均处于“子系统准备就绪”状态。作为步骤501的结果，对应于图6中的转变iv，可以看到系统进入状态“系统未准备就绪”。在子系统级别上，在步骤501之后，子系统ss1
‑
ss4仍处于状态“子系统准备就绪”。作为步骤502
‑
503的结果，可以看到相应的子系统ss1
‑
ss4进入状态“子系统未准备就绪，对应于图6中的转变v。由此，在系统级别和子系统级别上使软件系统准备好，然后失去电力由步骤504启始，对应于图6中的转变vi。
94.图5b是用于请求终止主子系统ss1的软件应用sw1的方法502'的实施例的流程图，该方法502'可以作为图5a中的步骤502的部分执行。在步骤505中，管理器shm1为主子系统ss1的软件应用sw1提供“子系统未准备就绪”通知。在步骤506中，软件应用获得“子系统未准备就绪”通知。在步骤507中，在获得“子系统未准备就绪”通知之后，相应的软件应用sw1x例如通过完成所有正在进行的具有后果性结果的活动而准备好终止，这些活动如果立即被
停止，则可能对医疗装置在关闭后重新启动时的性能产生影响，即，生成损坏的数据，或危害对象的健康。这样的具有后果性影响的活动可以包括将数据写入存储器，完成计算，生成用于致动器(图1a
‑
1c中的17)的控制信号等。具有后果性结果的活动还可能涉及用户体验，例如，由扬声器(图11a
‑
11c中的15)完成播放音频信号，在显示器(图11a
‑
11c中的12)上呈现关闭消息等。因此，在步骤507中，相应的软件应用可以允许被视为非后果性的其他活动继续进行以稍后终止。在步骤508中，当准备好终止时，相应的软件应用sw1x提供“应用关闭准备就绪”通知。在步骤509，管理器shm1从软件应用sw1获得“应用关闭准备就绪”通知。当管理器shm1已从所有软件应用sw1获得“应用关闭准备就绪”通知时，主子系统ss1可以视为处于状态“子系统未准备就绪”(图6)。
95.图5c是用于请求终止辅子系统ss2
‑
ss4的软件应用sw2
‑
sw4的方法503'的实施例的流程图，该方法503'可以作为图5a中的步骤503的部分来执行。方法503'由每个辅子系统ss2
‑
ss4分别执行。步骤505
‑
509对应于图5b中的方法502'的步骤505
‑
509，因此将不进一步描述。应当理解，步骤505和509由管理器shm2
‑
shm4执行，步骤506
‑
508由辅子系统ss2
‑
ss4的相应的软件应用执行。在步骤509之后，相应的辅子系统ss2
‑
ss4可以被视为处于状态“子系统未准备就绪”(图6)。在步骤510中，如果在步骤509中管理器shm2
‑
shm4已经从相应的辅子系统ss2
‑
ss4的所有软件应用获得了“应用关闭准备就绪”通知，则相应的管理器shm2
‑
shm4为主子系统ss1提供“子系统关闭准备就绪”通知。
96.返回到图5a，在步骤504中，管理器shm1仅在从所有辅子系统ss2
‑
ss4获得“子系统关闭准备就绪”通知(由方法503'生成)之后并且在从主子系统ss1中的所有软件应用sw1获得“应用关闭准备就绪”通知(由方法502'生成)之后，才可以开始电力失去。
97.在步骤504的变型中，可以想到的是，如果自从步骤501起经过了预定时间，管理器shm1在不存在来自一个或多个辅子系统ss2
‑
ss4的“子系统关闭准备就绪”通知的情况下也继续开始电力失去。因此，管理器shm1可以设置计时器，该计时器限定直到开始电力失去为止的最大时间延迟。如果软件应用或硬件组件在关闭期间发生故障，则这可以减轻软件冻结的风险。类似地，可以想到的是，管理器shm1
‑
shm4在步骤509中设置用于获取“应用关闭准备就绪”通知的对应的定时器。
98.还可以想到，在步骤509中，一个或多个管理器shm1
‑
shm4完全忽略来自一个或多个软件应用(例如，如果其所有活动立即停止，所有活动固有地不会造成后果性结果的软件应用)的“应用关闭准备就绪”通知，或者这些软件应用不提供“应用关闭准备就绪”通知。出于相同的原因，还可以想到，在步骤504中，管理器shm1完全忽略来自子系统的“子系统关闭准备就绪”通知，或者这样的子系统不提供“子系统关闭准备就绪”通知。
99.方法502'和503'中的每一个确保相应的子系统ss1
‑
ss4的确定性关闭，并且减轻正在进行的具有后果性结果的活动在切断电力时的风险。
100.在另一变型中，仅辅子系统ss2
‑
ss4中的软件应用被配置为从其相应的管理器shm2
‑
shm4接收“子系统未准备就绪”通知，并提供“应用关闭准备就绪”通知，而主子系统ss1中的软件应用不是这样。
101.尽管方法502'和/或503'可用于降低对象的健康风险，但是可能需要在医疗装置的关闭期间进一步提高患者的安全。在图5d中示例说明的一个实施例中，把关控制(gatekeeping)方法520在允许主子系统ss1启始步骤501中的关闭之前由软件系统执行。在
把关控制方法520中，每个关键软件应用被赋予“否决权”，从而如果认为这样的关闭会损害患者的安全，则阻止关闭该软件系统。在步骤521中，在被通知关闭命令之后，主子系统ss1的管理器shm1继续以向关键软件应用(例如，图3的示例中的sw1c和sw3c)提供“关闭请求”。在步骤522中，每个关键软件应用sw1c、sw3c验证“关闭请求”。在此验证中，相应的关键软件应用sw1c、sw3c可以基于一个或多个预定的关闭标准来评估关闭是否可接受。一种这样的关闭标准可以是患者的安全。在一个示例中，在医疗程序或其子过程完成之前，关闭可能被认为是不可接受的。在另一个示例中，在完成校准过程之前，关闭可能被认为是不可接受的。在另一个示例中，除非关键软件应用处于安全操作状态(例如，服务模式、空闲模式等)，否则关闭可能被认为是不可接受的。在步骤523中，仅当在步骤522中认为关闭是可接受的时，相应的软件应用sw1c、sw3c才提供“应用关闭准备就绪”通知。可选地，在步骤524中，相应的关键软件应用sw1c、sw3c然后可以进入受控状态。在这种背景下，“受控状态”意味着关键软件应用sw1c、sw3c根据考虑到患者的安全而设置的控制参数值进行操作，例如，通过降低泵速、停止泵、打开或关闭阀、关闭加热器等。然后，把关控制方法520继续到步骤501，在该步骤中，管理器shm1仅在已经获得了来自所有关键软件应用sw1c、sw3c的“应用关闭准备就绪”通知的情况下才继续以提供“关闭”通知。
102.把关控制方法520防止医疗装置在正在进行的医疗程序期间无意地关闭，例如，通过操作者按下开/关按钮。可以注意到，上述定时器未在把关控制方法520中实现，这意味着每个关键软件应用都对关闭过程拥有真正的否决权，除非关键软件应用提供“应用关闭准备就绪”，否则该关闭过程将在步骤501处停止。在这种情况下，可以想到的是，步骤501还涉及要求操作者确认应该发起覆盖关闭程序(override shutdown procedure)。如果确认，则关键软件应用可以被设置为受控状态，在此之上，可以根据图5a中的方法500继续进行关闭。
103.在下文中，将参考图7a
‑
7e和图8a
‑
8c中的序列图示例说明上述实施例和其他实施例。图7a
‑
7e描绘了在医疗装置的启动期间执行的步骤的序列，其被划分为用于图6中的转变ia、ib、ii和iii中的每一个的方法。图8a
‑
8c描绘了在医疗装置的关闭期间执行的步骤的序列，其被划分为用于图6中的转变iv、v和vi中的每一个的方法。所说明的步骤序列假定启动和关闭均在没有错误的情况下发生，尽管在下面的描述中将简要介绍错误处理。
104.图7a描绘了在子系统启始期间执行的方法，并且对应于图6中的转变ia。图7a中的子系统启始假定已在ss1中执行了安全引导，并且shm1已经检查了ss1的程序二进制文件(program binary)。在步骤701中，在引导期间，shm2、shm3和shm4分别检查ss2、ss3和ss4的相应的程序二进制文件。如果步骤701中的检查对于ss2
‑
ss4中的任何一个失败，则ss1将在随后的步骤712(参见图7b)中检测到该情况。在步骤702中，shm1
‑
shm4中的每一个都开始开启相应的硬件看门狗，这意味着相应的看门狗定时器被重启，如本领域技术人员所公知的。在步骤703中，shm1
‑
shm4分别标识ss1
‑
ss4的软件和硬件版本。在步骤704中，shm1和shm3中的每一个将关闭原因参数设置为“错误”，并将其存储在非易失性存储器中(参见图2中的m1
‑
m2)。如果随后的关闭在没有错误的情况下执行，则关闭原因参数被替代地设置并存储为“正常”(参见图8c中的步骤826)。默认存储为“错误”的原因是为了确保在启动期间检测到错误的关闭。由此，即使在例如由于电力失去而引起快速且无意的关闭事件的情况下，关闭原因参数将被存储为“错误”。步骤704可以涉及shm1和shm3执行对关闭原因参数的存储
值的初始检查。如果shm1(或shm3)得到值“错误”，则shm1(或shm3，或其两者)可以进入恢复模式，以使shm1(或shm3，或其两者)能够从关闭前的停止的位置恢复。在所示的示例中，步骤704仅由关键子系统ss1和ss3执行。然而，可以想到的是，只要需要或期望恢复ss2和/或ss4，也对不包括任何关键软件应用的ss2和/或ss4执行步骤704。
105.在步骤704之后，ss1
‑
ss4继续到转变ib。如图7a所示，可以与转变ib并行地执行ss1的转变ii。
106.图7b描绘了在系统启始期间执行的方法，并且对应于图6中的转变ib。在步骤710中，shm1
‑
shm4开启相应的通信模块isc1
‑
isc4(参见图3)。然后，shm1通过提供对连接的请求(步骤711)并接收对已建立的连接的确认(步骤712)，重复执行步骤711
‑
712以建立与ss2、ss3和ss4中的每一个的连接。如果无法建立连接，则isc1可以报告系统中的错误。建立连接后，shm1通过提供版本请求(步骤713)并接收版本数据，重复执行步骤713
‑
714，以从shm2、shm3和shm 4获得软件和硬件版本。版本数据可以包括相应的软件和硬件版本的标识符。如果未接收到版本数据，则shm1可以报告系统中的错误。当接收到版本数据时，shm1检查软件版本彼此的兼容性(步骤715)，并检查软件版本与硬件版本的兼容性(步骤716)。例如，shm1检查ss2、ss3和ss4的软件版本与ss1的软件版本的兼容性。如果步骤715或步骤716失败，或两者都失败，则shm1可以报告系统中的错误。
107.在步骤716之后，ss1
‑
ss4中的每一个继续到转变ii。如上所述，ss1可以与转变ib并行地执行转变ii。
108.图7a
‑
7b中的方法用于减轻例如不同子系统中的软件版本不兼容和/或硬件和软件不匹配和/或程序二进制文件在ss2
‑
ss4的任何一个中被破坏的风险，所有这些都可能导致医疗装置的不确定行为。
109.图7a
‑
7b中的序列图可以被看作示例说明实施例，在该实施例中，用于启动医疗装置的方法包括：开启每个子系统中的管理器；由管理器开启每个子系统(ss1
‑
ss4)中的通信模块；以及由主子系统的通信模块建立与相应的辅子系统中的通信模块的连接。
110.图7a
‑
7b中的序列图还可以被看作示例说明实施例，在该实施例中，用于启动医疗装置的方法包括：由主子系统的管理器获得包括在子系统中的软件的软件标识符；以及由主子系统的管理器基于软件标识符来验证软件的兼容性。
111.图7a
‑
7b中的序列图还可以被看作示例说明实施例，在该实施例中，用于启动医疗装置的方法包括：由主子系统的管理器获得由子系统使用的硬件的硬件标识符；以及由主子系统的管理器基于硬件标识符和软件标识符来验证硬件和软件之间的兼容性。
112.图7c描绘了在子系统启动期间由ss1执行的方法，并且对应于图6中的转变ii。在图7c中，ss1的各个软件应用通常表示为sw1x。仅出于说明的目的，图7c还明确地描绘了gui，该gui是负责显示器上的图形可视化并管理用户输入的软件应用。优选地，gui位于ss1中以确保快速开始用户交互。在步骤720中，shm1向gui和每个sw1x提供启动请求(参见步骤401)。在步骤721中，在获得启动请求之后，gui和每个sw1x执行内部启动。在一些实施例中，内部启动包括使软件应用准备好用于与同一子系统的其他部分进行通信(即，在同一子系统内的软件应用或处理之间的通信)。在步骤722中，当准备好启动时，gui和每个sw1x提供相应的“应用准备就绪”通知n1(参见步骤402)。该通知可以表明软件应用已准备好与同一子系统的其他部分进行通信。在步骤723中，shm1等待来自gui和每个sw1x的n1。如果shm1在
超时时段(timeout period)内未接收到n1，则shm1可以报告系统错误。在步骤724中，shm1判断gui和每个sw1x准备好启动，即当它们已经提供了“应用准备就绪”通知时。在步骤725中，shm1向gui和每个sw1x提供“子系统准备就绪”通知n2(参见步骤403)。在步骤726中，在接收到n2之后，gui和每个sw1x启用在ss1内彼此之间的通信(参见步骤404)。这意味着被配置为与ss1中的另一个软件应用交换数据的任何软件应用在开始数据交换之前都要等待n2。然而，可以在步骤726之前和/或之后激活相应的软件应用的其他功能。例如，gui可以被配置为使得它在步骤726之后尽快启用用户交互。但是，在一些实施例中，一个或多个(或全部)软件应用被配置为在提供n1之后暂停其内部启动，并在继续其内部启动之前等待n2。此外，在步骤726之前或之后，但无论如何在步骤727之前，激活gui和每个sw1x以在ss1内发送内部心跳。在步骤727中，shm1开始监测ss1内的内部心跳，以确保gui和每个sw1x是可操作的。在步骤727之后，ss1处于状态“子系统准备就绪”，并继续到转变iii。
113.图7d描绘了在子系统启动期间由ss2
‑
ss4执行的方法，并且对应于图6中的转变ii。在图7d中，ss2
‑
ss4的各个软件应用通常分别表示为sw2x
‑
sw4x。图7d中的步骤720
‑
727对应于图7c中的步骤720
‑
727，不同之处在于它们是在ss2
‑
ss4内而不是ss1内执行的。此外，在一些实施例中并且与图7c中的方法相反，如果在超时时段内未接收到n1，则shm2
‑
shm4可以避免报告系统中的错误。而是，由于不存在n1意味着未生成n2，因此shm1可以在系统启动期间，具体而言是在步骤730(参见图7e)，可以检测到该错误。鉴于对图7c的描述，根据图7d的子系统启动应该是不言自明的，因此在此不做进一步描述。在步骤727之后，ss2
‑
ss4处于状态“子系统准备就绪”并且继续到转变iii。
114.图7c
‑
7d中的方法用于减轻例如软件应用在另一软件应用未准备好通信时开始与该另一软件应用通信的风险。在这种情况下，另一软件应用将无法接收或处理传入的请求，而传达请求的软件应用无法知道这种不能性。
115.图7c
‑
7d中的序列图可以被看作示例说明实施例，在该实施例中，在启动期间以及针对每个子系统，用于启动医疗装置的方法包括：操作软件应用以发送内部心跳信号；以及开始由管理器监测内部心跳信号，以检测一个或多个软件应用的运行故障。
116.图7e描绘了在系统启动期间执行的方法，并且对应于图6中的转变iii。在图7e中，仅描绘了shm1
‑
shm4以及关键的软件应用sw1c和sw3c，而省略了ss1
‑
ss4的任何其他软件应用。在步骤730中，当ss2
‑
ss4准备好时，shm1
‑
shm3通过提供“子系统准备就绪”通知n2将其报告给shm1。实际上，步骤730可以由图7d中的步骤725代替，因此其在相应的子系统ss1
‑
ss4的内部和外部提供n2。在步骤731中，shm1等待来自所有shm2
‑
shm4的n2。如果shm1在超时时段内未接收到n2，则shm1可以报告系统中的错误。在步骤732中，shm1判断所有ss1
‑
ss4都准备好启动(参见图4a中的步骤405)。可以注意到，在此阶段默认shm1知道ss1已准备好启动，因为它已经完成了图7c中的转变ii。在步骤733中，shm1向ss1中的所有软件应用通知系统已准备好启动。在步骤734中，shm1开始在系统中发送外部心跳。在步骤735中，shm1提供“系统准备就绪”通知n3，以供shm2
‑
shm4接收(参见图4b中的步骤406)。在步骤736中，在获得n3之后(参见图4b中的步骤407)，shm2
‑
shm4中的每一个向其所有软件应用通知状态“系统准备就绪”。在步骤737中，shm2
‑
shm4的每个开始在系统中发送外部心跳。在步骤738中，shm2
‑
shm4中的每一个提供确认通知以供shm1接收。如果shm1在超时时段内未接收到确认通知，则shm1可以报告系统中的错误。在步骤739中，在从所有shm2
‑
shm4接收到确认通知
之后，shm1开始在系统中监测外部心跳。在步骤737之后的任意时间，允许ss1
‑
ss4的每一个中的软件应用在ss1
‑
ss4之间建立的通信路径(参见图3)上与一个或多个其他子系统中的软件应用开始应用级别的通信(参见图4b中的步骤408)。
117.图7e中的示例还包括步骤740
‑
741，其仅关于关键软件应用sw1c和sw3c执行，并且需要在允许sw1c和sw3c中的每一个与其他子系统中的软件应用进行通信之前完成。在步骤740中，sw1c/sw3c向shm1/shm3请求“系统准备就绪”状态的确认。在步骤741中，shm1/shm3向swc1/sw3c确认状态。这提供了针对可能损害患者的安全的故障的附加级别的鲁棒性。
118.为了提供进一步级别的鲁棒性，可以想到的是，关键子系统ss3中的步骤737还涉及shm3开始监测由另一个关键子系统shm1生成的外部心跳。从而，在关键子系统ss1、ss3之间建立了心跳的相互监测，从而使子系统能够快速检测其他关键子系统中的操作故障并采取适当的措施。
119.图7e中的方法用于减轻例如一个子系统中的第一软件应用在另一子系统中的第二软件应用还没有准备好通信时开始与该第二软件应用通信的风险。在这种情况下，第二软件应用将无法接收或处理传入的请求，而第一软件应用将无法知道接收端处的问题。
120.图7e中的序列图可以被看作示例说明实施例，在该实施例中，用于启动医疗装置的方法包括：操作相应的辅子系统的管理器以发送外部心跳信号；以及由主子系统的管理器开始监测外部心跳信号，以检测一个或多个辅系统的操作故障。
121.图7e中的序列图还可以被看作示例说明实施例，在该实施例中，用于启动医疗装置的方法包括：操作两个或更多个关键子系统的每个管理器以发送外部心跳信号；以及开始在关键子系统的管理器之间相互监测外部心跳信号，以检测操作故障。
122.此外，图7c
‑
7e中的序列图可以被看作示例说明实施例，在该实施例中，在启动期间用于启动医疗装置的方法包括：当未在第一预定时间段内从主子系统的软件应用接收到“应用准备就绪”通知n1时，由主子系统中的管理器报告第一错误；当未在第二预定时间段内从辅子系统接收到“子系统准备就绪”通知n2时，由主子系统中的管理器报告第二错误。
123.图8a描绘了在系统关闭期间执行的方法，并且对应于图6中的转变iv。在该方法开始时，假设软件系统已启动并正在运行，因此处于图6中的状态“系统准备就绪”。所示的示例还假定sw3c已被注册为shm1的“关闭把门控制件(shutdown gatekeeper)”，因此是“关闭”请求的订户。在步骤801中，操作者输入命令以关闭医疗装置，例如通过按下控制按钮。该命令由gui检测，该gui提供关闭请求以供shm1接收。在步骤802中，shm1转发关闭请求r1，以供sw1c接收。在步骤803中，sw1c验证r1。在步骤804中，在成功验证之后，sw1c将r1提供给sw3c。在步骤805中，sw3c验证r1。在成功验证之后，sw3c进入受控状态(步骤806)，并提供“应用关闭准备就绪”通知n7，以供sw1c接收(步骤807)。在接收到n7之后，sw1c进入受控状态(步骤808)，并将n7转发给shm1(步骤809)。在接收到n7后，shm1继续系统关闭。如果在步骤803中验证失败和/或如果在步骤809中，shm1在超时时段内未接收到n7，则shm1可以将“关闭未批准”通知返回给gui，然后该gui可以相应地通知操作者。
124.步骤802
‑
809的组合对应于图5d的把关控制方法520，并且示出在shm1与相应的关键软件应用sw1c、sw3c之间的直接通信中既不需要提供r1也不需要提供n7，但是r1和n7可以传输链的形式被中继。因此，当比较图5d和图8a时，步骤521可以对应于步骤802和804，步骤522可以对应于步骤803和805，步骤523可以对应于步骤807和809，步骤524可以对应于步
骤806和808。在变型中，n7不在传输链中被中继，而是直接从sw3c提供给shm1。
125.在步骤810中，shm1通过停止与ss2
‑
ss4的应用级别的通信来将其状态更新为“系统未准备就绪”。在步骤811，shm1停止监测外部心跳，即，由ss2
‑
ss4生成的心跳。在步骤812中，shm1提供“关闭”通知n4，以供shm2
‑
shm4接收(参见图5a中的步骤501)。在步骤813中，在接收到n4之后，shm2
‑
shm4中的每一个通过停止与其他子系统的应用级别的通信来将其状态更新为“系统未准备就绪”。在步骤814中，shm2
‑
shm4中的每一个停止发送外部心跳。如果软件系统在关键子系统之间实现上述相互心跳监测，则ss3中的步骤814也可能导致shm3停止监测shm1生成的外部心跳。在步骤815中，在完成步骤813
‑
814之后，shm2
‑
shm4中的每一个提供“确认”通知n5，以供shm1接收。n5用信号通知shm1相应的子系统ss2
‑
ss4已接收到n4。在步骤816中，在接收到n5之后，shm1停止发送外部心跳。如果shm1在超时时段内未从所有ss2
‑
ss4接收到n5，则shm1可以报告系统中的错误。
126.图8a中的方法用于减轻例如在医疗装置执行医疗程序的同时，特别是当医疗程序的中断可能损害患者的安全时，操作者主动关闭医疗装置的风险，以及一个关键子系统或软件应用准备好终止，而另一个关键子系统或软件应用没有准备好的风险。例如，如果在继续医疗程序的同时上述保护系统停机(go down)，则将会危及患者的安全。
127.图8a中的序列图可以被看作示例说明实施例，在该实施例中，用于关闭医疗装置的方法包括，在向辅子系统提供“关闭”通知n4之前：由主子系统的管理器为关键软件应用的链中的第一关键软件应用提供关闭请求r1，从而使该链中的每个关键软件应用根据医疗装置的操作来验证关闭请求r1，并且如果关闭是可接受的，则为该链中的后一个关键软件应用提供关闭请求r1，直到该链中最后的关键软件应用接收到关闭请求r1为止；其中，该链中最后的关键软件应用根据医疗装置的操作来验证关闭请求r1，并且如果关闭是可接受的，则使“应用关闭准备就绪”通知n7被提供给主子系统的管理器。关闭请求r1的这种有条件和顺序的验证可以用来提高把门控制方法的鲁棒性。
128.图8a中的序列图还可以被看作示例实施例，在该实施例中，用于关闭医疗装置的方法中，“应用关闭准备就绪”通知n7沿着关键软件应用的链中继到主子系统的管理器。
129.图8a中的序列图还可以被看作示例实施例，在该实施例中，链中的每个关键软件应用在接收到“应用关闭准备就绪”通知n7时进入受控状态，在该受控状态下医疗装置根据预定的参数值集合操作。
130.图8b描绘了在子系统关闭期间执行的方法，并且对应于图6中的转变v。图8b中的方法可以在接收到“关闭”通知n4(图8a中的步骤812)之后的任何时间由ss1
‑
ss4中的每一个执行。在步骤820中，每个shm1
‑
shm4停止监测内部心跳。在步骤821中，shm1
‑
shm4中的每一个为其软件应用提供“子系统未准备就绪”通知n6(参见图5b
‑
5c中的步骤505)。在步骤822中，在接收到n6之后，软件应用准备终止并停止相应的子系统内彼此之间的通信(参见图5b
‑
5c中的步骤506
‑
507)。在步骤824中，当准备好终止时，相应的软件应用sw1x
‑
sw4x为其管理器shm1
‑
shm4提供“应用关闭准备就绪”通知n7(参见图5b
‑
5c中的步骤508)。可选地，如图8b中的步骤823所示，可以响应于来自管理器shm1
‑
shm4的确认请求而发送n7。在步骤825中，shm1
‑
shm4中的每一个都等待来自其所有软件应用的n7。如果shm1
‑
shm4中的任何一个在超时时段内未从其所有软件应用接收到n7，则它可以报告系统中的错误。在步骤826中，在完成步骤825之后，关键子系统ss1、ss3中的shm1和shm3将关闭原因参数设置为“正
常”并将其存储在非易失性存储器中。在步骤827中，shm2
‑
shm4中的每一个为shm1提供“子系统关闭准备就绪”n8(参见图5c中的步骤510)。现在，已在系统级别和子系统级别两者上使软件系统准备好失去电力。
131.如以上参考图5b
‑
5c所示例说明的，图8b中的方法用于减轻例如当软件应用执行具有后果性结果的活动时切断电力的风险。
132.图7a和图8a中的序列图可以被看作示例实施例，在该实施例中，操作医疗装置的方法包括：在关闭期间没有错误的情况下，由至少一个管理器将关闭原因参数设置为指示正常关闭，并将关闭原因参数存储在存储器单元集合中。此外，该方法可以包括：在启动期间，由至少一个管理器将关闭原因参数设置为指示关闭错误，并将关闭原因参数存储在存储器单元集合中。
133.图8c描绘了在软件系统的执行退出期间执行的方法，并且对应于图6中的转变vi。在完成步骤827之后，由ss1
‑
ss4中的每一个执行图8c中的方法。在步骤830中，shm1
‑
shm4中的每一个在继续开启相应的硬件看门狗的同时等待电力失去。ss1
‑
ss4的任何一个都不可能离开该状态而不失去电力。在此阶段，可以安全关闭系统。例如，在步骤830中，shm1可以使医疗装置切断电力，例如，通过为医疗装置的功率管理器生成“电力切断”通知。
134.尽管已经结合当前被认为是最实用和优选的实施例描述了本发明，但是应当理解，本发明不限于公开的实施例，相反，本发明旨在覆盖包含在所附权利要求书的精神和范围内的各种修改和等同布置。