Разработка функциональных модулей мобильного приложения на платформе iOS для музея "Оружейная палата Кремля"

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Введение

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

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

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

Отличительной особенностью приложения будет являться доработка существующего решения indoor-навигации для использования его в качестве гида по помещениям музея. Данный проект является реальным коммерческим проектом, выполняемым компанией ООО «Лаборатория мультимедийных решений».

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

Целью выпускной квалификационной работы является разработка функциональных модулей «коллекция», «карта» и «квесты» для мобильного приложения на платформе iOS для музея «Оружейная палата Кремля», использующего технологию indoor-навигации.

Для достижения цели выпускной квалификационной работы, необходимо выполнить следующий объём задач:

1. Провести аналитическое исследование существующих решений для indoor-навигации, выявить их достоинства и недостатки, выбрать лучшее.

2. Разработать модели сценариев использования приложения с использованием нотации UML.

3. Разработать объектную модель приложения.

4. Создать интерактивный прототип приложения на основе сценариев использования.

5. Разработать функциональные модули приложения: экран карты, использующий технологию indoor-навигации, экраны описания коллекции, экран игры «Квесты» в виде чата.

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

Для проведения исследования будут использованы следующие методы:

1. Анализ и сравнение - для выявления преимуществ одних решений перед другими.

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

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

1. Исследование существующих решений для indoor-навигации

1.1 Введение в предметную область и описание ключевых понятий

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

Технология навигации внутри зданий относится к проблемному полю Интернета вещей (англ.: Internet of Things, IoT), соответственно, прежде чем давать определение термину indoor-навигация, необходимо изучить различные варианты определения IoT.

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

Интернет вещей - это концепция, ориентированная на «интеллект» физических объектов (датчиков, устройств), то есть вещей, а не людей.

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

Ещё одну версию определения данного термина дает футуролог консалтингового подразделения Cisco IBSG Дэйв Эванс. Интернет вещей - момент времени, когда количество «вещей» или материальных объектов, подключенных к Интернету, превышает число людей, пользующихся «всемирной паутиной».

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

Indoor-навигация (или навигация внутри зданий) - определение местоположения объекта в локальных координатах помещения с минимальной погрешностью в расстоянии.

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

1. Навигация с помощью WiFi - данная технология основана на определении расстояния до находящихся вблизи точек доступа, и последующем применении различных алгоритмов локального позиционирования для вычисления своего местоположения относительно этих точек. У данного метода основными недостатками являются сравнительно большое энергопотребление и большая погрешность (до 25 метров).

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

3. Системы спутниковой навигации в сочетании с инерциальными навигационными системами (ИНС) - данный способ применим, когда есть возможность периодически принимать сигналы систем спутниковой навигации. При потере связи со спутниками, навигация продолжается с использованием ИНС (на базе гироскопа, акселерометра и магнитометра), которая будет использовать в качестве начальной точки последние координаты, полученные от GPS. Недостаток: при долгом отсутствии связи со спутником, ИНС допускает большое количество ошибок.

4. Использование маячков Beacon - наиболее перспективный метод, основанный на технологии Beacon - Bluetooth маяках, использующих стандарт BLE (Bluetooth Low Energy). Схема работы технологии довольно проста - имеются установленные по всему периметру целевого помещения Bluetooth-маячки, координаты расположения которых мы знаем. Эти маяки с заданной периодичностью производят широковещательную рассылку, содержащую идентифицирующую их информацию. Пользовательское приложение циклично получает эти данные, по базе данных определяет координаты маячков, и на основе силы сигнала (позволяющей определить удалённость от каждого из них) определяет своё местоположение.

5. Sensor fusion - использование для навигации данных с различных сенсоров устройства, таких как гироскоп, сенсоры магнитного излучения, акселерометр, сонар и др.

6. Синергетический эффект - самый лучший вариант, реализация indoor-навигации с использованием в той или иной мере всех вышеперечисленных технологий.

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

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

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

В данной работе будет реализовано мобильное приложение для навигации внутри музея. Из описанных выше видов навигации внутри зданий наиболее подходящим и оправданным является использование синергии различных технологий для определения местоположения.

1.2 Обзор алгоритмов локального позиционирования

Постановка условия задачи.

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

