Прошу прощения за столь поверхностный и не точный ответ в предыдущем посте (не было времени найти документы, чтобы сослаться). Информация с перегонных контроллеров снимается событийно, с небольшой задержкой для «устаканивания схемы». Информация с ЛП на сервер приходит по запросу сервера. Фиксированного времени в 5с/цикл нет.
Не зафиксированные состояния могут быть. Время между циклами опроса плавающее очень зависит от качества канала связи и, конечно, от количества станций. Расчет времени цикла есть в учебном пособии «Микропроцессорная диспетчерская централизация «Каска» Харьков 2005, стр.163.
Кроме попадания данной занятости в интервал между опросами могут быть еще варианты:
1) в Каскад занятость этого участка снимается с повторителя, который срабатывает позже чем тот, через который идет индикация на пульт и этот повторитель не успел отработать (вероятность ничтожно мала);
2) пакет с этим изменением не прошел по каналу, или пришел повреждённый. Когда был сформирован второй пакет, секция уже была свободна и, соответственно, получилось «выпавшее» состояние.
Если скажете какая станция, могу рассчитать теоретический интервал между опросами для Вашей станции.

Программист добавил 21.01.2014 в 13:46
А могу посмотреть реальное количество пришедших, не пришедших или пришедших , но повреждённых пакетов, сервер ведёт статистику

Программист , а каким образом идет сбор информации о ОК если на станции МПЦ ?
.....................................

Часом не через RS-485 к которому подключается СК-2202?

Rafa, Вы правы частично. Наверно не довелось Вам побывать на этом участке, поэтому не видели что ЛП увязки с МПЦ/РПЦ отличается от привычного Вам ЛП «Каскад». При увязке с российскими МПЦ, ни Радиоавионика, ни Бомбардье не захотели увязываться по Ethernet. Увязка ЭЦ-ЕМ — Каскад «проводами» и на нижнем уровне по RS-485, на верхнем уровне программно мы «закосили» под ДЦ «Сетунь», у ЭЦ-ЕМ был готов модуль увязки под данное ДЦ. В Бомбардье сказали, что протокол ДЦ «Сетунь» неудачный (это если очень мягко) и попросили программно «закосить» под «Диалог». Нижний уровень тот же RS-485. А вот с КС-МИСАТ мы увязались по Ethernet. Аппаратно с нашей стороны во всех 3 случаях индустриальный х86-компьютер.

Там есть такой интересный момент, что пакет сигнала ТС растет по мере дохода к ЦП пройдя через промежуточные ЛП (добавляется сигнал ТС промежуточных ЛП).

Так ли это в реале ? Ведь как Вы говорите, конкретный ЛП начинает передавать на ЦП сигнал ТС лишь только по запросу ЦП.

Так как в книге написано. Сервер определяет какую станцию "дёрнуть" чтобы собрать всю "цепочку" аж до себя.

О, фоточки, а я пока станции отлаживал, даже не пофотографировал.

Меня тоже этот вопрос интересует. Или запрос всегда посылается на самый дальний ЛП и каждый ЛП в цепочке дописывает к передаваемому пакету свою информацию?

И еще вопрос, по описанию используется 2 пары магистрального кабеля. А на фотках видно что на станции в модемы воткнуто 4 шнурка, т.е. 4 пары. Это резервирование или 4-х проводное подключение или ответственные команды передаются по 2м каналам?
Станции в кольцо действительно включаются через одну?

И последнее. Если ЛП территориально сильно удалены от ЦП (точнее АРМов, которые будут в ЕДЦУ, ну например 300-400 км) то как обеспечивается связь? Сервер базы данных ставится на участке или возле АРМов? В структуре СЕТУНи все понятно, там есть РС связь. А у вас?

