Instruments that have intuitive controls and feel right in the hands are key requirements for all surgeons. For laparoscopic surgeons, who perform procedures through 5-to-15-millimeter incisions, such instruments are critical.

It takes many design iterations to perfect the control and feel of a laparoscopic device. Each design modification can take weeks to implement, making traditional design workflows unfeasible. At Ethicon Endo-Surgery, Inc, we have adopted a rapid prototyping workflow based on Model-Based Design that enables us to implement and test new design refinements in minutes and reduce overall development time by months.

Using this workflow, we designed and built a prototype for a next-generation endoscopic surgical stapler in just three months. We used MATLAB^® and Simulink^® to model and simulate the stapler’s motor and controls, and then generated code for ontarget rapid prototyping using Embedded Coder^®. Using this approach we were able to create a prototype that surgeons found comfortable, stable, and intuitive while refining system requirements in preparation for moving into production.

From Sutures and Staples to Embedded Controls

Most surgeries involve three common steps: make an incision, clamp the tissue surrounding the incision, and suture the tissue. In laparoscopic surgery, these steps are performed through minute incisions, often using an endoscopic cutter stapler, or endocutter, which uses staples instead of sutures to close the incision. Developed in the 1970s, the first endocutters required surgeons to apply considerable manual force, which led to fatigue. In 2011, Ethicon introduced the industry’s first powered endocutter with a motor that is operated with the press of button, increasing precision and stability (Figure 1).

Choosing Model-Based Design for Endocutter Motor Control

Having developed the initial powered endocutter, mechanical engineers at Ethicon had considerable expertise in the device’s mechanics. We had, however, relatively little experience in developing embedded control systems. On past projects that required control software, we typically outsourced the prototype development work. This approach was slow not only for the initial prototype but also for subsequent design revisions. It was also difficult to translate our in-house knowledge of how the device should work and how surgeons would use it into a set of well-defined requirements. More importantly, we learned little from the process—all the insights about the control system’s key functionality were acquired by the third-party developers.

By using Model-Based Design for the new endocutter, we would be able to apply our mechanical and biomedical domain expertise directly in the development of motor controllers for preproduction prototypes.

Characterizing the Motor and Building the Control Model

Our first task was the development of a plant model for the motor in Simulink. We began by connecting our motor to a breadboard running a TI F28335 processor. We deployed some simple code for the processor to stimulate the motor, and took measurements from the motor as it was spinning. Next, we used Simulink Design Optimization™ to import the measured data and perform parameter estimations for the plant model. Simulink Design Optimization automatically solved for the motor torque constant, dynamic friction, moment of inertia, and numerous other parameters of a nonlinear model that often take a long time to characterize accurately. We later added refinements to the model to account for backlash, and expanded the plant model to include the tissue environment in which the cutter would operate.

Once we had an accurate plant model, we began modeling the control system with Simulink and Stateflow^® (Figure 2).

The control inputs include 14 switches, as well as sensors that measure the current draw on the motor, the voltage drop across the motor, and the position of the drive train. With Simulink we modeled the sensors, an I²C interface, and a pulse-width modulator used to control the motor. We used Stateflow to model state transitions in the controller. State-space design methods and MATLAB were used to develop a compensator.

After running closed-loop simulations in Simulink to verify and refine the control design, we used Embedded Coder to generate C code from the model. We compiled and deployed the code to the TI C2000 breadboard, and conducted real-time tests using the actual motor.

Incorporating Feedback from Surgeons

Our initial hardware tests confirmed what we had seen in simulations: the motor controller accurately positioned the device upon command. This achievement, however, was just the precursor to much more vital testing, which began when we began using the device in the lab.

By actually using the endocutter, we could feel when it was moving too fast during certain movements or too slow for others. We adjusted the control model in Simulink, regenerated code, and quickly updated the embedded software in design iterations until the endocutter felt responsive and natural to our team.

We then invited surgeons to test the device and give us their feedback, which we incorporated into the design using the same rapid iterative cycle. Within minutes of a surgeon’s offering a suggestion, we had an updated control system ready for test. Model-Based Design made it easy to do this fine-tuning. If we had outsourced the design, each iteration could have taken weeks, or even months.

Building a Close-to-Production Prototype

Our first prototype was designed with a relatively high-powered processor and multiple high-resolution sensors. To prepare for production using less expensive components, we began designing a second prototype using hardware comparable to the type that will be used in production, including a more modestly powered Cortex-M4 processor and a single, lower-resolution sensor. While waiting for the board with these components to be assembled, we modified our Simulink controller model to reflect the changes. For example, we used specifications from the sensor datasheet to update our submodel of the sensor.

Our simulations revealed errors in our digital signal processing algorithm. We designed filters to eliminate the problem, and verified the fix via simulation—all before the hardware was ready. We also performed what-if analysis to determine a lower limit for sensor resolution that would still enable the design to meet its submillimeter tolerances for positioning.

To support code generation with our target processor, we worked with a third-party software development group to develop a software framework that performs low-level tasks to initialize the board’s interrupts and peripherals. This framework serves as an interface layer between the controller code generated with Embedded Coder and the hand-coded peripherals for the processor.The separation of the algorithm code and the interface layer will enhance the portability of the generated algorithm code if we choose to implement it on a different embedded processor in the future.

When the new hardware arrived in the lab, the simulations and verification that we had performed with Simulink paid off. We had a stable version of the controller running within a week, and we resumed in-lab refinements using feedback from the team and from surgeons testing the new prototype.

From Prototype to Production

Using Model-Based Design, we completed the first proof-of-concept in about three months. Similar projects in the past, which were outsourced, took about 18 months to complete. More importantly, we now have intimate knowledge of the subtle but important design details and decisions that went into the controller. We know, for example, how much processor delay to anticipate and what motor speeds feel most comfortable to the surgeon. The only way to learn these details is to build a prototype, and for us the only way to do that quickly was to use Model-Based Design with Simulink.

For the transition to production, we plan to work with a development team that has direct experience of developing software for medical devices. We now have the knowledge to write detailed and precise requirements, which will streamline the implementation process.

Meanwhile, we continue to develop and enhance the prototype. We plan to bring more of the software implementation in-house using MATLAB, Simulink, and Embedded Coder.