Перспективы развития систем СЦБ
 

Уважаемый Николай Николаевич!
Хотелось бы знать мнение ЦШ по вопросам перспективной модернизации и совершенствования аппаратуры СЦБ.
Взять хотя бы кодовую автоблокировку и АЛСН. Им уже более 70 лет! Слава её создателям, но насколько она несовременна - большая потребляемая мощность, механические контакты и помехи, создаваемые ими, недостаточное быстродействие АЛСН, громоздкие дроссель-трансформаторы и т.д. Давно пора уходить от частоты 50 Гц в рельсовых цепях (вспомним аварию на Октябрьской в прошлом году). Промышленность давно уже выпускает сравнительно дешевые преобразователи частоты (DC/DC) о которых и не мечтали в период ламповой техники.
Конечно, на переходной период придется создавать двухсистемную непрерывную локомотивную сигнализацию с установкой дополнительных модулей в КЛУБе. (АЛС-ЕН в сочетании с АЛСН по известным причинам не может быть принята за окончательный вариант).
Другой вопрос - элементная база путевой аппаратуры. Все новые разработки (например, рельсовые цепи тональной частоты) используют те же трансформаторы и дроссели, которые использовались при 50 Гц. А на повышенных частотах их масс-габаритные характеристики и требуемая мощность снижаются. С другой стороны надо увеличивать их электрическую прочность. На мой взгляд, всё, что подключается к рельсам и линиям связи должно выдерживать пробивное напряжение между входом и выходом не менее 30 кВ. Для передачи дискретных сигналов требуются оптроны и высоким пробивным напряжением между входом и выходом и с элементами грозозащиты, для передачи аналоговых сигналов - специальные трансформаторы с разнесенными первичными и вторичными обмотками и также с элементами грозозащиты.
Эти и аналогичные им работы нельзя поручать отдельным разрозненным организациям, они должны жестко координироваться ЦШ.
Имеется еще ряд наболевших вопросов, которые хотелось бы обсудить.

Это верно, модернизация требуеться. Но только на отдельных участках дорог главного хода. К примеру у нас система УСАБ (усовершенствованная система автоблокировки) на участке Краснодар-Новороссийск. Много проблем от неё. Как говорилось ранее, что при новом строительстве будут пускаться новые системы. Я читал в журнале АСИ прошлого года, что планируеться ввести второй путь Краснодар-Крымская, а этот участок 2 категории. Но всё так и затихло. А участок Тимашевская-Крымская который 1 категории также однопутный и с числовой кодовой. Вопрос. Николай Николаевич, возможны изменения на таких сложных участках где большая пропускная способность. И какие системы планируете реализовывать. Спасибо.

Добрый вечер!
Отвечаю без цитирования, поскольку практически все ответы на поставленные вопросы я уже давал и они есть здесь на форуме.
Если коротко: вновь - только автоблокировка с ТРЦ и с централизованным размещением аппаратуры. Как минимум - АБТЦ. Или перспективная (вроде) АБТЦМ-Ш. Или АБТЦ, интегрированная в МПЦ. АЛС - 75 ГЦ на электротяге переменного тока и 75 + 50 ГЦ на автономной тяге и электротяге постоянного тока. На скоростных ходах - АЛС-ЕН. В более серьезной перспективе - RBC и радиоканал GSM-R. Ну и т.д.

