Переход на ОС с открытыми кодами (Linux) - Страница 53 - СЦБИСТ - железнодорожный форум, блоги, фотогалерея, социальная сеть

**Николай Николаевич** · 20.12.2017, 08:57

Цитата:

Сообщение от xmel

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

Есть три ключевых момента, которые оказывают влияние на архитектуру системы:
1. Обеспечение безопасности движения поездов.
2. Деньги.
3. Время.

Безопасность движения поездов это, безусловно, то основное, от чего отталкиваются при проектировании систем СЦБ. Вследствие этого, для любого компонента системы, а также для совокупности взаимодействующих компонентов необходимо доказывать эту безопасность. В моем понимании безопасность движения поездов это выполнение некоторых очень простых требований, конечным результатом которых является невозможность, с определенной очень высокой вероятностью, допустить столкновение подвижного состава, а также сход его с рельсов в результате превышения установленных скоростей движения. Эти требования прописаны в трех книжках, а интерфейс машинист--система ЭЦ прописан в РУ. Всё остальное в вопросы обеспечения безопасности движения поездов со стороны СЦБ де-факто не входит.
Также, я принимаю, что возможность несанкционированного использования системы при выполнении требований безопасности движения поездов несет существенно меньший вред, чем собственно нарушение безопасности движения поездов.

Возможность несанкционированного использования системы - по своим негативным последствиям - должна рассматриваться как минимум на таком же уровне, как и безопасность движения! И, допускаю, что даже более жестко!
И еще про безопасность движения - мы в СЦБ всю жизнь безопасность движения строили, основываясь на постулате: "пусть светофор "сто раз" станет красным вместо зеленого, лишь бы "раз в сто лет" он не стал зеленым вместо красного". "Вчера" такой подход был допустим, сегодня - уже нет! За "красный" - бьют, больно и каждый день!

Николай Николаевич добавил 20.12.2017 в 09:42

Цитата:

Сообщение от xmel

Теперь посмотрим со стороны денег. В современной системе ЭЦ/АБ в любом случае будут присутствовать объектные контроллеры. Внутри это будут достаточно интеллектуальные устройства, даже если у них внешний интерфейс предельно тупой. Примером является приемник ТРЦ, непосредственно обеспечивающий безопасность движения поездов, и в серийных устройствах содержащий внутри микропроцессор или ПЛК.
Как только мы начинаем выносить от железнодорожного пути куда-то вверх обеспечение безопасности движения, сразу начинается "лавинное" увеличение сложности и стоимости доказательства безопасности системы.

Возьмем крайние случаи:
1. ЭЦ на объектных контроллерах с местными зависимостями. Требуется СПЕЦИАЛЬНО разработать и доказать безопасность:
- Объектные контроллеры со схемами увязки с железом и линиями связи (например, оптика) со своим программным обеспечением
- Линии связи (доказать, что засветка оптики при её откапывании и повреждении не приведет к приему ложных сообщений)

2. "Сверхцентрализация". Опять-таки, требуется СПЕЦИАЛЬНО разработать и доказать безопасность:
- Объектные контроллеры и программное обеспечение объектных контроллеров.
- Линии связи и коммуникационное оборудование на участках объектный контроллер-пост ЭЦ-какой-то хаб-совсем крупный хаб-ГВЦ РЖД, а также программное обеспечение, управляющее передачей сообщений.
- "Мейнфрейм", управляющий сетью и реализующий зависимости, а также его программное обеспечение.

В любом случае, будет какое-то место, куда подключаются АРМ с ОС общего назначения, и где заканчивается система, обеспечивающая безопасность.
На самом деле, оптимальное решение будет, как всегда, где-то посередине, и оно будет зависеть от многих факторов, в том числе и не технического характера.

Специально разработать и доказать безопасность - придется в любом случае и в любом из рассматриваемых вариантов.
Но "упрощать" задачу только из-за того, что сложно доказать безопасность - я бы так не формулировал. Доказательство безопасности - это всегда разумный компромисс между двумя сторонами.

Николай Николаевич добавил 20.12.2017 в 09:48

Цитата:

Сообщение от xmel

Но я могу сделать примерный расчет для "распределенной ЭЦ", в млн руб. Цены сопоставимы с разработками ПО по госконтрактам и железу оттуда же. Берем только управляющую систему, без светофоров, кабелей, приводов и всего остального, что одинаково для всех решений.

Единовременные затраты:
1. Разработка стандартов - 120
2. Принятие ПНСТ - ? пусть 300
2. Разработка нескольких моделей ОК (светофор, стрелка, путевой приемник) 3*50
3. Сертификация ОК 3*10
4. Разработка АРМ ДСП, ШНС, ДНЦ плюс софт для проектирования 300*3года поэтапно
Итого единовременно 1500

