Программные продукты и системы

Современные концепции высшего медицинского образования предусматривают широкое применение симуляционных технологий для обучения базовым навыкам хирургии. В частности, широко распространены лапароскопические и эндоваскулярные тренажеры [1, 2], используемые на различных этапах додипломного и последипломного образования. Однако необходимость постоянного совершенствования существующих хирургических тренажеров и разработки новых, расширение перечня учебных кейсов и применение новых трехмерных моделей органов человеческого тела с учетом различия методик обучения в разных уни- верситетах обусловливают новые требования к ПО хирургических тренажеров, такие как интероперабельность, открытая архитектура и возможность функционирования в едином информационном пространстве.

В результате обобщения этих требований, а также опыта внедрения симуляционных технологий [3] была сформулирована идея создания средств разработки ПО, предназначенных для адаптации существующих хирургических тренажеров при их внедрении в учебный процесс и созда- нии качественно новых симуляционных решений для высшего медицинского образования. Назначение разработки – предоставить возможность быстрого и удобного создания новых хирургических тренажеров и трехмерных атласов на базе существующих разработок и аппаратно-программных компонентов. В данной статье представлены основные принципы проектирования расширяемой программной архитектуры СРПО в рамках решения поставленной задачи.

Обзор существующих разработок

Создание медицинских тренажеров для отработки студентами медицинских вузов базовых хирургических навыков в настоящее время является перспективным направлением исследований [4, 5]. В связи с разнообразием выполняемых хирургических операций существует необходимость моделирования различных операционных случаев, наиболее соответствующих программам обучения студентов разных медицинских специальностей. Для обеспечения такой возможности актуальной явля- ется разработка программного инструментария, позволяющего с минимальными затратами времени и сил при отсутствии специальных требований к квалификации специалиста в области компьютерных технологий создавать новые тренажеры, подключать трехмерные модели и реализовывать операционные кейсы. Отсутствие специальных требований к технической квалификации специалистов обусловлено необходимостью формирования широкого круга пользователей, способных создавать новые симуляционные решения на базе уже готовых модулей и алгоритмов.

Сокращение временных затрат на разработку каждой новой модели операции может быть достигнуто путем максимизации использования уже разработанных внутренних (созданных в рамках моделирования других операций) и внешних (библиотек физического моделирования, визуализации и т.д.) модулей. Для эффективного использования эти модули должны быть объединены в програм- мную платформу, которая позволяла бы единым образом обеспечивать взаимодействие между ними для достижения целей моделирования. При этом должна быть реализована возможность описания свойств объектов операционной сцены и механизмов их взаимодействия на простом языке, в том числе с помощью WISIWYG-редакторов.

В последнее десятилетие ведутся разнообразные исследования в области разработки универсального набора инструментов моделирования операционных случаев на базе различных подходов и технологий. В 2006 году в рамках проекта GiPSi был сформулирован обобщенный подход [6] для моделирования физического поведения внутренних органов. Позднее были сформированы принципы [7], использованные при разработке проекта SOFA. Этот проект ориентирован на создание инструментария для разработки и сравнения между собой различных алгоритмов физической симуляции органов человека. Для достижения этой цели представлена архитектура, которая позволяет путем комбинирования между собой различных представлений механического состояния объектов и методик решения систем уравнений получать различное поведение объектов операционной сцены.

В 2008 году был предложен подход, во многом основанный на подходе, примененном в SOFA, с добавлением требования максимизации использования готовых сторонних библиотек визуализации, описания операционных сценариев и сцен [8]. Здесь также описан возможный механизм взаимодействия между разработчиками тренажера и конечным пользователем.

В рамках проекта «Виртуальный хирург» [3] применен принцип максимизации использования готовых сторонних библиотек для моделирования физического поведения, вывода информации на экран, контроля сценария операции. При этом в основе моделирования физического поведения объ- ектов лежали две взаимозаменяемые физические библиотеки (PhysX, Bullet), что позволяло выбирать для моделирования ту из них, которая больше подходила для реализации конкретного операционного случая. Разработанный лапароскопический тренажер представлен на рисунке 1.

В 2012 году было выполнено исследование технологий [9], примененных в популярном игровом движке Unity3D и обеспечивающих расширяемость функциональности этого движка. В частности, рассмотрен шаблон проектирования «Сущность-компонент» [10], являющийся одним из основных для достижения хорошей расширяемости программных компонентов. Пример успешного применения шаблона проектирования «Сущность-компонент» для реализации платформы визуализации медицинских данных приведен в работе [11].

