Operating medical devices during startup and shutdown

Abstract

A medical device includes a software (SW) system executed by a processor. The SW system defines a plurality of subsystems, including a main subsystem and one or more auxiliary subsystems, and each subsystem includes a SW application involved in the operation of the medical device during a medical procedure. Deterministic distributed startup of the SW system is achieved by dividing the startup procedure into a subsystem-level startup preparation and a system-level startup preparation using two different notifications, in which the main subsystem coordinates the startup of the subsystem. The method includes: starting (401) each SW application; when ready to start, each SW application in the corresponding auxiliary subsystem provides (402) an "application ready" notification; when all SW applications of the corresponding auxiliary subsystem have provided the "application ready" notification, the corresponding auxiliary subsystem provides (403) a "subsystem ready" notification; and when the "subsystem ready" notification is received, the main subsystem coordinates (405) the startup of the subsystem.

Description

Technical Field

[0001] The present invention relates to the field of medical devices, and more particularly to techniques for operating automated medical devices during startup and shutdown. Background Art

[0002] An automated medical device is a machine that the manufacturer intends to be used for medical purposes in humans or animals, either alone or in combination. Such purposes may include the diagnosis, prevention, monitoring, treatment or alleviation of disease, injury or disability.

[0003] Automated medical devices are frequently used in healthcare and are subject to strict regulations to ensure their safety and effectiveness.

[0004] Typically, automated medical devices are operated by software systems, which are complex systems that require careful design to mitigate the risk of failures that could affect health.

[0005] It may be desirable to design a software system as consisting of two or more independent subsystems or modules. Constructing sets of independent subsystems enables product designers and manufacturers of medical devices to create and deploy subsystems that perform specific functions that are subsets of the functions of the complete medical device. This modularity of software can also be paired with modularity of hardware through different subsystems executing on different processors, such as on one or more integrated circuits or chips.

[0006] Although much effort is usually put into the design of software systems to ensure that medical devices can operate in a controlled, safe and reliable manner when performing medical purposes, startup and shutdown of medical devices are often ignored and performed by assuming a nominal startup time for each process and using corresponding timers. This can lead to long startup times and is prone to failures if the process startup should be delayed beyond the nominal startup time for some reason. Regardless of the safety measures built into the software system, failures that occur during startup or shutdown may still have serious consequences for subsequent medical procedures performed by the medical device. In software systems that are modularized into two or more subsystems, startup and shutdown may be particularly prone to failures.

[0007] It is generally desirable to provide a software system for a medical device that ensures deterministic, safe, and reliable startup and shutdown of the medical device.

[0008] Prior art includes the article "Logical Architecture of Medical Telediagnostic Robotic System" by Stanczyk et al., published in the 21st International Conference on Methods and Models in Automation and Robotics (MMAR), pp. 200-205 (2016). This article proposes a multifunctional robotic system that allows remote physical examination. The patient-side control system includes a robot central control system (RCCS), which is connected to lower-level components, such as low-level control devices for the robot head, robot arm, and mobile robot base, respectively. Based on sensor signals, logical requirements of the assistant or doctor, and status signals from all low-level components, the RCCS decides whether the low-level components can be operated. All communications pass through the RCCS. After turning on the power, the RCCS enters the startup state to start the startup procedure. When all lower-level components are identified as active, the RCCS enters the active state. Conversely, when the power off button is pressed, the RCCS enters the shutdown state to start the shutdown procedure. When all lower-level components have completed their shutdown procedures, the RCCS enters the Shutdown state.

[0009] Although this prior art control system enables safe and reliable startup of the hardware components of the robotic system at a high level, it does not ensure deterministic startup of all processes of the control system.

[0010] Prior art also includes US2014 / 0121509, which discloses a dependency-based startup method in a multimodal medical treatment system. A system controller is arranged to coordinate the startup and shutdown of multiple executable components, which are modality-specific components for communicating with corresponding medical devices coupled to the treatment system. For each executable component, the system controller obtains dependency information, which includes a list of other executable components that the executable component depends on. The system controller dynamically derives a startup order for the multiple executable components based on the dependency information, and starts the executable components according to the startup order. Before starting the next component in the startup order, the system controller waits until the corresponding component exposes all of its interfaces and selectively broadcasts a process ready message.

[0011] The startup method only considers startup at the level of executable components. Therefore, it cannot ensure deterministic startup of all processes in the system, for example, deterministic startup of processes executed by software applications in one or more executable components. In addition, the proposed startup method is complex because it requires the exchange of dependency information and the centralized determination of the startup order by the system controller. Summary of the invention

[0012] It is an object of the present invention to at least partially overcome one or more limitations of the prior art.

[0013] Another object is to enable deterministic startup of all relevant processes of a software system for operating a medical device.

[0014] Another object is to enable deterministic shutdown of all relevant processes of a software system for operating a medical device.

[0015] One or more of these objects, as well as other objects that may emerge from the following description, are at least partly achieved by a method of operating a medical device, a medical device and a computer-readable medium, embodiments of which are defined by the dependent claims.

[0016] A first aspect of the present invention is a method for operating a medical device. The medical device is configured to perform a medical procedure and includes a processor set and a memory unit set storing a software system for execution by the processor set. The software system defines a plurality of subsystems, including a main subsystem and a set of auxiliary subsystems. Each subsystem includes a software application involved in the operation of the medical device during the medical procedure. The method includes, during the startup of the medical device: initiating each software application; when ready to start, each software application in the corresponding auxiliary subsystem provides an application readiness notification; when all software applications of the corresponding auxiliary subsystem have provided an application readiness notification, the corresponding auxiliary subsystem provides a subsystem readiness notification; and when the subsystem readiness notification is received, the main subsystem coordinates the startup of the auxiliary subsystem set.

[0017] A second aspect of the present invention is a medical device for performing a medical procedure. The medical device includes a set of processors and a set of memory units storing a software system for execution by the set of processors. The software system, when executed by the set of processors, operates the medical device to perform the medical procedure. The software system defines a plurality of subsystems, including a primary subsystem and a set of secondary subsystems. Each subsystem includes a software application involved in the operation of the medical device during the medical procedure. The software system, when executed by the set of processors, performs a method according to the first aspect or any embodiment thereof.

[0018] A third aspect is a computer-readable medium comprising a software system for operating a medical device to perform a medical procedure. The software system defines a plurality of subsystems, including a primary subsystem and a set of secondary subsystems. Each subsystem comprises a software application involved in the operation of the medical device during the medical procedure. The software system, when executed by a set of processors of the medical device, performs a method according to the first aspect or any embodiment thereof.

[0019] These aspects enable deterministic startup of all relevant software applications of a software system in a medical device. Deterministic startup is achieved by dividing the startup procedure into a subsystem-level startup preparation and a system-level startup preparation using application readiness notifications and subsystem readiness notifications, in which the main subsystem coordinates the startup of each subsystem. In addition, the aforementioned aspects enable the responsibility of ensuring that the software application is ready to start to be delegated to the corresponding subsystem. Therefore, the startup procedure can be modularized corresponding to the software system, so that each subsystem can be operated to prepare for startup independently of other subsystems. Such modularization is advantageous because it allows the startup procedure to be executed separately on the subsystems, and the startup of the subsystems can be tested separately during development and deployment.

[0020] In addition, the use of notifications enables the medical device to be safely and reliably started. For example, when a fault occurs that prevents the notification from being provided, the software system can be prevented from starting. The use of notifications also enables simple and effective detection and location of faults in the software system during the start-up of the medical device. In addition, the use of notifications can also shorten the time required to start the medical device compared to the use of timers and nominal start-up times as described above.

[0021] Corresponding modularity may be achieved in the shutdown procedure by using notifications to prepare all relevant executing software applications in the medical device for power loss in a deterministic, safe and reliable manner.

[0022] Some embodiments of the first aspect are defined below, and these embodiments can be used to enable, implement or improve the purpose of deterministic startup and / or shutdown of all relevant processes of a software system for operating a medical device, or other purposes understood by those skilled in the art.

[0023] In one embodiment, the method further includes, in the corresponding subsystem: upon obtaining the subsystem readiness notification, enabling, by the software application of the corresponding auxiliary subsystem, communication between software applications of the corresponding auxiliary subsystem.

[0024] In one embodiment, coordination includes generating, by the primary subsystem, a system readiness notification for receipt by the set of secondary subsystems.

[0025] In one embodiment, the coordination further comprises: upon obtaining the system readiness notification, enabling, by the corresponding auxiliary subsystem, communication between software applications of at least a subset of different subsystems of the plurality of subsystems, so that the medical device is ready to perform at least a portion of the medical procedure.

[0026] In one embodiment, the method further includes providing an application readiness notification by a corresponding software application in the primary subsystem when ready to start, wherein coordination is performed by the primary subsystem upon receiving the subsystem readiness notification from the corresponding secondary subsystem and upon receiving the application readiness notification from the corresponding software application in the primary subsystem.

[0027] In one embodiment, the manager in the primary subsystem receives subsystem readiness notifications from the corresponding secondary subsystems and receives application readiness notifications from the corresponding software applications in the primary subsystem and performs coordination.

[0028] In one embodiment, the corresponding auxiliary subsystem further includes a manager, wherein the manager of the corresponding auxiliary subsystem provides a subsystem readiness notification when obtaining application readiness notifications from all software applications of the corresponding auxiliary subsystem.

[0029] In one embodiment, the coordination includes: when obtaining application readiness notifications from each software application of the primary subsystem and obtaining subsystem readiness notifications from the corresponding secondary subsystems, the manager of the primary subsystem provides system readiness notifications to the corresponding secondary subsystems.

[0030] In one embodiment, the method further includes: upon obtaining the system readiness notification, enabling, by a manager of the corresponding auxiliary subsystem and by a manager of the primary subsystem, communication between at least a subset of software applications of different subsystems among the multiple subsystems, so that the medical device is ready to perform at least part of the medical procedure.

[0031] In one embodiment, the software system defines at least two secondary subsystems, and enabling communication between at least a subset of software applications of different subsystems includes enabling direct communication between at least a subset of software applications in the at least two secondary subsystems.

[0032] In one embodiment, the subsystems execute on different processors in a collection of processors.

[0033] In one embodiment, two or more subsystems are critical to a medical procedure performed by the medical device and include corresponding managers, and the method further includes, during the startup: operating each manager of the two or more subsystems to send an external heartbeat signal; and starting to monitor the external heartbeat signal between the managers of the two or more subsystems to detect operational failures.