Не нашёл подходящую рубрику и изложил всё здесь.
Извиняюсь за вступление, об этом и так все знают, но для полноты рассказа начну с истории.
Гениальные люди изобрели компьютер- устройство, которое работает по программе состоящей из элементарных частей. Высокое быстродействие компьютера и небольшие размеры устройства хранения информации привели к тому, что при помощи компьютера можно легко решать сложные задачи: расчётов, анализа, управления процессами и многое другое. Сложные механические устройства (станки, системы автомобилей: топливная аппаратура, ходовая часть), большие электронные схемы, и другие устройства. Были переведены на управление контролерами, работающими по программе. Это позволило: на порядок снизить стоимость изделий, до минимума уменьшить затраты на модернизацию (путём замены программы), максимально оптимизировать процесс благодаря быстродействию ЭВМ и низкой стоимости (даже полным отсутствием стоимости) программных алгоритмов и максимально упростить сложные изделия. А короче - простой микроконтроллер, получая информацию от датчиков, по сколь угодно сложной программе, управляет исполнительными устройствами. В результате: оптимальный минимум механизмов (самого дорогостоящего, наименее надёжного оборудования), бесконечная возможность вносить изменения в программу работы, неограниченный контроль, архивация процессов, самодиагностика и так далее и простота. Лишний раз подтверждается: всё гениальное просто.
И на конец-то, от «системы блоков и канатов» устройства железнодорожной автоматики перешли на микропроцессорное управление и вроде бы в СЦБ должен наступить рай бесконечного совершенствования: удобства для ДСП, безопасности, надёжности, гибкости, минимализации релейных схем, независимого моделирования всевозможных ситуаций, упрощения понимания реализуемых в программе зависимостей и другого. Я был долго в душе за релейные ЭЦ, но всё таки, как во всём мире уже давно, доказано- за компьютерами будущее.
Относительно ЭЦ- ЕМ.
По странному стечению обстоятельств, всё получилось до крайности наоборот:
• программное обеспечение составляется небольшой группой людей, которые во многом не правы, даже очень во многом
• содержание программы никому недоступно,
• алгоритм работы отслеживается только практическими опытами,
• стоимость изменения ПО несоразмерно дорога,
• существует необоснованная избыточность релейных схем из- за несогласования с ПО,
• внесение изменений в логику производится на уровне релейных схем - это вообще нонсенс.
К примеру, сомнительное, на мой взгляд, внесение изменения в питание рельсовых цепей, касаемо ТРЦ, (указание ГТСС №1683,в нём только логика- реле и БВМШ) реализуется на релейных схемах, а зачем вообще тогда надо было делать ЭЦ- ЕМ?! Проекты ЭЦ- ЕМ не анализируются составителями ПО, что приводит к появлению риска нарушения безопасности движения поездов. А я считаю, что только они должны сверять релейные схемы с программой.
Опять пример: из- за этого только чудом удалось избежать аварии на переезде. В схеме управления, которого по проекту релейных схем было заложено одно интерфейсное реле извещения, а в ПО предусмотрены два канала чётное и нечётное извещение (то есть должно было стоять два интерфейсных реле, контакты которых включаются последовательно в цепь извещения). Можно сказать, что виноваты проектировщики релейных схем, но я считаю, что виновата ситуация с программным обеспечением.
Ещё один нонсенс- на участке реконструкции производилось изменение путевого развития, добавление стрелок, путей на станциях и перегонах с включением АБТЦ на перегонах , замена релейных ЭЦ станций на ЭЦ- ЕМ. По этапам реконструкции всё изменение путевого развития делалось на старых релейных ЭЦ, а потом на окончательное путевое развитие включалась ЭЦ- ЕМ. Меня просто коробит этапность- изменение путевого развития в релейных ЭЦ, а без изменённое в ЭЦ- ЕМ.
Кто врезал стрелки, менял маршруты в БМРЦ знает чем это даётся. В окно: перепайки сделали, когда позволила поездная обстановка разобрались с косяками, своими, строителей и проектировщиков, проверили чтобы всё заработало и в лучшем случае минимально проверили на безопасность. А бывает, что к концу окна ничего не работает и … После этого подписываешь проверочные таблицы, а на душе обидно, так много хочется сказать тому кто эти таблицы составил и переложил с себя ответственность. А вы е-сь как хотите, но что бы всё было подписано. Все знают как надо, но мало кто знает- а возможно ли так?!
А вот собственно нонсенс- на окончательное путевое развитие включается ЭЦ- ЕМ. В котором для изменения путевого развития, переноса, добавления или исключения стрелок, включения сигналов, рельсовых цепе в релейной перепаивать в окно НИЧЕГО НЕ НАДО. Поднял напольные устройства, без этого по любому не обойтись, заменил ПО, проверенное на тестирующем комплексе и всё поехали. Безопасность на высоте, задержки в минимуме и всех одолевает гордость за достижения научного прогресса. Это самая гибкая система, все риски при переустройстве сведены к минимуму.
Почему так не делается- дорого менять ПО. Добавление 24 стрелок к 60- ти стоит 40 000 000 рублей, это только ПО . Парадокс- дорого то, что вообще ничего не должно стоить. Эх, узнал бы Бил Гейтц об этом, со стула бы рухнул и в ГТСС побежал бы работать, вот там деньги. Я бы сам за эти деньги всё ЭЦ (ЭЦ-12) запроектировал и целиком релейную собрал бы, даже две для надёжности.
Можно смело проверять то, что знаешь как работает. К примеру, можно после покупки велосипеда проверить:
• работают ли тормоза, при этом нужно чтобы не заклинивал передний тормоз
• были надёжно прикручены колёса, руль, сидение
• стоял щиток на цепь
• работал бы звонок, ну и прочее
На этом успокоится и отдать велосипед ребёнку. Ну а представьте, что вы не ведаете об устройстве этого велосипеда и предполагаете что он такой же как и все, которые были у вас в детстве. А на самом деле велосипед складной, с мотором, с крыльями и катапультой, вам просто об этом не сказали. Это я к тому, что есть общие требования к системам ЭЦ их обязательно надо проверять, но дополнительно должны быть проверки исходя из конструктивных особенностей каждой системы. То есть нельзя проверять программу как релейную ЭЦ. В релейных ЭЦ очень затруднительно в день Х сделать что- либо, а в программе проще простого и никто не заметит, пока не настанет день Х. Стоит задуматься о том, что бы аннулировать проверки всех программ ЭЦ- ЕМ. Нам конечно проще, мы таблицы заполнили.
О чём я мечтаю.
• разрабатывается язык программирования для ПО микропроцессорных ЭЦ, который преподают даже в техникумах
• программное обеспечение становится общедоступным, его все знают, изучают, вносят предложения, меняют в связи с новыми требованиями, недостатками и прочими пожеланиями
• любое изменение путевого развития сопровождается заменой ПО (относительно описанного выше случаю реконструкции: сначала включаем ЭЦ- ЕМ, а потом меняем путевое развитие с наименьшими рисками)