Условие математической задачи: определить декартовы координаты местоположения агента в модели помещения, на основе данных, передаваемых агенту точками доступа.

Перед построением модели следует дать определения терминам из условия задачи.

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

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

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

На рисунке 1.1 представлен пример графического условия задачи локального позиционирования на плоскости. APi - точка доступа (access point) с индексом i, (Xi, Yi) - координаты i-той точки доступа в декартовой системе координат, Pi - мощность сигнала от точки доступа с индексом i, N - количество точек доступа, А - агент, (XА, YA) - координаты агента.

Рисунок 1.1. Графическое условие задачи локального позиционирования

Для решения данной задачи может быть применён следующий набор алгоритмов:

1. Proximity (Ближайшая точка доступа).

2. Centroid (Центроид).

3. Weighted Centroid (Центр масс).

4. Fingerprinting (Сопоставление с образцом).

5. Lateration (Латерация).

6. Deduced reckoning (Навигационное счисление).

В следующих разделах приведено краткое описание принципов работы каждого из этих алгоритмов. Для последующего сравнения, при анализе данных алгоритмов следует обратить внимание на следующие их характеристики:

1. Вычислительная сложность в нотации Большое О - важна, так как вычисления требуется производить на мобильном устройстве.

2. Погрешность вычисления местоположения агента в метрах - основная характеристика качества работы алгоритма.

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

4. Вид алгоритма (базовый, улучшенный) - является ли алгоритм базовым, или расширенным, использующимся для улучшения работы предыдущего алгоритма.

Алгоритм ближайшей точки доступа

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

Преимущества данного алгоритма:

1. Низкая вычислительная сложность - O(N).

2. Простота реализации.

3. Необходимо знать только месторасположения точек доступа.

Недостатком является низкая точность алгоритма - погрешность может достигать дальности работы точек доступа в помещении (до 100 метров).

Алгоритм центроид.

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

(1)

Преимущества алгоритма Centroid:

1. Низкая вычислительная сложность.

2. Простота реализации.

3. Необходимость знать только месторасположение точек доступа.

Недостатки алгоритма Centroid:

1. Низкая вычислительная точность, большая погрешность.

Алгоритм центр масс.

Алгоритм центр масс (центроид с весами, Weighted centroid) является расширенной версией алгоритма. В данном алгоритме исправлен главный недостаток алгоритма центроид - для определения местоположения также используются данные о мощности сигналов от точек доступа. Координаты устройства агента вычисляются, как и в базовом алгоритме, с помощью нахождения линейной комбинации координат точек доступа, но добавляется характеристика веса (мощность сигнала). Точность позиционирования возрастает с подключением к дополнительным точкам доступа. По сравнению с уже рассмотренными алгоритмами, Weighted Centroid обеспечивает более высокую точность позиционирования, но её недостаточно для высокоточного определения положения в помещении. Алгоритм можно отнести к базовым, не требующим дополнительных измерении?. Формулы для вычисления местоположения агента имеют вид (i - характеристика веса):

(2)

Преимущества алгоритма центр масс:

1. Простота реализации.

2. Низкая вычислительная сложность - О(N).

3. Для вычисления достаточно знать только месторасположение точек доступа и мощность сигналов.

Недостатки:

1. Зависимость точности от количества точек доступа, одновременно доступных агенту.

Алгоритм сопоставления с образцом

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

Рисунок 1.2. Стадии позиционирования при помощи алгоритма сопоставления с образцом

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

Основным преимуществом данного алгоритма является малая погрешность, при условии плотного покрытия помещения измерениями. Из главного преимущества вытекает ряд существенных недостатков:

1. Заполнение базы данных требует большого количества времени.

2. При изменении характеристик помещения требуется переконфигурация базы данных.

3. Высокая вычислительная сложность - О(N*M), где M - количество записей в базе данных.

Алгоритм латерации или геометрический подход.

Алгоритм латерации является геометрическим подходом к решению задачи локального позиционирования. Данный алгоритм является интерпретацией аналогичного алгоритма из области геодезии. Для определения местоположения агента следует определить расстояние от него до как минимум трёх точек доступа. Затем составляется и решается система из N нелинейных уравнений. Если N равно трём, то данный подход принято называть трилатерацией. Её часто путают с триангуляцией, но это разные подходы. В отличии от трилатерации, в триангуляции координата агента вычисляется на основе координат точек доступа и углов от каждой из них до агента. Алгоритм относится к базовым, используется в геопозоционировании и сотовых сетях.