Несмотря на указанные тенденции по повышению универсальности и расширяемости програм- мных и аппаратных компонентов хирургических тренажеров, ведущие разработчики симуляционных технологий в медицине ограничены в своем взаимодействии и, как правило, придерживаются стратегии выпуска на рынок отдельных продуктов или их серий, не позволяя существенно изменять конфигурацию или наполнение своих разработок в процессе внедрения. Таким образом, разработка единых подходов к построению открытой программной архитектуры хирургического тренажера является актуальной.

Рассмотрим предлагаемое решение данной проблемы. Основное внимание в нем уделяется представлению объектов операционного поля и моделированию их взаимодействия друг с другом, которые обеспечили бы возможность создания новых обучающих модулей для хирургических тренажеров.

Общие подходы к проектированию

В предлагаемом подходе к построению распределенной архитектуры платформы для моделирования операционных случаев будем использовать шаблон проектирования «Сущность-компонент» [11]. Все объекты, описываемые в операционном случае (кейсе) (инструменты, органы, элементы окружения) являются контейнерами, не имеющими собственного поведения. На этапе моделирования с ними ассоциируются аспекты поведения, реализуемые в виде компонентов. Каждый компонент характеризуется именем и типом и реализует один или несколько интерфейсов для взаимодействия, которые могут быть получены путем посылки соответствующего запроса каждому компоненту.

Ответственность за создание и контроль жизненного цикла компонента возлагается на подсистемы, обслуживающие поведение всех компонентов определенной группы. Пример подсистемы: физическая сцена, обеспечивающая создание, уничтожение и контроль компонентов, отвечающих за моделирование динамики твердых и мягких тел.

Пример отношения подсистем и компонентов представлен на рисунке 2. Подсистемы регистрируются в ядре платформы при подключении программных модулей, содержащих эти подсистемы. В результате в системе появляются новые аспекты поведения объектов.

Программная логика тренажера разделяется на базовую (управление памятью, ресурсами, созданием и удалением компонентов, объектов сцены, ведение журналов работы приложения и т.д.) и специфичную (алгоритмы визуализации, физического поведения, контроля сценария операции, поведения инструментов на сцене и т.д.). Базовая логика реализуется в ядре системы и обеспечивает взаимодействие между объектами. Специфичная логика полностью реализуется в подключаемых модулях, что обеспечивает возможность разработки модулей, работающих с наиболее подходящими для моделирования конкретного операционного случая внешними зависимостями (например, с физической библиотекой PhysX или Bullet).

Использование этого подхода имеет ряд преимуществ:

-      отсутствие необходимости в глубокой иерархии классов, что уменьшает дублирование логики при большом количестве различных аспектов поведения объектов;

-      возможность определения поведения объекта без перекомпиляции исходного кода, что уменьшает накладные затраты на разработку операционного случая;

-      возможность распространения данных и алгоритмов в виде подключаемых модулей, легко интегрируемых в систему для расширения ее функциональности без масштабных изменений уже существующих частей системы.

Недостатки данного подхода:

-      взаимодействие между компонентами сопряжено с накладными расходами времени выполнения из-за отсутствия знания о потребителях и поставщиках данных (разрешение имен, контроль типов данных), поэтому требует от программиста минимизации этого взаимодействия;

-      многообразие различных по своей природе компонентов делает необходимой разработку механизма хранения и получения метаданных о свойствах компонента для идентификации типа и контроля платформой допустимых сценариев взаимодействия компонентов между собой.

Принимая во внимание разделение логики по степени ее специфичности для конкретного операционного случая, можно построить иерархию взаимодействия программных модулей, изображенную на рисунке 3.

Ядро системы предоставляет низкоуровневые базовые службы, не привязанные к моделируемой предметной области и обеспечивающие среду для взаимодействия объектов друг с другом. Базовый каркас системы предоставляет стандартные служ­бы, общие для моделирования широкого круга операционных случаев. К таким службам относятся различные подсистемы визуализации (OpenGL, OGRE), физической симуляции (PhysX, Bullet, SOFA), управления сценариями (Lua, Squirrel­Script), библиотеки графического интерфейса пользователя (SDL, Qt) и т.д.

