@tymburo

Всем привет!

Делаю вот сейчас курсовой проект, в будущем планируется развить все это дело до диплома.

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

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

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

Итак, каковы требования:
1. Все устройства вешаются на одну общую шину. А значит нужно организовать адресацию.
2. Главное устройство должно слать данные другим устройствам, другие устройства должны сами (то есть выступать ведущими) слать данные главному устройству. Слать данные друг другу им не нужно.
3. Физически интерфейс должен быть помехоустойчивый и максимальная длина кабеля должна быть где-то около 500 метров, а лучше километр (не знаю насколько это рационально для системы охраны, но препод настаивает на этом).
4. Ограничений к скорости передачи нет, ибо данных передавать ерунда: одна посылка вряд ли будет больше 2-6 байтов.
5. Было бы не очень хорошо тащить больше 3-5 проводов в кабеле.
6. Ах да, ну и не обязательно: думаю, было бы здорово, если бы интерфейс можно было бы несложно совместить с UART на борту контроллера.

Итак:
1. Какой мне лучше выбрать физический интерфейс?
2. Какие есть стандарты подходящих протоколов передачи поверх этого интерфейса?

Заранее спасибо за помощь!

0

@_pv

1) rs485, can
2) modbus, wake
так как в can уже предусмотрена адресация(идентификаторы сообщений), контрольные суммы и гарантированная доставка на низком уровне, то поверх него больше ничего особо можно и не городить, ну только свой формат комнанд устройствам. правда набортный УАРТ для организации связи по CAN никак не поможет. если нет в МК, CAN контроллер надо будет внешний, на spi вешать.

0

@tymburo

Я как раз думал остановится на rs485. Как минимум контроль по четности он то подразумевает. Правда вот всякую адресацию, арбитраж шины и т.д. придется реализовывать поверх. Вполне возможно с помощью modbus. Еще меня заинтересовала такая вещь как P-NET. А расскажите поподробнее про wake, что это? А то я что-то про него не знаю и прогуглить не могу. Или просто ссылочку где почитать.

А на счет CAN - я не понимаю, почему вы его в (1) написали. Как я понял, он более высокого уровня и реализуется поверх каких-то физических интерфейсов, нет?

UPD: Нашел инфу, что у CAN есть определенный наиболее популярный интерфейс физического уровня, который вроде как принято включать в сам CAN.

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

0

@_pv

rs485 это только физический уровень, ничего кроме напряжения логических уровней сигналов в линии он не подразумевает.
реализовывать modbus только для себя, ну то есть если не планируется использовать сторонние устройства с ним, пожалуй изыточно.
http://soxopa.ru/lib/wake/ автора, насколько понимаю, можно здесь на форуме найти.
если хочется свой велосипед изобрести, то для упрощения из него можно, пожалуй, byte stuffymg, убрать.
и зафиксировать байты адреса/команды, чтобы не идентифицировать их по старшему биту, а слать всегда обоих.
и если не планируется кучу данных гонять то и длину тоже можно зафиксировать и слать всегда 2-4 байта.

у него и физический уровень несколько отличается от rs485 тем, что уровни 0 и 1, не симметричны, типа как открытый коллектор, 0 всегда перетягивает 1, и ситуация когда на шину говорят сразу много устройств вполне нормальна, в отличии от 485, и позволяет на физическом уровне разруливать коллизии, и благодаря этому их там просто не возникает вообще.

физический уровень 485 может просто использоваться с UARTом любого контроллера. в некоторых контроллерах в УАРТах есть некие костыли которые помогают устроить адресацию, даже в AVRах вроде есть возможность перевести уарт в 9 битный режим, и тогда этого дополнительный бит используется для выделения байта с адресом, но имхо радости от этого не сильно много проще это самому руками сделать.
с арбитражем надо просто чтобы слэйвы самовольно не говорили ничего пока не спросят, если так не подходит, и надо чтобы по какому-то событию устройства сразу об этом сообщали не дожидаясь пока их спросят (опросить сотню устройств это десяток другой байт на устройство, то есть несколько переданных килобайт, на 9600 например - займёт несколько секунд), тогда протокол несколько усложняется, нужны подтверждения (хотя они и так нужны по хорошему), и надо детектить коллизии (то есть одновременно с передачей смотреть что происходит на линии и сравнивать с передаваемым) и разруливать их самому, например подождав случайное время после возникновения коллизии перед тем как еще раз попробовать.

0

@ZPS

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

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

