Patent Description:
Infusion pump devices and systems are relatively well known in the medical arts, for use in delivering or dispensing an agent, such as insulin or another prescribed medication, to a patient. A typical infusion pump includes a pump drive system which typically includes a small motor and drive train components that convert rotational motor motion to a translational displacement of a plunger (or stopper) in a reservoir that delivers medication from the reservoir to the body of a user via a fluid path created between the reservoir and the body of a user. Use of infusion pump therapy has been increasing, especially for delivering insulin for diabetics.

Different infusion pump devices may have different form factors, constraints, or otherwise utilize different techniques, which result in the particular type of actuator most suitable for the drive system varying from one type of infusion pump device to the next. Often, this also entails using a different controller that is designed or otherwise configured for use with a particular type of actuator. Alternatively, a common type of microcontroller or similar processing module could be utilized across different devices and actuators by being programmed to support the particular type of actuator deployed therewith; however, this often requires a sufficient number of general purpose input/output terminals to support the different potential types of actuators, which, in turn increases the size of the microcontroller package. Accordingly, it is desirable to provide an actuator control module that is extensible for use with different types of actuators without the drawbacks associated with existing approaches. Other desirable features and characteristics will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and this background.

<CIT> discloses an actuator comprising an interface to receive a PWM signal representing a desired reference current and a controller that decodes the PWM signal to control operation of the actuator and to provide power to operate the actuator.

Electromechanical actuation devices, systems, and methods suitable for use in medical devices or systems, such as an infusion device or infusion system, are provided.

An electromechanical actuator driver module is provided comprising:
a terminal to receive an input command signal; command logic coupled to the terminal to convert the input command signal to an actuation command; and decoding logic coupled to the command logic to generate a driver command for a selected type of electromechanical actuator based on the actuation command; wherein the decoding logic comprises: a plurality of driver command modules to generate a respective driver command based on the actuation command, wherein each driver command module of the plurality of driver command modules corresponds to a different one of a plurality of types of electromechanical actuators; and logic circuitry coupled to the plurality of driver command modules to enable a selected driver command module of the driver command modules corresponding to the selected type of actuator.

A method of controlling an electromechanical actuator in response to an input command signal at an input terminal is provided, the method comprising: determining a commanded actuation state value based on a characteristic of the input command signal; generating driver command signals based on the commanded actuation state value and an actuator type associated with the electromechanical actuator; and operating driver circuitry in accordance with the driver command signals to provide output signals at output terminals coupled to the electromechanical actuator. The method further comprises: identifying the actuator type as being selected from among a plurality of actuator types associated with a driver module comprising the input terminal and the output terminals; and enabling a driver command module associated with the actuator type to generate the driver command signals based on the commanded actuation state value.

A more complete understanding of the subject matter may be derived by referring to the detailed description and claims when considered in conjunction with the following figures, wherein like reference numbers refer to similar elements throughout the figures, which may be illustrated for simplicity and clarity and are not necessarily drawn to scale.

While the subject matter described herein can be implemented in any electronic device that includes an electromechanical actuator, exemplary embodiments of the subject matter described herein are implemented in conjunction with medical devices, such as portable electronic medical devices. Although many different applications are possible, the following description focuses on embodiments that incorporate a fluid infusion device (or infusion pump) as part of an infusion system deployment. That said, the subject matter described herein is not limited to infusion devices (or any particular configuration or realization thereof) and may be implemented in an equivalent manner in the context of multiple daily injection (MDI) therapy regimen or other medical devices, such as continuous glucose monitoring (CGM) devices, injection pens (e.g., smart injection pens), and the like. For the sake of brevity, conventional techniques related to infusion system operation, insulin pump and/or infusion set operation, and other functional aspects of the systems (and the individual operating components of the systems) may not be described in detail here. Examples of infusion pumps may be of the type described in, but not limited to, <CIT>; <CIT>; <CIT>; <CIT>; <CIT>; <CIT>; <CIT>; <CIT>; <CIT>; <CIT>; <CIT>; <CIT>; <CIT>; <CIT>; and <CIT>; each of which are herein incorporated by reference.

Generally, a fluid infusion device includes a motor or other actuation arrangement that is operable to displace a plunger (or stopper) or other delivery mechanism to deliver a dosage of fluid, such as insulin, from a reservoir provided within the fluid infusion device to the body of a patient. Dosage commands that govern actuation may be generated in an automated manner in accordance with the delivery control scheme associated with a particular operating mode, and the dosage commands may be generated in a manner that is influenced by a current (or most recent) measurement of a physiological condition in the body of the user. For example, in a closed-loop operating mode, dosage commands may be generated based on a difference between a current (or most recent) measurement of the interstitial fluid glucose level in the body of the user and a target (or reference) glucose value. In this regard, the rate of infusion may vary as the difference between a current measurement value and the target measurement value fluctuates. For purposes of explanation, the subject matter is described herein in the context of the infused fluid being insulin for regulating a glucose level of a user (or patient); however, it should be appreciated that many other fluids may be administered through infusion, and the subject matter described herein is not necessarily limited to use with insulin.

As described in greater detail below primarily in the context of <FIG>, exemplary embodiments described herein employ an electromechanical actuation module that is extensible and capable of supporting any number of different types of electromechanical actuators. In this regard, the electromechanical actuation module may be deployed across different types or configurations of fluid infusion devices that use different types of electromechanical actuators (e.g., brushless direct current (BLDC) motors, brushed direct current (BDC) motors, stepper motors, shape-memory alloy actuators, etc.). The electromechanical actuation module includes an individual input terminal for receiving an input command signal and command logic circuitry that maps or otherwise converts the input command signal to a commanded actuation. The electromechanical actuation module also includes decoding logic that is coupled to the command logic circuitry that generates a corresponding driver command for achieving the commanded actuation for the particular type of actuator that the electromechanical actuation module. The driver command is provided to driver circuitry of the electromechanical actuation module, which, in turn generates corresponding output voltage signals that are applied or otherwise provided to the appropriate inputs of the electromechanical actuator. In this regard, the driver command generated by the decoding logic and the corresponding output voltage signals for a given commanded actuation state will vary depending upon the selected type of actuator to be supported.