Каркас операционного блока представляет собой набор аспектов поведения, специфичных для конкретного типа операций. Например, каркас эндоскопического блока может содержать алгоритмы взаимодействия органов и инструментов (захват, разрез, пункция), алгоритмы контроля состояния пациента и качества выполнения оперативных действий оператора, модули взаимодействия с аппаратной частью тренажера. Специфичные алгоритмы конкретного операционного случая могут включать в себя детекторы успешности завершения операции (например, контроль видимости объекта при отработке навыка позиционирования камеры), контроллеры параметров конкретной операции (например, корректность позиционирования эндоскопических клипс на сосудах) и т.д.

Для каждого из уровней определяются свои интерфейсы и реализации этих интерфейсов, что позволяет иметь возможность использования как подсистем, например, физической подсистемы через ее обобщенный интерфейс, при этом имея возможность выбора конкретной реализации (PhysX, Bullet, SOFA) под нужды моделируемого случая, так и расширений, специфичных для какой-то конкретной подсистемы.

Алгоритмы взаимодействия органов и инструментов

Учитывая высокую вычислительную сложность моделирования процессов в операционном поле, при построении алгоритмов взаимодействия объектов необходимо стремиться достигнуть максимально возможной производительности при сохранении гибкости поведения объектов.

Рассмотрим пример алгоритма захвата органа твердым инструментом с двумя браншами в рамках моделирования эндоскопической операции. Инструмент может быть представлен как композитное твердое тело, содержащее подвижные части. Орган представляется в виде набора вершин, движение которых относительно друг друга ограничено законом эластичного растяжения [12]. Задача построения алгоритма захвата упрощенно может быть сформулирована следующим образом: необходимо обеспечить выполнение такого физического ограничения, при котором при достаточной степени сжатия вершин в области между браншами инструмента позиция этих вершин в системе координат, связанной с инструментом, остается неизменной при любом изменении положения инструмента.

На данном этапе исследования не рассматривается реализация тактильной обратной связи, поэтому из рассмотрения для простоты исключается воздействие захватываемого органа на инструмент, при этом инструмент считается объектом, имею- щим бесконечную массу.

Выполнение данной задачи состоит из нескольких этапов:

-      определение потенциально захваченных вершин;

-      определение момента, когда вершина становится захваченной;

-      создание и выполнение внутри подсистемы физической симуляции ограничения, обеспечивающего постоянство позиций вершин в системе координат инструмента;

-      определение момента, когда вершины перестают быть захваченными;

-      отмена ограничения на степени свободы вершин внутри подсистемы физической симуляции.

Среди выделенных этапов одним из наиболее вычислительно сложных является определение потенциально захваченных вершин, для которых требуется применение алгоритма проверки столкновений. Такая проверка должна выполняться для каждого органа на сцене и для каждого инструмента. Принимая во внимание тот факт, что каждый орган не всегда находится между браншами каждого инструмента, можно заменить этот процесс быстрой упрощенной проверкой столкновений.

Эту быструю проверку столкновений можно выделить в компонент, называемый триггером, который отвечает за инициирование процесса захвата и предоставляет информацию об ограниченной области поиска потенциально захваченных вершин.

Реализация ограничения позиций вершин может быть выполнена на стороне как физической подсистемы, так и модуля операционного блока, определяющего алгоритм захвата. В данной работе рассматривается вариант, при котором логика, обеспечивающая контроль позиций вершин, полностью выполняется на стороне физической подсистемы. Для этого физическая подсистема должна предоставить интерфейс для создания собственных ограничений мягкого тела, а далее нужно опреде- лить компонент, называемый, соответственно, физическим ограничением, и реализующий этот интерфейс.

Логично предположить, что разные внутренние органы имеют разную природу, поэтому одинаковая реализация алгоритма захвата, например, для сплошных и полых органов, может не обеспечивать правдоподобное моделирование поведения. Аналогично модели органов, реализованные с использованием различных алгоритмов (например PBD [13], FEM [12]), также могут требовать различной логики имитации процесса захвата. В то же время поведение инструмента практически не зависит от того, какой орган он в данный момент захватывает. Исходя из этих предположений, можно определить для каждого органа компонент, называемый фабрикой ограничений, который при обнаружении инструментом момента начала захвата будет создавать соответствующий тип физического ограничения, определяемый пользователем, описывающим операционный случай.

