А вы говорите микропроцессоры...

straus · Сообщение **straus** » 01 май 2009, 17:53

Набрел на информацию:
В России ставят МПЦ Ebilok 950 (Ebilock 950) компании Бомбардье. За три месяца 70 сбоев, 44 перезапуска объектных контроллеров, 8 логических обрывов петли связи. 2 случая перевода стрелок под составом.

(Наши глюки с системами пополнения проездных - просто детский лепет на лужайке.)
Че там микропроцессорное ДЦ есть в каком-то ТЧ в КМ?

Стас(ШЧ-1 киев)

да есть. В депо Харьковское. за почти 2 года с пуска работает без сбоев.

sashman · Сообщение **sashman** » 13 май 2009, 10:54

Думаю, на ржд было как всегда. Бюджет сначала распилили, а потом увидели, что денег нет, и заменили "некритичные" компоненты типа блоков питания, оптических модемов, экранированных кабелей на китайские "аналоги" подешевле. Съекономили на обогреве/охлаждении ящиков, и т.д.

straus · Сообщение **straus** » 13 май 2009, 12:19

Стас(ШЧ-1 киев) писал(а):да есть. В депо Харьковское. за почти 2 года с пуска работает без сбоев.

Неплохо. Есть подробности по системе? Проверка зависимостей дублируется релейной схемой? Под какой операционкой вся эта богодельня? (Ebilok работает под DNIX, разновидность UNIXа.) Кто разработчик системы?

P.S. Года два назад меня пытались подпрячь сделать светодиодный светофор для ТЧ-1. Там где-то на въезде стоит карлик в кривой, который в солнечную погоду нифига не видно. Потом это заглохло. Сделали что-нибудь?

straus · Сообщение **straus** » 13 май 2009, 12:28

sashman писал(а):Думаю, на ржд было как всегда. Бюджет сначала распилили, а потом увидели, что денег нет, и заменили "некритичные" компоненты типа блоков питания, оптических модемов, экранированных кабелей на китайские "аналоги" подешевле. Съекономили на обогреве/охлаждении ящиков, и т.д.

Не-а, там система "в себе", все увязано друг с другом и аналогов нет. Предполагаю, что есть две причины:
Изначально заложеная при проектировании высокая вероятность сбоев без полного отказа.
Местные реалии вроде высокого уровня помех.

Кстати, переводы стрелок под составом из-за ошибок в программной части.

В сухом остатке:
Полностью отказались от релейных устройств проверки зависимостей, возложив все на программную часть. Получили критичность ошибок в программе. Да еще огребли высокий уровень помех на местах. Соответственно добавились аппаратные сбои.

Стас(ШЧ-1 киев)

операционная система винд 2000 на сколько я помню. релейных схем проверки электроники нету. разработали и внедрили Желдоравтоматика.

sirrosh · Сообщение **sirrosh** » 14 май 2009, 08:03

вероянтее всего, на операционная система винд 2000 там только SCADA, т.е. операторская часть. Принимает решения все-таки контроллер.

Стас(ШЧ-1 киев)

операционная система на АРМах ШН и ДСП -винда. а в контролерах МПЦ естественно своя система. На АРМах никаких зависимостей не выполняется. Соотвественно если слетит винда, стрелка под составом не переведется.

sirrosh · Сообщение **sirrosh** » 14 май 2009, 09:24

Так точно, Капитан Очевидность, именно такую мысль я и планировал выразить

straus · Сообщение **straus** » 14 май 2009, 19:00

Стас(ШЧ-1 киев) писал(а):операционная система на АРМах ШН и ДСП -винда. а в контролерах МПЦ естественно своя система. На АРМах никаких зависимостей не выполняется. Соотвественно если слетит винда, стрелка под составом не переведется.

Значит самого главного ты и не написал. На чем сделаны ключевые завивимости? На чем сделана контрольная защитная проверка ключевых зависимостей?

(Хочется ответ приблизительно такой:
Ключевые зависимости на контроллере XXX марки YYY, программа написана ZZZ.
Контрольная проверка взаимоисключающих маршрутов проводится схемой на жесткой логике 564 серии.)

sirrosh · Сообщение **sirrosh** » 15 май 2009, 08:46

А какая разница на чем написана программа? Думаю, в любом случае это будет язык отвечающий в т.ч. требованиям полной детерминированности, согласно IEC 61508.
Например LD (аналог РКС - релейно-контактных схем) или FBD (аналога нет). Точно не на С (+,++,#)

straus · Сообщение **straus** » 15 май 2009, 13:31

sirrosh писал(а):А какая разница на чем написана программа? Думаю, в любом случае это будет язык отвечающий в т.ч. требованиям полной детерминированности, согласно IEC 61508.
Например LD (аналог РКС - релейно-контактных схем) или FBD (аналога нет). Точно не на С (+,++,#)

Мне вобщем-то интересно оценить уровень вероятности отказов и критических отказов. Язык программы малоинтересен. А вот модель контроллера очень даже.
И хочется сравнить реалии с тем, как бы сделал я сам.

sirrosh · Сообщение **sirrosh** » 15 май 2009, 14:47

Надежность и безопасность немного разные вещи. Поэтому отказ контроллера никак не подразумевает сбой (опасный либо неопасный) функционирования системы. Что тебе даст модель контроллера для оценки интенсивности опасных отказов всей системы?

straus · Сообщение **straus** » 18 май 2009, 10:29

sirrosh писал(а): Поэтому отказ контроллера никак не подразумевает сбой (опасный либо неопасный) функционирования системы.

На самом деле это зависит от конкретной реализации. Если выходы оппозитные, то отказ или обесточивание контроллера просто оставит систему в текущем состоянии. Если же используются выходы Single Ended, то система установится в состояние по умолчанию, например все стрелки в минус.
А вот сбой выполнения программы может привести к непредсказуемым последствиям. Именно поэтому на всех опасных объектах (химпром, атомная энергетика) используются схемы на жесткой логике для предотвращения аварийных ситуаций.

sirrosh · Сообщение **sirrosh** » 18 май 2009, 14:05

Сбой выполнения программы (именно сбой, а не систематическая ошибка) не должен приводить к непредсказуемым последствиям, иначе это не система обеспечения безопасности, или она не отвечает 61508, куда входят в т.ч. ж/д системы блокировок

И, пожалуйста, смягчай категоричность высказываний: "на всех объектах..., жесткая логика..." и вставляй фразы вроде "которые мне доводилось видеть".
Потому как оценка уровня твоей компетентности в мои задачи не входит, однако высказывание "на всех" в этом утверждении не соответствует действительнсти хотя бы потому, что некоторые мои проекты как раз заключались в проектировании и внедрении сертифицированных по процедурам IEC SIS на базе контроллеров на химических и горно-металлургических предприятиях.