СЦБИСТ - железнодорожный форум, блоги, фотогалерея, социальная сеть
Это сообщение показано отдельно, перейти в тему, где размещено сообщение: Переход на ОС с открытыми кодами (Linux)
Старый 14.12.2017, 21:44   #668 (ссылка)
__
 
Аватар для Николай Николаевич

Регистрация: 10.09.2010
Адрес: Москва
Возраст: 64
Сообщений: 13,931
Поблагодарил: 408 раз(а)
Поблагодарили 2364 раз(а)
Фотоальбомы: не добавлял
Репутация: 1516
Цитата:
Сообщение от Просто инженер АиТ Посмотреть сообщение
В БМРЦ нет обобщающего блока. В предлагаемом варианте ОК работают все вместе, например, находясь на общей шине обмена (например, всеми любимой CAN шине) и могут обмениваться информацией между собой, без участия ведущего блока (никто же не говорил, что должен быть только один порт (имеется ввиду физический порт) для связи). Более того, понадобится ещё один порт для технологической связи, для диагностики (для проверки, настройки и технологического тестирования ОК) и связи СТДМ (можно, конечно, весь обмен организовать по одному порту, но это будет неудобно). Можно работать по одному порту, но в разных протоколах (правда, не все такое умеют программировать!), да и зачем, если без проблем можно добавить физический порт, сейчас стоимость железа достаточно низкая.
Как бы Ваши ОК не обменивались информацией, где-то, в каком-то месте должно быть решающее устройство, которое скажет: трасса маршрута свободна, можно переводить стрелки в требуемое положение. А до этого - получить от ДСП заявку - хочу маршрут от светофора А до светофора Б. А еще до этого - проверить, что в этот момент времени не переводятся стрелки для установки другого маршрута. И так далее.
Я понимаю, что физически можно сделать подобную схемотехнику и на электронной элементной базе - только "конфетки" во всем этом я не вижу! Будет "блочная электронная БМРЦ", еще менее надежная, чем релейная.
Николай Николаевич вне форума   Цитировать 0
 Нажмите здесь, чтобы написать комментарий к этому сообщению  
 

Яндекс.Метрика