Для вычисления расстояний до точек доступа используется модель распространения радиоволн. Данная модель требует корректировки некоторых параметров, которые зависят от характеристик среды:

(3)

где d -- расстояние до агента, PL(d) -- потеря мощности сигнала на расстоянии d, PAP -- мощность сигнала точки доступа, P(d) -- мощность сигнала на приемнике на расстоянии d, d0 -- базовое расстояние (1 метр), n -- коэффициент распространения сигнала в среде.

После определения расстояний до точек доступа, высчитать положение агента можно двумя различными способами: круговой латерацией и гиперболической латерацией. На рисунке 1.3 изображены геометрические условия для обоих способов (ri - расстояние от i-ой точки доступа до агента):



Рисунок 1.3. Геометрические условия для задач позиционирования с помощью методов латерации

Для того, чтобы вычислить координаты агента с помощью метода круговой латерации, основанной на расстоянии между агентом и точками доступа, необходимо решить систему уравнении? вида:

(4)

Для вычисления координат агента по методу гиперболической латерации, которая основана на разнице расстояний между агентом и точками доступа, необходимо решить систему из уравнении? вида:

(5)

Преимущества латерационного позиционирования:

1. Высокая точность, при корректных параметрах среды.

Недостатки:

1. Необходимость калибровки параметров при изменении характеристик среды.

2. Воздействие в помещении эффектов затухающих и отраженных сигналов точек доступа, моделирование которых проблематично.

3. Довольно высокая вычислительная сложность.

Алгоритм навигационного счисления.

Алгоритм навигационного счисления (Deduced reckoning) является одним из старейших способов определения местоположения движущегося в пространстве объекта. Суть данного алгоритма заключается в вычислении или экстраполяции текущей позиции агента на основе предыдущей позиции, направления движения и скорости агента. Навигационное счисление не считается отдельным алгоритмом позиционирования и относится к улучшающим инструментам.

Рисунок 1.4. Принцип навигационного счисления

На рисунке 1.4 изображен принцип данного подхода. На рисунке (x0, y0) - последняя известная позиция агента, б - направление движения, L - преодоленная дистанция, (x1, y1) - текущая позиция агента.

Формула для определения координат текущей позиции агента:

(6)

Для вычисления пройденной дистанции используется простейшая формула:

(7)

где - скорость движения агента, а t - время движения.

Преимущества данного алгоритма:

1. Низкая сложность вычисления.

2. Использование информации о скорости, времени и направлении движения.

Недостатки алгоритма:

1. Необходимость вычисления начальной позиции.

2. Сложность сбора информации о направлении движения, скорости и преодоленном расстоянии

Выводы по обзору алгоритмов

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

1. Ни один из рассмотренных базовых алгоритмов не предоставляет достаточно малой погрешности результатов для использования их в технологии indoor-навигации без предварительного уточнения улучшающим алгоритмом (или несколькими улучшающими алгоритмами).

2. Большинство базовых алгоритмов имеют низкую вычислительную сложность и не требуют предварительных дополнительных измерений.

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

4. Большинство улучшающих алгоритмов также имеют малую вычислительную сложность.

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

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

1.3 Формализация критериев сравнения

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

Музейные залы представляют собой помещения большой площади с множеством препятствий в виде витрин (см. рисунок 1.5):

Рисунок 1.5. Планы этажей Оружейной Палаты

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

Данные требования накладывают ограничения на погрешность позиционирования в 1-2 метра. Подобную точность, а также возможность ограничить витрины, могут предоставить только решения, основанные на технологии iBeacon - или Bluetooth-маяках. Поэтому, наличие BLE-трекинга будет являться обязательным критерием.

Следующее ограничение - стоимость внедрения решения для навигации, в пересчёте на 1000 кв. м. (примерная площадь музейных залов). Данная характеристика должна быть как можно ниже, для повышения маржинальности проекта в целом.

Так как решение подбирается для разработки на его основе мобильного приложения, то одним из важнейших критериев является наличие SDK (Software Development Kit) для популярных мобильных операционных систем: iOS и Android OS.

