Речь о том, что для решения любой проблемы ему не нужно никому звонить, искать “того самого специалиста” или ждать подрядчика
Так так и пишите, однозначно и без "читайте между строк". Вы же, я надеюсь, технарь.
Но система, которая держится на опыте отдельных людей, неустойчива по определению.
Соглашусь с Вами. Вы не рассматриваете "темные фабрики", а значит везде имеют место быть неустойчивые системы, ибо есть люди. И никакие стандарты не "закроют" этот вопрос. Снизят риски ошибочных и неэффективных действий - да, однозначно, но не более того. Таким образом, рассматривать систему стандартов на любой этапе её жизненного цикла нужно только с учетом действий человека по отношению к этой системе.
Простейший пример из эксплуатации:
в электрических схемах нет обязательной координатной сетки;
нет однозначной привязки элемента к шкафу и месту установки;
держа лист схемы в руках, невозможно понять, куда идти и что искать.
Это только Ваш неудачный опыт. Так и пишите, нечего обобщать. Я имел дело с документацией систем автоматизации в различных отраслях экономики и знаю, что, например, документация проектов систем железнодорожной автоматики и телемеханики удобна и прозрачна.
кто определяет архитектуру всех проектов на предприятии?
ГОСТ — не определяет.
Каждый проект — определяет только себя.
Вы работали с объектами тепловой энергетики - АСУ тепломеханического оборудования? Видели ГОСТы, РД, связанные с этими объектами? Там много чего, включая и архитектуру самих АСУТП.
При этом, чего там нет, так это указанных Вами требований к программному обеспечению.
Я реально работал:
на предприятиях с жёсткими корпоративными стандартами АСУ ТП,
и на предприятиях, где стандартов не было вовсе или они существовали формально.
Не могу Вам ничего навязывать, просто считаю, что следовало бы "во первых строках" сообщить уважаемому сообществу, кто Вы и какой у Вас опыт, дабы сразу снять вопросы и додумки относительно ниже написанного.
Ох и покритикую я сейчас это частное мнение, выставляемое напоказ.
Если стандарта нет — может пройти год и больше, прежде чем человек сможет в одиночку обслуживать завод без постоянного риска что-то сломать
Да какая ересть! Никакой инженер не может обслуживать "никакой" завод "в одну каску". Практика "и жнец и на дуде игрец" крайне ущербна.
Разница между этими сценариями не в уровне специалистов, а в том, есть ли на предприятии система или только набор проектов
В конечном итоге, на предприятии, именно уровень специалистов является определяющим. Даже при "плохой мине" опытный сотрудник может поддерживать безаварийную работу сложного технологического оборудования, вывозя всё и вся "на классе". Не оцениваю, плохо ли это или хорошо, просто как мнение.
ГОСТ и ЕСКД — это не стандарты АСУ ТП
В технических заданиях до сих пор часто можно увидеть формулировку:
«Проект выполнить в соответствии с ГОСТ и ЕСКД».
По сути, это равнозначно фразе: «Делайте как хотите».
Еще одна ересть, особенно последняя фраза!
В ТЗ пишут не с "ГОСТ И ЕСКД", а конкретный перечень стандартов, выполнить требования которых необходимо на этапе разработки проектной и рабочей документации. Отдельный ГОСТ на разработку ТЗ на создание АСУТП четко регламентирует определенный набор требований к: структуре, надежности, безопасности, эргономике и пр. и пр.
ГОСТы и ЕСКД:
не определяют архитектуру АСУ ТП — они не отвечают на вопрос, как и для чего делить систему на зоны, ячейки и оборудование, где проходят границы ответственности и как связаны между собой элементы управления
Архитектуру конерктной АСУ ТП определяет проект. Баста!
Скрытый текст
Есть в природе стандарты, в которых описана архитектура, например: РД 153-34.1-35.127-2002 "Общие требования к АСУ ТП ТЭС", РД 153-34.1-35.137-00 "ТТ к подсистеме технолог. защит"
Сделать АСУ ТП не по ГОСТу практически невозможно — он слишком общий и не накладывает реальных ограничений
Да будет Вам известно, что цель создания ГОСТ совсем другая. Вот для сведения структура документов по стандартизации согласно 162-ФЗ.
Стандарты формируют требования государства к качеству продукции, работ и услуг
ЕСКД в контексте АСУ ТП — отдельная проблема.
Это стандарт, созданный для конструкторской документации прошлого века.
Документация, выполненная строго по ЕСКД:...
КД - это шкафы, оборудование, "железо". О какой логике работы системы, PLC и HMI Вы пишите? Для описания всего этого ГОСТ серии 34 регламентирует наличие соответствующих разделов и документов техно-рабочего проекта. Всё уже дано изобретено и, к счастью, работает. А где конкретного заказчика не устраивает, он разрабатывает свои корпоративные стандарты, а-ля, "общие технические требования к разработке автоматизированных систем управления...".
На практике такую документацию либо не открывают вовсе, либо открывают один раз — и больше к ней не возвращаются
Очень жаль, что Ваша "практика" не "видела" больше "одного раза". В иной, действительной, реальности в КД "заглядывают" чаще. Хотя бы исходя из планового регламента её проверки и соответствия реальному "положению дел".
Эти KPI противоречат друг другу по умолчанию.
В приведенных Вами перечислений нет НИ ОДНОГО конфликтующего друг с другом. Быстрее - не значит "хуже" и "непонятнее для эксплуатации".
Стандарты АСУ ТП не могут эффективно разрабатываться интеграторами ...
...
Рабочие стандарты могут разрабатывать только инженеры
Вы "мухи" и "котлеты" сравниваете: интегратора и инженеров )))) Так, для справки, инженеры работают и у интеграторов. Я знаю одного мощного интегратора, который разработал целый массив стандартов для одной крупной компании с Дальнего Востока. И ничего, приняли, работают, проекты разрабатывают и внедряют.
Так что Ваше обобщение - это просто Ваше частное мнение.
Приведите анализ двух-трех стандартов, чтобы подтвердить Вашу точку зрения про "специфику программирования".
Само наличие стандартов говорит, как минимум о том, что компания, принявшая их, решила упорядочить и систематизировать свои рабочие и производственные процессы. А это уже немало.
Автор, не знаю, откуда Вы брали столь скудную информацию об отечественной стандартизации в АСУ ТП. Впечатление такое, что имеют место быть лишь поверхностные знания.
РЖД уже много десятков лет "живет" со своей четко отлаженной системой стандартов, типовых проектных решений и т. д. и т. п. Один корпоративный стандарт СТО РЖД 1.19.005-2008 "Системы и устройства железнодорожной автоматики и телемеханики. Условные графические изображения" чего стоит.
Транснефть имеет четко выверенную систему стандартов, отлаженный порядок работы как с вендорами, так и с системными интеграторами.
И наконец, вообще ничего не указано про отраслевую стандартизацию в нефтегазе "под флагом" АНО "ИНТИ". А там более 250 стандартов, система оценки вендоров, система оценки СМК, система проведения отраслевых испытаний.
Ставлю жиииирнющий "минус" автору статьи за бездарную подачу материала, результатом которой являются комментарии, с которыми бОльшей частью согласен.
Первое и главное при писательстве подобных текстов - крайне отчётливо представлять целевую аудиторию. А лучше в первом-втором абзаце в явном виде указывать, для кого написан нижеприведенный текст.
Иначе прочитав статью, получаешь непозитивный осадочек из серии "очередная рекламщина".
А теперь по сути:
Абсолютно нет никакой привязки к общефедеральному законодательству и того, что "хочет регулятор". Ни про ПП1912, ни про Указ Президента № 250. Ничего. Сложилось впечатление, что ой, иностранные вендоры ушли, как же плохо. А давайте-ка сделаем что-то своё! Ау, про технологическую независимость слышали?
"Открытость" не значит "Бесплатность", это все должны прекрасно понимать. Ничего не сказано, что коммерческий интерес зарубежных вендоров, а жаль. Уверен, что бессеребренников там нет.
Сразу обращает внимание на то, что автор не проводит какой-либо анализ существующих DCS и выделения общих характеристик, а голословно пишет про их недостатки и слабые места, чтобы, в дальнейшем, вполне логично рассказать про решение отдельного китайского вендора.
Абсолютно нет какой-либо привязки к реалиям отечественного рынка АСУТП и отраслям промышленности. Термин "обрабатывающая" слишком широк.
Алексей, спасибо за рекомендацию книги, обязательно прочитаю.
Согласен с тем, что писательство - это труд и что нужно заставлять себя этим заниматься, особенно, если для тебя это не основная сфера деятельности.
Интересно, было ли у Вас такое: написал несколько страниц, а потом, спустя, например, неделю или две вернулся к ним, увидел, что написано "некрасиво", и переписал?
Я однозначно разделяю понимание кандидатов его должностных обязанностей и его уровень знаний и навыков. Сначала проговариваем первое, а затем второе при однозначном указании "а помните, вон там говорили про то, что требуется от сотрудника, работающего по данной профессии".
В результате кандидат понимает, зачем я все это спрашиваю.
Не соглашусь с такой формулировкой "проектных". Корректнее и ближе здесь "ОТР - основные технические решения". Да и этот документ разрабатывается на стадии реализации проекта, ни никак не при пресейле.
...разделит его подходы и решения. (и кто будет в этом случае отвечать за неуспех проекта?
Да, согласен. Отвечает команда, которая занимается управлением и реализацией проекта.
Хорошей практикой является предоставление обратной связи от этой команды в стороны presale-команды по итогам работы над проектом (промежуточным - после отгрузки шкафов в адрес заказчика и итоговым - после внедрения АСУТП в пром. эксплуатацию). В моём коллективе это must have.
Но это говорит о том, что соискатели совсем не представляют себе, что они будут делать на этой позиции
Нет, что Вы! Это говорит об уровне знаний и навыков относительно сферы автоматизации и передачи данных.
Отвечу только на последний вопрос, так первые два не относятся к теме статьи: да, на этапе инициализации проекта, первом установочном совещании и, если потребуется, частично на этапе проектирования для уточнения некоторых технических деталей ранее разработанного решения.
Так так и пишите, однозначно и без "читайте между строк". Вы же, я надеюсь, технарь.
Соглашусь с Вами. Вы не рассматриваете "темные фабрики", а значит везде имеют место быть неустойчивые системы, ибо есть люди. И никакие стандарты не "закроют" этот вопрос. Снизят риски ошибочных и неэффективных действий - да, однозначно, но не более того. Таким образом, рассматривать систему стандартов на любой этапе её жизненного цикла нужно только с учетом действий человека по отношению к этой системе.
Это только Ваш неудачный опыт. Так и пишите, нечего обобщать. Я имел дело с документацией систем автоматизации в различных отраслях экономики и знаю, что, например, документация проектов систем железнодорожной автоматики и телемеханики удобна и прозрачна.
Вы работали с объектами тепловой энергетики - АСУ тепломеханического оборудования? Видели ГОСТы, РД, связанные с этими объектами? Там много чего, включая и архитектуру самих АСУТП.
При этом, чего там нет, так это указанных Вами требований к программному обеспечению.
Не могу Вам ничего навязывать, просто считаю, что следовало бы "во первых строках" сообщить уважаемому сообществу, кто Вы и какой у Вас опыт, дабы сразу снять вопросы и додумки относительно ниже написанного.
Ох и покритикую я сейчас это частное мнение, выставляемое напоказ.
Да какая ересть! Никакой инженер не может обслуживать "никакой" завод "в одну каску". Практика "и жнец и на дуде игрец" крайне ущербна.
В конечном итоге, на предприятии, именно уровень специалистов является определяющим. Даже при "плохой мине" опытный сотрудник может поддерживать безаварийную работу сложного технологического оборудования, вывозя всё и вся "на классе". Не оцениваю, плохо ли это или хорошо, просто как мнение.
Еще одна ересть, особенно последняя фраза!
В ТЗ пишут не с "ГОСТ И ЕСКД", а конкретный перечень стандартов, выполнить требования которых необходимо на этапе разработки проектной и рабочей документации. Отдельный ГОСТ на разработку ТЗ на создание АСУТП четко регламентирует определенный набор требований к: структуре, надежности, безопасности, эргономике и пр. и пр.
Архитектуру конерктной АСУ ТП определяет проект. Баста!
Скрытый текст
Есть в природе стандарты, в которых описана архитектура, например: РД 153-34.1-35.127-2002 "Общие требования к АСУ ТП ТЭС", РД 153-34.1-35.137-00 "ТТ к подсистеме технолог. защит"
Да будет Вам известно, что цель создания ГОСТ совсем другая. Вот для сведения структура документов по стандартизации согласно 162-ФЗ.
Стандарты формируют требования государства к качеству продукции, работ и услуг
КД - это шкафы, оборудование, "железо". О какой логике работы системы, PLC и HMI Вы пишите? Для описания всего этого ГОСТ серии 34 регламентирует наличие соответствующих разделов и документов техно-рабочего проекта. Всё уже дано изобретено и, к счастью, работает. А где конкретного заказчика не устраивает, он разрабатывает свои корпоративные стандарты, а-ля, "общие технические требования к разработке автоматизированных систем управления...".
Очень жаль, что Ваша "практика" не "видела" больше "одного раза". В иной, действительной, реальности в КД "заглядывают" чаще. Хотя бы исходя из планового регламента её проверки и соответствия реальному "положению дел".
В приведенных Вами перечислений нет НИ ОДНОГО конфликтующего друг с другом. Быстрее - не значит "хуже" и "непонятнее для эксплуатации".
Вы "мухи" и "котлеты" сравниваете: интегратора и инженеров )))) Так, для справки, инженеры работают и у интеграторов. Я знаю одного мощного интегратора, который разработал целый массив стандартов для одной крупной компании с Дальнего Востока. И ничего, приняли, работают, проекты разрабатывают и внедряют.
Так что Ваше обобщение - это просто Ваше частное мнение.
Пффф, да Вы еще и старую информацию транслируйте...
Приведите анализ двух-трех стандартов, чтобы подтвердить Вашу точку зрения про "специфику программирования".
Само наличие стандартов говорит, как минимум о том, что компания, принявшая их, решила упорядочить и систематизировать свои рабочие и производственные процессы. А это уже немало.
Откуда взята информация по Северстали?
Автор, не знаю, откуда Вы брали столь скудную информацию об отечественной стандартизации в АСУ ТП. Впечатление такое, что имеют место быть лишь поверхностные знания.
РЖД уже много десятков лет "живет" со своей четко отлаженной системой стандартов, типовых проектных решений и т. д. и т. п. Один корпоративный стандарт СТО РЖД 1.19.005-2008 "Системы и устройства железнодорожной автоматики и телемеханики. Условные графические изображения" чего стоит.
Транснефть имеет четко выверенную систему стандартов, отлаженный порядок работы как с вендорами, так и с системными интеграторами.
И наконец, вообще ничего не указано про отраслевую стандартизацию в нефтегазе "под флагом" АНО "ИНТИ". А там более 250 стандартов, система оценки вендоров, система оценки СМК, система проведения отраслевых испытаний.
Овен )))) Шутка. Если "сделано в РФ", то только ПЛК REGUL
А что Вы имеете против ж.-д. статей? ))))
Ставлю жиииирнющий "минус" автору статьи за бездарную подачу материала, результатом которой являются комментарии, с которыми бОльшей частью согласен.
Первое и главное при писательстве подобных текстов - крайне отчётливо представлять целевую аудиторию. А лучше в первом-втором абзаце в явном виде указывать, для кого написан нижеприведенный текст.
Иначе прочитав статью, получаешь непозитивный осадочек из серии "очередная рекламщина".
А теперь по сути:
Абсолютно нет никакой привязки к общефедеральному законодательству и того, что "хочет регулятор". Ни про ПП1912, ни про Указ Президента № 250. Ничего. Сложилось впечатление, что ой, иностранные вендоры ушли, как же плохо. А давайте-ка сделаем что-то своё! Ау, про технологическую независимость слышали?
"Открытость" не значит "Бесплатность", это все должны прекрасно понимать. Ничего не сказано, что коммерческий интерес зарубежных вендоров, а жаль. Уверен, что бессеребренников там нет.
Сразу обращает внимание на то, что автор не проводит какой-либо анализ существующих DCS и выделения общих характеристик, а голословно пишет про их недостатки и слабые места, чтобы, в дальнейшем, вполне логично рассказать про решение отдельного китайского вендора.
Абсолютно нет какой-либо привязки к реалиям отечественного рынка АСУТП и отраслям промышленности. Термин "обрабатывающая" слишком широк.
Общий настрой статьи - маркетинг. И зачем такое?
Резюме: не рекомендую к прочтению.
Ни дня без строчки!
Алексей, спасибо за рекомендацию книги, обязательно прочитаю.
Согласен с тем, что писательство - это труд и что нужно заставлять себя этим заниматься, особенно, если для тебя это не основная сфера деятельности.
Интересно, было ли у Вас такое: написал несколько страниц, а потом, спустя, например, неделю или две вернулся к ним, увидел, что написано "некрасиво", и переписал?
Штанген - это конечно база.
До сих пор помню удивление, когда на уроке труда в школе нам объяснили принцип измерения. Просто и гениально.
Абсолютно все. Как и прокурора: "По совокупности".
Один из пяти-шести
Здравствуйте!
Обратите внимание на пункт 3 "картины второй" + на то, что я уже имею от коллег по HR после проведения первого собеседования.
Относительно ценовой вилки я не буду ничего писать.
Игра стоит свеч, об этом говорит опыт самого рекрутинга.
Не знаю, что происходит в других компаниях.
Я однозначно разделяю понимание кандидатов его должностных обязанностей и его уровень знаний и навыков. Сначала проговариваем первое, а затем второе при однозначном указании "а помните, вон там говорили про то, что требуется от сотрудника, работающего по данной профессии".
В результате кандидат понимает, зачем я все это спрашиваю.
Ок, благодарю за Ваш комментарий.
Не соглашусь с такой формулировкой "проектных". Корректнее и ближе здесь "ОТР - основные технические решения". Да и этот документ разрабатывается на стадии реализации проекта, ни никак не при пресейле.
Да, согласен. Отвечает команда, которая занимается управлением и реализацией проекта.
Хорошей практикой является предоставление обратной связи от этой команды в стороны presale-команды по итогам работы над проектом (промежуточным - после отгрузки шкафов в адрес заказчика и итоговым - после внедрения АСУТП в пром. эксплуатацию). В моём коллективе это must have.
Нет, что Вы! Это говорит об уровне знаний и навыков относительно сферы автоматизации и передачи данных.
Понял и спасибо за уточнение.
На мой взгляд, Ваши комментарии не относятся к теме написанного выше текста. Я именно на это обратил внимание.
Здравствуйте!
Отвечу только на последний вопрос, так первые два не относятся к теме статьи: да, на этапе инициализации проекта, первом установочном совещании и, если потребуется, частично на этапе проектирования для уточнения некоторых технических деталей ранее разработанного решения.
Прошу всех не офтопить. Имеются другие каналы связи для высказывания своих проблем с оборудованием и ПО.
Наше оборудование в количестве десятки тысяч штук успешно работает в составе множества АСУТП уже более 10 лет.
О какой сырости Вы вообще говорите?
Вооо, пошли "разговоры о наболевшем" (((
А тема статьи совсем о другом.