[0034] In one embodiment, the method also includes, during the startup: when an application readiness notification is not received from the corresponding software application of the primary subsystem within a first predetermined time period, a first error is reported by the manager in the primary subsystem; and when a subsystem readiness notification is not received from the corresponding secondary subsystem within a second predetermined time period, a second error is reported by the manager in the primary subsystem.

[0035] In one embodiment, the method includes, during shutdown of the medical device: the manager of the main subsystem provides a shutdown notification to the set of auxiliary subsystems; the manager of the main subsystem requests termination of the software application of the main subsystem; and after obtaining the shutdown notification, the manager of the corresponding auxiliary subsystem requests termination of the software application of the corresponding auxiliary subsystem.

[0036] In one embodiment, requesting to terminate the software application of the corresponding auxiliary subsystem includes, for at least one auxiliary subsystem: providing, by the manager, a subsystem not ready notification for the software application of the auxiliary subsystem; upon obtaining the subsystem not ready notification, preparing for termination by at least a subset of the software applications of the auxiliary subsystem; providing, by at least a subset of the software applications, an application shutdown readiness notification when ready to terminate; and upon obtaining the application shutdown readiness notification from at least a subset of the software applications, providing, by the manager of the auxiliary subsystem, a subsystem shutdown readiness notification to the manager of the main subsystem.

[0037] In one embodiment, requesting to terminate the software application of the main subsystem includes: providing, by the manager of the main subsystem, a subsystem not ready notification to the software application of the main subsystem; upon obtaining the subsystem not ready notification, preparing for termination by at least a subset of the software applications of the main subsystem; and providing, by the at least a subset of the software applications of the main subsystem, an application shutdown readiness notification when ready for termination.

[0038] In one embodiment, the method further comprises initiating, by the manager of the primary subsystem, power loss of the medical device upon obtaining a subsystem shutdown readiness notification from the at least one secondary subsystem and obtaining an application shutdown readiness notification from the at least a subset of software applications of the primary subsystem.

[0039] In one embodiment, the method includes: in the absence of an error during the shutdown, at least one manager sets a shutdown reason parameter for indicating a normal shutdown, and stores the shutdown reason parameter in a set of memory units; and during the startup, at least one manager sets a shutdown reason parameter for indicating a shutdown error, and stores the shutdown reason parameter in a set of memory units.

[0040] In one embodiment, the method includes: in the absence of an error during the shutdown, at least one manager sets a shutdown reason parameter for indicating a normal shutdown, and stores the shutdown reason parameter in the memory unit set; and during the startup, at least one manager sets a shutdown reason parameter for indicating a shutdown error, and stores the shutdown reason parameter in the memory unit set.

[0041] In one embodiment, the software applications include one or more critical software applications that are critical to a medical procedure performed by the medical device, and the method further includes, during shutdown of the medical device and before providing a shutdown notification to the set of auxiliary subsystems: providing, by a manager of the primary subsystem, a shutdown request for the one or more critical software applications; verifying, by the one or more critical software applications, the shutdown request based on the operation of the medical device; and providing, by at least one of the one or more critical software applications, an application shutdown readiness notification if the shutdown is acceptable; wherein, upon obtaining the application shutdown readiness notification from the at least one of the one or more critical software applications, the manager of the primary subsystem provides the shutdown notification to the set of auxiliary subsystems.

[0042] In one embodiment, the multiple subsystems include a first subsystem having a software application for controlling a medical device to perform a medical procedure, and a second subsystem having a software application for communicating with actuators and / or sensors of the medical device, and coordination is used to enable communication between the software application for controlling the medical device and the software application for communication.

[0043] In one embodiment, the multiple subsystems also include a third subsystem having a software application for supervising the medical procedure to detect deviations, and a fourth subsystem having a software application for communicating with auxiliary sensors of the medical device, and the coordination also enables communication between the software application for supervising the medical procedure and the software application for communicating with the auxiliary sensors, and communication between the software application for controlling the medical device and the software application for supervising the medical procedure.

[0044] Another aspect of the present invention is a method for operating a medical device. The medical device is configured to perform a medical procedure and includes a processor set and a memory unit set storing a software system for execution by the processor set. The software system defines a plurality of subsystems, including a main subsystem and a set of auxiliary subsystems. Each subsystem includes a software application involved in the operation of the medical device during the medical procedure. The method includes, during the startup of the medical device: starting each software application; when ready to start, each software application provides an application readiness notification; when all software applications of the corresponding auxiliary subsystem have provided an application readiness notification, the corresponding auxiliary subsystem provides a subsystem readiness notification; and when the subsystem readiness notification is received, the main subsystem coordinates the startup of the subsystem. The method can be deployed on a medical device corresponding to the second aspect, and can be implemented on a computer-readable medium corresponding to the third aspect. The foregoing embodiments are also applicable to methods of other aspects.

[0045] Other objects and aspects, as well as embodiments, features, technical effects and advantages of the present invention may appear from the following detailed description, the appended claims and the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Embodiments of the present invention will now be described in more detail with reference to the accompanying drawings.

[0047] Figures 1A-1C Examples of medical devices in which embodiments of the present invention may be implemented are shown.

[0048] Figure 2 is a schematic block diagram of hardware components of a medical device connected to a signal communication structure.

[0049] Figure 3 is a schematic block diagram of a software system for operating a medical device.

[0050] Figure 4A-4B is a flow chart of a method performed for starting a medical device according to an embodiment of the present invention.

[0051] Figures 5A-5D is a flow chart of a method performed for shutting down a medical device according to an embodiment of the present invention.

[0052] Figure 6 The embodiment of the present invention is shown Figure 3 The state of a software system when it is being operated.

[0053] Figures 7A-7E According to an embodiment of the present invention Figure 3 A sequence diagram of a software program used to initiate operation of a medical device.

[0054] Figures 8A-8CAccording to an embodiment of the present invention Figure 3 A sequence diagram of the operations of a software program for shutting down a medical device. DETAILED DESCRIPTION

[0055] Embodiments of the present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all, embodiments of the invention are shown. Indeed, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure may satisfy applicable legal requirements. Like numbers refer to like elements throughout.

[0056] Moreover, it will be understood that, where possible, any advantages, features, functions, equipment and / or operational aspects of any embodiment of the present invention described and / or conceived herein may be included in any other embodiment of the present invention described and / or conceived herein, and / or vice versa. In addition, unless otherwise expressly stated, any term expressed in the singular herein is also intended to include the plural form, and / or vice versa, where possible. As used herein, "at least one" shall mean "one or more", and these phrases are intended to be interchangeable. Therefore, the terms "one" and / or "an" shall mean "at least one" or "one or more", although the phrases "one or more" or "at least one" are also used herein. As used herein, unless the context requires otherwise due to the expression language or necessary implication, the word "include" or variations such as "include" or "contain" are used in an inclusive sense, that is, specifying the presence of the described features, but not excluding the presence or increase of other features in various embodiments of the present invention. As used herein, the "set" of an item is intended to imply the provision of one or more items.

[0057] It will also be understood that, although the term first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish an element from another element. For example, without departing from the scope of the present invention, the first element may be referred to as the second element, and similarly, the second element may be referred to as the first element. As used herein, the term "and / or" includes any and all combinations of one or more related listed items.