In exemplary embodiments, the input command signal is realized as a pulsewidth modulation (PWM) voltage signal having a variable duty cycle. The command logic circuitry measures the width (or duration) of the duty cycle and thereby converting the duty cycle into a discrete digital representation that is provided to the decoding logic. In exemplary embodiments, electromechanical actuation module includes additional safety logic that disables additional actuation when the input command signal is maintained constant, for example, by providing a commanded actuation state value that results in the driver circuitry grounding or otherwise providing a high impedance at the inputs of the electromechanical actuator. This eliminates the need for a dedicated enable signal for the electromechanical actuation module while also preventing a runaway condition that could otherwise result if an anomalous condition resulted in a static input command signal.

<FIG> depicts one exemplary embodiment of an infusion system <NUM> that includes, without limitation, a fluid infusion device (or infusion pump) <NUM>, a sensing arrangement <NUM>, a command control device (CCD) <NUM>, and a computer <NUM>. The components of an infusion system <NUM> may be realized using different platforms, designs, and configurations, and the embodiment shown in <FIG> is not exhaustive or limiting. In practice, the infusion device <NUM> and the sensing arrangement <NUM> are secured at desired locations on the body of a user (or patient), as illustrated in <FIG>. In this regard, the locations at which the infusion device <NUM> and the sensing arrangement <NUM> are secured to the body of the user in <FIG> are provided only as a representative, non-limiting, example. The elements of the infusion system <NUM> may be similar to those described in <CIT>, the subject matter of which is hereby incorporated by reference in its entirety.

In the illustrated embodiment of <FIG>, the infusion device <NUM> is designed as a portable medical device suitable for infusing a fluid, a liquid, a gel, or other medicament into the body of a user. In exemplary embodiments, the infused fluid is insulin, although many other fluids may be administered through infusion such as, but not limited to, HIV drugs, drugs to treat pulmonary hypertension, iron chelation drugs, pain medications, anticancer treatments, medications, vitamins, hormones, or the like. In some embodiments, the fluid may include a nutritional supplement, a dye, a tracing medium, a saline medium, a hydration medium, or the like.

The sensing arrangement <NUM> generally represents the components of the infusion system <NUM> configured to sense, detect, measure or otherwise quantify a condition of the user, and may include a sensor, a monitor, or the like, for providing data indicative of the condition that is sensed, detected, measured or otherwise monitored by the sensing arrangement. In this regard, the sensing arrangement <NUM> may include electronics and enzymes reactive to a biological condition, such as a blood glucose level, or the like, of the user, and provide data indicative of the blood glucose level to the infusion device <NUM>, the CCD <NUM> and/or the computer <NUM>. For example, the infusion device <NUM>, the CCD <NUM> and/or the computer <NUM> may include a display for presenting information or data to the user based on the sensor data received from the sensing arrangement <NUM>, such as, for example, a current glucose level of the user, a graph or chart of the user's glucose level versus time, device status indicators, alert messages, or the like. In other embodiments, the infusion device <NUM>, the CCD <NUM> and/or the computer <NUM> may include electronics and software that are configured to analyze sensor data and operate the infusion device <NUM> to deliver fluid to the body of the user based on the sensor data and/or preprogrammed delivery routines. Thus, in exemplary embodiments, one or more of the infusion device <NUM>, the sensing arrangement <NUM>, the CCD <NUM>, and/or the computer <NUM> includes a transmitter, a receiver, and/or other transceiver electronics that allow for communication with other components of the infusion system <NUM>, so that the sensing arrangement <NUM> may transmit sensor data or monitor data to one or more of the infusion device <NUM>, the CCD <NUM> and/or the computer <NUM>.

Still referring to <FIG>, in various embodiments, the sensing arrangement <NUM> may be secured to the body of the user or embedded in the body of the user at a location that is remote from the location at which the infusion device <NUM> is secured to the body of the user. In various other embodiments, the sensing arrangement <NUM> may be incorporated within the infusion device <NUM>. In other embodiments, the sensing arrangement <NUM> may be separate and apart from the infusion device <NUM>, and may be, for example, part of the CCD <NUM>. In such embodiments, the sensing arrangement <NUM> may be configured to receive a biological sample, analyte, or the like, to measure a condition of the user.

In some embodiments, the CCD <NUM> and/or the computer <NUM> may include electronics and other components configured to perform processing, delivery routine storage, and to control the infusion device <NUM> in a manner that is influenced by sensor data measured by and/or received from the sensing arrangement <NUM>. By including control functions in the CCD <NUM> and/or the computer <NUM>, the infusion device <NUM> may be made with more simplified electronics. However, in other embodiments, the infusion device <NUM> may include all control functions, and may operate without the CCD <NUM> and/or the computer <NUM>. In various embodiments, the CCD <NUM> may be a portable electronic device. In addition, in various embodiments, the infusion device <NUM> and/or the sensing arrangement <NUM> may be configured to transmit data to the CCD <NUM> and/or the computer <NUM> for display or processing of the data by the CCD <NUM> and/or the computer <NUM>.

In some embodiments, the CCD <NUM> and/or the computer <NUM> may provide information to the user that facilitates the user's subsequent use of the infusion device <NUM>. For example, the CCD <NUM> may provide information to the user to allow the user to determine the rate or dose of medication to be administered into the user's body. In other embodiments, the CCD <NUM> may provide information to the infusion device <NUM> to autonomously control the rate or dose of medication administered into the body of the user. In some embodiments, the sensing arrangement <NUM> may be integrated into the CCD <NUM>. Such embodiments may allow the user to monitor a condition by providing, for example, a sample of his or her blood to the sensing arrangement <NUM> to assess his or her condition. In some embodiments, the sensing arrangement <NUM> and the CCD <NUM> may be used for determining glucose levels in the blood and/or body fluids of the user without the use of, or necessity of, a wire or cable connection between the infusion device <NUM> and the sensing arrangement <NUM> and/or the CCD <NUM>.

In some embodiments, the sensing arrangement <NUM> and/or the infusion device <NUM> are cooperatively configured to utilize a closed-loop system for delivering fluid to the user. Examples of sensing devices and/or infusion pumps utilizing closed-loop systems may be found at, but are not limited to, the following <CIT><CIT><CIT><CIT><CIT><CIT>and <CIT> or <CIT>, all of which are incorporated herein by reference in their entirety. In such embodiments, the sensing arrangement <NUM> is configured to sense or measure a condition of the user, such as, blood glucose level or the like. The infusion device <NUM> is configured to deliver fluid in response to the condition sensed by the sensing arrangement <NUM>. In turn, the sensing arrangement <NUM> continues to sense or otherwise quantify a current condition of the user, thereby allowing the infusion device <NUM> to deliver fluid continuously in response to the condition currently (or most recently) sensed by the sensing arrangement <NUM> indefinitely. In some embodiments, the sensing arrangement <NUM> and/or the infusion device <NUM> may be configured to utilize the closed-loop system only for a portion of the day, for example only when the user is asleep or awake.

