Оглавление

Введение                                                                                                        3

1.      Цели и задачи                                                                                        5

1.1.   Цель работы  . . . . . . . . . . . . . . . . . . . . . . . . . .        5

1.2.   Поставленные задачи  . . . . . . . . . . . . . . . . . . . . .        5

2.      Возможные решения                                                                          6

2.1.   Удаленная база данных .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . . .        6

2.2.   Облачные вычисления    . . . . . . . . . . . . . . . . . . . .        7

2.3.   Сервер    . . . . . . . . . . . . . . . . . . . . . . . . . . . . .        8

3.      Стек технологий                                                                                    9

4.      Архитектура сервера                                                                       10

4.1.   Модульность  . . . . . . . . . . . . . . . . . . . . . . . . . .      10

4.2.   Работа с базой данных    . . . . . . . . . . . . . . . . . . . .      11

5.      Модуль  измерения  частоты сердечных сокращений             13

5.1.  Реализация модуля  . . . . . . . . . . . . . . . . . . . . . .      13

5.2.   Тестирование модуля  . . . . . . . . . . . . . . . . . . . . .      14

Заключение                                                                                                17

Листинги                                                                                                     18

Список литературы                                                                                 20

Введение

Одним из самых главных приоритетов в жизни людей всегда явля- лось поддержание и укрепление здоровья. Для этого ученые, универси- теты и даже частные компании1 постоянно проводят различные иссле- дования, а также испытания с целью измерения и отслеживания всевоз- можных биологических маркеров человека (например, пульса, объема легких, либо же способности человека удерживать равновесие). Иссле- дования человеческого организма как правило проводятся в специаль- ных условиях. Снятие некоторых биологических маркеров2 является достаточно долгой и сложной процедурой [1]. Для проведения измере- ний может потребоваться специальное помещение и дорогостоящее обо- рудование. Кроме того, нужны грамотные специалисты, которые будут следить за процессом измерения и поддерживать необходимые условия для экспериментов, и добровольцы, которые будут выполнять заданные исследователямиуказания.

Альтернативный подход для измерения биологических маркеров — использование тех инструментов, которые доступны практически каж- дому, например, мобильных телефонов и фитнес-браслетов. Их дат- чики, безусловно, не имеют высокой точности лабораторного оборудо- вания, но иногда являются удовлетворительными. На данный момент уже существует огромное множество различных приложений, выпол- няющих измерения тех или иных биологических маркеров (их даже можно найти в AppStore3 и GooglePlay4 ).

В СПбГУ и СПбНИИФК5 регулярно проводятся исследования в об- ласти физической культуры и спорта, и есть спрос на подобные при-

1Например, компания Nike, которая известна практически во всем мире, имеет свою команду ис- следователей [5]. Среди актуальных исследований — анализ формы и возможностей сгибов стопы, а также измерение её давления на поверхность [6].

2Биологический маркер (биомаркер) — характеристика, которая используется для индикации со- стояния организма.

3Instant            Heart            Rate:            HR            Monitor:             https://itunes.apple.com/us/app/ instant-heart-rate-hr-monitor/id409625068 (дата обращения: 08.05.2019)

4Accurate Heart Rate  Monitor:  https://play.google.com/store/apps/details?id=com.repsi. heartrate (дата обращения: 08.05.2019)

5ФГБУ СПбНИИФК. Санкт-Петербургский научно-исследовательский институт физической куль- туры: http://www.spbniifk.ru/ (дата обращения 10.05.2019)

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

В рамках работы с СПбНИИФК планируется разработка целого

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

1.       Цели и задачи

1.1.      Цель работы

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

1.2.      Поставленные задачи

Для выполнения обозначенной цели были выделены следующие за- дачи:

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

2.       Возможные решения

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

2.1.      Удаленная база данных

В рамках курсовой работы поставлена задача создания сервера для сбора биологических маркеров. Одним из альтернативных решений яв- ляется использование удаленной базы данных. Например, известным продуктом в этой области является GOOGLE FIREBASE7. Это решение предоставляет нереляционную базу данных для хранения и считывания произвольной информации.

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

Другая проблема связана с тем, что произведение всех расчетов на клиенте означает, что если в алгоритме обработки данных нашлась се- рьезная ошибка, нужно будет в срочном порядке обновлять все клиент- ские приложения для её полного исправления. Если клиентов много, это может быть проблематично, поскольку пользователи невсегда придают должное внимание обновлениям, в связи с чем редко устанавливают их самостоятельно. При этом, даже уведомления о срочной необходимости установки новой версии зачастую игнорируются [7].

