CC BY
74
УДК 519.688 Дата подачи статьи: 09.03.16
DOI: 10.15827/0236-235X.114.158-165
ПОСТРОЕНИЕ РАСШИРЯЕМОЙ ПРОГРАММНОЙ АРХИТЕКТУРЫ ХИРУРГИЧЕСКИХ ТРЕНАЖЕРОВ
(Работа выполнена в рамках проекта Минобрнауки России, грант № 2014-14-579-0003, соглашение № 14.607.21.0007)
А.В. Иващенко, д.т.н., доцент, профессор, [email protected]; Н.А. Горбаченко, аспирант, [email protected] (Самарский государственный аэрокосмический университет им. академика С.П. Королева (национальный исследовательский университет), Московское шоссе, 34, г. Самара, 443086, Россия); А.В. Колсанов, д.м.н., профессор, директор (Институт инновационного развития Самарского государственного медицинского университета, ул. Чапаевская, 89, г. Самара, 443099, Россия)
Непрерывное совершенствование современных хирургических тренажеров с учетом различия методик обучения в разных университетах обусловливает актуальность таких требований к их ПО, как интероперабельность, открытость архитектуры и возможность функционирования в едином информационном пространстве. В статье рассматриваются базовые принципы построения расширяемой архитектуры ПО хирургических тренажеров для симуляционного обучения базовым навыкам хирургии в медицинских высших учебных заведениях. Основное внимание уделяется представлению объектов операционного поля и моделированию их взаимодействия друг с другом, которое обеспечило бы возможность создания новых обучающих модулей для хирургических тренажеров. Для построения распределенной архитектуры платформы при моделировании операционных случаев предлагается использовать шаблон проектирования «Сущность-компонент». С учетом разделения логики по степени ее специфичности для конкретного операционного случая предлагается иерархия взаимодействия программных модулей. В качестве примера рассмотрен алгоритм захвата органа твердым инструментом с двумя браншами в рамках моделирования эндоскопической операции. Также рассмотрены базовые принципы организации взаимодействия между объектами на примере обучающего модуля эндоскопического клипирования. Результаты практической реализации предложенного подхода показывают, что он может быть использован для описания различных по природе аспектов поведения объектов сцены в рамках единой архитектуры, обеспечивающей гибкость настройки поведения и активное повторное использование готовых компонентов. Предложенный подход позволяет сократить временные затраты и трудоемкость создания новых хирургических тренажеров, а также затраты на адаптацию существующих симуляционных решений при их внедрении и практическом использовании.
Ключевые слова: программная платформа, компонент, средства разработки ПО, симуляционное обучение, хирургический тренажер.
Современные концепции высшего медицинского образования предусматривают широкое применение симуляционных технологий для обучения базовым навыкам хирургии. В частности, широко распространены лапароскопические и эндоваску-лярные тренажеры [1, 2], используемые на различных этапах додипломного и последипломного образования. Однако необходимость постоянного совершенствования существующих хирургических тренажеров и разработки новых, расширение перечня учебных кейсов и применение новых трехмерных моделей органов человеческого тела с учетом различия методик обучения в разных университетах обусловливают новые требования к ПО хирургических тренажеров, такие как интеропера-бельность, открытая архитектура и возможность функционирования в едином информационном пространстве.
В результате обобщения этих требований, а также опыта внедрения симуляционных технологий [3] была сформулирована идея создания средств разработки ПО, предназначенных для адаптации существующих хирургических тренажеров при их внедрении в учебный процесс и созда-
нии качественно новых симуляционных решений для высшего медицинского образования. Назначение разработки - предоставить возможность быстрого и удобного создания новых хирургических тренажеров и трехмерных атласов на базе существующих разработок и аппаратно-программных компонентов. В данной статье представлены основные принципы проектирования расширяемой программной архитектуры СРПО в рамках решения поставленной задачи.
Обзор
существующих разработок
Создание медицинских тренажеров для отработки студентами медицинских вузов базовых хирургических навыков в настоящее время является перспективным направлением исследований [4, 5]. В связи с разнообразием выполняемых хирургических операций существует необходимость моделирования различных операционных случаев, наиболее соответствующих программам обучения студентов разных медицинских специальностей. Для обеспечения такой возможности актуальной явля-
ется разработка программного инструментария, позволяющего с минимальными затратами времени и сил при отсутствии специальных требований к квалификации специалиста в области компьютерных технологий создавать новые тренажеры, подключать трехмерные модели и реализовывать операционные кейсы. Отсутствие специальных требований к технической квалификации специалистов обусловлено необходимостью формирования широкого круга пользователей, способных создавать новые симуляционные решения на базе уже готовых модулей и алгоритмов.
Сокращение временных затрат на разработку каждой новой модели операции может быть достигнуто путем максимизации использования уже разработанных внутренних (созданных в рамках моделирования других операций) и внешних (библиотек физического моделирования, визуализации и т.д.) модулей. Для эффективного использования эти модули должны быть объединены в программную платформу, которая позволяла бы единым образом обеспечивать взаимодействие между ними для достижения целей моделирования. При этом должна быть реализована возможность описания свойств объектов операционной сцены и механизмов их взаимодействия на простом языке, в том числе с помощью WISIWYG-редакторов.
В последнее десятилетие ведутся разнообразные исследования в области разработки универсального набора инструментов моделирования операционных случаев на базе различных подходов и технологий. В 2006 году в рамках проекта GiPSi был сформулирован обобщенный подход [6] для моделирования физического поведения внутренних органов. Позднее были сформированы принципы [7], использованные при разработке проекта SOFA. Этот проект ориентирован на создание инструментария для разработки и сравнения между собой различных алгоритмов физической симуляции органов человека. Для достижения этой цели представлена архитектура, которая позволяет путем комбинирования между собой различных представлений механического состояния объектов и методик решения систем уравнений получать различное поведение объектов операционной сцены.
В 2008 году был предложен подход, во многом основанный на подходе, примененном в SOFA, с добавлением требования максимизации использования готовых сторонних библиотек визуализации, описания операционных сценариев и сцен [8]. Здесь также описан возможный механизм взаимодействия между разработчиками тренажера и конечным пользователем.
В рамках проекта «Виртуальный хирург» [3] применен принцип максимизации использования готовых сторонних библиотек для моделирования физического поведения, вывода информации на экран, контроля сценария операции. При этом в основе моделирования физического поведения объ-
ектов лежали две взаимозаменяемые физические библиотеки (PhysX, Bullet), что позволяло выбирать для моделирования ту из них, которая больше подходила для реализации конкретного операционного случая. Разработанный лапароскопический тренажер представлен на рисунке 1.
Рис. 1. Лапароскопический тренажер «Виртуальный хирург»
Fig. 1. Laparoscopic trainer "Virtual surgeon "
В 2012 году было выполнено исследование технологий [9], примененных в популярном игровом движке Unity3D и обеспечивающих расширяемость функциональности этого движка. В частности, рассмотрен шаблон проектирования «Сущность-компонент» [10], являющийся одним из основных для достижения хорошей расширяемости программных компонентов. Пример успешного применения шаблона проектирования «Сущность-компонент» для реализации платформы визуализации медицинских данных приведен в работе [11].
Несмотря на указанные тенденции по повышению универсальности и расширяемости программных и аппаратных компонентов хирургических тренажеров, ведущие разработчики симуляцион-ных технологий в медицине ограничены в своем взаимодействии и, как правило, придерживаются стратегии выпуска на рынок отдельных продуктов или их серий, не позволяя существенно изменять конфигурацию или наполнение своих разработок в
процессе внедрения. Таким образом, разработка единых подходов к построению открытой программной архитектуры хирургического тренажера является актуальной.
Рассмотрим предлагаемое решение данной проблемы. Основное внимание в нем уделяется представлению объектов операционного поля и моделированию их взаимодействия друг с другом, которые обеспечили бы возможность создания новых обучающих модулей для хирургических тренажеров.
Общие подходы к проектированию
В предлагаемом подходе к построению распределенной архитектуры платформы для моделирования операционных случаев будем использовать шаблон проектирования «Сущность-компонент» [11]. Все объекты, описываемые в операционном случае (кейсе) (инструменты, органы, элементы окружения) являются контейнерами, не имеющими собственного поведения. На этапе моделирования с ними ассоциируются аспекты поведения, реализуемые в виде компонентов. Каждый компонент характеризуется именем и типом и реализует один или несколько интерфейсов для взаимодействия, которые могут быть получены путем посылки соответствующего запроса каждому компоненту.
Ответственность за создание и контроль жизненного цикла компонента возлагается на подсистемы, обслуживающие поведение всех компонентов определенной группы. Пример подсистемы: физическая сцена, обеспечивающая создание, уничтожение и контроль компонентов, отвечающих за моделирование динамики твердых и мягких тел.
Пример отношения подсистем и компонентов представлен на рисунке 2. Подсистемы регистрируются в ядре платформы при подключении программных модулей, содержащих эти подсистемы.
Позиция, ориентация
Рис. 2. Отношения подсистем и компонентов Fig. 2. Relations between subsystems and components
В результате в системе появляются новые аспекты поведения объектов.
Программная логика тренажера разделяется на базовую (управление памятью, ресурсами, созданием и удалением компонентов, объектов сцены, ведение журналов работы приложения и т.д.) и специфичную (алгоритмы визуализации, физического поведения, контроля сценария операции, поведения инструментов на сцене и т.д.). Базовая логика реализуется в ядре системы и обеспечивает взаимодействие между объектами. Специфичная логика полностью реализуется в подключаемых модулях, что обеспечивает возможность разработки модулей, работающих с наиболее подходящими для моделирования конкретного операционного случая внешними зависимостями (например, с физической библиотекой PhysX или Bullet).
Использование этого подхода имеет ряд преимуществ:
- отсутствие необходимости в глубокой иерархии классов, что уменьшает дублирование логики при большом количестве различных аспектов поведения объектов;
- возможность определения поведения объекта без перекомпиляции исходного кода, что уменьшает накладные затраты на разработку операционного случая;
- возможность распространения данных и алгоритмов в виде подключаемых модулей, легко интегрируемых в систему для расширения ее функциональности без масштабных изменений уже существующих частей системы.
Недостатки данного подхода:
- взаимодействие между компонентами сопряжено с накладными расходами времени выполнения из-за отсутствия знания о потребителях и поставщиках данных (разрешение имен, контроль типов данных), поэтому требует от программиста минимизации этого взаимодействия;
- многообразие различных по своей природе компонентов делает необходимой разработку механизма хранения и получения метаданных о свойствах компонента для идентификации типа и контроля платформой допустимых сценариев взаимодействия компонентов между собой.
Принимая во внимание разделение логики по степени ее специфичности для конкретного операционного случая, можно построить иерархию взаимодействия программных модулей, изображенную на рисунке 3.
Ядро системы предоставляет низкоуровневые базовые службы, не привязанные к моделируемой предметной области и обеспечивающие среду для взаимодействия объектов друг с другом. Базовый каркас системы предоставляет стандартные службы, общие для моделирования широкого круга операционных случаев. К таким службам относятся различные подсистемы визуализации (OpenGL, OGRE), физической симуляции (PhysX, Bullet,
SOFA), управления сценариями (Lua, Squirrel-Script), библиотеки графического интерфейса пользователя (SDL, Qt) и т.д.
Каркас операционного блока представляет собой набор аспектов поведения, специфичных для конкретного типа операций. Например, каркас эндоскопического блока может содержать алгоритмы взаимодействия органов и инструментов (захват, разрез, пункция), алгоритмы контроля состояния пациента и качества выполнения оперативных действий оператора, модули взаимодействия с аппаратной частью тренажера. Специфичные алгоритмы конкретного операционного случая могут включать в себя детекторы успешности завершения операции (например, контроль видимости объекта при отработке навыка позиционирования камеры), контроллеры параметров конкретной операции (например, корректность позиционирования эндоскопических клипс на сосудах) и т.д.
Для каждого из уровней определяются свои интерфейсы и реализации этих интерфейсов, что позволяет иметь возможность использования как подсистем, например, физической подсистемы через ее обобщенный интерфейс, при этом имея возможность выбора конкретной реализации (PhysX, Bullet, SOFA) под нужды моделируемого случая, так и расширений, специфичных для какой-то конкретной подсистемы.
Алгоритмы взаимодействия органов и инструментов
Учитывая высокую вычислительную сложность моделирования процессов в операционном поле, при построении алгоритмов взаимодействия объектов необходимо стремиться достигнуть максимально возможной производительности при сохранении гибкости поведения объектов.
Рассмотрим пример алгоритма захвата органа твердым инструментом с двумя браншами в рамках моделирования эндоскопической операции. Инструмент может быть представлен как композитное твердое тело, содержащее подвижные части. Орган представляется в виде набора вершин, движение которых относительно друг друга ограничено законом эластичного растяжения [12]. Задача построения алгоритма захвата упрощенно может быть сформулирована следующим образом: необходимо обеспечить выполнение такого физического ограничения, при котором при достаточной степени сжатия вершин в области между браншами инструмента позиция этих вершин в системе координат, связанной с инструментом, остается неизменной при любом изменении положения инструмента.
На данном этапе исследования не рассматривается реализация тактильной обратной связи, поэтому из рассмотрения для простоты исключается воздействие захватываемого органа на инструмент, при этом инструмент считается объектом, имеющим бесконечную массу.
Выполнение данной задачи состоит из нескольких этапов:
- определение потенциально захваченных вершин;
- определение момента, когда вершина становится захваченной;
- создание и выполнение внутри подсистемы физической симуляции ограничения, обеспечивающего постоянство позиций вершин в системе координат инструмента;
- определение момента, когда вершины перестают быть захваченными;
- отмена ограничения на степени свободы вершин внутри подсистемы физической симуляции.
Среди выделенных этапов одним из наиболее вычислительно сложных является определение потенциально захваченных вершин, для которых требуется применение алгоритма проверки столкновений. Такая проверка должна выполняться для каждого органа на сцене и для каждого инструмента. Принимая во внимание тот факт, что каждый орган не всегда находится между браншами каждого инструмента, можно заменить этот процесс быстрой упрощенной проверкой столкновений.
Эту быструю проверку столкновений можно выделить в компонент, называемый триггером, который отвечает за инициирование процесса захвата и предоставляет информацию об ограниченной области поиска потенциально захваченных вершин.
Реализация ограничения позиций вершин может быть выполнена на стороне как физической подсистемы, так и модуля операционного блока, определяющего алгоритм захвата. В данной работе рассматривается вариант, при котором логика, обеспечивающая контроль позиций вершин, полностью выполняется на стороне физической подсистемы. Для этого физическая подсистема должна предоставить интерфейс для создания собственных ограничений мягкого тела, а далее нужно определить компонент, называемый, соответственно, фи-
зическим ограничением, и реализующий этот интерфейс.
Логично предположить, что разные внутренние органы имеют разную природу, поэтому одинаковая реализация алгоритма захвата, например, для сплошных и полых органов, может не обеспечивать правдоподобное моделирование поведения. Аналогично модели органов, реализованные с использованием различных алгоритмов (например PBD [13], FEM [12]), также могут требовать различной логики имитации процесса захвата. В то же время поведение инструмента практически не зависит от того, какой орган он в данный момент захватывает. Исходя из этих предположений, можно определить для каждого органа компонент, называемый фабрикой ограничений, который при обнаружении инструментом момента начала захвата будет создавать соответствующий тип физического ограничения, определяемый пользователем, описывающим операционный случай.
Наконец, можно определить компонент, называемый контроллером алгоритма и обеспечивающий обработку события начала захвата, отправку запроса на создание физического ограничения, передачу состояния инструмента физическому ограничению, обнаружение момента завершения захвата и запрос на отмену физического ограничения.
Схема взаимодействия описанных компонентов представлена на рисунке 4.
Похожим образом могут быть реализованы другие алгоритмы взаимодействия органов и инструментов (разрез, пункция, коагуляция и др.).
Сформулируем основные принципы, использованные при формулировке алгоритма:
- определение момента начала работы алгоритма посредством генерации и обработки события;
- вариативность реализации физического ограничения для различных органов;
- минимизация объема данных, передаваемых между различными компонентами.
Эти принципы позволяют формулировать алгоритмы в интуитивно понятной форме и реализовы-вать их без больших накладных расходов на взаимодействие между компонентами.
С точки зрения оператора, моделирующего сцену на базе готовых алгоритмов, добавление новой формы взаимодействия между объектами сводится к формальному описанию возможности такого взаимодействия в объектах. В приведенном примере добавление контроллера захвата к инструменту добавляет свойство «инструмент может хватать объекты двумя браншами», а добавление соответствующей фабрики ограничений в орган добавляет свойство «орган может быть захвачен двумя браншами».
Построение сцены для моделирования операционного случая
Рассмотрев базовые принципы организации взаимодействия между объектами, рассмотрим процесс создания сцены для моделирования операции на примере создания обучающего модуля эндоскопического клипирования. Операционное поле в данном случае содержит гибкую трубку, закрепленную с двух сторон, и эндоскопический клипс-аппликатор, управляемый оператором (см. рис. 5). Задачей оператора является установка трех эндоскопических клипс в заданных местах трубки, представляющей собой модель кровеносного сосуда.
Операционная сцена состоит из четырех объектов: трубка, закрепленная с двух концов; клипс-аппликатор; камера, определяющая точку и угол обзора сцены; контроллер сценария операции.
Рис. 4. Схема взаимодействия компонентов, реализующих алгоритм захвата органа
Fig. 4. An interaction diagram of components that implement the algorithm of gripping an organ
Рис. 5. Сцена для обучения эндоскопическому клипированию
Fig. 5. A scene for training endoscopic clipping
Для моделирования поведения этих объектов можно определить следующие компоненты:
- компонент физического поведения полого трубчатого тела (физическое представление трубки);
- компонент физического поведения композитного твердого тела (физическое представление инструмента);
- компонент визуализации деформируемого тела (графическое представление трубки);
- компонент визуализации композитного твердого тела (графическое представление инструмента);
- триггер начала работы алгоритма клипиро-вания;
- компонент-интерфейс для работы с аппаратным устройством ввода;
- контроллер положения эндоскопического инструмента;
- контроллер алгоритма клипирования;
- физическое ограничение, обеспечивающее изменение положения клипсы при изменении пространственной конфигурации трубки;
- фабрика физического ограничения клипиро-вания;
- камера, реализующая задание точки и угла обзора сцены для визуализации;
- точечный источник света;
- сценарий операции.
Схема объектов сцены и потоков данных между ними представлена на рисунке 6.
Большинство реализованных компонентов, составляющих объекты сцены, в дальнейшем могут быть использованы для создания моделей других операционных случаев. Например, компоненты контроля положения эндоскопического инструмента можно использовать при моделировании любой эндоскопической операции; компоненты, реализующие алгоритм клипирования, - при моделировании любых операций, где требуется работа с кровеносными сосудами, например, при моделиро-
вании проведения лапароскопической холецистэк-томии. Компоненты визуализации могут найти применение в любой другой операции.
Таким образом, при создании новой операционной сцены пользователь может повторно использовать уже имеющиеся компоненты. Необходимость в разработке новых компонентов возникает только в случае, если существующие компоненты не обеспечивают необходимой функциональности.
Использование компонентов вместо наследования функциональности позволяет описывать поведение объектов сцены на этапе выполнения программы, следовательно, дает возможность как статически (на этапе загрузки операционного случая), так и динамически (в процессе выполнения операции, например, обеспечивая адаптивную сложность) расширять и сужать функциональность поведения этих объектов, тем самым быстро адаптируя модель под нужды конкретной ситуации. Однако открытость системы при использовании такого подхода накладывает на разработчиков определенные требования к соблюдению корректности модели. Учитывая то, что любой объект может быть параметризован любым свойством без каких-либо ограничений, необходимо обеспечить контроль за совместностью получаемой модели. Если этот контроль будет находиться в области ответственности оператора, создающего модель, нарушится условие минимизации требований к технической квалификации человека, моделирующего модель. Следовательно, необходимо обеспечить механизм автоматического контроля целостности модели. Подобное средство автоматического контроля обусловливает необходимость формального определения спецификации полученной модели и аспектов взаимодействия объектов внутри этой модели.
Результаты практической реализации предложенного подхода показывают, что он может быть использован для описания различных по природе аспектов поведения объектов сцены в рамках единой архитектуры, обеспечивающей хорошую гибкость настройки поведения и активное повторное использование готовых компонентов. При этом для реализации подхода необходимы относительно небольшие накладные расходы по сравнению с описанием аспектов поведения непосредственно в объектах сцены без использования динамического связывания.
Итак, сделаем следующие выводы. Предложенные в статье принципы проектирования расширяемой программной архитектуры средств разработки ПО для самостоятельного формирования медицинским сообществом решений в среде симуляцион-ных технологий в медицине позволяют сократить временные затраты и трудоемкость создания новых хирургических тренажеров, а также адаптации существующих симуляционных решений при их внедрении и практическом использовании. Даль-
Клипс-аппликатор
Графическое представление композитного тве рдого тела
Интерфейс взаимодействия с аппаратным устройством ввода
Позиция , ориентация
Физическое представление композитного тве рдого тела
Контроллер алгоритма клипирования
Данные с датчиков
Контроллер положения эндоскопического инструмента
Позиция, ориентация, угол между браншами
Событие «Начало клипирования»
Триггер алгоритма клипирования
Запрос на создание I удаление ограничения
Событие «Клипса установлена»
Контроллер сценария операции
Сценарий операции
Трубка
Графическое представление деформируемого тела
Конфигурация вершин меша
Отображение деформации трубчатого тела в деформацию графического представления
Конфигурация трубки
Физическое представление полого трубчатого тела
Конфигурация трубки
Физическое ограничение клипирования
Фабрика физического ограничения клипирования
Эндоскоп
Камера
Точечный источник света
Отображение локальных координат относительно инструмента в глобальные координаты сцены
Позиция , ориентация
Позиция, ориентация
Контроллер положения эндоскопического инструмента
Данные с датчиков
Интерфейс взаимодействия с аппаратным устройством ввода
Рис. 6. Состав и взаимодействие объектов сцены для отработки навыка эндоскопического клипирования Fig. 6. A composition and interaction of scene objects for training endoscopic clipping
нейшие исследования направлены на формулировку и практическую реализацию основных алгоритмов моделирования собственного поведения органов и взаимодействия органов и инструментов между собой в рамках предложенного подхода.
Литература
1. Колсанов А.В., Яремин Б.И., Воронин А.С., Черепанов А.С., Иващенко А.В., Сапцин Н.В. Программное обеспечение тренажера эндоваскулярной хирургии // Программные продукты и системы. 2013. № 2. С. 262-267.
2. Колсанов А.В., Чаплыгин С.С., Иващенко А.В., Кузьмин А.В., Горбаченко Н.А., Милюткин М.Г. Программное обеспечение тренажера лапароскопической хирургии // Программные продукты и системы. 2013. №2 2. С. 267-270.
3. Колсанов А.В., Иващенко А.В., Кузьмин А.В., Черепанов А.С. Комплекс «Виртуальный хирург» для симуляционного обучения хирургии // Медицинская техника. 2013. №2 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 module 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 framework 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 framework 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.
DOI: 10.15827/0236-235X.114.158-165 Received 09.03.16
OPEN SOFTWARE ARCHITECTURE FOR SURGERY TRAINING SUITES
(The work has been done within the project of the Ministry of Education and Science of the Russian Federation, grant no. 2014-14-579-0003, agreement no. 14.607.21.0007)
Ivaschenko A.V., Dr.Sc. (Engineering), Associate Professor, Professor, [email protected];
Gorbachenko N.A., Postgraduate Student, [email protected];
(Samara State Aerospace University, Moskovskoe Highway 34, Samara, 443086, Russian Federation) KolsanovA.V., Dr.Sc. (Medics), Professor, Director (Innovative Development Institute of the Samara State Medical University, Chapayevskaya St. 89, Samara, 443099, Russian Federation)
Abstract. The evolution of modern surgical simulators considering the differences in educational technologies at different universities determines the relevance of software requirements, such as interoperability, open architecture and the ability to operate in a common information space. This paper describes the basic principles of software open architecture development for surgical simulators designed to teach surgery at medical universities. The paper focuses on the representation of surgical field objects and modeling their interaction with each other, which would provide an opportunity to create new training modules for surgical simulators. In order to create a distributed platform architecture for modeling operational cases the paper proposes using a design pattern "Entity - component". Considering the specificity of logic for a particular operating case, the paper presents a hierarchy of interaction between software modules. As the example, the authors consider the algorithm of gripping an organ by a hard instrument with two jaws in an endoscope surgery simulation. In addition, the paper considers the basic principles of interaction between objects using the example of a training module endoscope clipping. The practical implementation results of the proposed approach prove that it can be used to describe various aspects of objects' behavior in a scene within a unified architecture. It provides the flexibility to customize the behavior and active reuse of components. The proposed approach can reduce time and complexity of new surgical simulators development, as well as adapt existing simulation solutions for their implementation and practical application. This work was performed as a part of a project to create a software development kit (SDK) for medical community to deliver new simulation technologies in medicine with the possibility to exchange them in healthcare and medical education system (supported by the Ministry of Education and Science of Russian Federation (grant 2014-14-579-0003), contract 14.607.21.0007).
Keywords: software platform, component, software development kit, simulation based training, surgery training suite.
References
1. Kolsanov A.V., Yaremin B.I., Voronin A.S., Cherepanov A.S., Ivashchenko A.V., Sapcin N.V. Endovascular surgery simulation training software. Programmnyeprodukty i sistemy [Software & Systems]. 2013, no. 2, pp. 262-267 (in Russ.).
2. Kolsanov A.V., Chaplygin S.S., Ivashchenko A.V., Kuzmin A.V., Gorbachenko N.A., Milyutkin M.G. Laparoscopic surgery simulation training software. Programmnye produkty i sistemy [Software & Systems]. 2013, no. 2, pp. 267-270 (in Russ.).
3. Kolsanov A.V., Ivashchenko A.V., Kuzmin A.V., Cherepanov A.S. Virtual Surgeon System for Simulation in Surgical Training. Biomedical Engineering. 2014, vol. 47, iss. 6, pp. 285-287 (in Russ.).
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. SurgEndosc. 2011, no. 25 (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 module and its applicability in the surgical curriculum. Surg Endosc. 2007, no. 21 (9), pp. 1641-1649.
6. Cavusoglu M.C., Goktekin T.G., Tendick F. GiPSi: a framework 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. SOFA - an open source framework for medical simulation. MMVR 15 - Medicine Meets Virtual Reality. Palm Beach, US, IOP Press, 2007, vol. 125, pp. 13-18.
8. Chun Bo B., Bo Liang W. An open source based general framework for virtual surgery simulation. Proc. Int. Conf. BioMedicalEng. and Informatics (BMEI '08). 2008, vol. 1, pp. 575-579.
9. Jingming Xie. Research on key technologies base Unity3D game engine. Proc. Computer Science & Education (ICCSE). 2012, pp. 695-699.
10. Nystrom R. Component. Game Programming Patterns. Available at: http://gameprogrammingpatterns.com/compo-nent.html (accessed November 12, 2015).
11. Schulte zu Berge C., Grunau A., Mahmud H., Navab N. CAMPVis - A game engine-inspired research framework for medical imaging and visualization. Technical report, 2014, Munich, Germany. Available at: http://campar.in.tum.de/Main/ CAMPVis (accessed November 12, 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.