<FIG> depicts an exemplary embodiment of a control system <NUM> suitable for use with an infusion device <NUM>, such as the infusion device <NUM> described above. The control system <NUM> is capable of controlling or otherwise regulating a physiological condition in the body <NUM> of a patient to a desired (or target) value or otherwise maintain the condition within a range of acceptable values in an automated or autonomous manner. In one or more exemplary embodiments, the condition being regulated is sensed, detected, measured or otherwise quantified by a sensing arrangement <NUM> (e.g., sensing arrangement <NUM>) communicatively coupled to the infusion device <NUM>. However, it should be noted that in alternative embodiments, the condition being regulated by the control system <NUM> may be correlative to the measured values obtained by the sensing arrangement <NUM>. That said, for clarity and purposes of explanation, the subject matter may be described herein in the context of the sensing arrangement <NUM> being realized as a glucose sensing arrangement that senses, detects, measures or otherwise quantifies the patient's glucose level, which is being regulated in the body <NUM> of the patient by the control system <NUM>.

In exemplary embodiments, the sensing arrangement <NUM> includes one or more interstitial glucose sensing elements that generate or otherwise output electrical signals (alternatively referred to herein as measurement signals) having a signal characteristic that is correlative to, influenced by, or otherwise indicative of the relative interstitial fluid glucose level in the body <NUM> of the patient. The output electrical signals are filtered or otherwise processed to obtain a measurement value indicative of the patient's interstitial fluid glucose level. In some embodiments, a blood glucose meter <NUM>, such as a finger stick device, is utilized to directly sense, detect, measure or otherwise quantify the blood glucose in the body <NUM> of the patient. In this regard, the blood glucose meter <NUM> outputs or otherwise provides a measured blood glucose value that may be utilized as a reference measurement for calibrating the sensing arrangement <NUM> and converting a measurement value indicative of the patient's interstitial fluid glucose level into a corresponding calibrated blood glucose value. For purposes of explanation, the calibrated blood glucose value calculated based on the electrical signals output by the sensing element(s) of the sensing arrangement <NUM> may alternatively be referred to herein as the sensor glucose value, the sensed glucose value, or variants thereof.

Although not illustrated in <FIG>, practical embodiments of the control system <NUM> may include one or more additional sensing arrangements configured to sense, detect, measure or otherwise quantify a characteristic of the body of the patient that is indicative of a condition in the body of the patient. For example, in addition to the glucose sensing arrangement <NUM>, one or more auxiliary sensing arrangements may be worn, carried, or otherwise associated with the body <NUM> of the patient to measure characteristics or conditions that may influence the patient's glucose levels or insulin sensitivity, such as a heart rate sensor (or monitor), a lactate sensor, a ketone sensor, an acceleration sensor (or accelerometer), an environmental sensor, and/or the like.

In the illustrated embodiment, the pump control system <NUM> generally represents the electronics and other components of the infusion device <NUM> that control operation of the fluid infusion device <NUM> according to a desired infusion delivery program in a manner that is influenced by the sensed glucose value indicating the current glucose level in the body <NUM> of the patient. For example, to support a closed-loop operating mode, the pump control system <NUM> maintains, receives, or otherwise obtains a target or commanded glucose value, and automatically generates or otherwise determines dosage commands for operating an electromechanical actuator <NUM> (e.g., a BLDC motor, a BDC motor, a stepper motor, a shape-memory alloy actuators, or the like) to displace the plunger <NUM> and deliver insulin to the body <NUM> of the patient based on the difference between the sensed glucose value and the target glucose value. In other operating modes, the pump control system <NUM> may generate or otherwise determine dosage commands configured to maintain the sensed glucose value below an upper glucose limit, above a lower glucose limit, or otherwise within a desired range of glucose values. In practice, the infusion device <NUM> may store or otherwise maintain the target value, upper and/or lower glucose limit(s), insulin delivery limit(s), and/or other glucose threshold value(s) in a data storage element accessible to the pump control system <NUM>. As described in greater detail, in one or more exemplary embodiments, the pump control system <NUM> automatically adjusts or adapts one or more parameters or other control information used to generate commands for operating the electromechanical actuator <NUM> in a manner that accounts for a likely change in the patient's glucose level or insulin response resulting from a meal, exercise, or other activity.

Still referring to <FIG>, the target glucose value and other threshold glucose values utilized by the pump control system <NUM> may be received from an external component (e.g., CCD <NUM> and/or computing device <NUM>) or be input by a patient via a user interface element <NUM> associated with the infusion device <NUM>. In practice, the one or more user interface element(s) <NUM> associated with the infusion device <NUM> typically include at least one input user interface element, such as, for example, a button, a keypad, a keyboard, a knob, a joystick, a mouse, a touch panel, a touchscreen, a microphone or another audio input device, and/or the like. Additionally, the one or more user interface element(s) <NUM> include at least one output user interface element, such as, for example, a display element (e.g., a light-emitting diode or the like), a display device (e.g., a liquid crystal display or the like), a speaker or another audio output device, a haptic feedback device, or the like, for providing notifications or other information to the patient. It should be noted that although <FIG> depicts the user interface element(s) <NUM> as being separate from the infusion device <NUM>, in practice, one or more of the user interface element(s) <NUM> may be integrated with the infusion device <NUM>. Furthermore, in some embodiments, one or more user interface element(s) <NUM> are integrated with the sensing arrangement <NUM> in addition to and/or in alternative to the user interface element(s) <NUM> integrated with the infusion device <NUM>. The user interface element(s) <NUM> may be manipulated by the patient to operate the infusion device <NUM> to deliver correction boluses, adjust target and/or threshold values, modify the delivery control scheme or operating mode, and the like, as desired.

