CN104914726A - 医疗设备控制系统及方法 - Google Patents

Abstract

一种医疗设备控制系统，包括事件调度模块、状态管理模块、动作管理和执行模块、资源管理模块和基础功能模块。上述医疗设备控制系统，将通用的医疗设备控制和调度逻辑进行封装，对具有相对独立功能的模块进行分离，建立重用机制；抽取易变因素，通过配置文件和具有良好协作接口的、可装配的软件模块进行隔离，提供相应的机制支持这些易变因素的变化。从而使医疗设备控制方法能够应用于不同类型的医疗设备中，以达到提高医疗设备控制软件的研发效率和质量的目标。同时，还提供一种医疗设备控制方法。

Description

医疗设备控制系统及方法

技术领域

本发明涉及医疗设备技术领域，特别是涉及一种医疗设备控制系统及方法。

背景技术

随着医学科学和生物工程技术的发展，各类医疗设备不断涌现，在各个医疗领域发挥着重要的作用。医疗设备向着自动化、信息化的方向不断发展，计算机硬件和计算机软件技术成为医疗设备的基础之一。医疗设备中采用的硬件种类逐步增多、硬件功能不断增强，硬件间的协作越来越复杂和多变，通过软件控制和调度硬件的要求越来越高。在不同医疗设备的研发过程中，往往需要重复开发硬件管理和调度功能，不仅成本高、效率低，也很难保证产品质量。亟需一种通用的方法和系统来管理和协调不同硬件器件，使不同硬件器件能够协调一致，共同完成预定的功能目标。

发明内容

基于此，有必要针对医疗设备硬件种类逐步增多、功能不断增强，不便于逐一开发软件的问题，提供一种医疗设备通用的医疗设备控制系统及方法。

一种医疗设备控制系统，包括：

事件调度模块，用于接收事件，并分发所述事件；

状态管理模块，用于接收分发的所述事件，根据所述事件和当前的状态信息变迁或维持所述状态信息，并根据配置定义的规则处理所述事件；

动作管理和执行模块，用于创建、调度和执行动作实例，并提供动作扩展机制；

资源管理模块，用于为所述动作实例提供资源访问接口，并实现资源的功能；

基础功能模块，用于支持实现所述资源。

一种医疗设备控制方法，包括：

接收事件，并分发所述事件；

接收分发的所述事件，根据所述事件和当前的状态信息变迁或维持所述状态信息，并根据配置定义的规则处理所述事件；

创建、调度和执行动作实例，并提供动作扩展机制；

为所述动作实例提供资源访问接口，并实现资源的功能；

支持实现所述资源。

上述医疗设备控制系统及方法，通过接收分发的事件，根据事件和当前的状态信息变迁或维持状态信息；并根据配置定义的规则处理事件等步骤，将通用的医疗设备控制和调度逻辑进行封装，对具有相对独立功能的模块进行分离，建立重用机制；抽取易变因素，通过配置文件和具有良好协作接口的、可装配的软件模块进行隔离，提供相应的机制支撑这些易变因素的变化。从而医疗设备控制方法及系统能够应用于不同类型的医疗设备中，以达到提高医疗设备控制软件的研发效率和质量的目标。

附图说明

图1为一实施例医疗设备控制系统的示意图；

图2为图1所示医疗设备控制系统中的事件调度模块的示意图；

图3为图1所示医疗设备控制系统中的状态管理模块的示意图；

图4为图1所示医疗设备控制系统中的动作管理和执行模块的示意图；

图5为图1所示医疗设备控制系统中动作动态链接库集成图；

图6为图1所示医疗设备控制系统中的动作异常处理模块的工作流程图；

图7为图1所示医疗设备控制系统中的资源管理模块的示意图；

图8为图1所示医疗设备控制系统中的基础功能模块的流示意图；

图9为图1所示医疗设备控制系统可应用于的医疗设备的硬件结构示意图；

图10为一实施例医疗设备控制方法的流程图；

图11为图10所示医疗设备控制方法中的步骤S110的流程图；

图12为图10所示医疗设备控制方法中的步骤S120的流程图；

图13为图10所示医疗设备控制方法中的步骤S130的流程图；

图14为图10所示医疗设备控制方法中的步骤S140的流程图；

图15为图10所示医疗设备控制方法中的步骤S150的流程图。

具体实施方式

为了便于理解本发明，下面将参照相关附图对医疗设备控制系统及方法进行更全面的描述。附图中给出了医疗设备控制系统及方法的首选实施例。但是，医疗设备控制系统及方法可以以许多不同的形式来实现，并不限于本文所描述的实施例。相反地，提供这些实施例的目的是使对医疗设备控制系统及方法的公开内容更加透彻全面。

除非另有定义，本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中在医疗设备控制系统及方法的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本发明。本文所使用的术语“及/或”包括一个或多个相关的所列项目的任意的和所有的组合。

图1为一实施方式的医疗设备控制系统，本实施例可以应用在具体的医疗设备中，针对不同医疗设备进行适应性开发后即可实现完整的控制软件系统。如图1所示，本实施例的医疗设备控制系统包括事件调度模块110、状态管理模块120、动作管理和执行模块130、资源管理模块140和基础功能模块150。

事件调度模块110，接收事件，并分发事件。在分发事件时，可以基于预设信息进行事件的分发。事件的兴趣可以根据实际需要进行划分。接收到的事件为多个，可以通过事件队列实现事件的异步发送。参见图2，在其中一个实施例中，事件调度模块110包括事件接收/分发模块112和事件兴趣管理模块114。

事件接收/分发模块112，用于接收、分发事件。用于实现事件接收和分发功能。事件接收过程通过同步接口接收事件，并将事件保存在事件队列中，运行于调用线程中。事件分发过程运行于独立的线程中，通常是系统的主线程。从事件队列中依次读取事件，并转发给事件处理实例。在其中一个实施例中，转发过程可以按照兴趣进行。

事件兴趣管理模块114，用于管理事件处理实例，提供基于预设信息的注册和注销方法。事件处理实例需要通过注册方法提交自己感兴趣的事件类型，同时提交接收事件的回调接口。事件处理实例可以是状态机、动作管理器和软件资源。在其中一个实施例中，动作通过软件资源进行事件的发布和处理；动作管理器处理异步动作的结束通知，用于删除动作实例。事件处理实例提供同步接口，事件分发时调用该接口，在该接口实现中，可以实现同步事件处理和异步事件处理。

事件的兴趣可以根据实际需要进行划分。从软件系统是否理解事件语义的角度，可以初步划分为软件事件和扩展事件两类，其中软件事件是软件控制系统需要理解语义并进行处理的事件。扩展事件是软件控制系统不需要理解的事件，这类事件由自定义动作使用，软件控制系统只提供发布和转发该类事件的通用方法。事件所携带参数在转发过程完毕后进行释放。通过上述事件调度机制，在系统内建立了灵活的协作方式，在实施过程中，能够容易地扩展动作间的协作，使本软件控制系统，能够适用于各种应用场景中。

在其中一个实施例中，以血液分析仪为例，事件包括开始测量、测量结束、发生堵孔故障、上样动作完成等。状态机模块对开始测量、测量结束、发生堵孔故障等事件感兴趣，向事件接收/分发模块112注册；采样动作对上样动作完成事件感兴趣，向事件接收/分发模块112注册。当上述事件发生时，根据注册兴趣信息，进行转发。其中，开始测量、测量结束、发生堵孔故障事件属于软件事件，上样动作完成事件属于扩展事件。

