Особенности проектирования мобильной клиент-серверной системы для калибровки математических моделей трафика Текст научной статьи по специальности «Компьютерные и информационные науки»

ОСОБЕННОСТИ ПРОЕКТИРОВАНИЯ МОБИЛЬНОЙ КЛИЕНТ-СЕРВЕРНОЙ СИСТЕМЫ ДЛЯ КАЛИБРОВКИ

«и»

МАТЕМАТИЧЕСКИХ МОДЕЛЕЙ ТРАФИКА

Волков Михаил Михайлович,

ассистент кафедры математической кибернетики и информационных технологий, МТУСИ, Москва, Россия, mmvolkov@gmail.com

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

В настоящее время развитие современных мобильных устройств и технологий хранения и представления данных позволяет построить систему мониторинга движущихся объектов. Такая система может получать данные для настройки и проверки математических моделей движения связанной цепочки объектов. Рассматриваются аппаратные, программные и алгоритмические аспекты создания такой системы, даны требования к работе системы для получения корректных данных, пригодных для математического моделирования. Определены и классифицированы основные причины отказов. Для создания отказоустойчивой системы реализована избыточность серверного аппаратного обеспечения, настроить кластеризацию сервера приложений и репликацию базы данных. Рассмотрены наиболее распространённые и актуальные программные платформы для создания серверных приложений описаны их достоинства и недостатки и обоснован выбор платформы на которой реализована система. В качестве примера математической модели транспортного потока описана выбранная модель следования за лидером. Реализация клиент-серверной системы работает внутри облачной инфраструктуры Openshift, которая решает проблему надежности аппаратной части сервера. Программная основа написана в виде сервиса на языке PHP. Обмен данными с мобильными устройствами реализован в соответствии с методологией REST c использованием формата JSON. Применение разработанной системы - управление и мониторинг потоков автомобилей на основе теоритических моделей теории транспортных потоков. Описаны реализованные алгоритмы обработки данных, применяемы при калибровке модели следования за лидером: синхронизация местоположения нескольких объектов по времени, построение траекторий нескольких движущихся объектов по времени, сглаживание траекторий движения для нескольких объектов, вычисление расстояния между объектами в один момент времени по сглаженным траекториям. В ходе испытания системы был проведен ряд экспериментов, результаты части из них приведены в конце настоящей статьи.

Для цитирования:

Волков М.М. Особенности проектирования мобильной клиент-серверной системы для калибровки математических моделей трафика // T-Comm: Телекоммуникации и транспорт. - 2016. - Том 10. - №3. - С. 30-38.

For citation:

Volkov ММ. Design features of the mobile client-server system for the calibration of mathematical traffic models. T-Comm. 2016. Vol. 10. No.3, рр. 30-38. (in Russian)

Введение

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

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

В таких системах нужно обеспечить:

1, Связь каждого с каждым.

2. Создать математическую модель движения в виде зависимости расстояния между частицами от их скорости.

Существуют различные применения настоящей системы:

1. Сбор статистики для построение и апробации математических моделей поведения движущихся объектов (автомобилей, пешеходов, людей во время массовых мероприятий).

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

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

Система сбора информации для модели

следования за лидером SSSR — Traffic

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

I ■

■IliOjULL__M"!tfj-*Вв!-

[-s*—4 03 —-4-^-

0

Уладера

Объекты мониторинга

Рис. 1, Принципиальная схема клиент-серверной системы мониторинга SSSR - Traffic

Наша исследовательская ipynna под руководством проф. А.П. Буслаева разрабатывает клиент-серверные системы мониторинга с 2008 года [4].

Предшествующая реализация системы - SSSR-Road позволяла управлять процессом мониторинга дорожного движения и была описана в статье [5]. Отличии настоящей версии в том, что используются смартфоны нового поколения (iOS, Android вместе Windows Mobile 5).

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

Информация, которую разработанная программа записывает в память смартфоны и передают на сервер:

1. Геоданные со встроенного GPS/ГЛОНАСС приемника:

a. координатор широта, долгота);