Still referring to <FIG>, in the illustrated embodiment, the infusion device <NUM> includes an actuator control module <NUM> coupled to an electromechanical actuator driver module <NUM>, which, in turn, is coupled to the electromechanical actuator <NUM> that is operable to displace a plunger <NUM> in a reservoir and provide a desired amount of fluid to the body <NUM> of a patient. In this regard, displacement of the plunger <NUM> results in the delivery of a fluid, such as insulin, that is capable of influencing the patient's physiological condition to the body <NUM> of the patient via a fluid delivery path (e.g., via tubing of an infusion set). The electromechanical actuator driver module <NUM> is coupled between an energy source <NUM> and the electromechanical actuator <NUM>, and the actuator control module <NUM> generates or otherwise provides command signals that operate the electromechanical actuator driver module <NUM> to provide current (or power) from the energy source <NUM> to the electromechanical actuator <NUM> to displace the plunger <NUM> in response to receiving, from a pump control system <NUM>, a dosage command indicative of the desired amount of fluid to be delivered.

In exemplary embodiments, the energy source <NUM> is realized as a battery housed within the infusion device <NUM> that provides direct current (DC) power. In this regard, the electromechanical actuator driver module <NUM> generally represents the combination of logic circuitry, hardware and/or other electrical components configured to convert or otherwise transfer DC power provided by the energy source <NUM> into alternating electrical signals applied to inputs of the electromechanical actuator <NUM> (e.g., respective phases of the stator windings of a motor) that result in current flow that causes the electromechanical actuator <NUM> to displace the plunger <NUM>. For example, the actuator driver module <NUM> may generate voltage signals applied to the phases of stator windings of a motor that result in current flow through the stator windings that generates a stator magnetic field and causes a rotor of the motor to rotate.

The actuator control module <NUM> is configured to receive or otherwise obtain a commanded dosage from the pump control system <NUM>, convert the commanded dosage to a commanded translational displacement of the plunger <NUM>, and command, signal, or otherwise operate the electromechanical actuator driver module <NUM> to cause actuation of the electromechanical actuator <NUM> by an amount that produces the commanded translational displacement of the plunger <NUM>. For example, the actuator control module <NUM> may determine an amount of rotation of the rotor required to produce translational displacement of the plunger <NUM> that achieves the commanded dosage received from the pump control system <NUM>. The actuator control module <NUM> monitors the current actuation state indicated by the output of a sensing arrangement <NUM> (e.g., the rotational position (or orientation) of the rotor with respect to the stator of a motor that is indicated by a rotor sensing arrangement) and provides one or more command signals to the actuator driver module <NUM> until achieving the desired amount of actuation, and thereby the desired delivery of fluid to the patient.

For example, using a BLDC motor as the actuator <NUM>, the actuator control module <NUM> receives the current rotor position measurement data from the sensing arrangement <NUM> and determines the desired rotor configuration or orientation corresponding to the desired delivery of fluid relative to the current rotor position using a lookup table. The actuator control module <NUM> then provides a PWM voltage signal to the actuator driver module <NUM> having a fixed frequency with a duty cycle that corresponds to the desired rotor position using another lookup table. As the measured rotor position changes, the actuator control module <NUM> dynamically updates the duty cycle of the PWM voltage signal as appropriate to move the rotor position from one state to another in the desired manner. For example, the actuator control module <NUM> may provide the PWM voltage signal with a duty cycle of <NUM>% to move the rotor to an orientation of <NUM> degrees, followed by a duty cycle of <NUM>% to move the rotor from the orientation of <NUM> degrees to an orientation of <NUM> degrees. Once the rotor reaches the desired position, the actuator control module <NUM> may maintain the duty cycle at the percentage corresponding to that position to hold or otherwise maintain the rotor at that particular angular orientation.

As described in greater detail below in the context of <FIG>, in exemplary embodiments, the actuator control module <NUM> provides an input voltage signal having a duty cycle corresponding to an angle of rotation of the electromechanical actuator <NUM> (and corresponding displacement of the plunger <NUM>) for achieving the commanded rotation angle. In such embodiments, the actuator driver module <NUM> needs only a single input terminal for receiving the input command signal from the actuator control module <NUM>. The actuator driver module <NUM> includes logic configured to convert the input duty cycle into the appropriate electrical signals to be applied to the electromechanical actuator <NUM> to achieve the desired actuation (or commutation) state corresponding to the input duty cycle and then applies those electrical signals to the inputs of the electromechanical actuator <NUM>. For example, where the electromechanical actuator <NUM> is realized as a BLDC motor, the actuator driver module <NUM> applies voltage signals to commutate the respective phases of the stator windings at the appropriate orientation of the rotor magnetic poles with respect to the stator and in the appropriate order to provide a rotating stator magnetic field that rotates the rotor in the desired direction by the commanded amount.

In some embodiments, after the actuator control module <NUM> operates the electromechanical actuator driver module <NUM> and/or electromechanical actuator <NUM> to achieve the commanded rotation angle, the actuator control module <NUM> ceases operating the electromechanical actuator driver module <NUM> and/or electromechanical actuator <NUM> until a subsequent rotation angle command is received. As described in greater detail below in the context of <FIG> and <FIG>, to put the electromechanical actuator <NUM> into an idle state, the actuator control module <NUM> may provide a fixed or constant input command signal (e.g., a duty cycle of <NUM>% or <NUM>%), which, in turn, results in the electromechanical actuator driver module <NUM> allowing the inputs of the electromechanical actuator <NUM> to be grounded or otherwise enter a high impedance state during which the electromechanical actuator driver module <NUM> effectively disconnects or isolates the electromechanical actuator <NUM> from the energy source <NUM>.

Depending on the embodiment, the actuator control module <NUM> may be implemented or realized with a general purpose processor, a microprocessor, a controller, a microcontroller, a state machine, a content addressable memory, an application specific integrated circuit, a field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. In exemplary embodiments, the actuator control module <NUM> includes or otherwise accesses a data storage element or memory, including any sort of random access memory (RAM), read only memory (ROM), flash memory, registers, hard disks, removable disks, magnetic or optical mass storage, or any other short or long term storage media or other non-transitory computer-readable medium, which is capable of storing programming instructions for execution by the actuator control module <NUM>. The computer-executable programming instructions, when read and executed by the actuator control module <NUM>, cause the actuator control module <NUM> to perform or otherwise support the tasks, operations, functions, and processes described herein.

It should be appreciated that <FIG> is a simplified representation of the infusion device <NUM> for purposes of explanation and is not intended to limit the subject matter described herein in any way. In this regard, depending on the embodiment, some features and/or functionality of the sensing arrangement <NUM> may implemented by or otherwise integrated into the pump control system <NUM>, or vice versa. Similarly, in practice, the features and/or functionality of the actuator control module <NUM> may implemented by or otherwise integrated into the pump control system <NUM>, or vice versa. Furthermore, the features and/or functionality of the pump control system <NUM> may be implemented by control electronics located in the fluid infusion device <NUM>, while in alternative embodiments, the pump control system <NUM> may be implemented by a remote computing device that is physically distinct and/or separate from the infusion device <NUM>, such as, for example, the CCD <NUM> or the computing device <NUM>.