状态管理模块120，用于接收分发的事件，根据事件和当前的状态信息变迁或维持状态信息，并根据配置定义的规则处理事件。状态管理模块120用于管理设备的状态信息，并根据当前状态判定接收到事件后的行为，定义了在不同场景下，系统如何运转。在其中一个实施例中，参见图3，状态管理模块120包括系统管理模块122、状态机模块124和状态关系管理模块126。

系统管理模块122，用于实现系统软件初始化/反初始化、功能实例生存期管理的功能。较优的，还可以实现软件系统进入和退出工作状态。

状态机模块124，用于保存设备的状态信息，并接收事件，根据当前的状态信息，以及配置定义的规则处理事件，事件通过相应的动作实例实现。根据当前的状态信息对事件进行响应。较优的，状态机不保存除状态外的其他信息。根据当前的状态信息对事件进行响应表现为创建、控制动作，忽略事件，记录日志等。

在其中一个实施例中，事件分为命令和通知，命令用于表示系统定义的具有独立意义的功能，通知是动作实例执行过程中产生的信息，用于动作实例管理、协作和产生新的命令。其中，动作管理包括已有动作的销毁和创建新动作。事件可以引发状态的变迁。事件的发送和处理通过事件调度模块完成，这个过程是基于预设信息的。

状态机模块124封装了处理事件的通用逻辑，包含了如何根据规则将命令分解为动作，并按照规则中的定义的顺序调用。规则定义了事件的具体处理逻辑，是易变的；通用逻辑是稳定的，实现了读取、解析和执行规则。规则包括当前状态和事件语义。规则可以由配置表达，定义为Action＝f(Status，Event)。

一个典型的状态机包括开机准备状态、待机状态、运转状态、休眠状态、故障状态、调试状态、维护状态、退出状态。为了简化控制，不采用多级状态机，所有状态都属于一层。通过配置表达的规则描述每个状态能够处理的命令，以及每个命令分解为哪些动作和动作调用顺序。软件系统实现通用的逻辑，通过该配置获得每个状态的行为逻辑。在实施过程中，不仅能够通过配置表达的规则灵活地扩展状态机的行为，也可以基于上述逻辑，对某个事件的处理逻辑进行扩展。

在其中一个实施例中，状态机模块124封装了处理事件的通用逻辑。事件可以通过执行一个或多个动作实例来处理。通过配置来定义每个状态能够处理的事件，以及事件被拆分为哪些动作和拆分后动作的调用顺序，这些逻辑是易变的；而解析配置，执行配置中定义的动作，是通用而稳定的逻辑。状态机模块124实现了上述通用的逻辑，包含读取配置，解析配置，调用动作管理模块创建和执行动作实例。在实施过程中，不仅能够通过配置灵活地扩展状态机的行为，也可以对某个事件的处理逻辑进行扩展。

状态关系管理模块126，用于保存状态关系的信息，根据事件和状态关系变迁或维持状态信息。状态关系管理模块126从状态机模块124接收事件，并根据规则定义是否发生状态变迁。若发生状态变迁，则相应的变迁状态信息，若未发送状态变迁，则不变迁状态信息，即维持状态信息。状态变迁的规则可以包含一系列事件，可以定义为Status＝f(Status，Set(Event，TimeTag))，其中Set(Event，TimeTag)是一组具有时间顺序关系的事件集合，该集合综合发生作用，该集合可以包括一个或多个事件。事件包含优先级属性，用于定义事件预计的发生顺序。属于一个事件集合的事件在判定转换规则时，可以依赖时间顺序，也可以不依赖时间顺序，当依赖时间顺序时，根据TimeTag和事件的优先级属性综合决策。通过上述机制，能够建立较灵活的状态机管理方法，能够根据实施中的需要，以配置的方式快速而高质量地调整状态机的行为，能够有效提高开发效率和质量。

在其中一个实施例中，以血液分析仪为例，典型的状态机包括开机准备状态、待机状态、运转状态、休眠状态、故障状态、调试状态、维护状态、退出状态。为了简化控制，不采用多级状态机，所有状态都属于一层。在配置中定义开机准备状态不处理任何命令，在待机状态能够接收并测量命令，测量命令定义为由上样动作和采样动作实现，调用顺序为上样动作前于采样动作。状态机模块124解析该配置，当收到测量命令后，创建上样动作实例、采样动作实例，并依次调用。状态关系管理模块126中定义了状态转移关系，如，开机准备状态在完成所有初始化动作后，切换为待机状态；待机状态下，收到测量命令并开始执行时，切换为运转状态。

动作管理和执行模块130，用于创建、调度和执行动作实例，并提供动作扩展机制。在其中一个实施例中，参见图4，动作管理和执行模块130包括动作管理模块132、动作扩展模块134和动作异常处理模块136。

动作管理模块132，用于创建、删除、调度和执行动作实例。医疗设备控制系统的控制逻辑划分为三个层次：命令、动作和指令。命令是指系统定义的具有独立意义的功能，是系统对外体现的能力，由一个或多个动作协调完成。动作是一个或多个命令可使用的功能，具有完整性，系统外不可见，由一个或多个指令完成。指令是指某个资源能够完成的单一功能，如电机器件的运行指令。通过这三个层次的划分，将不同粒度的逻辑进行不同程度的划分和组织，使每层能够专注于解决一定范围的问题，能够降低设计和实现的复杂度，并实现较好地重用。在本医疗设备控制系统的控制模型中，动作属于第二层，每个动作都具有相对独立和完整的功能，动作的划分应当具有独立的意义，遵循高内聚低耦合原则，以减少动作实例间的协作。动作分为若干类，通过动作标识区分。动作是一个抽象概念，而动作实例是动作的一次具体执行过程。动作和动作实例的关系类似于类和对象的关系。动作分为同步和异步两类。动作实例具有唯一标识。同步动作运行于创建调用线程中，异步动作运行于独立线程中。

以血液分析仪为例，命令为测量命令，表示对指定的样本进行测量。状态机根据配置信息将该命令拆分为上样动作和采样动作，并顺序调用。上样动作实现找到指定样本，并将样本混匀后移动至合适的位置，保证系统可以正确的吸取样本。使用的资源包括电机、光耦、事件信号量等，使用的资源通过指令调用。在测量命令中，上样动作完成后，将执行采样动作，采样动作实现吸取样本，传递到流动室，采集样本参数。

在其中一个实施例中，动作管理模块132包括动作创建模块，动作创建模块用于接收动作创建请求，根据预设逻辑创建相应的动作实例，并开始执行。动作实例创建时，需要将动作实例使用的预设的参数以统一的方式传递给动作实例。参数以通用的方式定义，创建动作实例的接口不需要了解参数的语义，动作实例内部理解。动作实例可以创建子动作实例。统一的方式是指通过一致的接口调用，可以是一组类形式的接口或函数形式的接口。

动作实例间存在协作关系，包括互斥和同步。动作实例间的互斥体现在对某个资源的访问，资源实现并发访问的安全性。动作实例间的同步用于实现逻辑上的协作，通过事件完成。在动作实例创建时，提供动作实例需要使用的参数，其中包括动作实例需要使用的资源标识。动作实例通过资源管理器，以资源标识获得对应的功能实例，并访问这些协作资源，不需要了解在与哪个具体的动作实例协作，只需要访问协作资源，按照预计的方式协作即可。动作实例执行完毕后，需要进行销毁。对于同步动作实例，执行后，动作管理器直接删除。对于异步动作实例，执行后，通过事件进行异步删除。

动作扩展模块134，用于提供动作扩展机制。所有的动作都封装在动作动态链接库中，并通过动作扩展模块134的动作扩展机制以动态链接库的方式集成到系统中。动作扩展模块134根据配置文件获得动作的动作标识与动态链接库的对应关系，并加载合适的动作动态链接库。动作管理模块132可以通过动作扩展模块134提供的动作扩展机制创建动作实例。动作实例通过资源访问接口访问资源，其结构如图5所示。