b. скорость;

c. высота над уровнем моря;

d. оценка точности GPS данных;

e. количество спутников использованных при фиксации местоположения;

f. полные исходные NMKA данные с GNSS спутников, для интерпретации на сервере.

2. Точные геоданные с дифференциального GNSS приемника, Например JAVAD (получаемые по протоколам Bluetooth или WiFi).

3. Вспомогательная информация со встроенных датчиков смартфона:

a. данные с компаса;

b. акселерометра;

c. температуру;

d. освещенность.

4. Данные полученные с внешних датчиков, подключенных к смартфону:

a. Температура (датчики 18В20, DHTll.SHTI, LM35);

b. Ускорение (датчики MEMSIC2125, ADXL345, ММА7341);

c. данные о состоянии подсистем автомобиля полученные через протокол ODB2 {например точная скорость полученная от спидометра автомобиля, угол открытия дроссельной заслонки, обороты двигателя, включенная передача и т.д) - адаптер ELM327 WiFi;

d. данные о состоянии водителя транспортного средства например пульс.

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

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

При использовании интерактивного мониторинга, на web-сервер передается следующая информация с телефона (рис. 2).

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

Пример POST запроса на сохранение данных: POST cr-duv.rhcloud.com/addpoint.php Content-Type", "multipart/fnrni-data; Content-Disposition: fonn-data; name- Latitude' 37,345743 Content-Disposition: form-data; name- Longitude': 55.374613 Content-Disposition: form-data; name- Speed': 36.383746 Content-Disposition: form-data; name='Time': 13787983271000 Content-Disposition: form-data; name='id': user2347

Аппаратная архитектура системы

Система состоит из сервера расположенного в облачной инфраструктуре и мобильных клиентов, В качестве мобильных устройств используются смартфоны работающие на базе операционной системы Android. Данные о местоположении нередаюз ся системой ГЛОНАСООРЯ. Также для получения более точных данных к смартфонам возможно подключение внешних дифференциальных GPS приемников и других оконечный устройств (например лазерный или ультразвуковых дальномеров).

Облачная инфраструктура сбора и обработки данных

GPSirnOHAOC

а е а

Сенсорная подсистема

Сервер сбора Мобильные клиенты

и обработки данных

POST запрос на передачу данмы*

GETaaflpoc авторизации а системе

Signa IR

передача ком манд управления

Сенсорная подсистема Рис. 2. Аппаратная реализация системы

Серверная часть

Используются облачные сервера предоставляемые компанией Redliat в рамках проекта Openshift. Для подсистем сбора, управления и хранения данных используются отдельные картриджи - виртуальные машины облачного сервиса. Каждая виртуальная машина имеет 512 MB RAM, 100 MB swap, I GB disk space.

Клиентская часть

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

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

- Samsung Galaxy S4 Zoom;

-ASUS PadPhone;

-Sony XPERIAZ3 dual;

-Sony XPERIA Z1;

- HTC DESIRE;

и другие.

Сенсорная подсистема

Выл использован дифференциальный GNSS приемник JAVAD, что позволило повысить точность измерений и записать эталонные треки для коррекции данных.

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

Платформы для создания wcb-приложенин

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

В настоящий момент существует большое количество технологий на основе которой может быть разработано сер-

верное приложение. Наиболее распространенными являются: php, JavaEE, NodeJS, ASP .net, Python и Perl/CGI.