<FIG> depicts an exemplary embodiment of an electromechanical actuator driver module <NUM> suitable for use with any number of different types of electromechanical actuators. In this regard, the electromechanical actuator driver module <NUM> may be utilized as an electromechanical actuator driver module <NUM> in an infusion device <NUM> with any number of different types of electromechanical actuators <NUM>. It should be appreciated that <FIG> is a simplified representation of the electromechanical actuator driver module <NUM> for purposes of explanation and is not intended to limit the subject matter described herein in any way.

In exemplary embodiments, the electromechanical actuator driver module <NUM> includes, without limitation, input command logic circuitry <NUM> (alternatively referred to herein as duty cycle measurement logic) that maps or otherwise converts an input command signal at an input command terminal <NUM> to a commanded actuation state, decoding logic circuitry <NUM> (alternatively referred to herein as duty cycle decoding logic) coupled to the input command logic circuitry <NUM> to map or otherwise convert the commanded actuation state into appropriate driver command signals for the particular type of electromechanical actuator being utilized, and driver circuitry <NUM> coupled to the decoding logic circuitry <NUM> to generate electrical output signals at one or more output terminals <NUM> coupled to corresponding inputs of the electromechanical actuator in response to the driver command signals from the decoding logic circuitry <NUM>. For example, the driver circuitry <NUM> may be realized using any sort of driver or power conversion circuitry (e.g., H-bridges, power inverters, or the like) to modulate or otherwise regulate current flow between a supply voltage input terminal <NUM> and the one or more output terminals <NUM>. The electromechanical actuator driver module <NUM> also includes additional safety logic <NUM> (alternatively referred to herein as runaway prevention logic) that is coupled to the input command terminal <NUM> and the input command logic circuitry <NUM> to disable actuation based on the input command signal, as described in greater detail below.

In one or more exemplary embodiments, the logic components <NUM>, <NUM>, <NUM>, <NUM> of the electromechanical actuator driver module <NUM> are encapsulated or otherwise contained within a common housing or device package <NUM>. For example, the logic components <NUM>, <NUM>, <NUM>, <NUM> may all formed or otherwise provided on a common substrate or support structure for the electromechanical actuator driver module <NUM>, such as, for example, a printed circuit board or similar electronics substrate, a lead frame or die pad, or the like. The terminals <NUM>, <NUM>, <NUM> generally represent the input/output interfaces of the actuator driver device package <NUM> and may be realized using any sort of pin, pad, connector, port, and/or the like. In this regard, in exemplary embodiments where the input command signal is realized as a voltage signal having a variable duty cycle, the actuator driver device package <NUM> needs to include only a signal input terminal <NUM> for receiving the input command signal. Additionally, by virtue of the safety logic <NUM> disabling actuation in response to a static duty cycle, the actuator driver device package <NUM> does not need to include an additional or separate terminal for an enable input signal. Additionally, the number of output terminals <NUM> may be limited to the maximum number of inputs from among the different types of electromechanical actuators to be supported. For example, in one or more embodiments, the driver circuitry <NUM> includes four half H-bridge arrangements, with each half H-bridge arrangement being coupled between the input voltage terminal <NUM> and a respective output terminal <NUM>, such that the electromechanical actuator driver module <NUM> includes a total of four output terminals <NUM> capable of supporting a bipolar stepper motor, in addition to supporting three-phase BLDC motors, three-phase BDC motors, or shape-memory alloy actuation arrangements having fewer than four inputs (or actuators).

Referring now to <FIG> with continued reference to <FIG>, in exemplary embodiments, the input command logic circuitry <NUM> is configured to measure the width or duration of the duty cycle and maps the corresponding percentage of an electrical cycle to a discrete digital value that is provided to the decoding logic <NUM>. The duty cycle measurement logic <NUM> includes oscillator circuitry <NUM> configured to generate or otherwise provide a digital clock signal having a fixed frequency (e.g., <NUM>). In exemplary embodiments, the frequency of the digital clock signal is greater than the frequency of the input command signal. For example, in one or more embodiments, the frequency of the digital clock signal is greater than the frequency of the input command signal by at least a factor of <NUM> (e.g., a clock frequency of <NUM> and an input command signal frequency of <NUM> or less). The clock signal output by the oscillator circuitry <NUM> is provided to a clock input of a counter <NUM>, which, in exemplary embodiments is realized as a <NUM>-bit state counter. The reset input of the counter <NUM> is connected to the input command terminal <NUM>, such that a logical high voltage level for the input duty cycle command signal resets the value of the counter <NUM> at the beginning of each new cycle for the input duty cycle command signal. The output of the counter <NUM> is coupled to the input to data (D) flip-flop circuitry <NUM> that is configured to latch the output of the counter <NUM> when the input duty cycle command signal transitions to a logical low voltage level (e.g., by providing the logical inverse of the input command signal to the clock input(s) of the D flip-flop circuitry <NUM>). Thus, the counted value by the counter <NUM> and latched by the D flip-flop circuitry <NUM> corresponds to the duration of the duty cycle of the logical high voltage level at the input terminal <NUM>.

The illustrated duty cycle decoding logic <NUM> includes multiple different driver command modules <NUM>, <NUM>, <NUM>, <NUM>, with each driver command modules <NUM>, <NUM>, <NUM>, <NUM> corresponding to a different type of electromechanical actuator to be supported by the electromechanical actuator driver module <NUM>. In this regard, each driver command module <NUM>, <NUM>, <NUM>, <NUM> includes an enable input that is coupled to or otherwise connected to a corresponding output of a decoder <NUM> that is utilized to select the particular type of electromechanical actuator being utilized. For example, in the illustrated embodiment with four driver command modules <NUM>, <NUM>, <NUM>, <NUM>, the decoder <NUM> may be realized as a <NUM>-to-<NUM> line decoder that provides a logical high voltage signal at the output coupled to the stepper motor driver command module <NUM> and logical low voltage signals at the outputs coupled to the other driver command modules <NUM>, <NUM>, <NUM> in response to a selection input of <NUM>, a logical high voltage signal at the output coupled to the BLDC motor driver command module <NUM> and logical low voltage signals at the outputs coupled to the other driver command modules <NUM>, <NUM>, <NUM> in response to a selection input of <NUM>, and so on. In some embodiments, the selection input(s) to the decoder <NUM> is hardwired to permanently select a particular type of electromechanical actuator to be supported for a given deployment of the electromechanical actuator driver module <NUM>. That said, in other embodiments, the selection input(s) to the decoder <NUM> may be coupled to corresponding selection input terminal(s) of the device package <NUM> of the electromechanical actuator driver module <NUM> to allow the selected type of electromechanical actuator coupled to the output terminals <NUM> to vary.

