Ни о чём →
ГЛОНАСС
В последнее время популярность чипов ГЛОНАСС/GPS выросла и на этой волне многие компании их внедряют в мыслимые и не мыслимые места в нашей жизни. Например, в телефоны, в автомобили, в амбарные замки и т.д. Чипы стали источником информации, которая создала новый бизнес, новый рынок «телематической информации». Это обусловило появления компаний, которые стали предоставлять различные услуги в сфере ГЛОНАСС/GPS мониторинга и безопасности. В одной из таких компаний мне удалось поработать. И возвращаясь к теме мой публикации, так как уже давно пора, я расскажу о проекте, в котором был единственным исполнителем и разработчиком.
Компания, в которой я работал, занимается спутниковой автосигнализацией и мониторингом автотранспорта. По сути это одно и то же, разница лишь в настройках работы ГЛОНАСС/GPS устройства установленного на борту автомобиля. В одном случае координаты устройство отдает по требованию человека по команде средствам GSM сетей (SMS, GPRS), а в другом случае блок отдает данные самостоятельно раз в минуту при включённом зажигании. Режимы работы устройств легким движением руки можно было удаленно менять. Это влияло только на увеличение или уменьшения GPRS трафика.
Для облегчения восприятия я постарался, нарисовал информативную картинку.
Устройство с ГЛОНАСС/GPS размещенное в автомобиле генерирует телематическую информацию о своем состояние относительно земли (географические координаты, скорость, направления движения и т.д.) и передаёт на сервер. К этим данным может быть добавлена информация о состоянии систем автомобиля, а если блок «охранный», то состояния вх/вых самого устройства (блока). Попав на сервер информация, разбирается и записывается в базу данных. После чего с данными начинает работать различный софт. Если сообщение тревожное оно попадает в Call-центр, где оператор на него реагирует и отрабатывает. Если сообщение логистическое (треки движения автомобилей в реальном времени), то оно отображается в веб-интерфейсе, в личном кабинете клиента. Вот такие логистическая информация и интересна компаниям, которые предоставляют сервис «Пробки». Для передачи телематических данных в такие компания как «ПРОГОРОД» и «NAVTEQ» я и писал свой сервис.
Сервис я реализовал на языке C# .NET в виде Windows Service. По сути, сервис имел структуру, состоящую из двух клиентов. Один работал с БД, другой клиент передавал информацию на сервера стронных компаний. Сервис должен был транслировать свежие (актуальные) данные с периодом раз в 10 секунд, причем информация от ГЛОНАСС/GPS не должна была быть старше 5 минут. Такая частота работы сервиса была тяжеловата для БД, так как БД была частью системы реального времени с большой частотой записи, что приводило к большим нагрузкам на сервера БД под управлением СУБД MS SQL. Любой «тяжелый» запрос вешал БД. Выручило то, что были проиндексированы некоторые поля таблиц, клиент по выборке работал несколько наносекунд. Слава архитектору БД!!! После чего на авансцену выходил клиент ретрансляции следующих данных: id устройства, широта, долгота, скорость, направление движения, время генерации данных.
У компании NAVTEQ для приема телематических данных был веб-сервис. Чтобы подключить, нужно было пройти аутентификацию, после чего сервер генерировал ticket, который необходимо было прикладывать к передаваемым данным.
Для передачи данных в ПРОГОРОД достаточно было знать специальный протокол, адрес, порт и иметь выданный на бумаге id компании в их системе, который необходимо было добавлять к каждой передаваемой точке.
Что происходит с данными после передачи мне не известно. Скорее всего, они математически анализировались и обрабатывались, после чего визуализировались на картах веб сервиса.
Сравнивать сервисы «Пробки» основанные на веб-камерах и ГЛОНАСС/GPS девайсах я не возьмусь. Сделаю маленькое дополнение, что для качественного сервиса минимальное количество уникальных ГЛОНАСС/GPS устройств для Москвы должно быть не меньше 3000 штук.
Компания, в которой я работал, занимается спутниковой автосигнализацией и мониторингом автотранспорта. По сути это одно и то же, разница лишь в настройках работы ГЛОНАСС/GPS устройства установленного на борту автомобиля. В одном случае координаты устройство отдает по требованию человека по команде средствам GSM сетей (SMS, GPRS), а в другом случае блок отдает данные самостоятельно раз в минуту при включённом зажигании. Режимы работы устройств легким движением руки можно было удаленно менять. Это влияло только на увеличение или уменьшения GPRS трафика.
Для облегчения восприятия я постарался, нарисовал информативную картинку.
Устройство с ГЛОНАСС/GPS размещенное в автомобиле генерирует телематическую информацию о своем состояние относительно земли (географические координаты, скорость, направления движения и т.д.) и передаёт на сервер. К этим данным может быть добавлена информация о состоянии систем автомобиля, а если блок «охранный», то состояния вх/вых самого устройства (блока). Попав на сервер информация, разбирается и записывается в базу данных. После чего с данными начинает работать различный софт. Если сообщение тревожное оно попадает в Call-центр, где оператор на него реагирует и отрабатывает. Если сообщение логистическое (треки движения автомобилей в реальном времени), то оно отображается в веб-интерфейсе, в личном кабинете клиента. Вот такие логистическая информация и интересна компаниям, которые предоставляют сервис «Пробки». Для передачи телематических данных в такие компания как «ПРОГОРОД» и «NAVTEQ» я и писал свой сервис.
Сервис я реализовал на языке C# .NET в виде Windows Service. По сути, сервис имел структуру, состоящую из двух клиентов. Один работал с БД, другой клиент передавал информацию на сервера стронных компаний. Сервис должен был транслировать свежие (актуальные) данные с периодом раз в 10 секунд, причем информация от ГЛОНАСС/GPS не должна была быть старше 5 минут. Такая частота работы сервиса была тяжеловата для БД, так как БД была частью системы реального времени с большой частотой записи, что приводило к большим нагрузкам на сервера БД под управлением СУБД MS SQL. Любой «тяжелый» запрос вешал БД. Выручило то, что были проиндексированы некоторые поля таблиц, клиент по выборке работал несколько наносекунд. Слава архитектору БД!!! После чего на авансцену выходил клиент ретрансляции следующих данных: id устройства, широта, долгота, скорость, направление движения, время генерации данных.
У компании NAVTEQ для приема телематических данных был веб-сервис. Чтобы подключить, нужно было пройти аутентификацию, после чего сервер генерировал ticket, который необходимо было прикладывать к передаваемым данным.
Для передачи данных в ПРОГОРОД достаточно было знать специальный протокол, адрес, порт и иметь выданный на бумаге id компании в их системе, который необходимо было добавлять к каждой передаваемой точке.
Что происходит с данными после передачи мне не известно. Скорее всего, они математически анализировались и обрабатывались, после чего визуализировались на картах веб сервиса.
Сравнивать сервисы «Пробки» основанные на веб-камерах и ГЛОНАСС/GPS девайсах я не возьмусь. Сделаю маленькое дополнение, что для качественного сервиса минимальное количество уникальных ГЛОНАСС/GPS устройств для Москвы должно быть не меньше 3000 штук.
30.01.2012 01:31+0400