Создание отдела АСУТП с нуля (организационные вопросы)

[Jackson]

И ещё, в довесок добавлю аргумент. Пусть выполнен хороший проект, согласован, объект отПНРен, сдан в эксплуатацию и работает нормально. Что- "чихнуло", какой-то контроллер дал сбой и вышел из строя. Случай негарантийный или это вовсе неизвестно до выяснения. Вызываются специалисты.
Два возможных сценария:
1) Если это свои специалисты, то копаться они могут сколь угодно долго - зарплата от этого ни больше ни меньше. Если вопрос спорный и специалистов и подразделений много, то начинается переписка актами, служебками и протоколами проверок, главная цель которых - вовсе не устранить неисправность и даже не найти причину, а снять вину с того или иного подразделения.
2) Если специалисты представляют стороннюю фирму, то едут они незабесплатно (что с гарантией пока непонятно), производство оплачивает дорогу, проживание и работу посуточно, а иногда и почасово. Время - как говорится, деньги. И, уж поверьте, ценник как правило такой, что заказчик бегает как ошпаренный, всячески обеспечивая приезжих специалистов всем необходимым. Все действия подчинены одной цели - устранить неисправность и поскорее спровадить специалистов.

Денежный критерий дисциплинирует, но к своим Вы его не примените в полной мере.

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

[Narywain]

Вообще я тоже сторонник аутсорсинга, особенно после некоторых ярких примеров с раздуванием IT-отделов, когда он становится больше производственных, набираем кучу хороших узкоспециализированных спецов которые 80% времени занимаются придумыванием себе работы... зато всё своё.

Ну а по поводу проектирования АСУ, могу привести пример из своей области (нефтепереработка), в некоторых проектных организациях существует 2 отдела, КИПовцы и АСУТПшники. КИПовцы проектируют нижний уровень, приборы, коробки и до кросс-шкафов, от кросс-шкафов и дальше - АСУТПшники, они и принципиальные схемы контуров управления делают и работают с поставщиками систем управления, ПАЗ, СОГО и т.д., ну у нас это как правило Yokogawa, Emerson или Honeywell. Ну а в программирование они не лезут, только логика. Система поставляется готовой, расставляй себе в контроллерных/операторной шкафы и инженерные станции, подводи питание, прокладывай внутрисистемные кабели их соединительные и пускай. Но насколько я понимаю такие "асушники" у вас уже есть...))

[Михайло]

Система поставляется готовой, расставляй себе в контроллерных/операторной шкафы и инженерные станции, подводи питание, прокладывай внутрисистемные кабели их соединительные и пускай. Но насколько я понимаю такие "асушники" у вас уже есть...))

Похоже да...

[Василий Иванович]

Не журись, Михайло. Свой инжиниринг имеет тоже плюсы. Если заказчик ни бумбум в системе (а с какой стати он будет разбираться, если он все на стороне заказывает), он будет платить двойные счета за услуги, имея при этом раздутую (и вдобавок неоптимальную) архитектуру системы впридачу. Особенно в случае системы PCS7, для которой характерен сравнительно большой объём инжиниринга, частые миграции и т.п. Поэтому на мой взгляд, может иметь смысл отдавать на сторону лишь крупные проекты, оставляя себе всё остальное.

[Михайло]

Поэтому на мой взгляд, может иметь смысл отдавать на сторону лишь крупные проекты, оставляя себе всё остальное.

Да... Таких малых объектов автоматизации много на заводе. Неприлично много. И потом служба нужна, чтобы вносить небольшие изменения в сложные проекты. А там гляди наберутся опыта родные хлопцы от АСУТП и сбацают проект посложнее и т.д.

Поговорю с одним замом по поводу темы диссертации, если он отфутболит, сменю направление темы и п...ц перспективе АСУТП на нашем предприятии... :)

[Михайло]

Все измы- через буфер (тестировщики).

Так... Вы хотите сказать, что должна существовать независимая группа тестеров, которая будет вносить изменения?

[Михайло]

ясно. :)

[Василий Иванович]

Но ни один изм не не должен пройти без тестирования и официальной приемки.

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

[Jackson]

Но ни один изм не не должен пройти без тестирования и официальной приемки.

Дмитрий, ну опять же обобщаете. Я бы не стал тестировать и официально принимать каждый пшик типа изменения уставки предупредительной сигнализации некритичного параметра.