The latched state count value output by the D flip-flop circuitry <NUM> represents a commanded actuation corresponding to the measured duty cycle of the input command signal. The commanded actuation state count value is provided to a corresponding input of each of the driver command modules <NUM>, <NUM>, <NUM>, <NUM>. Each of the driver command modules <NUM>, <NUM>, <NUM>, <NUM> includes logic, circuitry, hardware and/or other electrical components configured to generate driver command signals corresponding to the commanded actuation count value for their respective type of electromechanical actuator, as described in greater detail below in the context of <FIG>. In this regard, the enabled driver command module <NUM>, <NUM>, <NUM>, <NUM> maps or otherwise converts the latched commanded actuation state count value provided by the D flip-flop circuitry <NUM> into corresponding driver command signals that are output by the respective driver command module <NUM>, <NUM>, <NUM>, <NUM> and provided to inputs of the driver circuitry <NUM>.

Based on the driver command signals input to the driver circuitry <NUM>, the driver circuitry <NUM> selectively enables the supply voltage from the supply voltage terminal <NUM> to be provided to one or more of the output terminals <NUM>, thereby enabling resultant current flow to the electromechanical actuator to actuate the electromechanical actuator. For example, as described above, in an exemplary embodiment, the driver circuitry <NUM> includes an H-bridge arrangement <NUM> including four half H-bridges corresponding to the four output terminals <NUM>, where each half H-bridge is operated to selectively couple its respective output terminal <NUM> to either the supply voltage terminal <NUM> or a ground (or negative) reference voltage node according to the driver command signals applied to the switches of the respective half H-bridge.

The runaway prevention logic <NUM> includes a safety counter <NUM> having a clock input that receives the clock signal output by the oscillator circuitry <NUM>. The reset input to the safety counter <NUM> is coupled to the input command terminal <NUM>, such that a logical high voltage level for the input duty cycle command signal resets the value of the safety counter <NUM> at the beginning of each new cycle for the input duty cycle command signal. An overflow output of the safety counter <NUM> is inverted and provided to the input of an AND gate <NUM> that outputs the logical conjunction of the inverse of the overflow output bit and the input duty cycle command signal. The output of the AND gate <NUM> is provided to the set input of a set-reset (SR) flip-flop <NUM> having its reset input coupled to the overflow output of the safety counter <NUM> and its output coupled to the enable input of the oscillator circuitry <NUM>. Thus, during normal operation, when the input command signal varies between logical high and low voltage levels, the safety counter <NUM> does not overflow, the output of the AND gate <NUM> is a logical high voltage whenever the input command signal has a logical high voltage, thereby enabling the oscillator circuitry <NUM> and corresponding operation of the duty cycle measurement logic <NUM>. In one or more embodiments, the safety counter <NUM> is configured to overflow when the input command signal is constant for at least one and a half electrical cycles.

When the input command signal at the input terminal <NUM> has a duty cycle of either <NUM>% or <NUM>% for a sufficient duration to cause the safety counter <NUM> to overflow (e.g., greater than one and a half electrical cycles), the SR flip-flop <NUM> is reset, thereby disabling the oscillator circuitry <NUM>. Additionally, the reset input of the D flip-flop circuitry <NUM> receives the inverse of the output of the SR flip-flop <NUM>, which results in the D flip-flop circuitry <NUM> resetting and providing a commanded actuation state value of zero to the driver command modules <NUM>, <NUM>, <NUM>, <NUM>. In exemplary embodiments, the driver command modules <NUM>, <NUM>, <NUM>, <NUM> are configured to generate driver command signals in response to an input value of zero that result in the driver circuitry <NUM> allowing the output terminals <NUM> to be grounded or otherwise enter a high impedance state. For example, in response to a commanded actuation state value of zero, each of the driver command modules <NUM>, <NUM>, <NUM>, <NUM> may be configured to provide driver command signals that result in each of the switching elements of the H-bridge arrangement <NUM> being opened or otherwise turned off to prevent current flow through the H-bridge arrangement <NUM> and effectively provide a high impedance, thereby allowing the output terminals <NUM> to float as the electromechanical actuator coasts to a stop. Thus, referring to <FIG>, when the actuator control module <NUM> determines the actuation has been sufficient to achieve the desired dosage command, the actuator control module <NUM> may provide a constant logical low voltage signal (e.g., a duty cycle of zero) to the input terminal <NUM> of the electromechanical actuator driver module <NUM>, <NUM> to cease further actuation of the electromechanical actuator <NUM> without having to assert or de-assert a dedicated enable/disable signal for the electromechanical actuator <NUM>. Additionally, the runaway prevention logic <NUM> protects against any potential anomalous conditions where the actuator control module <NUM> might inadvertently maintain a logical high voltage level at the input command terminal <NUM>.

<FIG> depicts an exemplary embodiment of a stepper motor driver command module <NUM> suitable for use as the stepper motor driver command module <NUM> in the duty cycle decoding logic <NUM> in the electromechanical actuator driver module <NUM>, <NUM> described above in one or more embodiments. The stepper motor driver command module <NUM> includes a multiplexer <NUM> configured to selectively provide a selected <NUM>-bit input value provided from one of the <NUM>-bit inputs to the multiplexer <NUM> to the corresponding <NUM>-bit outputs of the multiplexer <NUM>, which, in turn may be coupled to the respective switching elements of the four half H-bridge arrangement <NUM> to selectively open or close the respective switching elements according to the respective bit line coupled to the activation input of the respective switching element. The enable input of the multiplexer <NUM> is coupled to the corresponding enable output of the decoder <NUM> to allow the output of the stepper motor driver command module <NUM> to be enable when a stepper motor is utilized (or otherwise disabled).

The respective inputs of the multiplexer <NUM> may be coupled to a hardware data storage arrangement <NUM> configured to maintain fixed state values that represent the appropriate operation of the driver circuitry <NUM> (e.g., the switches of the H-bridge arrangement <NUM>) for achieving different commutation states for the stepper motor. For example, the hardware data storage arrangement <NUM> may be configured to support a lookup table <NUM> of driver command signal states (or excitation states), which may correspond to different commutation states of the stepper motor.