Также, немаловажно, чтобы решение для навигации имело возможность работы как online, так и offline, без соединения с сервером. В музее бывают перебои в качестве Интернет-соединения, поэтому данная функция важна для комфорта посетителей.

Итого, основными критериями сравнения будут являться:

1. Величина погрешности позиционирования.

2. Наличие поддержки многоэтажности, возможности ограничить непроходимые объекты программно.

3. Стоимость внедрения на 1000 кв. м.

4. Наличие поддержки BLE-трекинга (iBeacons).

5. Наличие мобильных SDK.

6. Наличие возможности offline-работы.

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

1.4 Обзор рынка готовых решений для indoor-навигации

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

В настоящее время рынок решений для indoor-навигации стремительно развивается. По прогнозам Google, к 2019 году, объём целевого рынка подобных решений составит 4,4 млрд. долл. и обгонит по данному показателю рынок GPS решений.

По результатам поиска, на текущий момент, наиболее популярными на рынке корпоративных решений являются следующие платформы и продукты:

1) indoo.rs;

2) Indoor Atlas;

3) Infsoft;

4) Meridian;

5) Navigine;

6) NAO Campus;

7) Senion.

Обзор системы indoo.rs.

Компания indoo.rs была образована в 2010 году двумя студентами. Толчком к созданию системы для локального позиционирования послужило долгое пребывание в большом аэропорте и осознание проблемы навигации в таких помещениях. На текущий момент компания состоит из 28 сотрудников, распределенных по 3 офисам в Европе и США. Наиболее крупными клиентами фирмы на данный момент являются Национальный аэропорт Сан-Франциско и различные логистические компании.

Система локального позиционирования indoo.rs основана на синергии технологий iBeacon и sensor fusion. По данным с сайта компании, для первичного определения положения агента используются алгоритмы ближайшей точки доступа (Proximity) и трилатерации. Также, для улучшения точности позиционирования используется алгоритм Fingerprinting. Как заявляют разработчики, сложность сбора данных, характерная для этого алгоритма нивелируется за счёт разработанной ими системы SLAM Engine, которая автоматизирует предварительные измерения. Технологии, лежащие в основе данной разработки, не раскрываются.

Заявленная погрешность позиционирования составляет 2-4 метра, присутствует поддержка многоэтажности и программного определения преград. Стоимость внедрения навигационной инфраструктуры на 1000 кв.м. - 250$. Оффлайн-работа системы обеспечивается только инфраструктурой iBeacon-маяков, при оффлайн-работе точность позиционирования падает, так как у агента отсутствует доступ к базе данных измерений, использующейся для применения алгоритма Fingerprinting. Мобильные SDK разработаны для Android OS и iOS.

Обзор системы Indoor Atlas.

Система Indoor Atlas является финской разработкой в сфере indoor-навигации, начинавшейся как разработки для диссертации PhD студентов и преподавателей университета Оулу, Финляндия. Первая версия системы была представлена в 2012 году, бета-тестирование началось через год. В настоящее время, компания насчитывает более 40 сотрудников. Наиболее крупными клиентами фирмы являются Baidu, Yahoo Japan и Международный Аэропорт Мумбаи, Индия.

Платформа для навигации Indoor Atlas основана на синергии технологии геомагнитного позиционирования и sensor fusion. Для определения местоположения используется алгоритм Fingerprinting, результаты корректируются с использованием данных сенсоров агента различными уточняющими алгоритмами, такими как навигационное счисление. Предварительный сбор данных для алгоритма Fingerprinting производится с помощью мобильного приложения. Хотя геомагнитное позиционирование считается не самым точным методом, оно позволяет избавиться от затрат на аппаратную составляющую инфраструктуры навигации, такую как маяки или точки доступа.

Заявленная погрешность определения местоположения составляет 1-2 метра. Однако, подобная точность достижима только в зданиях металлической конструкции, в бетонных или блочных постройках погрешность позиционирования составит 2-4 метра.

Стоимость внедрения на 1000 кв.м. составляет 150$. Как уже было отмечено, низкая стоимость внедрения достигается отсутствием затрат на аппаратную инфраструктуру. Однако, её отсутствие делает невозможной работу системы без подключения к серверу. Также, система не может программно ограничить непроходимые объекты. В случае аномалии при измерениях, указатель местоположения может оказаться в стене или в витрине.