Если модуль не ответил 3-4 раза, он вычеркивается и выставляется ошибка "потеря модуля", которая дает тревогу если надо.

В простых системах обмен идет простой в пару байт:
- байт адрес модуля (1-255), где 255 может означать все модули или несколько верхних/нижних адресов под группы/типы модулей.
- байт на команду
- байт на размер ожидаемого ответа или контроль.
В сложных:
адрес идет в виде серийного номера модуля 8-12 байт
+ какая-то информация для модуля (обновление состояния выходов и тп),
+ 1-2 бита/байта под проверки (чексум) на каждый блок отдельно.
+ куча лишней информации для приведения всех пакетов к общей длине.
В больших системах много широковещательных передач - когда сообщение от мастера не имеет адресата, но несёт в себе огромное количество информации о всей системе и каждый модуль сам решает что из этой инфы ему надо - выходные модули читают что там с выходами, входные снижают скорость опроса при снятии с охраны и тп.

На что советую обратить внимание, если система пойдет в реальное использование или просто хочется сделать грамотно:
Длина кабеля в 500 метров - это не много, у меня были прогоны в 1-2км в пределах одного объекта (этаж складской 200 м + 40м подъема, потом ещё 200м обратно + ещё метров 50-100 от модуля до датчика). В универе, коридор был 1200 метров от поста охраны до дальнего корпуса.

Все модули на шине должны быть максимально автономны - никаких отдельных входов на клавиатуру - клавиатура или любой другой модуль должен вешаться в любое место на шину - никогда не знаешь где на объекте вырежут дверь (+клавиатура) или где наставят стен (+ модуль зон). При обрыве линии данных, все модули должны сохранять функциональность в разумных пределах - если это модуль управления дверями или нагрузками, он должен дальше управлять дверью или держать открытыми ворота и тп. Зонный модуль должен продолжать работать (если запитан своим блоком) и мигать индикатором ошибки - чтобы при поиске обрыва было видно, где линия есть, а где нет. Клавиатура должна выводить сообщение "потеря связи, зови ремонтника" - и ремонтнику проще и люди сума не сходят, пытаясь продавить кнопки.
По возможности, модули должны быть двунаправленные - если это модуль с 8 реле на нагрузки, сделай хотябы один простой вход на датчик - как минимум это антисаботажный датчик на крышке модуля. Модуля с реле должны иметь возможность питаться как от линии, так от своего блока, блок при этом с АКБ и контролем исправности питания - ошибки питания должны распознаваться мастером.
Включение/выключение модуля не должно никак сбивать работу шины - не включай питку приёмопередатчика, пока контроллер не сказал "всё, я проснулся, себя контролирую".
На основной плате должно быть минимум 2 изолированных блока питания - один на мозги платы, дозвонщик и сиренку, второй на питание линии - чтобы закорачивание линии не вывело из строя тревожную систему.

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

0

@ZPS

Ещё дополнение к автономности модулей - всю грязную работу надо скинуть на модули :) Ну или на какие-то максимально железные части основной платы. Например, проверки состояния входов.
Зона считается сработавшей, если датчик открыт более чем 60мс - если ниже, замучаешься с ложными срабатываниями, но должны быть возможность регулировки как в низ так и вверх - может где-то за 60мс уже успеют проскочить или где-то стоит механический медленный датчик и у него дребезг в пол секунды и тп. Вот эти интервалы должен помнить и проверять сам модуль - при настройке в него заливаются эти данные, он их запоминает и дальше сам проверяет свои входы по этим критериям, а шину беспокоит только когда уже уверен что это сработка.

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

0

@ivsxx1

В качестве органзации связи посмотрите Zigbee или открытые частоты Science medical и тп, так как тянуть километры проводов распределенных систем унылость.Кроме того прикрутите на главный модуль ГПРС и порстой веб интерфейс,хорошая няша выйдет.ну а прооткорл,протокол хоть ASCII символы)

0

@tymburo

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

я начинаю склоняться к тому чтобы сделать все на rs485, а остальное дописать ручками.

хмм.. то есть жесткий мастер-слейвы с опросом мастером слейвов это не плохо и очень даже используется, правильно?

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

дада, это одна из главных фишек, которые я и хочу сделать.

да, сурово и круто! :)

мм, да! на всякий случай и вправду стоило бы, для последующих расширений и доработок чтоб не перехреначивать опять всю систему.

благодарю за ценные напутствия, информация действительно для меня очень нужная!

0

@DOOMSDOY