7https://firebase.google.com/ (дата обращения: 10.05.2019)

2.2.      Облачные вычисления

Хорошим дополнением к удаленной базе данных могли бы служить облачные вычисления. Тогда алгоритмы обработки биомаркеров не при- ходилось бы хранить на клиентском приложении, и проблема обновле- ния клиентов при обнаружении критических ошибок стала бы неакту- альной. Разработки, использующие облачные вычисления, ещё называ- ют бессерверными, поскольку все операции производятся на серверах компаний, предоставляющих своим клиентам вычислительные мощно- сти. Стратегия работы с облаком выглядит следующим образом: дан- ные собираются с устройства и отправляются на заданный URL, после этого вызываются известные заранее пользовательские функции, ко- торые производят обработку данных и, если необходимо, сохраняют какой-то результат в облачное хранилище. Такой подход избавляет от необходимости развертывания сервера и поддержки его работоспособ- ности, позволяет легко масштабировать проект при необходимости и платить только за используемые ресурсы. Среди известных провайде- ров облачных вычислений числятся крупные компании с высоким ко- эффициентом доверия: Amazon (AWS Lambda8), Google (Google Cloud Platform9), Microsoft (Azure10), IBM (IBM Cloud11) идругие.

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

8AWS Lambda: https://aws.amazon.com/ru/lambda/

9Google Cloud Platform: https://cloud.google.com/products/

10Microsoft Azure: https://azure.microsoft.com/ru-ru/

11IBM Cloud: https://www.ibm.com/cloud/

12Например, согласно федеральному закону Российской федерации от 27.07.2006 N 152-ФЗ ”О персо- нальных данных” информация, относящаяся к состоянию здоровья человека, а также сведения, кото- рые характеризуют его физиологические и биологические особенности, на основании которых можно установить его личность, попадают под определение ”персональных данных” и для их сбора, хранения и обработки требуют выполнения специальных, описанных в законе условий.

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

2.3.      Сервер

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

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

3.       Стек технологий

Сервер написан на языке PYTHON (интерпретируемый, объектно- ориентированный язык высокого уровня), который был выбран в силу своей простоты, а также благодаря наличию множества готовых веб- фреймворков и библиотек,  облегчающих разработку. Используемая ба- за данных — POSTGRES — является объектно-реляционной и умеет ра- ботать с пользовательскими типами и сложными структурами. База данных в курсовой работе выполняет роль микросервиса. Она слабо связана с самим сервером, поскольку обновляется и поддерживается независимо от него. Для использования базы данных  в  таком  контек- сте хорошо подходит DOCKER [3]. Решение поместить её в изолирован- ный Docker-контейнер также удобно тем, что это позволяет один раз настроить конфигурационный файл, а затем использовать базу данных  на различных устройствах с различными операционными системами без необходимости установки дополнительных пакетов и их настройки. Эта особенность имеет важную роль, поскольку работа над проектом велась с разных операционных систем. Для сервера также были использованы возможности веб-фреймворка FLASK, который, по сравнению со своим известным аналогом DJANGO, является более низкоуровневым и предо- ставляет больше возможностей для настройки проекта под свои нужды. Для работы с базой данных используется библиотекаSQLALCHEMY. Она позволяет единым образом описывать запросы к разным базам данных, а также  предоставляет более удобный  интерфейс в сравнении   с использованием в коде  чистого языка SQL, благодаря чему запросы      к базе легче отслеживать и изменять.

4.       Архитектура сервера

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

4.1.      Модульность

Основная цель при проектировании сервера заключалась в том, что- бы позволить легко встраивать новые модули с различной функцио- нальностью. Для еёдостижения в корне сервера была отдельно создана специальная директория. Предполагается, что каждый новый модуль будет создаваться в ней. Любой новый модуль должен в одном из фай- лов содержать класс (менеджер), который наследует BaseAppManager, и, возможно, переопределяет некоторые его поля, среди которых ссыл- ка на обработчик запросов и ссылка на класс, осуществляющий под- готовку и фильтрацию данных для сохранения в  базу  данных  (да- лее — валидатор). Любой обработчик запросов для модуля должен унаследовать BaseRequestHandler. Аналогично, валидатор наследуется от BaseDataValidator. Минимальный рабочий модуль может содержать только менеджер.

Рабочий процесс выстроен следующим образом:

–     На выделенный для модуля URL приходит запрос в формате JSON (см. листинг 1).

–     Данные проходят через обработчик запросов.