Приёмка должна выявить степень соответствия поставленного оборудования требованиям ТЗ.

Кстати, ещё аргумент в пользу сторонних поставщиков. Своим родным проектантов после начала проектирования могут просто на словах высказывать пожелания, которых в ТЗ нет. ТЗ писал скажем нач.производства, а потом проектант встречает в курилке оператора этого цеха и выясняется что с его (оператора) точки зрения в ТЗ нет того, сего, а это понадобится, а вот это лишнее, а это и вот это вообще работать не будет. С одной стороны ТЗ отдано и работа пошла, дополнения/замечания - официально через того кто ТЗ выпускал. А с другой - люди-то все свои.... Дополнительная головная боль проектанту. Где-то проектант пойдёт на встречу, что-то выполнит что ТЗ не противоречит, но за рамки оговоренного выходит, мелочь какую-нибудь. Кто-нибудь на сдаче прицепится... Ну или разные варианты могут быть.

А для сторонних таких вариантов просто нет: есть заказ, есть ТЗ, есть заказчик - всё.

[Михайло]

Вот тут собрались три спеца: Дмитрий Милосердов, genelectric и Василий Иванович. Кто-нибудь из Вас в машиностроительном секторе работает?

[Jackson]

Вот тут собрались три спеца: Дмитрий Милосердов, genelectric и Василий Иванович. Кто-нибудь из Вас в машиностроительном секторе работает?

Тут собралось уже больше 700 спецов между прочим. :) Попрошу остальных не обижать.
Я долгое время работал на крупном производстве. Корабли строили.

[Василий Иванович]

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

[Василий Иванович]

Тогда уточняйте, когда говорите "ни один изм", а то "измы" бывают разные.

[Михайло]

Не твоего уровня контингент? :) Имеются сомнения в компетентности? :) Между прочим, я мог бы и вообще промолчать на эту тему и не делиться опытом (как и все остальные коллеги). Смысл какой тогда сюда писать, если советов не принимать? При чем здесь область производства? Все, о чем мы говорили- общепринятые грабли в ИТ. И не только в нашей стране. Хошь- пользуйся, хошь- делай как знаешь. никто тебе не навязывает мнения.

Да не обижайтесь, ребята! Я хотел высказать мысль малопрактичную... Машиностроение характеризуется большим количеством информации. Взять только трактор - он состоит из 5-15 тысяч деталей (точно количество не знаю), по каждой детали информация "гуляет" по заводу. С одной стороны, корпоративная ИС - это спасение, с другой стороны, оборудование иногда стоит, так как нечего на нем производить - информации нет и невыгодно подключать некоторую установку к АСУ.
Возникает вопрос: какие особенности приобретают АСУ машиностроительного сектора, благодаря этим аспектам?

[Jackson]

Возникает вопрос: какие особенности приобретают АСУ машиностроительного сектора, благодаря этим аспектам?

Тогда прошлый вопрос надо было уточнить: кто работал на автоматизированных автомобильных заводах? :)

По сути ничего не скажу, но отмечу забавный факт. Под Питером уже масса автомобильных заводов есть: Ford, Nissan, Toyota... Брат у меня в автосервисе работает. Пошли первые наши Питерские Форды (фокусы). Первый год всё было нормально, машина как машина. А потом стали попадаться до боли знакомые вещи: саморезы, забитые молотком, или вся электропроводка выполнена проводами одного цвета, хотя по фирменной документации маркировка как раз цветовая д.б..... А производство автоматизированное. :) Кто объяснит сей феномен с точки зрения АСУ? Аргумент "место проклятое" не предлагать.

[VADR]

Машиностроение характеризуется большим количеством информации.

Промышленная автоматитка вообще характеризуется немалым количеством информации :)

Взять только трактор - он состоит из 5-15 тысяч деталей (точно количество не знаю), по каждой детали информация "гуляет" по заводу. С одной стороны, корпоративная ИС - это спасение, с другой стороны, оборудование иногда стоит, так как нечего на нем производить - информации нет и невыгодно подключать некоторую установку к АСУ.
Возникает вопрос: какие особенности приобретают АСУ машиностроительного сектора, благодаря этим аспектам?

А вот это уже тема ближе к MES. Есть форум http://mesforum.ru/, но там, говорят, в основном теоретики обитают. Других мест обитания MES-овцев не знаю.

[Михайло]