Давайте идти цивилизованно в ногу со временем, а не смотреть на ЭЦ- ЕМ как на дорогую, малопонятную систему и лишь бы работала, мы в стороне постоим.
Не знаю, как обстоит дело с ПО других систем МПЦ и РПЦ, но знаю точно, что с ситуацией «кто во что горазд» надо покончить раз и навсегда. Процессоры ЭВМ отличаются набором команд, но базовые команды одни и те же. А поэтому все системы могут работать по одной программе, осталось разработать или взять наиболее подходящую за основу.
Может, у кого есть по этому поводу мнение? Было бы интересно и ЦШ послушать.

Добрый вечер!
Не берусь сразу дать развернутый ответ, но выскажусь по некоторым моментам.
Первое - про этапность. Убежден, что делать нужно именно так - еще в рамках "старой" системы реализовывать все этапы переустройства путевого развития и только на окончательное путевое развитие включать "новую" систему. Старая - свое уже отжила, а новой - работать несколько десятков лет, и курочить её с момента рождения - недопустимо. Бояться процедуры переустройства "старой" системы - не стоит, нет там ничего такого уж сверхсложного. Подготавливать этапы должным образом - это незыблемо, тогда и переключения промежуточные пройдут без проблем.
Второе - про ПО. Категорически не согласен с тем, чтобы "каждый" умел писать/изменять ПО. Иначе все свалится на эксплуатационников, что в принципе неверно. В примитивных - МКУшных и первых (относительно простых) релейных системах - это не создавало каких-то особых проблем, да и законы были другие (и страна другая). Но - по мере повышения функциональности (и сложности) релейных систем - это стало вполне ощутимой проблемой, когда директивой руководителя эксплуатирующую организацию заставляют "кроить" ЭЦ "по живому" - без проектировщиков, без строителей, в действующих устройствах, под колесами. Кто-нибудь может представить, чтобы в промышленности, например, на каком-нибудь заводе начальник цеха вместе со своим коллективом работников без проекта и без строителей перестраивает цех, надстраивает этаж и т.п.? Нет, конечно! А в СЦБ - так это сложилось, а мы и не заметили - запросто. И от беды всех нас спасало (и до сих пор спасает) - наглядность реализации зависимостей, возможность глазами (и приборами конечно) увидеть - "под током" или "без тока". Но - неправильно это!!! Все реконструкции, включая демонтажи, должны проектироваться проектировщиками, строиться строителями, вводиться в эксплуатацию - соответствующими структурами (ДКСС например) и в готовом виде передаваться балансодержателю на обслуживание. В релейных системах - а мы их уже практически не строим - новый порядок наверное уже не установить, но в принципиально новых, в МПЦ/РПЦ - нужно стремиться это сделать. Как это делается во всех цивилизованных странах.
А если "каждая кухарка" будет лезть в ПО - беды не избежать, рано или поздно кто-то ошибется, а ПО - это БМРЦ, ПО сколько не проверяй - до конца никогда не проверишь. Поэтому - только ответственность автора!

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