То о чём мы общались с Rafa, касается релейных постов ЭЦ и аналоговой связи между ними. На фотографиях выше показаны шкафы увязки с МПЦ. Там вообще нет модемов. Желтые провода это оптика и приходит она в медиаконвертер.
На счет территориального удаления, не совсем понял в чем вопрос. В любом случае, даже если управляется одной станцией, есть сервер, его исполнение не обязательно 19'' стойка. Ставится где найдут место, естественно с ограничениями на каналы связи, для аналоговых линий оно одно, для оптики другое, для цифровых линий третье. От сервера уже можно растягивать рабочие места куда вам заблагорассудится, лишь бы временные ограничения на прохождения ТС/ТУ выдерживались. Мы, в подавляющем большинстве случаев, используем связь которая уже есть у ШЧ, иногда используются ресурсы(сеть) вычислителей. Сервер базы, обычно, находится на сервере участка. В УЗ видят все участи, где есть Каскад и стартовая страничка у них начинается с карты Украины(постараюсь завтра выложить, если не получится — чур не пинать).

.

Да, меня именно это и интересовало.
Извиняюсь что задал вопрос по фото, которое здесь не приводилось. Просто решил что на всех ЛП с аналоговыми модемами подключение одинаково, хотя вот даже у себя на фото нашел и с 4-мя и с 6-ю линиями связи. Вот фото.
http://morepic.ru/thumbs3/lp1_7033.jpg http://morepic.ru/thumbs3/imga0455_9639.jpg
Так что вопрос про количество пар и их назначения остается в силе. На одной плате 2 модема? А разъемов RJ11 - 4 шт.? Для 2-х и 4-х проводного подключения или как?

Вот вопрос как раз в этих ограничениях. Согласно структуры, приведенной в учебном пособии к серверу с одной стороны подключаются ЛП через аналоговые модемы с ограничение дальности 40км. С другой стороны по Ethernet АРМы с ограничением 100м (ну пусть несколько промежуточных свичей - несколько сот метров). Можно, конечно удаленные АРМы подключать по SDSL модемам, но и скорость ниже и дальность несколько км. Вот и выходит что с этой структурой от ДНЦ до ЛП максимум 40 с небольшим км. А если больше? (диспетчера в ЕДЦУ), то тянем дальше ТУ/ТС?, или сервер на участке, а АРМы к нему по высокоскоростным каналам передачи данных типа оптики?, или сервер в ЕДЦУ, а на участке только промежуточный компьютер с модемами транслирующий ТУ/ТС с модемов в скоростной канал (как в Сетуни)?
Я не знаю какой объем информации циркулирует между АРМами и сервером. Превышает ли он объем между сервером и ЛП и потому пытаюсь выяснить что выгоднее ставить сервер ближе к участку или к рабочим местам.
Непонятно выражение "сервер участка". Это тоже что и сервер базы данных или нет?

P.S. Интересуюсь в учебных целях.

