Тел./факс (495) 782-44-33
E-mail: forrman@forrman.ru
Адрес: Москва,
ул. Народного ополчения,
дом 16, корпус 2.



Контактное лицо
iemtsov@forrman.ru




О некоторых аспектах построения сложных информационно-управляющих систем в среде GSM/GPRS Версия в формате PDF Версия для печати Отправить на e-mail
Написал Forrman   
18. 06. 2009

О некоторых аспектах построения сложных информационно-управляющих систем в среде GSM/GPRS на примере Московского региона

Директор по инновациям
Беловолов С.В.

Под "сложной" в настоящей статье подразумеваются системы, обладающие, в том числе, следующими ТРЕМЯ характеристиками (аспектами):

1.Большое количество удаленных контролируемых устройств (или - абонентов). Число точно не определено, но подразумевается, что оно измеряется тысячами.

2.Распределенность абонентов на большой территории. Отсюда - измеряемое как минимум десятками количество базовых станций.

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

К подобным системам можно отнести например:

  • задачи ГИС и управления мобильными объектами;
  • охранные системы (в том числе с предоставлением выделенного web-сервиса - например для владельцев квартир, дач, машин и прочее);
  • системы индивидуального назначения (например экстренный вызов медицинской помощи).

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

А. Принципы построения и структура

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

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

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

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

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

Роутер
  • контролирует состояние абонентских устройств в реальном времени;
  • контролирует состояние опорной сети (передающей среды) и ее резервирование;
  • обеспечивает отправку/получение пакетов к/от абонентов;
  • управление очередями и буферизация;
  • обмен данными с управляющим и функциональным серверами;
  • запись и хранение логов;
Функциональный сервер
  • производит обработку данных, получаемых от роутера согласно алгоритмов системы;
  • производит через роутер выдачу команд абонентским устройствам;
  • распределяет потоки данных согласно задач системы;
Управляющий сервер(ы)
  • обеспечивают рабочее место оператора (-ов), управляющих системой;
  • выполняют иные (например аналитические) задачи.
Таб.1

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

Наиболее критично состояние системы к сбоям роутера. Поэтому разрабатываемое для него ПО выполняет например требования по работе без перезагрузки в течении нескольких месяцев.

Еще одна интересная проблема - устойчивость роутера/функционального сервера к отказам типа Denial of Service - DoS. В результате этого стресс-теста было установлено, что отказоустойчивость системы более чем достаточна - количество пакетов в секунду, при котором начинаются появляться признаки DoS, в 1000 раз превышает максимально необходимое для полноценного функционирования системы.

В. Опорная сеть (среда)

Таковой может служить собственная сеть Заказчика, либо использоваться уже существующая -"чужая". Примером последней является среда GSM/GPRS.

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

Силами специалистов нашей компании такие исследования были проведены в начале 2009 года в Москве и Московской области. Предоставим слово им самим:

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

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

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

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

Начали пробовать: для испытаний была изготовлена макетная плата возможностью установки двух наиболее дешевых модулей X и Y (опубликование конкретных моделей не является целью данной статьи. За более подробной информацией пожалуйста обращайтесь к авторам). Были испытаны и другие модули, но они дали совершенно отрицательный результат.

Оказалось, что каждый из модулей имеет массу индивидуальных особенностей. Создание единого алгоритма обмена по стандартному протоколу TCP для разных модулей - невозможно. Т.е. вместить в драйвер модуля все нюансы разных модулей нам оказалось не под силу. Я думаю, что даже в разных версиях прошивки будут разные алгоритмы поведения в ошибочных ситуациях и нам придется дорабатывать программу. На самом деле, конечно универсальное решение существует, оно заключается в том ,что если диагностировать специфическую ситуацию (или ошибку модуля) не удается, то для восстановления связи мы делаем полный рестарт системы. Это занимает от 25 до 300 секунд. Вот и получается обычная задержка в 5 минут на доставку сообщений.

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

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

При этом, если при попытке установить соединение модуль или GPRS канал оказывался нефункционирующим, то время на перезапуск модуля, переустановления соединения, также прибавлялось к времени обмена.

Далее мы приводим результаты без указания конкретных операторов. За подробностями просьба обращаться к авторам.

Эксперименты показали, что лучшие результаты в Москве дает оператор А с модулем Y. Далее идет оператор В и замыкает оператор С. При работе с оператором А в течение 2-х недель тестирования модуля в автомобиле канал связи не был потерян более чем на 64 сек. При работе с сим-картами оператора С, были несколько ситуаций, когда в определенном районе Москвы связи не было по несколько часов. По истечению большого периода времени, или в результате переезда в другой район связь восстанавливалась автоматически.

Сравнение двух модулей показало, что на одном операторе, скорость обмена сообщениями для модуля Y оказалась в 1.8 раза больше, чем для модуля X. Время восстановления после потери связи на Y составляло около 25 сек, на X - от 40 до 90 секунд.

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

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

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

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

< Пред.   След. >








О компании | Новости | Статьи | Документарий | Контакты