В работе [41 2010 г., для задачи записи информации о местоположении дефектов дорожного покрытия, описана реализация распределенной клиент серверной системы с пассивным сервером, принимающим данные по протоколу FTP.

Платформа Java Enterprise Edition, сокращенно Java ЕЕ -набор спецификаций и соответствующей документации для языка Java, описывающей архитектуру серверной платформы используется для реализации информационных систем на Средних и крупных предприятиях.

Преимуществами J ЕЕ являются надежность, масштабируемость и гибкость в высокопроизводительных проектах, однако является сложной в освоении, обновлении и поддержании проекта. Релиз платформы Java Enterprise Edition состоялся в 1999 г. Платформа Java, как основа web сервисов получила активное развитие и популярность после выпуска сервера Glassfish в 2005 году.

Программные реализации web-cepBepa, на базе технологии JavaEE - Oracle Glassfish и apache Tomcat.

Современная набирающая, активно набирающая популярность технология — Node или Node.js - программная платформа, основанная на движке V8 (транслирующем JavaScript в машинный код), превращающая JavaScript из узкоспециализированного языка в язык общего назначения. Node.js добавляет возможность JavaScript взаимодействовать с устройствами ввода-вывода через свой API (написанный на С++), подключать другие внешние библиотеки, написанные на разных языках, обеспечивая вызовы к ним из JavaScript-кода. В основе Node.js лежит событийно-ориентированное и асинхронное (или реактивное) программирование с неблокирующим вводом/выводом.

При разработке серверных wéb-приложений обычно используют Node.js фреймворки (например Express),

Другая технология создания web-приложений и web-сервисов ASP.NET(Active Server Pages)—от компании Майкрософт. Она является составной частью платформы Microsoft .NET и развитием технологии Microsoft ASP. На данный момент последней версией этой технологии является ASP.NET 5. При разработке серверных web приложений на языке ASP применяют паттерн M VC. Разработка ведется на языке С#, благодаря чему можно пользоваться всеми преимуществами технологий Microsoft (например использовать Linq).

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

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

Тем не менее ввиду наличия хостинга для тестирования и удобства изменения функционала в системе используется сервер написанный на языка php.

Основные функции №еЬ-сервера:

КЕ8Т АР1 мобильных клиентов о Авторизация мобильных клиентов о Прием серий данных измерений о Синхронизация мобильных клиентов во время измерений

о Передача команд операторам мобильных клиентов Интерфейс просмотра результатов Отображение результатов эксперимента с геопри-

о

вязкой

о о о о

Построение графиков перемещений объектов Вывод параметров математических моделей Интерфейс для управления данными экспериментов Регистрация мобильных клиентов

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

• имеет распределенный доступ к данным, расположенных на нескольких серверах

• возможно параллельное извлечение данных Map Reduce

• более быстрое извлечение простых структур данных

• может хранить неструктурную информацию

• поддержка геопространственных индексов. Это позволяет сохранять х- и у-координаты у документов и затем находить документы вблизи (Snear) определённых координат, или внутри (Swithin) прямоугольника либо окружности.

Point Track

Jd: Objectf D latitude: float longitude: float height: float time: String accuracy: float speed: float ■ ----* name: String Owner; String description: Stnng device: String points; Ust<Polnt>

coordinator

Jd: objectiD coordLogin: String members LM<5trlng:>

Person

_kf: Object! [} login: string password: String surname: String

name: String patronymic: String description: string groupNum: Integer

Event

Jdi Objectiq üwrren strwig latitude ; float longitude: lloat text: Stnng time: string

tastposition

_ld: ObjsHID login: String latitude: float longitude: float

Message

_ki: ObjectlP irdogin: Siring ÎSltogïP Strtng

text: String time: String

Instruction

srdogm: string ditkyjlri: String latitude: float longitude: float text: string

Обозначении:

Встраивание в документ. Условная связь.

Рис. 3. Модель документно-ориентнрованной базы данных системы ЗйЗЯ-ТгаГПс

Для физической реализации базы данных выбрана СУБД MongoDB. Хотя MongoDB позволяет храни сь в коллекциях документы различной структуры, условимся, что в каждой коллекции будут храниться документы одинаковой структуры. Для наиболее наглядного и полноценного описания

структуры объектов, хранящихся в данной СУБД, документы, хранящиеся в базе данных, будут описаны в формате описания объектов ^СЖ. При описании объектов, имя описываемого объекта будет совпадать с названием коллекции, а его структура, структуре документа, который в ней хранится.

Модели трафика

Рассмотрим цепочку автомобилей движущихся в одной полосе 1Гриидшильдс[2], Танака, Буслаев]. Пусть Х1(1), ... ,х„(1), х11+|(1) - координаты каждого автомобиля в момент времени 1, при этом впереди движущийся автомобиль имеет индекс п+]. Основная микромодель рассматриваемая в статье - модель следования за лидером.

