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