Наконец, можно определить компонент, называемый контроллером алгоритма и обеспечивающий обработку события начала захвата, отправку запроса на создание физического ограничения, передачу состояния инструмента физическому ограничению, обнаружение момента завершения захвата и запрос на отмену физического ограничения.

Схема взаимодействия описанных компонентов представлена на рисунке 4.

Похожим образом могут быть реализованы другие алгоритмы взаимодействия органов и инструментов (разрез, пункция, коагуляция и др.).

Сформулируем основные принципы, использованные при формулировке алгоритма:

-      определение момента начала работы алгоритма посредством генерации и обработки события;

-      вариативность реализации физического ограничения для различных органов;

-      минимизация объема данных, передаваемых между различными компонентами.

Эти принципы позволяют формулировать алгоритмы в интуитивно понятной форме и реализовывать их без больших накладных расходов на взаимодействие между компонентами.

С точки зрения оператора, моделирующего сцену на базе готовых алгоритмов, добавление новой формы взаимодействия между объектами сводится к формальному описанию возможности такого взаимодействия в объектах. В приведенном примере добавление контроллера захвата к инструменту добавляет свойство «инструмент может хватать объекты двумя браншами», а добавление соответствующей фабрики ограничений в орган добавляет свойство «орган может быть захвачен двумя браншами».

Построение сцены для моделирования операционного случая

Рассмотрев базовые принципы организации взаимодействия между объектами, рассмотрим процесс создания сцены для моделирования операции на примере создания обучающего модуля эндоскопического клипирования. Операционное поле в данном случае содержит гибкую трубку, закрепленную с двух сторон, и эндоскопический клипс-аппликатор, управляемый оператором (см. рис. 5). Задачей оператора является установка трех эндоскопических клипс в заданных местах трубки, представляющей собой модель кровеносного сосуда.

Операционная сцена состоит из четырех объектов: трубка, закрепленная с двух концов; клипс-аппликатор; камера, определяющая точку и угол обзора сцены; контроллер сценария операции.

Для моделирования поведения этих объектов можно определить следующие компоненты:

-      компонент физического поведения полого трубчатого тела (физическое представление трубки);

-      компонент физического поведения композитного твердого тела (физическое представление инструмента);

-      компонент визуализации деформируемого тела (графическое представление трубки);

-      компонент визуализации композитного твердого тела (графическое представление инструмента);

-      триггер начала работы алгоритма клипирования;

-      компонент-интерфейс для работы с аппаратным устройством ввода;

-      контроллер положения эндоскопического инструмента;

-      контроллер алгоритма клипирования;

-      физическое ограничение, обеспечивающее изменение положения клипсы при изменении пространственной конфигурации трубки;

-      фабрика физического ограничения клипирования;

-      камера, реализующая задание точки и угла обзора сцены для визуализации;

-      точечный источник света;

-      сценарий операции.

Схема объектов сцены и потоков данных между ними представлена на рисунке 6.

Большинство реализованных компонентов, составляющих объекты сцены, в дальнейшем могут быть использованы для создания моделей других операционных случаев. Например, компоненты контроля положения эндоскопического инструмента можно использовать при моделировании любой эндоскопической операции; компоненты, реализующие алгоритм клипирования, – при моделировании любых операций, где требуется работа с кровеносными сосудами, например, при моделиро- вании проведения лапароскопической холецистэктомии. Компоненты визуализации могут найти применение в любой другой операции.

Таким образом, при создании новой операционной сцены пользователь может повторно использовать уже имеющиеся компоненты. Необходимость в разработке новых компонентов возникает только в случае, если существующие компоненты не обеспечивают необходимой функциональности.

Использование компонентов вместо наследования функциональности позволяет описывать поведение объектов сцены на этапе выполнения программы, следовательно, дает возможность как статически (на этапе загрузки операционного случая), так и динамически (в процессе выполнения опе- рации, например, обеспечивая адаптивную сложность) расширять и сужать функциональность поведения этих объектов, тем самым быстро адаптируя модель под нужды конкретной ситуации. Однако открытость системы при использовании такого подхода накладывает на разработчиков определенные требования к соблюдению корректности модели. Учитывая то, что любой объект может быть параметризован любым свойством без каких-либо ограничений, необходимо обеспечить контроль за совместностью получаемой модели. Если этот контроль будет находиться в области ответственности оператора, создающего модель, нарушится условие минимизации требований к технической квалификации человека, моделирующего модель. Следовательно, необходимо обеспечить механизм автоматического контроля целостности модели. Подобное средство автоматического контроля обусловливает необходимость формального определения спецификации полученной модели и аспектов взаимодействия объектов внутри этой модели.