–     Затем сохраняются согласно правилам, заданным в валидаторе.

–     В качестве ответа, сервер возвращает вычисленный результат от обработчика.

Иногда приложения могут не предполагать сохранения данных, ли- бо исключать их обработку. Для обозначения таких специальных слу- чаев внутри запроса приходят опции (options). Булевый параметр calc

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

5.1.      Реализация модуля

В качестве примера серверного модуля был разработан модуль для измерения частоты сердечных сокращений (далее — ЧСС ). Диаграм- ма классов данного модуля изображена на рисунке 2. Все вычисления происходит в рамках обработчика запросов – HeartrateRequestHandler. Поддерживается два типа измерения ЧСС: в состоянии покоя и в со- стоянии релаксации. Под состоянием релаксации понимается состояние восстановления обычной функциональности человеческого организма после выполнения физических упражнений.

Все существующие алгоритмы расчета ЧСС как правило состоят из двух этапов. Первый — преобразование кадров с камеры в какую-либо числовую характеристику. Второй — вычисление пульса в зависимости от изменения данной характеристики со временем [8]. Реализованный

на сервере алгоритм работает аналогично.

Используя клиентское приложение под ANDROID13, испытуемый в течение некоторого времени при включенном фонарике снимает данные с камеры мобильного телефона, приложив к ней указательный палец. Затем они конвертируются из формата YUV в RGB представление, из которого извлекаются значениякрасного канала. С их помощью можно явно различить моменты притока крови к пальцу. Собранные данные отправляются на сервер (описание формата см. в листингах 2 и 3), где происходит вычисление пульса в соответствующем обработчике входя- щих запросов.

Задача алгоритма  вычисления  ЧСС в  состоянии покоя  состоит   в

том, чтобы рассчитать результат, имея частоту снятия кадров с каме- ры и сигнал красного канала RGB. Для определения доминирующей частоты сигнала применяется метод, использующий быстрое преобра- зование Фурье, как наиболее точный и устойчивый к помехам [8]. Кро- ме того, для улучшения точностиизмерения в состоянии покоя также используется метод пересекающихся отрезков, суть которого состоит в том, что исходные данные разбиваются на такие отрезки, укоторых начало каждого следующего является серединой предыдущего. После разбиения доминирующая частота рассчитывается на каждом отрез- ке, а также навсех данных целиком. В качестве ответа принимается некоторое усредненное число с поправкой на доминирующую частоту. В состоянии релаксации пульс вычисляется методом скользящего окна. В исходных данных дополнительно присутствует его ширина и параметр сдвига (см. листинг 3). Метод пересекающихсяотрезков не применяется, поскольку результаты на отрезках будут  отличаться, и их будет сложно интерпретировать из-за постоянного снижения пульса. Быстрое преобразование Фурье может давать ошибку, выбирая невер- ную частоту в качестве доминирующей, поэтому из всего измерения удаляются ЧСС, сильно отклоняющиеся от среднего значения. Имею- щиеся данные затем приближаются экспоненциальной функцией14, за-

13Приложение разработано в рамках связанной курсовой работы.

14После проведения экспериментов такая функция выбрана как обеспечивающая наибольшую точ-

висящей от времени. Совокупность значений данной функции за время измерения является ответом.

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

предназначенную для модулей функциональность.

5.2.      Тестирование модуля

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

Проверка алгоритмов расчета ЧСС велась коллегами из СПБНИ- ИФК. Мобильное приложение было установлено на устройстве Sony Xperia M4 Aqua Dual (E2333). В качестве контрольного прибора ис- пользовался профессиональный пульсометр Polar M600. Во время те- стирования было выявлено, что в начале результаты измерений были удовлетворительными и слабо отклонялись от показаний контрольно- го прибора, но с течением времени показания телефона ухудшились. Было сделано предположение, что неточности могут быть связаны с дискомфортными ощущениями спортсменов из-за сильного нагревания устройства. Кроме того, в процессе проведения экспериментов неко- торые измерения признавались некачественными (сообщалось о невоз- можности вычислить пульс). В состоянии покоя это значит, что значе- ния на пересекающихся отрезках сильно отличаются. Происходит это, потому что в приложении заданы строгие критерии совпадения зна- чений. Сложившуюся ситуацию можно трактовать по-разному. С од- ной стороны, чем больше совпадений на отрезках, тем выше вероят- ность корректности результата. С другой же, слишком строгие кри- терии могут привести к тому, что большинство измерений будет счи-

ность.

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

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

Заключение

В ходе работы были достугнинуты следующие результаты:

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