Автомобильная спутниковая сигнализация на STM32F1

Теория создания самодельной автомобильной спутниковой сигнализации с web-интерфейсом и поддержкой eCall / ЭРА-ГЛОНАСС на базе микроконтроллеров STM32 как основа концепции «Умный автомобиль», и её использование в системах «Умный дом». Реализация аналога технологии Volvo On Call и автомобильной социальной сети Toyota Friends.

Решил наконец написать продолжение статьи «Спутниковый спидометр на STM32F1 и FreeRTOS».

Рассмотрим, как своими руками сделать автомобильную спутниковую сигнализацию с web-интерфейсом – основные идеи, элементная база, технические тонкости реализации. Отмечу сразу, что себестоимость выходит на уровне полутора тысяч рублей (в базовом исполнении), в то время как промышленные аналоги (вместе с установкой) выходят в районе 30-50 тысяч рублей. Абонентской платы нет – есть только расходы на сотовую связь (около 100р в месяц. При грамотном подходе к минимизации передаваемого трафика – в месяц будет уходить ~60руб, а то и меньше). Благодаря поддержке Глонасс появляется дополнительное преимущество в связи с ожидаемым 100% оснащением российского автопарка системами Глонасс. И в то же время описываемое устройство несёт в себе инновационные возможности, которых ещё нет на рынке.

Устройство, описанное ниже, является универсальным – с одинаковым успехом может быть установлено и работать как на Жигулях, так и на Lexus’е – как на мобильных объектах (легковые, грузовые автомобили), так и стационарных (дома, коттеджи и т.д.). Выполняет 3 основные функции:

* Информационная – аналог технологии Volvo On Call. Находясь на значительном удалении, вы остаётесь на связи со своей машиной, при наличии любого устройства, имеющего выход в Интернет (компьютер, нетбук, iPhone, iPad Android-устройство и т.д.) – найти местоположение своей машины, удалённо завести двигатель, получить сведения о техническом её состоянии, и т.д. Управление и мониторинг машины осуществляется через SMS / голосовые вызовы (dtmf) / сайт. Сайт является интернет-порталом, на который в автоматическом режиме объекты, оснащённые данным устройством, «сбрасывают» сведения о текущем своём состоянии и забирают с него настройки для своей работы. Также это – автомобильная социальная сеть (аналог Toyota Friends) для взаимодействия объектов (автомобилей, домов) и людей.
* Охранная – включает в себя:
а) метка с диалоговым кодом на 2.4Ггц на базе STM32W, для автоматического получения доступа к объекту.
б) защита от глушения gsm-сигнала (постоянный контроль канал связи сервером + обнаружение факта глушения со стороны самой сигнализации)
в) функция gsm/gps/глонасс-трекера – если машину угонят либо поместят на штрафстоянку, вы сможете узнать её текущее местонахождение.
г) скрытое видеонаблюдение – по rs485 с сигнализации подключаются видеокамеры, состоящие из STM32F4 и cmos-камеры на борту.
г) цифровые реле – даже физически удалив либо выведя из строя сигнализацию, злоумышленник ничего не добьётся – реле обесточат жизненно важные цепи, и их уже не активировать, даже напрямую подав питание на них. Также цифровые реле осуществляют управление штырями в дверях – даже если злоумышленник разобьёт стёкла и/или выломает личинки замков – ему не удастся открыть дверь, даже взломав её замок – двери открыть помешают электронные штыри в дверях, которые разблокируются только сигнализацией.
д) в качестве дополнительного оснащения используются 1 или несколько gsm/gps/глонасс-маячков, также самодельных. Т.к. по причинам, описанным ниже, применение одной только сигнализации недостаточно. Также рекомендуется применение замка капота, блокиратора руля (например, Гарант), бронировочной плёнки для стёкол (разбить стекло, чтобы украсть из салона ваши вещи либо проникнуть внутрь, будет крайне проблематично – защищает даже от пуль пневматического пистолета)
* Спасения – автомобиль, оборудованный данным устройством, сможет самостоятельно вызвать экстренные службы, даже если водитель и его пассажиры уже не в состоянии предпринять какие-либо действия. Для реализации этой возможности устройство имеет поддержку технологий eCall / ЭРА-Глонасс. Установка подобных устройств, по прогнозам, сможет ежегодно спасать 2500 жизней в год в Европе, 4000 жизней в год в России и на 14% снизить последствия травматизма при ДТП.
* Логистика – для компаний, осуществляющих грузоперевозки. Контроль и отслеживание перемещения транспорта, учёт расхода топлива по автопарку и т.д.

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

А теперь – как всё это самостоятельно реализовать, идеи в общих чертах. В конце рассмотрим реализацию на микроконтроллерах STM32.

1. Общая структура системы.

— как я уже писал ранее, устройство пригодно для применения не только в мобильных объектах (легковые машины, грузовики и т.д. – «Умный автомобиль»), но и в стационарных (квартиры, дома, коттеджи — «Умный дом»). Вообще, автомобильные спутниковые сигнализации, как показывает практика, оказываются хорошей заменой систем «Умный дом» для автоматизации и охраны квартир, коттеджей и прочих объектов недвижимости. Разумеется, они не могут конкурировать с такими системами «Умный дом», как LonWorks, Legrand и Bticino, но вполне могут решать задачи, которые для потребителя являются приоритетными при автоматизации своего жилища – охрана, удалённый мониторинг и управление, видеонаблюдение и прочее. Не всегда потребитель готов выкладывать за автоматизацию те деньги, которые стоят системы вроде LonWorks – ему требуется бюджетное решение, которым и может стать автомобильная спутниковая сигнализация. В качестве наглядного примера можно привести ресурс http://home-online.ru/solutions.html

В случае применения «Умный автомобиль» устройство размещается в металлическом корпусе, способном выдерживать нагрузки до 40G, в котором размещается сама сигнализация и резервный аккумулятор. Это – требование стандарта «ЭРА-Глонасс» — устройство в случае ДТП и последующего возможного пожара должно быть способно связаться с экстренными службами и передать координаты автомобиля, даже если водитель и его пассажиры уже не способны предпринять какие-либо действия со своей стороны. Кроме того, вместо сим-карты используется сим-чип (подробнее — в разделе «GSM-модуль SIM900» ниже).

В случае применения «Умный дом» устройство размещается в обычном компактном пластиковом корпусе с аккумулятором для размещения в скрытном для злоумышленника месте, при этом его силовая часть размещается в корпусе для монтажа в DIN-рейку электрического шкафа объекта недвижимости:

Рассмотрим теперь структуру самого устройства, в случае автомобильного применения:

Для съёма данных о состоянии автомобиля (обороты двигателя, датчики давления масла и жидкостей и т.д.) используется подключение к диагностическому разъёму автомобиля, используя CAN/LIN. В случае, если наше устройство не поддерживает данную марку автомобиля, используется подключение непосредственно к датчикам и исполнительным механизмам автомобиля – тахометру/генератору, форсункам, датчикам давления масла, уровня охлаждающей жидкости и т.д.

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

Настройка моей сигнализации выполняется через USB – использую в STM32 USB CDC класс, поэтому на стороне компьютера устройство видется как обычный ком-порт, и работать с ним можно через любую терминалку (я использую Putty).

Датчик объёма – используется стандартный внешний, а в качестве датчика наклона можно использовать акселерометр в самом устройстве – например, LIS203DL (плюс в том, что этот акселерометр установлен на отладочной плате stm32f4-discovery и имеются хорошо документированные примеры работы с ним).

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

Камеры на STM32F4

Элементная база камер представлена микроконтроллером STM32F407 + CMOS-камерой + внешней памятью. Подключаются они к основному блоку сигнализации через интерфейс RS-485 (на физическом уровне, а на прикладном используется ModBus). Наиболее оптимальным вариантом является размещение камер следующим образом:

Камеры работают в режиме фотосъёмки. Микроконтроллер STM32F4 выбран не случайно – он имеет встроенный синхронный параллельный интерфейс камеры DCMI, позволяющий подключать cmos-камеры до 1 мегапикселя. Среди прочих у него есть режим Snapshot, который и используется. При помощи механизма прямого доступа к памяти (DMA) данные с камеры сразу размещаются массивом во внешней памяти, подключённой через интерфейс FSMC микроконтроллера – при этом вычислительные ресурсы ядра не задействуются. По окончании записи кадра перегоняем данные в JPEG-формат – далее по RS-485 они пересылаются в центральный блок и используются для отправки на сайт системы и для формирования MMS-сообщения с фото (при этом вычислительной нагрузки на микроконтроллер STM32 основного блока сигнализации как таковой нет – мы тупо принимаем с камер и отправляем дальше (на сервер и в виде mms) jpeg-данные, не обрабатывая их. Построением MMS-сообщения занимается уже gsm-модем.

К слову говоря, использование cmos-камеры с обычными микроконтроллерами осложняется тем, что та же камера OV7670 не умеет передавать данные с частотой менее 10МГц + данные с неё нужно где-то размещать. Поэтому для использования камер с обычными микроконтроллерами (а также ПЛИС) очень часто применяют FIFO-буферы, например AL422B, объема памяти которых достаточно для хранения 1 кадра изображения с камеры:

Устройство основного блока сигнализации

Основными составляющими основного блока являются микроконтроллер stm32f103, gps/глонасс модуль, gsm-модуль SIM900.

GPS / Глонасс модуль

На данный момент использую всем известный gps EB500, но планируется переход на GPS/Глонасс модуль Геос-3М. Если сравнивать его с ML8088s/GL8088s, nv-08-c, то от первого выгодно отличается энергопотреблением (судя по инженерным образцам), от второго – ценой (28$ розница, 15$ опт). К слову говоря, в ё-мобилях планируется использование GPS/Глонасс-модуля Геос-1М.

Использование вместо обычного GPS сдвоенного модуля GPS/Глонасс даёт нам два основных преимущества:
1) Использование режима GPS+Глонасс позволяет повысить точность и успешность определения координат (т.к. нам доступно большее количество спутников – не только GPS, но и Глонасс).
2) Сейчас набирает обороты коммерциализация технологии Глонасс. Уже на законодательном уровне установка Глонасс-терминалов обязательна для установки на ряд транспортных средств. Поэтому поддержка Глонасс в автомобильном устройстве является дополнительным конкурентным преимуществом, обеспечивающим его привлекательность на рынке.

Работа с модулем не вызывает проблем – всю математическую обработку модуль берёт на себя, выдавая на выход текстовые строки с готовыми данными (протокол NMEA). О том, как на микроконтроллере STM32 организовать их разбор и работу с модулем – я писал в прошлой статье, «Спутниковый спидометр на STM32F1 и FreeRTOS». К слову говоря, модулем Геос-3М поддерживается выдача данных и в бинарном виде.

При использовании таких модулей основной проблемой становится повышенный уровень шумов на стоянке, что выражается в дрейфе координат и скорости на неподвижном объекте. И за ночь автомобиль, если не предпринять дополнительных мер, может накрутить на карте не один круг, оставаясь при этом в реальности всё время неподвижным. Самый лучший вариант решения этой проблемы без применения дополнительных компонент, который мне известен — это контроль изменения азимута с одновременным расчетом координат (не учитывать при небольшом изменении) – при таком подходе и мусор не учитываем, и получаем экономию памяти и трафика.

В любом случае, любая разновидность математической обработки показаний GPS/Глонасс-модуля не является идеальной – даже в самом лучшем варианте получается, что мы не учитываем малую скорость и небольшое изменение координат. Кардинально решить эту проблему в случае автомобильного применения способно совместное с Глонасс/GPS –модулем использование 3х-осевого гироскопа и автомобильного спидометра. В качестве такого гироскопа можно взять, к примеру, L3G4200D (19$). Для автомобильного применения уже анонсирован гироскоп A3G4250D, но его пока не найти в продаже. Работает такой гироскоп по шине I2C/SPI:

Итак, чем же нам помогает подключение гироскопа и спидометра?
а) мы получаем возможность довольно просто победить дрейф на стоянке — отбрасывать ложные данные о скорости и изменении координат на стоянке с GPS/Глонасс
б) При пропадании сигналов GPS/Глонасс мы получаем возможность продолжать вести географическое позиционирование по спидометру и гироскопу – продолжать вести трек.

В режиме стоянки, когда машина неподвижна, GPS/Глонасс-модуль говорит нам, что мы движемся с небольшой скоростью, координаты дрейфуют. Но с гироскопа мы получаем нули, что и даёт нам основания полагать, что мы стоим на месте и показания модуля можно игнорировать. При пропадании сигнала GPS/Глонасс в движении информацию о скорости мы берём со спидометра, а информацию о поворотах (угловых скоростях) – с гироскопа.
По реализации – нам по сути не важно, какой датчик скорости используется и откуда в машине его брать. Почти везде амплитуда сигнала скорости – 12 вольт, разница только в количестве импульсов в секунду. Здесь можно просто ввести самокалибровку – в движении по GPS/Глонасс автоматом определять, сколько импульсов приходится на 1 метр пути, и запоминать в память полученную константу.
Также необходимо ввести температурную калибровку гироскопа по GPS/Глонасс, т.к. его побочной стороной является температурный дрейф.