да комплектующие там копейки стоят по сравнению с конечной стимостью системы

Изменение путевого развития в ЭЦ- ЕМ не оставит и следа, всё будет сделано в программном обеспечении. Я много старых ЭЦ перелопатил, мне это нравится. Но простота изменения путевого развития в ЭЦ-ЕМ, не скупясь на выражения- совершенна, никакой пайки и все таблицы заполнены по чесноку.
А я и не предлагаю каждому вносить изменения в ПО. Посмотреть релейные схемы может каждый и что- нибудь предложить, а программа недоступна для анализа. И в добавок имеется тестирующий комплекс, для проверки зависимостей, и по принятой системе «безопасности» некорректные изменения кухарки не пройдут. Вот только систему проверять надо не только по канонам СЦБ, а исходя из особенностей реализации зависимостей в ПО.

Копейки стоят комплектующие, извините за выражение, гавно(в основном для ширпотреба) А качественные ,надежные(даже китайские) стоят ох как недешево! Да еще все это собрать и настроить в больших объемах будет проблематично.Если уж браться капитально, то без своей базы не обойтись.

Доброе утро!
Даже не верится, что сам ЦШ отвечает на моё сообщение. Уважаемый Николай Николаевич, мне всегда интересно читать ваши комментарии, они по теме и очень грамотные. Но Вы меня не поняли.
Ответственность автора ПО отсутствует. Автор написал программу, а мы должны её проверить, ни чего не выявили- сами виноваты.
В релейных схемах 95% ошибок нашёл при анализе схем и никогда за это проектировщиков не ругал. Анализировать схемы- это интересно, а когда ошибку найдёшь, тогда такой подъём ощущаешь- так и работал бы анализатором. Я вообще предлагаю вносить в проекты сознательно 3 ошибки и не сообщать в ШЧ об этом. Перед пуском/переключением проверять найдены ли ошибки, если нет то значит к пуску не готовились, схемы не смотрели- окно отменить. Энтузиазма анализировать схемы будет в 100 раз больше, а это залог успешного переключения.
Ну собственно об анализе ПО, ввиду того что он, с нашей стороны отсутствует, а типовыми проверками ничего не выявляется, все ошибки проявляются в эксплуатации и потом мы разводим руками, от безсилия. При таком подходе я против МПЦ, только релейным схемам могу доверять.
Вот примеры:
• Перевод охранной стрелки под вагоном на Гатчине Товарной Балтийской, после этого оказалось , что эта же ошибка есть и на других станциях
• Когда поезд, идущий на проход, вступал на путь станции, прекращалась подача извещения на переезд расположенный в горловине. Сообщил путеец с вытаращенными глазами- всем повезло программу быстро заменили.
• На этой же станции, контроль переезда выведен на картинку перегонов на АРМ ДСП и при неисправности на переезде картинка станции не как не меняется, хорошо, что у ДСП три рабочих места, так теперь на одном работает, а на другом перегон открыт из- за одного переезда.
• Так же переезд в нечётной горловине, маршрут по боковому пути, поезд, чётный, идёт на проход с установленной скоростью, проезжает выходной сигнал и только после этого на переезд подаётся извещение, а до него поезду 100 метров ехать. На наше и ДСа счастье, что переезд сделали охраняемым и мы сразу узнали об извещение. Разбираемся в ситуации, в ТВЗ в разделе переезд на такой маршрут : извещение подаётся с от вступления на путь, в графе задержки на подачу извещения прочерки. Ребята из ГТСС эти прочерки трактовали по своему и включили задержку на подачу извещения из расчёта раз путь не предназначен для пропуска поездов, а только для приёма и отправления то поезд сначала должен прибыть на путь, а потом тронуться. В итоге 115 секунд задержки. Поезд за меньшее время не спешно проезжает по пути, а у нас задержка на подачу извещения. Пришлось долго объяснять движкам, что есть пути для пропуска поездов, а есть для приёма и отправления. Не вдаваясь в нарушения ДСП по пропуску поездов спрашиваю, а как мы такое допустили у нас столько защит от неправильных действий, а здесь такое !? И главное, что теперь так на станции и будет. Один выход движкам накопить миллионов десять рублей и пойти в ГТСС попросить убрать эту самодеятельность из ПО.
И сколько всего ещё может быть скрыто в ПО, одному … известно. Я понимаю, что мало желанья менять то, что вроде бы и так работает. Но на мой взгляд эта дорога очень скользкая.