Впервые такую карту я увидел в далеком году так 1996. Харьковское НПП ТАИС разрабатывало (с 1993(94) года первую украинскую МП ДЦ ТЕМП и концепцию Автоматизированной системы управления перевозками по железным дорогам Украины. Начинали все под ДОСом на 14" мониторах с EGA (даже не VGA) разрешением 640х350, так что качество картинки не очень, но многие интересные идеи до сих пор не реализованы. Могу выложить полную powerpoint презентацию "Автоматизированная система управления перевозками по железным дорогам Украины". 1998 год. 180 слайдов. 164 Мб без английского варианта (он еще мег 40), 40 мин показа в автоматическом режиме (нудновато, надо запускать в режиме ручной смены слайдов).

http://morepic.ru/images3/temp1_2671.gif

http://morepic.ru/images3/temp2_9992.gif

http://morepic.ru/images3/temp3_2482.gif

http://morepic.ru/images3/temp4_4502.gif

http://morepic.ru/images3/temp5_1435.gif

Какие топологии сети вы поддерживаете? Спасибо.

Добрый день. Для начала обещаное:Вложение 10169

что-то не так сделал, и фотка мутная, но идею вы поняли

Программист добавил 22.01.2014 в 14:15
Теперь по порядку: micush, ваши фота, скорее всего, с участка Джанкой-Вадим. Это был первый участок и там использовалась схема двух каналов. Эта схема требовала 4 модемов, но уже на следующем участке от неё отказались и стали использовать «кольцо». Если я не ошибаюсь, когда запускали участок Джанкой-Керч, производили обновление участка Джанкой-Водим и переделывали схему связи на кольцо. Теперь везде стоит один модемный модуль в котором только 2 порта RJ11. Теперь на счёт вставленных 3 пар в одну плату: там была возможность параллельно «стать трубкой» или еще чем и послушать что творится в канале. То есть 2 RJ11 параллельно сидит на одном канале. Позже это убрали.

Теперь на счёт расстояний: В действительности «пробить» 40км аналоговыми модемами и получить приличную скорость, на существующем кабельном хозяйстве, практически невозможно. Есть сервер участка — железяка, которая занимается сбором информации с ЛП, обработкой этой информации, ведением базы, управляет поездным процессом, прогнозирует движение поездов и выдаёт информацию клиентам. Для ясности, «сервер участка» - программно-аппаратный комплекс, как правило помещается в одной 19'' стойке. Состоит из шкафа, в который вставлен сервер, монитор, клавиатура, УБП, и аппаратура связи (аналоговая стойка, DSL-стойка, коммутатор Ethernet). Назван так, потому что собирает информацию с участка или нескольких участков. Участок — обычно до 20 станций. Этот сервер ставится недалеко от ЛП какой-нибудь крупной станции (максимум что могу вспомнить это пару км, хотя на него распространяются такие же ограничения как и на ЛП, просто не было необходимости). А дальше от сервера к клиентам у нас сеть TCP/IP. Тут уже смотрим кто ближе 100м — то Ethernet, если чуть дальше можем свич поставить, если надо подключить 1-4 клиента в другом здании обычно используем DSL, можем оптику, если выделят. Сервера между собой связаны оптическими каналами. Если стоит задача удалённо подключить, например, 20 клиентов, то можно поставить сервер, назовём его связевым (чисто условно, т.к. он не занимается сбором информации с поля), который будет обслуживать этих клиентов, а можно просто поставить коммутатор. В него притянуть оптику, и к нему подключить клиентов. Тут на что заказчик согласится. Свич стоит несколько тис. грн, а сервер с ящиками, УБП и тд. уже за 20 тыс.грн может перевалить. В каждом конкретном случае поступаем индивидуально, учитывая желание заказчика. В Каскаде нет отдельной «железяки», которая бы писала только базу. Выделить можно, не видим смысла раздувать количество аппаратуры.

В своё время при создании системы АСДК (не доделанная ДЦ) для уменьшения времени реакции, мы отказались от циклического опроса ЛП (кроме того низкая надёжность, остановка сервера и участок встал). Информация с ЛП о ТС передавалась спорадически по мере возникновения изменения состояния объектов и по регламенту или запросу от сервера о всех объектах ЛП (тафик резко снижался, так, например, информацию о 120 станциях мы могли передать со скоростью 57 кбит, при этом ряд станций были с числом объектов более 1024, время доставки не более 5с). Информация с ЛП передавалась по различным путям (кольцевание), дополнительные пути или среды, в ПО сервера забиралось только первое сообщение (не путайте с сообщениями TCP, в сообщении TCP могло быть несколько сообщений ТС (некоторых системах такие сообщения называются - кадрами (АСК ПС))) от ЛП, от остальных путей доставки уничтожалось, таким образом надёжность доставки резко возрастала.
И ещё, как правило, сообщения(кадры) ТС небольшие, поэтому при передаче по TCP сообщения(кадры) упаковались в пакет, и на оборот при передаче по модемным ненадёжным каналам сообщения делились на блоки (размер блока вычислялся в зависимости от качества обмена), после приёма блоки собирались обратно в сообщения. Контроль доставки велся на уровне точка-точка, если была ошибка, то передача повторялась не более 3 раз, в противном случае информация устаревала и создавала лишний напряг обмена, за счёт резервирования информация не терялась.
Эх, дела давно минувших лет. :hmm:

В "кадрах" с ЛП были какие-то счётчики-маркеры, чтобы отлечить какой из пакетов более новый. Например произошло событие (таже ситуация занятие секции) допустим в 00:00:01, кадр №1 сформеровали и он ушел. В 00:00:02 секция освободилась, еще один кадр №2 ушел. На принимающей стороне (если есть различные пути, значит есть различное время прохождения кадров) приходит кадр №2 и через 0,1с кадр №1. Как решалась это проблема? Спрашиваю как говорил "почтальён Печкин": "С целью повышения образованности".