The selection input of the multiplexer <NUM> is coupled to selection logic circuitry <NUM> (alternatively referred to herein as select line decoding circuitry) that is configured to map or otherwise convert the commanded actuation state value provided from the duty cycle measurement logic <NUM> (e.g., the output of the D flip-flop circuitry <NUM>) to a corresponding selection input for the multiplexer <NUM> that results in the particular set of fixed state values corresponding to the commanded actuation being provided to the driver circuitry <NUM> to achieve the commanded actuation of the stepper motor. In this regard, <FIG> includes a table <NUM> depicting an exemplary mapping of commanded actuation state values to selection input values (or corresponding driver command signal states) for an embodiment of the select line decoding circuitry <NUM>. The select line decoding circuitry <NUM> compares the current commanded actuation state value to predetermined values (or ranges) to decode or otherwise identify the appropriate selection input state and corresponding driver command signal states for achieving the commutation state corresponding to the input duty cycle. For example, in the illustrated embodiment, in response to a commanded actuation state value between <NUM> and <NUM>, the select line decoding circuitry <NUM> selects the set of values provided at the first input to the multiplexer <NUM>, which results in driver command signals to turn off or disable a first switch of a first half H-bridge that is coupled between the supply voltage terminal <NUM> and a first motor input at a first output terminal <NUM>, turn on or enable a second switch of the first half H-bridge that is coupled between the first output terminal <NUM> and a ground reference voltage node, turn on or enable a first switch of a second half H-bridge that is coupled between the supply voltage terminal <NUM> and a second motor input at a second output terminal <NUM>, turn off or disable a second switch of the second half H-bridge that is coupled between the second output terminal <NUM> and the ground reference voltage node, turn on or enable a first switch of a third half H-bridge that is coupled between the supply voltage terminal <NUM> and a third motor input at a third output terminal <NUM>, turn off or disable a second switch of the third half H-bridge that is coupled between the third output terminal <NUM> and the ground reference voltage node, turn off or disable a first switch of a fourth half H-bridge that is coupled between the supply voltage terminal <NUM> and a fourth motor input at a fourth output terminal <NUM>, and turn on or enable a second switch of the fourth half H-bridge that is coupled between the fourth output terminal <NUM> and the ground reference voltage node. As illustrated, a commanded actuation state value of zero resulting from the runway prevention logic <NUM> in response to a static input command signal results in the driver command signals output by the multiplexer <NUM> grounding the output terminals <NUM>, <NUM>, <NUM>, <NUM>, thereby allowing the stepper motor to coast to a stop.

Referring to <FIG> with reference to <FIG>, in one or more exemplary embodiments, the actuator control module <NUM> may utilize the mapping between the duty cycle (or commanded actuation state value) to determine the appropriate duty cycle(s) for the input command signal provided to the input terminal <NUM> to achieve the rotation angle of the stepper motor <NUM> and thereby achieve a desired dosage of fluid delivery. For example, if the desired dosage corresponds to actuating the stepper motor <NUM> through two commutation states, and the sensing arrangement <NUM> indicates the motor <NUM> is in a first state (State <NUM>), the actuator control module <NUM> may provide an input command signal having a duty cycle resulting in a commanded actuation state value between <NUM> and <NUM> to cause the stepper motor driver command module <NUM> to advance the stepper motor <NUM> to the next commutation state (State <NUM>), before increasing the duty cycle to achieve a commanded actuation state value between <NUM> and <NUM> to cause the stepper motor driver command module <NUM> to advance the stepper motor <NUM> to the following commutation state (State <NUM>), thereby actuating the stepper motor <NUM> through two commutation states and delivering the desired dosage. It should be appreciated that the same device package and encapsulated hardware for the electromechanical actuator driver module <NUM> may be employed with any number of different types of electromechanical actuators <NUM> and/or employed in different types or models of infusion devices <NUM>, with the actuator control module <NUM> generating the input command signals provided to the actuator driver module <NUM>, <NUM> according to the particular type of actuator <NUM> being utilized for the particular implementation.

It should be noted that <FIG> is a simplified representation of a driver command module for a stepper motor provided for purposes of explanation. It should be appreciated that driver command modules for other types of electromechanical actuators may be implemented in an equivalent manner to achieve the desired operation of those types of electromechanical actuators. Additionally, although <FIG> depicts a hardware-based implementation, alternative embodiments could utilize software to map or otherwise convert a commanded actuation state value to driver command signals, as will be appreciated in the art.

<FIG> depicts an exemplary embodiment of a control process <NUM> suitable for implementation by an electromechanical actuator driver module <NUM>, <NUM> to control operation of an electromechanical actuator <NUM>. While exemplary embodiments described herein implement the control process <NUM> using hardware, alternative embodiments may utilize any suitable combination of electrical components, logic, firmware, and/or software executed by processing circuitry. For illustrative purposes, the following description refers to elements mentioned above in connection with <FIG>. It should be appreciated that the control process <NUM> may include any number of additional or alternative tasks, the tasks need not be performed in the illustrated order and/or the tasks may be performed concurrently, and/or the control process <NUM> may be incorporated into a more comprehensive procedure or process having additional functionality not described in detail herein. Moreover, one or more of the tasks shown and described in the context of <FIG> could be omitted from a practical embodiment of the control process <NUM> as long as the intended overall functionality remains intact.

In exemplary embodiments, the control process <NUM> initializes or otherwise begins in response to detecting a rising edge of an input command signal asserted or otherwise provided at an input command terminal of the electromechanical actuator driver module (task <NUM>). In response to detecting a rising edge when the input command signal transitions to a logical high level, the control process <NUM> resets or otherwise initializes the state and safety counters before counting until detecting a falling edge of the input command signal (tasks <NUM>, <NUM>). For example, as described above in the context of <FIG>, the input command terminal <NUM> is connected to the reset inputs of the state counter <NUM> and the safety counter <NUM> to reset the values of the counters <NUM>, <NUM> to zero when the signal at the input command terminal <NUM> transitions to a logical high voltage level.