Мобильные SDK присутствуют на платформах iOS и Android OS.

Обзор системы Infsoft.

Компания Infsoft расположена в городе Гросмеринг, Германия. Компания была основана в 2006 году отцом и сыном, и к настоящему времени насчитывает в штате более 40 человек. Первая версия системы для локального позиционирования внутри зданий была представлена в 2007 году. Наиболее крупными постоянными клиентами компании являются Международный аэропорт Франкфурта, концерн Daimler и Vodafone.

Навигационная платформа Infsoft основана на технологии iBeacon, также для навигации используется Wi-Fi. От других подобных систем она выгодно отличается наличием множества дополнительных программных модулей, например, редактора карт. Для позиционирования используются геометрические алгоритмы трилатерации и триангуляции. Предварительные измерения и сбор информации в базу данных не производятся.

Погрешноть позиционирования при использовании клиентского приложения Infsoft составляет 3-5 метров. Точность невысока, в сравнении с другими алгоритмами, однако она не падает, если приложение работает без подключения к серверу, так как все вычисления производятся на устройстве агента. Стоимость внедрения инфраструктуры на 1000 кв.м. сопоставима с аналогичными системами и составляет приблизительно 250$.

Так как система использует для навигации iBeacon маяки, то она поддерживает многоэтажность и возможность ограничить непроходимые преграды программно. Мобильные SDK предлагаются для платформ iOS и Android OS.

Обзор системы Meridian.

Фирма Meridian расположена в городе Портлэнд, штат Орегон, США и является дочерней фирмой компании Aruba, крупного производителя BLE-маяков, использующих свой, отличный от iBeacon, протокол функционирования.

Навигационные решения от Meridian основаны на взаимодействии с сетью различных устройств, произведенных Aruba, от BLE-маяков до WiFi-роутеров. Это приводит к большей стоимости при внедрении этих решений в инфраструктуру, в сравнении с продуктами, основанными на протоколе iBeacon. В среднем, стоимость внедрения подобной инфраструктуры на 1000 кв. м. составляет 300$.

Вычисление позиции производится на основе сети маяков, с помощью алгоритмов трилатерации и триангуляции. Для начального приближения используется алгоритм Weighted Centroid.

Архитектура мобильных SDK систем Meridian такова, что локальное позиционирование работает только при соединении с сервером. Однако, закрытая инфраструктура из маяков одного типа позволила улучшить погрешность позиционирования до 1-2 метров.

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

Поддерживаемые мобильные платформы: iOS и Android OS.

Обзор системы Navigine.

Компания Navigine является российским стартапом, прошедшим акселератор научного центра Сколково. Cозданная в 2011 году, компания разрабатывает платформу для создания точных геолокационных сервисов внутри помещений: навигации, маркетинга и аналитики перемещений. Наиболее крупными партнерами компании являются IBM, SAP, Сбербанк, Samsung.

Для обеспечения высокой точности позиционирования технология навигации использует как внешнюю инфраструктуру - iBeacon/Wi-Fi, так и внутренние датчики устройств агентов - акселерометры, гироскопы, барометр, компас, а также позволяет учитывать особенности карты помещений и модель движения человека. Для расчёта позиции используются алгоритмы триангуляции и латерации, для уточнения применяются методы навигационного счисления и sensor vision.

Погрешность позиционирования сравнима с другими аналогичными системами и составляет 1-3 метра. За счет гибкости предварительной настройки, система Navigine предоставляет широкие возможности для конфигурации инфраструктуры в помещении, такие как ограничение непроходимых преград, многоэтажность, создание строгих маршрутов для точки, позиционирование дополнительных объектов. Разработано удобное API для взаимодействия с серверами, а также имеются SDK для всех популярных мобильных платформ.

Стоимость размещения инфраструктуры в целевом помещении составляет 200$ на 1000 кв. м.

Система Navigine предоставляет обширные возможности для работы в offline, возможность отслеживать и автоматически восстанавливать соединение.

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

Обзор системы NAO Campus.

Компания Pole Star была создана в 2002 году выходцами из крупных корпораций Thales и Alcatel. Первое решение, реализующее indoor-навигации в современном понимании, платформу NAO Campus, компания выпустила в 2009 году. На данный момент, крупнейшим клиентом компании является аэропорт Шарль де' Голь.