Результаты практической реализации предложенного подхода показывают, что он может быть использован для описания различных по природе аспектов поведения объектов сцены в рамках единой архитектуры, обеспечивающей хорошую гибкость настройки поведения и активное повторное использование готовых компонентов. При этом для реализации подхода необходимы относительно небольшие накладные расходы по сравнению с описанием аспектов поведения непосредственно в объектах сцены без использования динамического связывания.

Итак, сделаем следующие выводы. Предложенные в статье принципы проектирования расширяемой программной архитектуры средств разработки ПО для самостоятельного формирования медицинским сообществом решений в среде симуляционных технологий в медицине позволяют сократить временные затраты и трудоемкость создания новых хирургических тренажеров, а также адаптации существующих симуляционных решений при их внедрении и практическом использовании. Дальнейшие исследования направлены на формулировку и практическую реализацию основных алгоритмов моделирования собственного поведения органов и взаимодействия органов и инструментов между собой в рамках предложенного подхода.

Литература

1.     Колсанов А.В., Яремин Б.И., Воронин А.С., Черепа- нов А.С., Иващенко А.В., Сапцин Н.В. Программное обеспечение тренажера эндоваскулярной хирургии // Программные продукты и системы. 2013. № 2. С. 262–267.

2.     Колсанов А.В., Чаплыгин С.С., Иващенко А.В., Кузьмин А.В., Горбаченко Н.А., Милюткин М.Г. Программное обеспечение тренажера лапароскопической хирургии // Программные продукты и системы. 2013. № 2. С. 267–270.

3.     Колсанов А.В., Иващенко А.В., Кузьмин А.В., Черепанов А.С. Комплекс «Виртуальный хирург» для симуляционного обучения хирургии // Медицинская техника. 2013. № 6. С. 7–10.

4.     Iwata N., Fujiwara M., Kodera Y., Tanaka C., Ohashi N., Nakayama G., Koike M., Nakao A. Construct validity of the LapVR virtual-reality surgical simulator. Surg Endosc, 2011, vol. 25, no. 2, pp. 423–428.

5.     Ayodeji I.D., Schijven M., Jakimowicz J., Greve J.W. Face validation of the Simbionix LAP Mentor virtual reality training mod- ule and its applicability in the surgical curriculum. Surg Endosc, 2007, vol. 21, no. 9, pp. 1641–1649.

6.     Cavusoglu M.C., Goktekin T.G., Tendick F. GiPSi: a fra­mework for open source/open architecture software development for organ-level surgical simulation. IEEE Transactions on Information Technology in Biomedicine, 2006, vol. 10, no. 2, pp. 312–322.

7.     Allard J., Cotin S., Faure F., Bensoussan P.-J., Poyer F., et al. SOFA – an open source framework for medical simulation. Medicine Meets Virtual Reality, 2007, Palm Beach, US, IOP Press, vol. 125, pp. 13–18.

8.     Chun Bo B., Bo Liang W. A open source based general fra­mework for virtual surgery simulation. Proc. Intern. Conf. “BioMedical Eng. and Informatics” (BMEI'08), 2008, vol. 1, pp. 575–579.

9.     Jingming Xie. Research on key technologies base Unity3D game engine. Proc. Comp. Sc. & Education (ICCSE), 2012, pp. 695–699.

10.  Nystrom R. Component. Game Programming Patterns. URL: http://gameprogrammingpatterns.com/component.html (дата обращения: 12.11.2015).

11.  Schulte zu Berge C., Grunau A., Mahmud H., Navab N. CAMPVis – a game engine-inspired research framework for medical imaging and visualization. 2014, URL: http://campar.in.tum.de/ Main/CAMPVis (дата обращения: 12.11.2015).

12.  Liu X.P., Xu S., Zhang H., Hu L. A new hybrid doft tissue model for visio-haptic dimulation. IEEE Transactions on Instrumentation and Measurement, 2011, vol. 60, no. 11, pp. 3570–3581.

13.  Müller M., Heidelberger B., Hennix M., Ratcliff J. Position based dynamics. J. Vis. Comun. Image Represent, 2007, vol. 18, no. 2, pp. 109–118.