Тут необходимо отметить, что высчитывать путь по показаниям гироскопа и спидометра силами Cortex M3 – весьма сомнительная задача. Данные необходимо отправлять на сервер, на котором уже и будет производиться расчёт. Но в случае, если мы готовы отказаться от Глонасс, оставив только GPS, можно присмотреться к GPS-модулям LEA-6R – он имеет функцию DR (dead reconing), позволяющую подключить к модулю напрямую дополнительные каналы получения информации о пути — гироскоп и спидометр. Соответственно как микроконтроллер, так и сервер разгружаеся в этом случае в плане расчета координат – этим занимается уже сам модуль, выдавая готовые данные по NMEA. Что значительно снижает время и трудоёмкость разработки готового устройства. Жаль, но подобных решений, поддерживающих Глонасс, пока на горизонте не видно.: — (

А теперь — самое время рассмотреть работу с GSM-модемом.

GSM/GPRS модуль SIM900

Раньше во встраиваемых системах было распространено использование gsm-модуля sim300, но вскоре ему на замену пришёл sim900 (21$), а через некоторое время – начался выпуск его облегчённой бюджетной версии sim900r (в отличии от sim900, это – двухдиапазонный модуль с уменьшенной памятью программ и с ограничением по использованию в странах – только по России и приграничных странах). SIM900 является четырёхдиапазонным (850/900/1800/1900) GSM/GPRS модулем со встроенным TCP/IP-стеком. Позволяет отправлять MMS-сообщения, имеет встроенную поддержку протоколов прикладного уровня HTTP, FTP, а в последних прошивках – декодирование DTMF, возможность детектирования глушения сигнала GSM (Jamming Detection) и поддержка систем спасения eCall / ЭРА-ГЛОНАСС (о последнем будет рассказано подробно чуть ниже). Управлять модемом можно посредством AT-команд, подключать – через UART или I2C.

Разводить плату под этот модуль для отладки самостоятельно – дело неблагодарное, тем более, что отладочная плата для этого модуль совсем недорогая – 65$, поэтому её и рекомендую брать:

Для поддержки Эра-Глонасс, DTMF-декодирования и т.д. нужно обновить прошивку – для этого обратиться к дистрибьютору в своём регионе (я обращался в МТ-Систем), после чего прошить её через debug-порт.

Отлаживать работу с модулем удобней с компьютера. Благо я изначально в устройство закладывал поддержку USB для задания настроек, то сделал так: подключил библиотеку от ST для реализации USB CDC – класса, что дало возможность общаться с устройством через любую терминалку, работающую с последовательным портом (устройство видется в системе как виртуальный ком-порт). Устройство шлёт команды модулю SIM900, при этом в модуле включён эхоповтор – т.е. всё, что ему шлётся, он высылает обратно, вместе с ответом. А весь ответ с UART от SIM900 микроконтроллер шлёт по USB, мне в терминалку. Т.е. в процессе взаимодействия устройства с SIM900 на экране наглядно виден весь процесс общения + с терминалки появляется возможность управлять процессом общения, устанавливая своеобразные брейкпоинты. Это значительно упрощает написание функционала по работе с SIM900 и его отладку.

Начало работы с модулем SIM900 описано здесь и здесь, поэтому остановлюсь на наиболее интересных моментах:

SIM900: GPRS

Устройство по умолчанию раз в минуту отсылает данные (текущие координаты, скорость автомобиля и др.) на web-сервер и получает с него настройки. Давайте на простом примере посмотрим, как можно реализовать отправку данных по HTTP на свой сервер (оператор в нашем случае – МТС):

< AT+CREG? // Проверяем, зарегистрирован ли модуль в сети
< AT+CGATT=1 // Просим модуль включить GPRS
< AT+CSTT=”internet.mts.ru” // Задаём точку доступа.
//Если успешно – модем переходит в состояние IP START
< AT+CIICR // Работает только, когда модем в состоянии IP START. Открывает GPRS-сессию. Если удачно – модем переходит в состояние IP GPRSACT
< AT+CIFSR // Узнаём свой IP-адрес
< AT+CIPHEAD // Просим модем добавлять IP-заголовок к получаемым данным
< AT+CIPSTART=”TCP”,”www.tzit.ru”,”80” // Подключаемся к нашему серверу, допустимо только если модем в состояниях IP INITIAL или IP START
< AT+CIPSEND // отправлять только после получения от модема строки CONNECT OK. Говорим модему, что далее последуют данные, которые нужно отправить на указанный нами выше сервер. Наши данные отправляем только после получения строки «> »:
< GET /cgi-bin/sim900.pl?device_id=123&gsm_lac=111&gsm_ci=222&led=0
< Host: www.tzit.ru HTTP/1.0
< // На сервере для домена www.tzit.ru по протоколу HTTP 1.0 вызываем скрипт /cgi-bin/sim900.pl и методом GET передаём ему параметры device_id,gsm_lac,gsm_ci и led

SIM900: Защита от глушения GSM-сигнала

Злоумышленник может спокойно нарушить связь нашего устройства с сервером через GSM-канал, и для этого у него есть 3 пути:

1) Глушение GSM-сигнала

— при помощи такого нехитрого устройства стоимостью 119$ можно в радиусе 5-20 метров заглушить 3G/GSM/CDMA-модемы. И тревожный канал связи спутниковой gsm-сигнализации с сервером нарушится.

2) Подмена базовой станции оператора сотовой связи
Существуют устройства, помещающиеся в чемоданчике и позволяющие выдавать себя за базовую станцию сотовой сети:

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

3) Клонbирование сим-карты.
— у номера, используемого gsm-сигнализацией, появляется вторая сим-карта, находящаяся в руках у злоумышленников. И если заглушить сигнал сигнализации глушилкой из п.1, то устройство с таким номером (у злоумышленника) будет доступно и не будет подавать сигналов тревоги. Если проверка сигнализации основана на периодическом дозвоне – то дозвон будет осуществляться на поддельную сим-карту, и тревоги не вызовет.

4) Детектор поля для обнаружения радиотрансляторов (в т.ч. GSM-устройств)
— используется для локализации установленной сигнализации. Можно приобрести за 43$ такое чудо устройство:

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

Для защиты от п.4 на автомобиль устанавливают допонительно к штатной сигнализации gps/gsm-маячки, речь про которые пойдёт в разделе «SIM900: Использование пользовательских приложений. GPS / Глонасс – маяки.».

Для защиты от п.1 и п.3 модуль SIM900 поддерживает функцию Jamming Detection, предназначенную для выявления попытки глушения сигнала – для этого предназначена команда AT+SJDR. В случае, если модем глушат, будет выдано сообщение «+SJDR: JAMMING DETECTED». Конечно, модем не успеет связаться с сервером и передать данные о тревоге. Но устройство сможет включить сирену, заблокировать авто и запомнить, что его глушили – после возобновления связи эта информация уйдёт на сервер.