Стоимость ОК 0,2
Принимаем количество объектов на сети как 20 000 централизованных стрелок, по 2 светофора на стрелку, 3 РЦ на стрелку. Общее количество 120 000.
Итого ОК: 24 000
Выходит, что примерно за 25,5 миллиардов рублей можно полностью поменять всю ЭЦ РЖД на современную.

Ну и по времени. Может-ли РЖД потратить на систему управления движением 26 млрд руб за 10 лет? Думаю, может. Может-ли РЖД потратить по миллиарду рублей на МПЦ каждой из 2000 станций? Сомневаюсь.

Финансирования со стороны заказчика, какого-то НИОКРа - точно не будет, эту тему можно даже не начинать обсуждать...
Справочно - разработка ГОСТа или ГОСТ Р в ОАО "РЖД" стоит примерно 1,5 - 3,0 млн руб.
Потенциальный объем рынка - все округленно, но близко к фактам:
- станций - 4500
- стрелок - 130 000
- светофоров (с а/б) - 250 000
- РЦ - 250 000.

Николай Николаевич добавил 20.12.2017 в 09:52

Цитата:

Сообщение от xmel

Да не нужно будет ничего допаивать. ОК должен быть тупой как пробка. Включили правильно--работает. Включили неправильно--не работает. Предыдущие РУ были выпущены в 1980 году, действующие в 2012. Прошло 32 года. Все блоки вЫходят срок службы за это время. Инструкция по сигнализации меняется примерно также. Не нужно никаких постов ЭЦ, для серверной достаточно помещения, например, в контейнере КТСМ или на посту ДПП, заодно и под присмотром будет. Сами ОК должны быть вообще необслуживаемые.

Согласен. Но только в случае, если ОК отвечает за безопасное и надежное функционирование объекта управления и контроля, но не отвечает за обеспечение взаимозависимостей между совокупностью объектов.
И тогда мы возвращается к вопросу: "кто", "как" и "где" будет обеспечивать эти взаимозависимости? И ключевой вопрос - "как", за счет "железа" или за счет ПО? Все остальное - вторично...

Николай Николаевич добавил 20.12.2017 в 09:57

Цитата:

Сообщение от xmel

Это будет тоже, но только это железо должно обеспечивать только управление по алгоритмам любой сложности. Зачем выносить обеспечение безопасности на верхний уровень--непонятно. Светофорный контроллер априори должен быть безопасным. Ну и пусть обеспечивает и безопасность зависимостей, задача одной сложности.

Что касается вопросов замены и программирования ОК, то это должно также решаться системой высокого уровня (отказ ОК-выдача предписания ШН на замену-программирование ОК-замена ОК-верификация и включение в работу), но неправильно сконфигурированный ОК должен уходить в защитный отказ, если его включение не соотвествует топологии.

В МПЦ ОС не нужно. Но нужно доказывать безопасность ПО и его конфигурации. И, поправьте меня, если я не прав, но для каждой станции/участка.

Каждый лишний бит данных это увеличение количества возможных состояний системы вдвое. Вопрос, как будем безопасность доказывать?

Давайте отделять мух от котлет. Безопасность движения обеспечивается конечным автоматом. Прочие примочки должны быть отдельно.

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

**Александр** · 21.12.2017, 16:02

Цитата:

Сообщение от Николай Николаевич

Коллеги, кто умеет - вырезать бы всю эту полемику, начиная с сообщения №780 - в отдельную тему...

Создана тема
Надёжность и безопасность МПЦ

**Николай Николаевич** · 21.12.2017, 16:07

Цитата:

Сообщение от Александр

Создана тема
Надёжность и безопасность МПЦ

Спасибо!
Присоединяйтесь "к столу"!

Похожие темы
Тема	Автор	Раздел	Ответов	Последнее сообщение
[РЖД ТВ] РЖД и Саровский ядерный центр разработают отечественную операционную систему на базе Linux	rzd.ru	Новости на сети дорог	0	29.08.2014 01:04
Переход на резерв З	Shaddix	Общие вопросы эксплуатации устройств СЦБ	3	17.11.2013 10:33
Переход в Трансремком	gvmax2	Вагонное хозяйство	2	04.10.2012 19:05
=Распоряжение= № 45р от 17 января 2007 г. - Об обеспечении структурных подразделений ОАО "РЖД" штемпелями с кодами подразделений	Admin	2005-2008 годы	0	09.07.2012 15:52
[РЖД ТВ] В Самарских электричках установят стикеры с матричными двухмерными штрих-кодами	Admin	Новости на сети дорог	0	06.07.2012 08:34

Здесь присутствуют: 1 (пользователей: 0 , гостей: 1)