Николай Николаевич

Но тогда получается, что версия "декларированного ПО" всегда будет отличаться от версии ПО на конкретном объекте?

Трезвый путеец

Да. Декларируется не "конкретную версию ПО", а безопасность исполнения функций, согласно ГОСТам, ОСТам, СТО итд.итп.

Николай Николаевич

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

Абрамов..ИЧ

Ну, а как иначе? Одинаковые же станции не бывают...

Николай Николаевич

Итог: теряется весь смысл подтверждения соответствия ПО...

Абрамов..ИЧ

Есть разные типы ПО (системное, базовое, технологическое и т.д.), т.е. меняется оно не 100%но, поэтому смысл есть

Nad

Так вот если эта часть является базовой, условно зашитой в неизменяемые функциональные блоки, то зачем их "передоказывать"? Для каждого нового объекта нужна утвержденная методика тестирования, которые и подтверждают соответствие адаптации к очередному проекту. В контексте проверки выполнения зависимостей на релейной логике - разные станции ведь проектируют по одному ТМП, так сказать "базовому".

Николай Николаевич

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

"На заре" появления российских МПЦ было принято, что за основу работы МПЦ взяты алгоритмы релейной системы ЭЦ по ТР ЭЦ-12-ХХ (год не помню), как самой функционально "продвинутой" системы ЭЦ на тот момент...
Вопрос к знатокам - а по единым ли алгоритмам действительно работают разные системы МПЦ???

Узник Абакана

Нет конечно. Даже принцип мажоритарности и то различен

__________________
Разделение ШЧ на ПЧ и НГЧ

Николай Николаевич

А вот это - первое, что нужно директивно унифицировать!

Узник Абакана

Можно попробовать найти некое коренное различие ЭЦ с жесткой логикой (например релейные ЭЦ) и с программной логикой (компъютерные ЭЦ)
Была даже электронная ЭЦ, но она тоже работала по принципам жесткой логики. Значит делить ЭЦ на релейные и нерелейные не получится. Как пример можно взять любую РПЦ. Вроде как и реле есть, а логика построена на программных кодах. Значит самое главное - это ПО. Выходит что НН прав, все объектные контроллеры и прочее железо продлежат одноразовой сертификации при выпуске в серийное производство, а любой проект станции как нового изделия также подлежит сертификации именно из-за ПО и пего взаимодействия с железом.

__________________
Разделение ШЧ на ПЧ и НГЧ

Admin

никаких особых "алгоритмов ЭЦ" нет. основные функции МПЦ - достоверно отображать состояние напольных устройств, выполнять команды ДСП, достоверно контролировать прохождение поезда по маршруту или перегону

все это решается кучей if else

ну и дополнительно - защищаться от аппаратных сбоев памяти и цпу - случайного изменения переменных и перепрыгивания на другие участки кода при его выполнении

__________________
Телеграм-канал ЖЕЛЕЗНОДОРОЖНИК

Узник Абакана

Тут еще можно добавить что логику работы релейных ЭЦ может проследить любой монтер с помощью стремянки попрыгав по стативам и просмотрев соединения воочию.
Для компъютерных ЭЦ такое невозможно так как все алгоритмы записаны в виде нулей/едениц на магнитных или других носителях, которые так просто не проверить.

__________________
Разделение ШЧ на ПЧ и НГЧ

Трезвый путеец

Молодец. Схватил мысль. Декларируется как правило функциональное исполнение по блокам.


Далеко не все пишется, на классическом понимании "if else". Некоторые контроллеры имеют свою среду разработки ПО, которое даже и близко не похоже на классику. А уж контроль состояния - отдельная немного сложная тема.


А есть ли разница, что будет крутится в шкафу, если выполняются функции одинаково? Т.е. будь это ЭЦ-12 или БМРЦ? Разница по факту же будет в паре элементов в шкафу и коде. Но на выходе мы увидим те же маршруты и те же переводы стрелок.

Неправильно. Будет ТР на использование оборудования. Будет ПО, для этого оборудования. И будет стадия Адаптация (разработка ПО под конкретную станцию), согласно сертифицированной "базовой версии".

На выходе, в проекте будет спецификация шкафов + диск с ПО.

Трезвый путеец добавил 26.03.2019 в 22:58
Здесь тоже работает принцип Лего. Безопасность будет одинакова, что у вас на станции 10 стрелок что 50 что 100. Просто объем "блоков кода" будет больше. Принцип от этого не изменится.

Николай Николаевич

Нет, не соглашусь!
Алгоритмы ЭЦ-12 и БМРЦ - разные, например - задержка размыкания секций маршрута за хвостом поезда. И еще много чего.
И алгоритмы МПЦ - проще, чем в ЭЦ-12 быть не должны (речь, естественно, об алгоритмах установки и размыкания маршрутов).

Николай Николаевич добавил 26.03.2019 в 23:05
Я же говорю о "документарном" подтверждении соответствия одной и другой версии ПО...