Говоря про МПЦ-системы, выглядит все складно, если исходить из того, что "система" ограничвается постом ЭЦ. что снаружи - не система, а объекты, которыми она управляет и их контролирует, а кабель - линия связи с ними.
Таким образом, на МПЦ - сертификат свой (и у неё есть один конкретный изготовитель с ТУ), на линию связи - свой, на напольные устройства - свой. Пазл сходится.

А вообще само по себе отсутствие ГОСТов по большей части восполняется существующими + требования ТУ. По крайней мере, по сложным системам ещё плодить ГОСТ уже вроде как достаточно) По мелкой продукции - да наверное стоит.

Пазл сойдется, когда разработчик и/или проектировщик рассчитают показатель надежности для объекта в целом!

Николай Николаевич добавил 22.12.2016 в 12:37
В сотый раз - должны быть ГОСТы на применяемые изделия!

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

Поставщик МПЦ за отказ кабеля не должен отвечать.

А зачем? Что это реально даст, тем более расчётный показатель? Может быть не стоит иметь обобщённый показатель надёжности, а иметь несколько показателей надёжности: на УВК, на кабель, на напольные устройства и т.д.. Так легче анализировать и понимать где тонко!
Кроме того, расчётный показатель надёжности никак не учитывает условия эксплуатации (обслуживания)?!

Поддерживаю. Нужно распределить "подсистемы", с которых снимать показания и налагать требования. С кабелем, кстати, вопрос уже во многом решен: ГОСТ 31947, 31995, 31995.

Для условий использования и климатики есть ГОСТ 14254, 15150 и т.п., но это уже другая история. Применяемые элементы этим ГОСТам должны просто соответствовать, а иначе не могут быть использованы вообще.
Условия обслуживания - это уже совсем-пресовсем другая история. Конструкторы и технологи определяют, какими специальностями и разрядами должен обладать обслуживающий персонал, а их соответствие - это уже проблемы негров эксплуатирующей организации.

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

Да, только этого недостаточно!
Нужно, чтобы ГИП рассчитывал показатель надежности для всего объекта в целом, да еще и раскладывал это показатель по основным составляющим.

Николай Николаевич добавил 22.12.2016 в 13:22
Как бы "да", но и как бы "нет"...
Надо еще посмотреть - а насколько "удачно" разработчик МПЦ применил такой кабель, а не другой, "столько" кабеля, а не "пол-столько", почему не задублировал/ не зарезервировал и т.д.

Без общего показателя надежности для объекта отдельные показатели надежности для составных частей или для элементов - не очень-то и интересны, ибо не виден конечный результат.
Вы всё хотите размазать ответственность - а я хочу наоборот...

Дело в том, что это тогда не ГИП, а Главный конструктор будет это делать. И тогда на каждой станции ЭЦ будет не "типовая с привязкой", а выполненная по своим собственным КД, что увеличит стоимость проектирования на порядок. (Проектирование ЭЦ осмечивается по одному справочнику, а разработка КД системы автоматизации - по другому, и цены там начинаются, ЕМНИП, с ~11М за самую "простую" работу).

А кто этим будет заниматься? ГТСС? ВНИИАС?

Система ЭЦ слишком разнородна, не получится всю ответственность повесить на одного (ну, кроме ШЧ, конечно).
Возвращаясь, опять-таки, к общепромышленным АСУ: там за систему и подводящий информационный кабель отвечает одно подразделение (т.н. "АСУ-шники"), а за электропривод и силовой кабель - другое (электроцех).

Считаю (моё личное мнение, никому его не хочу навязывать!) показатель надежности следует считать на каждый функционально неделимый узел. Для связанных узлов показатель надёжности будет равен произведению показателей надёжности каждого узла (могут быть варианты связанные с резервированием).

К сожалению, у нас нет такого Главного конструктора...
А вот тезис о переходе от проектирования "по ТМП" к, условно, "по собственной КД" - имеет право на жизнь! Поскольку сегодня ГИП настолько повязан по рукам и ногам, что с одной стороны, он мало за что реально отвечает, с другой стороны - мало что реально может в плане выбора технических решений.
Ну а ценник - это вопрос регулируемый...

Николай Николаевич добавил 22.12.2016 в 13:42
Ну на это вопрос готового ответа явно нет!
Сначала на этот путь нужно вступить...

Николай Николаевич добавил 22.12.2016 в 13:43
В этом и есть самая главная "неправильность".
И её нужно исправлять!

А что - напольный кабель поставляют разработчики МПЦ?
при разворачивании МПЦ напольный кабель ведь обычно уже куплен и уложен (интеграторами, СМПистами и проч.) и к нему разработчик не имеет отношения...

Это все теория.
А должна быть практика - чтобы на любом уровне, от ШНа и до ЦШ было понятно: какая надежность автором проекта заложена в каждый конкретный объект эксплуатации. И при этом ни ШН, ни ШЧ, ни ЦШ сами считать этот показатель не должны - не их это дело.

Если системы будут строится по модульному/блочному типу (а такое уже было - БРМЦ), а на функционал модулей/блоков будет ГОСТ и показатели надёжности известны, то из этих кубиков можно создавать любой функциональности системы (так примерно сейчас делаются системы в промышленной автоматике). Кроме, того хочешь по надёжнее выбираешь модули siemens, хочешь подешевле берешь модули нпп "овен"!

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