Для защиты от всех вышеприведённых пунктов в современных спутниковых gsm-сигнализациях применяют контроль канала связи GSM. Суть в том, что gsm-модем с заданной периодичностью связывается с сервером – например, шлёт данные по HTTP. Если в течении N последних минут модем с сервером не связался – это повод поднимать тревогу и звонить/отправлять SMS с сервера владельцу машины. Конечно, это не панацея для 100% случаев – где-то просто плохой приём GSM-сигнала. В других случаях злоумышленник может воздействовать на психику человека – периодически глуша сигнал и вынуждая владельца машины выбегать к своей машине. Через какое-то время владельцу это надоест и он отключит контроль канала связи, дав тем самым зелёный свет угонщику авто. Но тем не менее, контроль канала связи оказывается ощутимым подспорьем в решении задачи защиты от угона.

SIM900: Получение координат при отсутствии сигналов GPS / Глонасс

О текущем месторасположении машины мы получаем координаты от GPS / Глонасс – спутников. Но может возникнуть ситуация, при которой получение этих координат невозможно (например, нет сигнала). Вариант расчёта в этом случае координат через связку спидометр+гироскоп я уже рассмотрел выше. Но есть и другое решение — нам на помощь могут прийти базовые станции оператора сотовой связи, к одной из которых мы и подключены. От базовых станций мы можем получить такую информацию, как LAC и CELLID (код зоны и идентификатор базовой станции соответственно). Эта информация однозначно идентифицирует данную базовую станцию среди прочих текущего оператора сотовой связи. А координаты базовых станций широко известны. Поэтому, зная, к какой базовой станции модем подключён, можно определить географические координаты (долготу и ширину) этой станции, а тем самым – и примерные координаты нахождения самого модема. Географические координаты по lac и cellid базовых станций можно получить через API-интерфейс Яндекса, Google, opencellid.org, location-api.com. К слову говоря, операторы сотовой связи не публикуют в свободном доступе координаты своих базовых станций. Поэтому тот же Яндекс получает эти сведения от своих ползователей, у которых загружены приложения Яндекс и имеется в телефоне gps-приёмник. Приложение Яндекс с gsm-модема телефона получает cellid и lac базовой станции, а с gps-приёмника – текущие географические координаты, и отсылает на сервер Яндекса – таким образом и пополняются списки географических координат базовых станций БиЛайн, МТС и Мегафон.

Итак, мы хотим определить свои координаты по GSM. Для этого модулю SIM900 нужно подать команду AT+CREG=2 – он выдаст ответ в формате +CREG: ,,. Также этот ответ автоматически будем получать при смене модемом текущей базовой станции. Далее эти и передаём через GPRS на наш сервер. Сервер на базе этих данных берёт географические координаты из своего кеша, а при отсутствии в кеше – делает запрос на один из сервисов определения координат базовых станций – например, Яндекс, и получаем в формате координаты. Более подробно по использованию этих сервисов можно почитать на http://www.xakep.ru/post/48378/

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

В модемах SIM900 не так давно появились команда AT+CIPGSMLOC, сразу выдающая сразу географические координаты gsm-сети. Но ничего принципиального нового она в себе не несёт – эта команда выполняет всё то, что я написал выше. Получает lac, ci, отправляет их в Google и выдаёт результат.

Заодно отмечу, что некоторые модемы имеют возможность последовательно подключаться ко всем в БС в зоне видимости. Этим можно воспользоваться для уточнения gsm-координат — в таком случае мы можем узнать lac, ci всех ближайших БС, узнать по ним географические координаты – они будут вершинами полигона, в котором и находится наш модуль:

SIM900: Использование пользовательских приложений. GPS / Глонасс – маяки.

Автомобильная спутниковая сигнализация – это, конечно, хорошо. Но её могут найти и деактивировать. Например, при помощи детектора поля, рассмотренного выше. На помощь приходят gps/gsm-маяки, представляющие собою миниатюрные устройства с GPS (или GPS / Глонасс) приёмником, GSM-модемом и аккумулятором. Такие маяки сложно обнаружить визуально, т.к. они хорошо прячутся в скрытых местах автомобиля. Детектором поля их сложно выявить – т.к. большую часть времени такой маяк просто спит, лишь изредка просыпаясь, чтобы зарегистрироваться в сети, передать на сервер свои координаты, и снова заснуть.

Может возникнуть вопрос – а как же микроконтроллер? Ответ – он не нужен. В современных GSM-модемах имеется специальная область памяти для запуска пользовательских приложений. Например, в модемах Sierra Wireless используется операционная система OpenAT, в среде которой могут выполняться ваши программы. А SIM900 поддерживает технологию Embedded AT – вы просто создаёте свою программу в среде SIM900DevIDE, загружаете его с прошивкой в модем – и радуетесь жизни. Нет необходимости тратиться на отдельный контроллер – модем буде сам снимать данные с GPS/Глонасс-приёмника и отсылать на Ваш сервер. Вместе со средой SIM900DevIDE уже идут примеры программ, так что с чистого листа писать своё приложение не придётся.

SIM900: системы спасения eCall / ЭРА-ГЛОНАСС.

ЭРА-Глонасс – это система, предназначенная для снижения смертности и травматизма на российских дорогах, основанная на применении Глонасс. Если человек попадает в ДТП – автомобиль, оснащённый терминалом данной системы, способен самостоятельно, без участия челвовека, вызвать экстренные службы. Также имеется ручная возможность их вызова, по нажатию кнопки «SOS» (нечто похожее есть в Volvo On Call и Lexus Link, но там это платные услуги + стоимость самого оборудования довольно высока). Для того, чтобы автомобили, следующие из стран ЕС к нам, могли и в России получить экстренную помощь, и наоборот, чтобы наш автомобиль, оборудованный терминалом ЭРА-ГЛОНАСС, мог работать с западной инфраструктурой при выезде за границу, существует полная совместимость с европейской системой eCall. Т.е. если у нас есть поддержка ЭРА-ГЛОНАСС – то будучи за границей в странах ЕС, мы сможем воспользоваться системой экстренного реагирования eCall. По предварительным прогнозам, применение терминалов систем ЭРА-Глонасс/eCall позволит в Европе спасать ежегодно 2500 жизней, в России – 4000 жизней, и примерно на 14% снизить последствия травматизма в результате ДТП. Пока идёт лишь тестирование и развёртывание систем ЭРА-Глонасс и eCall. Окончательный запуск в эксплуатацию eCall намечен на 2014 год, а ЭРА-Глонасс – на конец 2013 года (мы оптимисты, однако!). С 2013 года все выпускаемые с конвеера автомобили должны уже иметь поддержку ЭРА-ГЛОНАСС. Но пройдёт ещё не один десяток лет, прежде чем у большей части нашего населения появятся автомобили с уже встроенным терминалом ЭРА-ГЛОНАСС / eCall, поэтому встроенная поддержка в наших устройствах этих систем ещё долго будет нести собой весьма значимое конкурентное преимущество, тем более, что в плане аппаратной реализации данная поддержка не несёт в себе дополнительных материальных затрат.