где с« - средняя длина автомобиля; С[ - средняя время реакции водителя; с2- коэффициент, связанный со сцеплением с дорогой.

Рассматривается реализация для движения в одной полосе, так как для захвата данных о многополосном движении необходимы приемники ОР5 более высокой точности (например, дифференциальные). Дчя определения в какой именно полосе движется автомобиль точности встроенного в смартфоны приемника (4-8 метров) недостаточно, так как ширина полосы в городе составляет 2.2 метра [3].

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

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

Исследование систем дифференциальных уравнений ранее рассматривалась в работе [5].

Калибровка модели движения цепочки частиц

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

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

Правая часть уравнения (1) представляет собой, (классическая модель) — это квадратичная зависимость с/ = /(у) — щ + а/V + й?/, где параметры а а, а¡, аз имеют определённую физическую интерпретацию.

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

Виды и причины отказов

В клиент серверных системах возможны сбои по следующим причинам:

1. Отказ оборудования сервера;

2. Отказ клиентского оборудования;

3. Сбой канала связи;

4. Сбой программного обеспечения.

Рассматриваются способы защиты от сбоев оборудования сервера и канала связи сервера с сетью Интернет и вопросы обеспечения надежности клиент-серверной системы с обратной связью для передачи текстовых данных с GPS инкапсуляцией, предающей координаты с мобильных устройств, находящихся на движущихся со скоростями до 100 км/ч объектах. Для корректной маршрутизации объектов необходимо, чтобы ответ от сервера был получен за время At. При этом клиент перемещается на расстояние As = At *Av, что может привезти к потери связи с базовой станцией.

Требуется создать систему сбора реальных данных дчя калибровки моделей. Для простоты в статье рассматривается модель следования за лидером [2] без учета многополосности.

Определения сбоя и отказа в соответствии с ГОСТ [9].

Ресурсный отказ (Marginal failure) - отказ, в результате которого объект достигает предельного состояния.

Независимый отказ (Primary failure) — отказ, не обусловленный другими отказами.

Зависимый отказ (Secondary failure) — отказ, обусловленный другими отказами.

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

Постепенный отказ (Gradual failure) - отказ, возникающий в результате постепенного изменения значений одного или нескольких параметров объекта.

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

Перемежающийся отказ (Intermittent failure) — многократно возникающий самоустраняющийся отказ одного и того же характера.

Явный отказ (Explicit failure) — отказ, обнаруживаемый визуально ила штатными методами и средствами контроля и диагностирования при подготовке объекта к применению или в процессе его применения но назначению.

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

Конструктивный отказ (Design failure) - отказ, возникший по причине, связанной с несовершенством или нарушением установленных правил и (или) норм проектирования и конструирования.

Производственный отказ (Manufacturing failure) - отказ, возникший по причине, связанной с несовершенством или нарушением установленного процесса изготовления или ремонта, выполняемого на ремонтном предприятии.

Эксплуатационный отказ (Misuse failure, mishandling failure) - отказ, возникший по причине, связанной с нарушением установленных правил и (или) условий эксплуатации.

Деградационный отказ (Wear-out failure, ageing failure) - отказ, обусловленный естественными процессами старения, изнашивания, коррозии и усталости при соблюдении всех установленных правил и (или) норм проектирования, изготовления в эксплуатации.

Методы увеличения отказоустойчивости

серверных приложений

В системе SSSR-Traffic обеспечение отказоустойчивости организованно за счет дублирования ключевых узлов серверной части.

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

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

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

Не все приложения подходят для работы в кластере. Необходимо, чтобы приложение соответствовало некоторым требованиям:

Простой запуск, принудительная и обычная остановка, возможность проверки состояния приложения;

• Наличие интерфейса командной строки или специальных инструкций для управления;

• Поддержка нескольких экземпляров приложения;

• Возможность использования общего хранилище данных - NAS или SAN;

• Приложение должно располагаться на энергонезависимом хранилище;

Возможность перезапуска приложения в последнем состоянии до ошибки на другом узле (для сохранения состояния используется общее хранилище);

• Приложение не должно повреждать данные при возникновении ошибки;

К методам, которые используется на кластере для обеспечения надежности, относятся:

Зеркалирование дисков, например DRBD; Резервные сетевые соединения; Резервные сети хранения данных (SAN) соединения; Избыточные электрические энергозатраты на разных каналах связи, защищенные источниками бесперебойного питания и вторичным источником.

Алгоритмы обработки данных

В системе обрабатывается информация получаемая с GPS/ГЛОНАСС приёмника смартфона. Стандартная реализация провайдера местоположения в операционной системе Android выдает географические координаты при изменении местоположения устройства, но не чаще чем раз в секунду, если сила сигнала от спутников достаточна. Соответственно при плохом сигнале координаты могут заноситься в базу данных реже чем раз в секунду, и необходимо синхронизировать данные для нескольких объектов. Все геоданные, приходящие от GPS/ГЛОНАСС, сопровождаются метками времени (время UNIX - количество миллисекунд прошедших с 1 января 1976 г.).

Таблица 1

Пример несинхронизированных данных

Номер измерения Метка времени 1 Метка времени 2

1 1446024291000 1446024291000

2 1446024291000 1446024302000

3 1446024305000 1446024302000

4 1446024305000 1446024307000

5 1446024317000 1446024307000

6 1446024317000 1446024320000

7 1446024324000 1446024320000

8 1446024324000 1446024329000

9 1446024333000 1446024329000

10 1446024333000 1446024336000

11 1446024342000 1446024336000

12 1446024342000 1446024347000

13 1446024348000 1446024347000

14 1446024348000 1446024356000

15 1446024358000 1446024356000

16 1446024358000 1446024366000

17 1446024367000 1446024366000

18 1446024367000 1446024376000

19 1446024377000 1446024376000

20 1446024377000 1446024385000

21 1446024384000 1446024385000

22 1446024396000 1446024385000

23 1446024396000 1446024395000

24 1446024396000 1446024405000

25 1446024403000 1446024405000

26 1446024410000 1446024405000

27 1446024410000 1446024409000

28 1446024410000 1446024413000

29 1446024418000 1446024413000

30 1446024418000 1446024423000

31 1446024428000 1446024423000

32 1446024428000 1446024433000

33 1446024436000 1446024433000

34 1446024436000 1446024441000

35 1446024445000 1446024441000

36 1446024445000 1446024449000

Синхронизация местоположения нескольких объектов по времени

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

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

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

Построение траекторий нескольких

движущихся объектов по времени

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

= 3„_± +</(х„_1 -Х*)2 + (Уп-1-Уи)2

После этого строится зависимость ^-^от 8п рис. 7

Сглаживание траекторий движения

для нескольких объектов

Проведенные эксперименты

с использованием

Был проведен ряд экспериментов разработанной системы.

Эксперимент 09.12.15 - проверка точности приемника GPS телефона Samsung Galaxy S4 zoom (Чипсет GPS Exynos 4 Dual) и Sony XPERiA zl (GNSS чип Qualcomm), проводился во дворе МТУСИ (ул. Народного Ополчения 27), два человека двигались пешком на расстоянии пяти метров.

а)