In response to detecting a falling edge of the input command signal, the control process <NUM> latches or otherwise buffers the value of the state counter and then maps or otherwise converts the latched state count value to a corresponding driver output state (tasks <NUM>, <NUM>). For example, as described above, the input command signal from the input command terminal <NUM> may be inverted prior to being provided to the clock input of the D flip-flop arrangement <NUM> so that the D flip-flop arrangement <NUM> latches the value of the state counter <NUM> in response to a falling edge of the input command signal. The latched commanded actuation state value is then provided to the duty cycle decoding logic <NUM> which maps or otherwise converts the commanded actuation state value to a corresponding driver state. For example, as described above in the context of <FIG>, the driver command module <NUM>, <NUM>, <NUM>, <NUM> for the selected type of electromechanical actuator <NUM> (e.g., select line decoding circuitry <NUM>) may compare the input commanded actuation state value to predefined values or thresholds (e.g., using a lookup table <NUM>) corresponding to different driver output states to identify the appropriate driver output state assigned to that commanded actuation state value. In this regard, in contrast to systems where the duty cycle of the command signal is correlative to or otherwise proportionally related to the amount (or percentage) of current (or power) delivered to a load during an electrical cycle, embodiments described herein map the duty cycle to a discrete commucation state (or actuation state). Thereafter, the control process <NUM> operates the driver circuitry of the electromechanical actuator driver module to set the voltage levels at its output terminals (which are coupled to the inputs of the electromechanical actuator) to the appropriate values for achieving the commanded actuation (task <NUM>). For example, after mapping the commanded actuation state value to a corresponding selection input state, the select line decoding circuitry <NUM> operates the selection input of the multiplexer <NUM> to apply the driver command signals corresponding to the commanded actuation to the driver circuitry <NUM> to thereby set the output terminals <NUM> of the electromechanical actuator driver module <NUM> to the voltage levels for achieving the commanded actuation corresponding to the duty cycle of the input command signal.

The loop defined by tasks <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> repeats throughout operation of the electromechanical actuator <NUM> while the actuator control module <NUM> varies the duty cycle of the input command signal provided to the actuator driver module <NUM>, <NUM> to achieve a desired actuation, and thereby, a desired delivery of fluid. In the absence of a rising or falling edge of the input command signal, the control process <NUM> monitors the value of the safety counter to detect or otherwise identify an overflow condition of the safety counter (tasks <NUM>, <NUM>). In response to overflow (or expiration) of the safety counter, the control process <NUM> disconnects the electromechanical actuator from the power supply and exits (task <NUM>). For example, as described above, the reset input of the safety counter <NUM> is coupled to the input command terminal <NUM> and resets with the rising edge for each new cycle of the input command signal. Thus, when the input command signal is maintained at a logical high voltage or a logical low voltage, the safety counter <NUM> does not reset and eventually overflows. In response, the additional safety logic <NUM>, <NUM> disables the oscillator circuitry <NUM> and sets the commanded actuation state to a zero value (e.g., by resetting the D flip-flop arrangement <NUM>), which results in the duty cycle decoding logic <NUM> operating the driver circuitry <NUM> to disconnect the output terminals <NUM> from the supply voltage. In exemplary embodiments, the driver circuitry <NUM> is operated to provide a high impedance at the output terminals <NUM> and allows the electromechanical actuator <NUM> to coast to a stop. Thereafter, the control process <NUM> may be reinitiated by varying the input command signal at the input terminal (e.g., task <NUM>), as described above.

By virtue of the subject matter described herein, various different types of electromechanical actuators may be driven using a single control signal and a common electrical hardware platform. In addition to the increased flexibility, extensibility and/or reusability of the electromechanical actuator driver module, the size of the driver module can be reduced by reducing the number of I/O interfaces required for the input commands to a single terminal. Similarly, the package size of the control module providing the input command signal can also be reduced by reducing the number of I/O interfaces required for outputting the command signal. Additionally, control signals for generating driver commands may be contained within the driver module package, leaving only a single control signal (e.g., the input command signal) exposed to environmental elements (e.g., humidity, water ingress, and/or the like) or other external factors (e.g., electromagnetic interference, electrostatic discharge, and/or the like) thereby increasing the safety. Unintentional actuation or motion of a rotor may also be inhibited by requiring a command signal at the input command terminal having a specific duty cycle (e.g., to map to a particular commanded actuation state), thereby preventing noise, transients, or other spurious signals from achieving actuation. The hardware-based implementations described herein also allows for more reliable performance that reduces software burdens and is less error prone.

For the sake of brevity, conventional techniques related to motors and related actuation systems and controls, logic circuits, electronic devices, device packaging, and other functional aspects of the subject matter may not be described in detail herein. In addition, certain terminology may also be used in the herein for the purpose of reference only, and thus is not intended to be limiting. For example, terms such as "first," "second," and other such numerical terms referring to structures do not imply a sequence or order unless clearly indicated by the context. The foregoing description may also refer to elements or nodes or features being "connected" or "coupled" together. As used herein, unless expressly stated otherwise, "coupled" means that one element/node/feature is directly or indirectly joined to (or directly or indirectly communicates with) another element/node/feature, and not necessarily mechanically. Thus, although various drawing figures may depict direct electrical connections between components, alternative embodiments may employ intervening circuit elements and/or components while functioning in a substantially similar manner.

While at least one exemplary embodiment has been presented in the foregoing detailed description, it should be appreciated that the exemplary embodiment or embodiments described herein are not intended to limit the scope, applicability, or configuration of the claimed subject matter in any way. For example, the subject matter described herein is not limited to the infusion devices and related systems described herein. Moreover, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing the described embodiment or embodiments.

Claim 1:
An electromechanical actuator driver module (<NUM>) comprising:
a terminal (<NUM>) to receive an input command signal;
command logic (<NUM>, <NUM>) coupled to the terminal to convert the input command signal to an actuation command; and
decoding logic (<NUM>) coupled to the command logic (<NUM>) to generate a driver command for a selected type of electromechanical actuator based on the actuation command: wherein the decoding logic (<NUM>) compriscs:
a plurality of driver command modules (<NUM>, <NUM>, <NUM>, <NUM>) to generate a respective driver command based on the actuation command, wherein each driver command module (<NUM>, <NUM>, <NUM>, <NUM>) of the plurality of driver command modules corresponds to a different one of a plurality of types of electromechanical actuators; and
logic circuitry (<NUM>) coupled to the plurality of driver command modules (<NUM>, <NUM>, <NUM>, <NUM>) to enable a selected driver command module of the driver command modules (<NUM>, <NUM>, <NUM>, <NUM>) corresponding to the selected type of actuator.