Навигационная платформа NAO Campus основана на одновременном использовании GPS, Wi-Fi, Bluetooth Low Energy и сенсоров устройства агента, для того чтобы адаптироваться под как можно более разнообразную по условиям среду, в том числе в многоэтажных зданиях и помещениях со множеством преград. Для навигации используется геометрический подход в паре с различными улучшающими алгоритмами.

Платформа NEO Campus предоставляет SDK для Android OS и iOS. На всех платформах присутствует поддержка работы offline. Заявленная погрешность позиционирования составляет 2-3 метра.

Стоимость создания среды для навигации на площади в 1000 кв.м. оценивается в 250$.

Обзор системы Senion.

Компания SenionLab была основа в 2010 году 6-ю научными сотрудниками университета Линчёпинг в Швеции. Толчком к созданию системы локального позиционирования послужили проблемы с поиском коллег в большом по площади компусе университета. К настоящему моменту компания имеет офисы в Швеции и США, штат сотрудников насчитывает более 25 человек. Первая версия системы Senion вышла в 2013 году. Крупнейшим партнером компании является корпорация Cisco.

Senion является аббревиатурой от Sensor Fusion. Для позиционирования система использует данные сенсоров устройств агентов. Запатентованная компанией технология StepInside позволяет определять местоположение агента с погрешностью от 3 до 5 метров, даже в многоэтажных. Для определения местоположения используется алгоритм сравнения с образцом, необходимы предварительные измерения. При использовании дополнительно iBeacon - маяков, точность позиционирования можно увеличить до 1 - 5 метров. Также, использование маяков позволит ограничить программно непроходимые преграды. Стоимость внедрения составляет 250$ на 1000 кв. м. (c маяками BLE).

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

Итоги исследования систем indoor-навигации.

После рассмотрения каждой системы в отдельности, все данные были объединены в таблицу, для удобства сравнения (cм. таблицу 1.1):

Таблица 1.1. Сравнение систем indoor-навигации

	indoo.rs	Indoor Atlas	Infsoft	Meridian	Navigine	NAO Campus	Senion
Погрешность	2-4 м.	2-4 м.	3-5 м.	1-2 м.	1-3 м.	2-3 м.	1-5 м.
BLE-трекинг	есть	нет	есть	Aruba	есть	есть	опция
Платформы	iOS, Android	iOS, Android	iOS, Android	iOS, Android	iOS, Android	iOS, Android	iOS, Android
Стоимость на 1000 кв. м.	250$	150$	250$	300$	200$	250$	250$
Многоэтажность	есть	есть	есть	есть	есть	есть	есть
Ограничение преград	есть	нет	есть	есть	есть	есть	опция
Offline-режим	есть, низкая точность	нет	есть, точность не изм.	нет	есть, точность не изм.	есть, точность не изм.	есть, низкая точность

В таблице выше, выделенные ячейки обозначают явных лидеров по какому-либо признаку.

Обратившись к критериям, описанным в пункте 1.3, можно выделить системы, которые удовлетворяют всем данным критериям в базовой конфигурации: Infsoft, Navigine и NAO Campus. Среди этих систем, Navigine является явным лидером в соотношении цена внедрения/точность позиционирования.

Кроме того, при более близком сравнении данных трёх систем, можно отметить, что платформа Infsoft проигрывает, если учитывать алгоритмы позиционирования, использущиеся для определения местоположения клиента. Navigine и NAO Campus используют наиболее точные и наиболее эффективные алгоритмы.

Таким образом, исходя из результатов исследования, проведенного в данной главе, для проекта по разработке мобильного приложения для Оружейной палаты Кремля целесообразно использовать платформу Navigine.

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

2. Разработка проектного решения

2.1 Написание пользовательских историй

Перед разработкой технического задания для мобильного приложения Оружейной палаты, необходимо определить и задокументировать сценарии использования приложения. Проектирование сценариев использования приложения принято начинать с написания пользовательских историй (обычно называемых User Stories).

