Не думайте об этом как о данных реального времени или медицинских данных — думайте об этом как о пакетах данных, которые необходимо сжать для передачи (скорее всего, в пакетах TCP). Детали содержимого имеют значение только при выборе алгоритма сжатия, и даже здесь важно не то, является ли оно медицинским, а то, как данные форматируются/хранятся и как выглядят фактические данные. Важными вещами являются сами данные и ограничения, связанные со всей системой (например, это сбор данных, такой как монитор Холтера, или отчет о состоянии в реальном времени, такой как кардиомонитор в отделении интенсивной терапии? Какая система получает данные? данные?).
Глядя на данные, представляются ли они для передачи в виде необработанных двоичных данных или принимаются от другого компонента или устройства в виде (например) структурированного XML или HL7 с числовыми значениями, представленными в виде текста? Будет ли сжатие исходных данных наиболее эффективным вариантом, или их следует преобразовать в собственный двоичный формат, который покрывает только фактический диапазон данных (достаточно ли 2, 3 или 4 байтов, чтобы покрыть диапазон значений?)? Какая экономия может быть достигнута путем конвертации и каковы проблемы совместимости (например, потеря совместимости с HL7).
Выбор абсолютно лучшего алгоритма сжатия также может не стоить много дополнительной работы, если только вы не собираетесь работать в сценарии с чрезвычайно низкой пропускной способностью; если данные поступают со встроенного устройства, вы должны сбалансировать эффективность сжатия с возможностями и ограничениями встроенного процессора, набора инструментов и окружающей системы для работы с ним. Если специально созданная процедура сжатия экономит вам 5 % по сравнению с тем, что уже встроено в инструменты, стоит ли дополнительное время кодирования и отладки и место для хранения во встроенной флэш-памяти? Существующие проверенные программные библиотеки, которые обеспечивают "достаточно хороший" результат, могут быть предпочтительными, особенно для медицинских устройств.
Наконец, в зависимости от среды вы можете захотеть пожертвовать большой частью сжатия в пользу некоторого уровня избыточности, например, передачи скользящего окна данных, чтобы потеря любых X-пакетов не приводила к потере данных. Это также может позволить вам изменить протоколы и изменить конфигурацию устройства — разница между потоковой передачей UDP (без повторной передачи потерянных пакетов) и TCP (где отправителю может потребоваться повторная передача) может быть значительной.
И теперь, когда я болтал о системной стороне, появилось много информации о пакетировании и потоковой передаче аналоговых данных, начиная от разработки протоколов потоковой передачи, таких как RTP, чтобы узнать подробности пакетирования голоса для GSM/CDMA и VOIP. Тем не менее, наиболее важными факторами, определяющими ваши решения, могут стать наборы инструментов, доступные вам на стороне устройства и сервера. Использование существующих наборов инструментов, даже если они не являются наиболее эффективным вариантом, может позволить вам значительно сократить время разработки (и время выхода на рынок), а также может упростить сертификацию вашего устройства/продукта для медицинского использования. С точки зрения бизнеса, дополнительные 3-6 месяцев на разработку программного обеспечения, поиск действительно квалифицированных разработчиков и получение разрешений регулирующих органов, вероятно, будут решающими факторами.
ОБНОВЛЕНИЕ 01/02/2012: я только что провел несколько минут, просматривая XML-экспорт ЭКГ сердечного стресса в 12 отведениях с общим временем наблюдения более 12 минут и размером XML-файла ~ 6 МБ. . По моим оценкам, более 25% этого файла были повторяющимися и ЧРЕЗВЫЧАЙНО сжимаемыми XML-файлами в заголовках исследования, а данные формы волны представляли собой числа, разделенные запятыми, в диапазоне от -200 до 200, сосредоточенные в центре диапазона и медленно меняющиеся. , с числами, пересекающими ось Y и остающимися на этой стороне некоторое время. Предполагая, что большая часть того, что вам нужно, — это значения формы волны, для этого примера вы будете смотреть на скорость передачи данных без сжатия 4500 КБ / 763 секунды или около 59 Кбит / с. Полностью несжатый и с использованием текстового форматирования, вы можете легко запустить его через GPRS-соединение «2,5G». В любой современной беспроводной инфраструктуре используемая полоса пропускания практически незаметна.
Я все еще думаю, что стандартные библиотеки сжатия съели бы такие данные на обед (с учетом проблем с заголовками сжатия и, возможно, заголовками пакетов). Если вы настаиваете на выполнении пользовательского сжатия, я бы посмотрел на отправку значений разницы, а не на необработанные числа (если только ваши необработанные данные уже не смещены). Если ваши данные выглядят примерно так, как я просматриваю, вы, вероятно, могли бы преобразовать каждый элемент в 1-байтовое значение от -127 до +127, возможно, зарезервировав крайние концы как «специальные» значения, используемые для переполнения (обработайте их, как вы видите fit - специальное представление, ошибка и т.п.). Если вы предпочитаете быть немного менее эффективным при передаче и незначительно быстрее в обработке, вы можете вместо этого просто отправить каждое значение как подписанное 2-байтовое значение, которое все равно будет использовать меньшую полосу пропускания, чем текстовое представление, потому что в настоящее время каждое значение в любом случае составляет 2+ байта. (значения 1-4 символа плюс разделители больше не нужны).
По сути, не беспокойтесь о размере данных, если только они не будут работать 24 часа в сутки 7 дней в неделю по высокоскоростному беспроводному соединению с низкими ограничениями.
person
fencepost
schedule
29.01.2012