Терминал ЭРА-ГЛОНАСС несложно сделать и самому – для этого уже появились модемы, поддерживающие технологию передачи данных по голосовому каналу – функцию in-band modem. Давайте посмотрим, как это работает:

Но вначале ответим на вопрос – почему бы просто не использовать обычные GPRS, SMS? Дело в том, что они вносят существенную задержку при передаче данных. В режиме in-band modem данные передаются мгновенно, такому вызову будет выделяться максимальный приоритет оператором мобильной связи, даже в случае перегрузки сотовой сети. Если сеть перегружена – то активные вызовы других абонентов будут разрываться, чтобы ваш терминал мог связаться со службой 112.
В случае ДТП (определяется по показаниям датчиков автомобиля), либо если сами нажмёте кнопку SOS – то делаем экстренный вызов на службу 112 и отправляем на PSAP-сервер (в России – на PSAP-сервер федерального оператора НИС-ГЛОНАСС, который поддерживает версию 3GPP 8.6.0/9.4.0. PSAP расшифровывается как Public Service Answering Point) MSD-сообщение (MSD-Minimum Set of Data, минимальный набор данных) с ограничением в 140 байт, в котором содержится следующая информация:

1) Control data: является ли вызов тестовым, можно ли доверять указанным геокоординатам, тип автотранспорта (пассажирский автомобиль (класс M1), городской/междугородний автобус (M2-M3), легкий коммерческий автомобиль (N1), грузовик (N2, N3) мотоцикл – классы L1e-L7e)
2) Vehicle identification data: VIN-номер вашей машины
3) Vehicle propulsion storage type: на чём ездит ваша машина (газ, дизель, бензин, водород, электродвигатель) – можно одновременно указывать несколько значений (в случае если, например, машина использует как газ, так и электрическую энергию для передвижения)
4) Time stamp: Указываем текущую дату, включая секунды
5) Current location of vehicle: указываем географическую долготу и ширину, получаемые с нашего GPS / Глонасс – модуля. Если не знаем – можно просто не заполнять поле.
6) Direction of vehicle: направление движения машины по встроенному в терминал магнитометру, в градусах, причём 0 – это магнитный север. Отсчёт идёт по часовой стрелке, шагами в 2 градуса. Т.е. если отклонение в 120 градусов у нас от магнитного севера – то в MSD указываем значение 60. Либо просто 0xFF, если направление движения не известно.
7) Location delta with respect to vehicle Location, Location delta with respect to recentVehicleLocationN1: Разница в географических координатах между текущими координатами и теми координатами, которые были зафиксированы в момент происшествия. Эти поля также не является обязательным для заполнения.
8) Number of passengers: минимально известное количество пассажиров. Если не знаем – указываем 0xFF. Автоматически высчитывается следующим образом: в ремнях безопасности машины имеются датчики, фиксирующие, защёлкнут ли ремень безопасности (для нас это означает, что пассажир занял соответствующее место) — количество активированных датчиков и записываем в это поле.
9) Optional additional data: любая дополнительная информация (binary/bcd/xml/asn.1/ascii), формат жестко не регламентируется.
10) CRC32 – контрольная сумма CRC32 нашего MSD-сообщения

Суммарная длина MSD не может превышать 140 байт. Соединение по умолчанию инициируется клиентом (т.е. нами), но может инициироваться и PSAP-сервером службы 112.
Одним из первых модемов, в котором реализовали режим in-band modem для работы с eCall / ЭРА-ГЛОНАСС, был модем SL6087 компании Sierra Wireless. Но пару месяцев назад такая поддержка появилась и в прошивке для используемых мной модемов SIM900 компании SimCom. Причём есть возможность не только отправить уже сформированное готовое MSD-сообщение:

AT+CMSD=”015C0681508204420014264000420D101404E80DA4C89A3B2F09905B6440E829F6829EC020301027D04303046460”
AT+CECALL="112",0

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

AT+CMSDFORMATID=1
AT+CMSDMESSAGEID=1
AT+CMSDCONTROL=1,0,1,1
AT+CMSDVIN="WM9VDSVDYA123456"
AT+CMSDSTORAGE=1,0,0,0,1,0
AT+CMSDTIMESTAMP=2011,7,12,17,28,14
AT+CMSDLOCATION="48.300333","11.617367"
AT+CMSDDIRECTION=14
AT+CMSDRECENT1="10","-10"
AT+CMSDRECENT2="10","-20"
AT+CMSDPASGNUM=2
AT+CMSDBUILD
AT+CECALL=”112”,0

У оператора службы ЭРА-ГЛОНАСС эта информация при этом отобразится следующим образом:

Для тестирования вовсе необязательно обращаться в НИС-Глонасс – можно организовать тестовый PSAP-сервер на своей стороне с модемом на OpenAT, подробнее можно почитать здесь

Устройство, реализующая данный функционал, размещаем в металлическом корпусе, выдерживающем нагрузку в 40G (ведь устройство должно функционировать в случае ДТП), и имеющем встроенный аккумулятор для автономной работы.
Также, дополнительные требования распространяются и на сим-карту – использовать обычную сим-карту здесь малоприемлемо, т.к. в случае ДТП механический контакт сим-карты с устройством может с большой долей вероятности нарушится. Здесь приходят их аналоги для применения во встраиваемых устройствах – сим-чипы, которые имеют два основных преимущества по сравнению с сим-картами:
1) Лучший контакт ввиду отсутствия механических соединений – сим-чип напаивается на плату, а не вставляется механически в держатель,
2) Расширенный температурный диапазон (-40 … +105 градусов по Цельсию), а также повышенная устойчивость к воздействию пыли, выбрации, влажности, ударам, коррозии, химически-агрессивной среде.

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

В заключении данного раздела добавлю, что идея сама по себе имеет множество достоинств, притом реально полезных и нужных, но при всём при этом не лишена недостатков. Инфраструктура России в полной мере не подготовлена для внедрения данной технологии – только 97% территории охватывает сотовая связь, поэтому далеко не везде можно будет получить экстренную помощь. Причём даже в густонаселённых районах есть участки, где сотовая связь не работает или работает из рук вон плохо. Например, в Южном Бутово я знаю места, где воспользоваться сотовой связью довольно проблематично – порой её вообще нет. Нельзя не отметить и халатность – бывает, что позвонив на в полицию, скорую, можно так и не дождаться результата, получить отказ на выезд, хотя ситуация реально экстренная. Либо вообще не дозвониться. Вообще, многие российские государственные проекты в области информационных технологий оказываются реализованными на «тройку с минусом» — взять в пример хотя бы портал «Госуслуги», который с завидным постоянством радует нас «Ошибкой связи с ведомством» и «Internal server error», притом на самом последнем этапе оформления заявки, когда уже потратил много времени, чтобы забить все данные… Но даже если не удастся добиться 100% эффективности работы этого проекта – всё равно реализация не будет лишена смысла, поскольку в любом случае позволит снизить смертность и уровень травматизма на дорогах нашей страны, и позволит работать с экстренными службами других стран при международных поездках.

