СЦБИСТ - железнодорожный форум, блоги, фотогалерея, социальная сеть
Вернуться   СЦБИСТ - железнодорожный форум, блоги, фотогалерея, социальная сеть > Обратная связь, новости, СМИ > ЦШ ОАО "РЖД" - обратная связь

Ответ   m.scbist.com - мобильная версия сайта  
 
В мои закладки Подписка на тему по электронной почте Отправить другу по электронной почте Опции темы Поиск в этой теме
Старый 28.02.2011, 00:11   #1 (ссылка)
Новичок


Регистрация: 27.11.2010
Сообщений: 11
Поблагодарил: 7 раз(а)
Поблагодарили 0 раз(а)
Фотоальбомы: 0
Репутация: 0
По умолчанию

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


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


Регистрация: 26.03.2011
Адрес: г.Крымск, Краснодарский край
Сообщений: 46
Поблагодарил: 2 раз(а)
Поблагодарили 3 раз(а)
Фотоальбомы: 0
Репутация: 0
По умолчанию

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


Регистрация: 10.09.2010
Адрес: Москва
Возраст: 59
Сообщений: 13,792
Поблагодарил: 399 раз(а)
Поблагодарили 2307 раз(а)
Фотоальбомы: 0
Репутация: 1470
По умолчанию

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


Регистрация: 26.11.2010
Сообщений: 30
Поблагодарил: 1 раз(а)
Поблагодарили 5 раз(а)
Фотоальбомы: 0
Репутация: 0
По умолчанию

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

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

Последний раз редактировалось Admin; 25.05.2012 в 22:00. Причина: Добавлено сообщение
Антон Евгеньевич вне форума   Ответить с цитированием 0
Поблагодарили:
Anatoly (19.07.2015), anscb (16.10.2012)
Старый 25.05.2012, 21:53   #5 (ссылка)
__


Регистрация: 10.09.2010
Адрес: Москва
Возраст: 59
Сообщений: 13,792
Поблагодарил: 399 раз(а)
Поблагодарили 2307 раз(а)
Фотоальбомы: 0
Репутация: 1470
По умолчанию

Добрый вечер!
Не берусь сразу дать развернутый ответ, но выскажусь по некоторым моментам.
Первое - про этапность. Убежден, что делать нужно именно так - еще в рамках "старой" системы реализовывать все этапы переустройства путевого развития и только на окончательное путевое развитие включать "новую" систему. Старая - свое уже отжила, а новой - работать несколько десятков лет, и курочить её с момента рождения - недопустимо. Бояться процедуры переустройства "старой" системы - не стоит, нет там ничего такого уж сверхсложного. Подготавливать этапы должным образом - это незыблемо, тогда и переключения промежуточные пройдут без проблем.
Второе - про ПО. Категорически не согласен с тем, чтобы "каждый" умел писать/изменять ПО. Иначе все свалится на эксплуатационников, что в принципе неверно. В примитивных - МКУшных и первых (относительно простых) релейных системах - это не создавало каких-то особых проблем, да и законы были другие (и страна другая). Но - по мере повышения функциональности (и сложности) релейных систем - это стало вполне ощутимой проблемой, когда директивой руководителя эксплуатирующую организацию заставляют "кроить" ЭЦ "по живому" - без проектировщиков, без строителей, в действующих устройствах, под колесами. Кто-нибудь может представить, чтобы в промышленности, например, на каком-нибудь заводе начальник цеха вместе со своим коллективом работников без проекта и без строителей перестраивает цех, надстраивает этаж и т.п.? Нет, конечно! А в СЦБ - так это сложилось, а мы и не заметили - запросто. И от беды всех нас спасало (и до сих пор спасает) - наглядность реализации зависимостей, возможность глазами (и приборами конечно) увидеть - "под током" или "без тока". Но - неправильно это!!! Все реконструкции, включая демонтажи, должны проектироваться проектировщиками, строиться строителями, вводиться в эксплуатацию - соответствующими структурами (ДКСС например) и в готовом виде передаваться балансодержателю на обслуживание. В релейных системах - а мы их уже практически не строим - новый порядок наверное уже не установить, но в принципиально новых, в МПЦ/РПЦ - нужно стремиться это сделать. Как это делается во всех цивилизованных странах.
А если "каждая кухарка" будет лезть в ПО - беды не избежать, рано или поздно кто-то ошибется, а ПО - это БМРЦ, ПО сколько не проверяй - до конца никогда не проверишь. Поэтому - только ответственность автора!
Николай Николаевич вне форума   Ответить с цитированием 0
Поблагодарили:
anscb (16.10.2012), Евгений002 (26.05.2012)
Старый 25.05.2012, 22:43   #6 (ссылка)
Super V.I.P.


