Довольно часто я слышу такое мнение среди своих коллег и сотрудников, и, будем честными, на то есть причины.
АСУ ТП (автоматизированные системы управления технологическими процессами) — это когда у вас большое предприятие, конвейер, производство, очистные сооружения или что-то подобное и вам нужно отладить весь процесс в автоматическом режиме, чтобы все работало без участия человека, а человек только наблюдал на большом мониторе. Сюда же относится и инфраструктура здания: вентиляция, отопление, свет, вода, учет и т. д. Все эти системы можно объединить более емким словом — АСУ. И так как я работаю в основном именно в области инфраструктуры зданий, то дальше речь пойдет о ней.
Что не так с АСУ, с точки зрения программиста? Сложный и объемный фронт работы, при этом невысокие зарплаты. Программист на объекте чаще всего и швец, и жнец, и на дуде игрец. Помимо процесса разработки программного обеспечения, он обязан также понимать сам процесс, который автоматизирует. Необходимо разбираться в датчиках, исполнительных механизмах и нюансах процесса. Нужно уметь читать электрические схемы и разбираться во всех внутренностях шкафа управления, находить нестыковки в проекте и сборке. Добавим сюда панель оператора, на нее тоже нужно написать программу и увязать с алгоритмом. Надо разработать верхний уровень, установить SCADA-систему, настроить базу данных, отчеты, графики, написать кучу скриптов, увязать опять-таки с алгоритмом и с панелью оператора. Не забываем про сетевую инфраструктуру, коммутаторы, свичи и т. д. Добавим еще и графический интерфейс для панели и для SCADA-системы. По-хорошему этим должны заниматься несколько специалистов, но в реальности все делает именно программист, используя готовые библиотеки для экономии времени. Почему так происходит, я писал в этой статье. Стоит еще обязательно сказать о том, что редко компания работает только с одним вендором, чаще это 2-4 разных производителя железа и софта, отсюда разные среды разработки и разные языки, разные нюансы и подходы. Многовато выходит, да? И это все делается в полевых, не самых комфортных условиях, не в уютном офисе и точно не в кафешке. Даже перечислять непросто, а разобраться во всем одному человеку и довести до рабочего состояния крайне сложно, притом что вилка зарплаты — 80-150 тыс. р.
Что не так с АСУ, с точки зрения предпринимателя? Крайне сложно продать свои услуги дорого. Почему-то так сложилось, что вся эта работа стоит существенно дешевле, чем она должна стоить. Каждый раз приходится объяснять и обосновывать, почему заказчик должен заплатить за то или иное.
Звучит все это не очень перспективно, да? Прямо-таки антиреклама отрасли. Не знаю, как там сейчас у айтишников, но кажется, что их час работы оценивается прилично дороже. Мы же имеем что имеем, и нужно что-то делать и учиться работать с тем, во что уже влип по уши. На мой взгляд, есть тонкости и ошибки, над которыми стоит поработать, если вы предприниматель, руководитель или фрилансер, чтобы ваши услуги стоили дороже.
Давайте разбираться по порядку. Нужно понимать, что мы технари и общаемся и договариваемся тоже с технарями. Мы общаемся на техническом языке и решаем технические задачи. А технический язык — это не совсем про деньги. Я могу ошибаться, и наверняка есть исключения, но моя практика показывает именно это. Для примера: стоит задача — автоматизировать кондиционеры в офисе, вывести на удаленное управление и расставить несколько датчиков, контролировать температуру и влажность. Обсуждая с эксплуатацией эту задачу, вы будете решать, где ставить сервер, датчики, как тащить кабель, как сделать локалку, какие данные собирать и какой софт использовать. Так как монтаж кабеля, установка и настройка не могут быть дорогими, то выставить высокую цену будет сложно, придется искусственно раздувать и накручивать стоимость, а это неправильно.
Напрашивается выводы: нужно переходить с технического языка на язык маркетинга. Можно начать с банальной подмены слов. Понятия «объект» и «заказчик» давайте оставим строителям, а мы будем использовать «проект» и «клиент». Слова «монтаж» и «установка» тоже оставим там же, будем говорить «реализация» и «интеграция». Перефразируем нашу задачу так: проект мониторинга микроклимата офисного пространства и повышение общей энергоэффективности инженерных систем. Уже звучит интересно и для нас, и для клиента.
Идем дальше. Всю внутреннюю кухню по реализации проекта давайте оставим внутри компании. Такие слова, как «интерфейс», «шлюз», Modbus, SCADA, ПЛК и т. д. , будем использовать между собой и не выносить за пределы. Нет смысла погружать клиента во все технические тонкости. У клиента (читаем — бизнеса) есть свои проблемы и задачи, которые нам необходимо решить. Как именно это будет происходить — дело третье.
Следующий вывод: клиенту нужны комплексный подход и готовое решение его проблемы. При этом само решение мы, скорее всего, будем разрабатывать под каждого клиента и задачу индивидуально, так как в нашей отрасли подготовить по-настоящему работающее коробочное решение крайне сложно. Например, к нам обратилось крупное производственное предприятие, которое по понятным причинам расходует очень много электроэнергии. Нас попросили сделать систему технического учета разных потребителей, чтобы можно было понять, как именно она расходуется, вследствие чего в будущем оптимизировать этот расход. С нашей стороны, задача не слишком сложная. Необходимо развесить трансформаторы, поставить анализаторы тока, прокинуть пару сотен метров кабеля, развернуть и настроить SCADA-систему. В этом случае клиенту вообще не стоит вникать в эти подробности. Ему надо, чтобы в определенный момент времени в нужном месте появлялись необходимые отчеты. Чаще всего ему неважно, на каком оборудовании и на каком софте будет реализован проект, и нам от этого проще. Назовем это пилотным проектом по оптимизации энергозатрат производства и представим как готовое решение под конкретную задачу клиента.Важно понимать, что стоимость коммерческого предложения для клиента будет формироваться не из затрат на материалы + ФОТ + налоги + прибыль, а именно как стоимость, которую бизнес готов заплатить за решение своей проблемы, чтобы он (бизнес) дальше продолжил заниматься решением своих проблем и зарабатывать больше денег.
Резюмирую. Мы сейчас внутри себя все автоматчики. Контроллеры, SCADA, HMI, Siemens, Schneider. Мы на процесс смотрим изнутри, и большинство, с кем мы работаем, тоже видит процесс изнутри. Нам нужно общаться с клиентами на принципиально ином языке. Рекламировать себя и давать информацию именно как компания, которая реализует комплексно сложные технические проекты (не объекты). Правильнее всего будет ориентироваться на топовые диджитал-студии, к которым обращаются крупные компании за их компетенцией и проектами под ключ. Мы должны позиционироваться так же, как профессионалы, решающие комплексные задачи. Когда идет работа такого плана, как заменить контроллер, запустить вентиляцию, собрать шкаф, — это здорово, и на таком можно зарабатывать. Но в долгосрочной перспективе этим заниматься неинтересно, и к росту это не приведет.
Есть еще один существенный плюс отрасли АСУ, который я стараюсь использовать в последнее время. Организовав правильно процесс, отдавая монтаж и сборочную работу на аутсорс, можно реализовывать действительно крупные и серьезные проекты очень маленькой командой инженеров, буквально из 2‐4 человек
Комментарии (275)
ceH9l
01.08.2022 00:16+7АСУТП всё-таки более консервативная и медленно развивающаяся область. Освоив пару сред программирования основных ПЛК можно клепать проекты очень долго, порог вхождения не такой высокий. Проект десятилетней давности можно и сейчас залить на такой же десятилетний ПЛК и запустить в другом месте практически без правок, клиента интересует только чтобы всё работало. Обычно клиента действительно особо не интересует что там установлено, какой ПЛК, какой КИП, главное чтобы тз выполнялось (конечно были и исключения раньше, когда прописаны в тз модели ПЛК и т.п., но сейчас, когда все из РФ разбежались, уже точно пофиг на бренды). Да и большинство задач не поражают своей сложностью, никаких там тебе абстракций, замудрённых алгоритмов — обычно обработка сигналов с датчиков, да выдача команд на исполнительные механизмы. Да, тех процесс нужно понять, но это всё-таки не квантовая физика обычно, всё доступно и наглядно.
В общем отрасль конечно близка к IT, всё-таки программу для ПЛК надо написать, это да, но мне кажется особенность IT именно в постоянном осваивании новых инструментов, технологий, не думаю что АСУТПшнику так легко будет влиться. Но если получится, то почему бы и нет? По деньгам с IT сложно конкурировать конечно.
Chupakabra303
01.08.2022 10:55+6Если в ПЛК есть Ethernet (или другие менее известные "ITшникам" технологии, типа Ethercat, Profinet) то это уже IT. А ещё есть SCADA. А мониторинг и управление по Modbus TCP, это АСУТП или IT? А По SNMP? А лабораторная автоматизация, LabVIEW, python, web клиенты SCADA для доступа к мнемосхемам, telegram оповещение об авариях.
Про задачи тоже можно поговорить. Каскадные регуляторы, нечеткая логика, распознавание изображений. Все это реальные приложения из практики.
ceH9l
01.08.2022 13:48+3В АСУТП полно всяких интересных технологий, спору нет. Просто по моему опыту исполнители выбирают максимально простое решение и никогда не начнут использовать машинное зрение там, где можно просто поставить датчик, просто потому что это современно (в рамках одного и того же бюджета естественно). Ethernet-based протоколы тоже кажутся поначалу так сложно, но по факту с тем же Profinet возни в сто раз меньше чем с Profibus и это не усложняет, а упрощает наладку. Впрочем я сужу в рамках своей более узкой области промышленной автоматизации, возможно если речь идёт о более широкой области информационной сети завода — то там мне кажется уже чисто IT во все поля.
Просто хотел пояснить свой изначальный комментарий, что денег меньше в АСУТП не потому, что там мало сложных технологий, а потому, что (в РФ) основной принцип: проще = надёжней, а проще — это соответственно дешевле. Исполнители тоже не рвутся внедрить что-нибудь новенькое, больше денег это вряд ли принесёт, а вот головняка прибудет 100%.yerbabuena
02.08.2022 00:00+2а потому, что (в РФ) основной принцип: проще = надёжней, а проще — это соответственно дешевле.
И, надо сказать, они не так уж и неправы. OpenCV- это колдунство с багами и магами, а датчики - дело куда как более простое и работающее поэтому с гораздо меньшей фантазией и вкладом настроения. И это не только в РФ.
Sergeant101
01.08.2022 11:49+2Кто работал в АСУ тот поймет, что подключить два провода - не такая уж и тривиальная задача, какой интерфейс передачи данных может за ними скрываться: симплекс RS232, RS485, CAN, Hurt, а может токовая петля?
И таки да, например EtherCat'у с его чтением/записью в "пролетающий мимо" по сети фрейм аналогов в мире IT нет (я по крайней мере не встречал), так что я небыл бы столь категоричен называя промышленную автоматизацию отсталой.
SergeyMax
01.08.2022 13:55+1аналогов в мире IT нет (я по крайней мере не встречал), так что я небыл бы столь категоричен называя промышленную автоматизацию отсталой.
Если чему-то нет аналогов, то это не значит, что это "что-то" является каким-то преимуществом, а не например легаси сорокалетней давности (это к вопросу об EtherCap и TokenRing).
kipar
01.08.2022 14:13+1Ну Ethercat позволяет каждые 30 микросекунд отправлять команды и получать состояние каждого из 1000 устройств. А за пару миллисекунд можно и 65000 устройств опросить. Что там сопоставимого есть у айти?
SergeyMax
01.08.2022 14:17Ну Ethernet позволяет за секунду 100 гигабит передать, а какая у EtherCap скорость, 100 мегабит-то есть?)
kipar
01.08.2022 14:28100мбит полный дуплекс, я так понимаю стандарты описанные на википедии про 1 и 10гбит просто не слишком нужны - не фильмы же отправляем. А сколько времени Ethernet будет отправлять пакеты тысяче устройств и потом собирать ответы (ну допустим запрос можно мультикастом отправить, но ответы то все равно будут по-одиночке приходить)? И за какое время он перестроится в случае разрыва одного из проводов?
SergeyMax
01.08.2022 14:40Дак я про что вам и говорю, то, что в ИТ выкинуто за ненужностью сорок лет назад, в АСУТП помирает долго, мучительно, с мантрами "всё и так работает" и "это не нужно". В принципе, в каком-то смысле это так и есть, для передачи нескольких байт от датчиков гигабит тут и не нужен, просто важно понимать, что это не передний край технологий, а задний)
kipar
01.08.2022 14:46И все-таки. Сколько времени потребуется в 100гбитном езернете, чтобы сигнал дошел до тысячи устройств и вернулся к отправителю? Миллисекунды?
Ах да, а сколько займет перестроение сети если один из проводов окажется разорван?
Sergeant101
01.08.2022 14:51+2Нет, не миллисекунды, имел опыт с промышленным Ethernet/IP, передача данных от камеры технического зрения до TCP сервера на контроллере, время отклика с обработкой больше секунды (в среднем, потому что от раза к разу менялось).
Вообще TCP негоден для автоматизации из-за неопределенного времени доставки... но это отдельная история.
SergeyMax
01.08.2022 15:06И все-таки. Сколько времени потребуется в 100гбитном езернете, чтобы сигнал дошел до тысячи устройств и вернулся к отправителю? Миллисекунды?
Я чот не понимаю, вы осознаёте, что EtherCat - это просто протокол поверх довольно древней редакции Ethernet?)
kipar
01.08.2022 15:31Это улучшенный Ethernet. Обычный Ethernet предполагает соединение звездой, что в случае тысячи устройств означает отдельный провод идущий к каждому из тысячи шкафов (либо тысяча свитчей на пути сигнала, если мы решим все-таки соединить их цепочкой).
EtherCAT позволяет сделать из Ethernet кольцо, причем добавление новых устройств не будет вносить практически никакой задержки в линию (устройству не надо ждать конца приема фрейма чтобы начать отвечать). Да, кольцо было придумано давным-давно. Но в итоге Ethernet не обеспечивает тех параметров сети которые обеспечивает EtherCAT.
SergeyMax
01.08.2022 16:00+3Это улучшенный Ethernet
Честно говоря он больше напоминает поднятый из гроба token ring, прикостыленный поверх более современного протокола)
kipar
01.08.2022 16:08угу. Так и какую частоту опроса для 1000 устройств (ну или для 65к устройств, если 1000 слишком мало чтобы замерять) в локальной сети обеспечивает более современный протокол?
mayorovp
01.08.2022 16:05Ethernet вовсе не обязательно предполагает соединение строго "звездой". Тот же 10BASE-T1S позволяет 8 устройствам "сидеть" на одной линии.
kipar
01.08.2022 16:19Судя по вики
Задержка передачи пакетов составляет от 2 до 4 микросекунд, по сравнению с 1-12 микросекундами в 1000Base-T
и значит даже если у нас будет 1000/8 = 125 свитчей, суммарно они внесут задержку в 250-500микросекунд, что на порядок больше "поднятого из гроба" протокола.
Sergeant101
01.08.2022 15:41+1Вы не совсем уловили суть: на ведомых устройствах специальный контроллер сети, работа исключительно на 1 уровне OSI, что и позволяет читать/писать данные на лету, без всяких там запросов-ответов и TCPшных рукопожатий, а то что EtherCat может работать поверх Ethernet не обращая на него внимания - это фича.
SergeyMax
01.08.2022 15:52+2без всяких там запросов-ответов и TCPшных рукопожатий
А где связь между ethernet и "всякими там запросами-ответами и TCPшными рукопожатиями"?
Sergeant101
01.08.2022 16:27Ethernet подразумевает механизм контроля несущей, то есть ожидание своей очереди заговорить, EtherCAT ожидает одного единственного на всех фрейма, Ethernet подразумевает прием и передачу данных как два отдельных действия (и фрейма соответственно), у EtherCATа фрейм один на всех, и операции чтения/записи идут в один фрейм, без буферизации и ожидания, на лету. Передача данных по Ethernet подразумевает установку канала связи, EtherCAT канал связи не нужен, поэтому а его модели уровень только один - физический.
П.С. к слову: тот же ProfiNET то же вроде Ethernet, но не Ethernet - у него тоже нет контроля несущей, как у него коллизии разрешаются я не знаю, ибо это походу секрет фирмы.
SergeyMax
01.08.2022 16:36+2EtherCATа фрейм один на всех, и операции чтения/записи идут в один фрейм, без буферизации и ожидания, на лету
Один фрейм на всех — это очень хорошо, до тех пор, пока один датчик не начнёт срать в этот один на всех фрейм, и не положит весь сегмент)
Sergeant101
01.08.2022 16:50А вот запись может идти только во фрейм, а фрейм формирует только ведущее устройство!
Ну как то так )
Про Token ring - и правда очень похоже, возможно даже идею из него почерпнули, но, как говорится, все новое - это хорошо забытое старое.
П.С. упс, не про то ответил )
А вот это уже совсем другая тема, датчики нужно периодически менять в рамках планово-профилактических работ, и тогда отказов не будет.
F0iL
01.08.2022 17:15+3датчики нужно периодически менять в рамках планово-профилактических работ, и тогда отказов не будет.
Своевременная замена датчика не поможет предотвратить отказ из-за бага в прошивке процессора этого датчика, проявляющегося в ничтожно редких случаях, или, например, из-за воздействия на него космических лучей. Поэтому хорошо когда отказоустойчивость достигается комплексом мер, в том числе и на уровне протокола.
Sergeant101
01.08.2022 19:51+1Если модуль изначально бракованный его найдут ещё при наладке, а вообще сейчас принято делать модули, выставляющие значение по умолчанию в случае аварии, то бишь выводящие систему в безопасное состояние.
F0iL
01.08.2022 20:02+1Перечитайте внимательнее, это не имеет отношения к производственному браку конкретного модуля :)
Sergeant101
01.08.2022 20:36Там действительно всё сложно, скажу конкретно за связь: в модулях автоматики есть прям конкретные настройки на случай обрыва соединения - установка сигнала на выходе + с какой скоростью сигнал будет формироваться если он аналоговый.
При выходе из строя модуля, даже без резерва по сети, при правильной настройке, например манипулятор не уронит груз на пол, а пойдёт в исходное положение.
Обидно, досадно, но ладно - штатная ситуация.
kipar
01.08.2022 17:11Ну один то отказ предусмотрен (если используем Ethercat Redundancy). (дальше мое понимание, скажу сразу что не пробовал) Отправляем фрейм который закольцует порт у первого устройства. Если сигнал теперь проходит - открываем порт и закрываем у второго. Так пока не найдем у какого номера проблема. С другой стороны отправляем фрейм который закольцует порт у следующего за неисправным устройства. Дальше ведем опрос с двух сторон.
SergeyMax
01.08.2022 20:54Ну один то отказ предусмотрен
Одно дело, когда предусмотрен один отказ на один датчик, и другое дело, когда один отказ предусмотрен на десять датчиков (про 65000 вообще посмеялся). В общем, идея взять провод, и соедить кучу машин последовательно как бы настолько не нова (и это не обязательно про токен ринг, а вполне даже про коаксиальный эфирнет), что даже странно это обсуждать.
Sergeant101
01.08.2022 22:17Коаксиалка ловит помехи прям на ровном месте, скорость низкая.
EthercCAT это скорее про робототехнику: чтобы быстро, точно и в срок.
Идея не нова, Нова реализация.
Sergeant101
01.08.2022 14:46+2Ну что вы, сударь! EtherCat это новейшая технология - появился в 2003.
Гигабитные скорости, кабель только F/FTP, гарантированное время доставки, поддержка резервированных каналов связи.
https://ipc2u.ru/articles/prostye-resheniya/obzor-protokola-ethercat-i-ustroystv-na-ego-osnove/
Antra
01.08.2022 20:28А насколько специалист АСУ свободен в своем выборе?
При построении условной ИТ системы можно выбирать из огромного количества технологий, самостоятельно их интегрировать между собой... Разве в АСУ так же?
Вариантов, конечно, много. Но мне кажется, что коли выбрали производителя, он достаточно жестко диктует свои требования. Это, конечно, не кубики Лего, соображать и выкручиваться надо, но в "самописное АСУ" на серьезном производстве я слабо верю. А если о каком-то небольшом речь - на таком много при всем желании не заплатят. Там и ИТшники вряд ли жируют.
MaxEkb77
02.08.2022 11:19Ага нам надо доехать до концевика и остановиться ;) в реальности вылетает в приличное количество кода.
Affdey
01.08.2022 11:53Так то оно так, но не всегда. Заказчики уже хотят чего-то поновее, получше алгоритмы с большей самостоятельностью, более точные измерения и отклики. Вот реально, бывает не найти даже АСУ оборудования под ТЗ, только уровень научно-лабораторного может помочь, но там проблемы с интегрированием в промышленное АСУ.
АСУ консервативно не более чем производственный мир, мне так кажется что жизнь инструментов в IT похожа на поп-группы 2000х, а в АСУ остаётся проверенные решения.
s60
01.08.2022 15:02Вот реально, бывает не найти даже АСУ оборудования под ТЗ
всегда было интересно что делают такие ТЗписатели, не получив ни одного ТКП под на свои хотелки?Affdey
01.08.2022 17:25Не знаю. Бывает, что одно ТКП есть от дружеской фирмы, и такое ТЗ это лишь защита от чужих в тендере. А что они поставят по факту - да никто не проверяет. (радиатор от Газели на пром. оборудовании, компьютерные колонки в качестве пром. сирены)
s60
02.08.2022 09:55тю, как всё просто… а я голову ломал как же они будут жить, если такого штатно не производят… заказное? у кого? космо-цены и парсек-сроки… или упростят свои хотелки?…
Affdey
02.08.2022 14:04А бывает наоборот, заказчик хочет повторить имеющееся оборудование без отступлений. И там выползают бумажные(!) осциллографы, электромеханическое колдовское АСУ, алгоритмы на схемах времён Гагарина... и прочие вещи из музеев. "А нового мы боимся, не надо нам сенсорных экранов"
s60
02.08.2022 14:12и как тогда происходит? гагаринские схемы или сенсорные экраны?
а что за предприятия такие? насколько они конкурентны?
s60
01.08.2022 15:00Освоив пару сред программирования основных ПЛК можно клепать проекты очень долго, порог вхождения не такой высокий.
вы это про формошолепов-сайтоделов?Проект десятилетней давности можно и сейчас залить на такой же десятилетний ПЛК
это если у тебя есть виртуалка с Windows XP, на которой твоя десятилетняя IDE для ПЛК сохраниласьклиента интересует только чтобы всё работало. Обычно клиента действительно особо не интересует что там установлено,
сегодня не интересует, а завтра заинтересует, кто ему это барахло подшаманить сможет… десятилетней давности…
Pleshivchev
01.08.2022 22:32+2Достаточно столкнуться с задачей пид регулирования, а пид регулятор написать в ручную не используя библиотеки и функциональные блоки как в CFC. И тогда сразу появляются замудренные алгоритмы и сложности. Приходится даже вспоминать теорию автоматического управления*( быть честным, не вспоминать, а учить заново).
Akon32
02.08.2022 00:55А что сложного в реализации ПИД-регулятора? ЕМНИП там всего десяток арифметических операций?
eteh
02.08.2022 15:07+2А реализация и наладка хотя бы 2х контурной ПИД системы — тоже то еще веселье, я их применяю, а многие боятся и обходят стороной. Причем в химических процессах еще и мат. моделирование приходится помнить для наладки чего-то посложнее (оно неплохо помогает более-менее адекватно выставить стартовые значения).
s60
02.08.2022 15:13а критерий Найквиста хоть раз пригодился?
eteh
02.08.2022 15:22Нет — ЦОС в основном меня «мимокрокодил»… Обычно фильтра стоят уже и в ПЛК и на датчиках — смысла работать с ними не вижу. Обычное усреднение сделать можно и готовыми библиотеками.
s60
02.08.2022 15:30ЦОС? что такое ЦОС?
Обычно фильтра стоят уже и в ПЛК
А реализация и наладка хотя бы 2х контурной ПИД системы
так и ПИД регулятор «уже в ПЛК» есть…eteh
02.08.2022 15:38Товарища Котельникова_Найквиста критерий по моей памяти нужен либо для цифровой обработки сигналов, чтобы адекватную частоту дискретизации выбрать, либо для проверки адекватности частоты выборки обратной связи в сложных системах. Так вот — первым я не занимаюсь, т.к. не проектирую датчики и их фильтра, а второе реализуется программно, но кроме института я эти графики нигде не рисовал специально, т.к. для начальных значений настроек систем автоматического регулирования проще использовать специальное программное обеспечение.
s60
02.08.2022 15:46
товарищЪ Найквист — Михайлов нужен, чтобы «судить об устойчивости замкнутой системы управления»eteh
02.08.2022 15:54Ну тогда мы друг-друга не совсем поняли) А так да — проверку на устойчивость системы я делаю в любом случае, но есть исключения. Например когда идет несколько методов регулирования — т.е. есть граничные точки и при их достижении регулировку осуществлять возможно только экстренным методом, чтобы не рванул реактор с химией грубо говоря, там расчеты эти имеют смысл только в границах этих точек, когда регулятор может вывести процесс на оптимальный режим без применения кардинальных мер.
Daddy_Cool
01.08.2022 00:20+1Так рыночек и порешал.
Чем проще работа и чем быстрее она осваивается - тем меньше она стоит.
Правда есть еще важный нюанс - трудоемкость. Скажем работать грузчиком просто, но не все пойдут ибо нафиг, здоровье дороже. А тут - крупноблочные задачи, по сути - конструктор. Да - надо иметь некий интеллект, но научные сотрудники в НИИ тоже не миллионы зарабатывают.
lymes
01.08.2022 00:44+6Можно подумать у нас не крупноблочные. Разработка, имхо, становится все менее и менее креативна, - готовые паттерны архитектур, линтеры (шаг вправо, шаг влево - ворнинги), готовые библиотеки на любой вкус, сниппеты со stackoverflow.. Ремесленничество.
Когда-то в универе (я учился не в РФ), у нас был курс лабораторных по промышленному программированию на PLC Mitsubishi. Язык Ladder, непростая штукенция для освоения. Простейший хелло_ворлд, конечно, просто нарисовать, но реальные задачи с кучей датчиков (и ещё и аналоговых) и обратными связями - тот ещё квест.
Daddy_Cool
01.08.2022 01:38Значит пока рынок растет. А это системные процессы. В результате должно быть по Марксу - ЗП должна стать равной стоимости воспроиводства рабочей силы.
BigBeerman
01.08.2022 06:05+4LD штука непростая для программиста, а вот для электрика наоборот, собсна, он для того и придуман, чтобы просто переводить релейные схемы в программу для ПЛК.
Viktorinox
01.08.2022 11:18+1Поддержу , LD очень удобен тем кто хорошо понимает , или разбирается в контактно -релейных схемах . В начале своей карьеры была у меня одна задачка , перевести установку пароочистки овощей DSA -200 с реле времени коих в схеме данной установки было около 12 на один контроллер .
Причем это был даже не ПЛК а скорее программируемое логическое реле Lovato , если правильно помню .
Задача решилась буквально за вечер .
То же можно сказать про язык FDB.
Sergeant101
01.08.2022 11:52+4LD плох загромождением рабочего пространства: там где программу можно реализовать в три строки на ST, десять строк на IL, у LD уйдет пара экранов.
При большом объеме кода сложно в этой лапше ориентироваться. Хотя может это и дело вкуса.
П.С. программа с двенадцатью реле времени на программируемом реле - такой себе показатель, хотя это уже на пару порядков удобнее чем собирать шкаф автоматики с двенадцатью физическими реле времени.
AndreyUA
01.08.2022 14:00+1Тут я с вами не соглашусь. LD получается больше там, где его не нужно применять. ST по умолчанию используют те, кто пришел в АСУТП из программирования.
Посмотрите разницу
LD
или ST
If (310V1Mem Or SeqManG1.InClose) and (not SeqManG1.InOpen) and Op_power Then310V1A:=True;%MW7193.0:=True;end_if;В LD проще отладка и он нагляднее, в нем удобно делать обработку входов-выходов. Любая математика, последовательные действия и переходы на нем делать сложнее. Для этого есть ST.
Sergeant101
01.08.2022 15:52+1Пример конечно за уши притянутый: где вы видели программы из одной линии LD, плюс у вас чистая релейка без матеши и вызова функций.
Мой посыл бы в том что сложные проекты при большом объеме кода с вычислениями, вызовами, преобразованиями, адресной арифметикой начинают растекаться по странице.
Попробуйте просто разделить два числа и привести их к целому при условии достижения счётчика определенного значения. LD сразу становится громоздким, даже в одну строчку.
AndreyUA
01.08.2022 17:17+3В том и дело, что в проектах "чистую релейку" надо писать на LD. И ее обычно очень много и она составляет основную часть кода. А математику выносить в отдельные блоки на ST. Когда вам нужно написать что-то типа этого
в ST у вас будет куча вложенных условий, в которых вы запутаетесь сразу, а LD все наглядно и понятно. Я писал выше, что математику проще вынести в отдельный блок на ST, а вы мне предлагаете разделить два числа. Tia Portal, например, позволяет сейчас в одном блоке в разных нетворках использовать разные языки. В Unity Pro есть блок Operate, где вы можете спокойно написать любой код.
mayorovp
01.08.2022 17:31Не очень и сложно выглядит ваша первая картинка, с аналогичным количеством условий в коде я как-то разбирался, пусть и при написании веб-интерфейса. А ведь их вовсе не обязательно записывать в одном месте!
А вот на второй — кошмар полный: код написанный в одну строчку, да ещё и спрятанный за диалогом настроек...
AndreyUA
01.08.2022 17:51+1Не очень сложно он выглядит в LD, а в ST это 20 условий, скомпонованных так, что без бутылки не подойдешь, я не готов сейчас этот код переписать в ST без ошибок :) И при отладке отследить какой сигнал не дает правильно работать в коде на ST будет очень сложно, в отличие от LD, где наглядно видно зеленую и красную полоску.
Второй тоже удобен, это как отдельная функция с математикой, которая написана на ST и которую можно открыть по клику. На LD это было бы не так красиво и состояло еще из 3-4 больших прямоугольников. Там не нужно смотреть, какой сигнал не отработал и переменная не поделилась на 2.
mayorovp
01.08.2022 17:59Не очень сложно он выглядит в LD, а в ST это 20 условий, скомпонованных так, что без бутылки не подойдешь, я не готов сейчас этот код переписать в ST без ошибок :)
Понятия не имею как оно может выглядеть в вашем ST, но на C# или Rust я был бы готов это всё записать если бы понимал что на этой схеме вообще происходит.
Второй тоже удобен, это как отдельная функция с математикой, которая написана на ST и которую можно открыть по клику.
Отдельная функция с математикой должна лежать в отдельном текстовом файле, который бы открывался как файл в отдельной вкладке, а не по клику в модальном диалоговом окне.
DimanDimanyich
02.08.2022 09:00ну напиши здесь. А человек выложит на STL.
типа
A M0.1
O M0.0
A M0.2
= M0.3
= M0.4
Отладка в степе будет виден каждый этап RLO. Так же как и в LAD, для начинающих очень понятно.
ЗЫ в примере на ST ошибка, присвоение TRUE есть, а False - нет. Или ElseIf нужен или типа такого
M0.4 := (M0.1 Or M0.0) And M0.2
M0.3 := M0.3
mayorovp
02.08.2022 10:14Говорю же, я не понимаю что на этой схеме происходит. Вот эта цепочка фронтов сверху — это ожидание последовательности? Или вы фронты как-то через "И" умудряетесь объединять? Или это вообще не фронты?
AndreyUA
02.08.2022 13:38примере на ST ошибка, присвоение TRUE есть, а False - нет.
Согласен, накосячил, else еще надо дописать. В LD я бы так не накосячил. По идее, правильней было бы написать:
310V1A:=(310V1Mem Or SeqManG1.InClose) and (not SeqManG1.InOpen) and Op_power;%MW7193.0:=310V1A;
Yukr
01.08.2022 16:39+1добавлю - LD хорош для работы с импульсными сигналами, отслеживания фронтов и т.п.
DimanDimanyich
03.08.2022 09:46а также таймерами, счетчиками и прочие прелести. Плохо/удобно делать циклы, тут как раз SCL рулит.
mapnik
01.08.2022 00:56+34Когда слово "IT" ("информационные технологии") стало синонимом фразы "веб-программирование"? Разве можно сказать, что АСУТП - это не IT? Я где-то отстал от темы?
Jian
01.08.2022 06:13+1Именно так! Всю жизнь мой АСУТП-диплом считается IT-дипломом.
Hikonomuro
01.08.2022 08:32+3Админов, мониторинг и тот же техпод почему-то тоже сейчас к ИТ забывают причислять. А ведь казалось бы.
Flidermouse
01.08.2022 15:03Воистину 220200! школота-сайтоделы, вайтишники с курсов и самоучки с ютуб-образованием и примкнувшие к ним скрам-мастера, продакты и ит-бизнеспартнёры считают что автоматизация это скрипт на питоне. Они забыли, а многие и не знали «origins»!
altervision
01.08.2022 08:35+7Тогда же, когда к ИТ приравняли ручных тестировщиков-кнопкотыков, копирайтеров, HR, смешивателей смузи и уборщиц, способных мыть полы не выдирая провода из розеток.
АСУТП всегда было ИТ. От темы отстали исключительно модные любители пить смузи и играть в эджайл со скрамом вместо работы.
net_racoon
01.08.2022 09:48+1Дык давно уже. Далеко ходить не надо. Открываешь любую статью на хабра с заголовком: "Как ITшнику сделать...". А там в тексте сразу: "5 лет назад я начал кодить на Пайтоне...". Сейчас началась эра разрабов и прочих причастных, потому про остальных ИТшников забыли.
Komrus
01.08.2022 16:38+2Есть нонче такой забавный (или не очень) перекос:
Когда в СМИ ( а также и в ШирНарМассах и среди власть предержащих...) говорят "врач", то обычно понимают, что врачи бывают не только терапевты, но и хирурги, окулисты и т.п.
А вот когда говорят "ИТшник" - то зачастую по-умолчанию туда причисляют токмо программистов. АСУТПшники, системные интеграторы и прочия - как-то за скобками остаются.См., например, последние меры партии и правительства по поддержке ИТ отрасли...
AlexS00
01.08.2022 01:07+1Единственная причина которая увеличивает зарплату работника - это дефицит подобных работников. Навряд ли то, что расписал автор резко увеличит спрос на работников АСУТП, а следовательно и не увеличит их зп.
W_Lander
01.08.2022 13:37+4Да, возможно это классика, но не всегда. Например школы и детсады недозагруженные из-за дефицита кадров, но о росте зп никто не слышал. Как следствие - группы по 35 чел. Учителей "заставляют" брать двойную нагрузку с прибавкой 0.5 к базовой 20. В больнице я вообще офигел, когда каждый день одна и та же медсестра приходила и на дежурствах в т.ч. Говорит никто не идет работать, да еще зп уменьшили с 20 до 18. Как там люди держаться для меня загадка, а ведь это наш фундамент. Чувствуешь себя порой избалованным слизнем, хоть и с красными глазами. Хотя может эти профессии уже не так важны по сравнению с оптимизацией рекомендательных систем и рекламы.
Brrastak
01.08.2022 20:29+1Потому что образование/медицина государственные и законам рынка не подчиняются
AlexS00
01.08.2022 20:54+2Например школы и детсады недозагруженные из-за дефицита кадров, но о росте зп никто не слышал
Выбросьте эту пропагандистскую чушь из головы. Никакого дефицита учителей и врачей нет.
Дефицит - это неудовлетворенный платежеспособный спрос. Ключевое слово в вашем примере, это не "неудовлетворенный ", а "платежеспособный". У кого деньги есть нанимают нянечку, идут в частные поликлиники и т.д. А насчет "спроса" со стороны государства, так он формальный, спрос-то. В пропагандистских целях. Нельзя же сократить всех учителей и врачей. Надеюсь, Вы не верите, что у государства нет денег.
Неплохо об этом написал здесь, на хабре, один инженеришка-киповец Дефицита нет, платить не нужно
Debianer70
01.08.2022 04:21+15Подпишусь под каждым словом статьи. Сам работаю мастером АСУТП, и, должен заметить, что даже простая задача (та же вентиляция) требует довольно много сил и умений. Спроектировать, проложить кабели (не забываем про ПУЭ!). Правильно и красиво (эстетика монтажа) подключить. Написать софт... Под ту же вентиляцию - климат-контроль, контроль загрязнения фильтров, прием сигналов с пожарной сигнализации, отключение вентиляции и закрытие заслонок воздуховодов при пожаре...
А если взять что-то помасштабнее, то там уже даже софтовых проблем и задач несоизмеримо больше. Пример из недавних: СПКБ (станция перекачки конденсата бойлерной). Одних задвижек на паропроводах 53 штуки. Чуть больше сотни датчиков температуры, около 30 датчиков давления. Четыре насоса, которые, не просто вкл/выкл, а еще и с контролем наличия воды или пара в трубопроводе. Управление с HMI панели и в полностью автоматическом режиме. И не дай бог какой баг в софте - всё просто рванет. А так - да, просто всё. )) Прошивку на СПКБ, кстати, писАли и отлаживали полгода, т.к. проект по мере внедрения оперативно менялся. Что, впрочем, привычноSergeant101
01.08.2022 06:42+6Ты не забывай что от правильной работы твоей системы в критической ситуации будет зависеть жизнь людей (см. Зимняя Вишня), а это как ни крути офигенская ответственность.
Jian
01.08.2022 06:45+2А что с отделом тестирования? Ведь, это именно их задача убедиться, что в критических ситуациях всё будет работать.
Sergeant101
01.08.2022 06:54+6Ты просто не знаешь отечественную реальность, где инженер АСУ по три должности по сути совмещает, какие тестировщики, тем более что отрасль скатывается до того что не каждый суть электромагнитной совместимости понимает, а это трудноуловимые, часто совершенно случайные по времени, ошибки, вызванные наводками на линиях цифровой и сигнальных связей. Они вообще не тестируются практически никак, а избежать их можно лишь строгим следованием инструкций по совместимости.
П.С. да и испытать систему (протестировать) можно лишь при работе, а это дополнительные риски.
П.П.С. испытывать системы можно конечно в специальных лабораториях, но это дополнительные затраты, на которые отечественные компании никогда не пойдут, ибо им проще, условно говоря, потерять десять миллионов из-за плохо работающей системы, чем потратить миллион на испытания.
Strohmann
01.08.2022 07:28+23Отдел тестирования. Ах-ха-ха-ха. Как правило, Находится по соседству с отделом дизайна человеко-машинного интерфейса. И, как правило, все эти отделы представлены одним и тем же человеком, с должностью инженер АСУТП.
Autonomnoe Автор
01.08.2022 09:43+11
То чувство когда ты монтажник, и проектировщик, и программист, и наладчик
Affdey
01.08.2022 12:00+1Отдел тестирования это тот же программист, при разработке, когда можно запустить код в симуляторе и поймать основные ошибки, и при ПНР, когда всё железо начинает работать, там и ЭМ совместимость, и чувствительность и шумы датчиков, и имитация кривых рук оператора тоже. Да, с помощниками "попинай датчик". Но прям отдела тестирования не встречал никогда.
AndreyUA
01.08.2022 14:07+1В основном, инженер АСУТП должен поговорить с заказчиком, выяснить, как должно работать оборудование, написать ТЗ для заказчика, разработать электросхемы, написать программу для PLC и SCADA, съездить на объект, сделать там шеф-монтаж, запустить и написать документацию.
s60
01.08.2022 14:53+5съездить на объект, сделать там шеф-монтаж, запустить и написать документацию.
нахер документацию, АКТЫ! он должен привезти подписанные акты! без них может не приезжать
s60
01.08.2022 15:05А что с отделом тестирования? Ведь, это именно их задача убедиться, что в критических ситуациях всё будет работать.
они деруться за право отладить вашу поделку, так что победивший ответив вам в понедельник! :) (с)
Autonomnoe Автор
01.08.2022 09:40+1Да, это один из главных моментов, надо было написать об этом. Даже банальная работа с вентиляцией, не корректно сделал расписание, она проработала всю ночь, это траты. Можно свет погасить случайно в критической зоне, можно линию остановить с миллионными штрафами, можно, короче, очень много как накосячить)))
Komrus
01.08.2022 16:42Наилучшее "достижение", что слышал от лично знакомых - закрыть в процессе отладки не тот клапан и включить вентиляторы вытяжки на полную...
"Схлопнулось" пара десятков метров магистрального венткороба. Смонтированного за уже готовым потолком :(((F0iL
01.08.2022 17:08+4Из того что наблюдал своими глазами в нефтянке:
Насосы качают в емкость. В емкости датчик уровня заведен на контроллер (чтобы вовремя отключить насосы), продублирован еще одним датчиком с релейной защитой. Не сработали обе защиты, в итоге нефть через трубу наверху емкости ударила фонтаном в небо, и потом еще несколько дней нефтяники матерясь отмывали паром все железо вокруг, а деревья так и стояли покрашенные в черный цвет.
Из-за ошибки то ли в программе, то ли при монтаже (инвертирование релейного выхода), отключился насос дозатора реагента. На улице зима, в результате жидкость текущая из скважин замерзает нафиг. Сработала защита по сигналу манометра, а вот если бы не сработала - то трубопровод прорвало бы с последущим разливом нефти в реку неподалеку.
Гидроприводы переключателей скважин многоходовых горят, если подавать на них сигнал включения больше определенного времени и не выдерживать паузы между переключениями. Несколько сгорело.
Ну и по мелочи - блок управления ТЭНов при записи в него через Modbus пороговых значений, не входящих в диапазон, указанный в документации, вместо того чтобы вежливо отклонить некорректные значения или хотя бы просто не использовать их, предпочтя какое-то значение по умолчанию, трогался кукухой и врубал печку на полную, когда на улице было +30 градусов. Понятное дело, ТЭНы сгорали :)
frozzzen
01.08.2022 04:24+3Обычная история. Из рандомного "хорошего инженера" обычно получается так себе продажник и горе-предприниматель. Разные наборы компетенций. Даже в детских книжках для стартаперов описан минимальный сет из хакера, хастлера и хипстера. То неспроста. Иначе эта балалайка(бизнес) просто не работает.
Касательно ограниченности самой сферы деятельности асушника. Я бы так не сказал. Есть достаточно бысторастущих веток на этом дереве. От интернета вещей до робототехники. Хотя, если человек решил посвятить жизнь подбору коэффициентов ПИД-регулятора, то нет. Вот зарплату бы побольше. Это да.
Debianer70
01.08.2022 06:09+2Да, вы правы, в АСУТП много разнообразного, от тех же регуляторов и до WiFi связи между точками; оптика и физика, регуляторы, термометры, двигатели, заслонки, приводы, кран-балки - всего не перечислить. На последнем моем объекте мы внедряли 27 разных систем - конвейерное оборудование (датчики скорости, вибрации, натяжения, веса и т.д.), система резервной связи, аспирация, орошение, пожаротушение, СОСНВ (система оптического считывания номеров вагонов), КГУ (контрольно-габаритные устройства) и т.д. И да, зарплату бы хотелось немного больше; соразмерно работе, а не на хлебушек
frozzzen
02.08.2022 05:45И есть Matlab и Simulink внутре его. Откуда разверзаются бездны и открываются глубины. И появляются какие-то парни из Беркли и MIT. Ещё какие-то турки и китайцы.
Ares_ekb
01.08.2022 06:19+12Я думаю, что дело не только в АСУ ТП. Например, я работал в медицинском центре (достаточно крупном, который мог себе позволить и ИТ отдел, и научный отдел). Чем я там только не занимался:
1) И аналитикой. Нужно досконально разбираться в процессах, в документации, отчетности - для этого общаться со всеми от работников регистратуры до директора, в том числе с сотрудниками из смежных учреждений. После того как я уволился мне ещё лет 5 люди звонили из разных больниц.
2) И разработкой. Часто считают, что в медицине устаревший стек, что там всё пишется на Delphi и тяп-ляп, но у нас это было не так. Код писался на C#, мы сначала сами писали свой движок, потом взяли DevExpress XAF, у приложения было два интерфейса - десктопный на WinForms и веб на ASP.NET, что было достаточно прогрессивным для того времени. Ещё у нас были информационные киоски на WPF.
3) И BI-разработкой. С помощью SSIS собирали данные. На SSAS делали OLAP кубы, чтобы люди сами получали нужные отчеты в Excel. Это были 2008-2013 годы, когда это вообще не было мейнстримом, в нашем городе были единичные такие вакансии.
4) И аналитикой данных. Врачи собирали данные, мы их анализировали в существующих пакетах (SPSS, Statistica), писали свои плагины на Excel-DNA, писали свои приложения с разными заложенными решающими правилами для поддержки диагностики заболеваний (и даже продавали их другим медучреждениям - к вопросу о маркетинге, бизнес-ориентированности и т.п.). Пытались использовать process mining. Пытались заниматься анализом изображений.
5) И вообще какими-то побочными вещами типа создания call-центра, настройки IP-телефонии, настройки DICOM-сервера для хранения изображений.
В общем, там была очень сильная погруженность во всё это. Когда к нам приходили разные ИТ компании с предложением своих услуг, выглядели они на столько ущербно. Аналитики совершенно ничего не понимали в процессах, для них всё это было просто набором каких-то документов, формочек, даже намека на какое-то целостное видение там не было, в лучшем случае они автоматизировали работу регистратуры в какой-нибудь поликлинике, а не работу многопрофильного областного медицинского центра. Бывало, что на прошлом проекте они автоматизировали что-то совершенно другое, а здесь типа за пару недель планировали полностью погрузиться в предметную область. Разработка тоже не отличалась прогрессивностью, какой-нибудь треш на Delphi. Или какой-нибудь веб-треш на Python, тогда это было модным. OLAP? - просто забудьте. Системы поддержки принятия решений на основе анализа данных? - эээ... а что это вообще? давайте мы запилим вам просто формочки и распечатку документов, а эту заумь вы сами сделаете, у вас же есть контакты с вузами и т.п.?
К чему я всё это пишу?.. Зарплата, как вы наверное уже догадались, там была как и в АСУ ТП. Когда я перешел в ИТ-компанию она увеличилась одномоментно в 3 раза, а объём работы уменьшился раз в 10. С чем это связано?.. Я думаю, с тем, что в неИТ-компаниях ИТ - это всё-таки какая-то вспомогательная деятельность, которая не приносит прямой прибыли. Например, у врачей ситуация была совершенно другая, с точностью до копейки можно посчитать какой доход они приносят, затем эти деньги распределяются между остальными сотрудниками. Очевидно, что у ИТшника зарплата никак не может быть на уровне ведущего врача в клинике или тем более выше. Т.е. она определяется не рынком, а зарплатами других сотрудников в этой компании. Там скорее вообще откажутся от ИТ, чем будут платить такие деньги.
Наверное поэтому у нас продвигались идеи, что нужно продавать наше ПО другим клиникам, оказывать им разные консультативные услуги, т.е. приносить прямой доход компании и получать с этого какой-то процент. В вашей статьи в принципе высказываются аналогичные идеи про маркетинг и т.п. Если работать не на одного заказчика, а на несколько, то наверное можно кратно увеличить доходы при примерно тех же затратах времени. Я думаю, что поэтому в ИТ компаниях зарплаты и выше.
Плюс наверное большинство производств находятся за пределами Москвы. И уровень зарплат там соответствующий. Когда я в следующий раз сменил работу, зарплата снова выросла в 3 раза, причём я даже никуда не переезжал, просто из-за ковида удаленки стало на много больше. И даже в моей прошлой компании, когда люди активно стали валить, условный потолок зарплат увеличился со 150 т.р. до 300 т.р. достаточно быстро. В АСУ ТП наверное с этим сложно.
usego
01.08.2022 08:54+1Ничуть не умаляя вашей работы, вы же понимаете, что с точки зрения целостности и масштабируемости бизнеса такое эникейство - это совершенно ненормально и загоняет самих таких "кулибиных" в жёсткие рамки возможностей роста?
Ares_ekb
01.08.2022 10:51+6Сейчас такое сложно представить, но 15-20 лет назад не было такого уж строгого разделения труда в ИТ, и даже 10 лет назад было не везде. На мой взгляд, это не считалось эникейством, у людей было нормальное инженерное ИТшное образование с совершенно разными дисциплинами: от схемотехники, программирования микроконтроллеров на ассемблере, сетей, информационной безопасности до алгоритмизации, теории баз данных, статистики, машинного обучения, теории игр, теории автоматического управления, теории систем и т.п. Плюс какие-то общие вещи начиная с разных разделов математики, физики до менеджмента (привет, софт-скилы), экономики, философии. Ну, люди и применяли все эти знания на практике. В чём здесь эникейство? Человек легчайше мог идти и в разработку, и в аналитику, и в менеджмент. Или совмещать всё это.
И тогда, и сейчас есть мнение, что в вузах преподают какую-то устаревшую фигню. На мой взгляд, в значительной степени это не так. Та же статистика и машинное обучение у нас преподавались задолго до того как в ИТ вообще появились такие специальности. Я копался с нейронными сетями или функциональным программированием, сокурсник в диссертации использовал генетические алгоритмы. Тогда, например, в принципе не было ни профессиональных дата сайнтистов, ни дата инженеров. Любой ИТшник мог спокойно этим заниматься. Причём здесь эникейство и кулибинство?
Насчет "целостности", блин, мне много-много лет проедали мозг в вузе "системным" взглядом на всё, я могу на эту тему часами разговаривать, рисовать тонны разных моделей AS-IS и TO-BE в разных нотациях, нарисовать дерево целей компании, стратегическую карту и т.д.
Я согласен, что сейчас ситуация в ИТ другая. Если человек, например, закончил курсы по React/Spring/AnotherBuzzword, за джва года дорос до тимлида, выгорел и уехал на Бали пить смузи и медитировать, запустил там свою онлайн-школу, то это совершенно нормально, он не кулибин и не эникей, а хороший профессионал. А если человек занимался совершенно разными вещами, успел поработать и аналитиком, и разработчиком, то скорее всего он ни в чём глубоко не разбирается, overqualified или в конце концов просто не впишется в наш дружный молодой коллектив. Хотя у него есть вариант, карьерного развития: отрастить усы странной формы или хотя бы бородку, носить странные ботинки с длинными носками, шотландский килт и рассказывать всем, что он T-shaped специалист. Извиняюсь за этот поток бурной фантазии, меня куда-то понесло :)
Если серьезно, то, да, сейчас в ИТ очень узкие специализации. У меня ощущение, что особенно в крупные компании ищут людей по очень специфическим критериям, с очень узким профилем. У меня сначала бомбануло от обвинения в эникействе и кулибинстве, и я изрыгнул всю эту пафосную муть про фундаментальное образование и т.п. Но с другой стороны, да, вы правы. На данный момент так и есть, но так было не всегда.
С другой стороны, в каких-нибудь стартапах или продуктовых компаниях наверное, наоборот, больше востребованы люди, которые не ограничены рамками одной специальности и могут всё и сразу.
Хотя, блин, и в крупных компаниях очень узкие специалисты обычно нужны на начальных должностях. Если человек хочет карьерно развиваться, то ему придётся заглядывать в соседние области.
usego
01.08.2022 11:01Думаю тут надо с другой стороны смотреть. Не в контексе сможет ли человек что-то сделать/разобраться/внедрить или не сможет, а может ли бизнес расчитывать на длинный жизненный цикл этих решений, а это означает поддержку, передачу знаний, штрафы за простой системы в конце концов. Ту же SIP телефонию понять и поднять много ума не надо, но обеспечить приемлемый для бизнеса SLA может только процесс, как правило внешний, с наличием соответствующего штата бекапящих друг друга людей. И так во всём.
Ares_ekb
01.08.2022 13:16Конкретно по IP-телефонии от нашего отдела была больше инициатива, чем техническая реализация. Было несколько территориально разнесенных отделений, куча телефонов регистратур (штук 20), люди часто звонили не на те телефоны, не могли дозвониться, не на всех телефонах регистраторы доступны весь день, у всех по-разному велась запись на приём (у кого-то были свои приложения, кто-то просто в тетрадь записывал), гигантские счета за телефонию. Возникла очень простая идея, давайте настроим IP-телефонию, чтобы внутри компании звонить бесплатно, и сделаем единый номер для клиентов с голосовым меню, чтобы
злить людейразгрузить сотрудников, напишем единое приложение для записи на приём.Всё, что касается техники мы конечно отдали профессионалам - интернет-провайдеру. Переняли у них какие-то знания, в частности у нас был отдельный телефонист, который всё это админил и в принципе на каком-то уровне разобрался и в новом оборудовании, разработчики на каком-то уровне разобрались в программной части, как, например, изменить голосовое меню. А технические вещи с нашей стороны преимущественно ограничились добавлением в МИС общего для всех модуля с расписанием врачей.
На мой взгляд, здесь самая важная часть была в том, чтобы в принципе увидеть проблему, найти варианты её решения, убедить руководство, чтобы они выделили на это деньги, увидеть задачу в целом (мало IP-телефонии, нужно приложение для регистраторов, оно должно работать в рамках МИС - аутсорсеру вообще оно нужно ещё куда-то что-то интегрировать?). Я думаю, что в таких вещах гораздо лучше разбираются и заинтересованы штатные сотрудники, а не внешняя компания, у которой цель просто продать типовое решение, по возможности поменьше его допиливая, и потом посадить на абонентскую плату. Всё это прекрасно работало и работает лет 10 уже.
Хотя опять-таки сейчас, когда всё это обыденность и полно компаний, которые предоставляют такие услуги, наверное они могут всё это сделать под ключ от и до.
Но это очень простой пример. Мы там делали, например, управленческие аналитические системы, придумывали вместе с экономическим отделом разные показатели (в медицине не всё измеряется деньгами, важен социальный эффект). Конечно можно было бы отдать это на аутсорс профессиональной консалтинговой компании, но ничего хорошего на тот момент они не могли предложить, они вообще не разбирались в медицинской специфике, все их решения больше для каких-нибудь торговых сетей подходили. Или, например, делали диагностические системы на основе машинного обучения. Даже сейчас компаний, которые специализируются на этом, не так много, а тогда их просто не было. Короче некому отдавать на аутсорс. Этим занимались в основном в вузах на некоторых кафедрах или выпускники этих вузов.
На аутсорс по моему опыту можно отдавать какие-то простые, типовые проекты, иначе получается что-то такое, исполнителям просто не выгодно глубоко погружаться в задачу, у них нет вообще никакого интереса, чтобы делать что-то сложное и уникальное. Хотя, блин, сейчас есть и такие компании, которые специализируются на уникальных проектах. Но у меня всё равно сильная убежденность в том, что действительно клёвые продукты могут создавать люди, которые сами активно пользуются этими продуктами, глубоко погружены в предметную область, ежедневно общаются с предметными специалистами, стремятся сделать что-то уникальное, т.е. люди с достаточно широким опытом и близкие к бизнесу, а не молодой дружный коллектив профессиональных аналитиков, разработчиков, РП на аутсорсе, который вчера автоматизировал торговую сеть, сегодня пилит сайт знакомств, а завтра - медицинскую информационную систему. Да, даже если они специализируются именно на медицинских системах, подавляющее большинство таких систем заточено на типовые медицинские учреждения: поликлиника, стационар, стоматология, косметология, аптека, ... Если медучреждение не типовое, то все эти коробочные решения идут лесом.
В общем я пошёл по кругу, для крупных компаний или для аутсорсеров с типовыми задачами, да, у сотрудников должна быть максимально узкая специализация. А если задачи не очень типовые, то по моему опыту узким специалистам с ними справляться сложнее, а большинству компаний, занимающихся заказной разработкой или аутсоросом, это просто не выгодно.
К слову, в тех же штатах:
ВистА началась со стандартизации MUMPS ANSI в 1977 году. Два компьютерных энтузиаста, работающих в Департаменте ветеранов, — Joseph (Ted) O’Neill и Marty Johnson — увидели в MUMPS базу больничной системы по всей стране.
Типичные эникейщики и кулибины :) Возможно конечно времена энтузиастов прошли... Хотя вроде как разработка с тех времен только упростилась.
MockBeard
01.08.2022 12:04+2Делайте поправку на время. Двести лет назад, ученый с мировым именем мог заниматься и физикой и математикой и биологией, а потом объем знаний вырос и пришло время узкой специализации.
Antra
01.08.2022 20:38Прямо с языка сняли.
"На все руки" все одинаково качественно делать уже не получается.
telobezumnoe
02.08.2022 00:24+1как то был на лекции Жореса Алфёрова, так вот он привел пример узкой специализации, и универсального образования (юниверсити -вселенная) где все науки связаны в единую реальность.. так вот люди с широким образованием быстрее находят решение тех задачах, которые ещё не смоделированы и не имеют решения, а узкие специалисты быстрее и голубже выполняют прикладные задачи. так вот он на примере космической гонки показал именно эффективность универсального образования, в сравнении с нашими пилотируемыми станциями и их скайлэбом, который с его слов просто не успевали ремонтировать, так как столкнулись с множеством проблем, которые не были учтены на этапе проектирования
MockBeard
02.08.2022 10:31Универсальное образование это здорово, но сцуко, очень дорого и долго. Это применимо для стратегических, долгосрочных проектов с неограниченным финансированием. А в большинстве проектов некогда ждать, когда построят экскаватор, быстрее и дешевле нанять землекопов. В треугольнике Цена-Качество-Время у всех свои приоритеты.
s60
01.08.2022 15:18+2т.р. до 300 т.р. достаточно быстро. В АСУ ТП наверное с этим сложно.
на 2019 год — это ЗП директора департамента (третий человек сверху, у генерального ЗП лям) в немаленькой производственной конторе в СПб (порядка 1000 человек персонала, производственные цеха, проектный офис в отдельном здании, несколько офисов в городах, в какие-то года крупнейший налогоплательщик по мнению ФНС и т.п., не рога-и-копыта)
300 у асутпшника может получиться, если он в командосе на ПНР отсидит месяца два со всеми командировочными, северными надбавками, коэффициентами и пр.…
так что да, не быстро…
хотя, если сейчас посмотреть на хх.ру сколько предлагают оператору дорожной фрезы… то он (оператор) почти айтишник :)
justPersonage
01.08.2022 21:27И разработкой. Часто считают, что в медицине устаревший стек, что там всё пишется на Delphi и тяп-ляп, но у нас это было не так. Код писался на C#
А почему не Java?Ares_ekb
02.08.2022 05:51Для Java не было нормальных движков для создания учетно-аналитических систем типа DevExpress XAF или просто нормальных UI компонентов. Да, по-моему и сейчас в Java всё печально с UI. Я не против Java, мы сейчас делаем на ней проект, что-то типа IDE или инструмента моделирования, в этой области наоборот для Java особо нет альтернатив.
justPersonage
02.08.2022 10:35Для Java не было нормальных движков для создания учетно-аналитических систем типа DevExpress XAF или просто нормальных UI компонентов.
JavaFX?Ares_ekb
02.08.2022 12:41Я не спец по JavaFX, но на тот момент это выглядело не очень впечатляюще. Нужны таблицы с фильтрацией, сортировкой, в идеале с возможностью задавать составные условия фильтрации, возможность работать с миллионами строк, inplace-редакторы для разных типов полей (галочки, выпадающие списки, ...), вложенные строки, валидация вводимых данных, выбор столбцов для отображения, строки с итогами, условное форматирование. Сводные таблицы для OLAP кубов.
Но даже если всё это есть, то хочется, чтобы это всё работало и на десктопе, и в вебе. И чтобы было low-code решение: описал схему данных в виде классов, добавил туда каких-нибудь аннотаций, определяющих какие поля отображать в таблицах, какие на формах и всё, получил готовые формы со списками сущностей, готовые формы для редактирования отдельных сущностей. У нас просто было слишком мало людей, чтобы делать всё это вручную. Точнее сначала мы делали всё это вручную на нашем движке, а потом тупо взяли DevExpress XAF. К слову, этот же движок используется в ERP Галактика.
Учетно-аналитические системы обычно совершенно типовые, нет смысла тратить время на решение типовых задач: создание типовых формочек, авторизация, генерация отчетов и т.п. Проще взять готовый движок. Для Java есть похожие проекты, возможно EMF Parsley, но по сравнению с XAF это прямо совсем грустно. Хотя сейчас, если бы я делал такой проект, то вопрос стал бы использовать XAF. Возможно сделал бы какой-то свой движок, например:
1) описываем схему данных (скорее всего не в коде, а в виде модели)
2) генерим из неё JPA-сущности, репоизитории, DTO, сервисы, контроллеры для Spring-приложения
3) из неё же генерим UI на React + MUI
...
N) profit
Просто JavaFX недостаточно. Нужен какой-то тулинг, который позволяет превратить схему данных (которая составляет по сути 90% таких систем) в формочки и остальное. К слову, для Java такой тулинг развит на порядок лучше, чем для .NET. Поэтому тут я однозначно выбрал бы Java. Но делать UI на чём-то кроме веба не очень хочется, я намучился со всеми этими десктопными движками, единственное что было более-менее - это WPF.
s60
02.08.2022 14:16описал схему данных в виде классов, добавил туда каких-нибудь аннотаций, определяющих какие поля отображать в таблицах, какие на формах и всё, получил готовые формы со списками сущностей, готовые формы для редактирования отдельных сущностей.
и это «настоящее» программирование ??? это ж конфигурирование!
тут только что за подобное LEGO асутэпэшников гнобили…Ares_ekb
02.08.2022 14:53+1А клепать изо дня в день тонны типовых форм - это настоящее программирование? :) Конечно мы не сразу до этого дошли, сначала как труЪ программисты клепали эти формы руками, потом постепенно появился внутренний движок, в который вынесли типовой код, а потом просто заменили его на готовый. Но движок и конструктор - это немного разные вещи. Всё равно есть значительное количество функциональности, которое в движке не реализовано, например, очевидно в XAF из коробки нет интеграции с DICOM сервером, нет возможности хранить часть данных в виде XML/JSON и генерить для работы с ним формочки и ещё кучи всего нет.
Готовый движок всего лишь позволяет больше времени уделять продумыванию схемы данных, а остальное время тратить на реализацию нестандартной функциональности. Я встречал много компаний, в которых люди этого не понимают и находятся где-то на нулевом уровне развития, всё время тратят на клепание формочек. На мой взгляд, автоматизация разработческой рутины - это и есть труЪ программирование, когда одну и ту же задачу два раза не делаешь.
s60
02.08.2022 15:22Ares_ekbб к вам вопросов нет, это был камень в спину тем, кто говорит, что в АСУТП как в лего собрал «тяп-ляп и в продакшен»…
так говорят те, кто не работал в АСУТП (SCADA, РСУ) (или работал, но ни на мм не выходил за функционал SCADA/DCS — мол штатных/готовых кубиков/средств нет, давай, досвидания)
та же SCADA система — это фреймворк, упрощающий работу с получением данных, отрисовкой окошек, записью в БД и т.п… Но фрейиворк не исключает работу «ручками»
Wan-Derer
03.08.2022 15:29описал схему данных в виде классов, добавил туда каких-нибудь аннотаций,
определяющих какие поля отображать в таблицах, какие на формахА как железка связывает множество форм со множеством сущностей? Т.е. как понимает что данная сущность должна появиться в данной форме, да не вся, а тремя полями из двух десятков, да в определенном порядке? Ить форм у нас сотни, аннотаций на все не напасёшься, даже аннотаций с регулируемыми параметрами.
Ares_ekb
03.08.2022 17:00В общем случае наверное, да. Но в учетно-аналитических системах обычно всё просто :) Для каждого типа сущностей может быть форма с их списком и форма с детальной информацией. Достаточно аннотаций указывающих нужны эти формы или нет для данного типа сущностей. Аннотаций, указывающих нужно ли отображать определенные поля на этих формах (например, в списке отображаются только основные поля, а в детальной форме - все). Ещё какие-нибудь дополнительные аннотации, задающие порядковый номер, категорию, можно ли редактировать поле. Это уже покрывает значительную долю потребностей. Если нет, то вместо аннотаций или дополнительно к аннотациям, можно положить рядом модель, в которой будет проще всё это настраивать.
Могут быть какие-то аннотации по умолчанию, составные аннотации. Ещё в том же XAF аннотации, грубо говоря, можно добавлять программно в соответствии с заданными разработчиком правилами. И в этом случае может быть особо и не понадобится для каждой отдельной сущности вообще что-то настраивать. Короче, если все эти настройки подвергаются какой-то формализации, то всё это можно автоматизировать.
Если в приложении каждая форма вообще не похожа на другие формы, и каждый раз нужно добавлять какие-то совершенно разные аннотации, то, да, такой движок не подходит.
panzerfaust
01.08.2022 06:49+20Обращаюсь ко всем молодым, у кого в голове всплывает вопрос из заголовка. Ответ на него утвердительный. Даже в статье контр-агрументов нет.
Можно убеждать себя, что вы тоже ИТшники, тоже программисты, тоже занимаетесь сложными и интересными задачами. Это все так, но есть 2 проблемы. Первая: рынок так не думает. Вторая: жизнь одна. Выводе делайте сами, и чем раньше, тем лучше. Я 7 лет назад сбежал из АСУ ТП в "обычное" ИТ и ни разу не пожалел.
Strohmann
01.08.2022 07:22+15+1
4 года как ушёл из АСУТП в Python-программисты. АСУТП - интересный жизненный опыт и неплохой источник для баек (не каждый backend-разработчик может рассказывать истории о том, как чуть не сжёг в печи главного инженера предприятия и директора института =) ).
Но в целом, хорошего в АСУТП в России не было ничего и на момент моей работы, и уж тем более, не будет сейчас, с учётом изоляции российского рынка и массового исхода поставщиков интересных технологий и оборудования.
Итак, студент, интересна электроника и мехатроника - оставь это хобби и изучай самостоятельно, это будет эффективнее, чем лекции от старых пердунов в ВУЗах. Программирование позволит тебе обеспечивать себя и семью, не пропадая месяцами в командировках, плюс еще и деньги на интересные электронные игрушки для хобби останутся.wAgo
01.08.2022 15:08+6А я видел как автоматизированная установка("киборг-убийца") сломала руку проектировщику(как он кричал идеоматическими выражениями..) в двух местах когда он положил монетку на датчик блокировки чтобы "взглянуть одним глазком" - после выхода с больничного датчик был переделан так чтобы его специально нельзя было заблокировать ))))
Проблема оплаты АСУТП в том что автоматизацию почти всегда можно заменить на "ручной труд" - пока есть дешевые работники выполняющие основную работу на производстве автоматизация не особо и необходима ;)
panzerfaust
01.08.2022 16:02+3Проблема оплаты АСУТП в том что автоматизацию почти всегда можно заменить на "ручной труд"
Скорее проблема в том, что нет сценариев, когда АСУТП приносит сверхприбыль. Ну да, обмазали цех автоматикой, получили какой-то буст в производительности, лет через 5 оно может даже окупится... В это время студенты-ухари склепали очередной тикток и грамотно его раскрутили - сорвали 1000% прибыли просто из воздуха
a_sergeevich
01.08.2022 11:01+3Соглашусь. Я вот в свои 43 года с огромным опытом в автоматизации, а я не чистый АСУшник, я больше КИПовец, хотя от АСУшника отличаюсь только большим объёмом обязанностей и знать должен тоже в разы больше, хочу свалить из всей этой промышленной автоматизации в IT, так как особо в зарплате каких-то перспектив роста не вижу, хотя и работаю в крупной нефтегазовой компании. У нас в стране где бы ты ни работал КИПиА, АСУ ТП не принято ценить, так как если у тебя всё работает идеально то у всех сразу складывается мнение, что ты ничего не делаешь, а раз так то за чем платить тебе больше. Да и уровень молодых АСУшников сейчас очень низкий, работать особо не с кем, мотивации развиваться у людей нет так как чем больше знаешь тем больше требуют, а на кой это нужно если зарплата та же. Короче, если есть возможность выбрать то лучше в IT, ответственности меньше, условия работы комфортнее, зарплата выше, работа сама по себе интереснее.
belyvoron
01.08.2022 07:58+10Если мало платят, переименуйте АСУ ТП в IoT :)
Если серьезно. Бизнес не очень интересует "сложно". Пока то, что вы делаете, является commodity, сложность этого не волнует вообще. Но как только вы будете приходить к бизнесу с предложениями "а я знаю, как на 5% повысить продуктивность доменной печи", ну или если вы занимаетесь зданиями - снизить счёт на отопление, то разговор может быть совсем другим.
Тут на Хабре были ребята, которые описывали кейсы автоматизации на производстве. Я почему-то уверен, что они проблем, подобных вашей, не испытывают.
Strohmann
01.08.2022 08:09+12Для того, чтобы знать, как повысить эффективность доменной печи нужно всего лишь разбираться в металлургии, тех процессах и экономике лучше технолога установки и экономиста цеха. Небольшой soft-скилл, типичный для программистов.
belyvoron
01.08.2022 08:13+4Софтскилом тут будет умение пообщаться с технологом, понять его боли и придумать, как средствами IT это можно пофиксить.
Jef239
01.08.2022 09:11+5Совсем не обязательно. При помощи нашего софта производство некоторых видов оцинкованной стали увеличили в полтора раза.
Что мы сделали
Да в общем-то почти ничего - инструмент, позволяющий записывать процессы в контроллерах.
На оцинковку стальной лист идет в рулонах и сваривается в непрерывную ленту. Сварной шов ленты - чуть толще, на время его прохождения надо тянущие валы раздвигать (или тянуть не на максимальной скорости). При этом лента тянется, поэтому просто "по длине" место шва прогнозируется грубо.
Ну вот при помощи нашей системы определили моменты прохождения швов. И подняли скорость. В полтора раза. Проходил рулон стали оцинковку за час, стал проходить за 40 минут.
А с печью есть интересная задача - прогнозирования выхода из строя футеровки. В зависимости от материалов, поставщиков и так далее. Где-то на хабре она описывалась. Если делать плановые ремонты печи пореже - то можно и 10% сэкономить.
LLIypLLIuk
01.08.2022 09:57+2Если делать плановые ремонты печи пореже - то можно и 10% сэкономить.Чтобы корова меньше ела и больше давала молока, её надо меньше кормить и чаще доить?
А ещё я видел предложения - вообще отказаться от плановых ремонтов, а делать только внеплановые/аварийные. И тоже прогнозируемо на небольшом отрезке времени увеличится выхлоп с оборудования, но никто нормально не может просчитать как поведёт себя ресурс на всем отрезке срока эксплуатации.
Jef239
01.08.2022 10:07+1Без ППР (планово-предупредительные ремонты) никто в трезвом уме не будет работать. Потому что при аварии могут погибнуть люди, а отвечать - тому, кто принял решение отказаться от ППР.
А анализ остатка ресурса при замене на ППР - вполне решаемая задача. И прогнозирование ресурса с учетом отклонений.
Собственно вот статья о футеровках. Там про ковш, но у печи - похожие задачи.
Static_electro
01.08.2022 11:33+3для молодого специалиста в АСУ ТП крупного предприятия есть еще сюрприз в виде "не вы*буйся, и так всё работает". Спросите, откуда я это знаю.
GidRo
02.08.2022 09:42Работал начальником отдела АСУТП на заводе. Всегда приветствовал инициативных молодых специалистов и их начинания. Но, к сожалению, попадались такие не часто. Правда, предприятие не крупное, 200 чел.
BasilM
01.08.2022 08:31-9Я работал с АСУ ТП. Поэтому немного странно когда инженер АСУ ТП считает себя тоже программистом и хочет такие же зарплаты. Нет, инженер АСУ ТП ни разу не разработчик. АСУ ТП это сборка "лего", как правило, по готовому проекту. Скрипты и даже интегрированные блоки кода не имеют к программированию никакого отношения. Просто это совсем разные профессии.
F0iL
01.08.2022 08:55После вашего комментария мне прям вспоминалось послесловие из моей статьи про опыт АСУТП :)
Имел я дело и "классическими" АСУТПшными проектами с ПЛК именитых вендоров, разработка для которых ведется на МЭК'овских языках, но там все еще хуже — а именно, лично для меня (прошу не кидать камнями, это лишь мнение) по сравнению с теми же C++/C#/Python эти МЭКовские языки кажутся детскими кубиками против Lego Mindstorms.
:)
Sergeant101
01.08.2022 09:09Ассемблероподобный STL - детский кубик?
Что то вы сударь не договариваете!
F0iL
01.08.2022 09:14STL как по мне более паскалеподобный, чем ассемблероподобный.
Alxndrch
01.08.2022 09:20Паскале-подобный скорее SCL (ST в соответствие с IEC 61131-3), а STL (IL в соответствие с IEC 61131-3) очень даже ассемблероподобный.
Sergeant101
01.08.2022 09:28Вот и я про то же: FOiL не понимает о чем говорит.
F0iL
01.08.2022 09:43Не, это просто вы на ходу сменили контекст :) я говорил про ST Language по МЭКовской классификации. Мир ПЛК Сименсами не ограничивается, а МЭК это индустриальный стандарт.
Ну и в любом случае, вполне соглашусь с комментатором ниже.
F0iL
01.08.2022 09:41+2А, понятно. Я говорил именно про ST Language по МЭКовской классификации, а вы и комментатор выше, видимо, сименсовики.
BasilM
01.08.2022 09:29Сложность разработки на ассемблере сильно преувеличена ). Наоборот, это довольно просто, да и масштаб задачи, как правило, не большой. Написать на ассемблере реализацию протокола МЭК-104 (в телемеханике используется), например, не очень сложно, а самое главное, для этого нужен минимальный набор знаний - изучил протокол, собрал стенд, понял смысл работы двух десятков команд процессора и можно начинать готовить "прошивку". Немного утрирую, но только немного.
Jian
01.08.2022 09:05Поэтому немного странно когда инженер АСУ ТП считает себя тоже программистом и хочет такие же зарплаты
В 2010-х, после многих лет программирования, я работал ровно один год в АСУ ТП, и получал как обычный программист (нужно было кое-что подправить в легаси, написанном за десяток лет до меня).
F0iL
01.08.2022 09:15Либо вам как программисту недоплачивали, либо как асушнику переплачивали :) А если серьезно, то щедрые заказчики бывают (например, когда надо вот прям очень, а делать никто не может/не хочет), но выше речь комментатор ведёт, как мне кажется, о среднему по рынку.
Jef239
01.08.2022 09:58+6Ну так можно про любого программиста сказать, что мол "лего" из if и for. На самом деле, АСУТП бывает совсем разного уровня.
АСУ, то есть сбор экономических данных. Да, тут в основном интеграция готовых решений.
SCADA, то есть управление техпроцессом с участием оператора. Например, котельной или атомной электростанцией.
ПЛК, то есть программирование контроллеров на LD и иных специфических языках, пришедших из релейных схем.
Embed. Например ECU, управляющий двигателем автомобиля. Или авионика.
Большой emded. То, что, что хорошо бы загнать в однокристалку, но реально занимает чемодан или стойку. Например - автовождение.
AСУ - обычно не относят к АСУТП, потому что системы АСУ не влекут рисков гибели людей.
А всё остальное - влечет. Поэтому в АСТУП всегда надо думать, а что будет при отказе одного датчика, а двух, а трёх? А если процессор откажет? Советский стандарт - без одного датчика работает, при отказе двух датчиков диагностируем, при одновременном отказе трёх - как повезет. Это влечет за собой медленность разработки, ибо уголовная ответственность всегда рядом.
Цементный фильтр
На цементном заводе приняли решение ввести цементный фильтр в строй, не дожидаясь автоматики. Фильтр забился цементом и упал. Цементный фильтр - это такая огромная дура на ножках в пару этажей. Под фильтром - рабочие места четырёх человек. Один был в курилке, один в туалете, двое удрали из-под падающего фильтра.
Решение завод принимал сам, ни одной нашей подписи не было, но... мы были в курсе. И полгода ждали, придут к нам искать согласие в наших бумагах или не придут.
Карьер
Коллега делал систему предотвращения наездов карьерной техники на людей. А на объекте, на этапе ДО ввода системы в эксплуатацию, произошел наезд со смертельным исходом. Прокуратура трясла коллегу полгода.
Насчет зарплат.... Ну в Google (автовождение), Ford (ECU) и так далее - они не ниже, чем у сайтописателей. В российском АСУТП - да, ниже, но это особенность РФ.
F0iL
01.08.2022 10:12+3Embedded-разработка бывает очень близка к АСУТП, хотя обычно ее рассматривают как что-то другое и отдельное.
Про тлен и боль российского embedded (и особенно зарплат там) можно написать отдельную статью, да и здесь вроде уже такие были.
А так - да, я сейчас в Европе пишу прошивки для зарядных станций электромобилей и прочего IoT/IIoT, и офферы у специалистов в этой области не сильно отстают от тех же фуллстек-разработчиков (хотя до предложений от банков и модных стартапов совсем не дотягивают)
lymes
01.08.2022 10:49Хех, тоже в Европе и один из моих проектов - мобильное приложение iOS/Android для тех же зарядных станций от Leasys и EnelX. Приложение, кроме всего прочего, использует стек BLE для общения со станцией (команды, настройка WiFi, конфигурация и проч.). По количеству апдейтов firmware и глупых поведенческих багов, у меня сложилось впечатление, что на другом конце посадили какого-то джуна, который пилит этот firmware, и платят ему копейки. Сам проект миллионный, но видать слишком много посредников со стороны hw.
Jef239
01.08.2022 21:43Ну так embed - это не только АСУТП. Это могут быть датчики, игрушки... АСУТП - это управление технологическим процессом. Если embed управляет - он АСУТП, если нет - то нет.
AlexeyK77
01.08.2022 11:25+4вот-вот, а за падение сайта еще никого не то что не поосадили, а даже на допрос не вызывали. При этом ЗП выше значительно, и отношение как к полубогу. Так спрашивается, нафига за копейки и перспективу сесть по статье корячиться на производстве, если можно быть в коворкинге с девушками-психологами.
Как по мне в этом все есть какой-то чудовищный дисбалланс и он навреняка со временем уйдет, но пока ситуация такая.Jef239
01.08.2022 21:40Я тут скорее луддизм вижу. По идее лошадь, которую растили и обучали много лет, должна быть в сотни раз дороже автомобиля, который за день-два склепали на конвейере.
Увы, индустриальная эпоха ушла вслед за гужевым транспортом. Коли сайт приносит больше прибыли, чем производство - то и платят за него больше.
Ну и плюс в РФ дисбаланс побольше, чем в мире. Но на фоне остальной сотни российских дисбалансов это уже не так важно.
AndreyUA
01.08.2022 16:36+5Вы точно работали в АСУТП? Потому что в современных реалиях программист АСУТП более программист, чем некоторые верстатели сайтов на фреймворках и "вордпресах", которые называют себя веб программистами. В АСУТП отсутствуют такие понятия, как комьюнити, библиотеки, фреймворки и подобное (они есть, но их так мало, что ими можно пренебречь). И, то, что современный программист подключит с помощью библиотеки и даже не будет заморачиваться, как оно работает, АСУТПшник вынужден будет писать сам, попутно разбираясь во всех тонкостях. Потому что нет у него github, stackoverflow и docs.microsoft.com Все примеры кода он видит или у коллег, или у заказчика на соседней линии, проект которой он выпросил у местного киповца за бутылку водки. Документации часто просто нет в открытом доступе и добыть ее можно по запросу у производителя, который еще посмотрит, какой ты партнер и достоин ли ты прочитать их документацию. Вот он из этих кубиков лего и пытается что-то собрать. Кубиков у него не так много, все они квадратные, а собрать нужно шар. И никаких тебе PM> Install-Package. Конечно, есть таймеры, счетчики, блоки PID регуляторов и т.п., но сравнить все это с nuget или pip даже рука не поднимается.
a_titaev
01.08.2022 17:52Справедливости ради, у Сименса очень хороший форум по Плк и ответы на большинство типовых вопросов там есть. А также много статей, иллюстрирующих отдельные ситуации
AndreyUA
01.08.2022 18:04+2Англоязычный/немецкий - да, русскоязычный - был. Еще неплохой форум у Овена. Пару форумов на общую тематику, где обитают пару десятков человек.
s60
02.08.2022 10:32+1Пару форумов на общую тематику, где обитают пару десятков человек.
это не идет ни в какое сравнение с true программистким community
Yukr
01.08.2022 08:31+2Читал статью и "вот пишу, а слёзы душат и капают" , как пел В.С. Высоцкий. Производство железа для АСУТП и так просело в ходе короны и дефицита полупроводников, а после февраля и вовсе грустно стало. Работал с ПЛК от одного тайваньского производителя (чтоб без рекламы) - оборудование от официального дилера даже еле/медленно доходит, модули ввода/вывода - предоплаченые!!! - вообще не пришли. Искал "импортозамещение" - китайское работает с багами, российское - красивая (в лучшем случае) коробочка с китайской начинкой, один "отечественный производитель с 2013 года" из Краснодара даже не затруднился убрать китайские данные производителя из мануала.
работать с этим - терять репутацию. Смотрел уже в сторону Ардуино, Малинки и Апельсина, но тут проблема с периферией - а у меня много тензометрии было. да и условия производства...
не соглашусь с принадлежностью к секте "настройщиков ПИД" , просто хотелось бы работать с интересными задачами проекта, а не вылавливанием косяков в криво перевоплощенной технике.
Насчёт денег в АСУТП - есть
мысльнадежда, что как всегда они появятся, как только производство встанет, и надо будет "срочно всё сделать уже вчера". только надо помнить,что "ничто так не укрепляет доверие, как 100% предоллата ))).F0iL
01.08.2022 08:57один "отечественный производитель с 2013 года" из Краснодара даже не затруднился убрать китайские данные производителя из мануала.
Напомнило старую историю: https://habr.com/ru/post/408825/
MaxAltay
01.08.2022 08:31+2Больше знаком с АСУ производством, допускаю что в АСУ зданий свои особенности, но выскажу свое мнение:
“Всю внутреннюю кухню по реализации проекта давайте оставим внутри компании.”
Не могу согласиться. Это прямой путь к тому, что цена проекта сильно упадет (и зарплата программиста тоже). Поясню: если заказчик не учитывает “внутреннюю кухню” проекта, значит он будет выбирать поставщика автоматики исходя из цены. Много было случаев: заказчик выбирает конкурентов с ценой минус 10% (для примера), а оборудования там минус все 70% по цене (соотвественно появляются недостатки, которых заказчик не видит). Отсюда вывод: надо акцентировать внимание на “внутренней кухне”, объяснять плюсы и минусы предлагаемого решения, это значит, работать с теми, у кого есть кому оценить предлагаемый проект. Понятно, что навряд ли их правильно оценит ген директор :) но их должен оценить главный инженер или руководитель местной службы АСУ.
нужно переходить с технического языка на язык маркетинга
Зачем? А если придет конкурент с более умелым маркетологом? Мы превратим нормальную конкуренцию тех решений в гонку цен и красивых слов. В итоге пострадает и заказчик и мы.
Так как монтаж кабеля, установка и настройка не могут быть дорогими, то выставить высокую цену будет сложно, придется искусственно раздувать и накручивать стоимость, а это неправильно.
Не совсем понятно. Если эта работа несложная и недорогая зачем ее делать Вам? Зачем искусственно раздувать и накручивать? Вы же сами пишете, что надо бороться с недооценкой работ по АСУ. И предлагаете переоценивать простые работы?
Необходимо развесить трансформаторы, поставить анализаторы тока, прокинуть пару сотен метров кабеля, развернуть и настроить SCADA-систему. В этом случае клиенту вообще не стоит вникать в эти подробности.
А я считаю, надо ему вникать. Надо учесть возможность расширения количества датчиков тока, например. Возможность взаимодействия с бух программами, например. Возможность вывода информации по потреблению на планшет директора, например.
Dotarev
01.08.2022 09:08+2Понятно, что навряд ли их правильно оценит ген директор :) но их должен оценить главный инженер или руководитель местной службы АСУ
Должен - да. А реально оценивать будет ... отдел гос.закупок. И у них один критерий - цена.
MaxAltay
01.08.2022 09:21+2По моему опыту, если отдел закупок не прислушивается к тех спецам, лучше не работать с этим предприятием. Однако, чаще у них есть понимание. Но! Тут мы подходим еще к одной проблеме: торги. Это одна из самых главных причин обилия хреновой (дешевой) автоматики. Борцы с коррупцией добились того, что заказчик даже понимая задачу и имея желание и возможность оплатить нормальные решения, вынужден заключать договор с поставщиком с наименьшей ценой (и с хреновым с технической стороны предложением). И, наверняка, программер у этого поставщика похуже :) и получит ЗП меньше :)
net_racoon
01.08.2022 09:53-3Да все просто. Едете на вахту, если хотите получать столько же сколько получают войтишники. Кому то даже нравится вахтовый формат работы.
F0iL
01.08.2022 10:08+3Кому то даже нравится вахтовый формат работы.
А кому-то нет:
...это постоянные разъезды и командировки.
Объекты часто находятся вдали от цивилизации, и описанный мной вариант "три часа на машине, пять дней в захолустной гостинице, до объекта на внедорожнике или на лыжах" на самом деле еще лайтовый — у некоторых моих знакомых из той же профессии объекты запросто могли находиться где-нибудь за полярным кругом, куда закинуться можно только на вертолете, сами командировки длились не недели, а месяцы, а постановка задач вида "фронт работ обозначен, и без подписанных актов приемки можешь не возвращаться" была не такой уж редкостью. По молодости, конечно, в этом есть своя веселуха и свой кайф, но со временем начинает приходить чувство, что со всеми этими разъездами жизнь просто проходит мимо.
hahenty
01.08.2022 10:15-1Здесь нужна низовая ассоциация специалистов АСУТП. И многие вопросы решать таким вот образом, в том числе постепенный равномерный рост цен за свою работу. Коллегиальный сговор.
Nester911
01.08.2022 11:02+3Перешёл из АСУ ТП (нефтеперекачка) в "обычное" IT, ни разу ещё не пожалел. Всё что вы описали для вашей отрасли - в нефтянке аналогично. Про "и швец, и жнец, и на дуде игрец" - знать и уметь действительно нужно больше одного контроллера и одной OS, промышленные протоколы, SCADA, датчики, сети, хотя бы базово знать сам тех. процесс - это минимум для хорошего специалиста. Но всё же разделение труда конкретно у нас было хорошим и в прямые должностные обязанности настройка коммутаторов не входила.
Я до сих пор крайне удивлён, что в РФ средний тестировщик с курсами за спиной и несколькими месяцами опыта может получать больше, чем средний специалист АСУ ТП - отличия в требуемых знаниях и уровню ответственности колоссальные. При этом лично знаком с людьми с той и другой стороны, это не какие-то абстрактные примеры. Выровняет ли это рынок - вряд ли... Свободный рынок в принципе существует только благодаря регуляторным механизмам, и пока текущий расклад работает - так и останется. А в связи с уходом из страны Schneider/Siemens/B&R зарплаты скорее опустятся, больше никаких иностранных сертификатов и продвижения продукта от вендора (свои этим заниматься не будут, и так купят).
Касательно резюме в статье - на мой взгляд для каких-то сфер превращение АСУ ТП в "чёрный ящик" может и прокатит, но лишь для малой части. Автоматизация в основном сильно зарегулирована отраслевыми стандартами, и заказчики просто обязаны разбираться во внутрянке, а модные технологии им объективно не нужны - это ведь нужно ещё дёшево сопровождать.
Willy64
01.08.2022 11:06+1Написали много, практически со всем согласен, но есть, что добавить: АСУТП в плане осязаемости результата - намного более благодарная сфера деятельности. Результат работы виден и осязаем. Отказ (особенно такой, который приводит к затоплению, пожару и прочим убыткам) - тоже. Плюс многим нравится быть универскальными специалистами и разбираться в устройстве процессов, имея возможность увидеть их близко и потрогать руками.
Бесспорно, из IT в АСУТП переходить легче, потому что понимаешь устройство и работу контроллеров (особенно при знании ассебмлера) и сетей сбора данных, но первые несколько лет такой асутпшник будет слаб в новой сфере, пока не вспомнит школьный курс физики и не выучит ПУЭ, ПОТЭУ, ПТЭЭП и другие страшные на первый взгляд документы и регламенты по своей специфике. Обратный переход, по-моему, даже сложнее, нужно переключаться на абстрактное мышление и переходить к "виртуальным" процессам вместо реальных.
jstbot
01.08.2022 11:07не про АСУТП но сталкивался с подобным отношением к своему труду и приходилось обычно объяснять с точки зрения экономики почему услуги стоят столько сколько стоят и сколько предприятие выиграет в определенном временном отрезке в виде прямой или косвенной прибыли
sokol_9
01.08.2022 11:15+10В нашей стране много нищих профессий. Одна из них - инженер. Начиная с 90-х годов, инженер - это синоним неудачника по жизни. Этому поспособствовал тотальный упадок в промышленности. АСУТП привязана к промышленности, и если промышленность не хочет платить, значит ей и не особо надо АСУТП. Если здания, эстакады, оборудование, трубопроводы в изношенном виде, на автоматику уже не обращают внимания. Состояние инженеров зависит от отрасли, региона и монопольности компании. Самые большие зарплаты в нефтегазе, госкомпаниях и их подрядчиках.
В то время как в ИТ для работы нужен только компьютер и связь. Поэтому в ИТ больше свободы и возможностей. И эпоха стратегического роста ИТ, в которую мы живём. Однако, большая потребность специалистов ИТ - это миф. Это видно из того, как трудно устроиться на первую работу в ИТ, чтобы вас приняли, а не отказали.
Переход из автоматики в ИТ - типовая история. Много кто так делает, так как профессии действительно смежные.usego
01.08.2022 11:31+1Первая работа и специалист - это, в большинстве случаев, оксюморон. Не все готовы вкладываться в дообучение и сопутствующие риски.
lymes
01.08.2022 11:33+2Удивительно, как все с ног на голову. В Италии Ingegnere это титул, который добавляется к имени, как Professore или Dottore, и это очень почетный титул. Учиться на инженерном факультете гораздо сложнее и инженеров довольно мало.
yerbabuena
01.08.2022 19:47+2Аналогично и в Германии - там даже в права и паспорт можно добавить все эти Dr Prof Dipl Ingeneur von Münchhausen. И в табличку на доме/квартире.
mapnik
01.08.2022 14:01+6Начиная с 90-х годов, инженер - это синоним неудачника по жизни
Вероятно, вы не очень хорошо помните 80-е.
DonAgosto
01.08.2022 23:34+1Приятельская пара. Познакомились они на одном производстве году в 84 кажется. Он — инженер только что из института, она — монтажница РЭА. У него почти голый оклад 120р, а у нее сделка и до 300р в мес.
Akon32
01.08.2022 11:38Хм. Получается, в своё время я крайне удачно выбрал специальность разработчика ПО вместо инженера АСУ. Ещё тогда боялся, что обычное ПО - это сложно (а в контроллерах всё проще), но в итоге оказалось, что со сложностью мне относительно легко работать. Повезло, однако.
avl33
01.08.2022 11:50+6Давайте я попробую высказаться от имени потенциального заказчика - тем более, что по сути, именно потенциальным представителем его я и являюсь.
Вы абсолютно правы в том, что бизнесу, т.е. ТОПам представляющим компанию и подписывающим документы (договора), на самом деле не нужно знать всех этих АСУповских и ИТшных терминов и перегружать их деталями.
В "недоразвитых" организациях (а таких по стране очень много) руководству достаточно показать красивые графики (читай бусы), чтобы они начали нажимать на свои службы о проработке вопроса.
Проработка вопроса!
Крупный заказчик, как правило, внутри себя уже имеет службу ИТ, которая, в 2022 году, уже по любому имела дело и со SCADA и с датчиками напрямую, и имеет свои информационные системы.
Помимо службы ИТ - есть ещё служба, которая будет непосредственно работать с этими графиками и что-то на их основе менять ("улучшать").
Как минимум две эти службы выдвинут технические требования к системе, по интеграции и обратной связи.
Помимо них в процесс обязательно будет включена хотя бы одна экономическая служба, задача которой определить целевое назначение и окупаемость.
Три эти составляющие:
техническая прозрачность, интеграция и поддержка;
наглядность, управляемость и доступность по требованию;
экономическая целесообразность и окупаемость;
и лягут в основу принятия решения по проекту.
Как Вы понимаете, Ваша задача увеличения стоимости проекта, для увеличения заработной платы сотрудников напрямую влияет на последний показатель - окупаемости.
Таким образом, для поднятия стоимости проекта, крайне мало красивых слов и громких названий. Куда продуктивнее предоставить в продукте метрики сравнения или улучшение нового решения относительно чего бы то ни было.
Как в ОС - система очистки от ненужных файлов показывает сколько места было сэкономлено, что напрямую может трансформироваться в сэкономленные средства на системы хранения, которые не надо было покупать.
Помимо этого, в современных условиях система для крупного заказчика не должна быть черным ящиком, который невозможно обслуживать без привлечения компании разработчика или посредника.
Система должна иметь очень развитый API на чтение и запись (если есть необходимость) - для обратной связи и управляемости.
Система должна быть кросплатформенной и адаптированной под разные устройства, а также способной работать под разными СУБД.
Всё перечисленное выше добавляет стоимости системе и абсолютно адекватно понимается и службами и руководством предприятия.
Отсутствие чего бы то ни было из перечисленного, говорит о том, что продукт будет дорабатываться на живую и существует огромное число рисков, как ошибок проектирования и реализации, так и в дальнейшей интеграции. Это означает длительную привязку к исполнителю (в том числе и финансовую) и растянутую во времени опытную эксплуатацию. Всё это снижает стоимость проекта, для того, чтобы снизить риски. Выход из этой ситуации есть, для того - для увеличения стоимости проекта надо, чтобы сторона исполнителя готовая была разделить с заказчиком риски, в том числе и финансовые, на период опытной эксплуатации. И вот на этом ломаются все, а риски срабатывают - всегда.
Yukr
01.08.2022 13:42В моей практике часто были вышеперечисленные требования, причём запрашиваемые системы были нестандартными ( не решалились за разумные деньги поставщиками стандартного оборудования). И вопрос упирался в то, чтобы мы "показали рабочую модель" до подписания контракта. за свой счёт естественно))). Где-то удавалось обойтись малой кровью, представив пару демо-вариантов HMI (с имитацией работы периферии), это было на 1-2 дня работы. а где-то не удалось - риск бесплатной работы в стол не устроил.
avl33
01.08.2022 14:53Организация командировок на места, где Вы уже внедрились и возможность потенциальному заказчику поговорить напрямую с сотрудниками предприятия, куда Вы привозите на показ - чаще всего снимают 90% вопросов к "рабочей модели".
Yukr
01.08.2022 16:08отчасти согласен с Вами, но не в случае пищевых производств и сельскохозяйственных ферм - они не пускают к себе посторонних, ибо санитарные требования.
avl33
02.08.2022 08:40Я работаю в отрасли, где присутствует секретка. Могу Вам сказать, что все предприятия одной и смежных отраслей, готовы встречаться для обмена опытом даже без компаний внедренцев и такие встречи проходят регулярно.
В нашей отрасли есть четкое понимание, что одна встреча многих участников по сложной задаче, может сократить сроки её успешной реализации для всех на месяцы, а то и годы, особенно если у кого-то есть задел или неудачный опыт - это, кстати, тоже очень ценно.
Пищевые и сельхофермы - я не знаю, не сталкивался, НО виноделы и сыровары также собираются, а у них требований санитарных и внутренних по системах хранения и созревания - не меньше.
Другой вопрос, что не все компании готовы показывать результат своего внедрения, поскольку не редко бывает, что желаемое на словах выдают за действительное, а встреча, на которую приедут спецы с другого предприятия, которые точно понимают, что ищут и что хотят увидеть - всё это вскроет.
Именно по этой причине многие крупные компании заказчики и просят показать результат внедрения на других предприятиях. Логика: если у внедренца получилось сделать у других, значит помехой во внедрении можем быть либо мы сами, либо наши неразумные или завышенные требования к системе.
lisovsky1
01.08.2022 12:13+1Ну как-то сгущаете краски. Не везде и не всегда АСУшник - универсальный солдат. Чаще я встречал персонажей с мышлением - я программист - моё дело контроллер, а в добавок и не дизайнер интерфейсов. Если контора нормальная, то АСУшник в командировке находится с инженером КИП, который занимается полевым уровнем и шкафами, и электромонтажником, который, в случае чего устраняет косяки монтажа
F0iL
01.08.2022 12:21+3Если контора нормальная, то АСУшник в командировке находится с инженером КИП, который занимается полевым уровнем и шкафами, и электромонтажником, который, в случае чего устраняет косяки монтажа
Это в теории оно так, да. А на деле нередко может быть, что ты натыкаешься на косяк монтажа или барахлящий датчик, а киповец и электрик или застряли на соседнем объекте, или третий день с матом ковыряются в соседнем шкафу, или заболели, или еще что, и у тебя остается выбор: или сидеть и ждать их, продлевая себе командировку вдали от дома и родных на неопределенное время, или засучив рукава самому лезть решать проблему, если допуски позволяют.
alexhott
01.08.2022 13:34Штатные АСУшники как сисадмины должны получать премию за то что сидят и ничего не делают.
kv22
01.08.2022 13:38Перефразируя одного мелкого презика, АСУТПшник, это призвание. А если вы хотите деньги зарабатывать, то идите вы в ...... бизнес.
AndreyDmitriev
01.08.2022 14:28+11Я больше двадцати лет работаю в области автоматизации производства, но в Германии. В конце девяностых имел незабываемый экспириенс на Волжском и Челябинском трубопрокатных заводах. Имею сообщить следующее.
АСУТП в общем тоже бывает разное. В моём случае (рентгеновский неразрушающий контроль) это не только тривиальное программирование ПЛК (но и это тоже, я знаю Сименс и B&R, немного GE Fanuc). Сейчас в основном B&R и мы программируем в основном на плюсплюсах, соответственно все классические методологии (хранение кода, автоматическая сборка, и т.д. работают в полный рост), но также программирование промышленных роботов-манипуляторов (KUKA, ABB, Fanuc, Adept), что также требует знания и понимания промышленных протоколов, полевых шин (Profibus, Profinet, ASi, Modbus, CAN, OPC, OPC UA, ...). Машинное зрение - приходилось программировать смарт-камеры типа Cognex, NI и специальные рентгеновские детекторы - тут и распознавание объектов и автоматический поиск дефектов. Визуализация на стороне ПК часто делается не только на WinCC или mappVIEW, но и на C#/WPF. Тут UI/UX/HMI тоже надо понимать, что б не ваять вырвиглазные интерфейсы.
В целом мне очень нравится. Да, иногда приходится программировать у заказчика, где шумно, грязно и по вечерам много пива и шнапса с коллегами, куда ж без этого.
В принципе если вы уверенно знаете Siemens TIA Portal, который в Германии почти стандарт де факто и (или) CoDeSys, владеете Simotion, и Safety для вас не пустой звук, то работу найти можно и за рубежом. Скажем, если вы умеете запрограммировать автоматическую хлеборезку, где конвейер программно синхронизирован с ножом, где буханки хлеба подаются промышленным роботом, с визуализацией всего этого хозяйства на C#/WPF c подключением по OPC UA, и понимаете как осуществляется, скажем экстренный останов всей этой штуки при нажатии большой красной кнопки, а контроль качества осуществляется камерой, и при этом вам не приходит в голову собрать это всё на ардуинке, то можно смело искать работу в Германии - предложений выше крыши (хотя и претендентов довольно много). Сейчас все помешались на Индустрии 4.0, ну вот в этом тренде и надо быть.
Из дополнительных плюшек - если я в дороге больше десяти часов, то путешествую бизнес классом. До кучи топовый ноут, кредитка, машина и мобильник с интернетом в любой точке мира от компании. Зарплата вполне достойная, хотя и не скажу какая (ну, правда, после двадцати лет я всё-таки лид, но тем не менее). Переработки и работа на выходных щедро оплачиваются. Работа как работа, но как по мне, так это всё заметно интереснее "рутинного" IT.Autonomnoe Автор
01.08.2022 14:31+1спасибо за такой развернутый ответ!
Autonomnoe Автор
01.08.2022 14:32+3Так и хочется написать "возьмите меня с собой" ))))
AndreyDmitriev
01.08.2022 14:55Вообще-то я по образованию физик, закончил физико-технический факультет в питерском политехе (полупроводники), но вот чёрт меня дёрнул запрограммировать дифрактометр для дипломной работы (анализ дефектов кристаллических решёток в структурах из арсенида галлия), но получилось неожиданно хорошо, так я и "вошёл" в эту область. Я защитил диплом на отлично, получил рекомендацию в аспирантуру и даже начал работать в лаборатории физтеха, но фундаментальная наука в конце девяностых совсем развалилась, а в питере открылся филиал немецкой фирмы (а тут ещё и кризис) и после пары лет работы Германия начала выдавать "гринкарты" для айтишников (моя была одна из первых), и вот я здесь. Хотя иногда ковыряясь в кабине радиационной защиты я с ностальгией вспоминаю мои любимые лекции по квантовой механике. Большую часть полученных знаний я не использую, но кое-что из университетской математики мне до сих пор в работе помогает. У нас были хорошие преподаватели.
justPersonage
01.08.2022 21:39Вам наверно нравиться работать с физическим миром больше чем с виртуальным?))
AndreyDmitriev
02.08.2022 07:08Да, я всегда был практиком. У нас поток делился на лве части - теоретики - это те, кому достаточно письменного стола и листа бумаги и экспериментаторы - это те, кто ночи напролёт просиживал в лаборатории.
А, вот, кстати, нашёл видео на ютьюбе - я тогда в комании Зайферт работал - наша система начиная с 3:08, одна минута:Там мы делаем "флюорографию" блокам цилиндров. Софт, правда, старенький, образца 2005 года примерно. Но всё настоящее и живое. Тот случай, когда оборудование из Германии едет в Китай, а оттуда к нам едут обратно готовые двигатели.
justPersonage
02.08.2022 10:45Да, я всегда был практиком.
Практики редко выгорают. Теоретики (всякие там full stack dev выгорают сильно чаще)
Смотрю видео и думаю. А полностью все автоматизировать сейчас возможно? Вижу что еще ручной работы на заводе много.AndreyDmitriev
02.08.2022 12:39Выгорание больше зависит от человека, нежели от рода деятельности. Кому-то больше нравится рутина, кому-то разнообразие.
Полностью всё автоматизировать возможно (ну, почти всё), вопрос только в экономической целесообразности данного мероприятия. Во-первых системы довольно дорогие (то, что на видео - это примерно под миллион евро). В данном случае автоматизация оправдана, поскольку требует высокой квалификации работников, ну и с такой скоростью проверять блоки они не смогут. Во-вторых некоторые несложные на вид операции могут потребовать довольно больших инвестиций - проще оставить низкоквалифицированного рабочего.
s60
03.08.2022 16:52Там мы делаем «флюорографию» блокам цилиндров.
это показушный цех или обычный?
заметили как там чистенько, светленько, ни одного в кирзачах…?AndreyDmitriev
03.08.2022 19:49Самый обычный. Я полагаю, там прибрались немного для видео, но в целом так и есть. В кирзачах уже давно не ходят - там требуется специальная защитная обувь, но она нынче по виду от обычных ботинок/кроссовок ничем не отличается, разве что там вставлены металлические пластины в подошву и защита пальцев. Я видел цеха ещё чище, но бывают и грязные.
AndreyUA
01.08.2022 15:03Работал с коллегами из Германии, з/п и соцпакет у них достаточно неплохие.
На счет Simotion и Simovert с вами согласен, отдельная ниша, а в чем заключается владение Safety? Знание SIL и принципов построения систем безопасности? Как по мне, со стороны программиста, программирование Safety ничем не отличается от обычного программирования контроллера, есть небольшие нюансы.
AndreyDmitriev
01.08.2022 15:22Тут я имел ввиду скорее Integrated Safety, в том смысле, что если раньше весь шкаф был забит Pilz Pnoz релейной автоматикой, то теперь тренд таков, что мы заводим все критические цепи, включая экстренный останов и т.д. прямо в ПЛК (на безопасные модули). Надо понимать двухканальность, различные способы останова применительно к Motion и т.п. Вот, к примеру.
galsrv
01.08.2022 17:31Раз уж зашел такой разговор - как в известных вам производственных компаниях проводится грань между АСУТП и КИПиА? Как часто специалистов в этих областях объединяют в рамках одной штатной единицы?
В моей практике попытки слепить "универсального солдата", совмещающего в себе навыки ИТ-админа, инженера АСУТП, инженера КИПиА и местами даже энергетика регулярно приводили к вымыванию грамотных специалистов из профессии. Приличные ребята разбегались кто куда. Всё потому, что руководитель завода считал, что инженер АСУТП недостаточно загружен и надо поработать кем придется на благо родного предприятия.
После многих лет работы в таком режиме граница между АСУТП и КИПиА стерлась, сейчас это является предметом дискуссий внутри компании. Я был бы признателен тем, кто поделится своим опытом. Спасибо
Affdey
02.08.2022 09:03Зависит от объёма задач и возможностей фирмы. Совсем мелочь сделает и один человек. А так - объединение утомляет, слишком за многим надо следить. Лучше разделять на 3-4 человека - ведущий проекта, который видит в целом и определяет логику и реализацию (он же и программист и ПНР) + схемотехник + программист нижнего уровня и HMI + электромонтажник. //говорю за проекты объёма на 5-8 месяцев// Конечно, чем шире знания каждого специалиста, тем лучше.
Korvus
02.08.2022 14:37У нас отдельная служба от КИПовцев. Начальник и целых 4 человека инженеров АСУ ТП. По идее, киповцы должны подключать оборудование до клеммников, а мы от клеммников к контроллерам. По факту, киповцы занимаются полностью шкафами а мы программированием контроллеров и SCADA системой. Но по знаниям - асушники должны знать все, и как датчики подключаются и как насосы работают. Иногда приходится и начальнику КИПиА объяснять как работает оборудование и где может быть косяк.
s60
02.08.2022 15:38Но по знаниям — асушники должны знать все, и как датчики подключаются и как насосы работают.
это чтобы отвести от себя (и своего барахла) подозрения ибо самый частый случай «АРМ не работает!»… а то что АРМ — это то, последнее в цепочки «датчик — ПЛК — АРМ» + его все видят им совсем не очевидно — «я не вижу данных на АРМ — значит АРМ не работает!!!!1111»Korvus
02.08.2022 15:49Ну и это тоже. )) Почему то презумпция невиновности не действует в таких случаях, приходится постоянно доказывать что ты не виноват. ))
s60
02.08.2022 16:15Почему то презумпция невиновности не действует
это мозг включать надо… думать… это сложно… а у нас пока чтона работе два инженера кип- оба затрудняются в настройках регуляторов… только пропорциональный, тепловую мощность проектируемого шкафа не знают как считать....
мечтают о новом АйФон и бэхе семёрке…
kolesaev
01.08.2022 18:50У пищевиков заграничного происхождения за мелкие проекты можно поднимать от 500к до 1млн. Единственное, что они либо работают с теми с кем работали всегда, либо с теми с кем их заставляет заграничное руководство, либо с кем попало и зайти туда очень тяжело, только через подвязки. Я работал в одной такой компании сисадмином и в плане АСУТП там вечно были проблемы что некому допилить какие-то вещи и это, скорее всего, до сих пор происходит, особенно в условиях закрытой заграницы
@Autonomnoe, если работаешь с GeFanuc, Cimplicity, Siemens, Pilz и тп, могу попробовать сконтактировать с заинтересованными лицами из моей прошлой работы. Там пищевики с кучей разных автоматизированных линий и если мутить интеграцию с ERP, то там ценники вообще невообразимые будут.
AndreyUA
02.08.2022 14:18+1Вот расценки у немцев, которые они нам выставляли
Это в час за работу 35 часов в неделю в дневное время Сверхурочное и ночное время оплачивалось от +25% до +150% Время, которое они тратят на проезд до объекта, считается рабочим. Как говорили сами работники, они получают до 50% от этих расценок.
s60
02.08.2022 14:231) авторы подобных статей тоже столько денег хотят — почему иностранцам столько платят, а нашим нет? (наши строчат статьи «как я ушел уйти в IT»)
2) ок, расценки на ЗП их мы видим, а какие цены у них там в Германии? Не получается ли соотношение доходы/расходы примерно в то же, что и у нас?AndreyDmitriev
03.08.2022 08:29Такое сравнение - это довольно большая тема, но если взять среднюю температуру по больнице, то мне думается, что общий уровень жизни среднестатистического айтишника в Европе и России будет примерно одинаков - семья, дом/квартира, машина, отпуск на море, иногда рестораны. Я переехал больше двадцати лет назад и нет, у меня тут нет виллы с бассейном. Что касается расходов, то да - они выше, вот, к примеру, со следующего месяца у меня только коммуналка (свет, газ, вода) влетит в 750 евро в месяц. Так что так на так и выходит. Ну и не забывайте, что выше сумма - это до налогов, можете смело 30-40% откинуть. Можно, конечно, начать детально и дотошно сравнивать, сколько стоит еда, жильё, одежда, техника, налоги и т.д., но смысла нет. А, и ещё такой момент - если говорить об АСУТП, то у меня есть ощущение, что в сравнении с IT в России эта работа оплачивается по "низу" рынка, а вот в Европе - по "верху", так что тут да, есть некоторая разница.
s60
03.08.2022 09:45Ну и не забывайте
вот ваш ответ и не позволит забывать… некоторым… а то модно смотреть только на доходы «у них», а расходы видимо считают «у нас»
кстати, может кто сможет прояснить: в «Во все тяжкие», если мистер Уайт такой крутой химик (и у него уже был опыт удачного стартапа/бизнеса), то почему он не нашел себе роботу с зарплатой достойной его уровня знаний?
AndreyDmitriev
03.08.2022 08:12Всё правильно, и расценки, кстати, не самые высокие, почасовая оплата высококвалифицированного пусконаладчика/программиста на выезде может запросто влететь в 200 евро в час. Чем больше компания, тем выше расценки. Но вот 50% - это черезчур оптимистично, я б сказал 30-40% где-то. Хотя практически любая командировка - это плюс, поскольку обычно мы работаем под десять часов в день, плюс выходные, и там набегает много надбавок, плюс командировочные (иногда питание предоставляет заказчик, тогда мы вообще почти ничего не тратим).
s60
03.08.2022 09:40почасовая оплата высококвалифицированного пусконаладчика/программиста на выезде может запросто влететь в 200 евро в час.
эт ж как здорово: наладчик разгребает за всех предыдущих (от проектировщиков до монтажников) за 200 баксов в час… контора наладчика явно не против такого положения дел…
как ваши заказчики такие моменты разруливают?
или 200 баксов в час и 100 часов наладки — итого бюджет проекта и ни копейки сверху, если ваши наладчики сидят сверх 100 часов — то уже за ваш счет?AndreyDmitriev
03.08.2022 13:37Пусконаладка, командировочные, билеты - всё это заложено в бюджет (я не так давно летал в Канаду, билет стоил 5500 евро, и это оплачивал заказчик), наладчик ничего не разгребает, поскольку он уже как следует потренировался при постройке системы. И обычно мы укладываемся в сроки. Конечно, бывают непредвиденные ситуации, тогда мы начинаем работать себе в минус. Причём, по некоторым контрактам, если мы не справляемся в срок, то начинаем платить пени (лучшее, что я видел - один процент стоимости системы за сутки, что при общей стоимости в миллион - можете сами посчитать), это мотивирует. Дело в том, что система - часть общего конвейера, то есть если мы не уложимся, то у заказчика встанет вообще всё. В принципе риски просчитываются, а системы тестируются и предварительно налаживаются у нас, и доставляются в полуразобранном состоянии, так что там не так много неожиданностей бывает. Но, бывает, конечно, вот как-то раз в Южной Африке запускали несколько линий, и вместо трёх месяцев провозились шесть (но там не было "драконовских" пенальти, а прибыль заметно уменьшилась, само собой).
xanto
01.08.2022 18:57Что не так с АСУ, с точки зрения предпринимателя? Крайне сложно продать свои услуги дорого. Почему-то так сложилось, что вся эта работа стоит существенно дешевле, чем она должна стоить. Каждый раз приходится объяснять и обосновывать, почему заказчик должен заплатить за то или иное.
Вероятно, Ваш опыт связан исключительно с работой на небольшие коммерческие компании.
В моём круге этапность реализации проектов примерно такая:Формирование ТЗ на проектирование службой заказчика.
Закупка на формирование проектной и сметной документации (на этом этапе проектировщик производит предварительную оценку стоимости материалов и работ).
Закупка на разработку рабочей документации, СМР, ПНР.
Есть, конечно, в этом проблема, когда между ПД и РД происходит изменение цен (а у нас так происходит примерно всегда) - сложно влезать в бюджет.
Программист на объекте чаще всего и швец, и жнец, и на дуде игрец.
Тут уж зависит от Вашего руководства: никто не запрещает иметь на объекте монтажников, наладчиков отдельных подсистем и прочего.
ilya73
01.08.2022 19:10Странная статейка! Я хоть и тружусь на галерах вАйти, но мне удалось поработать несколько лет в одной "специфической" Питерской компании, производителю комплексов АСОДУ.
И поскольку компания была основана на "совковом" базисе, то в компании была куча отделов: отдел программистоff "верхнего уровня" (SCADA, серверный софт,...), отдел программистов нижнего уровня (контроллеры), отдел разработки - тут вам инженеры электроники, механики, математики (DSP), производство (по площади занимало 1/2 всей конторы), бухгалтерия + втюхивальщики манагеры, ...
Так вот, про что автор описал, у нас этим занимались самые "негры" и назывался этим отдел пусконаладки!
А, что такое отдел пусконаладки? Это когда ты должен не только знать, но и уметь программировать (хоть Scada, хоть контроллеры), выявить неисправность электронных модулей + уметь общаться со специалистами заказчика+сдать объект + ...
ЗЫ хз, что за компания у автора, но сколько я себя помню, то обычно "ваше" оборудование монтируют местные спецы! ;-)triinne
01.08.2022 22:20Согласен, только назовем это не пусконаладкой, а красиво - интеграцией. Не понял претензии автора. Пусконаладчики/интеграторы всегда так зарабатывали и всегда выполняли такой объем работы. Другое дело - если ты инженер-разработчик/инженер-исследователь САУ
sozercanie_kosmosa
01.08.2022 19:51+2В свое время вывел некоторую зависимость.
Все, как в обычном физическом мире, кто сидит к печке ближе тому тепла достается больше. Другими словами, IT, который занимается автоматизацией для создания реального продукта получает денег меньше, так как находится далеко, от тех, кто этот продукт продает и как следствие аккумулирует большую часть маржи с продаваемой продукции (имею ввиду пользователей приложений бизнес-логики) менеджеры различных эшелонов, на против, тот же который находится к менеджерам ближе получает больше.
ilya73
01.08.2022 22:07+1вы таки сильно удивитесь! Но ваш супер-пупер крутой код никого не удивит! А реально решает всё "вась-вась"!
triinne
01.08.2022 22:07Всем любителям математики, физики, программирования, искусственного интеллекта я бы советовал направление САУ. Грамотные разработчики САУ (особенно САУ на основе физических/глубокого обучения/гибридных моделей) получают очень большие деньги. Правда не знаю как с этим обстоит в России, есть ли вообще такие предприятия, кто этим занимается.
AlexS00
01.08.2022 22:43+2Правда не знаю как с этим обстоит в России, есть ли вообще такие предприятия, кто этим занимается.
Не знает, но советует. Тогда бы сразу назвали страны, в которых получают за это большие деньги, а главное как туда попасть вчерашнему студенту без опыта, так как в РФ опыт получить проблематично будет.
triinne
01.08.2022 22:51Во всем мире получают, а в России не получают за это большие деньги? Я вот сейчас ради интереса погуглил: в Москве/Питере есть такие компании. Думаю, если вы хорошо учились и действительно интересуетесь этим, то вас возьмут, несмотря на то, что вы студент!
thevlad
01.08.2022 23:38Разработка современных систем управления, на основе сложных математических/физических моделей это вообще несколько другая реальность по сравнению с тем, что описал автор статьи и IT вообще. Тут скорее больше нужна профильная математика/физика и специализация в области ТАУ(теория автоматического управления, как это называлось очень давно и сейчас существует в виде множества разнообразных направлений). И конечно нужен опыт. В конечном итоге может оказаться, что количество вакантных мест в несколько раз меньше количества студентов выпускаемых топовыми ВУЗами(МФТИ и т.д.) по специальности.
triinne
02.08.2022 10:40Не соглашусь с вами. Как-раз таки современные комплексные системы управления требуют знания не только ТАУ, физики, математики, но и знания алгоритмов, структур данных, оптимизации софта, машинного обучения. Например, сейчас вообще идет тренд на то, чтобы не разрабатывать сложную математическую модель, а синтезировать системы управления в реальном времени, на основе испытаний и машинного обучения. Поэтому я бы не сказал, что разработка систем управления далека от IT. Это прекрасная сфера, где соединяются практически все технические специальности.
Про вакатные места: их никогда не будет мало, потому что во-первых: такая специальность не пользуется популярностью из-за своей сложности, во-вторых: у индустрии всегда есть запрос на оптимизацию и разработку систем управления/процессов, в-третьих: разработка систем управления это настолько обширная специальность, что практически в каждой области найдется применение. Будь-то классические авиатехника, автомобилестроение, судостроение, приборостроение, робототехника, энергетика или же что-то более экзотическое вроде квантовой физики, биологии, социологии, экономики.thevlad
02.08.2022 15:29В моем понимании, человек который может в машинное обучение, какую-то прикладную математику и алгоритмы со структурами данных, в современных реалиях называется data scientist. Может ли инженер АСУ ТП переквалифицироваться в дата сайнтиста? Может, но при прочих равных это наверное будет один из наиболее трудных путей для "вливания в IT". Конечно, если мы говорим про студентов, и предлагаем им "бежать куда только можно", то да можно рассмотреть дата сайнс, особенно, если есть интерес и "глаза горят". Только причем тогда знания АСУ ТП, которые по сути будут являются балластом с очень низким КПД?
sokol_9
02.08.2022 11:17+1Вполне может быть, что в России не получают. Сплошь и рядом такое, когда инженеры работают за маленькую плату, прокачивают скилы жизни без денег и вникают в философию аскетизма. Иначе менять профессию, потому что другой такой же работы нету.
Поделитесь, пожалуйста, поисковыми запросами, и назовите хотя бы одну такую компанию, которую вы нашли.triinne
02.08.2022 11:22Такую, которая занимается разработкой систем управления?
sokol_9
03.08.2022 11:25Да, такую, что вы написали:
Я вот сейчас ради интереса погуглил: в Москве/Питере есть такие компании.
Интересуют поисковые запросы и результаты поиска.
triinne
03.08.2022 16:12Да, конечно. Только можно сначала узнать: вы не смогли найти ни одну компанию? Или и не пытались? Потому что судя по вопросу, вы даже и не искали.
nva23756
01.08.2022 23:38+3АСУ ТП действительно тухлая отрасль.
Проблема не в названии, а в том, что заказчиков значительно меньше, чем исполнителей. Крупных платежеспособных клиентов в России можно пересчитать на пальцах, а, вот ребят, которые хотят работать - вагон. АСУ ТП давало крутой доход до 2008 года, там интеграторы - пара/тройка серьезных компаний ворошили палкой в помойке заказчиков и выбирали лакомые куски. Сейчас все наоборот - заказчик ворошит палкой и нагибает всех на свои условия: цену вниз до себестоимости, 100% пост-оплата, гарантия на 5 лет, односторонние штрафные санкции. Недоволен - пошел вон с рынка, за воротами толпа. 100% постоплата позволяет заказчику не рисковать деньгами, он теряет только время.
В IT же все по-другому. Программистов явный недостаток. Зарплаты бывших студентов выше, чем специалистов с опытом в 20 лет в области АСУ и они подгоняются гигантами отрасли. За АСУ ТП Яндекс, мэйл.ру, Гугл, Микрософт, Apple, Амазон не платят.
В общем, товарищи: Python, Machine Learning, Java наше все, я, например, активно переучиваюсь и собираюсь ставить крест на своей деятельности в области АСУ ТП.
Mike-M
02.08.2022 00:54Спасибо за статью!
Ещё раз убедился, что рассматривая вакансии только в сфере B2C, я поступаю правильно )
Dogfooding forever! )Autonomnoe Автор
02.08.2022 01:09как по мне B2C это еще хуже))) об этом тоже есть статья))
https://vc.ru/life/150498-pochemu-my-ne-delaem-umnye-doma-i-ne-rabotaem-s-chastnikami
s60
02.08.2022 11:03так в чём проблема, Autonomnoe, хочешь — иди… если можешь…
Autonomnoe Автор
02.08.2022 11:50Не хочу) в статье написал, куда нужно дуть, чтобы по кпд приближаться к айтишникам)
s60
02.08.2022 12:14тогда не иди…
анекдот в темуПриходит молодой еврей к равину:
— Реббе. что мне делать? Жена неряха, дома грязь…
Реббе: разводись…
— Реббе, но я ее люблю, она такая хорошая…
Реббе: не разводись…
— Но она плохо готовит, дети голодные грязные…
Реббе: разводись…
— Но она красивая, и я ее люблю…
Реббе: не разводись…
— Но она хозяйством не занимается…
Реббе: разводись…
— Но мне с ней очень хорошо…
Реббе: ну не разводись, и вообще, прими христианство
и иди морочь голову отцу Федору…
s60
02.08.2022 12:16в статье написал, куда нужно дуть, чтобы по кпд приближаться к айтишникам)
ну так дунь… приблизь… и расскажи нам результаты в новой статье :)
drosselmayer
02.08.2022 11:07+2В комментариях вижу боль. Трудно что-то добавить в части эмоций, поэтому досыплю немного наблюдений в части упаковки АСУТП проектов. Не скажу за производство, но, например в дорожной автоматизации проекты оформляются как строительные. ИТ составляющая присутствует одной-двумя строчками в ведомости объемов работ как "АСУ такая-то 1 штука". Разработку стараются запихнуть внутрь пуско-наладочных работ, так как в этих проектах есть только деньги за поставку лицензий, деньги за поставку железа и деньги за работы по наладке и монтажу. Если вы разработчик АСУ и хотите заработать на этой теме, то вам нужно учиться вписываться в эти условия. Как пример, возьмем подход западных людей к снаряду. Когда приходит условный Сименс, у него в цене поставки будут и лицензии, и обязательства по обучению персонала, и сертификация инженеров. К вам бизнес-классом приедет некий чувак для "шеф-монтажа" с запредельным почасовым прайсом. Вам навялят обязательства по приобретению техподдержки за жалкие 30% от цены лицензий. В общем, как в старом бухгалтерском анекдоте про составление авансового отчета за командировку, "шляпа тут, только хрен ты её найдешь".
Представьте теперь, что компания понесла все эти расходы по закупке оборудования, работ и прочего, внесла в бюджет расходы на техподдержку. А на ком теперь экономить? На том самом Васе с покоцаным ноутом, который обслуживает АСУ. Просто все деньги, которые на это были, ушли холеным румынам или словакам в фирменной униформе, а также манагерам в сверкающих офисах класса А. Так устроен мир, собственно.
Подобный перекос он глобальный. Везде самый жирный кусок будут съедать корпорации. Разница лишь в объеме ответственности, который несут корпорации за свой жирный кусок. У нас их ответственность несопоставимо меньше, а условный Вася вынужден брать на себя все косяки и недоделки. Это уже вопросы к качеству юристов и менеджеров. Западные люди очень хорошо видят некомпетентность и умело ей пользуются. В итоге их Вася за свою небольшую зарплату по сути занимается диспетчеризацией заявок и мониторингом. При этом он обучен и защищен сертификатами. А наш Вася в мыле фигачит за тот же прайс. Про рынок тут уже написали много и по делу. Постепенно люди с головой действительно будут вымываться из АСУ, одновременно с деградацией систем и уходом вендоров, что через полгода-год приведет к серьезным отказам и авариям на тех производствах, которые не успеют адаптироваться. Думаю, что кроме, может быть, нефтянки, адаптироваться не успеет никто.
ndreamer92
02.08.2022 16:45Подобная ситуация не везде. Я, например, работая уже ~3 года в Швеции могу сказать что мой доход ощутимо выше среднестатистического IT-спеца. Ну и условия работы совершнно другие. В РФ в свое время, порядка 8 лет работал с пердовыми нефтегазовыми проектами - и даже имея очень приличный доход, почти был готов уходить в IT.
Serhioromano
03.08.2022 09:18Как программист веб и прикладных решений 20 лет, перед тем как перейти в АСУ, хочу обратить внимание на еще один недостаток АСУ перед IT. В IT вы можете создать продукт. Готовое решение и продавать его. В конечном итоге, можно уже ничего не делать, поехать в долгий отпуск, но продолжать получать прибыль от своих трудов. В АСУ ты зарабатываешь только пока работаешь. Как только ты пошел в отпуск на неделю, ты сразу обеднел.
s60
03.08.2022 09:47приведите, пожалуйста, пример такого продукта?
Serhioromano
03.08.2022 10:33Например компонент на Joomla, приложение на телефон, расширение для Wordpress, игра, ....
s60
03.08.2022 11:05не класс продукта, а имя собственное
F0iL
03.08.2022 16:41Эм... Так вам комментатор выше вполне четко обозначил, как найти имена, в чем проблема-то? Открываете список платных (или даже бесплатных, но со встроенной рекламой) приложений в PlayMarket, среди них будут приложения от индивидуальных разработчков - вот вам названия. Вот тут, например, есть очень хорошая статья с примерным обзорам, как и сколько на таком зарабатывают программисты, и названия самих приложений там тоже есть.
Или откройте джумловскую Extension Directory, посмотрите платные расширения от индивидуальных разработчиков - получите еще кучу названий. И так далее.s60
03.08.2022 17:06Эм… дык я хотел плавно подвести к тому, что сделать и бросить… хз что так нынче живет, чтоб толково денег приносила… всё течёт, всё меняется, нужно бежать, чтобы оставаться на месте… пилить новые фичи, добавлять новые баги, удалять старые баги, расширять функционал и т.п. и если посмотреть на даты последних релизов модных поделок, то увидим, что хозяин не забросил их…
но с казуальными играми да… не знаю, что такое, но если типа «кристаллики в метро пособирать», то да, один раз сделал и хватит, но такие вещи разве покупают? полно ж бесплатных…компонент на Joomla
была Joomla 2.5, стала 3 -> компонент надо подогнать/подпилить?
версия php была 7.2, а стала 7.3, 7.4 -> компонент надо подогнать/подпилить?
и т.п.приложение на телефон
был Android 4.4 KitKat, стал 8.0 Oreo -> программу надо подогнать/подпилить?игра
W.O.T -> аж 1.17.1.0… почему-то не остановились на 1.0.0.0
The Need for speed — первая вышла в 1994, а последняя Need for Speed Hot Pursuit Remastered аж в 2020
и т.д. и т.п.triinne
03.08.2022 17:39Прочитайте комментарий еще раз, вы его неправильно поняли. Автор не имел ввиду, что надо продуктом не надо будет работать.
F0iL
03.08.2022 17:40но с казуальными играми да… не знаю, что такое, но если типа «кристаллики в метро пособирать», то да, один раз сделал и хватит, но такие вещи разве покупают? полно ж бесплатных…
Так гляньте статью по ссылке выше, там как раз на примере казуальных игр показывается, что с них можно получить. Как ни странно да, нередко покупают. Еще бывает, что игры публикуются бесплатно, а автор имеет копеечку с рекламы. И т.д.
была Joomla 2.5, стала 3 -> компонент надо подогнать/подпилить?
версия php была 7.2, а стала 7.3, 7.4 -> компонент надо подогнать/подпилить?Ну, такое происходит все-таки не каждую неделю. А мажорные версии (где ломается обратная совместимость и API) так вообще обычно выходят раз в несколько лет.
s60
03.08.2022 17:49Так гляньте статью по ссылке выше
да, уже посмотрел — херня какая-то… типа анимированых октрыток или таких же видосиков в мессенджерах/тиктоке, кто-то ж сидит, рисует, склеивает? треки накладывает на все это безобразиебезобразие
lymes
Как там говорится, рыночек порешает? Асушники ломанутся в IT, спецы АСУ станут востребованнее, зарплаты вырастут. Но время идёт, а ничего не меняется. Хотя профессия действительно интересная.
F0iL
Программистам-айтишникам с бородатых времён была доступна удаленка и работа на зарубежный рынок, а отечественные работодатели конкурировали за кадры с международными компаниями - в результате зарплаты в провинции подтягивались к зарплатам в столицах, а зарплаты в столицах подтягивались к зарплатам за бугром (по крайней мере, до недавних пор до начала известных событий). В АСУТП и остальном инжиниринге такое по ряду причин распространено в разы меньше, отсюда и разницы в вилках зарплат.
Так что то, что не смотря на дефицит толковых спецов, в АСУТП зарплаты растут не то чтоб активно, влияет ещё специфика рынка и работодателей, как в старой цитате "...это чаще всего, само-окупаемое, само-финансируемое российское предприятие, с российскими же заказчиками, российским рынком сбыта и российским начальником — бывшим инженером возрастом 50+, ранее также работавшим за копейки. Поэтому мысль у него такая: «Я всю жизнь пахал, чтобы я какому-то молодому платил? Перебьется!» Таким образом, сильно больших денег у подобных предприятий нет, а если и есть, то вкладываться они будут отнюдь не в вашу зарплату".
EVolans
Я уже давно заметил, что количество твоих реальных знаний и твой опыт как специалиста очень и очень косвенно влияют на твою зарплату. Основной критерий один - это место где ты работаешь и готовы ли они платить кадрам. При этом если они платят - качество кадров их зачастую даже не волнует.
milkground
Можно в этот список добавить ещё сложность работы. У многих в голове есть стереотип, что если работа сложнее, то она обязательно будет оплачиваться выше.
spacediver
Слышал тезис: «чем меньше зарплата, тем тяжелее она достаётся»
Sergeant101
То же такая мысль в голову приходила.
justPersonage
2 професси. Кому легче?
1.Библиотекарь в каком нибудь вузе(школе...)
2.senior haskell developer
SMUWork
Думаю библиотекарю в FAANG будет на порядок проще чем senior haskell developer в вузе геленджика.
wrk9
Без проблем. Не хочет платить нормально - пусть не платит. Тогда нужно уходить из профессии или менять локацию. Зачем работать за копейки? Рыночек пусть решает, надо давать рыночку работать.
8street
Рынок не порешает. Дело в том, что при каждом крупном предприятии имеются ВУЗ, который выпускает 20-100 специалистов АСУТП ежегодно, которые готовы работать поначалу за минималку.
Sergeant101
Как показывает практика - не готовы.
DarkWolf13
не готовы и не могут....на работе два инженера кип- оба затрудняются в настройках регуляторов...только пропорциональный, тепловую мощность проектируемого шкафа не знают как считать....сечение силового кабеля в зависимости от длины тоже оказалось для них открытием...и еще много разных вопросов которые вызвали затруднения. Плюнул на все уволился оттуда. А так отрасль вроде и с деньгами, но из-за большого количества контролирующих органов и бюджетных денег появляются откаты заказчику и прочим , которые удешевляют труд. Много нюансов требуется уточнять у вендоров, техподдержка которых, не всегда готова правильно ответить и вообще ответить, даже наличие пройденных, за свои или работодателя деньги, курсов не спасает. Там где нет "бюджета" проекты дают хорошо заработать, а так показывают развалины и просят сделать что бы работало за полкопейки....
AlexS00
Нет, дело не в этом.
Вот Вы уволились, остались такие что
Вопрос: производство встало? Нет? Тогда и проблем НЕТ. Этих сотрудников/квалификации достаточно.
Sergeant101
Есть такое понятие как инерция, сразу не встанет, но будет неуклонно хиреть.
AlexS00
Правильно. Но одна из главных характеристик менеджмента РФ это то, что они временщики. Поэтому проблем НЕТ.
s60
вот совершенно верно! процессы крутятся — лавеха мутится, чего еще надо?
InChaos
Часто при потных отношениях предприятие-ВУЗ есть схема при которой те, кто не поступил на бюджет, могут поступить на платное отделение, но за деньги этого предприятия, т.е. для себя бесплатно, но с договором 3-5 лет отработать на предприятии. Тут уже выбор или платить самому за обучение или бесплатно отучится, но будь добр отработай. Естественно на средних ЗП, никто таким большую ЗП не обещает.
Walker99011
Это, кстати, называется "целевое обучение"
tvr
Корпоративный хёнтай :))
Oleksii21
Не все 20-100 выпускников будут специалистами или толковыми специалистами, каждый должен сделать свое количество ошибок на пути к опытному и грамотному работнику, иногда эти ошибки в разы дороже чем ЗП всего отдела асу тп как в проектировании, так и в производстве. Дешевле платить хорошую ЗП именно специалисту который отфильтрует эти ошибки.
AndreyUA
Самая большая проблема в том, что ВУЗ не выпускает специалистов. После ВУЗа люди приходят абсолютными нулями в профессии и учатся на месте. Большинство выпускников контроллеров (PLC) не видели в ВУЗе, а те которые видели - видели их из далека. В лучшем случае, они что-то делали на arduino и т.п., а это совсем не промышленный контроллер, подход и философия программирования совсем другая.
В IT сфере после ВУЗа выпускник зачастую имеет общее представление о профессии и уже может работать джуном. Да и google, stackoverflow + доступность документации играет в плюс. Попробуйте сравнить информацию по программированию контроллеров siemens с программированием на с#.
PqDn
ну знаете по разному бывает, я умел на фануках прогать когда только технарь закончил
правда в итоге в чистом IT работаю
Kelsink
Я, в целом, согласен. Вуз учит искать информацию и дает базовые навыки, но вы про какие-то странные вузы говорите.
Я закончил профильный - нефтяной, правда я именно программист, а есть АСУТП кафедра. Тем не менее мы PLC (сименсы) трогали и программировали, SCADA настраивали, автоматику для ректификационной колонны я проектировал и подбирал эти гребанные железки по журнальчикам. Успел даже пару лет покататься по северам, делая небольшие проекты. Собственно после этого четко понял почему я не хочу с нефтянкой/железками связываться. Выводы +/- как в статье. Унылое болотце с нормальной, но фиксированной сверху з.п.
AlexS00
В корень смотрите. Да, проблема образованных кадров в РФ в том, что их много. То есть образование в РФ избыточно. Да, ниже пишут, что выпускники ничего не знают, не умеют. Но. Специалистом можно стать только на работе.
matroskinufa
И их не хватает. Их рассуют по другим отделам, зачастую не по профилю. В результате они, через некоторое время, теряют начальную квалификацию...ну и т.д.
Вообще можно найти нормального работодателя, точнее менеджера, который будет снабжать тебя заказами, но это трудновато. Да и не так уж и стабильно. Все равно придется затыкать дыры между крупными и вкусными контрактами. Можно пойти в крупную контору, но тут ставка, галерный принцип, зато стабильно. Иногда - стабильно сидеть посередь тайги.
s60
порешает-порешает… если не справитесь своими силами (ОВЕН, КОНТАР и т.п.), а делать надо — пригласят за нефтедоллары Штефанов, Майклов, которые, как в старые добрые времена, сделают всё на том же Siemens, Rockwell, Schneider, Honeywell, Triconex, Yokogawa
nmrulin
Насколько я понимаю специфику АСУ, самое ближайший аналог среди программистов, это программисты микроконтроллеров и прочего железа. А там зарплаты как раз самые низкие в IT.
eximus
Подскажите ссылочку, где это глянуть. Меня в гугле забанили.
пс: и {просто уточняю} не путаете ли вы программирование микроконтроллеров и системное программирование?
F0iL
Например:
(отсюда: https://habr.com/ru/article/649423/)
Ну и личные наблюдения на протяжении последнего десятка лет это в принципе подтверждают.
Gordon01
Подтверждаю как бывший эмбеддер
NetBUG
Судя по оценкам коллег, просто не нужно идти в АСУ ТП в России.
fixik-papus в своё время (года два или три назад) отлично описал, насколько в этом плане рациональнее искать работу по специальности в европейских странах с активно развитым производством (Польша, Чехия, Германия, Финляндия).