Устройства дистанционного доступа к сигнализации: метки, брелки, gsm-устройства

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

1) обычные брелки с односторонним/двусторонним каналом передачи данных – наверняка есть у каждого из вас. Нажимаем на кнопку – машина снимается с охраны и двери отпираются. Нажимаем ещё раз – двери блокируются, машина ставится на охрану. При снятии/постановки на охрану брелок отправляет на сигнализацию (обычно на частоте 433МГц) фиксированный уникальный код. Сигнализация проверяет код в своей базе – при совпадении код принимается. Недостаток очевиден – при применении код-грабберов мы слушаем эфир, и в момент, когда владелец машины нажимает на кнопку брелка, просто тупо записываем код, который брелок вещает в эфир. В дальнейшем злоумышленник может этот код воспроизвести и разблокировать машину.

2) Дальнейшим развитием сигнализаций в этом направлении была технология «прыгающего кода» KeeLoq – здесь каждый раз код меняется, и если перехватим код-граббером переданный код, то это нам не поможет. Но тем не менее злоумышленники и к KeeLoq нашли подход. Всю математическую мощность этой технологии сводит на нет физическая реализация – подбирать код никто и не пытается. Вместо этого, посылку портят, запоминают, и передают в следующий раз. Дело в том, что каждый бит посылки KeeLoq кодируется тремя битами. Первый бит – 0, далее значащий бит, и последний – 1. Если граббером включать передатчик на месте третьего бита (глушить приёмник сигнализации), то посылка для сигнализации окажется испорченной, и будет отвергнута. Мы же таким образом запомним код сигнализации, и в дальнейшем сможем им воспользоваться (если, разумеется, до этого сигнализация не примет успешно очередную посылку с брелка). Также можно учитывать то, что брелком посылается 3 одинаковых посылок. Можно заглушить первую половину первой посылки и вторую половину второй, третью полностью – сигнализация передачу отвергнет, а у нас будет рабочий код. В итоге – математика у KeeLoq была действительно сильной, но всё свелось на нет физической реализацией

3) На смену KeeLoq пришла технология диалогового кода (использующая ассиметричные алгоритмы шифрования и частоты 2.4ГГц), которая и используется сейчас в современных сигнализациях. Взломать её ещё никому не удалось, и производители сигнализации настолько уверены во взломостойкости этой технологии, что тот же StarLine предлагает 1 миллион рублей тому, кто удасться взломать такую сигнализацию. Этот миллион рублей пока никому не выплатили. Посмотрим, как идет общение между брелком и сигнализацией:
А) Брелок ----запрос----- > Сигнализация
Б) Брелок < ------случайное число ------ Сигнализация
В) …Брелок шифрует случайное число закрытым ключом…
Г) Брелок ----шифрованное закрытым ключом случайное число--- > Сигнализация
Д) …Открытым ключом сигнализация дешифрует шифрованное сообщение с брелка,
если числа совпадают - значит это свой брелок.
При прописывания нового брелка происходит передача открытого ключа брелка в память сигнализации, при этом используется алгоритм Диффи-Хеллмана для передачи ключей на открытых линиях связи.

Реализовать самостоятельно вполне реально, хоть и достаточно накладно. В этом плане можно присмотреться к микроконтроллерам STM32W, имеющие аппаратный ускоритель шифрования AES, работающий со 128-битными ключами, и 2.4Ггц трансивер. STM32W позволяет работать в сетях Wi-Fi, ZigBee, Bluetooth и спящем режиме имеет потребление порядка 1мкА, позволяющее использовать его в брелках. Имеются готовые отладочные наборы, позволяющие быстро освоить его беспроводные возможности (~50$).

4) RFID-метки – служат для бесконтактного доступа («свободные руки»), дальность связи – до 10 метров. Не нужно доставать из кармана и нажимать на кнопку – если метка находится в зоне действия приёмника сигнализации, то машина снимается с режима охраны. Пассивные метки представляют не имеют собственного источника питания, получают энергию по воздуху с сигнализации путём наведения токов на встроенной антенне. Активные – имеют встроенную батарейку, что позволяет снизить мощность считывателя сигнализации и увеличить дальность сязи. В основном метки работают на частоте 2.4ГГц (т.к. с увеличением частоты растёт дальность связи), и дальность связи со считывателем сигнализации составляет до 10м.

5) Сравнительно недавно в автомобильных СКУД стали применять GSM-устройства – снятие/постановка на охрану с сотовых телефонов, смартфонов. И всё чаще, глядя на будущее автомобильных сигнализаций, говорят о полном отказе от брелков в пользу GSM-устройств — смартфонов, сотовых. Но в чистом виде эта затея натыкается на грабли: нет 100% покрытия территории сотовой связью, есть большая вероятность остаться в глухом районе с заблокированной машиной и севшим смартфоном, необходимость платить за связь. Плюс сами пользователи пока не готовы отказываться от применения брелков. Тем не менее, всё движется
к тому, что в скором времени придём к связке метка+смартфон, и применение брелков останется в прошлом.

В случае применения смартфонов свести на нет основные недостатки – платность gsm-связи и недостаточное покрытие сетями – можно, обеспечив сигнализацию Wi-Fi модулем, что и будет рассмотрено далее

Обеспечение Wi-Fi доступа к сигнализации

В современных мобильных устройствах — телефонах и смартфонах, а также нетбуков и планшетах – имеется встроенная поддержка Wi-Fi, что и можно использовать для удалённого непосредственного доступа к нашему устройству, минуя сервер. Рассмотрим наиболее популярное решение – WiFi-модуль MRF24WB0MA стоимостью 22$ от Microchip:

— увы, к нашему STM32 его напрямую не подключить, для использования модуля придётся использовать прослойку в виде микроконтроллера PIC (впрочем, на цене изделия это ощутимо не отразится), на который и залить библиотеку, реализующую TCP/IP-стек, от Microchip, поддерживающую данный модуль (впрочем, для меня самого это не проблема, т.к. на PIC’ах я и поднимался). Сам модуль подключается к PIC по SPI, а уже с PIC к нашему STM32 его можно подключить через spi/i2c/uart. Сам модуль обладает хорошей функциональностью: встроенный акселератор для AES/RC4, поддержка WEP, WPA-PSK, WPA-2-PSK. Дальность – до 400м. потребление в режиме сна – 250мкА, гибернации — <0.1мкА. Сама библиотека среди прочего имеет поддержку SSL. Кстати, отмечу, что эта библиотека одинаковым образом работает как с Wi-FI-модулями Microchip, так и с проводными Ethernet (ENC28J60 и т.д.). Т.е., когда вы работаете с этой библиотекой, нет разницы, работаете вы с Wi-Fi или Ethernet модулем – программный интерфейс один и тот же. Подробнее про библиотеку можно прочитать здесь.

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

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

В последнее время бурное распространение получили мобильные GSM-устройства на базе операционных систем iOS (iPhone, iPad), Android, Windows Mobile, Blackberry и др., и в последнее всё большая номенклатура оборудования бытового назначения начинает обрастать поддержкой удалённого управления с этих устройств. Не остались в стороне и производители автомобильных GSM-сигнализаций, которые быстро выпустили приложения, позволяющие вести управление и мониторинг автомобилей со смартфонов. Добавить такую поддержку можно и в нашу с вами сигнализацию, которая уже умеет взаимодействовать с WEB-сервером (см. раздел по использованию TCP/IP-стека SIM900). WEB-сервер будет выступать здесь в роли посредника – ваше мобильное приложение подключается к серверу, и уже сервер взаимодействует непосредственно с сигнализацией. Само мобильное приложение реализует следующие основные функции:
1) Просмотр на карте (Google.Maps, Яндекс.Карты или OpenStreetMaps) текущего положение автомобиля
2) Бортовой компьютер – показания датчиков, температура, напряжение, сколько осталось до замены расходников и т.д.
3) Постановка/снятие с охраны
4) Удалённый запуск двигателя
5) Опционально – просмотр фотографий с камер и т.д.

Основной камень преткновения – необходимость изучать Objective-C и другие языки для разработки своего мобильного приложения под различные платформы. Тут на помощь приходят универсальные решения вроде PhoneGap:

PhoneGap – OpenSource среда, позволяющая кросс-платформенно разрабатывать приложения для почти всех известных платформ (iOS, Android и т.д.) на HTML5, используя Mobile jQuery и CSS. Приложение фактически является web-страницей, которая имеет доступ к аппаратной периферии смартфона (акселерометр, камера, GPS и т.д.). PhoneGap не лишён недостатков, и при промышленном применении необходимо всё же отказаться от кросс-платформенного подхода в пользу нативного – Objective-C. Но на первых порах он служит хорошую службу (особенно тем, кто по роду деятельности и так связан с web-разработкой), позволяя «малой кровью» обеспечить поддержку мобильных устройств.
Более подробно про PhoneGap можно почитать здесь

Программное обеспечение web-сервера

Пришла пора разобраться с реализацией web-сервера, который будет посредником во взаимодействии сигнализации и устройств, имеющих подключение к Интернет (смартфоны, нетбуки, планшеты, обычные компьютеры и т.д.). Web-сервер выполняет в нашем случае следующие функции:
1) Получает данные с gsm-сигнализаций и отдаёт им текущие настройки
2) Предоставляет web-интерфейс владельцам сигнализаций для мониторинга и управления сигнализациями
3) Обеспечивает доступ к данным с мобильных приложений (для устройств под управлением iOS, Android и и т.д.)
4) Предоставляет XML API-интерфейс для выгрузки данных на сервера клиентов
Наглядные примеры реализации можно посмотреть на http://panel.car-online.ru/ и https://p-on.ru/
Для размещения лучше выбрать облачный хостинг — в этом случае вы не ограничены жёстко в ресурсах, есть возможность гибкого масштабирования вычислительной мощности. В отличии от VPS-хостинга, здесь оплата идёт только фактически потребляемых ресурсах (при VPS приходится оплачивать ресурсы, которые большую часть времени простаивают + жёсткое ограничение по ресурсам).

Далее о структуре приложений сервера. На первых порах и при низкой нагрузке наиболее простым и обыденным решением оказывается LAMP (Linux-Apache-MySQL-PHP).
Но те, кто затачиваются на такой подход, очень быстро начинают об этом жалеть. :-)
Идёт время, растёт нагрузка, и довольно быстро наступает момент, когда текущая архитектура перестаёт справляться со своими задачами. Тогда и приходят мысли о Highload. Существует далеко не один подход, и в качестве примера рассмотрю Open-Source связку nginx+varnish+memcached+php-fpm+eaccelerator (+PHP, +MySQL). Немного о том, что это такое.
• Nginx – web-сервер, который обычно используется для отдачи статики. Популярна архитектура, в которой nginx выступает в роли front-end, проксируя запросы на динамические страницы на Apache (back-end), на котором уже и крутятся серверные скрипты. Но от применения Apache можно (и нужно) вовсе отказаться, повесив его функцию на более легковесный в работе nginx.
• php-fpm – PHP FastCGI Process Manager – выступает в нашем случае «связующим мостом» PHP для работы с nginx. Php-fpm позволяет эффективно использовать PHP в режиме FastCGI на highload-проектах.
• eAccelerator – средство, позволяющее каждый раз не выполнять интерпретацию PHP-кода. Один раз выполнили интерпретацию – и держим код в памяти для последующего использования – экономия процессорного времени и обращения к дисковым ресурсам налицо.
• Memcached – сервер кеширования данных в оперативной памяти. Серверы баз данных типа MySQL – это хорошо, но они тратят время на выполнения запросов и считывание с медленных устройств хранения данных – жёстких дисков. Гораздо быстрее данные можно выбирать из оперативной памяти, поэтому логика работы здесь такова: Делаем запрос к memcached, если искомых данных нет (пусто), то делаем запрос к серверу баз данных MySQL, и отправляем ответ в memcached. Т.е. MySQL выступает в роли медленного back-end решения, а Memcached – в роли быстрого front-end. К back-end обращаемся только один раз – чтобы разместить данные в front-end и обращаться в дальнейшем к этим данным только через front-end (пока, разумеется, они не утратят актуальность).
• Varnish – это HTTP-акселератор, позволяющий кешировать контент. В чём-то это аналог Memcached, то для существенно больших объёмов данных. Varnish сохраняет страницы в виртуальной памяти и по необходимости скидывает их на жёсткий диск. Мы можем логически разбить каждую страницу на составляющие блоки (футер, хидер, новостной блок и т.д.) и указать свои правила кеширования для каждого из блоков. В конечном итоге получаем выигрыш в скоросте отдаче страниц, и разгружаем back-end часть сервера от повторяющихся запросов.