Для сглаживания траектории движения при наличии неравномерно распределенных координат используется вычисление дополнительных точек. Если в момент времени t] известны координаты для первого объекта, а для второго объекта координаты в момент времени to и tj, для второго объекта можно вычислить приращение расстояния по разнице времени trtc и ta—-

1.4 Коррекция данных по эталонным координатам.

Для повышения точности позиционирования в пространстве возможно использовать алгоритм притягивания координат к эталонному треку, либо ребрам улично-дорожной сети. Эталонный трек можно записать при помощи точного приемника GPS, например JAVAD TRIUMPH - это многофункциональный приемник с возможностью RTK до 100 Гц, оснащенный 216 каналами двух частота ого GPS и ГЛОНАСС, Точность съемки (автономная точность) которого составляет 2 метра.

- Эталонный трек аЗ

а2

а1 аО

а1с

Рис. 4. Сглаживание трека: аО-аЗ —точки трека

Для каждой точки трека проверяется принадлежит ли она эталонному треку. Если условие выполняется координаты точки заносятся в базу данных. Иначе вычисляются новые

координаты: ^с — аох+ созСагх} х а1к и

аус = °оУ + С05(агу) х а±у

i Л. т "J TV Л ^ jm 3|J Jt* ■

303 м

1-ШШ ж {* :ШКШ я ■■■ аЛЯш

Шо^Ш

1 йДИг дМ

Кс^Н

1 "А

: - ^ТМЯо' _ " Ре т_Г ^А^^^^ИВ Sp. ^r _ ^Д^РГ Е- м^^И

Jf ' ^^^^^^^^^^^ A JV f+'J/b л V Ifr V f^ У А

- Т» я/^Ж^

б)