User Stories, в первую очередь являются планом действий по созданию, тестированию и продвижению проекта. Также, пользовательские истории предоставляют возможность еще раз оценить перспективы продукта. Автор утверждает, что в среде разработчиков мобильных и веб-приложений, User Stories с успехом заменяют функциональные спецификации. В поддержку этой идеи приводятся следующие доводы:

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

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

3. Пользовательские истории по факту содержат в себе сценарии для тестирования приложения.

Существует негласно принятый сообществом алгоритм написания пользовательских историй. Перед тем, как приступать к их написанию, необходимо чётко разделить все роли в приложении. Затем, для каждой роли следует прописать User Stories по следующему шаблону: «Как, <роль пользователя>, я <что-то хочу получить>, <с такой-то целью>».

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

В рамках данного раздела были разработаны пользовательские истории для этих двух ролей. Список пользовательских историй для посетителей музея:

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

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

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

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

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

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

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

Список User Stories для человека, интересующегося культурой, но не имеющего возможности побывать в музее:

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

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

3. Как потенциальный посетитель музея, я хочу читать новости о новых выставках или мероприятиях музея.

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

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

2.2 Моделирование сценариев использования

Построение диаграммы прецедентов.

Термин сценарий использования, или use-case, относится к методологии моделирования UML - Unified Modelling Language. Для наглядного представления всех сценариев использования в систематизированном виде удобно пользоваться диаграммой прецедентов UML (см. рисунок 2.1):



Рисунок 2.1. Диаграмма прецедентов приложения Оружейной палаты

Данный набор сценариев использования покрывает весь требуемый функционал приложения. Описанные в User Stories потребности пользователей полностью удовлетворены прецедентами.

Сценарий «Использование приложения».

Для моделирования последовательности действий пользователя в каждом сценарии, используем диаграммы последовательности UML. Они удобны, так как на них наглядна видна вложенность экранов для каждой функции мобильного приложения. Моделирование будет производиться с помощью программного пакета StarUML, так как этот продукт является единственным удобным редактором UML-моделей для MacOS, позволяющим контролировать семантику моделей. Для начала, следует описать базовую последовательность действий пользователя по работе с приложением (см. рисунок 2.2). После запуска приложения в первый раз, пользователь должен видеть экран выбора языка. Данный экран необходим, так как приложение рассчитано на посетителей музейного комплекса Кремля, в числе которых множество иностранных туристов. После осуществления выбора, пользователь попадает в Главное меню, из которого ему доступны все основные функции приложения: «Настройки», «Новости», «Гид», «Коллекция», «Игры» и «Скачать контент». После использования какой-либо функции, пользователь возвращается в главное меню (см. рисунок 2.2):



Рисунок 2.2. Диаграмма последовательности «Использование приложения»

Данная диаграмма моделирует использование приложения на самом высшем уровне. На следующем этапе детализируем сценарии использования конкретных функций приложения. Начнём с детализации использования функции просмотра новостей музея.

Сценарий «Просмотр новостей».

В заявленном функционале приложения доступна лента просмотра новостей. При выборе пункта меню «Новости» в главном меню, пользователь должен попадать на экран просмотра новостей. Новости должны быть упорядочены по убыванию даты публикации. Каждая новость может быть прочитана подробно на новом экране (при нажатии на неё, см. рисунок 2.3):



Рисунок 2.3. Диаграмма последовательности сценария «Просмотр новостей»

Далее, рассмотрим сценарий использования функции «Гид».

Сценарий «Ознакомиться с экспозицией».

Функции гида доступны при нажатии по соответствующему пункту главного меню. На экране «Гид» пользователю должны быть доступны две основные опции: тематические экскурсии и обзорная экскурсия. Тематическая экскурсия представляет собой эквивалент экскурсии с живым гидом. Приложение ведёт пользователя по экспонатам маршрута, проигрывая для него аудио каждого экспоната. Все элементы текущей экскурсии должны быть отображены на экране карты в виде пинов. Также, пользователю должен быть доступен плейлист, через который можно переключать треки, и элементы управления аудиоплеером. Экран карты должен быть интерактивным, на нём должна работать функция локального позиционирования. Если пользователь не находится в музее, вместо функции автопозиционирования должен быть доступен ручной режим.