动作动态链接库的接口定义包括一个动作实例创建接口和一个统一的动作实例访问接口。一个典型的接口定义如下：

Class ActionFactory{AbstractActionInstance*CreateActionInstance(ActionID，Param)；｝；

Class AbstractActionInstance{ActionResult Run(Param)；｝；

对于不同的医疗设备，需要执行的动作千差万别，对于同类的设备，其控制逻辑也会随着应用场景的不同而有很大差别。这就要求系统提供扩展控制逻辑的机制。在本实施例中，通过动作扩展槽，提供动作的扩展能力。

在其中一个实施例中，通过可视化的动作编辑工具进行创建和修改。通过可视化工具以拖拽方式表达动作逻辑，并自动生成动态链接库。该工具提供访问资源的表达方法，并自动实现访问系统资源访问接口的功能。动作的设计原则：具有完备的逻辑，相对独立，利于重用和测试。尽量减少动作执行过程中与其他动作的协作。动作的组合逻辑由状态机在解析和执行事件时实现。通过上述机制，能够将易变的动作控制逻辑从软件系统中剥离出来，并通过辅助的可视化动作编辑工具，灵活地调整动作中的控制逻辑，在系统研发过程中能够起到封装变化点，使软件系统与动作分别开发、测试的效果，能够大大提高系统的开发效率和质量。

在其中一个实施例中，以血液分析仪为例，测量命令由上样动作和采样动作实现。上样动作和采样动作间存在同步关系，当上样动作完成后，才能开始采样动作的采集逻辑。否则无法采集到正确的信号。在配置中，定义采样动作所在的动态链接库为Sample.dll，需要创建采样动作实例时，读取配置，加载Sample.dll，并按照标准接口创建该动作实例并调用接口开始执行。通过可视化编辑工具，可以独立地修改采样动作的逻辑，并生成新版的Sample.dll，系统不需要更改，再次启动时，会使用新版本的Sample.dll。

动作异常处理模块136，根据提供动作实例执行中发生异常后的处理方法。动作实例执行中，当发生异常时，需要进行相应的处理。在其中一个实施例中，该处理方法的流程如图6所示，包括异常上报、故障判定、故障即时处理、故障分析、故障状态切换、故障整机处理、用户干预修复、故障消除、故障信息的记录和发布。在故障处理的不同阶段，都可以记录和发布故障信息。故障信息可以包括故障类型、发生场景、以及各种详细信息，如，系统电压参数等。

异常是指系统发生的不正常情况，如硬件器件指令返回结果错误，计算结果偏出正常范围等，异常具有唯一标识。

故障是指系统发生了错误，由异常产生，但异常可能不是故障。故障具有唯一标识。

场景是指软硬件当前运转所处的情况。场景包括用户权限、状态机状态、动作和子动作调用路径等。

判定异常是否是故障，需要根据场景来决定。

故障树是指根据场景决策异常是否是故障、是哪个故障的树形数据结构。该数据结构中，树的分支表示场景，第一层节点表示用户权限、第二层节点表示状态，后续节点表示动作和子动作调用路径，叶节点表示对应的故障。当发生异常时，根据当前场景在故障树中遍历，如果没有匹配的树分枝则认为不产生故障，如果找到匹配树分枝则返回叶节点表示的故障。

故障即时处理是指故障发生时，在该动作实例所处的场景中，立即执行的故障修复子动作。运行于发生异常动作实例所处的线程中，并返回处理结果，可根据执行结果选择继续执行或中断上报异常。在故障即时处理动作中不产生新故障。故障的即时处理能够保证在发生故障所处场景中及时地进行针对性处理，提高了处理故障的效率和质量。

故障分析是指系统记录运行过程中发生的历史故障信息，并根据规则判断是否产生新故障。如，系统连续多次发生同一类型的小故障，都被即时处理动作修复，但多次发生意味着相关器件可能存在隐患，可以通过产生新故障，提示用户进行更换。

故障状态切换是指整个系统需要进入故障状态，停止当前正常动作实例。是否进入故障状态根据故障类型和故障即时处理结果决定。进入故障状态，不能直接中断所有正在执行的其他动作实例，而是通过发布事件，通知系统要进入故障状态，状态机将设置进入故障标识，所有动作实例在运行过程中，根据需要检测该标识，当确认系统需要进入故障时，尽快停止自己的后续逻辑。当所有动作实例都停止后，系统切入故障状态。在获知故障标识后，动作实例可以查询故障信息，并根据需要判断如何结束。

故障整机处理是指系统在进入故障状态后，执行的故障修复动作，此时只有故障整机处理动作在执行。整机处理成功时，系统将自动恢复，退出故障状态，否则保持故障状态，等待用户干预。在故障整机处理动作中不产生新故障。

用户干预修复是指系统无法自我恢复，用户进行人工干预的过程。

故障消除是指用户干预修复后，认为故障已经人工排除，系统可以进入正常状态，此时，用户指示系统再次尝试修复，通常是一个系统自检的过程。

上述流程具有多变性和不确定性，因此需要以配置方式管理。配置定义包括异常标识定义、场景信息定义、故障标识定义、故障树定义、故障即时处理动作、故障整机处理动作、提示信息和故障消除处理动作。用户可以通过异常标识定义、场景信息定义、故障标识定义、故障树定义设计系统需要响应的异常情况，并通过动作扩展槽自定义故障即时处理动作、故障整机处理动作和故障消除动作。在上述异常处理过程中，相关动作需要使用各种资源，特别是需要通过故障信息管理器资源对整个系统故障相关信息进行管理。

通过上述异常判定和故障处理机制，能够最大限度地降低系统发生异常时对用户的依赖程度，通过设计完善的处理动作，不仅能够在异常发生的场景中进行针对性处理，同时能够协调整个系统进行故障排除，能够有效地提高系统的可靠性，改善用户体验。通过配置和动作扩展机制，能够较好地完成系统处理能力的提升和改进，提高了研发、实施和维护的效率和质量。

在其中一个实施例中，以血液分析仪为例，在采样动作中，样本液体将流过流动室，可能发生堵孔异常，对该异常利用动作异常处理模块136进行处理。在异常配置文件中，定义了堵孔异常编号、堵孔故障场景判定树、堵孔故障编号、堵孔故障即时处理动作、堵孔故障整机处理动作、提示信息和堵孔故障消除处理动作。实现了堵孔故障即时处理动作、堵孔故障整机处理动作和故障消除处理动作的动态链接库，并通过动作扩展槽集成到系统中。在堵孔故障即时处理动作中，自定义了故障处理逻辑：增大液体流量，冲洗小孔。在堵孔故障整机处理动作中，自定义了处理逻辑：暂停采样，从清洗液池中吸取大量液体，冲洗小孔。在提示信息中，自定义了提示用户：流动室孔堵塞，请维修。在堵孔故障消除处理动作中，自定义了处理逻辑：初始化流动室部的所有硬件，吸取清洗液，验证故障是否排除。

资源管理模块140，用于为动作实例提供资源访问接口，并实现资源的功能。资源访问接口为资源的访问接口。管理软件资源和硬件资源，对上层提供资源访问接口。资源定义为具有强相关性的功能单元，能够对外提供相对独立和单一的功能，如电机控制器、日志等。资源分为软件资源和硬件资源。资源设计和实现的目标是提供相对独立，可重用，易测试的功能集合。硬件资源是依赖于硬件器件提供功能实现的资源，是对硬件器件提供功能的抽象和封装，提供同步访问接口，记录硬件器件的状态。对上层提供了访问硬件器件的接口，依赖于硬件代理访问具体的硬件器件。硬件资源采用基于执行结果的控制方式，即每个控制指令都会返回执行结果。硬件资源实现了上层软件与硬件器件具体控制方式的分离。软件资源是相对于硬件资源而定义的，是指不依赖于硬件器件的功能单元，只依赖于操作系统和软件实现。

在其中一个实施例中，参见图7，资源管理模块140包括资源访问接口模块142、软件资源模块144和硬件资源模块146。

资源访问接口模块142，用于提供资源访问接口。该模块用于提供资源访问的接口，隐藏资源的具体实现。资源访问接口分为：查询接口、控制接口、通知接口和等待接口。所有接口都是同步方式，不支持异步。查询接口用于获取指定信息。控制接口用于调用指定功能。通知接口用于发布指定信息。等待接口用于同步等待指定信息。一个典型的动作，通过查询接口获得需要的配置信息或系统状态，通过控制接口控制电机等器件运转，在执行到特定状态时，通过通知接口发布动作执行状态信息，当需要接收外部信息时，通过等待接口同步等待该信息。对动作可见的只是相对稳定的资源访问接口，该接口隐藏了资源的具体实现方法；当资源的具体实现发生变化时，动作不需要感知，节约了维护成本；否则资源实现改变，动作就要改变，那会带来巨大的维护成本。比如电机硬件资源接口，抽象为开启、运动100步、关闭，三个功能接口，可以通过CAN协议控制电机，也可以通过SPI协议控制，还可以根据其他协议控制，那么这种变化就不需要让资源的使用者感知。

通过以资源的方式对不同功能点进行封装，并通过统一的资源访问接口供其他功能模块使用，能够将复杂度进行分离。可以在研发过程中，针对不同的资源进行相对独立的开发和测试。在跨产品的研发过程中，能够积累不同类型的资源，形成资源库，在开发或改进产品时进行重用，达到提高研发效率和质量的目标。

软件资源模块144，用于实现软件资源的功能。软件资源包括网络、消息泵、配置中心、事件信号量等。软件资源分为：

操作系统类软件资源：对操作系统API(Application Programming Interface应用程序编程接口)功能的封装和管理，如事件信号量、计时器、线程等。

功能类软件资源：是对若干功能的封装，如消息泵、日志、配置信息、故障信息管理器、事件发布器、专业算法集、动作监听器。其中，故障信息管理器负责管理整个系统的故障信息，如当前故障队列、历史故障信息等。

通信软件资源：提供系统对外的交互接口，如网络，FPGA等。

硬件资源模块146，用于实现硬件资源的功能。硬件资源包括电机、传感器、光耦、阀等。硬件资源实现的功能包括查询、监控、控制等。

基础功能模块150，用于支持实现所述资源。参见图8，具体的，基础功能模块150可以包括网络模块152、文件模块154和硬件代理模块156。

网络模块152，用于实现网络收发功能。在其中一个实施例中，网络收发功能可以是基于TCP/IP协议的网络收发功能。

文件模块154，用于实现文件的读写功能。

硬件代理模块156，用于实现对硬件器件的访问的功能。基于操作系统驱动层的硬件控制接口和协议，实现同步或异步的硬件器件控制功能，包括CAN代理、FPGA代理等。

基础功能模块150同时实现了对操作系统和具体协议的封装，能够避免上层功能模块对操作系统和具体协议的依赖，使他们能够集中解决具体的应用逻辑。通过积累不同操作系统和协议的具体实现，可以在不同产品实施过程中进行重用。

上述实施例的医疗设备控制系统可以应用在具体的医疗设备中，针对不同医疗设备进行适应性开发后即可实现完整的控制软件系统。基于对不同医疗设备控制需求共性和易变因素的分析和梳理，在本系统中封装通用和抽象的系统控制逻辑，并根据具体需求对可变因素进行调整，为复杂医疗设备的开发提供支持，达到简化开发过程、降低开发难度、提供开发效率和质量的目的。

在一实施例中，一个典型的医疗设备硬件结构如图9所示，通常医疗设备包括控制类器件、采集类器件、通信类器件、监测类器件和存储类器件，以及运行软件控制系统的基础硬件平台。控制类器件实现医疗设备采集数据所需的环境，如电机、阀等。采集类器件实现有效信号的采集，如AD传感器等。监控类器件实现对整个系统硬件运行状态的监控，如电压监控器件。通信类器件实现与其他系统的通信，如网络、串口等。存储类器件实现数据的存储，如DDR、SD卡等。软件控制系统需要按照医疗设备的目标，协调上述硬件，完成有效数据的采集。通过通信类器件，接收控制指令。解析指令，协调控制类器件构造合适的环境。达到条件后，协调采集类器件采集数据。获取的数据，以及运行中的数据，通过存储类器件进行保存。通过通信类器件，将执行结果和采集数据发送给控制端。在上述过程中，通过监控类器件监控整个系统的运行状况。医疗设备控制系统是实现上述过程的核心。

以血液分析仪为例。状态管理模块120中状态机定义为：

状态：开机准备状态、待机状态、运转状态、休眠状态、故障状态、调试状态、维护状态、退出状态。

变迁：系统启动进入开机准备状态，完成后进入待机状态。待机接收到测量命令后切换为运转状态。测量完成后切换为待机状态。测量中发生无法修复的故障时，转换为故障状态。故障状态中，故障消除后切换为待机状态。系统收到休眠命令后进入休眠状态。系统收到调试命令后进入调试状态。系统收到维护命令后进入维护状态。系统收到关机命令后进入退出状态。

上述信息通过配置文件进行定义，系统读取配置中的信息后，建立状态机和转换关系。

动作管理和执行模块130中测量命令表示对指定的样本进行测量。状态机根据配置信息该命令拆分为上样动作和采样动作，并顺序调用。状态机收到测量命令后，执行上样动作。上样动作是指实现找到指定样本，并将样本混匀后移动至合适的位置，保证系统可以正确的吸取样本。以动态链接库方式实现，并集成到系统中，其处理逻辑由独立的可视化工具进行编辑。使用的资源包括电机、光耦、事件信号量，资源访问接口由资源管理模块140提供。

动作管理和执行模块130在测量命令中，上样动作完成后，将执行采样动作。其中采样动作是指实现吸取样本，传递到流动室，采集样本参数。以动态链接库方式实现，并集成到系统中，其处理逻辑由独立的可视化工具进行编辑。

在采样动作中，样本液体将流过流动室，可能发生堵孔异常，对该异常利用动作异常处理模块136进行处理。在异常配置文件中，定义了堵孔异常编号、堵孔故障场景判定树、堵孔故障编号、堵孔故障即时处理动作、堵孔故障整机处理动作、提示信息和堵孔故障消除处理动作。实现了堵孔故障即时处理动作、堵孔故障整机处理动作和故障消除处理动作的动态链接库，并通过动作扩展槽集成到系统中。在堵孔故障即时处理动作中，自定义了故障处理逻辑：增大液体流量，冲洗小孔。在堵孔故障整机处理动作中，自定义了处理逻辑：暂停采样，从清洗液池中吸取大量液体，冲洗小孔。在提示信息中，自定义了提示用户：流动室孔堵塞，请维修。在堵孔故障消除处理动作中，自定义了处理逻辑：初始化流动室部的所有硬件，吸取清洗液，验证故障是否排除。

图10为一实施方式的医疗设备控制方法，本实施例可以应用在具体的医疗设备中，针对不同医疗设备进行适应性开发后即可实现完整的控制软件系统。如图10所示，本实施例的医疗设备控制方法的具体步骤如下：

S110，接收事件，并分发事件。在分发事件时，可以基于预设信息进行事件的分发。事件的兴趣可以根据实际需要进行划分。接收到的事件为多个，可以通过事件队列实现事件的异步发送。参见图11，在其中一个实施例中，步骤S110包括步骤S112和步骤S114。

S112，接收、分发事件。用于实现事件接收和分发功能。事件接收过程通过同步接口接收事件，并将事件保存在事件队列中，运行于调用线程中。事件分发过程运行于独立的线程中，通常是系统的主线程。从事件队列中依次读取事件，并转发给事件处理实例。在其中一个实施例中，转发过程可以按照兴趣进行。

S114，管理事件处理实例，提供基于预设信息的注册和注销方法。事件处理实例需要通过注册方法提交自己感兴趣的事件类型，同时提交接收事件的回调接口。事件处理实例可以是状态机、动作管理器和软件资源。在其中一个实施例中，动作通过软件资源进行事件的发布和处理；动作管理器处理异步动作的结束通知，用于删除动作实例。事件处理实例提供同步接口，事件分发时调用该接口，在该接口实现中，可以实现同步事件处理和异步事件处理。

事件的兴趣可以根据实际需要进行划分。从软件系统是否理解事件语义的角度，可以初步划分为软件事件和扩展事件两类，其中软件事件是软件控制系统需要理解语义并进行处理的事件。扩展事件是软件控制系统不需要理解的事件，这类事件由自定义动作使用，软件控制系统只提供发布和转发该类事件的通用方法。事件所携带参数在转发过程完毕后进行释放。通过上述事件调度机制，在系统内建立了灵活的协作方式，在实施过程中，能够容易地扩展动作间的协作，使本软件控制系统，能够适用于各种应用场景中。

在其中一个实施例中，以血液分析仪为例，事件包括开始测量、测量结束、发生堵孔故障、上样动作完成等。状态机模块对开始测量、测量结束、发生堵孔故障等事件感兴趣，向事件接收/分发模块注册；采样动作对上样动作完成事件感兴趣，向事件接收/分发模块注册。当上述事件发生时，根据注册兴趣信息，进行转发。其中，开始测量、测量结束、发生堵孔故障事件属于软件事件，上样动作完成事件属于扩展事件。

S120，接收分发的事件，根据事件和当前的状态信息变迁或维持状态信息，并根据配置定义的规则处理事件。步骤S120用于管理设备的状态信息，并根据当前状态判定接收到事件后的行为，定义了在不同场景下，系统如何运转。在其中一个实施例中，参见图12，步骤S120包括步骤S122、步骤S124和步骤S126。

S122，实现系统软件初始化/反初始化、功能实例生存期管理的功能。较优的，还可以实现软件系统进入和退出工作状态。

S124，保存设备的状态信息，并接收事件，根据当前的状态信息，以及配置定义的规则处理事件，事件通过相应的动作实例实现。根据当前的状态信息对事件进行响应。较优的，状态机不保存除状态外的其他信息。根据当前的状态信息对事件进行响应表现为创建、控制动作，忽略事件，记录日志等。

在其中一个实施例中，事件分为命令和通知，命令用于表示系统定义的具有独立意义的功能，通知是动作实例执行过程中产生的信息，用于动作实例管理、协作和产生新的命令。其中，动作管理包括已有动作的销毁和创建新动作。事件可以引发状态的变迁。事件的发送和处理通过事件调度模块完成，这个过程是基于预设信息的。

状态机模块封装了处理事件的通用逻辑，包含了如何根据规则将命令分解为动作，并按照规则中的定义的顺序调用。规则定义了事件的具体处理逻辑，是易变的；通用逻辑是稳定的，实现了读取、解析和执行规则。规则包括当前状态和事件语义。规则可以由配置表达，定义为Action＝f(Status，Event)。一个典型的状态机包括开机准备状态、待机状态、运转状态、休眠状态、故障状态、调试状态、维护状态、退出状态。为了简化控制，不采用多级状态机，所有状态都属于一层。通过配置表达的规则描述每个状态能够处理的命令，以及每个命令分解为哪些动作和动作调用顺序。软件系统实现通用的逻辑，通过该配置获得每个状态的行为逻辑。在实施过程中，不仅能够通过配置表达的规则灵活地扩展状态机的行为，也可以基于上述逻辑，对某个事件的处理逻辑进行扩展。

在其中一个实施例中，状态机模块封装了处理事件的通用逻辑。事件可以通过执行一个或多个动作实例来处理。通过配置来定义每个状态能够处理的事件，以及事件被拆分为哪些动作和拆分后动作的调用顺序，这些逻辑是易变的；而解析配置，执行配置中定义的动作，是通用而稳定的逻辑。状态机模块实现了上述通用的逻辑，包含读取配置，解析配置，调用动作管理模块创建和执行动作实例。在实施过程中，不仅能够通过配置灵活地扩展状态机的行为，也可以对某个事件的处理逻辑进行扩展。

S126，保存状态关系的信息，根据事件和状态关系变迁或维持状态信息。步骤S126从步骤S124接收事件，并根据规则定义是否发生状态变迁。若发生状态变迁，则相应的变迁状态信息，若未发生状态变迁，则不变迁状态信息，即维持状态信息。状态变迁的规则可以包含一系列事件，可以定义为Status＝f(Status，Set(Event，TimeTag))，其中Set(Event，TimeTag)是一组具有时间顺序关系的事件集合，该集合综合发生作用，该集合可以包括一个或多个事件。事件包含优先级属性，用于定义事件预计的发生顺序。属于一个事件集合的事件在判定转换规则时，可以依赖时间顺序，也可以不依赖时间顺序，当依赖时间顺序时，根据TimeTag和事件的优先级属性综合决策。通过上述机制，能够建立较灵活的状态机管理方法，能够根据实施中的需要，以配置的方式快速而高质量地调整状态机的行为，能够有效提高开发效率和质量。

在其中一个实施例中，以血液分析仪为例，典型的状态机包括开机准备状态、待机状态、运转状态、休眠状态、故障状态、调试状态、维护状态、退出状态。为了简化控制，不采用多级状态机，所有状态都属于一层。在配置中定义开机准备状态不处理任何命令，在待机状态能够接收并测量命令，测量命令定义为由上样动作和采样动作实现，调用顺序为上样动作前于采样动作。状态机模块解析该配置，当收到测量命令后，创建上样动作实例、采样动作实例，并依次调用。步骤S126定义了状态转移关系，如，开机准备状态在完成所有初始化动作后，切换为待机状态；待机状态下，收到测量命令并开始执行时，切换为运转状态。

S130，创建、调度和执行动作实例，并提供动作扩展机制。在其中一个实施例中，参见图13，步骤S130包括步骤S132、步骤S134和步骤S136。

S132，创建、删除、调度和执行动作实例。医疗设备控制方法的控制逻辑划分为三个层次：命令、动作和指令。命令是指系统定义的具有独立意义的功能，是系统对外体现的能力，由一个或多个动作协调完成。动作是一个或多个命令可使用的功能，具有完整性，系统外不可见，由一个或多个指令完成。指令是指某个资源能够完成的单一功能，如电机器件的运行指令。通过这三个层次的划分，将不同粒度的逻辑进行不同程度的划分和组织，使每层能够专注于解决一定范围的问题，能够降低设计和实现的复杂度，并实现较好地重用。在本医疗设备控制方法的控制模型中，动作属于第二层，每个动作都具有相对独立和完整的功能，动作的划分应当具有独立的意义，遵循高内聚低耦合原则，以减少动作实例间的协作。动作分为若干类，通过动作标识区分。动作是一个抽象概念，而动作实例是动作的一次具体执行过程。动作和动作实例的关系类似于类和对象的关系。动作分为同步和异步两类。动作实例具有唯一标识。同步动作运行于创建调用线程中，异步动作运行于独立线程中。

以血液分析仪为例，命令为测量命令，表示对指定的样本进行测量。状态机根据配置信息将该命令拆分为上样动作和采样动作，并顺序调用。上样动作实现找到指定样本，并将样本混匀后移动至合适的位置，保证系统可以正确的吸取样本。使用的资源包括电机、光耦、事件信号量等，使用的资源通过指令调用。在测量命令中，上样动作完成后，将执行采样动作，采样动作实现吸取样本，传递到流动室，采集样本参数。

在其中一个实施例中，接收动作创建请求，根据预设逻辑创建相应的动作实例，并开始执行。动作实例创建时，需要将动作实例使用的预设的参数以统一的方式传递给动作实例。参数以通用的方式定义，创建动作实例的接口不需要了解参数的语义，动作实例内部理解。动作实例可以创建子动作实例。统一的方式是指通过一致的接口调用，可以是一组类形式的接口或函数形式的接口。

动作实例间存在协作关系，包括互斥和同步。动作实例间的互斥体现在对某个资源的访问，资源实现并发访问的安全性。动作实例间的同步用于实现逻辑上的协作，通过事件完成。在动作实例创建时，提供动作实例需要使用的参数，其中包括动作实例需要使用的资源标识。动作实例通过资源管理器，以资源标识获得对应的功能实例，并访问这些协作资源，不需要了解在与哪个具体的动作实例协作，只需要访问协作资源，按照预计的方式协作即可。动作实例执行完毕后，需要进行销毁。对于同步动作实例，执行后，动作管理器直接删除。对于异步动作实例，执行后，通过事件进行异步删除。

S134，提供动作扩展机制。所有的动作都封装在动作动态链接库中，并通过步骤S134的动作扩展机制以动态链接库的方式集成到系统中。步骤S134根据配置文件获得动作的动作标识与动态链接库的对应关系，并加载合适的动作动态链接库。步骤S132可以通过步骤S134提供的动作扩展机制创建动作实例。动作实例通过资源访问接口访问资源，其结构如图5所示。

动作动态链接库的接口定义包括一个动作实例创建接口和一个统一的动作实例访问接口。一个典型的接口定义如下：

Class ActionFactory{

AbstractActionInstance*CreateActionInstance(ActionID，Param)；

｝；

Class AbstractActionInstance{

ActionResult Run(Param)；

｝；

对于不同的医疗设备，需要执行的动作千差万别，对于同类的设备，其控制逻辑也会随着应用场景的不同而有很大差别。这就要求系统提供扩展控制逻辑的机制。在本实施例中，通过动作扩展槽，提供动作的扩展能力。

在其中一个实施例中，通过可视化的动作编辑工具进行创建和修改。通过可视化工具以拖拽方式表达动作逻辑，并自动生成动态链接库。该工具提供访问资源的表达方法，并自动实现访问系统资源访问接口的功能。动作的设计原则：具有完备的逻辑，相对独立，利于重用和测试。尽量减少动作执行过程中与其他动作的协作。动作的组合逻辑由状态机在解析和执行事件时实现。通过上述机制，能够将易变的动作控制逻辑从软件系统中剥离出来，并通过辅助的可视化动作编辑工具，灵活地调整动作中的控制逻辑，在系统研发过程中能够起到封装变化点，使软件系统与动作分别开发、测试的效果，能够大大提高系统的开发效率和质量。

在其中一个实施例中，以血液分析仪为例，测量命令由上样动作和采样动作实现。上样动作和采样动作间存在同步关系，当上样动作完成后，才能开始采样动作的采集逻辑。否则无法采集到正确的信号。在配置中，定义采样动作所在的动态链接库为Sample.dll，需要创建采样动作实例时，读取配置，加载Sample.dll，并按照标准接口创建该动作实例并调用接口开始执行。通过可视化编辑工具，可以独立地修改采样动作的逻辑，并生成新版的Sample.dll，系统不需要更改，再次启动时，会使用新版本的Sample.dll。

S136，提供动作实例执行中发生异常后的处理方法。动作实例执行中，当发生异常时，需要进行相应的处理。在其中一个实施例中，该处理方法的流程如图6所示，包括异常上报、故障判定、故障即时处理、故障分析、故障状态切换、故障整机处理、用户干预修复、故障消除、故障信息的记录和发布。在故障处理的不同阶段，都可以记录和发布故障信息。故障信息可以包括故障类型、发生场景、以及各种详细信息，如，系统电压参数等。

异常是指系统发生的不正常情况，如硬件器件指令返回结果错误，计算结果偏出正常范围等，异常具有唯一标识。

故障是指系统发生了错误，由异常产生，但异常可能不是故障。故障具有唯一标识。

场景是指软硬件当前运转所处的情况。场景包括用户权限、状态机状态、动作和子动作调用路径等。

判定异常是否是故障，需要根据场景来决定。

故障树是指根据场景决策异常是否是故障、是哪个故障的树形数据结构。该数据结构中，树的分支表示场景，第一层节点表示用户权限、第二层节点表示状态，后续节点表示动作和子动作调用路径，叶节点表示对应的故障。当发生异常时，根据当前场景在故障树中遍历，如果没有匹配的树分枝则认为不产生故障，如果找到匹配树分枝则返回叶节点表示的故障。

故障即时处理是指故障发生时，在该动作实例所处的场景中，立即执行的故障修复子动作。运行于发生异常动作实例所处的线程中，并返回处理结果，可根据执行结果选择继续执行或中断上报异常。在故障即时处理动作中不产生新故障。故障的即时处理能够保证在发生故障所处场景中及时地进行针对性处理，提高了处理故障的效率和质量。

故障分析是指系统记录运行过程中发生的历史故障信息，并根据规则判断是否产生新故障。如，系统连续多次发生同一类型的小故障，都被即时处理动作修复，但多次发生意味着相关器件可能存在隐患，可以通过产生新故障，提示用户进行更换。

故障状态切换是指整个系统需要进入故障状态，停止当前正常动作实例。是否进入故障状态根据故障类型和故障即时处理结果决定。进入故障状态，不能直接中断所有正在执行的其他动作实例，而是通过发布事件，通知系统要进入故障状态，状态机将设置进入故障标识，所有动作实例在运行过程中，根据需要检测该标识，当确认系统需要进入故障时，尽快停止自己的后续逻辑。当所有动作实例都停止后，系统切入故障状态。在获知故障标识后，动作实例可以查询故障信息，并根据需要判断如何结束。

故障整机处理是指系统在进入故障状态后，执行的故障修复动作，此时只有故障整机处理动作在执行。整机处理成功时，系统将自动恢复，退出故障状态，否则保持故障状态，等待用户干预。在故障整机处理动作中不产生新故障。

用户干预修复是指系统无法自我恢复，用户进行人工干预的过程。

故障消除是指用户干预修复后，认为故障已经人工排除，系统可以进入正常状态，此时，用户指示系统再次尝试修复，通常是一个系统自检的过程。

上述流程具有多变性和不确定性，因此需要以配置方式管理。配置定义包括异常标识定义、场景信息定义、故障标识定义、故障树定义、故障即时处理动作、故障整机处理动作、提示信息和故障消除处理动作。用户可以通过异常标识定义、场景信息定义、故障标识定义、故障树定义设计系统需要响应的异常情况，并通过动作扩展槽自定义故障即时处理动作、故障整机处理动作和故障消除动作。在上述异常处理过程中，相关动作需要使用各种资源，特别是需要通过故障信息管理器资源对整个系统故障相关信息进行管理。

通过上述异常判定和故障处理机制，能够最大限度地降低系统发生异常时对用户的依赖程度，通过设计完善的处理动作，不仅能够在异常发生的场景中进行针对性处理，同时能够协调整个系统进行故障排除，能够有效地提高系统的可靠性，改善用户体验。通过配置和动作扩展机制，能够较好地完成系统处理能力的提升和改进，提高了研发、实施和维护的效率和质量。

在其中一个实施例中，以血液分析仪为例，在采样动作中，样本液体将流过流动室，可能发生堵孔异常，对该异常利用步骤S136进行处理。在异常配置文件中，定义了堵孔异常编号、堵孔故障场景判定树、堵孔故障编号、堵孔故障即时处理动作、堵孔故障整机处理动作、提示信息和堵孔故障消除处理动作。实现了堵孔故障即时处理动作、堵孔故障整机处理动作和故障消除处理动作的动态链接库，并通过动作扩展槽集成到系统中。在堵孔故障即时处理动作中，自定义了故障处理逻辑：增大液体流量，冲洗小孔。在堵孔故障整机处理动作中，自定义了处理逻辑：暂停采样，从清洗液池中吸取大量液体，冲洗小孔。在提示信息中，自定义了提示用户：流动室孔堵塞，请维修。在堵孔故障消除处理动作中，自定义了处理逻辑：初始化流动室部的所有硬件，吸取清洗液，验证故障是否排除。

S140，为动作实例提供资源访问接口，并实现资源的功能。资源访问接口为资源的访问接口。管理软件资源和硬件资源，对上层提供资源访问接口。资源定义为具有强相关性的功能单元，能够对外提供相对独立和单一的功能，如电机控制器、日志等。资源分为软件资源和硬件资源。资源设计和实现的目标是提供相对独立，可重用，易测试的功能集合。硬件资源是依赖于硬件器件提供功能实现的资源，是对硬件器件提供功能的抽象和封装，提供同步访问接口，记录硬件器件的状态。对上层提供了访问硬件器件的接口，依赖于硬件代理访问具体的硬件器件。硬件资源采用基于执行结果的控制方式，即每个控制指令都会返回执行结果。硬件资源实现了上层软件与硬件器件具体控制方式的分离。软件资源是相对于硬件资源而定义的，是指不依赖于硬件器件的功能单元，只依赖于操作系统和软件实现。

在其中一个实施例中，参见图14，步骤S140包括步骤S142、步骤S144和步骤S146。

S142，提供资源访问接口。该步骤用于提供资源访问的接口，隐藏资源的具体实现。资源访问接口分为：查询接口、控制接口、通知接口和等待接口。所有接口都是同步方式，不支持异步。查询接口用于获取指定信息。控制接口用于调用指定功能。通知接口用于发布指定信息。等待接口用于同步等待指定信息。一个典型的动作，通过查询接口获得需要的配置信息或系统状态，通过控制接口控制电机等器件运转，在执行到特定状态时，通过通知接口发布动作执行状态信息，当需要接收外部信息时，通过等待接口同步等待该信息。对动作可见的只是相对稳定的资源访问接口，该接口隐藏了资源的具体实现方法；当资源的具体实现发生变化时，动作不需要感知，节约了维护成本；否则资源实现改变，动作就要改变，那会带来巨大的维护成本。比如电机硬件资源接口，抽象为开启、运动100步、关闭，三个功能接口，可以通过CAN协议控制电机，也可以通过SPI协议控制，还可以根据其他协议控制，那么这种变化就不需要让资源的使用者感知。

通过以资源的方式对不同功能点进行封装，并通过统一的资源访问接口供其他功能模块使用，能够将复杂度进行分离。可以在研发过程中，针对不同的资源进行相对独立的开发和测试。在跨产品的研发过程中，能够积累不同类型的资源，形成资源库，在开发或改进产品时进行重用，达到提高研发效率和质量的目标。

S144，实现软件资源的功能。软件资源包括网络、消息泵、配置中心、事件信号量等。软件资源分为：

操作系统类软件资源：对操作系统API(Application Programming Interface应用程序编程接口)功能的封装和管理，如事件信号量、计时器、线程等。

功能类软件资源：是对若干功能的封装，如消息泵、日志、配置信息、故障信息管理器、事件发布器、专业算法集、动作监听器。其中，故障信息管理器负责管理整个系统的故障信息，如当前故障队列、历史故障信息等。

通信软件资源：提供系统对外的交互接口，如网络，FPGA等。

S146，实现硬件资源的功能。硬件资源包括电机、传感器、光耦、阀等。硬件资源实现的功能包括查询、监控、控制等。

S150，支持实现资源。参见图15，具体的，步骤S150可以包括步骤S152、步骤S154和步骤S156。

S152，实现网络收发功能。在其中一个实施例中，网络收发功能可以是基于TCP/IP协议的网络收发功能。

S154，实现文件的读写功能。

S156，实现对硬件器件的访问的功能。基于操作系统驱动层的硬件控制接口和协议，实现同步或异步的硬件器件控制功能，包括CAN代理、FPGA代理等。

步骤S150同时实现了对操作系统和具体协议的封装，能够避免上层功能模块对操作系统和具体协议的依赖，使他们能够集中解决具体的应用逻辑。通过积累不同操作系统和协议的具体实现，可以在不同产品实施过程中进行重用。

上述实施例的医疗设备控制方法可以应用在具体的医疗设备中，针对不同医疗设备进行适应性开发后即可实现完整的控制软件系统。基于对不同医疗设备控制需求共性和易变因素的分析和梳理，在本方法中封装通用和抽象的系统控制逻辑，并根据具体需求对可变因素进行调整，为复杂医疗设备的开发提供支持，达到简化开发过程、降低开发难度、提供开发效率和质量的目的。

在一实施例中，一个典型的医疗设备硬件结构如图9所示，通常医疗设备包括控制类器件、采集类器件、通信类器件、监测类器件和存储类器件，以及运行软件控制系统的基础硬件平台。控制类器件实现医疗设备采集数据所需的环境，如电机、阀等。采集类器件实现有效信号的采集，如AD传感器等。监控类器件实现对整个系统硬件运行状态的监控，如电压监控器件。通信类器件实现与其他系统的通信，如网络、串口等。存储类器件实现数据的存储，如DDR、SD卡等。软件控制系统需要按照医疗设备的目标，协调上述硬件，完成有效数据的采集。通过通信类器件，接收控制指令。解析指令，协调控制类器件构造合适的环境。达到条件后，协调采集类器件采集数据。获取的数据，以及运行中的数据，通过存储类器件进行保存。通过通信类器件，将执行结果和采集数据发送给控制端。在上述过程中，通过监控类器件监控整个系统的运行状况。医疗设备控制方法是实现上述过程的核心。

以血液分析仪为例。步骤S120中状态机定义为：

状态：开机准备状态、待机状态、运转状态、休眠状态、故障状态、调试状态、维护状态、退出状态。

变迁：系统启动进入开机准备状态，完成后进入待机状态。待机接收到测量命令后切换为运转状态。测量完成后切换为待机状态。测量中发生无法修复的故障时，转换为故障状态。故障状态中，故障消除后切换为待机状态。系统收到休眠命令后进入休眠状态。系统收到调试命令后进入调试状态。系统收到维护命令后进入维护状态。系统收到关机命令后进入退出状态。

上述信息通过配置文件进行定义，系统读取配置中的信息后，建立状态机和转换关系。

步骤S130中测量命令表示对指定的样本进行测量。状态机根据配置信息将该命令拆分为上样动作和采样动作，并顺序调用。状态机收到测量命令后，执行上样动作。上样动作是指实现找到指定样本，并将样本混匀后移动至合适的位置，保证系统可以正确的吸取样本。以动态链接库方式实现，并集成到系统中，其处理逻辑由独立的可视化工具进行编辑。使用的资源包括电机、光耦、事件信号量，资源访问接口由步骤S140提供。

步骤S130在测量命令中，上样动作完成后，将执行采样动作。其中采样动作是指实现吸取样本，传递到流动室，采集样本参数。以动态链接库方式实现，并集成到系统中，其处理逻辑由独立的可视化工具进行编辑。

在采样动作中，样本液体将流过流动室，可能发生堵孔异常，对该异常利用步骤S136进行处理。在异常配置文件中，定义了堵孔异常编号、堵孔故障场景判定树、堵孔故障编号、堵孔故障即时处理动作、堵孔故障整机处理动作、提示信息和堵孔故障消除处理动作。实现了堵孔故障即时处理动作、堵孔故障整机处理动作和故障消除处理动作的动态链接库，并通过动作扩展槽集成到系统中。在堵孔故障即时处理动作中，自定义了故障处理逻辑：增大液体流量，冲洗小孔。在堵孔故障整机处理动作中，自定义了处理逻辑：暂停采样，从清洗液池中吸取大量液体，冲洗小孔。在提示信息中，自定义了提示用户：流动室孔堵塞，请维修。在堵孔故障消除处理动作中，自定义了处理逻辑：初始化流动室部的所有硬件，吸取清洗液，验证故障是否排除。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来控制相关的硬件来完成的程序，可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

以上实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (18)

1.一种医疗设备控制系统，其特征在于，包括：

事件调度模块，用于接收事件，并分发所述事件；

状态管理模块，用于接收分发的所述事件，根据所述事件和当前的状态信息变迁或维持所述状态信息，并根据配置定义的规则处理所述事件；

动作管理和执行模块，用于创建、调度和执行动作实例，并提供动作扩展机制；

资源管理模块，用于为所述动作实例提供资源访问接口，并实现资源的功能；

基础功能模块，用于支持实现所述资源。

2.根据权利要求1所述的医疗设备控制系统，其特征在于，所述状态管理模块包括：

系统管理模块，用于实现系统软件初始化/反初始化、功能实例生存期管理的功能；

状态机模块，用于保存设备的所述状态信息，并接收所述事件，根据当前的所述状态信息，以及所述配置定义的规则处理所述事件，所述事件通过相应的所述动作实例实现；

状态关系管理模块，用于保存状态关系的信息，根据所述事件和所述状态关系变迁或维持所述状态信息。

3.根据权利要求1所述的医疗设备控制系统，其特征在于，所述事件包括命令和通知；

所述命令用于表示系统定义的具有独立意义的功能；

所述通知为动作实例执行过程中产生的信息，用于动作实例管理、协作和产生新的命令。

4.根据权利要求1所述的医疗设备控制系统，其特征在于，所述动作管理和执行模块包括：

动作管理模块，用于创建、删除、调度和执行所述动作实例；

动作扩展模块，用于提供动作扩展机制；

动作异常处理模块，用于提供所述动作实例执行中发生异常后的处理方法。

5.根据权利要求4所述的医疗设备控制系统，其特征在于，所述动作扩展机制支持可视化的编辑和扩展。

6.根据权利要求4所述的医疗设备控制系统，其特征在于，所述动作扩展模块通过所述动作扩展机制以动态链接库的方式集成；所述动作扩展模块还用于根据配置文件加载有效的所述动态链接库。

7.根据权利要求4所述的医疗设备控制系统，其特征在于，所述动作异常处理模块中，所述处理方法包括异常上报、故障判定、故障即时处理、故障分析、故障状态切换、故障整机处理、用户干预修复、故障消除和故障信息的记录和发布中的一种或多种组合，所述故障信息的记录和发布的步骤与所述处理方法中任一其他步骤同步执行；

所述处理方法以配置方式管理，所述配置方式的配置定义包括异常标识定义、场景信息定义、故障标识定义、故障树定义、故障即时处理动作、故障整机处理动作，以及提示信息和故障消除处理动作。

8.根据权利要求1所述的医疗设备控制系统，其特征在于，所述资源访问接口实现所述动作实例与系统的协作；所述资源访问接口包括用于获取信息的查询接口、用于调用功能的控制接口、用于发布信息的通知接口和用于同步等待信息的等待接口。

9.根据权利要求1所述的医疗设备控制系统，其特征在于，所述资源包括软件资源和硬件资源；所述硬件资源是依赖于硬件器件提供功能实现的资源；所述软件资源是依赖于操作系统和软件实现的资源；

资源管理模块包括：

资源访问接口模块，用于提供资源访问接口；

软件资源模块，用于实现所述软件资源的功能；

硬件资源模块，用于实现所述硬件资源的功能。

10.根据权利要求9所述的医疗设备控制系统，其特征在于，所述软件资源包括操作系统类软件资源、功能类软件资源和通信软件资源；

所述操作系统类软件资源，用于对操作系统的应用程序编程接口的功能的封装和管理；

所述功能类软件资源，用于对所述操作系统的应用程序编程接口的功能之外的其他功能的封装；

所述通信软件资源，用于提供系统对外的交互接口。

11.根据权利要求9所述的医疗设备控制系统，其特征在于，所述硬件资源模块对所述硬件器件提供功能进行抽象和封装，提供同步访问接口，记录所述硬件器件的状态。

12.根据权利要求1所述的医疗设备控制系统，其特征在于，所述事件调度模块基于预设信息进行所述事件的分发；并通过事件队列实现所述事件的异步发送。

13.根据权利要求1所述的医疗设备控制系统，其特征在于，所述基础功能模块包括：

网络模块，用于实现网络收发功能；

文件模块，用于实现文件的读写功能；

硬件代理模块，用于实现对硬件器件的访问的功能。

14.根据权利要求13所述的医疗设备控制系统，其特征在于，所述硬件代理模块基于操作系统驱动层的硬件控制接口和协议，实现同步或异步的控制所述硬件器件的功能。

15.一种医疗设备控制方法，其特征在于，包括：

接收事件，并分发所述事件；

接收分发的所述事件，根据所述事件和当前的状态信息变迁或维持所述状态信息，并根据配置定义的规则处理所述事件；

创建、调度和执行动作实例，并提供动作扩展机制；

为所述动作实例提供资源访问接口，并实现资源的功能；

支持实现所述资源。

16.根据权利要求15所述的医疗设备控制方法，其特征在于，所述接收分发的所述事件，根据所述事件和当前的状态信息变迁或维持所述状态信息，并根据配置定义的规则处理所述事件的步骤，包括：

实现系统软件初始化/反初始化、功能实例生存期管理的功能；

保存设备的所述状态信息，并接收所述事件，根据当前的所述状态信息，以及所述配置定义的规则处理所述事件，所述事件通过相应的所述动作实例实现；

保存状态关系的信息，根据所述事件和所述状态关系变迁或维持所述状态信息。

17.根据权利要求15所述的医疗设备控制方法，其特征在于，所述创建、调度和执行动作实例，并提供动作扩展机制的步骤，包括：

创建、删除、调度和执行所述动作实例；

提供所述动作扩展机制；

提供所述动作实例执行中发生异常后的处理方法。

18.根据权利要求15所述的医疗设备控制方法，其特征在于，所述资源包括软件资源和硬件资源；所述硬件资源是依赖于硬件器件提供功能实现的资源；所述软件资源是依赖于操作系统和软件实现的资源；

所述为所述动作实例提供资源访问接口，并实现资源的功能的步骤，包括：

提供资源访问接口；

实现所述软件资源的功能；

实现所述硬件资源的功能。