[0058] For the sake of brevity and / or clarity, well-known functions or constructions may not be described in detail. Unless otherwise defined, all terms (including technical terms and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the invention belongs.

[0059] Embodiments of the present invention are directed to enabling the deterministic startup and / or shutdown of all relevant processes of a medical software system for operating a medical device. The medical device is an automated device or machine that is configured to operate, optionally in combination with one or more other medical devices, to perform a medical procedure on a human or animal object. As used herein, a medical procedure may involve one or more of the diagnosis, prevention, monitoring, treatment or mitigation of a disease, injury or disability or monitoring to detect these. In the following, it is assumed that a medical software system includes two or more subsystems that are executed on one or more processors to control a medical device to perform a medical procedure. A subsystem may be viewed as a software module of a computer executable instruction that can be independently developed and tested to provide specific functions related to the operation of a medical device when performing a medical procedure. A corresponding subsystem includes a collection of software applications, wherein each software application corresponds to a process or task executed within the context of a corresponding subsystem. Therefore, a software application within a subsystem may be designed to perform a group of coordinated processes to provide specific functions of a subsystem. However, it is conceivable that a subsystem includes one or more software applications that are not involved in the operation of a medical device. In addition, the subsystems may include other software components, such as middleware and / or low-level software components that perform basic functions or services in the software system, such as a communication stack for managing communications with other subsystems, an error manager for managing technical errors, a notification manager for managing notifications, etc. One or more subsystems may run on top of one or more operating systems to utilize services provided by the operating system regarding hardware and software resources. Depending on the implementation, the operating system may, for example, include a real-time operating system, an embedded operating system, a single-task operating system, or a multi-task operating system, or any combination thereof. It is also conceivable that one or more subsystems are configured to run without an operating system and directly interface with the hardware resources of the medical device.

[0060] Figures 1A-1C is a schematic diagram of an example medical device connected directly or indirectly in fluid communication with a subject. It should be noted that the examples shown are highly schematic and are merely given for the purpose of illustrating different implementation contexts of embodiments of the present invention.

[0061] Figure 1AA medical device 10 is shown that is operable to deliver a medical fluid into the body of a subject 100 in a controlled manner, for example, into the circulatory system of the subject 100, as indicated by the arrows. The medical fluid may be any suitable fluid, including but not limited to medications and / or nutrients. This type of medical device 10 is often referred to as an "infusion pump". In the simplified example shown, the medical device 10 includes a fluid line 11 for connection to the subject 100, a display 12, control buttons 13 (one is shown), an indicator light 14, a speaker 15, a control system 16, one or more actuators 17 for controlled delivery of the medical fluid to the subject 100 via the fluid line 11, and one or more sensors 18 for providing sensor data indicating the infusion process performed by the infusion pump. The actuator 17 and the sensor 18 may include internal components (as shown in dashed lines) or external components of the medical device 10, or both internal and external components. The control system 16 is configured to coordinate the operation of the actuator 17 and the sensor 18 to perform the intended medical procedure of the infusion pump, and to operate the display 12, the indicator light 14 and the speaker 15 when necessary in conjunction with the medical procedure, and to obtain user input via the control button 13. For example, the display 12 can be operated to present instructions to the user of the medical device 10, the indicator light 14 can be operated to indicate the device status, the speaker 15 can be operated to generate an alarm signal, etc.

[0062] Figure 1B A medical device 10 is shown that is operable to deliver dialysate to the peritoneal cavity of a subject 100 in a controlled manner and subsequently remove dialysate therefrom, as indicated by the double-headed arrow. This medical procedure is often referred to as automated peritoneal dialysis, and the medical device 10 is often referred to as a "PD cycler." At the level of detail shown, Figure 1B The medical device 10 in the embodiment may have Figure 1A The medical device 10 in FIG. 1 is a similar component set and therefore will not be described further.

[0063] Figure 1CTwo medical devices 10, 10' are shown that may be involved in a medical procedure for performing extracorporeal blood treatment, for example as part of renal replacement therapy (e.g., hemodialysis, hemodiafiltration, hemofiltration, or ultrafiltration). The medical device labeled 10 is a blood treatment apparatus that includes a blood extraction line 11A and a blood return line 11B for connecting to the circulatory system of a subject 100, for example at a vascular inlet. As indicated by the arrows, the medical device 10 is operable to extract blood from the subject 100 in a controlled manner, process the blood, and return the processed blood to the subject 100. The medical device labeled 10' is operable to prepare a fluid for use by the blood treatment apparatus 10, and includes a fluid line 11 for supplying the fluid to the blood treatment apparatus 10. In one example, the medical device 10' is a water preparation apparatus, and the fluid is purified water. For example, as is known in the art, the water treatment apparatus 10' may filter the incoming water by reverse osmosis. At the level of detail shown in the figure, Figure 1C Each of the medical devices 10, 10' may have Figure 1A The medical device 10 in FIG. 1 is a similar set of components and therefore will not be described further.

[0064] Figure 2 It is shown that it can be used in (for example, Figures 1A-1C 2. An example of hardware components that are active during operation of a medical device (as shown) and the interconnection of these hardware components. In the example shown, the hardware components are connected to exchange signals via a signal communication structure 20, which may include any form of bus structure or switching fiber structure and / or separate wiring. It is also conceivable that one or more components are located on a common substrate, such as in an integrated circuit (IC) or the like, and are interconnected by signal conductive traces on the common substrate, which in turn is connected to other components via the signal communication structure 20. Figure 2In the example of , in addition to the display 12, the control button 13, the indicator light 14, the speaker 15, the actuator 17 and the sensor 18, the medical device also includes four separate processors P1-P4 and two separate memory units M1-M2. The processors P1-P4 and the memory units M1-M2 are "separate" in the sense that they are separately operable units, and they may or may not be located on a common substrate in any combination, such as in an IC. The corresponding processors P1-P4 may be any commercially available processing device, such as a CPU, DSP, microprocessor, FPGA, ASIC or any other electronic programmable logic device, or a combination thereof. The corresponding memory units M1-M2 may include non-volatile memory or volatile memory or a combination thereof, including but not limited to ROM, PROM, EEPROM, flash memory, removable memory, RAM, DRAM, SRAM, cache memory, hard disk drive, storage medium, etc.

[0065] exist Figure 2 In the example of , the above software system can be stored in one or more of the memory units M1-M2 to be executed by one or more of the processors P1-P4. Figures 1A-1C The control system 16 in may be implemented by a software system when executed by one or more of the processors P1 - P4 .

[0066] The software system may be provided on any suitable computer readable medium (CRM) for installation on a medical device. The CRM may include non-transitory storage or memory media, whether volatile or non-volatile, such as electronic, magnetic or optical media. Alternatively or additionally, the CRM may include a transient medium such as an electrical, electromagnetic or digital propagated signal that may be transmitted via a communication medium such as a network and / or a wireless link.

[0067] Figure 2 The hardware components in the figure are given as examples only. The medical device 10, 10' may include any number of each type of component, and may be omitted or replaced depending on the desired function of the medical device. Figure 2 For example, if the display 12 is touch-sensitive, the control buttons 13 may be replaced by virtual buttons on the display 12. It should also be appreciated that Figure 2 The examples in are not exhaustive, and the medical device may include other types of components that are active during its operation, such as a keyboard, a computer mouse, a power supply, etc.

[0068] Typically, the medical device 10, 10' comprises at least one processor, at least one memory unit, and at least one of an actuator and a sensor. Figures 1A-1CThe medical device 10, 10' in the embodiment generally comprises at least one actuator 17 and may also comprise at least one sensor 18. A medical device designed for monitoring may in principle comprise at least one sensor 18, but need not comprise an actuator 17. Figures 1A-1C In an example, actuator 17 may include one or more of a fluid pump, a valve, a heater, a cleaning system, etc., and sensor 18 may be configured to generate sensor data representing one or more of temperature, conductivity, concentration, pressure, flow rate, etc.

[0069] Figure 3 1 is a block diagram of a software system for executing in a medical device (e.g., any of the aforementioned medical devices) according to a non-limiting example. As shown, the software system includes four subsystems SS1-SS4. In the following, it is assumed that the subsystems SS1-SS4 are executed on one or more separate processors. Figure 2In the example of , subsystems SS1-SS4 can be executed on corresponding processors P1-P4. In other words, in some embodiments, subsystem SS1 can be executed on processor P1, subsystem SS2 can be executed on processor P2, subsystem SS3 can be executed on processor P3, and / or subsystem SS4 can be executed on processor P4. Each subsystem SS1-SS4 includes a collection of software applications that are involved in the operation of the medical device when the medical device performs a medical procedure. The collection of software applications in subsystems SS1, SS2, SS3, and SS4 are jointly specified by SW1, SW2, SW3, and SW4, respectively. The individual software applications in subsystems SS1, SS2, SS3, and SS4 are specified by software applications SW1x, SW2x, SW3x, and SW4x, respectively. In addition, each subsystem SS1-SS4 includes a corresponding communication module represented as ISC1-ISC4, which includes the above-mentioned communication stack and is responsible for managing communications with one or more other subsystems. In the example shown, ISC1-ISC4 are configured to establish communications between subsystems SS1 and SS3, between subsystems SS1 and SS2, and between subsystems SS3 and SS4. According to an embodiment, each subsystem SS1-SS4 also includes a manager module represented by SHM1-SHM4 and referred to as a "manager" hereinafter. The corresponding manager SHM1-SHM4 is responsible for managing the operation of its subsystem SS1-SS4 during startup and shutdown. The corresponding manager SHM1-SHM4 can access a list of software applications to be managed. The manager SHM1-SHM4 can also be responsible for monitoring the health of the software system during operation, such as monitoring that its software applications SW1-SW4 are running as expected through the corresponding manager SHM1-SHM4. One or more of the managers SHM1-SHM4 may also include boot code, which is executed at startup to prepare the system to load and run an operating system on one or more of the processors P1-P4.

[0070] exist Figure 3In the example of , subsystem SS1 includes a software application specified by SW1c, and subsystem SS3 includes a software application specified by SW3c. Software applications SW1c and SW3c are different from other software applications in that they are critical to the operation of the medical device when performing a medical procedure. In this context, "critical" means that, for example, considering the reduction of health risks to the object 100, the correct operation of the corresponding software applications SW1c, SW3c is necessary for performing the medical procedure according to the requirement specifications, which can be set by the manufacturer and / or by the regulatory body. A subsystem including at least one critical software application is also referred to as a "critical subsystem" in this article. In one example, the critical software application can be configured to control the medical procedure performed by the medical device, for example, by generating an ordered sequence of control commands or signals for operating one or more actuators 17 and optionally operating one or more sensors 18. In another example, the critical software application can be configured to supervise the operation of the medical procedure performed by the medical device, for example, by generating an ordered sequence of control commands or signals for operating one or more sensors 18.

[0071] In one specific example, SW1c is configured to control a medical procedure and SW3c is configured to supervise the operation of the medical procedure. Many medical devices that perform medical procedures that pose a health risk to a subject in the event of an operational failure in a host system controlling the medical procedure or in any hardware component used by such a host system are required to include a protection system that operates in parallel with and independently of the host system. Whenever the protection system detects a potential operational failure, the medical device is switched to a safe operating state. Thus, returning to Figure 3 , subsystem SS1 may correspond to a main system, while subsystem SS3 may correspond to a protection system. Subsystems SS2 and SS4 may be configured to communicate with different sets of actuators and / or sensors based on commands / signals generated by subsystem SS1 and subsystem SS3, respectively. To this end, each of subsystems SS2, SS4 may include a software application for providing access to peripheral devices (e.g., actuators and / or sensors) connected to the corresponding subsystem SS2, SS4. In order to achieve independence between the main system and the protection system, SS2 may be connected to a set of main sensors, and SS4 may be connected to a separate set of auxiliary sensors. Subsystems SS1-SS4 may also be implemented on separate processors (e.g., Figure 2 In a variation, subsystem SS2 and / or subsystem SS4 may be included in subsystem SS1 and subsystem SS3, respectively.

[0072] Therefore, in one implementation, the software system may include at least a main system (subsystem SS1) and a protection system (subsystem SS3), which may be a monitoring and fail-safe component that is fully redundant with subsystem SS1 to help ensure the safety of the patient all the time. Subsystem SS3 may be designed so that any single point failure of subsystem SS1 that may harm the patient may be detected and avoided by subsystem SS3. Under normal conditions, subsystem SS1 will read the current state of the HW and / or SW components, determine the next state according to the selected operating mode, and write the new state to the HW and / or SW components as needed. Due to the inherent risk of errors in each of these three operating stages, subsystem SS3 is implemented to protect the patient by stopping the system and notifying the operator of the fault condition in the event of a failure. Possible failures may include data loss or misrepresentation, software calculation errors or failures, or hardware failures such as transducers, switches, or processors. Subsystem SS3 guards against such risks by monitoring the commands and status information sent in the system. Subsystem SS3 may also be connected to one or more dedicated sensors to provide redundant measurements. It should be noted that the link between subsystems need not be a single connection, but may include a series of links, such as one or more of integrated circuits, digital logic, I / O buses, and software.

[0073] Below is an example of a software application that can be included in subsystem SS3. It should be understood that this is only an example given to increase understanding and provide additional background. Therefore, subsystem SS3 can contain more, less or other software applications. It should also be clear that the following example structure or part thereof can also be implemented in other subsystems of the system (e.g., subsystem SS1). In a specific example, subsystem SS3 includes an I / O application ("I / O"), which is responsible for implementing low-level SW to HW in addition to serial communication. Therefore, I / O provides I / O data to the client and can also perform CRC of I / O data. The alarm processing application is responsible for managing alarms and requesting resets through I / O when the alarm is activated. During the operation of the medical device, the alarm processing application interacts with the mode management application (as follows) and I / O. The configuration processing application is responsible for providing treatment settings to the client in subsystem SS3. During the operation of the medical device, the configuration processing application interacts with subsystem SS1 via inter-system processing (as follows). The data logger application is responsible for receiving text-based log data from other software applications within subsystem SS3 and providing the log data to the client. During operation of the medical device, the data logger application also interacts with the time processing application (as described below). The mode management application is responsible for providing the current system status and treatment status to the client. The status is received from subsystem SS1 via inter-system processing (as described below) and I / O. The time processing application provides the current system time to the client. The device supervision application is responsible for monitoring the ongoing treatment using the values ​​obtained from the I / O. If subsystem SS1 does not take preventive measures in time, the device supervision application is responsible for reporting alarms to the alarm handling application. During operation of the medical device, the device supervision application also interacts with the configuration processing application, the mode management application, the time processing application, and the software health monitoring software module (as described below). The device supervision application can monitor the status and status changes in subsystem SS1. In a medical device (e.g., reference Figures 1A-1C In the context of a medical device such as the example, the device supervision application may also monitor the operation (values, commands, status, timing, etc.) of one or more blood leak detectors, one or more weight scales, one or more clamps, one or more bubble detectors, one or more pumps (syringe pumps, blood pumps, dialysate pumps, sewage pumps, replacement pumps, etc.), one or more pinch valves, one or more control panels, one or more liquid leak detectors, one or more pressure sensors, etc. Subsystem SS3 also includes a corresponding Figure 3The software health monitoring software module of SHM3 in SS3 is responsible for monitoring the health of the software in subsystem SS3, thereby monitoring that subsystem SS1 is active and running. Examples include checking the integrity of the software, checking the RAM, monitoring that all software applications in subsystem SS3 are running as expected, monitoring subsystem SS1 to verify that it is up and running, and kicking the hardware (HW) watchdog. Subsystem SS3 also includes Figure 3 The inter-system communication software module corresponding to ISC3 in the subsystem SS1 is responsible for managing serial communication with other subsystems including subsystem SS1. Inter-system communication can be subdivided into inter-system processing for high-level communication and inter-system transmission for low-level communication. In an implementation example, alarm processing, configuration processing, data logger, mode management and time processing are thread-safe libraries executed in the context of the client, and software health monitoring is executed as a task and is event-driven to act on incoming events. The software health monitoring task also has a periodic event with a predetermined time period (e.g., 50 milliseconds) to handle timeouts. The software health monitoring task has the highest priority to avoid other tasks blocking task supervision. Device supervision is executed as a task and has an execution period of, for example, 50ms and a high priority to execute at the required timing. I / O is executed as a task and is event-driven to service I / O events, and has an execution period of, for example, 5ms to perform independent signal reading and bus buffer clearing. The I / O task has a medium priority so that it can service events in a short time while avoiding blocking the device supervision task. Inter-system communication is executed as a task and is event-driven, as the responsibility of the inter-system communication is to handle incoming and outgoing communication events. The inter-system communication task also has an execution period of, for example, 100ms to supervise system status messages. The inter-system communication task has a low priority because the real-time requirements of this task are minimal. Communication between tasks is non-blocking; higher priority tasks can communicate with lower priority tasks without being blocked.

[0074] Figure 4A Is used to start including Figure 3 Flowchart of an embodiment of a method 400 for a medical device in a software system in FIG. 400 assumes that one of the subsystems is a "primary subsystem" that coordinates the startup of the subsystems, while the remaining subsystems are referred to as "secondary subsystems." The method is generally applicable to any software system that includes one primary subsystem and at least one secondary subsystem. In the following examples, SS1 is the primary subsystem and SS2-SS4 are secondary subsystems. In the following examples, it is also assumed that managers SHM1-SHM4 are controllers for system startup, as described below.

[0075] Method 400 includes step 401 of starting each software application SW1x-SW4x in all subsystems SS1-SS4. Step 401 can be performed after or as part of a conventional boot procedure, which starts system functions and system communications within the software system, including starting the managers SHM1-SHM4 and communication modules ISC1-ISC4 of the subsystems SS1-SS4. Step 401 can be performed automatically when the medical device is powered on. In one embodiment of step 401, the software applications SW1-SW4 in the corresponding subsystem are started upon receiving a start command / signal, which can be generated by the managers SHM1-SHM4 of the corresponding subsystems SS1-SS4 or elsewhere in the software system. During the initialization in step 401, the corresponding software applications SW1-SW4 can complete a corresponding predetermined startup action sequence, such as loading the boot file from the memory (see Figure 2 , read memory units M1, M2 in the memory, initialize one or more parameters, start the communication interface, etc. It can be noted that the present disclosure assumes that Figure 3 All of the software applications SW1-SW4 shown are to be launched by the launch method 400. However, it is contemplated that one or more of the subsystems SS1-SS4 include one or more software applications that are involved in the operation of the medical device for performing a medical procedure, but are launched at another time, i.e., separate from the launch method 400.

[0076] In step 402, when the corresponding software application SW1x-SW4x has been initiated according to step 401, the software application provides an "application ready" notification within its corresponding subsystem SS1-SS4 indicating that the software application is ready to start. In this context, a software application is "ready to start" when it is ready to perform its designated tasks or processes and interact with other software applications. In one embodiment, the software application provides an "application ready" notification whenever the software application operates to the extent that it is ready to receive incoming communication signals from other software applications. In some embodiments, the software application is also ready to send communication signals to other software applications, such as through a request-response message exchange pattern. Therefore, the software application does not have to be fully operational when providing the "application ready" notification.

[0077] Each subsystem SS1-SS4 respectively performs step 403. When the manager SHM1-SHM4 of the corresponding subsystem SS1-SS4 has obtained the "application ready" notification from all software applications SW1-SW4 in the corresponding subsystem SS1-SS4, the manager SHM1-SHM4 provides the "subsystem ready" notification within the software system, both internally within the corresponding subsystem SS1-SS4 and externally to be received by the main subsystem SS1 (in step 405 below).

[0078] Step 404 is also performed by each subsystem SS1-SS4, respectively. When each software application SW1-SW4 in a subsystem SS1-SS4 has obtained the "subsystem ready" notification provided by the manager SHM1-SHM4 of the subsystem SS1-SS4, the software applications SW1-SW4 enable communication between them (i.e., within the corresponding subsystem SS1-SS4). Therefore, step 404 allows "internal communication" at the application level within the corresponding subsystem SS1-SS4. When step 404 is completed, all software applications in the subsystem have been started, so that the subsystem is ready to interact with other subsystems in the software system.

[0079] Step 405 is only performed by the primary subsystem SS1. When the manager SHM1 has obtained the "subsystem ready" notifications of all the secondary subsystems, the manager SHM1 coordinates the startup of the subsystems SS1-SS4.

[0080] The method 400 enables deterministic startup of the software system of the medical device by dividing the startup into a subsystem level and a system level, and first ensuring that all software applications are ready for startup at the subsystem level, and then ensuring that all subsystems are ready for startup at the system level before continuing the startup. Figure 6 This principle is further illustrated in Figure 6 The state of a software system during startup and shutdown at the subsystem level (top) and the system level (bottom) is shown. It is important to note that Figure 6 This does not imply that the software system must be implemented as a state machine, but is intended only to explain the overall control mechanism during startup and shutdown of the software system. Figure 6 The software system is in the state "system not ready" and each subsystem SS1-SS4 is in the state "subsystem not ready". As a result of steps 401-404, corresponding to Figure 6In transition II in step 405, the corresponding subsystem SS1-SS4 enters the state "subsystem ready" (after receiving the "application ready" notification from its software application). At the system level, the software system is still in the "system not ready" state. As a result of step 405, corresponding to Figure 6 In transition III in, the software system enters state "system ready" (after receiving the "subsystem ready" notification from the auxiliary subsystem), so that the software system is now ready to operate the medical device to perform a medical procedure. It should be understood that the use of the "application ready" notification and the "subsystem ready" notification ensures safe and reliable startup of the medical device. For example, the notification prevents the software system from being started whenever a fault occurs that prevents the notification from being provided. The use of notifications enables simple and effective detection and location of faults in the software system. In addition, compared to the use of timers and nominal startup times discussed in the background technology section, the use of notifications can also shorten the time required to start the medical device, because the nominal startup time is typically set to have a significant margin relative to the actual startup time.

[0081] It is also worth noting that the common "subsystem is ready" notification is received by all software applications within the subsystem in step 404, and the notification triggers the individual software applications to enable application-level internal communication within the subsystem. Through steps 401-404, the startup method 400 provides a distributed but deterministic startup of the corresponding subsystems. This in turn means that the method 400 eliminates any need for centralized control of the startup sequence of the individual software applications within the corresponding subsystems, and instead allows all of these software applications to start whenever a "subsystem is ready" notification is received. Those skilled in the art will appreciate that this distributed startup of software applications not only facilitates control and troubleshooting of startup procedures, but also facilitates maintenance and updating of software systems by facilitating the addition and removal of software applications.

[0082] Notifications can be distributed in software systems via a push mechanism or a pull mechanism, which are well known in the art. With a push mechanism, a notification or a message indicating that a notification is available is sent from an originator for receipt or interception by a recipient. With a polling mechanism, a recipient requests a notification from an originator.

[0083] Back to Figure 4A, it can be noted that the "application ready" notification does not need to be provided directly from the corresponding software application to the manager SHM1-SHM4 within the corresponding subsystem SS1-SS4. Instead, the software applications within the subsystem may provide their "application ready" notifications from one software application to the next in a predetermined sequence. Then, when the last software application in the sequence provides its "application ready" notification to the manager, the manager concludes that all "application ready" notifications have been provided in the subsystem.

[0084] It is also conceivable to use a central manager instead Figure 3 In the distributed managers SHM1-SHM4, the central manager obtains the "application readiness" notification and the "subsystem readiness notification" as described above. However, the distributed managers SHM1-SHM4 provide the advantage of strict modularity of the subsystems SS1-SS4, which in turn enables independent development and / or testing and / or deployment of the subsystems SS1-SS4.

[0085] In another variant, the functionality of the managers SHM1 - SHM4 is instead performed by one of the software applications in the corresponding subsystem SS1 - SS4 .

[0086] It should also be noted that although Figure 4A Step 404 in provides the advantage of ensuring that when the subsystem enters the state “subsystem ready”, the software applications in the subsystem are able to communicate with each other and the subsystem is truly ready to start, but it is conceivable that such internal communication of the subsystem is enabled at a later stage (for example, when the software system enters the state “system ready” (for example, in step 408 below)).

[0087] In yet another variation, only software applications in the secondary subsystems SS2-SS4 are configured to provide "application ready" notifications and receive "subsystem ready" notifications from their respective managers SHM2-SHM4, while software applications in the primary subsystem SS1 are not.

[0088] Figure 4B is a flow chart of an embodiment of a method 405' for coordinating the activation of subsystems SS1-SS4, which method 405' may be used as Figure 4A In step 406, the primary subsystem SS1 provides a "system ready" notification to the corresponding secondary subsystems SS2-SS4. Return to Figure 4AIt should be understood that the "system ready" notification is generated when the main subsystem SS1 has obtained the "application ready" notification from all its software applications SW1 (step 403) and the "subsystem ready" notification from all auxiliary subsystems SS2-SS4 (step 405). In step 407, the corresponding auxiliary subsystems SS2-SS4 obtain the "system ready" notification. By obtaining the "system ready" notification, the manager SHM2-SHM4 knows that all subsystems SS1-SS4 are ready to start. Similarly, the manager SHM1 knows that all subsystems are ready to start. It can be understood from the foregoing that when the software applications of the subsystem have been started and are allowed to communicate with each other, the subsystem is ready to start.

[0089] In the following step 408, the managers SHM1-SHM4 of all subsystems SS1-SS4 enable application-level communication between subsystems, so that software applications in one subsystem can communicate with software applications in another subsystem. Thus, step 408 enables "intercommunication" between subsystems SS1-SS4. Figure 3 In the example of , communication between SS1 and SS2, between SS1 and SS3, and between SS3 and SS4 is enabled. Thus, step 408 enables not only centralized communication, i.e., communication between the primary subsystem and one or more secondary subsystems, but also direct communication between the secondary subsystems. When step 408 is completed, the software system has been started and the medical device is ready to perform at least part of the medical procedure, for example, by providing instructions to the operator, allowing the operator to input control parameter values ​​for the medical procedure, etc.

[0090] Method 405' ensures deterministic startup of all subsystems SS1-SS4. The advantages of providing a "system ready" notification are similar to the advantages of providing "application ready" and "subsystem ready" notifications as described above. For example, it can be noted that in step 407, all auxiliary subsystems within the software system receive a common "system ready" notification, and this notification triggers each auxiliary subsystem to enable inter-subsystem communication within the software system. Through steps 406-408, the startup method 400 provides a distributed but deterministic startup of the software system. This in turn means that method 400 eliminates any need for centralized control of the startup sequence of each subsystem within the software system, and instead allows all subsystems to start whenever a "system ready" notification is received. Those skilled in the art will appreciate that this distributed startup of subsystems not only facilitates control and troubleshooting of startup programs, but also facilitates maintenance and updating of software systems by facilitating the addition and removal of subsystems.

[0091] Figure 5A Is used to close the Figure 3Flowchart of an embodiment of a method 500 for operating a medical device using a software system in the present invention. Closing may be initiated by an operator-generated closing command (eg, when the operator presses a control button (see Figures 1A-1C 13)) in, or triggered by a process in a medical device.

[0092] In step 501, the manager SHM1 of the main subsystem SS1 is notified of the shutdown command, and the manager SHM1 starts the shutdown by providing a "shutdown" notification to all the auxiliary subsystems SS2-SS4. In step 502, the manager SHM1 requests the termination of the software application SW1 in the main subsystem SS1. In this context, "termination" means that each software application stops its activity to the extent that it is ready to lose power. Step 503 is performed by each auxiliary subsystem SS2-SS4 separately. The managers SHM2-SHM4 obtain the "shutdown" notification and then request the termination of the software applications SW2-SW4 of the auxiliary subsystems SS2-SS4. Then, in step 504, the manager SHM1 of the main subsystem SS1 starts the power loss of the medical device, for example, by notifying the power manager in the medical device to cut off the power.

[0093] The combination of steps 501-503 ensures deterministic shutdown of the medical device by dividing the shutdown into system level and subsystem level. Figure 6 When the medical device is to be shut down, the software system is in the "system ready" state, and each subsystem SS1-SS4 is in the "subsystem ready" state. As a result of step 501, the corresponding Figure 6 As a result of steps 502-503, it can be seen that the corresponding subsystems SS1-SS4 enter the state "Subsystem Not Ready", corresponding to Figure 6 Thus, the software system is prepared at the system level and the subsystem level, and then the power loss is initiated by step 504, corresponding to Figure 6 Transformation in VI.

[0094] Figure 5B is a flow chart of an embodiment of a method 502' for requesting termination of a software application SW1 of a master subsystem SS1, which method 502' may be used as Figure 5AIn step 505, the manager SHM1 provides a "subsystem not ready" notification to the software application SW1 of the main subsystem SS1. In step 506, the software application obtains the "subsystem not ready" notification. In step 507, after obtaining the "subsystem not ready" notification, the corresponding software application SW1x is prepared to terminate, for example by completing all ongoing activities with consequential results, which, if stopped immediately, may have an impact on the performance of the medical device when it is restarted after being shut down, that is, generate corrupted data, or endanger the health of the subject. Such activities with consequential effects may include writing data to memory, completing calculations, generating signals for actuators ( Figures 1A-1C 17) of the control signal, etc. Activities with consequential results may also involve user experience, for example, by a speaker ( Figures 1A-1C 15) in the audio signal playback, the display ( Figures 1A-1C 12) in step 507. Therefore, in step 507, the corresponding software application can allow other activities that are considered non-consequential to continue to be terminated later. In step 508, when ready to terminate, the corresponding software application SW1x provides an "application shutdown ready" notification. In step 509, the manager SHM1 obtains the "application shutdown ready" notification from the software application SW1. When the manager SHM1 has obtained the "application shutdown ready" notification from all software applications SW1, the main subsystem SS1 can be regarded as being in the state "subsystem not ready" ( Figure 6 ).

[0095] Figure 5C is a flow chart of an embodiment of a method 503′ for requesting termination of software applications SW2-SW4 of auxiliary subsystems SS2-SS4, which method 503′ may be used as Figure 5A Method 503' is performed by each auxiliary subsystem SS2-SS4 respectively. Steps 505-509 correspond to Figure 5B Steps 505-509 of method 502' in FIG. 5 are therefore not described further. It should be understood that steps 505 and 509 are performed by managers SHM2-SHM4, and steps 506-508 are performed by the corresponding software applications of the auxiliary subsystems SS2-SS4. After step 509, the corresponding auxiliary subsystems SS2-SS4 can be regarded as being in the state "subsystem not ready" ( Figure 6 ). In step 510, if the managers SHM2-SHM4 have obtained the "application shutdown ready" notification from all software applications of the corresponding auxiliary subsystems SS2-SS4 in step 509, the corresponding managers SHM2-SHM4 provide the "subsystem shutdown ready" notification to the main subsystem SS1.

[0096] Return to Figure 5A In step 504, the manager SHM1 can start power loss only after obtaining the "subsystem shutdown ready" notification (generated by method 503') from all auxiliary subsystems SS2-SS4 and after obtaining the "application shutdown ready" notification (generated by method 502') from all software applications SW1 in the main subsystem SS1.

[0097] In a variant of step 504, it is conceivable that the manager SHM1 also proceeds to initiate the power loss in the absence of a "subsystem shutdown ready" notification from one or more auxiliary subsystems SS2-SS4, if a predetermined time has passed since step 501. Therefore, the manager SHM1 can set a timer that defines a maximum time delay until the start of the power loss. This can mitigate the risk of software freezing if a software application or a hardware component fails during shutdown. Similarly, it is conceivable that the managers SHM1-SHM4 set corresponding timers for obtaining "application shutdown ready" notifications in step 509.

[0098] It is also conceivable that, in step 509, one or more managers SHM1-SHM4 completely ignore the "application shutdown ready" notification from one or more software applications (for example, software applications whose all activities inherently do not cause consequential results if all their activities are stopped immediately), or these software applications do not provide the "application shutdown ready" notification. For the same reason, it is also conceivable that, in step 504, the manager SHM1 completely ignores the "subsystem shutdown ready" notification from the subsystem, or such a subsystem does not provide the "subsystem shutdown ready" notification.

[0099] Each of methods 502 ′ and 503 ′ ensures deterministic shutdown of the respective subsystems SS1 - SS4 and mitigates the risk of ongoing activities with consequential results when power is removed.

[0100] In another variation, only software applications in the secondary subsystems SS2-SS4 are configured to receive "subsystem not ready" notifications from their respective managers SHM2-SHM4 and provide "application shutdown ready" notifications, while software applications in the primary subsystem SS1 are not.

[0101] Although methods 502' and / or 503' may be used to reduce health risks to a subject, it may be desirable to further improve patient safety during shutdown of a medical device. Figure 5DIn one embodiment illustrated in FIG. 5 , a gatekeeping method 520 is performed by the software system before allowing the master subsystem SS1 to initiate the shutdown in step 501. In the gatekeeping method 520, each critical software application is given a "veto power" to prevent the shutdown of the software system if such a shutdown is deemed to compromise the safety of the patient. In step 521, after being notified of the shutdown command, the manager SHM1 of the master subsystem SS1 proceeds to issue a veto to the critical software applications (e.g., Figure 3 In step 522, each critical software application SW1c, SW3c verifies the "shutdown request". In this verification, the corresponding critical software application SW1c, SW3c can evaluate whether the shutdown is acceptable based on one or more predetermined shutdown criteria. One such shutdown criterion can be the safety of the patient. In one example, shutdown may be considered unacceptable before the completion of a medical procedure or a sub-process thereof. In another example, shutdown may be considered unacceptable before the completion of a calibration process. In another example, shutdown may be considered unacceptable unless the critical software application is in a safe operating state (e.g., service mode, idle mode, etc.). In step 523, only when the shutdown is deemed acceptable in step 522, the corresponding software application SW1c, SW3c provides an "application shutdown ready" notification. Optionally, in step 524, the corresponding critical software application SW1c, SW3c can then enter a controlled state. In this context, "controlled state" means that the critical software applications SW1c, SW3c operate according to control parameter values ​​set with consideration for patient safety, for example, by reducing pump speed, stopping pump, opening or closing valves, turning off heaters, etc. The gatekeeper control method 520 then continues to step 501, where the manager SHM1 proceeds to provide a "shutdown" notification only if it has obtained an "application shutdown ready" notification from all critical software applications SW1c, SW3c.

[0102] The gatekeeping control method 520 prevents the medical device from being inadvertently shut down during an ongoing medical procedure, for example, by an operator pressing an on / off button. It may be noted that the above-mentioned timer is not implemented in the gatekeeping control method 520, which means that each critical software application has a true veto over the shutdown process, which will be stopped at step 501 unless the critical software application provides "application shutdown ready". In this case, it is conceivable that step 501 also involves asking the operator to confirm that an override shutdown procedure should be initiated. If confirmed, the critical software application can be set to a controlled state, upon which the shutdown procedure can be initiated according to the control method. Figure 5AMethod 500 in continues with shutdown.

[0103] In the following, reference will be made to Figures 7A-7E and Figures 8A-8C The sequence diagrams in exemplify the above-mentioned embodiments and other embodiments. Figures 7A-7E Depicts a sequence of steps performed during activation of a medical device, divided into Figure 6 A method for each of transformations Ia, Ib, II and III in . Figures 8A-8C Depicts a sequence of steps performed during shutdown of a medical device, divided into Figure 6 The described sequence of steps assumes that both startup and shutdown occur without errors, although error handling will be briefly discussed in the following description.

[0104] Fig. 7A Describes the methods performed during subsystem startup and corresponds to Figure 6 Transformation in Ia. Fig. 7A The subsystem startup in FIG. 7 assumes that a secure boot has been performed in SS1 and that SHM1 has checked the program binary of SS1. In step 701, during the boot, SHM2, SHM3, and SHM4 check the corresponding program binary of SS2, SS3, and SS4, respectively. If the check in step 701 fails for any of SS2-SS4, SS1 will fail in the subsequent step 712 (see FIG. 71). Figure 7B ) detects this condition. In step 702, each of SHM1-SHM4 starts to turn on the corresponding hardware watchdog, which means that the corresponding watchdog timer is restarted, as is known to those skilled in the art. In step 703, SHM1-SHM4 identify the software and hardware versions of SS1-SS4, respectively. In step 704, each of SHM1 and SHM3 sets the shutdown reason parameter to "error" and stores it in non-volatile memory (see Figure 2 If the subsequent shutdown is performed without error, the shutdown reason parameter is instead set and stored as "normal" (see Figure 8C826 in ). The reason for the default storage as "ERR" is to ensure that an erroneous shutdown is detected during startup. Thus, even in the event of a rapid and unintentional shutdown event, such as due to a loss of power, the shutdown cause parameter will be stored as "ERR". Step 704 may involve SHM1 and SHM3 performing an initial check of the stored value of the shutdown cause parameter. If SHM1 (or SHM3) obtains the value "ERR", SHM1 (or SHM3, or both) may enter a recovery mode to enable SHM1 (or SHM3, or both) to resume from the position where it stopped before the shutdown. In the example shown, step 704 is performed only by critical subsystems SS1 and SS3. However, it is conceivable that step 704 is also performed on SS2 and / or SS4, which do not include any critical software applications, as long as it is necessary or desired to recover SS2 and / or SS4.

[0105] After step 704, SS1-SS4 continues to transition Ib. Fig. 7A As shown, transition II of SS1 may be performed in parallel with transition Ib.

[0106] Figure 7B Describes the method performed during system startup and corresponds to Figure 6 In step 710, SHM1-SHM4 turn on the corresponding communication modules ISC1-ISC4 (see Figure 3 ). SHM1 then repeats steps 711-712 to establish a connection with each of SS2, SS3, and SS4 by providing a request for connection (step 711) and receiving a confirmation of the established connection (step 712). If the connection cannot be established, ISC1 may report an error in the system. After the connection is established, SHM1 repeats steps 713-714 to obtain software and hardware versions from SHM2, SHM3, and SHM 4 by providing a version request (step 713) and receiving version data. The version data may include identifiers of the corresponding software and hardware versions. If the version data is not received, SHM1 may report an error in the system. When the version data is received, SHM1 checks the compatibility of the software versions with each other (step 715) and checks the compatibility of the software version with the hardware version (step 716). For example, SHM1 checks the compatibility of the software versions of SS2, SS3, and SS4 with the software version of SS1. If step 715 or step 716 fails, or both fail, SHM1 may report an error in the system.

[0107] After step 716, each of SS1-SS4 proceeds to transition II. As described above, SS1 may perform transition II in parallel with transition Ib.

[0108] Figure 7A-7BThe method in is used to mitigate the risk of, for example, incompatible software versions in different subsystems and / or hardware and software mismatches and / or program binaries being corrupted in any of SS2-SS4, all of which may result in undefined behavior of the medical device.

[0109] Figure 7A-7B The sequence diagram in can be regarded as an example embodiment, in which the method for starting the medical device includes: starting the manager in each subsystem; starting the communication module in each subsystem (SS1-SS4) by the manager; and establishing a connection between the communication module of the main subsystem and the communication module in the corresponding auxiliary subsystem.

[0110] Figure 7A-7B The sequence diagram in can also be viewed as an example embodiment, in which a method for starting a medical device includes: obtaining, by a manager of the main subsystem, a software identifier of software included in the subsystem; and verifying, by the manager of the main subsystem, the compatibility of the software based on the software identifier.

[0111] Figure 7A-7B The sequence diagram in can also be viewed as an example embodiment, in which a method for starting a medical device includes: obtaining, by a manager of the main subsystem, a hardware identifier of hardware used by the subsystem; and verifying, by the manager of the main subsystem, the compatibility between the hardware and software based on the hardware identifier and the software identifier.

[0112] Figure 7C depicts a method performed by SS1 during subsystem startup and corresponds to Figure 6 II. Figure 7C In the SS1 software application, the individual software applications are generally denoted as SW1x. For illustration purposes only, Figure 7CThe GUI is also explicitly depicted, which is a software application responsible for graphical visualization on the display and managing user input. Preferably, the GUI is located in SS1 to ensure a quick start of user interaction. In step 720, SHM1 provides a startup request to the GUI and each SW1x (see step 401). In step 721, after obtaining the startup request, the GUI and each SW1x perform an internal startup. In some embodiments, the internal startup includes preparing the software application for communication with other parts of the same subsystem (i.e., communication between software applications or processes within the same subsystem). In step 722, when ready to start, the GUI and each SW1x provide a corresponding "application ready" notification N1 (see step 402). The notification can indicate that the software application is ready to communicate with other parts of the same subsystem. In step 723, SHM1 waits for N1 from the GUI and each SW1x. If SHM1 does not receive N1 within a timeout period, SHM1 can report a system error. In step 724, SHM1 determines that GUI and each SW1x are ready to start, that is, when they have provided the "application ready" notification. In step 725, SHM1 provides the "subsystem ready" notification N2 to GUI and each SW1x (see step 403). In step 726, after receiving N2, GUI and each SW1x enable communication with each other within SS1 (see step 404). This means that any software application configured to exchange data with another software application in SS1 must wait for N2 before starting data exchange. However, other functions of the corresponding software application can be activated before and / or after step 726. For example, the GUI can be configured so that it enables user interaction as soon as possible after step 726. However, in some embodiments, one or more (or all) software applications are configured to suspend their internal startup after providing N1 and wait for N2 before continuing their internal startup. In addition, before or after step 726, but in any case before step 727, the GUI and each SW1x are activated to send internal heartbeats within SS1. In step 727, SHM1 begins monitoring the internal heartbeat within SS1 to ensure that the GUI and each SW1x are operational. After step 727, SS1 is in state "Subsystem Ready" and proceeds to transition III.

[0113] Fig.7D The method performed by SS2-SS4 during subsystem startup is depicted and corresponds to Figure 6 II. Fig.7D In the example, the individual software applications of SS2-SS4 are usually represented as SW2x-SW4x respectively. Fig.7D Steps 720-727 in correspond to Figure 7C, except that they are performed in SS2-SS4 instead of SS1. In addition, in some embodiments and with Figure 7C In contrast to the method in , if N1 is not received within the timeout period, SHM2-SHM4 can avoid reporting an error in the system. Instead, since the absence of N1 means that N2 is not generated, SHM1 can be used during system startup, specifically in step 730 (see Fig. 7E ), the error can be detected. Figure 7C Description, according to Fig.7D Subsystem startup should be self-explanatory, so it will not be described further here. After step 727, SS2-SS4 is in state "Subsystem Ready" and continues to transition III.

[0114] Figure 7C-7D The method in is used to mitigate the risk that, for example, a software application starts communicating with another software application when the other software application is not ready to communicate. In this case, the other software application will not be able to receive or process incoming requests, and the software application that transmits the request cannot know this inability.

[0115] Figure 7C-7D The sequence diagram in can be seen as an example embodiment in which, during startup and for each subsystem, a method for starting a medical device includes: operating a software application to send an internal heartbeat signal; and starting monitoring the internal heartbeat signal by a manager to detect operational failures of one or more software applications.

[0116] Fig. 7E Describes the methods that are executed during system startup and corresponds to Figure 6 III. Fig. 7E In FIG. 7 , only SHM1-SHM4 and key software applications SW1c and SW3c are depicted, while any other software applications of SS1-SS4 are omitted. In step 730, when SS2-SS4 are ready, SHM1-SHM3 reports it to SHM1 by providing a "subsystem ready" notification N2. In practice, step 730 may be performed by Fig.7D 725 in the above subsystems, so it provides N2 inside and outside the corresponding subsystems SS1-SS4. In step 731, SHM1 waits for N2 from all SHM2-SHM4. If SHM1 does not receive N2 within the timeout period, SHM1 can report an error in the system. In step 732, SHM1 determines that all SS1-SS4 are ready to start (see Figure 4A It can be noted that at this stage SHM1 knows by default that SS1 is ready to start because it has completed Figure 7CIn step 733, SHM1 notifies all software applications in SS1 that the system is ready to start. In step 734, SHM1 begins sending external heartbeats in the system. In step 735, SHM1 provides a "system ready" notification N3 for SHM2-SHM4 to receive (see Figure 4B In step 736, after obtaining N3 (see Figure 4B In step 407), each of SHM2-SHM4 notifies all its software applications of the status "system is ready". In step 737, each of SHM2-SHM4 starts sending external heartbeats in the system. In step 738, each of SHM2-SHM4 provides a confirmation notification for SHM1 to receive. If SHM1 does not receive the confirmation notification within the timeout period, SHM1 can report an error in the system. In step 739, after receiving the confirmation notification from all SHM2-SHM4, SHM1 starts monitoring the external heartbeat in the system. At any time after step 737, the software applications in each of SS1-SS4 are allowed to establish a communication path between SS1-SS4 (see Figure 3 ) to initiate application-level communication with software applications in one or more other subsystems (see Figure 4B 408 in step 408).

[0117] Fig. 7E The example in also includes steps 740-741, which are performed only with respect to critical software applications SW1c and SW3c, and need to be completed before each of SW1c and SW3c is allowed to communicate with software applications in other subsystems. In step 740, SW1c / SW3c requests confirmation of the "system ready" status from SHM1 / SHM3. In step 741, SHM1 / SHM3 confirms the status to SWc1 / SW3c. This provides an additional level of robustness against failures that could compromise the safety of the patient.

[0118] To provide a further level of robustness, it is contemplated that step 737 in critical subsystem SS3 also involves SHM3 commencing monitoring of an external heartbeat generated by another critical subsystem SHM1. Thus, mutual monitoring of heartbeats is established between critical subsystems SS1, SS3, enabling the subsystems to quickly detect operational failures in other critical subsystems and take appropriate action.

[0119] Fig. 7EThe method in the invention is used to mitigate the risk that, for example, a first software application in one subsystem begins communicating with a second software application in another subsystem when the second software application is not yet ready to communicate. In this case, the second software application will not be able to receive or process the incoming request, and the first software application will not be aware of the problem at the receiving end.

[0120] Fig. 7E The sequence diagram in can be viewed as an example embodiment, in which a method for starting a medical device includes: operating the manager of the corresponding auxiliary subsystem to send an external heartbeat signal; and starting monitoring the external heartbeat signal by the manager of the main subsystem to detect operational failures of one or more auxiliary systems.

[0121] Fig. 7E The sequence diagram in can also be viewed as an example embodiment in which a method for starting a medical device includes: operating each manager of two or more critical subsystems to send an external heartbeat signal; and starting to mutually monitor the external heartbeat signal between the managers of the critical subsystems to detect an operational failure.

[0122] also, Figure 7C-7E The sequence diagram in can be regarded as an example embodiment, in which the method for starting a medical device during startup includes: when an "application ready" notification N1 is not received from the software application of the main subsystem within a first predetermined time period, a first error is reported by the manager in the main subsystem; when a "subsystem ready" notification N2 is not received from the auxiliary subsystem within a second predetermined time period, a second error is reported by the manager in the main subsystem.

[0123] Fig. 8A Describes the methods performed during system shutdown and corresponds to Figure 6 At the beginning of this method, it is assumed that the software system is up and running, so it is in Figure 6The example shown also assumes that SW3c has been registered as a "Shutdown Gatekeeper" of SHM1 and is therefore a subscriber to the "Shutdown" request. In step 801, the operator enters a command to shut down the medical device, for example by pressing a control button. The command is detected by the GUI, which provides a shutdown request for receipt by SHM1. In step 802, SHM1 forwards the shutdown request R1 for receipt by SW1c. In step 803, SW1c verifies R1. In step 804, after successful verification, SW1c provides R1 to SW3c. In step 805, SW3c verifies R1. After successful verification, SW3c enters a controlled state (step 806) and provides an "application shutdown ready" notification N7 for receipt by SW1c (step 807). After receiving N7, SW1c enters a controlled state (step 808) and forwards N7 to SHM1 (step 809). After receiving N7, SHM1 continues system shutdown.If the verification fails in step 803 and / or if SHM1 does not receive N7 within the timeout period in step 809, SHM1 may return a "shutdown not approved" notification to the GUI, which may then notify the operator accordingly.

[0124] The combination of steps 802-809 corresponds to Figure 5D The gatekeeping control method 520 is shown, and it is shown that neither R1 nor N7 need to be provided in the direct communication between SHM1 and the corresponding key software applications SW1c, SW3c, but R1 and N7 can be relayed in the form of a transmission chain. Figure 5D and Fig. 8A , step 521 may correspond to steps 802 and 804, step 522 may correspond to steps 803 and 805, step 523 may correspond to steps 807 and 809, and step 524 may correspond to steps 806 and 808. In a variant, N7 is not relayed in the transmission chain but is provided directly from SW3c to SHM1.

[0125] In step 810, SHM1 updates its status to "system not ready" by stopping application-level communication with SS2-SS4. In step 811, SHM1 stops monitoring external heartbeats, i.e., heartbeats generated by SS2-SS4. In step 812, SHM1 provides a "shutdown" notification N4 for SHM2-SHM4 to receive (see Figure 5A501 in SS3). In step 813, after receiving N4, each of SHM2-SHM4 updates its status to "system not ready" by stopping application-level communication with other subsystems. In step 814, each of SHM2-SHM4 stops sending external heartbeats. If the software system implements the above-mentioned mutual heartbeat monitoring between critical subsystems, step 814 in SS3 may also cause SHM3 to stop monitoring the external heartbeats generated by SHM1. In step 815, after completing steps 813-814, each of SHM2-SHM4 provides a "confirmation" notification N5 for SHM1 to receive. N5 signals SHM1 that the corresponding subsystem SS2-SS4 has received N4. In step 816, after receiving N5, SHM1 stops sending external heartbeats. If SHM1 does not receive N5 from all SS2-SS4 within the timeout period, SHM1 can report an error in the system.

[0126] Fig. 8A The method is used to mitigate the risk of an operator actively shutting down a medical device, for example, while the medical device is performing a medical procedure, particularly when interruption of the medical procedure could compromise the safety of the patient, and the risk of one critical subsystem or software application being ready to terminate while another critical subsystem or software application is not ready. For example, if the above protection system goes down while the medical procedure is continuing, the safety of the patient will be compromised.

[0127] Fig. 8A The sequence diagram in can be regarded as an example of an embodiment, in which a method for shutting down a medical device includes, before providing a "shutdown" notification N4 to the auxiliary subsystem: providing a shutdown request R1 to the first critical software application in a chain of critical software applications by the manager of the main subsystem, so that each critical software application in the chain verifies the shutdown request R1 according to the operation of the medical device, and if the shutdown is acceptable, providing the shutdown request R1 to the next critical software application in the chain, until the last critical software application in the chain receives the shutdown request R1; wherein the last critical software application in the chain verifies the shutdown request R1 according to the operation of the medical device, and if the shutdown is acceptable, causes an "application shutdown ready" notification N7 to be provided to the manager of the main subsystem. This conditional and sequential verification of the shutdown request R1 can be used to improve the robustness of the gate control method.

[0128] Fig. 8A The sequence diagram in can also be seen as an example embodiment in which, in a method for shutting down a medical device, an "application shutdown ready" notification N7 is relayed along the chain of critical software applications to the manager of the primary subsystem.

[0129] Fig. 8A The sequence diagram in can also be seen as an example embodiment, in which each key software application in the chain enters a controlled state upon receiving the "application shutdown ready" notification N7, in which the medical device operates according to a predetermined set of parameter values.

[0130] Figure 8B Describes the methods that are executed during subsystem shutdown and corresponds to Figure 6 The transformation in V. Figure 8B The method in can be used upon receiving the "close" notification N4 ( Fig. 8A 812 in step 820). Each SHM1-SHM4 stops monitoring the internal heartbeat. In step 821, each SHM1-SHM4 provides a "subsystem not ready" notification N6 to its software application (see Figure 5B-5C In step 822, after receiving N6, the software application prepares to terminate and stop the communication between the corresponding subsystems (see Figure 5B-5C In step 824, when ready to terminate, the corresponding software application SW1x-SW4x provides its manager SHM1-SHM4 with an "application shutdown ready" notification N7 (see Figure 5B-5C Optionally, as in step 508 Figure 8B As shown in step 823 in , N7 can be sent in response to a confirmation request from the manager SHM1-SHM4. In step 825, each of SHM1-SHM4 waits for N7 from all its software applications. If any of SHM1-SHM4 does not receive N7 from all its software applications within the timeout period, it can report an error in the system. In step 826, after completing step 825, SHM1 and SHM3 in the critical subsystems SS1, SS3 set the shutdown reason parameter to "normal" and store it in non-volatile memory. In step 827, each of SHM2-SHM4 provides SHM1 with a "subsystem shutdown ready" N8 (see Figure 5C 5. The software system has now been prepared for power loss at both the system level and the subsystem level.

[0131] As mentioned above Figure 5B-5C As illustrated by the example, Figure 8B The method in is used to mitigate the risk of power being cut off, for example, when a software application performs an activity that has consequential results.

[0132] Fig. 7A and Fig. 8AThe sequence diagram in can be viewed as an example embodiment, in which a method of operating a medical device includes: in the absence of an error during shutdown, setting a shutdown reason parameter by at least one manager to indicate a normal shutdown, and storing the shutdown reason parameter in a set of memory units. In addition, the method may include: during startup, setting a shutdown reason parameter by at least one manager to indicate a shutdown error, and storing the shutdown reason parameter in the set of memory units.

[0133] Figure 8C Describes a method performed during an execution exit of a software system and corresponds to Figure 6 After completing step 827, each of SS1-SS4 executes Figure 8C In step 830, each of SHM1-SHM4 waits for power to be lost while continuing to enable the corresponding hardware watchdog. It is impossible for any of SS1-SS4 to leave this state without losing power. At this stage, the system can be shut down safely. For example, in step 830, SHM1 can cause the medical device to lose power, for example, by generating a "power off" notification for the power manager of the medical device.

[0134] While the invention has been described in connection with what are presently considered to be the most practical and preferred embodiments, it should be understood that the invention is not limited to the disclosed embodiments, but on the contrary, the invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. A method of operating a medical device (10, 10'), the medical device (10, 10') being configured to perform a medical procedure and comprising a set of processors (P1-P4) and a set of memory units (M1, M2) storing a software system executed by the set of processors (P1-P4), the software system defining a plurality of subsystems (SS1-SS4), including a primary subsystem (SS1) and a set of secondary subsystems (SS2-SS4), wherein: Each subsystem (SS1-SS4) comprises a software application (SW1-SW4) involved in the operation of the medical device (10, 10') during a medical procedure, the method comprising, during startup of the medical device (10, 10'): Starting (401) each software application (SW2-SW4); providing (402) an application readiness notification (N1) by each software application (SW2-SW4) in the corresponding secondary subsystem (SS2; SS3; SS4) when ready to be started; When all software applications (SW2-SW4) of the corresponding auxiliary subsystem (SS2; SS3; SS4) have provided the application readiness notification (N1), the corresponding auxiliary subsystem (SS2; SS3; SS4) ； SS4) provides (403) a subsystem readiness notification (N2); as well as The primary subsystem (SS1) coordinates (405) the activation of the set of secondary subsystems (SS2-SS4) upon receipt of the subsystem readiness notification (N2), The coordination (405) includes: the primary subsystem (SS1) generating (406) a system readiness notification (N3) for reception by the secondary subsystem set (SS2-SS4), The coordination (405) also includes: when the system readiness notification (N3) is obtained (407), the corresponding auxiliary subsystem (SS2; SS3; SS4) enables communication between at least a subset of software applications (SW1; SW2; SW3; SW4) of different subsystems (SS1; SS2; SS3; SS4) in the multiple subsystems (SS1-SS4), so that the medical device (10, 10') is ready to perform at least part of the medical procedure.

2. The method according to claim 1, further comprising: In the corresponding subsystem (SS2; SS3; SS4): upon obtaining the subsystem readiness notification (N2), the software application (SW1; SW2; SW3; SW4) of the corresponding auxiliary subsystem (SS2; SS3; SS4) enables (404) the communication between the software applications (SW2; SW3; SW4) of the corresponding auxiliary subsystem (SS2; SS3; SS4).

3. The method according to claim 1, further comprising: The application readiness notification (N1) is provided (402) by the corresponding software application (SW1) in the primary subsystem (SS1) when it is ready to start, wherein the coordination (405) is performed by the primary subsystem (SS1) when the subsystem readiness notification (N2) is received from the corresponding secondary subsystem (SS2-SS4) and the application readiness notification (N1) is received from the corresponding software application (SW1) in the primary subsystem (SS1).

4. The method according to claim 3, wherein: The manager (SHM1) in the primary subsystem (SS1) receives the subsystem readiness notification (N2) from the corresponding secondary subsystem (SS2-SS4), and receives the application readiness notification (N1) from the corresponding software application (SW1) in the primary subsystem (SS1), and performs the coordination (405).

5. The method according to claim 1, wherein: The corresponding auxiliary subsystem (SS2; SS3; SS4) also includes a manager (SHM2-SHM4), wherein the manager (SHM2-SHM4) of the corresponding auxiliary subsystem (SS2; SS3; SS4) provides the subsystem readiness notification (N2) when the application readiness notification (N1) is obtained from all its software applications (SW2-SW4).

6. The method according to claim 5, wherein: The coordination (405) includes: the manager (SHM1) of the main subsystem (SS1) provides a system readiness notification (N3) to the corresponding auxiliary subsystem (SS2-SS4) when obtaining the application readiness notification (N1) from each software application (SW1) of the main subsystem (SS1) and obtaining the subsystem readiness notification (N2) from the corresponding auxiliary subsystem (SS2-SS4).

7. The method according to claim 6, further comprising: The corresponding auxiliary subsystem (SS2; SS3 ； The managers (SHM2-SHM4) of the master subsystem (SS4) enable different subsystems (SS1; SS1; SS2; SS2; SS4) of the master subsystem (SS1) when obtaining (407) the system readiness notification (N3) and the manager (SHM1) of the master subsystem (SS1) enables different subsystems (SS1; SS1; SS2; SS2; SS4) of the master subsystem (SS1); SS2; SS3; SS4) so ​​that the medical device (10, 10') is ready to perform at least part of a medical procedure.

8. The method according to claim 7, wherein: The software system defines at least two auxiliary subsystems (SS2-SS4), and wherein different subsystems (SS1; SS2; SS3; The communication between at least a subset of the software applications (SW1; SW2; SW3; SW4) of the at least two auxiliary subsystems (SS2-SS4) comprises: enabling the software applications (SW2; SW3; SW4) in the at least two auxiliary subsystems (SS2-SS4) SW4) for direct communication between at least a subset of the SW4).

9. A method according to any one of the preceding claims, wherein: The subsystems (SS1-SS4) execute on separate processors in the set of processors (P1-P4).

10. The method according to any one of claims 1 to 3, wherein: Two or more subsystems (SS1, SS3) are critical to a medical procedure performed by the medical device (10, 10') and include respective managers (SHM1, SHM3), and the method further comprises, during the start-up: operating each manager (SHM1, SHM3) of the two or more subsystems (SS1, SS3) to send an external heartbeat signal; as well as Mutual monitoring of external heartbeat signals between managers (SHM1, SHM3) of the two or more subsystems (SS1, SS3) is initiated to detect operational failures.

11. The method of claim 4, further comprising, during said starting: When the application readiness notification (N1) is not received from the corresponding software application (SW1) of the main subsystem (SS1) within a first predetermined time period, a first error is reported by a manager (SHM1) in the main subsystem (SS1); as well as When no data is received from the corresponding auxiliary subsystem (SS2; SS3) within a second predetermined period of time ； When SS4) receives the subsystem readiness notification (N2), the manager (SHM1) in the main subsystem (SS1) reports a second error.

12. The method according to any one of claims 1 to 3, comprising: During the closing of the medical device (10, 10'): The manager (SHM1) of the main subsystem (SS1) provides (501) a shutdown notification (N4) to the auxiliary subsystem set (SS2-SS4); A request (502) by a manager (SHM1) of the master subsystem (SS1) to terminate a software application (SW1) of the master subsystem; as well as After obtaining the shutdown notification (N4), the manager (SHM2; SHM3; SHM4) of the corresponding auxiliary subsystem (SS2; SS3; SS4) requests (503) to terminate the software application (SW2; SW3; SW4) of the corresponding auxiliary subsystem (SS2; SS3; SS4).

13. The method according to claim 12, wherein: The request (503) to terminate the software application (SW2; SW3; SW4) of the corresponding auxiliary subsystem (SS2; SS3; SS4) comprises, for at least one auxiliary subsystem (SS2; SS3; SS4): The manager (SHM2; SHM3; SHM4) provides (505) a subsystem not ready notification (N6) to the software application (SW2; SW3; SW4) of the auxiliary subsystem (SS2; SS3; SS4); Upon obtaining (506) the subsystem not-ready notification (N6), at least a subset of the software applications (SW2; SW3; SW4) of the auxiliary subsystem (SS2; SS3; SS4) prepares (507) for termination; When ready to terminate, providing (508) an application shutdown readiness notification (N7) by at least a subset of the software applications (SW2; SW3; SW4); as well as When the application shutdown readiness notification (N7) is obtained (509) from at least a subset of the software applications (SW2; SW3; SW4), the manager (SHM2; SHM3; SHM4) of the auxiliary subsystem (SS2; SS3; SS4) provides (510) a subsystem shutdown readiness notification (N8) to the manager (SHM1) of the main subsystem (SS1).

14. The method according to claim 13, wherein: The request (502) to terminate the software application (SW1) of the primary subsystem (SS1) comprises: providing (505) a subsystem not ready notification (N6) by a manager (SHM1) of the master subsystem (SS1) to a software application (SW1) of the master subsystem (SS1); preparing (507) for termination by at least a subset of the software applications (SW1) of the master subsystem (SS1) upon obtaining (506) the subsystem not ready notification (N6); and An application shutdown readiness notification (N7) is provided (508) by the at least a subset of the software applications (SW1) of the primary subsystem (SS1) when ready to terminate.

15. The method according to claim 14, further comprising: The power loss of the medical device (10, 10') is initiated by the manager (SHM1) of the main subsystem (SS1) when the subsystem shutdown readiness notification (N8) is obtained from the at least one auxiliary subsystem (SS2-SS4) and the application shutdown readiness notification (N7) is obtained from the at least one subset of the software applications (SW1) of the main subsystem (SS1).

16. The method according to claim 12, comprising: In the absence of an error during the shutdown, at least one manager (SHM1-SHM4) sets a shutdown reason parameter for indicating a normal shutdown, and stores the shutdown reason parameter in the memory unit set (M1, M2); and during the startup, at least one manager (SHM1-SHM4) sets a shutdown reason parameter for indicating a shutdown error, and stores the shutdown reason parameter in the memory unit set (M1, M2).

17. The method according to claim 12, wherein: The software applications (SW1-SW4) include one or more software applications (SW1c, SW3c) that are critical to a medical procedure performed by the medical device (10, 10'), the method further comprising, during shutdown of the medical device (10, 10') and before providing the shutdown notification (N4) to the set of secondary subsystems (SS2-SS4): providing (521) a shutdown request (R1) by a manager (SHM1) of the master subsystem (SS1) for the one or more software applications (SW1c, SW3c) that are critical to a medical procedure performed by the medical device (10, 10'); verifying (522) the shutdown request (R1) by the one or more software applications (SW1c, SW3c) critical to a medical procedure performed by the medical device (10, 10') based on operation of the medical device (10, 10'); and providing (523) an application shutdown readiness notification (N7) by at least one of the one or more software applications (SW1c, SW3c) that are critical to a medical procedure performed by the medical device (10, 10'); Wherein, the manager (SHM1) of the main subsystem (SS1) provides (501) the shutdown notification (N4) to the auxiliary subsystem set (SS2-SS4) when obtaining the application shutdown readiness notification (N7) from at least one of the one or more software applications (SW1c, SW3c) that are critical to the medical procedure performed by the medical device (10, 10').

18. The method according to any one of claims 1 to 8, wherein: The multiple subsystems (SS1-SS4) include a first subsystem (SS1) having a software application (SW1c) for controlling a medical device (10, 10') to perform a medical procedure, and a second subsystem (SS2) having a software application for communicating with an actuator (17) and / or a sensor (18) of the medical device (10, 10'), wherein the coordination (405) enables communication between the software application (SW1c) for controlling the medical device (10, 10') and the software application for communication.

19. The method according to claim 18, wherein: The multiple subsystems (SS1-SS4) also include a third subsystem (SS3) having a software application (SW3c) for supervising medical procedures to detect deviations, and a fourth subsystem (SS4) having a software application for communicating with an auxiliary sensor (18) of the medical device (10, 10'), wherein the coordination also enables communication between the software application (SW3c) for supervising medical procedures and the software application for communicating with the auxiliary sensor (18), and communication between the software application (SW1c) for controlling the medical device (10, 10') and the software application (SW3c) for supervising medical procedures.

20. A medical device for performing a medical procedure, comprising: The set of processors (P1-P4), and a set of memory units (M1, M2) storing a software system executed by said set of processors (P1-P4), wherein the software system, when executed by the set of processors (P1-P4), operates the medical device to perform a medical procedure, wherein the software system defines a plurality of subsystems (SS1-SS4) including a primary subsystem SS1) and a set of secondary subsystems (SS2-SS4), wherein each subsystem (SS1-SS4) includes a software application (SW1-SW4) involved in the operation of the medical device (10, 10') during a medical procedure, and Wherein, when the software system is executed by the processor set (P1-P4), it performs the method according to any one of claims 1-19.

21. A computer readable medium comprising a software system for operating a medical device (10, 10') to perform a medical procedure, the software system defining a plurality of subsystems (SS1-SS4), including a primary subsystem SS1) and a set of secondary subsystems (SS2-SS4), wherein: Each subsystem (SS1-SS4) comprises a software application (SW1-SW4) involved in the operation of the medical device (10, 10') during a medical procedure, wherein the software system, when executed by a set of processors (P1-P4) of the medical device (10, 10'), performs a method according to any one of claims 1-19.

Images