Регистрация: 18.05.2012
Сообщений: 2,088
Поблагодарил: 642 раз(а)
Поблагодарили 1771 раз(а)
Фотоальбомы: 0
Репутация: 700
По умолчанию

Всё это возможно только на импортных комплектующих(наша промышленность на данный момент не сможет обеспечить качественных аналогов) А без отечественного производства(пусть даже совместного) эти приборы станут дороже чугунного моста. Плюс контроль за производством процессоров(непонятные ошибки,всевозможные закладки)
Balbes вне форума   Ответить с цитированием 0
Старый 25.05.2012, 22:50   #7 (ссылка)
Crow indian
 
Аватар для Admin


Регистрация: 21.02.2009
Возраст: 39
Сообщений: 26,660
Поблагодарил: 393 раз(а)
Поблагодарили 5611 раз(а)
Фотоальбомы: 2570
Записей в дневнике: 424
Репутация: 126067
По умолчанию

Цитата:
Всё это возможно только на импортных комплектующих(наша промышленность на данный момент не сможет обеспечить качественных аналогов) А без отечественного производства(пусть даже совместного) эти приборы станут дороже чугунного моста
да комплектующие там копейки стоят по сравнению с конечной стимостью системы
__________________
Если не можете скачать файл... / Наше приложение ВКонтакте / Какими программами открывать скачанное? | Распоряжения 1
Admin вне форума   Ответить с цитированием 12
Старый 25.05.2012, 23:39   #8 (ссылка)
Участник


Регистрация: 26.11.2010
Сообщений: 30
Поблагодарил: 1 раз(а)
Поблагодарили 5 раз(а)
Фотоальбомы: 0
Репутация: 0
По умолчанию

Изменение путевого развития в ЭЦ- ЕМ не оставит и следа, всё будет сделано в программном обеспечении. Я много старых ЭЦ перелопатил, мне это нравится. Но простота изменения путевого развития в ЭЦ-ЕМ, не скупясь на выражения- совершенна, никакой пайки и все таблицы заполнены по чесноку.
А я и не предлагаю каждому вносить изменения в ПО. Посмотреть релейные схемы может каждый и что- нибудь предложить, а программа недоступна для анализа. И в добавок имеется тестирующий комплекс, для проверки зависимостей, и по принятой системе «безопасности» некорректные изменения кухарки не пройдут. Вот только систему проверять надо не только по канонам СЦБ, а исходя из особенностей реализации зависимостей в ПО.
Антон Евгеньевич вне форума   Ответить с цитированием 0
Старый 26.05.2012, 08:19   #9 (ссылка)
Super V.I.P.


Регистрация: 18.05.2012
Сообщений: 2,088
Поблагодарил: 642 раз(а)
Поблагодарили 1771 раз(а)
Фотоальбомы: 0
Репутация: 700
По умолчанию

Цитата:
да комплектующие там копейки стоят по сравнению с конечной стимостью системы
Копейки стоят комплектующие, извините за выражение, гавно(в основном для ширпотреба) А качественные ,надежные(даже китайские) стоят ох как недешево! Да еще все это собрать и настроить в больших объемах будет проблематично.Если уж браться капитально, то без своей базы не обойтись.
Balbes вне форума   Ответить с цитированием 0
Старый 26.05.2012, 10:37   #10 (ссылка)
Участник


Регистрация: 26.11.2010
Сообщений: 30
Поблагодарил: 1 раз(а)
Поблагодарили 5 раз(а)
Фотоальбомы: 0
Репутация: 0
По умолчанию

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


Регистрация: 10.09.2010
Адрес: Москва
Возраст: 59
Сообщений: 13,792
Поблагодарил: 399 раз(а)
Поблагодарили 2307 раз(а)
Фотоальбомы: 0
Репутация: 1470
По умолчанию

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

И сколько всего ещё может быть скрыто в ПО, одному … известно. Я понимаю, что мало желанья менять то, что вроде бы и так работает. Но на мой взгляд эта дорога очень скользкая.
Добрый день!
Скажу сразу - вот чего я не знаю в СЦБ, так это ПО...
По Вашим примерам. Не умаляя вины/ответственности разработчиков ПО - разве на стадии пусконаладки ВСЕ вами указанные ляпы не должны были быть выявлены и устранены? Разве мы не умеем все это проверять на макете? Это ведь уже вопросы не столько к ним, сколько к нам!
Мысль, появившаяся в моей голове после осмысления Ваших слов - может быть с учетом особенностей МПЦ нам существенно усложнить таблицу взаимозависимостей? Детализировать все ключевые моменты алгоритмов? Можно подумать и пообсуждать...
Николай Николаевич вне форума   Ответить с цитированием 0
Старый 26.05.2012, 11:22   #12 (ссылка)
))
 