2 ZPS.
Во расписал... Классно, я аж завидую, что пока не приходилось с подобным поработать. Хоть и затрах, наверное, бывает, но интересно же))

0

@tymburo

веб-интерфейс для управления главным модулем я как раз и хотел сделать, а вот ГПРС это идея!

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

0

@DOOMSDOY

веб-интерфейс для управления главным модулем я как раз и хотел сделать, а вот ГПРС это идея!

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

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

0

@tymburo

о да, я тоже предчувствую, что так будет... но зато интересно и полезно

0

@ShodS

Кстати, чтото подобное тоже в свое время с нуля замутил.....
http://asis-kbr.ru/forum/viewtopys.php?f=9&t=107

0

@ZPS

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

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

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

Поясню - модули расширения ставятся на большом расстоянии от главной платы - это позволяет не тянуть пучки проводов на сотни метров. Если модули будут стоять на удалении в 200 метров от платы, это всё будет отлично работать в поле или в фанерном доме, но если это здание завода с фортификационным бетоном в самых неожиданных местах... зигби и одной стены не пройдет. А связь должна быть быстрой и устойчивой.
А если за стеной лифт, станки, просто кабеля силовые - могу много баек рассказать про то, как после обычного, планового выключения питания в офисном здании, мы меняли по 2-3 радиомодуля или видеокарты.
Как быть с потерей связи? На объекте стоящем под охраной, это однозначный сигнал тревоги - но если потеря вызвана включившимся за стеной лифтом или вент автоматикой.
Радиосистему очень сложно, почти невозможно протащить через сертификацию (европа) - тут очень сложно соблюсти баланс между мощностью и надежностью - слишком слабо будут потери, слишком сильно - вред здоровью и другой технике. А есть ещё сертификация на соответствие нормам безопасности - если её не пройти, ставить такой прибор можно будет только на сараи. Система построенная на стандартных радиомодулях, тест на безопасность не пройдет. Для России это не критично, но я бы на защите обязательно задал пару вопросов на эту тему.

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

0

@drvtos

+1
Упредил мои слова! Достойная лекция. Чувствуется огромный практический опыт и, что редко встречается, умение его толково изложить.
Я-то никаким боком не в теме, но понятие иметь надо. И вот эти все КАНы и радиоштучки как-то уводят, делают картинку расплывчатой. А тут просто и конкретно: вот такая практика и по таким причинам.
Думаю, дал поучиться не только студенту :) Спасибо, уважаемый ZPS!

0

@ZPS

Ой, а расскажи в 2х словах о физическом уровне протокола. В данный момент аналогичную штуку разрабатываю и тоже на тиньке13 :) Пока тестовое у меня бегает на аналоге wiegomd протокола по 2м жилам, но это как-то коряво...

0

@ZPS

Пожалуйста :)
Я на самом деле давно хотел поделиться и даже наброски заметок сделал, думал серию на we. выложить. Но там получается слишком много секретов раскрывается, которые не стоит в открытый доступ класть - не за чем "пионерам" знать уязвимости охранных систем.

0

@_pv

[QUOTE="tymburo"] почему нет, чем проще и топорней тем лучше и надёжнее, однако как я уже замечал, для того чтобы опросить сотню датчиков на небольшой скорости может потребоваться значительное время - секунды, оно конечно частично лечится если критичные датчики опрашивать чаще.
так что одноранговые сети где все узлы могут быть равнозначны тоже имеют право на жизнь.
еще в физическом уровне CAN по сравнению с УАРТом несколько более злой способ принятия решения о том какой лог уровень на шине и битовая синхронизация.
не как в УАРТе, где поймали первый фронт стартового бита и потом от него осчитываем 1.5, 2.5, 3.5 ... длительности бита и сэмплим данные.
это делает CAN немного более помехозащищённым чем rs485.

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

0

@tymburo

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

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

Да, и еще вот какая штука: эта система безопасности очень и очень близка к системе "умного дома". Я увлекся такими системами именно как начал делать элементы "умного дома" у себя на даче. И поэтому меня посетила идея: в одной готовой системе можно комбинировать систему автоматики и управления, систему безопасности и "умного дома". Да и систему можно продавать и как систему безопасности, и как "умный дом". В последнем случае, она может быть несколько облегченная.

почитаю :)

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

я думал на счет этого, но мне показалось, что слишком большая угроза надежности.

была даже идея модулировать на сеть 220 вольт :)

0

@tymburo

Кстати к вопросу о выжидании случайного промежутка времени.

А как получить надежный аппаратный генератор случайных чисел?

0