Из дополнительных мер – посмотреть в сторону переключения MySQL на tmpfs, выстроить индексы таблиц, использовать движок хранения данных InnoDB (подходит в конкретно нашем случае), настройку sysctl.

Посмотрим одну из возможных схем архитектуры, с SSI-инклюдами. В первом случае, изначальном, у нас пустой кеш, в дело включается back-end (PHP+MySQL), а во втором – не используется, данные получаем с Varnish и Memcached:

— в первом случае nginx обращается к Varnish за страницей, которой нет в кеше – потому запрос идет на Back-end (PHP+MySQL). Кеш SSI-инклюдов хранится у нас в Memcached – и т.к. там пусто, то Nginx производит обращение к back-end части, которая отдает результат в nginx и одовременно сохраняет в кеше через Memcached.
Во втором случае мы уже не дёргаем back-end часть, данные берутся из кеша Varnish и Memcached.

Вышеизложенное не является универсальным решением – архитектура Highload проекта своя под каждую конкретную задачу – требуется на тестовом сервере реализовать решение и провести нагрузочное тестирование – попытаться максимально полно смоделировать рабочую ситуацию, учитывая максимально прогнозируемые объёмы роста нагрузки. И никогда нельзя останавливаться на достигнутом. «Я всё сделал, все работает, можно вздохнуть с облегчением и расслабиться» — так не бывает. Всё время нужно думать на шаг вперёд, прогнозируя возможные развития текущей ситуации.

Пути дальнейшего развития

Устройство уже и так выполняет множество функций – это и сигнализация, и бортовой компьютер, и телекоммуникационный сервис (ЭРА-ГЛОНАСС / eCall) в одном флаконе, с доступом через Интернет. Предназначено как для легковых машин, так и для грузовых, и для объектов недвижимости. Но нет предела совершенству. Если мы хотим снабдить электроникой свою машину, то приходится приобретать разрозненные устройства – магнитолу, навигатор, видеорегистратор и т.д. Приходится облеплять ими ветровое стекло, что сужает видимую область и привлекает лишний раз нечистых на руку людей к машине. На рынке сейчас нет достойного устройства – «медиакомбайна», заменяющего вышеперечисленные устройства, создающего единую точку входа для всех функций и хорошо интегрируемого со штатным оборудованием автомобилей. Даже Китай до сих пор не преуспел в этом плане. Довольно значимый шаг вперёд в этом направлении сделал Мирком:

— решение на ARM11 под управлением WinCE с gsm-модемом, gps/Глонасс-приёмником, позволяющее подключать аудио-видео источники и выводящее изображение как на отдельные дисплеи, так и на штатные автомобилей. Интегрируется со штатными системами Lexus/ Toyota/Subaru/Nissan и др. автомобилей. Задумка неплохая, это действительно значимый прорыв. Прорыв, сведённый на «нет» реализацией – устройство до сих пор слишком сырое, имеющее проблемы в работе и недостатки реализации, высокую цену.
Таким образом, эта область до сих пор остаётся неосвоенной, достойных, сильных и доступных большинству решений здесь нет. Информация, приведённая в этой статье по разработке спутниковой сигнализации, может стать хорошим трамплином для разработки конкурентноспособного устройства. В качестве основы сразу напрашивается одноплатный компьютер Raspberry Pi с ARM11, функциональное оснащение которого можно расширить. :-)

В качестве заключения

Вот мы и разобрали буквально в двух словах на пальцах основные моменты разработки автомобильных спутниковых GSM-сигнализаций, от и до. :-) На своём собственном примере убедился, что не так страшен чёрт, как его малюют, и всё реально сделать самому, нужно лишь время и терпение. На самом деле, важно помнить золотое правило: «лучше меньше, да лучше». Стремясь объять необъятное, наделить своё устройство как можно большим набором функционала, производители зачастую теряют в качестве исполнения. Лучше очертить для себя круг, урезать свою «хотелку», сделать меньше, но зато качественно и достойно, детально проработав все нюансы.

В статье я рассматривал только спутниковые системы, оставив в стороне радиопоисковые. С одной стороны, радиопоисковые системы выигрывают над спутниковыми – меньшее энергопотребление, работа в закрытых помещениях (сигнал пробивается через металлические боксы, подземные гаражи и т.д.), передатчик можно размещать в машине где угодно (в дверях, скрытых полостях кузова и т.д.). Но с другой стороны, есть и минусы: недостаточное покрытие территории радиомаяками, относительно высокая абонентская плата, невозможность отображения на карте положения охраняемого объекта, невозможность разработки своего радиопоискового устройства – разве что только свои радиомаяки в городе ставить, что весьма накладно ) Плюс преимущества радиопоисковых систем конечному потребителю наглядно на примере работы устройства не продемонстрируешь. Мало кто из вас решится заплатить ощутимую сумму денег за агрегат, которым не воспользуешься в своих целях, работа которого будет ему не видна. Т.е. потребителю важно «пощупать» в деле то, что он приобретает. Спутниковые системы в этом плане заметно выигрывают. И нет ничего удивительного в том, что они по продажам заметно выигрывают, а радиопоисковые до сих пор остаются в тени, несмотря на все свои преимущества.

Что касается комплектации автомобильной сигнализации, то настоятельно рекомендую не довольствоваться штатным оснащением, а устнавливать в скрытые полости gps-маячки. Кроме того, оклеить стёкла бронированной плёнкой и вставить в двери штыри – это не только дополнительная мера от угона автомобиля, но и реальная защита от кражи вещей в салоне. Кроме того, уже давно стандартом де-факто является установка электрического замка капота и замок типа Гарант на руль + цифровые реле (на основе токовых ключей) на основные цепи машины, которые блокируются, если сигнализацию выводят из строя – если сигнализация поддерживает их установку. Нам часто жалко денег – махаем рукой, думаем, что машина того не стоит. И жалеем только тогда, когда уже поздно что-либо изменить…

P.S. Думаю, многие из вас заметили, что ролик в самом начале статьи «переигран» для завлечения клиентов – сигнализация разумеется не отправляет никакие данные на спутник, такие сигнализации называются спутниковыми только потому, что принимают данные с GPS/Глонасс-спутников. Чтобы отправлять информацию на спутники, нужна хорошая такая тарелка. ;)

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

1) Спутниковый спидометр на STM32F1 и FreeRTOS
2) Проект национальных стандартов ЭРА-ГЛОНАСС. Выражаю благодарность директору службы разработки абонентских устройств Федерального оператора «НИС-ГЛОНАСС» Домарацкому Я. А. за предоставленные материалы.
3) Исходники автомобильного gps-трекера на базе ATmega128
4) Исходники gsm-сигнализации на 2 сим-карты, iButton, dtmf-декодером

Автор: tzirulnicov