Рис. 5. а) График расстояния между смартфонами; б) Карта эксперимента

Литература

1. Бугаев A.C.. Буслаев АЛ. Козлов В.В.. Яшина М.В. Некоторые математические и информационные системы моделирования трафика ИT-Comm: Телекоммуникации и транспорт, 201 ¡. №4. - С. 29-31.

2. Городничев М.Г. Информационные и математические модели следования за лидером, a bio реф. дне с. к.т.н. 05.13.17. - М., 2015. — 27 с.

3. Баоков В.Ф. Дорожные условия и безопасность дорожного движения. - М.: Изл-во Транспорт, 1982. - 271 с.

4. Отчет по проекту ГК№ 14.740.11.0397 от 20.09.2010. «Теоретические и прикладные вопросы создания систем интеллектуального мониторинга и управления распределенными процессами» (Руководитель проф. Буслаев А.П.) (ФЦП «Научные и научно-педагогические кадры инновационной России» на 2009-201 3 годы)

5. Абышов Р.Г.. Буслаев А.П.. Куприянов Ю.Д.. Яшина М.В. Распределенная система мониторинга содержания автомобильных дорог // Вестник МАДИ. Вып. 1 (24), 2011. - С. 79-85.

6. Alexander P. Buslaev, Andrew V. Provorov, Marina V. Yashina. Infocommunication Systems of Saturated Traffic Control in Megalopolises, The 2013 International Conference on Internet Computing and Big Data, July 22-25, 2013, Las Vegas, USA.

7. Bugaev A.S.. Buslaev A.P.. Kozlov V.V.. Yashina M.V. Distributed Problems of Monitoring and Modern Approaches to Traffic Modeling, p. 6, 14th International IEF.E Conference on Intelligent Transportation Systems (ITSC 2011), Washington, USA, 5-7.10.2011. DDI: 10.1109/ITSC.20116082895.(2011)477-481.

8. Buslaev A.P.. Gorodnichev M.G. Microwave Eye of "Big Brother": What is Visible from the Window of MADI. Ninth international Conference on Traffic and Granular Flow 2011. Book of abstracts. M.. 2011, 338-340 p.

9. Alexander P. Buslaev, Marina V. Yashina. Mikhail Volkov. Algorithmic and Software Aspects of Information System Implementation for Road Maintenance Management, Proceedings of the Tenth International Conference on Dependability and Complex Systems DepCoS-RELCOMEX, June 29 July 3 2015, Brunow, Poland, DO I 10.10079783-319-19216-17, pp 65-74.

10. ГОСТ 27,002-89 «Надежность в технике»

DESIGN FEATURES OF THE MOBILE CLIENT-SERVER SYSTEM FOR THE CALIBRATION