Аватар для Sama Y


Регистрация: 22.02.2010
Адрес: Екатеринбург
Сообщений: 2,521
Поблагодарил: 2228 раз(а)
Поблагодарили 1348 раз(а)
Фотоальбомы: 0
Записей в дневнике: 6
Отправить сообщение для Sama Y с помощью ICQ
По умолчанию

Цитата:
Я вообще предлагаю вносить в проекты сознательно 3 ошибки и не сообщать в ШЧ об этом.
да!!!!!!!!!!!
Вячеслав Юрьевич, считайте, что три ошибки были сделаны сознательно
Цитата:
может быть с учетом особенностей МПЦ нам существенно усложнить таблицу взаимозависимостей? Детализировать все ключевые моменты алгоритмов?
нет!
тогда надо проектировщикам научиться писать ПО
Sama Y вне форума   Ответить с цитированием 0
Старый 26.05.2012, 11:48   #13 (ссылка)
Участник


Регистрация: 26.11.2010
Сообщений: 30
Поблагодарил: 1 раз(а)
Поблагодарили 5 раз(а)
Фотоальбомы: 0
Репутация: 0
По умолчанию

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


Регистрация: 22.12.2011
Адрес: Называевск
Возраст: 34
Сообщений: 332
Поблагодарил: 20 раз(а)
Поблагодарили 13 раз(а)
Фотоальбомы: 0
Репутация: 11
По умолчанию

Я как человек закончивший и программиста образования правда средне специальное и СЦБ микропроцессорное могу с увериностью сказать то что человек который пишет программу должен быть сцб, или хотя бы 1 из команды.
Michail Lupinos вне форума   Ответить с цитированием 1
Старый 26.05.2012, 12:19   #15 (ссылка)
))
 
Аватар для Sama Y


Регистрация: 22.02.2010
Адрес: Екатеринбург
Сообщений: 2,521
Поблагодарил: 2228 раз(а)
Поблагодарили 1348 раз(а)
Фотоальбомы: 0
Записей в дневнике: 6
Отправить сообщение для Sama Y с помощью ICQ
По умолчанию

Антон Евгеньевич,
Вы видели написаное ПО???
о чем Вы говорите...
Цитата:
Тем кто изучил БМРЦ на изучение элементарных основ программирования, а в ПО МПЦ большего быть не должно, понадобится не больше недели.
больше всего слово "бред" подходит...
Sama Y вне форума   Ответить с цитированием 0
Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
[Статья] Концепция развития электронных систем резервирования мест и обслуживания пассажиров на железных дорогах Admin Ж/д статьи 0 16.04.2011 09:23
[Статья] Перспективы применения электронного обмена данными в грузовых перевозках в международном сообщении Admin Ж/д статьи 0 13.03.2011 11:25
Перспективы развития ходовых частей вагонов Admin Вагонное хозяйство 0 07.02.2011 15:42
Этапы развития станционных систем автоматики и телемеханики Admin Рефераты 0 15.12.2010 08:53
Перспективы развития автосцепного оборудования Admin Вагонное хозяйство 0 09.12.2010 16:12

Ответ

Метки
развития, перспективы, систем


Здесь присутствуют: 1 (пользователей: 0 , гостей: 1)
 
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Trackbacks are Вкл.
Pingbacks are Вкл.
Refbacks are Выкл.



Часовой пояс GMT +3, время: 07:10.

СЦБ на железнодорожном транспорте Справочник  Сайт ПГУПС
сцбист.ру сцбист.рф

Лицензия зарегистрирована на scbist.com
СЦБИСТ (ранее назывался: Форум СЦБистов - Railway Automation Forum) - крупнейший сайт работников локомотивного хозяйства, движенцев, эсцебистов, путейцев, контактников, вагонников, связистов, проводников, работников ЦФТО, ИВЦ железных дорог, дистанций погрузочно-разгрузочных работ и других железнодорожников.
Связь с администрацией сайта: admin@scbist.com
Powered by vBulletin® Version 3.8.1
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
Powered by NuWiki v1.3 RC1 Copyright ©2006-2007, NuHit, LLC Перевод: zCarot
Advertisement System V2.4