SanyaKID 0 9 сентября, 2011 Опубликовано 9 сентября, 2011 · Жалоба Необходимо спроектировать и разработать сеть, протокол и ПО для датчиков. Сами датчики разрабатывать не надо. Датчики дают наличие воздействия и его описание. Со стороны PC необходимо получать не только сигнал, но понимать какой из датчиков его выдал. Соответственно датчики должны быть адресными. Кроме того, необходимо управление датчиками (например настройка чувствительности), как по отдельности так и группами. Сеть должна покрывать расстояния от нескольких сотен метров до двух десятков километров. Поэтому требуется хорошая масштабируемость. Исходя из задачи, на данный момент подразумевается древовидная архитектура: PC /......\ HUB HUB /...\ /...\ Д Д Д Д PC - компьютер, собирающий информацию с датчиков HUB - некий коммутатор, за счет которого производится масштабирование. Д - датчик. Уровней Хабов может быть несколько. Под линиями связи пока подразумевается CAN или RS485. Может быть и другая. В будущем датчики должны быть оснащены беспроводным интерфейсом и батарейным питанием и это тоже нужно учитывать. Для решения задач с беспроводным интерфейсом можно использовать например следующую штуку: http://www.kb-mars.ru/products.html Так вот, нам нужен человек, имеющий опыт построения схожих сетей и способный выполнить задачу. Так как архитектуры точной нет, только общие требования, то от кандидата хотелось бы услышать предложения по наиболее оптимальному решению задачи. Офис: Москва, м. Белорусская. Работать можно и не в офисе, но желательно Москва и область, так как нужно будет много общаться и испытывать систему. Пишите на aosurkov(сабака)gmail.com Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ruslan1 17 9 сентября, 2011 Опубликовано 9 сентября, 2011 · Жалоба (Просто комментарий, извините.) Вам точно зададут вопрос про предельное количество устройств и требуемый объем данных для обмена. Также СЕРЬЕЗНО подумайте над вопросом кто является инициатором связи. У Вас написано что "Со стороны PC необходимо получать не только сигнал, но понимать какой из датчиков его выдал". То есть инициатива датчиков? Это еще туда-сюда на CAN, но вот при беспроводной реализации проблемы создает крупные по времени доступа и оверхеду траффика. По закону подлости всем датчикам приспичит свистнуть одновременно. Для решения задач с беспроводным интерфейсом можно использовать например следующую штуку: http://www.kb-mars.ru/products.html Ну не знаю, может в России все и хорошо (на каком чистом полигоне интересно они 10км на 433МГц 10mW получили?), но в Москве и окрестностях эти расстояния думаю так в сотню-тысячу раз уменьшить нужно. Ну и мне кажется, вам лучше ориентировать потенциального разработчика системы на взять что-то готовое (протокол хотя бы) и реализовать его, а не придумывать очередной доморощенный велосипед, задача классическая и решения нужны классические а не придуманные вчера. Если дело ограничется написанием(разработкой) простенького интерфейса с конкретными датчиками а не разработкой доморощенных протоколов и железа с нуля- вы только выиграете в результате. Не будет устраивать стоимость покупного-позже сделаете разработку своих аналогов для удешевления. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SanyaKID 0 9 сентября, 2011 Опубликовано 9 сентября, 2011 (изменено) · Жалоба Опустим пока беспроводную часть. Это отдельная задача. по поводу количества устройств - в том то и дело что их будет много. Даже если датчики будут стоять каждые 20 метров, то на 1 км их нужно 50. Скорее всего они будут стоять чаще. А если будет 10 км ? Поэтому и древовидная структура. Допустим есть некий контроллер с двумя CAN и одним RS485, Каждый CAN которых покрывает 250 метров и допустим 25 датчиков. Это и есть HUB. Он опрашивает эти 50 датчиков на 500 метрах раз в секунду и получает с них сигнал. Понятное дело что большой поток данных не обеспечить, но я и не думаю что он нужен. Допустим запрос - 2 байта (адрес и тип запроса), ответ 8 байт, получается 500 байт *8 = 4 кБит. Это примерные цифры. Так вот, этот хаб ведет опрос и, в случае появления сигнала, отправляет по RS485 его в PC. Соответственно в обратную сторону с PC команда в хаб, который транслирует его датчикам. Получается 2 хаба на километр - вполне можно повесить на одну RS485 нишу. Дальше наверняка существует что-то типа повторителей (тот же контроллер с двумя RS485), чтобы можно было удлинить сеть. Тут на мой взгляд важен опыт работы с длинными сетями, из которого можно сделать выводы о оптимальной длине, количестве устройств и иерархии. Изменено 9 сентября, 2011 пользователем SanyaKID Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ruslan1 17 9 сентября, 2011 Опубликовано 9 сентября, 2011 · Жалоба Из сугубо личного опыта, CAN очень чувствителен к параметрам линии (и это объяснимо), RS-485 намного дубовей и всеядней. 38400 на несколько километров по нелиниям связи со свистом бегает. Зато у CAN (я говорю про CANopen протокол) стандартизирована атоматическая раздача адресов и автоопределение скорости, вещи очень удобные если часто что-то подключается-переносится. Велосипед не нужен, достаточно реализации стандартного Модбаса с его 256 устройствами на линии. просто хаб это тоже одно из устройств, ему приходит команда- он коммутирует компьютер на нужный луч со своими двумя сотнями точек. Обязательно нужно предусмотреть вторичную проверку, правильно ли произошла коммутация, это можно сделать на уровне пользовательского приложения, не трогая протокол(в контроллере один из Модбас-регистров хранит этот персональный неповторяющийся ID, который всегда спрашивается и присутствует как данные в составе пакета данных принятого от слейва). Применение стандартных технологий дает массу возможностей в будущем, в любой момент можете купить какую-нибудь примочку (ну скажем, выйти на езернет или радио-удлинить какой-нибудь кусок вашей сети). Аппетит придет во время еды и лучше быть к этому готовым :) Насчет все контроллеры(каналы связи)в один порт PC: планируете узкое место в самом дешевом разовом участке сети, в центре. Если можно разложить на порты по скажем максимум 256 устройств на порт, то тот же Модбас вообще без выкрутасов и коммутаторов потянет (правильнее кажется 240 устройств, остальные адреса зарезервированы стандартом). Чем меньше "умных" устройств между центром и сенсором-тем спокойней спать будете. Многопортовка не такая дорогая вещь, а распараллеливание медленных процессов (связь) это всегда хорошо. Крайне не советую делать доморощенный протокол, получится очередная вещь в себе, тупиковая ветвь эволюции. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_3m 4 9 сентября, 2011 Опубликовано 9 сентября, 2011 · Жалоба Допустим есть некий контроллер с двумя CAN и одним RS485, Каждый CAN которых покрывает 250 метров и допустим 25 датчиков. Это и есть HUB. Он опрашивает эти 50 датчиков на 500 метрах раз в секунду и получает с них сигнал. Понятное дело что большой поток данных не обеспечить, но я и не думаю что он нужен. Допустим запрос - 2 байта (адрес и тип запроса), ответ 8 байт, получается 500 байт *8 = 4 кБит. Это примерные цифры. Так вот, этот хаб ведет опрос и, в случае появления сигнала, отправляет по RS485 его в PC. Выбор RS485 как интерфейса PC-HUB никуда не годится. По 485 интерфейсу хаб сам ничего не может послать. Его нужно опрашивать. Вы заткнетесь на стороне PC при масштабировании сети. Интерфейс HUB-PC должен обеспечивать передачу информации как по инициативе PC так и по инициативе HUB. Т.е это либо CAN либо Ethernet. Второе гораздо предпочтительнее. А интерфейс HUB-датчики можете делать на RS485, но это лишь в случае медленных датчиков. Если на срабатывание датчиков надо реагировать быстро - тогда CAN. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
HtLab 0 9 сентября, 2011 Опубликовано 9 сентября, 2011 · Жалоба Делали такое лет 10 назад. На оптически развязанном RS485, скорость от 19200 до 250кБит, с хабами. Протокол был собственноручно изобретен :) Возможно оно еще производится. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
igor_shirokov 0 9 сентября, 2011 Опубликовано 9 сентября, 2011 · Жалоба Необходимо спроектировать и разработать сеть, протокол и ПО для датчиков. Сами датчики разрабатывать не надо. Датчики дают наличие воздействия и его описание. Со стороны PC необходимо получать не только сигнал, но понимать какой из датчиков его выдал. Соответственно датчики должны быть адресными. Кроме того, необходимо управление датчиками (например настройка чувствительности), как по отдельности так и группами. Сеть должна покрывать расстояния от нескольких сотен метров до двух десятков километров. Поэтому требуется хорошая масштабируемость. Исходя из задачи, на данный момент подразумевается древовидная архитектура: PC /......\ HUB HUB /...\ /...\ Д Д Д Д PC - компьютер, собирающий информацию с датчиков HUB - некий коммутатор, за счет которого производится масштабирование. Д - датчик. Уровней Хабов может быть несколько. Под линиями связи пока подразумевается CAN или RS485. Может быть и другая. В будущем датчики должны быть оснащены беспроводным интерфейсом и батарейным питанием и это тоже нужно учитывать. Для решения задач с беспроводным интерфейсом можно использовать например следующую штуку: http://www.kb-mars.ru/products.html Так вот, нам нужен человек, имеющий опыт построения схожих сетей и способный выполнить задачу. Так как архитектуры точной нет, только общие требования, то от кандидата хотелось бы услышать предложения по наиболее оптимальному решению задачи. Офис: Москва, м. Белорусская. Работать можно и не в офисе, но желательно Москва и область, так как нужно будет много общаться и испытывать систему. Пишите на aosurkov(сабака)gmail.com Поясните, какая скорость обмена данными Вас устроит. Паспортная скорость CAN 64 кбод при длине линии до 1 км. Есть ссылки о работоспособности линии CAN до 10 км при скорости 5 кбод. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
LLLLLLLLLL 8 9 сентября, 2011 Опубликовано 9 сентября, 2011 · Жалоба Есть подфорум по умным домам. Для начала почитайте там. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