OF MATHEMATICAL TRAFFIC MODELS

Mikhail M. Volkov, MTUCI, Moscow, Russia, mmvolkov@gmail.com

Abstract

Currently, the development of modern mobile devices and technologies for the storage and presentation of data allows to develop the system of monitoring moving objects. Such a system may obtain information to configure and validate mathematical models of movement of a related series of objects. The article considers hardware, software, and algorithmic aspects of creating such a system, given the requirements to work the sys-tem to obtain valid data suitable for mathematical modeling. Defined and classified the main causes of failures. To create a failover system, you must implement redundancy of server hardware, configure the clustering of application server and database replication. The most common and relevant software platform for creating server applications de-scribes their advantages and disadvantages and the choice of platform on which to im-plement a system. As an example of a mathematical model of traffic flow describes the chosen model is following the leader. The current implementation of the system is being run inside cloud infrastructure Openshift, which solves the problem of reliability of the server hardware. Software framework written in PHP. Exchanging data with mobile de-vices is implemented in accordance with the methodology REST using json format. The article describes the implemented data processing algorithms used in calibration of the model follow the leader: synchronize location of multiple objects in time, the trajectories of several moving objects in time, the smoothing of the trajectories of multiple entities, the distance calculation between objects at one time by the smoothed trajectories. Dur-ing testing of the system was performed a series of experiments, the results of some of them is given at the end of this article.

Keywords: distributed information systems, client-server system, fault-tolerant system, mobile applications, traffic models. References

1. Bugaev A.S., Buslaev A.P., Kozlov V.V., Yashina M.V. Some mathematical and information systems of traffic modeling. T-Comm. No. 4, 2011. Pp. 29-31. (in Russian)

2. Gorodnichev M.G. Information and the mathematical model follow the leader. author. Diss. Ph. D. 05.13.17. Moscow. 2015. 27 p. (in Russian)

3. Babkov V.F. Road conditions and traffic safety. Moscow: Publishing house of Transport, 1982. 271 p. (in Russian)

4. Project report Ledger No. 14.740.11.0397 from 20.09.2010 "Theoretical and applied issues of creation of intellectual systems of monitoring and managing distributed processes" (Supervisor Professor A. P. Buslaev) (Federal program "scientific and Scientific-pedagogical personnel of innovative Russia" for 2009-2013). (in Russian)

5. Buslaev, A.P., Abyshov, R.G., Kupriyanov, U.D., Yashina, M.V. A distributed system for monitoring road maintenance. Vestnik MADI 24(1), 79-85 (2011). (in Russian)

6. Alexander P. Buslaev, Andrew V. Provorov, Marina V. Yashina. Infocommunication Systems of Saturated Traffic Control in Megalopolises, The 2013 International Conference on Internet Computing and Big Data, July 22-25, 2013, Las Vegas, USA.

7. Bugaev A.S., Buslaev A.P., Kozlov V.V., Yashina M.V. Distributed Problems of Monitoring and Modern Approaches to Traffic Modeling, p. 6, 14th International IEEE Conference on Intelligent Transportation Systems (ITSC 2011), Washington, USA, 5-7.10.2011. DOI: I0.II09/ITSC.20II6082805. (2011). pp. 477-481.

8. Buslaev A.P., Gorodnichev M.G. Microwave Eye of "Big Brother'': What is Visible from the Window of MADI. Ninth International Conference on Traffic and Granular Flow 20II. Book of abstracts. Moscow, Media Publisher, 20II, pp. 338-340.

9. Alexander P. Buslaev, Marina V. Yashina, Mikhail Volkov. Algorithmic and Software Aspects of Information System Implementation for Road Maintenance Management, Proceedings of the Tenth International Con- ference on Dependability and Complex Systems DepCoS-RELCOMEX, June 29 July 3 20I5, Brunow, Poland, DOI I0.I007978-3-3I9-I92I6-I7, pp 65-74.

10. GOST 27.002-89 russian national standard "Reliability in engineering". (in Russian)