Обзорная экскурсия представляет собой свободный режим для неограниченных прогулок по музею. Должен открываться тот же самый экран карты, однако набор элементов управления другой. В свободном режиме, подсвечиваются пинами только ближайшие к текущему положению пользователя витрины и залы. При нажатии на витрину в свободном режиме, пользователь должен видеть плашку с краткой информации об этой витрине. На этом элементе интерфейса должны располагаться кнопки «Аудио» и «Подробнее». При нажатии на Подробнее, пользователь должен видеть подробное описание витрины. Кнопка «Аудио» запускает краткое описание данной витрины. Также, при прохождении через зал, по которому есть отдельная тематическая экскурсия, пользователь должен иметь возможность запустить её через экран «Рекомендуемое».

На рисунках 2.4-2.6 представлены диаграммы последовательности описанных сценариев:

Рисунок 2.4. Диаграмма последовательности сценария «Ознакомиться с экспозицией»

На диаграмме выше представлен общий сценарий знакомства с экспозицией. Далее, он декомпозирован на обзорную и тематическую экскурсии (см. рисунки 2.5-2.6):

Рисунок 2.5. Диаграмма последовательности сценария «Обзорная экскурсия»

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

В тематической экскурсии, режим позиционирования также должен активно использоваться. При переходе от одной витрины к другой по маршруту, пользователь должен иметь возможность ориентироваться. Сценарий тематической экскурсии представлен на рисунке 2.6:

Рисунок 2.6. Диаграмма последовательности сценария «Тематическая экскурсия»

В следующем разделе будет описан сценарий «Получить информацию о музее».

Сценарий «Получить информацию о музее».

Экран «О музее» должен предоставлять пользователю всю актуальную информацию о музее, включая номера телефонов, ссылки на Интернет-ресурсы, социальные сети, местоположение на карте. Все ссылки и номера телефонов должны быть интерактивными и при нажатии на них открывать соответствующий контент. Экран «О музее» должен быть доступен при нажатии соответствующий пункт главного меню. Подробный сценарий представлен на рисунке 2.7:



Рисунок 2.7. Диаграмма последовательности сценария «Просмотр информации о музее»

Далее будет рассмотрен сценарий просмотра коллекции.

Сценарий «Просмотр коллекции».

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

Для открытия коллекции, пользователь выбирает соответствующий пункт главного меню. Подробный сценарий представлен на рисунке 2.8:



Рисунок 2.8. Диаграмма последовательности сценария «Просмотр коллекции»

Как видно из рисунка 2.8, на каждом экране коллекции пользователю доступны функции запуска аудио о просматриваемом объекте, а также переход на экран «Подробно» о данном объекте.

Сценарий «Определение местоположения».

Следует также описать последовательность определения положения при работе пользователя с экраном карты (см. рисунок 2.9):



Рисунок 2.9. Диаграмма последовательности сценария «Определение местоположения»

Сценарий «Поиграть в игру».

В приложении задуманы 3 вида игр: квесты, «Пары» и викторины. Для начала, следует описать общий сценарий выбора и запуска игры (см. рис. 2.10):



Рисунок 2.10. Диаграмма последовательности сценария «Поиграть в игру»

Сценарий «Пары».

Игра «Пары» представляет собой классическую игру для тренировки памяти. Пользователю на короткое время показываются 6 пар картинок, после переворота которых, он должен открыть их парами поочерёдно. Диаграмма последовательности представлена на рисунке 2.11:

Рисунок 2.11. Диаграмма последовательности «Игра в пары»

Сценарий «Викторины».

Викторины представляют собой обычные вопросники на тематику музейной экспозиции. После ответа на каждый вопрос пользователю раскрываются различные исторические факты. Диаграмма последовательности представлена на рис. 2.12:

Рисунок 2.12. Диаграмма последовательности сценария «Викторина»

Сценарий «Квест».

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



Рисунок 2.13. Диаграмма последовательности сценария «Квест»

Сценарий «Скачать контент».

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



Рисунок 2.14. Диаграмма последовательности сценария «Скачивание контента»

2.3 Разработка объектной модели

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

Объектную модель для приложения Оружейной палаты целесообразно представить в виде диаграммы классов UML. Здесь следует отметить, что от музея были присланы инструкции, какие данные и в каком формате готовы предоставить специалисты музея. На основе этих инструкций, а также обсуждения внутри команды проекта, была создана объектная модель приложения. Диаграмма разделена на две части.

...