Добрый день!
Скажу сразу - вот чего я не знаю в СЦБ, так это ПО...
По Вашим примерам. Не умаляя вины/ответственности разработчиков ПО - разве на стадии пусконаладки ВСЕ вами указанные ляпы не должны были быть выявлены и устранены? Разве мы не умеем все это проверять на макете? Это ведь уже вопросы не столько к ним, сколько к нам!
Мысль, появившаяся в моей голове после осмысления Ваших слов - может быть с учетом особенностей МПЦ нам существенно усложнить таблицу взаимозависимостей? Детализировать все ключевые моменты алгоритмов? Можно подумать и пообсуждать...

да!!!!!!!!!!!
Вячеслав Юрьевич, считайте, что три ошибки были сделаны сознательно :lol::lol::lol:
нет!
тогда надо проектировщикам научиться писать ПО :maniak:

БЕЗ АНАЛИЗА ПРОГРАММЫ НЕЛЬЗЯ СОСТАВЛЯТЬ ПРОВЕРОЧНЫЕ ТАБЛИЦЕ И ВООБЩЕ ЧЕГО- ЛИБО ПРОВЕРЯТЬ. Усложнением проверок ничего не решишь, мы заложники ситуации. Все описанные ошибки не типичны для релейных ЭЦ их невозможно предсказать. То что в ПО делается в двух строках, в релейной может привести к появлению целого статива.
Я в 6-ом классе собрал синклер- это компьютер в корпусе клавиатуры с записанным в постоянное запоминающее устройство языком программирования Бейсиком. И сам по небольшой книге составлял программы, одна из них представляла игру: летит самолёт и сбивает препятствия. Конечно же, без красивой графики. Я это к тому что всё зависит от качества представления программы, если это машинный код- то всё сложно, а если при помощи машинного кода составлен язык программирования, то всё гораздо проще. Тем кто изучил БМРЦ на изучение элементарных основ программирования, а в ПО МПЦ большего быть не должно, понадобится не больше недели.

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

Антон Евгеньевич,
Вы видели написаное ПО???
о чем Вы говорите...
больше всего слово "бред" подходит...