Проприетарные протоколы что это
Передача данных в портативных мультимедиа-плеерах: проприетарные протоколы
Основным отличием портативных аудиоплееров «поколения Интернет» от своих предшественников является их тесная интеграция с персональным компьютером.
В прошлом портативные плееры воспроизводили музыку с распространенных сменных носителей и не нуждались в подключении к чему бы то ни было, кроме наушников
До недавнего времени ПК был для них единственным источником контента. При этом возникала необходимость в механизме сопряжения портативного плеера и компьютера. Задача заключалась в передаче данных в цифровой форме с одного носителя (в ПК) на другой (в плеере) в формате, принятом в компьютерной отрасли.
Контент необходимо перенести с компьютера, в котором он обычно хранится на жестком диске форм-фактора 3.5”, на носители портативных плееров: флэш-память, жесткие диски форм-фактора 1” и 1.8”
Следовательно, нужно задействовать какой-либо компьютерный интерфейс передачи данных.
В любом подобном интерфейсе можно выделить два уровня. Первый – физический, т.е. непосредственно провода, разъемы, микросхемы и т.п. Второй – программный, это, условно говоря, набор инструкций и алгоритмов, согласно которым осуществляется обмен данными на физическом уровне. Этот программный уровень часто называют протоколом. Сегодня мы будем в основном говорить именно о нем. Для пользователя он является «лицом» интерфейса, его возможности и недостатки определяют удобство или сложности в эксплуатации устройства в целом.
Для полноценной эксплуатации протокола необходимо наличие двух программных компонентов. Во-первых, это драйвер, занимающийся непосредственно сопряжением портативного устройства и ПК на программном уровне. Во-вторых, это программное обеспечение, позволяющее пользователю управлять протоколом и использовать его для своих нужд. ПО, строго говоря, не является непосредственной частью протокола. Но без его наличия само существование протокола теряет смысл. Поэтому в рамках данной статьи мы будем рассматривать ПО как неотъемлемую часть рассматриваемых протоколов.
Любой программный протокол использует драйверы и ПО, хотя реализация этих компонентов в каждом конкретном случае может сильно отличаться. Удачность протокола можно условно вычислить по формуле: возможности минус неудобства. Под возможностями понимается спектр доступных функций. Неудобства обычно включают в себя непрозрачность при использовании, неудобство в установке, сложность в освоении, ограниченную совместимость.
По меркам цифровой портативной техники MP3-плееры – уже достаточно немолодой класс устройств. Они появились в то время, когда инфраструктура ПК была совершенно не готова к роли компьютера как мультимедиа-хоста. И на физическом, и на программном уровне в этой области еще не существовало распространенных и стандартизированных решений, они лишь находились в разработке, готовились к выходу на рынок или существовали в штучных количествах. В схожем положении оказались другие родственные классы портативных устройств: мобильные накопители, цифровые камеры, сотовые телефоны, КПК. Все эти разновидности мобильной техники появились примерно в одно и то же время, во второй половине 90-х годов. Своим появлением они вызвали необходимость разработки единых стандартных протоколов сопряжения ПК с портативной техникой.
На физическом уровне все было относительно ясно. Первые портативные устройства были вынуждены использовать COM и LPT – других широкодоступных интерфейсов в то время просто не было.
LPT-разъем до сих пор можно найти на большинстве ПК
Так, именно физический интерфейс LPT использовался родоначальниками MP3-плееров, Saehan MpMan и Diamond Rio. Этот период можно назвать «кустарным», разработчикам приходилось использовать интерфейсы и протоколы, изначально созданные для совершенно иных задач.
Однако мучаться в оковах медленных и неудобных интерфейсов новому поколению портативного аудио пришлось недолго: уже в следующем 1999 году производители представили широкий спектр устройств, использующих новый стандарт: USB, Universal Serial Bus.
Какое-то время наблюдалась видимость борьбы между USB и распространенным главным образом на компьютерах Apple Macintosh протоколом Firewire.
Война Firewire-USB в портативных плеерах: от iPod 1G – только Firewire – до iPod 5G – только USB
Однако основная масса портативного аудио быстро и безболезненно пересела на Universal Serial Bus, закрыв, по крайней мере в рамках проводных решений, вопрос с передачей данных на физическом уровне.
Далеко не так просто сложилось все для программных протоколов. В тот короткий период, когда производители вынужденно использовали COM и LPT, программные протоколы были исключительно их собственной разработки. Никакими другими они быть, собственно, и не могли, т.к. и COM-, и LPT-интерфейсы создавались в свое время, естественно, совсем не для передачи мультимедийных файлов на портативные цифровые проигрыватели. Разрабатывать драйверы и программные оболочки для последних кроме самих разработчиков было некому, а о стандартизации речи и вовсе не шло.
Но и появление USB не решило проблему. Индустрия в первую очередь озаботилась созданием стандартных протоколов для мобильных накопителей, цифровых камер. Ситуация с MP3-плеерами была вообще не ясна: запретят их или нет, а если все же не запретят, то какими особенностями должны обладать протоколы, чтобы форум SDMI дал добро. В подобных условиях разработка программных протоколов по-прежнему лежала на плечах разработчика устройства. Так продолжалось не менее четырех лет, пока, наконец, в плеерах не начали появляться стандартные протоколы передачи данных. Эти годы были временем господства первой разновидности программных протоколов – проприетарных или закрытых.
Характерной их чертой являлись индивидуальные драйверы и программное обеспечение для каждого производителя, а зачастую и для каждого нового поколения плееров в рамках продукции одного и того же производителя.
Проприетарный протокол на примере RCA-Thomson Lyra. Используется собственный драйвер (PDP2222.SYS), который необходимо устанавливать отдельно на каждый ПК, к которому планируется подключать плеер
Это создает множество неудобств для пользователя. Ни о какой прозрачности речи нет – пользователь сам вынужден вручную устанавливать драйверы и ПО для своего плеера. При этом могут возникать различные сложности, к примеру, если покупатель по ошибке подключит плеер к ПК раньше установки драйверов.
Перепутав порядок действий при подключении плеера, пользователь рисковал любоваться подобным сообщением, даже установив впоследствии все необходимые драйверы
О совместимости тоже лучше забыть: драйверы и ПО работали лишь с данной моделью плеера (в лучшем случае – с несколькими моделями от данного производителя), а плеер мог работать только с ПК, на котором установлены данные драйверы и ПО. Возможности программных оболочек поначалу были совсем скудны и ограничивались исключительно копированием аудиофайлов в память плеера. Позже появилось разнообразие в способах копирования контента на плеер: индивидуально по трекам или синхронизацией содержимого памяти плеера с содержимым скомпонованной из аудиофайлов, находящейся на ПК библиотеки. Отдельные программные оболочки поддерживали лишь один из этих способов. Со временем ПО обретало дополнительные возможности, к примеру, копирование любых файлов, а не только поддерживаемых плеером, что давало возможность использования его как накопителя (функция получила прозвище Data Taxi). Однако тот факт, что для данной операции была обязательна установка на ПК драйверов и ПО, серьезно снижал полезность этой функции. О высоких эстетических качествах, безукоризненной работе и хорошей эргономике оболочек речь, как правило, и вовсе не шла. Пользователи тогда были в массе своей людьми суровыми и неизбалованными: копируются файлы на плеер – и ладно.
Через проприетарные системы прошло большинство производителей: iriver, Rio Audio, Creative, Cowon, Mpio и т.д. У каждого из этих производителей в свое время были и свои драйверы, и свое программное обеспечение, у кого-то более, у кого-то менее удачное. В любом случае, сменив плеер на устройство другого производителя, пользователь был вынужден приспосабливаться к новой оболочке с ее логикой и особенностями. Многие производители продолжают и сегодня комплектовать свои устройства этими программами как альтернативой стандартам MSC/UMS или MTP-решениям.
Проприетарные оболочки-менеджеры: Iriver Music Manager, Cowon JetAudio, Mpio Manager, Creative Play Center
Зоопарк всевозможных оболочек не мог устраивать потребителей (с существованием кучи разношерстных драйверов они еще могли смириться). Не устраивал он и производителей, особенно небольших, не имевших ресурсов на разработку качественного программного обеспечения. Поэтому в 1999 – начале 2000-х годов определенную популярность обрело использование оболочек сторонних производителей.
Среди них можно выделить программу MusicMatch Jukebox.
Интерфейс MusicMatch Jukebox
До появления iTunes для Windows PC именно она использовалась здесь для работы с Apple iPod. Работала она и с плеерами других производителей, таких, как RCA-Thomson.
Программы типа MusicMatch Jukebox были первыми ростками стандартизации. Они позволяли использовать плееры разных производителей без установки дополнительного ПО для каждого из них. Решение не было безупречным, это был лишь шаг от разномастных протоколов и оболочек к стандартизированным решениям. В данном случае же был стандартизирован только интерфейс управления протоколом, установка отдельных драйверов для каждого устройства по-прежнему оказывалась необходимой. Сами оболочки не входили в состав операционной системы, их было необходимо устанавливать отдельно, из Интернета или с сопутствующего CD. Их функциональность, стабильность работы и удобство зачастую также вызывали вопросы. Поддерживались далеко не все плееры, что вынуждало производителей комплектовать свои устройства плагинами для популярных программ-менеджеров.
Доступно для скачивания на сайте RCA-Lyra: в первую очередь плагин для MusicMatch Jukebox и только потом собственная оболочка Lyra DJ
Обычно со временем программа «толстела», обрастала ненужными пользователю функциями, рекламой, требовала все больше ресурсов.
Еще одна популярная в прошлом оболочка – RealJukebox
Одновременно росло давление конкурентов: в 2001 году Windows Media Player вошел в стандартную поставку Windows XP, в 2003 году появился iTunes для Windows. Небольшие азиатские компании в 2002-2003 году также нашли хорошую замену этому ПО – открытый протокол MSC/UMS. В результате оболочки типа MusicMatch Jukebox сошли со сцены, чтобы уступить место протоколам нового поколения. Но их наследие не пропало даром: модель «одна оболочка для разных плееров» во многом унаследована системой Microsoft PlaysForSure.
Одна черта проприетарных систем, однако, позволила им прожить на отдельных рынках дольше разумного. Их закрытость создавала препятствия при использовании плеера для свободного переноса данных с ПК на ПК, то есть, по версии RIAA, при использовании его как орудия цифрового пиратства. На проблемных рынках, наподобие американского, компании, не желающие привлекать к себе лишнего внимания, продолжали придерживаться проприетарного подхода даже после распространения универсальных решений.
На сайте iriver непроприетарные прошивки до сих пор отмечаются особо, как UMS или MTP
Тут можно вспомнить, к примеру, iriver или Creative. Плееры iriver вообще выпускались в двух вариантах: для рынка США – работающие через проприетарный протокол, для других – через открытый MSC/UMS. Такая «жизнь после смерти» для закрытых протоколов продолжилась вплоть до выхода в 2004 протокола MTP, который, будучи относительно универсален, устроил и звукозаписывающие компании.
Период 2002-2004 гг. был переходным от «темных веков» закрытых систем к относительной открытости современных протоколов. Сегодня чистые проприетарные протоколы полностью вышли из употребления.
Там, где Wi-Fi не справляется. Применение проприетарных беспроводных технологий в промышленности и не только
Вдохновившись интересом к моему посту по проводным промышленным сетям, хочу продолжить свои изыскания и рассказать о беспроводных технологиях. Существует множество сценариев беспроводных подключений, где самые распространённые технологии – Wi-Fi и LTE не вполне справляются. В этих случаях стоит обратиться к проприетарным беспроводным технологиям. Одним из таких решений под названием Ultra-Reliable Wireless Backhaul недавно обзавелась компания Cisco. Предлагаю в нем разобраться, посмотреть где такие решения применяются – вместо или вместе с стандартными технологиями, и как там устроена передача данных.
Для чего это нужно?
Решение Cisco Ultra-Reliable Wireless Backhaul выросло из продуктов приобретённого компанией Cisco производителя FluidMesh. Оно призвано обеспечить высокоскоростную беспроводную передачу данных на большие расстояния на стационарных и движущихся объектах.
Несмотря на наличие в названии слова Wireless, важно не путать его с привычным Wi-Fi. В сетях Wi-Fi у нас есть точки доступа и стандартизованные клиентские устройства – ноутбуки, смартфоны, планшеты. Бывает, что вместо клиентского устройства подключается ещё одна точка доступа – получается Wi-Fi-мост, из мостов можно составить Mesh-сеть, но это не совсем то, для чего Wi-Fi придуман и не то, где он проявляет себя лучше всего.
В случае с Ultra-Reliable Wireless Backhaul клиентских устройств у нас нет. Есть только устройства, которые умеют принимать и передавать данные по специальной проприетарной технологии. Для того, чтобы подключить клиентское устройство, необходимо использовать Ethernet-коммутатор и/или точку доступа Wi-Fi, подключив их к устройству Ultra-Reliable Wireless Backhaul кабелем.
Проще всего представить, что нам нужно соединить некие локации высокоскоростным кабелем, но протягивать его дорого, сложно или, в случае с подвижными объектами, невозможно. Поэтому мы ставим приёмопередатчики и делаем этот «кабель» беспроводным. Получается опорная сеть, в англоязычной терминологии — Wireless Backhaul.
Примеры использования
Стационарное соединение «точка-точка»
Самый простой пример всё тот же: вам нужно подключить новое здание на территории, скажем, завода к общей сети, а оптику туда прокладывать дорого и долго. Мост, построенный на оборудовании Cisco, позволит быстро и дёшево обеспечить подключение до 500Мбит/с. Если необходимо, можно поставить две пары устройств и получить 1Гбит/с.
Точно также решается задача подключения к сети строительных площадок. Здесь протягивать оптику смысла, как правило, вообще нет, в том числе и потому, что её скорее всего порвут.
Стационарное соединение «точка-многоточка»
Здесь хороший пример – подключение камер видеонаблюдения на территории вокруг основного здания – управления завода, торгового центра и т.п. Камеры чаще всего устанавливаются на фонарные столбы, где электропитание уже подведено ради самих фонарей, а вот с подведением Ethernet-кабеля возникает вопрос. Чтобы этого избежать – можно ставить вместе с камерами простейшие устройства Ultra-Reliable Wireless Backhaul и с каждого столба передавать данные на устройства, установленные на здание.
Транспортные средства и другие мобильные объекты
Особенности технологии Cisco Unified Wireless Backhaul, о которых пойдёт речь чуть ниже, позволяют обеспечивать очень высокое качество связи с подвижными объектами.
— На предприятиях, добывающих полезные ископаемые открытым способом с её помощью организуется связь для сбора данных телеметрии и местоположения с карьерной техники. По периметру карьера устанавливаются стационарные устройства Cisco Unified Wireless Backhaul с антеннами, направленными внутрь карьера, а на технике – мобильные с всенаправленными антеннами. Пропускной способности при этом хватает даже для передачи видео с камер, установленных на машинах.
— В шахтах Ultra Reliable Wireless Backhaul может быть использован для организации связи с машинами или поездами, ходящими внутри. Схема аналогичная: ряд стационарных устройств ставится в тоннеле для обеспечения покрытия, а мобильные устойства – на технике. Для шахт могут быть интересны и варианты стационарного использования: раздача Wi-Fi для работников, использующих планшеты, телефоны, радиометки, сбор данных и управление автоматикой – вентиляция, устройства SCADA и т.д.
— Связь между «землёй» и обычным пассажирским поездом: для раздачи Wi-Fi и сбора данных видеонаблюдения в последнем.
— Внутри железнодорожного состава Wireless Backhaul может быть использован для обеспечения связи между вагонами: два устройства устанавливаются в разных вагонах со специальными антеннами, направленными друг на друга.
— Приём и передача данных в лифты в высотных зданиях для обеспечения работы видеонаблюдения, Wi-Fi и передачи контента на мониторы, расположенные в лифтовых кабинах. Для таких целей традиционно используются специальные дорогие и сложные в установке кабели. Беспроводное решение может оказаться надёжнее и дешевле.
Зачем нужно проприетарное решение?
Кажется, что все описанные выше задачи можно решить с помощью обычного Wi-Fi, а для ситуаций, где необходима передача данных на большие расстояния – LTE. Однако возникает целый ряд проблем:
Как устроено?
Решение Ultra-Reliable Wireless Backhaul не единственное в своём роде в том смысле, что и другие производители предлагают реализации опорных сетей на базе проприетарных протоколов беспроводной передачи данных. В чём особенность Wireless Backhaul?
“Физика” от Wi-Fi
Физический уровень передачи данных реализован на чипах, полностью аналогичных тем, что используются в устройствах Wi-Fi последнего поколения (IEEE 802.11ax). Это значит, что и частоты, и каналы передачи данных используются те же самые, а значит, с точки зрения регулирующих органов, установка устройства FluidMesh выглядит также, как установка точки доступа, вещающей в нелицензируемом диапазоне 5ГГц.
В отличие от обычного Wi-Fi, физика Ultra-Reliable Wireless Backhaul даже на очень больших расстояниях способна обеспечивать MIMO.
«Логика» от операторских сетей связи
На канальном и сетевом уровнях в решении Ultra-Reliable Wireless Bakchaul используется протокол под названием PRODIGY 2.0, основанный на MPLS. MPLS – это технология передачи данных в сетях операторов связи, обеспечивающая высокую производительность и хорошую управляемость таких сетей. Использование такого протокола позволяет обеспечить качество обработки трафика – прежде всего, предсказуемую задержку передачи, которая так важна для аудио, видео и телеметрии реального времени. Для приоритетных приложений обеспечивается задержка меньше 0.3мс.
Пропускная способность
Доступная пропускная способность соединения «точка-точка» — до 500Мбит/с. Устройства Ultra-Reliable Wireless Backhaul умеют выбирать DataRate так, чтобы он не менялся непредсказуемо при изменении расстояния или хендовере, как это происходит в Wi-Fi-сетях.
Действительно бесшовный хендовер
Протокол PRODIGY 2.0 имеет продвинутые механизмы хендовера – переключения с одной базовой станции на другую. В обычном Wi-Fi переключение происходит следующим образом: при падении соотношения шум/сигнал ниже порогового значения клиентское устройство переключается на другую доступную точку доступа с максимальным соотношением шум/сигнал. При этом это клиентское устройство ничего не знает о том, насколько хорошо будет работать связь с новой точкой. Кроме того, как уже говорилось выше, чтобы переключиться на новую точку ему необходимо сначала разорвать соединение с предыдущей, то есть существует промежуток времени, хоть и короткий, в течение которого данные передаваться не могут. Даже при так называемом «бесшовном» хендовере. В протоколе PRODIGY 2.0 на устройствах Ultra-Reliable Wireless Backhaul переключение реализовано иначе: обмениваясь данными с текущей базовой станцией, устройство ищет вторую доступную, устанавливает с ней соединение, тестирует его и только потом переключает в него поток данных.
Перестроение Mesh-сети при отказе
Mesh-сети строятся из некоторого количества беспроводных точек доступа или базовых станций, передающих данные от одной к другой. В случае отказа одного из устройств, его соседи должны оперативно перестроить передачу данных через другие доступные, если это возможно. Сеть Ultra-Reliable Wireless перестраивается менее чем за 500мс.
Безопасность
Здесь всё просто: помимо встроенных механизмов шифрования трафика с помощью AES, передача данных с использованием проприетарного протокола остаётся невидимой для анализаторов Wi-Fi. Подменить базовую станцию, чтобы подключиться к вашей сети, у злоумышленника тоже не получится – от этого защищает механизм аутентификации.
От попыток заглушить сеть шумами защищает механизм автоматической смены частот (Frequency Hopping).
Поддержка PROFINET
Ultra Reliable Wireless Backhaul умеет правильно передавать пакеты, относящиеся к работе распространённого протокола промышленной автоматизации PROFINET. Применение технологии допускается и в сетях PROFINET Conformance Class B.
Структура сети
С простыми случаями, вроде соединений «точка-точка» всё понятно. Структуру же большой сети Ultra Reliable Wireless Backhaul, проще всего понять по аналогии с Wi-Fi.
Сама сеть строится из базовых станций – это аналоги точек доступа.
Шлюзы (Gateway) выполняют агрегацию MPLS трафика и являются его точкой выхода в сеть предприятия. Шлюзы не обязательная составляющая решения, поскольку они не являются беспроводным контроллером в понимании Wi-Fi решений. Каждая базовая станция может выполнять роль шлюза, но ограничена пропускной способностью в 500 Мбит/с. Если необходима суммарная пропускная способность выше 500 Мбит/с, тогда нужна установка шлюза. Шлюзы доступны для пропускной способности 1 Гбит/с и 10 Гбит/с.
Дополнительно ко всему этому прилагается система мониторинга FM-Monitor и система управления RACER – аналог в Wi-Fi – Cisco Prime Infrastructure или DNA Center.
Здесь аналогия с Wi-Fi-заканчивается. В плане взаимодействия точек доступа между собой сеть больше похожа на проводные Ethernet-сети:
Как общаться в проприетарном зоопарке или проблема совместимости медицинских устройств
Проблема совместимости медицинских устройств
Современный мир трудно представить без отраслевых стандартов, позволяющим интегрировать решения различных производителей в единую систему. Такие технологические системы могут взаимодействовать и обмениваться данным, многократно повышая производительность и удобство пользования. Примеров можно привести множество – начиная от стандартизованных информационных протоколов до международного стандарта стыковочной системы применяемой на Международной космической станции.
К сожалению отрасль здравоохранения отстает от других отраслей в обеспечении совместимых и безопасных систем и компонентов. В этой статье мы рассмотрим проблему совместимости PoC медицинских устройств и возможные пути решения.
PoC медицинские устройства
Концепция проведения диагностических тестов рядом с пациентом также известна как Point-Of-Care диагностика. Пример PoC медицинских устройств:
Мобильный рентгеновский аппарат
Совместимость медицинских устройств со сложившиейся информационной инфраструктурой медицинского учреждения
До эры открытых стандартов каждый производитель PoC медицинских устройств разрабатывал собственные проприетарные коммуникационные протоколы. Таким образом только медицинские устройства одного бренда могли беспроблемно взаимодействовать внутри больничной инфраструктуры, что ставило руководство клиник в условия сложного выбора производителя. Невозможность обеспечить безопасное и устойчивое взаимодействие устройств различных производителей привело к необходимости разработки открытых протоколов взаимодействия медицинских устройств.
Медицинская отрасль во многом консервативна, и, в отличии от, например, рынка смартфонов, где срок жизни новой модели от вывода на рынок до устаревания очень короток, медицинские устройства находятся в реальном использовани много лет, некоторые модели могут производится и использоваться десятилетиями.
На текущий момент в реальных клиниках используется большой зоопарк проприетарных устройств, которые по различным причинам невозможно быстро заменить на аналогичные по функционалу устройства с открытыми протоколами.
Идеальным решением является создание новых PoC медицинских устройств, изначально спроектированных для использования с открытыми протоколами. И хотя многие производители медицинского оборудования уже сейчас разрабатывают подобные устройства, тем не менее пройдет не мало времени пока они появятся на рынке. Так же остается открытой проблема дальнейшего использования медицинских устройств старого образца, весьма дорогих и вполне еще работоспособных.
Интегрировать же новые протоколы в уже существующие легаси устройства потребует значительных усилий, сравнимых с разработкой нового устройства с нуля. Необходимо будет заново протестировать, сертифицировать, поменять прошивку на каждом из устройств, частично парализовав работу клинику.
Совместимость протоколов (Interoperability)
Способность двух или более устройств (разного типа, модели или производителя) обмениваться информацией (независимо от того, подключены ли они друг к другу напрямую или через систему связи) и эффективно использовать информацию, которой обменивались.
Конвертер протоколов или виртуальный мост
Промежуточным звеном между легаси PoC устройствами и новыми PoC SDC-совместимым устройствами является конвертер проприетарных протоколов, который будет связывать вместе устройства нового поколения и устаревшие в ИТ-инфраструктуре больницы.
В этой статье Аурига делится своим опытом разработки решения и проблемами, которые могут возникнуть при преобразовании проприетарных протоколов в открытый стандарт IEEE 11073 Service-oriented Device Connectivity (SDC)
Что такое SDC?
SDC был задуман и разработан OR.NET, некоммерческой организацией, объединяющей производителей медицинских устройств, клиницистов и исследователей.
Что такое MDIB?
В SDC широко используется понятие как MDIB – Medical Device Information Base. MDIB является описанием PoC медицинского устройства как абстрактной модели возможостей медицинскго устройства в статической описательной части и текущего состония устройства в динамической части. Для такого описания используется формат XML.
Процесс создания MDIB как модели медицинского устройства весьма сложен.
MDIB должен содержать описание всех измеряемых устройством метрик, медицинских тревог и поддерживаемых операций по удаленному изменению настроек.
Например PoC медицинское устройство измеряет частоту сердечных сокращений (Heart Rate или сокращенно HR), результатом будет numeric metric со значением текущего пульса. Так же на экране будет видна кривая каридогрммы, она же вейформа и будет представлена в MDIB соответствующей метрикой.
Метрики могут объединяться в каналы, а каналы объединяются в VMD – Virtual Medical Device. Таким образом реальное медицинское устройство делится на логические сущности, VMD, например если медицинское устройство измеряет температуру, ЭКГ и уровень сатурации, то в MDIB будет три соответствующих VMD – Temperature Monitor, ECG Monitor и SpO2 Monitor.
Если значения измеренного HR будет превышать установленный min или max, медицинское утройство сгенерирует медицинскую тревогу, medical alert. В MDIB этому соответствует Alert System.
Соответственно медцинское устройство предоставляет сервис по изменению настроек min/max, и в MDIB этому соответсвуют операции из Control Service.
Каждый объект MDIB содержит множество аттрибутов, которые необходимо корректно установить и тонко настроить.
BodySites и PhysicalConnectors
Одним из аттрибутов метрики является bodysite, а именно часть тела пациента являющаяся источником метрики. Например температуру можно измерять подмышкой или во рту, это будет немного разная температура.
И если bodysite можно грубо представить как координату на теле пациента, то за координаты на медицинском устройстве отвечают PhysicalConnectors, например устройство может иметь несколько портов для температурных датчиков, и за каждому порту будет соответсвовать свой PhysicalConnector.
Установка аттрибутов легаси медицинского устройства в MDIB
Для корректной работы SDC протокола необходимо предварительно разработать описание легаси медицинского устройства как совокупность метрик, медицинских тревог и других аттрибутов MDIB.
PoC медицинское устройство может быть транслировано в MDIB множеством способов из-за гибкой структуры MDIB. Процесс создания MDIB может быть упрощен путем разделения на итерации, а именно необходимо:
Составить список сигналов мединского устройства на основе анализа проприетарного протокола
Составить прототип MDIB содержащим только метрки и вейформы на основе списка сигналов
Расширить описание метрик используя технические особенности мединского устройства используя такие SDC объекты как bodysites и physical connectors
Исследовать работу мединцинское устройство на различных сценариях, на основании полученных данных расширить MDIB алертами
Исследовать различные сценарии удаленного измения настроек медицинского устройства, на основании полученных данных расширить MDIB операциями контроля на основе SDC сервисов
Реализовать сложные сценарии, выявив список не покрытых SDC требования, и составив список исключений
Автогенерация зависимостей в статической части MDIB
Статическая часть MDIB содержит описание абстрактной модели медицинского устройства.
Такая модель для реальных устройств может содержать тысячи узлов, поэтому довольно сложно и дорого каждый раз искать в MDIB какие-либо зависимости во время работы конвертера протоколов. Целесообразно в целях опитимизации минизировать такие обращения к MDIB. Одним из самых удобных инструментов такой оптимизации является использование автогенеренных таблиц зависимостей.
На этапе компиляции проекта производится парсинг XML файла как описательной части MDIB, формируются таблицы зависимостей в наиболее удобном формате. Из минусов такого подхода является снижение гибкости и не возможности горячей замены MDIB, конкретная версия контвертера будет связана с конкретной версией MDIB.
Мапинг параметров легаси медицинского устройства
Довольно часто невозможен прямой маппинг 1 в 1 из легаси протокола в SDC протокол из-за особенностей легаси протокола. В таких случаях приходится прибегать к машинам состояний (конечным автоматам), где конвертер протокола хранит историю состояний легаси устройства для корректного маппинга в SDC формате.
Синхронизация времени
Проблема синхронизации стоит довольно остро, т.к. практически любое PoC медицинское устройство предоставляет метки времни (timestamps) для метрик, вейформ, мединцинских тревог в собственном проприетарном формате, а некоторые необходимые для SDC timestamp может и вовсе не предоставлять, приходится их вычислять внутри конвертера.
Пропускная способность больничной сети
В SDC сети одно PoC медицинское устройство генерирует траффика около 80 Кб/сек из-за использования XML файлов. Типичная клиника может использовать сотни PoC устройств одновременно для диагностики пациентов, так же существует не SDC траффик вроде видео звонков и т.п. Все это необходимо учитывать на этапе построения больничной сети, необходимо оптимизировать маршрутизацию SDC траффика или даже выделять отдельное оборудование для сегмента SDC сети для избежания перегрузки больничной сети.
Кибербезопаность
В больничной инфраструктуре может использоваться два типа сетей – SDC и легаси медицинского устройства. Часто легаси сети разрабатывались очень давно и не отвечают современным нормам кибербезопаности:
Отсутствие peer-to-peer аутентификации
Сообщения проприетарного протокола не зашифрованы
Отсутствие зарезервированных TCP/UDP портов и трудности в настройке Firewall
Решением проблем является изоляция легаси сегмента сети или использование бюджетного аппаратного ключа донгла во избежание пересечения с другими сетями.
Скрытые медицинские тревоги и самостоятельная генерация медицинских данных
Некоторая критически важная информация, например факт медицинской тревоги SDC формата, может отсутствовать в легаси протоколе в явном виде зарегистрированного события, но может быть установлен по косвенным признакам в результате анализа исходящего трафика медицинского устройства. Таким образом конвертер не только обеспечивает трансфер медицинских данных из одного протокола в другой, но и самостоятельно может генерировать такие данные, устанавливать факт медицинской тревоги или вычислять какие-то метрики, что может повысить класс безопасности конвертера до медицинского устройства.
Хороший пример это вычисление данных waveform усиленных отведений от конечностей aVL, aVR, aVF как линейную комбинацию стандартных отведений I, II, III:
В случае если легаси медицинское устройство измеряет и передает только основные параметры кардиограммы, конвертер протоколов может самостоятельно вычислять дополнительные параметры.
Требования к конвертеру протоколов
Конвертер протоколов должен работать автоматически и автономно без какого-либо взаимодействия с пользователем. Для всех поддерживаемых протоколов он должен выглядеть как собственное устройство, действующее как прокси (виртуальный мост).
Определять тип устройства, версию протокола и другие важные настройки для правильной работы
Автоматически восстановливаться в случае сбоя программного или аппаратного обеспечения
Поддерживать автоматическое обнаружения устройств и hot-plug сценарии
Учитывать требования кибербезопасности, такие как шифрование, разделение сетей, white lists
Общие проблемы проприетарных протоколов
Хотя проприетарные протоколы и отличаются у различных производителей медицинских устройств, вызовы и сложности при разработке конвертеров будут в той или иной степени общими. Рассмотрим основные подводные камни конвертеров проприетарных протоколов и методы их преодоления.
Проблема №1 – Отсутствие документации
Подробное описание проприетарного протокола может отсутствовать в силу различных причин, от бюрократических проволочек и юридических запретов до банального разгильдяйства разработчиков. Как следствие возможные артефакты незадокументированного поведения медицинского устройства придется исследовать методом реверс-инжиниринга.
Проблема №2 – Сложные сценарии поведения медицинского устройства
Для разработки и тестирования медицинских устройства на рынке представлены симуляторы пациента, позволяющие прорабатывать основные состояния параметров пациента в широких диапазонах. Однако такие симуляторы пациента не позволят воспроизвести сложные сценарии поведения медицинского устройства, например такие симуляторы не позволят вопроизвести техническую неисправность самого PoC устройства, например неисправность какого-либо сенсора, клапана и мотора помпы.
Медицинское устройство как правило имеет возможности самодиагностики и предоставляет информации о технических проблемах через проприетарный протокол, и, конечно же, представляется невозможным физически разрушать устройство для таких сценариев.
Для решения этой проблемы Аурига использует симулятор медицинского устройства собственной разработки, позволяющие протестировать конвертер протокола для таких сложных технических сценариев. Симулятор устройства представляет собой сетевое приложение, моделирующие поведение медицинского устройства в проприетарном коммуникационном протоколе. Такой симулятор позволяет работать без реального медицинского устройства, что так же полезно для автоматического тестирования.
Резюме
Можно с уверенностью утверждать что область телемедицины, совместимых PoC медицинских устройств и удаленной диагностики будет иметь большой спрос в ближайшем будущем, а значит с проблемами interoperability и вызовами разработки совместимых коммуникационных протоколов столкнутся многие участники рынка.
Опыт разработки конвертеров протоколов показывает что идеи заложенные в проприетарные коммуникационные протоколы 80х-90х годов уже значительно устарели и не позволяют реализовать простой маппинг 1 в 1 в совместимые SDC протоколы. В этой статье мы рассмотрели некоторые проблемы конвертации и способы их преодоления.