Теория создания самодельной автомобильной спутниковой сигнализации с 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 класс, поэтому на стороне компьютера устройство определяется как обычный com-порт, и работать с ним можно через любую терминалку (я использую 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 на свой сервер (оператор в нашем случае – МТС):
SIM900: Защита от глушения GSM-сигнала
Злоумышленник может спокойно нарушить связь нашего устройства с сервером через GSM-канал, и для этого у него есть 3 пути:
1) Глушение GSM-сигнала

— при помощи такого нехитрого устройства стоимостью 119$ можно в радиусе 5-20 метров заглушить 3G/GSM/CDMA-модемы. И тревожный канал связи спутниковой gsm-сигнализации с сервером нарушится.
2) Подмена базовой станции оператора сотовой связи
Существуют устройства, помещающиеся в чемоданчике и позволяющие выдавать себя за базовую станцию сотовой сети:
GSM-модем устройства не сможет отличить реальную базовую станцию от поддельной мобильной, и в случае тревоги не сможет отправить данные по тревожному каналу.
3) Клонирование сим-карты.
— у номера, используемого 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: <stat>,<lac>,<ci>. Также этот ответ автоматически будем получать при смене модемом текущей базовой станции. Далее эти и передаём через 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-сообщение:
, но и переложить эту функцию на сам модем, указав значения полей MSD-сообщения через АТ-команды:
У оператора службы ЭРА-ГЛОНАСС эта информация при этом отобразится следующим образом:

Для тестирования вовсе необязательно обращаться в НИС-Глонасс – можно организовать тестовый 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/Глонасс-спутников. Чтобы отправлять информацию на спутники, нужна хорошая такая тарелка. ;)
UPD 06.09.2012: Модули 2G (sim900) теперь не могут использоваться в системах ЭРА-ГЛОНАСС в соответствии с новым ГОСТ Р 54620-2011, для этого требуются модули 3G (например, работу с ЭРА-ГЛОНАСС поддерживает 3G-модуль SIM5320).
Список литературы
1) Спутниковый спидометр на STM32F1 и FreeRTOS
2) Проект национальных стандартов ЭРА-ГЛОНАСС. Выражаю благодарность директору службы разработки абонентских устройств Федерального оператора «НИС-ГЛОНАСС» Домарацкому Я. А. за предоставленные материалы.
3) Исходники автомобильного gps-трекера на базе ATmega128
4) Исходники gsm-сигнализации на 2 сим-карты, iButton, dtmf-декодером
5) Исходники GPS-трекера на STM32
6) Исходники GPS-трекера на STM32F10x
6) ГОСТ Р 54620-2011 «Автомобильная система вызова экстренных оперативных служб. Общие технические требования»
7) Приказ Минтранса России от 31.07.2012 N 285 — интересен описанием протокола передачи телематической информации и процедуры вызова экстренных служб
Решил наконец написать продолжение статьи «Спутниковый спидометр на 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 класс, поэтому на стороне компьютера устройство определяется как обычный com-порт, и работать с ним можно через любую терминалку (я использую 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? // Проверяем, зарегистрирован ли модуль в сети<br>
< AT+CGATT=1 // Просим модуль включить GPRS<br>
< AT+CSTT=”internet.mts.ru” // Задаём точку доступа.<br>
//Если успешно – модем переходит в состояние IP START<br>
< AT+CIICR // Работает только, когда модем в состоянии IP START. Открывает GPRS-сессию. Если удачно – модем переходит в состояние IP GPRSACT<br>
< AT+CIFSR // Узнаём свой IP-адрес<br>
< AT+CIPHEAD // Просим модем добавлять IP-заголовок к получаемым данным<br>
< AT+CIPSTART=”TCP”,”www.tzit.ru”,”80” // Подключаемся к нашему серверу, допустимо только если модем в состояниях IP INITIAL или IP START<br>
< AT+CIPSEND // отправлять только после получения от модема строки CONNECT OK. Говорим модему, что далее последуют данные, которые нужно отправить на указанный нами выше сервер. Наши данные отправляем только после получения строки «> »:<br>
< GET /cgi-bin/sim900.pl?device_id=123&gsm_lac=111&gsm_ci=222&led=0<br>
< Host: www.tzit.ru HTTP/1.0<br>
< // На сервере для домена www.tzit.ru по протоколу HTTP 1.0 вызываем скрипт /cgi-bin/sim900.pl и методом GET передаём ему параметры device_id,gsm_lac,gsm_ci и ledSIM900: Защита от глушения GSM-сигнала
Злоумышленник может спокойно нарушить связь нашего устройства с сервером через GSM-канал, и для этого у него есть 3 пути:
1) Глушение GSM-сигнала

— при помощи такого нехитрого устройства стоимостью 119$ можно в радиусе 5-20 метров заглушить 3G/GSM/CDMA-модемы. И тревожный канал связи спутниковой gsm-сигнализации с сервером нарушится.
2) Подмена базовой станции оператора сотовой связи
Существуют устройства, помещающиеся в чемоданчике и позволяющие выдавать себя за базовую станцию сотовой сети:
GSM-модем устройства не сможет отличить реальную базовую станцию от поддельной мобильной, и в случае тревоги не сможет отправить данные по тревожному каналу.
3) Клонирование сим-карты.
— у номера, используемого 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: <stat>,<lac>,<ci>. Также этот ответ автоматически будем получать при смене модемом текущей базовой станции. Далее эти и передаём через 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 миллион рублей тому, кто удасться взломать такую сигнализацию. Этот миллион рублей пока никому не выплатили. Посмотрим, как идет общение между брелком и сигнализацией:
А) Брелок ----запрос----- > Сигнализация<br>
Б) Брелок < ------случайное число ------ Сигнализация<br>
В) …Брелок шифрует случайное число закрытым ключом…<br>
Г) Брелок ----шифрованное закрытым ключом случайное число--- > Сигнализация<br>
Д) …Открытым ключом сигнализация дешифрует шифрованное сообщение с брелка,
если числа совпадают - значит это свой брелок.При прописывания нового брелка происходит передача открытого ключа брелка в память сигнализации, при этом используется алгоритм Диффи-Хеллмана для передачи ключей на открытых линиях связи.
Реализовать самостоятельно вполне реально, хоть и достаточно накладно. В этом плане можно присмотреться к микроконтроллерам 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/Глонасс-спутников. Чтобы отправлять информацию на спутники, нужна хорошая такая тарелка. ;)
UPD 06.09.2012: Модули 2G (sim900) теперь не могут использоваться в системах ЭРА-ГЛОНАСС в соответствии с новым ГОСТ Р 54620-2011, для этого требуются модули 3G (например, работу с ЭРА-ГЛОНАСС поддерживает 3G-модуль SIM5320).
Список литературы
1) Спутниковый спидометр на STM32F1 и FreeRTOS
2) Проект национальных стандартов ЭРА-ГЛОНАСС. Выражаю благодарность директору службы разработки абонентских устройств Федерального оператора «НИС-ГЛОНАСС» Домарацкому Я. А. за предоставленные материалы.
3) Исходники автомобильного gps-трекера на базе ATmega128
4) Исходники gsm-сигнализации на 2 сим-карты, iButton, dtmf-декодером
5) Исходники GPS-трекера на STM32
6) Исходники GPS-трекера на STM32F10x
6) ГОСТ Р 54620-2011 «Автомобильная система вызова экстренных оперативных служб. Общие технические требования»
7) Приказ Минтранса России от 31.07.2012 N 285 — интересен описанием протокола передачи телематической информации и процедуры вызова экстренных служб