Про АСУП-то понятно... У нас есть такой отдел, они на SAP R/3 сидят.

[Jackson]

Машиностроение характеризуется большим количеством информации.

Промышленная автоматика вообще характеризуется немалым количеством информации :)

Машиностроение от многих других процессов в этом смысле ни грамма не отличается. Так что не стОит думать что это какая-то особенная отрасль - не особеннее остальных, правда. :)

А теперь давайте уже уточнять, чтобы не толочь воду в ступе. Исходно спрашивали про создание отдела АСУТП. Так что нужно-то этому отделу создать в итоге: MES?

[Jackson]

А вот это уже тема ближе к MES. Есть форум http://mesforum.ru/, но там, говорят, в основном теоретики обитают.

Я там узрел только техподдержку по системе ФОБОС в огромных количествах.

[Теплоприбор]

Приятно читать споры умных людей.

Я работаю на предприятии, занимающегося разработкой и проивзодсвтом вторичной и функциональной аппаратуры. Мы выпустили бумажных регистраторов больше всех в мире. Предприятие развивается, пытаемся внедрить множество технологий (например KanBan,...). Наш стратегический партнер - Endress+Houser (Германия). Один из лидеров на рынке КИПиА. У них автоматизация производства налажена. НО!!! Работая как с партнерами я вижу множество проблемм. Встречаются и сбои в програмах управления производством и чисто человеческие факторы. Могут отгрузить совершенно не ту продукцию или забыть запрограммировать контроллер на плате.
Т.е. машиностроение - это обычная отрасль со своими проблемами. Со своими проблемами и сложностями данной отрасли приходится автоматизировать свои тех процессы по максимуму, устраняя одни проблемы и добовляя новые.

[Василий Иванович]

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

[Михайло]

Мне тоже интересно пообщаться с людьми, которые знают больше меня (у которых больше практики и опыта).

Развею сомнения:
1. Меня интересует именно проблема создания отдела АСУТП, а не АСУП. Но тема взаимодействия АСУП и АСУТП тоже интересна!
2. В нашем машиностроении не только сборка, но и изготовление деталей на станках (ЧПУ, ПЛК и простые на релейно-контакторные схемы), испытание узлов и т.д. Добрую половину нестандартного оборудования проектировало, проектирует и будет проектировать наше КБ.
3. Также меня интересует взаимодействие нижнего и верхнего уровня АСУТП.

С нижнего на верхний уровень посылаете все входы I, выходы Q и маркеры M контроллера? Какая типовая информация идет вниз?

[Василий Иванович]

Михайло, мы тут уже писали про аргументы за и против. Но главное, пожалуй то, что всё решают кадры. Если Вы действительно располагаете необходимым количеством толковых специалистов, можно и самим заниматься инжинирингом. Имея в виду, что эти люди могут разбежаться рано или поздно. С другой стороны, можно найти действительно хорошего интегратора, который будет делать недорого и по уму. Но ведь и оттуда могут кадры утечь.

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

[Михайло]

Михайло, мы тут уже писали про аргументы за и против. Но главное, пожалуй то, что всё решают кадры. Если Вы действительно располагаете необходимым количеством толковых специалистов, можно и самим заниматься инжинирингом. Имея в виду, что эти люди могут разбежаться рано или поздно. С другой стороны, можно найти действительно хорошего интегратора, который будет делать недорого и по уму. Но ведь и оттуда могут кадры утечь.

Эт точно! :)

[Владимир Николаевич]

Создание отдела АСУ не такое уж и сложное дело, я возглавляю фирму и занимаюсь АСУ вот уже 20 лет. Сейчас я работаю один, разрабатываю принципиальные и монтажные схемы, шкафы и щиты управления, комплектую оборудование, разрабатываю программное обеспечение микропроцессорных контроллеров, разрабатываю верхний уровень в СКАДА-КАСКАД. Для создания АСУ использую Чебоксарские контроллеры «РЕМИКОНТ» «МИКОНТ» «КОНТРАСТ» и Чебоксарскую
СКАДА-КАСКАД. Программирование контроллеров на языке «ФАБЛ» очень простое разрабатываю программы любой сложности все изучил самостоятельно, не смотря на то, что мне 60лет. Оптимальное количество сотрудников 3 человека, программист, конструктор и инженер КИП, квалификация должна быть высокой, зарплата 50-60 тысяч. ;)