Если вы отправитесь на любой тематический АСУ ТП-форум или группу, вы к сожалению не найдете обсуждения стандартов, архитектуры РСУ, лучших практик для ISA101, ISA88, ISA95.
В лучшем случае вы найдете дискуссии на тему «являются ли АСУ-шники настоящими программистами когда пишут код на LAD/FBD» или «обязан ли монтажник/программист знать технологический процесс объекта на котором работает» и т.п.
Проще говоря – сообщество и особенно ИТ-сообщество разработчиков в сфере АСУ ТП отсутствует в принципе.
Справедливости ради стоит отметить, что профильные ИТ-шники встречаются в АСУ ТП. Обычно это молодые ребята, которые в институте действительно изучали алгоритмы, структуры данных и базы данных. Будучи еще студентами они случайно попадают в АСУ ТП, где не могут нормально применить свои навыки и с ужасом убегают в Web или Enterprise, потеряв в лучшем случае 1-3 года.
В чем же дело?
Безусловно причин у этой проблемы можно найти великое множество, но на мой взгляд их общим корнем является МЭК-стандарт в части разработки программного обеспечения (IEC 61131).
Основной целью стандарта было повышение скорости и качества разработки программ для ПЛК, а также создание языков программирования, ориентированных на технологов, обеспечение соответствия ПЛК идеологии открытых систем, исключение этапа дополнительного обучения при смене типа ПЛК.
Но на практике, помимо перечисленных плюсов, это привело к «эффекту-кобры» в сфере автоматизации, а именно:
Огромное количество сред разработки PLC / HMI / SCADA («зоопарк»). Каждый из производителей автоматики разрабатывает свою «уникальную» IDE и урезаный язык программирования.
Отсутствие специализации и разделения труда. Это тонкая проблема вытекающая из первой. Из-за того, что профильные программисты буквально не хотят работать на суррогатных языках программирования - работу вынуждены выполнять инженеры-КИП, электромеханики, монтажники, технологи - специалисты, которые рады бы делать свою любимую работу, но сложившийся отраслевой стандарт буквально заставляет их программировать.
Полное отсутствие культуры разработки инженерного ПО, отсутствие сообщества, унизительные заработные платы. Естественно, у тех, кто вынужден этим заниматься «потому что надо» это не вызывает ничего кроме раздражения «поскорей сделать эту ненавистную програмщину». Отсутствие архитектуры, комментариев, версификации это лишь стандартный набор того с чем вы будете иметь дело при доработке ПО для инженерных систем.
Сложный и объемный фронт работы Инженерам, которые не смотря на все это терпят, потому что любят свою работу (на Хабре есть отличная статья на эту тему).
Что же делать?
На мой взгляд необходима масштабная популяризация IOT оборудования - должно появляться как можно больше открытых GNU/Linux IOT-решений способных решать задачи автоматизации.
Со временем это выведет из употребления устаревшие IEC PLC.
Разработчики АСУ ТП смогут разрабатывать и отлаживать ПО с помощью современных языков программирования и IDE.
ИТ-шники будут оставаться в сфере, а значит неизбежно появятся реальные стандарты и качество.
Компании смогут изменить экономическую модель, что позволит платить Инженерам и Программистам АСУ ТП достойную заработную плату.
Если вы инжиниринговая компания и вас есть ресурсы — займитесь развитием IOT-решений для АСУ ТП!
Комментарии (188)
petuhoff
19.05.2023 12:40Есть ответ - SimInTech! Вот пример разделения труда:
1dNDN
19.05.2023 12:40+14Доводилось мне для SimInTech модуль из матлаба портировать.
Извините, пригорело
ИМХО - язык крайне ограниченный и построен по принципу наибольшего удивления. Сообщения об ошибках при компиляции архинеинформативные и не дают совершенно никакой информации о самой ошибке.
Ну и отдельное неудовольствие - читать документацию для ЯПа SimInTech.
P.S. Открыл сохраненные три месяца назад ссылки на их доку - все протухли и ведут на заглавную страницу
UPD: Ну и да, это отличная иллюстрация тезиса статьиразрабатывает свою «уникальную» IDE и урезанный язык программирования
Уникальная замена матлабу с преферансом и куртизанками, которую нужно везде использовать только потому, что она отечественная
petuhoff
19.05.2023 12:40+6Ну во первых SimInTech используют там где, Matlab Simulink просто не вывозит по своим возможностям. Например, в 2000-x, SimInTech (тогда это называлось ПК МВТУ) использовался для проектирвания и моделирования УСБТ управляющей системы безопасности технологи, для реактора черобыльского типа РБМК, с живым экспериментом на смоленской АЭС.
Потом была простая задача алгоритмы насосной перекачивающей станции (НПС) проверить. Это в 2008 у Вексельберга на ВСТО, у него тогда даже яйца фаберже были западные не говорял уже о софте. И матлаб с симулинком он тоже купил, только помер матлаб с simulink на половине алгоритмов одной НПС, а в SimInTech их собрали все полтора десятка, и он считал.
Солнечная батрея для спутника Решетнева году так в 2015, опять matlab с simulink пыхтел кряхтел, с трудом матрицу 100х100 ячеек посчитал и помер. В SimInTech мы просто памяти докупили для сревера и посчитал полную солнечную батарею с учетом затенения.
Ну а сомвсем недавно в 2022 Яндекс просил посчитать воздушное охлаждения дата центра где 8000 сервеных юнитов, в каждом из которы 4 вентилятора и два ПИД регулятора. Matlab и Simulink снова в пролете, заказ Yandex нам отдал.
Цифровые двойники АСC в SimInTech, до их изобретения. Какая компиляция? Там нет никакой компиляции, для проверки запускай на расчет и смотри что происходит прямо на графической схеме, в этом и смысл стуркутрного програмирования в графическом виде. Если расчетная схема запустилась на расчет и выдала нужны результаты, то все решено можно заливать в контроллер, все скомпилируется без ошибок.
Ну а прямое сравнение лоб в лоб Simulink и SimInTech мы давно уже выложили в ютубе 6 прошло, до сих пор никто не может объяснить что там Simulink считает.
И кстати если не наравится встроенный язык программирования, никто не мешает собственные блоки делать на Си, примеры там есть.
1dNDN
19.05.2023 12:40+10Matlab Simulink просто не вывозит по своим возможностям
Не знаю, как там с расчетом реакторов, не владею предметной областью, но давайте сравним функционал SimInTech и Matlab на примере функции eig:
SimInTech
eig(M) – функция возвращает массив собственных чисел матрицы.
Matlab
e = eig(A)returns a column vector containing the eigenvalues of square matrixA.[V,D] = eig(A)returns diagonal matrixDof eigenvalues and matrixVwhose columns are the corresponding right eigenvectors, so thatA*V = V*D.[V,D,W] = eig(A)also returns full matrixWwhose columns are the corresponding left eigenvectors, so thatW'*A = D*W'.The eigenvalue problem is to determine the solution to the equation Av = λv, where A is an
n-by-nmatrix, v is a column vector of lengthn, and λ is a scalar. The values of λ that satisfy the equation are the eigenvalues. The corresponding values of v that satisfy the equation are the right eigenvectors. The left eigenvectors, w, satisfy the equation w’A = λw’.e = eig(A,B)returns a column vector containing the generalized eigenvalues of square matricesAandB.[V,D] = eig(A,B)returns diagonal matrixDof generalized eigenvalues and full matrixVwhose columns are the corresponding right eigenvectors, so thatA*V = B*V*D.[V,D,W] = eig(A,B)also returns full matrixWwhose columns are the corresponding left eigenvectors, so thatW'*A = D*W'*B.The generalized eigenvalue problem is to determine the solution to the equation Av = λBv, where A and B are
n-by-nmatrices, v is a column vector of lengthn, and λ is a scalar. The values of λ that satisfy the equation are the generalized eigenvalues. The corresponding values of v are the generalized right eigenvectors. The left eigenvectors, w, satisfy the equation w’A = λw’B.[___] = eig(A,balanceOption), wherebalanceOptionis'nobalance', disables the preliminary balancing step in the algorithm. The default forbalanceOptionis'balance', which enables balancing. Theeigfunction can return any of the output arguments in previous syntaxes.[___] = eig(A,B,algorithm), wherealgorithmis'chol', uses the Cholesky factorization ofBto compute the generalized eigenvalues. The default foralgorithmdepends on the properties ofAandB, but is generally'qz', which uses the QZ algorithm.If
Ais Hermitian andBis Hermitian positive definite, then the default foralgorithmis'chol'.[___] = eig(___,outputForm)returns the eigenvalues in the form specified byoutputFormusing any of the input or output arguments in previous syntaxes. SpecifyoutputFormas'vector'to return the eigenvalues in a column vector or as'matrix'to return the eigenvalues in a diagonal matrix.Коротко:
simintech умеет считать вектор с собственными числами матрицы,
matlab умеет считать вектор с собственными числами, матрицу (правых?) векторов собственных чисел, матрицу (левых?) векторов собственных чисел, матрицу обобщенных векторов собственных чисел от двух матриц, плюс все это с отключаемой предварительной балансировкой, используя векторизацию Холецкого или обобщенную декомпозицию Шура, а так же с настраиваемой формой выхода.Еще короче: simintech умеет в
e = eig(A), а matlab умеет в[V,D,W] = eig(A)и[V,D,W] = eig(A,B), что немного не соответствует вашему тезису о большем количестве возможностей у SimInTech.Matlab и Simulink снова в пролете, заказ Yandex нам отдал
Что-то мне подсказывает, что тут определенно есть какая-то связь с тем, что Mathworks располагается в США
petuhoff
19.05.2023 12:40+2Что-то мне подсказывает, что тут определенно есть какая-то связь с тем, что Mathworks располагается в США
Ошибаетесь, тут вы, это еще до войны было и Yandex сначала в Експоненту обратился и те честно пытались, но "не сшмогла, я не шмогла".
Еще короче: simintech умеет в
e = eig(A), а matlab умеет в[V,D,W] = eig(A)и[V,D,W] = eig(A,B), что немного не соответствует вашему тезису о большем количестве возможностей у SimInTechИ что? Как вы опровергли тезис о возможностях? Какой практический смысл от этих функций, если на реальных задачах он валится и сыпется и тормозит дико. Я так же могу показать навскиду какие нибуть формулы энтропии воды и пара на линии насыщения, которых нет в матлабе и есть в SimInTech только что это доказывает? Вам нужны новые функции? Обратитесь к разработчику сделают. Можно и самому на си реализовать, система открытая. Например в 2010 году к нам обратились из франции им нужны были элептическиие интегралы, в Matlab Simulink их не было и те делать отказались для французов, что то в ядро добавлять.
И теперь это есть в SimInTech, но нет у Simulink. Причем это не просто "шоб было як у людей", а для решения конкретной практической задачи в рамках расчета термоядерного реатора.
А вот эти японские товарищи, из научного центра морской техники, даже собрали все в Simulink, все функции были, но скорость расчета не позволилам им двинуться дальше к экспереметам. Купили японцы SimInTech, после сравнения функционала с Simulink.
N-Cube
19.05.2023 12:40но "не сшмогла, я не шмогла"
Это называется «откат 50%+», нашли чем хвалиться.
petuhoff
19.05.2023 12:40+2У Yandeкса откат? Смешно. Там зарпалата инженера разработчика системы охлаждения дата центров, которму продавали Matlab примерно такой же по размеру, как наш с ними контракт на моделирование охлаждения дата центра, ему откат брать себе дороже.
Мы же не Exponenta которая в МГТУ им. Баумана больше чем на $1 000 000 (Миллион, Карал, баксов!) Matlab продавала.
greensun1
19.05.2023 12:40+10В посте нет полного понимания проблемы программирования технологическими процессами. Написание программного обеспечения для полевого уровня АСУ ТП отличается от обычного IT весьма существенно. Если для SCADA, MES и ERP можно переносить идеи из мира IT, то на полевой – нет.
1. Программы должны быть надежны и просты, и легки в понимании длительное время эксплуатации. За время эксплуатации технологической линии до ее капитальной реконструкции может поменять не одно поколение сред разработки. Обновлять микропроцессорные системы полевого оборудования работающей технологической линии никто не будет, если вдруг появляется новая крутая технология. От того, что вдруг появится новый супер-пупер-мелафон, от его внедрения насос, сушилка, сверло не станет работать по другому. Необходимо иметь возможность внесения небольших изменений на все время эксплуатации технологической линии. А для этого код должен быть понятен текущему работнику и сейчас и через 10 лет. (Пару лет назад видел SCADA сделанную на Microsoft Excel 97 на деревообрабатывающем комбинате. Ее функционал их устраивает за исключением поставленного пароля и не возможности внесения некоторых коррекций в формулу расчета).
2. Внесение изменений во многих отраслях промышленности требует обновление проектной документации и длительных не дешевых согласований. Кроме этого доказанной надежности используемого программного обеспечения. Если вдруг из-за зависания или бага не сработает ПАЗ, взорвется колона синтеза аммиака и потравит людей. Кто будет отвечать? То что хорошо для умного дома побаловаться не подходит для большинства производств.
3. Очень многие технологические процессы имеют свои особенности, которые больше нигде не встречаются. Технолог их понимает. Поэтому за рубежом технологи непосредственно могут писать несложные алгоритмы, вносить изменения в программы без участия IT. И их этому обучают. Это стандартная практика. Это на постсоветском пространстве свой путь.
PS. Предпочту, чтобы насосная станция водоснабжения управлялась стареньким Siemens s-300 (начал выпускаться еще в прошлом веке и до сих их выпускают), с программой написанной на одном из языков IEC 61131-3? чем последним айфоном с программой написанной на языке из первой пятерки в самых популярных языков программирования.
PSS. У меня ощущение, что в управлении техпроцессами мы накануне грандиозного шухера. Снижения уровня подготовки инженеров, технологов. Отсутствие системности в принятии в автоматизации начнет приводить к крупным промышленным катастрофам.
PSSS. Язык АДА еще старше языков IEC 61131-3, но до сих пор используют.
mayorovp
19.05.2023 12:40+15Что-то вы путаете. Идеи и практики из мира ИТ — они как раз про понятность кода, и про то что код не должен зависеть от IDE.
Это как раз в IEC 61131-3 из пяти языков три графических, программы на которых без подходящей им IDE даже не посмотреть.
vassabi
19.05.2023 12:40кстати, подумалось, что современный "ограниченный ИИ с распознавалкой рисунков" - дает возможность рисовать код напрямую в графике, с трансляцией в какой-надо-код. Человеку надо будет только нарисовать, указать - во что это счастье передать и проверить результат в железе (на стенде).
petuhoff
19.05.2023 12:40+3Просто смотреть на программу управления технологическим процессом, очень часто бесмысленно без хорошего знания самой промышленной технологии. Ну например мне бесмысленно смотреть на программу управления химической колонны крекинга, там нужно лет 5 посидеть в университете над формулами органической химии, что понять есть ошибка в пересчете температуры и показания датчика в парциальное давление газовой фракции или нет. Поэтому графические языки и пременяются, что химик технолог мог пальчиком по линии провести и увидеть, что у него уставка по температуре не срабатывает на низком давлении, при снижении расходи ингибитора. Хотя нас Си будет нормальный рабочий код,даже структурно красиво оформленный.
ООП в графических языках програмирования
https://habr.com/ru/articles/736320/comments/#comment_25566424
YDR
19.05.2023 12:40-1в то же время, существует подход, позволяющий получить результат(найти проблему) без 5 лет органической химии. Главное, не выходить за рамки безопасных режимов работы.
N-Cube
19.05.2023 12:40+2Будьте любезны пояснить, каким макаром связь температуры с давлением газа из термодинамики превратились у вас в органическую химию и чему такому нужно учиться озвученные пять лет, чтобы показания манометра прочитать? « химик технолог мог пальчиком по линии провести» - вот этому?
iig
19.05.2023 12:40В термодинамике обычно используется идеальный газ. В нефтехимии, наверное, есть своя специфика.
vassabi
19.05.2023 12:40Отсутствие системности в принятии в автоматизации начнет приводить к крупным промышленным катастрофам.
главное - чтобы не в масштабах земного шара. Региональные - человечество переживет (хотя возможно это будет как крушение бронзовой эпохи :) но тем не менее)
Debianer70
19.05.2023 12:40+1Подпишусь под каждым словом. АСУТП - это вам не в "умный дом" поиграться, тут одна ошибка может стоить многих жизней. В управлении конвейерами. В вентиляции. В системе орошения. (Не дай бог!)В пожаротушении...
Это не для банков утилитки кропать, здесь за каждой строчкой кода - чья-то жизнь.
А платят - да, маловато. Но мы работаем. Ведь если не мы- то кто?
SpiderEkb
19.05.2023 12:40+4Это не для банков утилитки кропать, здесь за каждой строчкой кода - чья-то жизнь.
Что есть "утилитки для банков"? Всякие мобильные клиенты? Так он к банку весьма опосредовано относятся. Там нет никакой логики - им предоставляются готовые REST API - "вызови вот это получишь вот то". А вся логика в конечном итоге реализуется на самом нижнем уровне (ядро банковской системы)
Про банк уже писал в комментариях тут - когда оказываешься на уровне ядра, то обнаруживаешь что и платформа специфическая (можно погуглить про IBM i, бывшая AS/400) и языки специализированные (тот же RPG - тут как-то про него была статейка) и требования весьма специфические по производительности, ресурсам (писал в коментариях примеры решаемых задач).
И, к примеру, час недоступности банка оценивается этак миллионов в 25 только прямых финансовых убытков, не считая репутационных, штрафав от регулятора (время недоступности нормируется минутами, дальше уже штрафы вплоть до лишения лицензии).
Я не хочу сказать, что где-то проще или сложнее. Просто везде есть своя специфика.
И в АСУТП далеко не всегда речь идет о жизнях (да, такое там тоже есть) и в финтехе далеко не везде мобильные утилитки и джава... У нас, кстати, большая часть разработчиков - достаточно солидные люди от 40-ка и старше (я пришел в 52, сейчас 58, есть и постарше). Т.е. к "хипстерам-смузихлебам" ну никак не отнести. И каждый приходящий первые три месяца только проходит обучение работы на платформе нашей. А "в силу" более-менее входит где-то через год. Когда осовит все тонкости и особенности платформы, нюансы языка, весь набор "неформальных требований к раазработке".
Да, тут намного лучше с деньгами. Но не легче ни разу. Просто так никто не заплатит - каждую копейку отработать надо.
Лично я считаю, что те шесть лет что работаю тут, дали мне не меньше полезного опыта в разработке (не в плане каких-то конкретных навыков, но в плане подхода), чем предыдущие годы в АСУТП.
vassabi
19.05.2023 12:40+1Но мы работаем. Ведь если не мы- то кто?
вот с одной стороны понимаю какой классный лозунг, но с другой стороны точит мысль "а чем это отличается от разводки? если люди там такие уникальные - почему нет переманивания ?"
GDragon
19.05.2023 12:40Пару лет назад видел SCADA сделанную на Microsoft Excel 97 на деревообрабатывающем комбинате. Ее функционал их устраивает за исключением поставленного пароля и не возможности внесения некоторых коррекций в формулу расчета
Excel-97 использовал короткий ключ шифрования, для него уже много лет есть утилиты практически мгновенно вытаскивающие пароль.
mphys
19.05.2023 12:40+2Вы отчет ВНИИА им. Духова читали на ваш симинтек?) Я люблю симинтек, и пользуюсь им (увы), я даже хорошо знаком человеком, который его создал (Козлов О.С.), но это же ад, просто ад
BasilM
19.05.2023 12:40+41Все решил рынок. Рынок привел в АСУ ТП тех, кто там готов работать за те деньги, которые там готовы платить и использовать те инструменты, которые там есть. Всех, кроме отдельных энтузиастов, всё устраивает
dyadyaSerezha
19.05.2023 12:40+6Именно. Почему-то в списке “что делать" не нашёл пункта под номером ноль - повысить наконец эту "унизительные заработную плату".
MiraclePtr
19.05.2023 12:40+26Как человек,
всравшийпосвятивший АСУТП лет так пять и сбежавший в прикладное и системное программирование оттуда с большим удовольствием и облегчением - подтверждаю, всё так.Впрочем, тут можно еще добавить, что в отечественной embedded-разработке (на которую тоже пришлось потратить часть своей профессиональной жизни), даже не смотря на отсутствие МЭКовских языков, и казалось бы, гораздо большую близость к "классическому" программированию, ситуация тоже так себе (зарплаты, нередко ужасная культура разработки, местами озлобленное сообщество), в чем-то получше, а в чем-то даже хуже.
ripandtear
19.05.2023 12:40+6Я учился в универе на АСУТП, но я миновал данный этап, увлекшись на последних курсах микроэлектроникой и программированием микроконтроллеров/DSP. На них ушло около 8 лет. Сейчас успешно вроде-бы вкатился в С++ (последние стандарты) и программирование под десктопы.
Все что вы написали чистая правда, теперь вспоминаю нашу действительность разработки на "железе" как страшный сон - только как хобби и не более того.
vkni
19.05.2023 12:40+15зарплаты, нередко ужасная культура разработки, местами озлобленное сообщество
Первого пункта достаточно, а остальное из него просто вытекает.
MiraclePtr
19.05.2023 12:40+22Самое интересное, что не только из него. Там своя атмосфера, так сказать.
Например, нередко embedded-программированием занимаются вообще инженеры-электроники или бывшие инженеры электроники. И у них во-первых просто нет необходимого багажа знаний именно по разработке ПО (и, например, понимания, почему необходима и какой должна быть грамотно сделанная архитектура программы, владения хорошими практиками разработки сложных программных систем, и т.д.) и научиться/подсмотреть не у кого, потому что вокруг все такие же, а во-вторых нередко процветает довольно наплевательское отношение к коду, типа, плату и железку сконструировать так, чтобы все работало - вот это искусство, а код любая обезьяна на коленке написать может (и в итоге пишет, да).
А во-вторых, там есть своеобразная профдеформация, очень долгое время встраиваемые системы были очень ограничены в вычислительных возможностях, нужно было экономить каждый байт и каждый такт, и в то же время по функционалу довольно они были относительно простые. Сейчас времена поменялись - у современных чипов даже стоящих копейки ТТХ весьма достойные, и в большинстве случаев уже нет нужды экономить каждый байт и каждый такт, зато важны читаемость, поддерживаемость и качество кода, потому что функционал сильно усложняется и растет - но подход "здесь так принято" в отрасли очень силен, и в итоге получается то что получается (и ладно еще если обходится без жертв).
Ну а озлобленность - да, вполне возможно из-за зарплат и атмосферы в подобных учреждениях в целом, особенно если это какой-нибудь советско-постсоветский завод или НИИ. И чтобы прочувствовать на себе это, достаточно пересказать написанное в моем комментарии на любом эмбеддерском форуме или группе в соцсетях, запастись попкорном и наблюдать эпичный шитшторм с крепкими выражениями.
victor_1212
19.05.2023 12:40+4> у них во-первых просто нет необходимого багажа знаний именно по разработке ПО (и, например, понимания, почему необходима и какой должна быть грамотно сделанная архитектура программы, владения хорошими практиками разработки сложных программных систем
embedded-программирование это вообще самое сложное что бывает в разработке sw + одновременно самое простое, т.к. системы бывают разного уровня сложности, назначения и важности, поэтому супер трудно говорить сразу обо всем, эта тема знакома, т.к. занимаюсь примерно этим достаточно долго, привел бы такой пример - математика, это просто или сложно, очевидно зависит от уровня, и конечно не сводится к таблице умножения
DerSpiwak
19.05.2023 12:40+3Да ну в смысле. Задачи очень разные бывают, одно дело сделать девайс с каким нибудь тач экраном чтоб там плавно менюшки листались и совсем другое скоростной ШИМ контроллер, которому действительно каждый такт на счету, а совсем третье сделать прецизионный измеритель физ. величин. Для всех этих случаев нужен софт, только требования к нему могут быть совершенно разные
victor_1212
19.05.2023 12:40требования разные, например кто-то делает embedded sw для boeing, насколько знаю там для больших систем ada до сих пор используется среди прочего, с контроллерами такие системы трудно сравнивать
vkni
19.05.2023 12:40+9Самое интересное, что не только из него. Там своя атмосфера, так сказать.
Люди, которые в капиталистическом мире могут работать почти забесплатно, достаточно специфические. Тем более, что сейчас деньги — это мерило статуса. Вы, чтобы осознавать свой высокий статус специалиста, должны получать большую зарплату (дома можете её хоть сжигать).
SpiderEkb
19.05.2023 12:40+30Ох... Как Вас понимаю...
Большую часть жизни отдал разработке системы мониторинга инженерного оборудования зданий. Применялось главным образом в ЖКХ - т.н. системы ЛДСС (лифтовая диспетчерская связь и сигнализация).
Нас была небольшая группа энтузиастов (в разработке в разные годы было задействовано 4-6 человек - это на все). Начинали году... в 93-м, по-моему. Когда никаких аналогов в тране не было вообще, а на диспетчерских стояли "шкафы" ПД-32 с лампочками и кнопочками и толстым пучком провдов (от каждой лампочки к каждому устройству отдельная пара шла). Т.е. с голой идеи. Вообще с ничего. Сами архитектуру придумывали, сами контроллеры проектировали и программировали (первые были на 8080), сами протоколы обмена (тогда еще все было на RS-485), пользовательский интерфейс, принципы формализации описания разных типов устройств...
Еще потом приходилось потенциальных клиентов уговаривать поставить систему - им "и так все хорошо".
Ладно хоть была "подпорка" - одна контора, которая лифты обслуживала - у них кой-какая база производственная была, монтажники ну и обслуживанием потом занимались...
Но развились как-то. Последняя версия системы уже вполне современная была - RS-485 остался на местных линиях. Между УСО (устройство сопряжения с объектом) и IP-шлюзом ("концентратор" к которому несколько ближайших УСО подключалось). Дальше уже UDP.
В центре всего - "микроядро". С одной стороны к нему по UDP IP-шлюзы, с другой, по TCP, интерфейсные клиенты (разного типа - диспетчер, администратор, аварийная бригада и т.п.). Ядро выполняло роль связки "многие-ко-многим", маршрутизатора, фильтра, монитора состояния IP-шлюзов и т.п. Контроллеры уже все модульные были, в основе STM32.
Денег, конечно, там немного было... Но... за идею работали - это же свое, выстраданое.
А потом в конторе руководство поменялось. Пришли "эффективные менеджеры". И сказали - "вы хорошую систему сделали, молодцы, теперь мы ее продавать будем, а дальнейшая разработка больше не нужна". Вот и сказке конец...
Короче, все разбежались. Сам теперь в банке (на удивление, ряд вещей, которые понял и освоил там, пригодились и тут, не в прямом смысле, но принципы, подходы...).
Спустя пять лет звонит директор бывший - "ай беда-беда, там проблемы какие-то, надо бы посмотреть, мы бы заплатили...". Я еще удивился - пять лет проработало вообще без никакой поддержки и сопровождения... Естественно, послал подальше - нет у меня времени уже вспоминать что там и как. Да и денег таких, за которые сейчас работаю у них нет...
Такая вот грустная история... Но не жалею ничуть. Весело было, увлекательно. Да и опыта приобрел немало на этой теме.
petuhoff
19.05.2023 12:40В этом наша основная проблема. Дефективные менегеры учатся у западных вендоров "продавать", а не разрабатывать, а инженегры считают продаванов справедливо дебилами. В итоге менегеры ни в зуб ногой в разработке и не могут построить полный цикл от разработки до продавать и рвать рынок. А ижненегры утекают в найм, туда где больше платят. Хотя по сути инженегр+продаван это и есть сикорский, боинг, форд и хьюлет с паккардом.
Катался я тут на яхте не так давно с инженегром из Yandex. Он мне сетовал за жизнь, что вот все есть, как специалист состоялся, но потолок, а хочется своего бизнеса. И даже вспоминает как будучи выпускником на коленке писал обработчик данных для эксперементов в металургии. Сейчас бы из этого можно было сделать узкоспециализированный инструмент и продавать по миру, но зарплата прогером на дядю пересилила тягу к инженерии.
cat_chi
19.05.2023 12:40+1по сути инженегр+продаван это
Менеджер по продукту. Одна из самых "хайповых" IT-специальностей на данный момент
petuhoff
19.05.2023 12:40Нет не совсем так. Продакт менегер, это кодер+продаван это другое, когда хозяину надоело самому вапаривать прогу и пинать кодеров, он повышает зарплату самому коммуникабельному из быдлокодеров и говорит, ты вот тебе палка - кодеров по голове бить и контакты заказчиков возми в службе поддержки, что бы они на тебя говно лили, ты теперь продакт менегер.
инженегр+продаван это другое. Например случае описанном выше, когда дефективные менагеры разработчиков железа турнули, инженер-продван не в другую контору ушел бы кодить на дядю, а свою контору откроет и бывших хозяев натянет на когалыгу. Поскольку у него и знания по железу и умение его делать.
Floyd54
19.05.2023 12:40+6Я тоже в прошлом АСУшник. Тоже спустя лет 8 с обьекта позвонили, типа что-то у них сломалось и надо бы помочь. На что было сказано: ребята, сорян, у меня nda по моим прошлым объектам, интеллектуальная собственность не моя, вам надо связаться с теми, с кем у вас договор заключен был на поставку и монтаж с наладкой. На самом деле я уже не хотел этим заниматься. Вспоминать, что там сделано и что можно сделать. На удивление мне с конторы позвонили. И мы не сошлись в сумме. Странно, правда? ????
Komrus
19.05.2023 12:40+16В широко распространённом на данный момент ИТ (программировании облачных и web решений, разработке коробочных продуктов) один раз разработанный продукт может продаваться сильно более одного раза. Соответственно, маржинальность продукта (по крайней мере теоретически :) - достаточно высокая.
Поэтому есть возможность платить разработчикам достаточно много. Это тянет за собой рост зарплат и остальных программистов (работодателям, дабы найти приемлемого кандидата приходится поднимать ставку).
В остальных областях (включая АСУ ТП) ситуация остаётся классическая. Один раз сделали - один раз продали.
Продали контроллеры/SCADA'у в другое здание - их опять надо с нуля программировать. (Наработки, конечно, помогают, но программировать и отлаживать надо каждый раз).
Продать
мозги инженераодну разработку много раз подряд - не получается. А трудоёмкость - ни разу не малая. Что делать - вопрос открытый.PS. Такая маленькая фирма,как Bosch, в новой линейки своих контроллеров (X) сделала возможным программирование этих контроллеров не только на АСУ ТПшных языках, но и на обычных языках программирования...
MiraclePtr
19.05.2023 12:40+2В остальных областях (включая АСУ ТП) ситуация остаётся классическая. Один раз сделали - один раз продали.
Далеко не всегда. Есть АСУТП проекты, суть которых в серийном производстве систем автоматики - например, какой-нибудь шкаф управления замерной установкой с ПЛК, модулями ввода/вывода и панелью оператора внутри, который из года в год штампуют партиями по много сотен штук, в том числе и для разных заказчиков, а шкафчики телеконтроля скважинных насосов - вообще тысячами. И то же самое с верхним уровнем (SCADA, OPC, отчеты) для всего этого дела.
Такая маленькая фирма,как Bosch, в новой линейки своих контроллеров (X) сделала возможным программирование этих контроллеров не только на АСУ ТПшных языках, но и на обычных языках программирования...
Ну, это не новость. Программироваться на обычном Си еще с десяток-два лет назад вполне умели ПЛК от тайваньцев (типа Advantech и ICP DAS), и даже от вендоров по-именитее (типа SCADAPack, которых потом купил Schneider).
vkni
19.05.2023 12:40+6Это тянет за собой рост зарплат и остальных программистов
(работодателям, дабы найти приемлемого кандидата приходится поднимать
ставку).Короче, рынок опять не вывозит стратегически важные отрасли, такие как АСУ ТП. Ничего нового.
cat_chi
19.05.2023 12:40+6Возможно, из этого следует, что они не такие уж стратегически важные? :)
vkni
19.05.2023 12:40+12Нет, не следует. Посмотрите, скажем, на зарплаты школьных учителей, которые определяют какая будет рабочая сила через 20 лет. Отрасль, очевидно, стратегически важная, если государство собирается жить несколько дольше ближайших 2-3 десятков лет. И что?
В современном мире наоборот, чем меньше человек делает полезного для общества, тем больше он получает. А если он ещё и вредит... :-)cat_chi
19.05.2023 12:40+8Мы же про Россию, верно?
Посмотрите, скажем, на зарплаты школьных учителей
А причём здесь вообще школьные учителя? Речь шла о рынке. Бюджетники вне рынка.
Отрасль, очевидно, стратегически важная
Неа, неочевидно. Стратегическая важность предполагает, что есть а) некая стратегия и б) в рамках этой стратегии вот именно это отвечает неким критериям важности.
Я не знаю ни стратегии, ни критериев, поэтому для меня нихрена не очевидно.
Могу только предполагать, что стратегия – классическая для определённой категории управленцев, которых я бы назвал осознанными вредителями. "Выжать" ресурс по-максимуму, вплоть до полного обескровливания, забрать себе всё, что можно, и свалить подальше, и плевать, что будет с ресурсом. "Школьные учителя" в такой стратегии не то чтобы не важны, они абсолютно бессмысленны.
Повторюсь, я предполагаю, а не утверждаю.
если государство собирается жить несколько дольше ближайших 2-3 десятков лет
Государство не может куда-то собираться, чего-то хотеть или принимать какие-либо решения. Государство не существует как осознанная сущность. Есть группы людей, преследующие какие-то интересы. Иногда эти группы стоят во главе государства. Иногда во главе государства стоит одна, монолитная группа, и вы можете приравнять её интересы к интересам государства. Большая ошибка.
В современном мире наоборот, чем меньше человек делает полезного для общества, тем больше он получает. А если он ещё и вредит... :-)
Интересная фраза. Красивая по форме, но по сути – бессмысленное обобщение.
vassabi
19.05.2023 12:40+8А причём здесь вообще школьные учителя?
кстати - учителя отличная аналогия АСУ ТП.
Бюджетники вне рынка.
ну да, они наверно паек получают от государства, поэтому не в курсе рыночных цен. (сарказм)
Там такой же рынок труда, как и везде - просто рынок картельный : школы держат зп учителей на одинаковом уровне, и это читается нормальным. Переходы учителей между школами затруднены.
Специалистов базового уровня до сих пор много выпускается педУнами и педИнами, поэтому рынок труда перенасыщен младшими специалистами (и они в итоге работают не по специальности).
Традиции круговой поруки.
Есть частные учебные заведения + немногие исключения из правил (но гораздо больше людей в этой профессии ИМХО работают репетиторами)
что еще ?
Я думаю - это дает достаточно много аналогий с АСУшниками (ок, у учителей - практически нет дальних командировок :D ) ...
cat_chi
19.05.2023 12:40+5ну да, они наверно паек получают от государства, поэтому не в курсе рыночных цен. (сарказм)
Я же о рынке труда говорил, а не о продуктовом :)
И там уже повеселее. Вообще нормальное явление, когда люди из одной страты не знают, как обстоят дела в другой страте. Знаю множество людей, которые не верят, что IT-шники получают 200-300к. И множество IT-шников, которые не верят в существование зарплат 20-30к.
Там такой же рынок труда, как и везде
Ага, на этом рынке один покупатель – государство. Кажется, это называется "монопсония", и это крайне вырожденный случай, так что нет уж, далеко не везде.
И то, учителя всё-таки ухитряются и на этом рынке находить альтернативы, ну да вы сами их назвали – частные заведения и фриланс (репетиторство). Беда в том, что альтернатив пока маловато. Сам альтернативный рынок развивается медленно.
vkni
19.05.2023 12:40И то, учителя всё-таки ухитряются и на этом рынке находить альтернативы, ну да вы сами их назвали – частные заведения и фриланс (репетиторство).
Ну видите, вы уже согласились, что там рынок. У АСУТПшников точно также есть теоретическая возможность перейти на JS и перетаскивать JSON'ы. Всё абсолютно аналогично.
leafup
19.05.2023 12:40+5"Выжать" ресурс по-максимуму
Какие предприятия строить кроме газа/нефти?
Микроэлектронику?
А куда эту микроэлетронику продавать?
Кто ее купит?
Тут была на хабре новость про отечественное оптоволокно.
Так его теперь некуда продавать(кроме 2 стран).vkni
19.05.2023 12:40-4Совершенно верно, кап. строй сейчас бесперспективен — только завернуться в белую простыню и умереть.
vkni
19.05.2023 12:40-3Мы же про Россию, верно?
Мы практически про все капиталистические страны.
А причём здесь вообще школьные учителя? Речь шла о рынке. Бюджетники вне рынка.
Внутри, просто наниматель — монополист, точно также срезающий косты на раб. силе. У нас капитализм, если вы не знали. Да, какие-то рудименты совка остались, но их всё меньше и меньше.
MiraclePtr
19.05.2023 12:40+3Внутри, просто наниматель — монополист, точно также срезающий косты на раб. силе. У нас капитализм, если вы не знали. Да, какие-то рудименты совка остались, но их всё меньше и меньше.
В совке так-то на рынке труда был только один наниматель, монополист - само государство.
vkni
19.05.2023 12:40-1Совершенно верно, разница между совком и гос. капом только в постановке цели. В гос. капе цель — прибыль нанимателя.
leafup
19.05.2023 12:40+3Возможно, из этого следует, что они не такие уж стратегически важные? :)
А футбол является стратегически важным?
Почему у футболистов такие высокие зарплаты?cat_chi
19.05.2023 12:40+8Почему у футболистов такие высокие зарплаты?
Потому что это демагогический вброс? :)
Вы, возможно, хотели сказать, что у некоторых – весьма немногих, на самом деле, – самых популярных футболистов высокое денежное вознаграждение? Это немного меняет аргумент, не правда ли. Та же история с актёрами, художниками, блоггерами... Такова специфика деятельности, единицы получают всё, остальные – хорошо если хоть что-то. Сравнивать подобные отрасли с тем же АСУ ТП – не очень-то логично. У Талеба в "Чёрном лебеде" неплохо описано разделение всех видов деятельности на масштабируемые и немасштабируемые. Можете почитать, если интересно.
leafup
19.05.2023 12:40+1Вы, возможно, хотели сказать, что у некоторых – весьма немногих, на самом деле, – самых популярных футболистов высокое денежное вознаграждение?
У каких инженеров АСУ вы найдете такую же зарплату как у звезд футбола?
Ответ — никаких.
Все равно звезда АСУ не получит столько сколько звезда футбола.Такова специфика деятельности, единицы получают всё, остальные – хорошо если хоть что-то.
Так почему они футболисты столько получают?
Значит кто то за это много платит.
Тогда на выходе мы получаем что в нынешней системе экономики, футбол цениться выше чем Инженер АСУ.
Значит футбол более стратегически важнее направление чем инженер АСУ.Сравнивать подобные отрасли с тем же АСУ ТП – не очень-то логично.
Почему?))) Вполне логично.
cat_chi
19.05.2023 12:40+2Забавно, что вы проигнорировали именно тот аргумент, который отвечает на все ваши вопросы. Думаю, диалог можно не продолжать
MiraclePtr
19.05.2023 12:40+5Это тянет за собой рост зарплат и остальных программистов (работодателям, дабы найти приемлемого кандидата приходится поднимать ставку).
Кстати, не совсем так. Долгое время очень существенным драйверов зарплат программистов была... удаленка. Зачем программисту в Мухосранске работать за X рублей, если можно работать удаленно на столичную фирму за 2X, а если подучить английский, то вообще на иностранных заказчиков за 3X-4X? Поэтому местные конторы были вынуждены поднимать зарплаты, чтобы не остаться вообще без работников (правда, как это будет после нынешних событий - вопрос отдельный). В АСУТП же с удаленкой довольно сложно, иногда из-за специфики, а иногда из-за закостеневших мозгов руководства.
LeoSv
19.05.2023 12:40+111. В АСУ ТП полно продукции, которая продается серийно, да по высокой цене. А уж оборудование, в котором приборы АСУ ТП используются, порой настолько серьезное, дорогое и приносящее космическую прибыль (за счет которой между прочим держится вся экономика РФ, типа, нефтегаза), что IT-шка рядом не стоит по значимости.
2. Зарплата в рыночной экономике никогда не зависит от прибыли, а зависит она от того же рынка - рынка труда. У АСУ ТП рынок труда локальный, российский, малооплачиваемый. У IT-шки российский рынок труда находится в сильнейшей зависимости от международного рынка. Эта зависимость вызвана возможностью удаленной работы и легкой релокации за счет релевантного опыта для IT во всем мире. Правда влияние международного рынка труда постепенной снижается в РФ после начала определенных событий.
xSVPx
19.05.2023 12:40+6Вы посмотрите сколько стоит в каждом конкретном случае электронный документооборот именно частное внедрение.
То, что продают один раз.
И ведь платят.
По идее АСУ ближе к деньгам, чем "классическое ИТ", почему там мало денег платят я не очень понимаю.
5 лет назад пытался проконсультироваться в эмбеддед. Ничего сложного, просто час поговорить по Скайпу. Просто поговорить. Без гарантий, без решений, просто чуть вникнуть и высказать свое мнение, дать советы. Был готов заплатить за этот час авансом 100$. И консультироваться в будущем. Написал паре десятков специалистов. Ни один не согласился.
У них там нищенские зарплаты, да ?
В пересчёте на 160 рабочих часов в месяце у меня получается 16000$...
vkni
19.05.2023 12:40По идее АСУ ближе к деньгам, чем "классическое ИТ", почему там мало денег платят я не очень понимаю.
Потому что в интересах капиталиста платить раб. силе как можно меньше. Если рынок раб. силы позволяет установить зарплату в 0, так и будет. Абсолютно вне зависимости от прибыли предприятия.
Блин, вы же всю жизнь при капитализме живёте, а рассуждаете как замшелый совок из 70х.У них там нищенские зарплаты, да ?
Там специфические люди, которые согласны на эти зарплаты при том, что всегда могут пойти в банк. Значит, им деньги не нужны. Вот вы это и выяснили.
MiraclePtr
19.05.2023 12:40+3Там специфические люди, которые согласны на эти зарплаты при том, что всегда могут пойти в банк. Значит, им деньги не нужны
Не нужно ещё забывать о когнитивных искажениях. Я когда покинул АСУ ТП и пытался перетянуть несколько бывших коллег оттуда по своему пути, такого наслушался...
Например, некоторые в принципе не верят, что какому-нибудь фуллстеку-крудошлепу за перекладывание джейсонов в айти-компании на позиции джуна могут платить з/п как у матёрого инженера на производстве, а синьору так вообще в два-три раза больше - они таких денег никогда в жизни не видели, значит такого не может быть. Люди просто уверены что таких зарплат у рядового персонала не бывает, а если и бывает, то эти теплые места заняты чьими-нибудь сынками.
Другие считают, что большие деньги просто так не платят и "там", в "большом программировании" тебя обязательно заставят пахать до смерти по 80 часов в неделю, а если не выдержишь, то уволят по щелчку пальца и больше работу потом не найдешь (все это, в принципе, иногда бывает, но уж явно не повсеместное явление сегодня) - поэтому выгоднее оставаться в своем теплом болоте, где привычно, ненапряжно и стабильно.
Третьи всё-таки решаются и пробуют что-то сделать, например изучать в свободное время какую-нибудь джаву, но тут вступает в дело тот факт, что условный инженер АСУ ТП пусть даже в компьютерах и программировании что-то понимает, но с точки зрения IT рынка труда он скорее всего будет оценен где-то на уровне джуна из-за отсутствия боевого опыта разработки на требуемом стеке, позиций куда нанимают джунов не так уж и много, а вот конкуренция среди них сейчас невероятная, и при поиске работы ему придется конкурировать не только с тысячами вайтишников с курсов и свитчеров из других отраслей, но и со вчерашними выпускниками профильных специальностей вузов... В итоге помыкавшись и получив пачку отказов на отклики человек опускает руки.
vkni
19.05.2023 12:40-2Не нужно ещё забывать о когнитивных искажениях.
Я это включил в специфичность. Но да, конечно причин множество.
petuhoff
19.05.2023 12:40+1А меня в свое время еще и гордость за специальность была очень развита, на все предложения бросить эти ядерно-реакторыне расчетные программы и идти кодировать в торговле или там банках, я принципиально не велся, только хард кор, только ядерные реакторы и атомные подводные лодки. При этом для своих первых работодателей в 2000-х, я был меркантильной сволочью требующих денег постоянно и много. И сейчас таких людей которым идея важнее денег встречаю не редко в самых разных отраслях. Им бы еще деньги научится выколачивать из менегеров, но не учат этому в школах к сожалению.
Yukr
19.05.2023 12:40+5/ Продать
мозги инженераодну разработку много раз подряд - не получается.не вполне согласен. там, где решение сильно привязано к условиям заказчика, типа складских конвейерных систем - да.
Там где есть повторяющиеся, более - менее одинаковые по функционалу решения (из того,что знаю, это например: системы управления на АЗС, с/х фермах, машинах в пищевой промышленности) можно делать "коробочный продукт" и зарабатывать на продаже копий, как в классическом ИТ.
Чем я сейчас и занимаюсь. Не с такими правда заработками, как в ИТ, это правда. Но мне это ближе.
petuhoff
19.05.2023 12:40А вот правильно, зарабатывать на том, что нравится делать всегда лучше, чем кодить на дядю.
MiraclePtr
19.05.2023 12:40+1а если человеку действительно нравится кодить на дядю? :)
vassabi
19.05.2023 12:40что-то у меня в голове на такую реплику только две ассоциации
1) это типа "крепкий союз мазохистов и садистов" ?
2) где бы взять еще побольше таких низкооплачиваемых высококлассных специалистов? а то их постоянно нехватает ....
MiraclePtr
19.05.2023 12:40+5А что не так-то? Если человек - востребованный и ценный специалист, то в айти индустрии нередко "дяди" таких ценят и очень неплохо платят. Не миллионы в месяц, конечно, но все равно более чем достаточно, чтобы не переживать из-за денег, комфортно жить и закрывать все потребности и хотелки себя и близких. Работник работает свои 6-8 часов в день, а уходя с работы вечером больше не думает и не переживает о ней вообще. Дядя снабжает человека всем необходимым для комфортной работы, решает за него всякие скучные вопросы от которых болит голова (типа поиска заказчиков и переговоров с ними, бухгалтерии, продаж, и т.д.), а если вдруг у дяди возникают проблемы, то работник извиняющеся улыбается, получает свою положенную по закону выплату, машет ручкой и уходит к другому дяде на условия не хуже. Не говоря уж о том, что очень многие крутые и интересные проекты чисто на себе попросту не потянуть, потому что там требуются большие команды разнообразных спецов, производственные ресурсы, инвестиции, и вообще совсем другие масштабы, а мелочью всю жизнь заниматься тоже скучно. Короче, этакий win-win для обоих сторон.
MiraclePtr
19.05.2023 12:40+1Для программистов альтернативой этому - работой "на себя" будет или "свой продукт" (а для этого нужна очень хорошая и жизнеспособная идея, что бывает очень не всегда), или всякие биржи типа апворка, в общем и целом то что во всем мире называется "конракторство". И в итоге почасовая ставка там действительно может быть выше, чем при обычной работе (но не то чтобы прям очень сильно, надо отметить), но и специфика совершенно другая, как и структура расходов: поиском новых заказчиков надо заниматься самому, закупать все необходимое - тоже, бухгалтерия, налоги, договора - на тебе, бизнес-аналитика, согласования ТЗ, планирования - тоже (скука смертная), соцгарантий минимум, и т.д.
И то же самое про масштабность - у примеру, в геймдеве, если очень хочется делать AAA-тайтлы, то инди-разработчику их в одну морду в принципе потянуть невозможно, без дяди никак, и во многих других сферах ситуация такая же. Да, конечно можно организовать свое предприятие, нанимать людей, развивать дело, и т.д., и таким образом самому стать "дядей" - если выстрелит, то разбогатеешь, если нет, то потеряешь все - но, опять же, человек может быть великолепным программистом, но совершенно никакущим бизнесменом/менеджером/маркетологом/итд, и заниматься всем этим ему может быть просто не интересно
mishkin79
19.05.2023 12:40+8ПЛК должен быть простым как топор и таким же надёжным. Не нравиться идея "конечного автомата" - отсутствия переполнения стека и отсутствие "нескучных обоев"? 24*7*365 работа таких устройств. Отказоустойчивые процессоры, качественные входы-выходы занимающие большую часть устройства. Вставшая колом технологическая линия, или всё производство - это "мелочи" по сравнению с отвалившимся Wi-Fi или утёкшим паролем от тиктока) Зарплаты в АСУ были копеечные ещё в "аналоговую" эпоху. Работает ведь? Не ломается? За что платить лишнее? Предлагаете разрушить парадигму - "надёжность прежде всего" ?
glazko Автор
19.05.2023 12:40Отказоустойчивые процессоры, качественные входы-выходы занимающие большую часть устройства.
Это скорее обязательное условие для модулей ввода-вывода чем к управляющему устройству. К тому же можно сделать IOT в точно таком же, промышленном исполнении (IIOT)
mishkin79
19.05.2023 12:40В плк уже давно есть модульные системы. Ремонтопригодность и расширяемость выше, отказоустойчивость ниже. То что работает в "чистом цехе" отвалится в автомобиле или агрессивной среде с непредсказуемыми последствиями. Минимум итераций и соединений- максимум надёжности. В промэлектронике был момент когда вся бригада была на вызовах месяцами пока не занялись пропайкой "пистонов" межслойных соединений контроллеров из Пензы. Акустическое давление рядом с работающим станком - вибрации даже через пол передавались. Стоять рядом с станком и ждать когда залипнет выход - тащить в лабу - пропаивать? Одного спирта на отмывку лака литры ушли ), в брак процентов 30 попало. Эх времена были)
eteh
19.05.2023 12:40+5Ну вот лично мне за 10 лет ковыряния ПЛК не нравятся урезанные IDE кучи производителей, гды ты завязан только на реализованные ими блоки. Пример из классики — типа декларативные ЯП и императивные… Мне зачастую гораздо проще написать (или применить готовые) свои обработчики RS-485 для разных типов датчиков, 4...20 входов/выходов, чем юзать не пойми что "любезно" подсунутое мне производителем. Финансово тут есть вопросы — есть компании интеграторы — там тоже не во всех адекватные труду зарплаты, а есть компании пользователи — там вообще треш по уровню зп… Потому потихоньку под менторством родственника синьора учу джаву) Реально удобство IDE для джавы и IDE для пром программирования это небо и земля.
mishkin79
19.05.2023 12:40+1В одной игре за 2 года патчами "улучшающими производительность" превратить мой комп в тыкву ради удобства группы "разработчиков" - это одно дело. Перенести такую практику в мир автоматизации - уже другое. Можно встретить электрика в тёмном и не электрифицированном переулке и стать "героем" - инженером досрочно)
ЗП низкие. Если есть желание зарабатывать больше - лучше сменить профиль. Но сама профессия хорошая и самое главное нужная, хоть и не заметная).
eteh
19.05.2023 12:40+2Вы меня не так поняли — я не предлагаю заменить МЭК тотально на что-то другое — каждое уместно в своем направлении. ЗП в некоторых направлениях и АСУ могут быть достойными, но это очень узкие направления.
Crocodile77
19.05.2023 12:40+6Не всё так просто на первый взгляд, как считает автор. Круто конечно на каком-нибудь Питоне писать проги для контроллеров, но нет, не получится натянуть сову на глобус. Слишком разные требования к системам из IT и из промышленности в плане ошибок. Одно дело подзавис сервер или на сайте окошко не там всплыло, другое дело - встала автоматическая линия, или на химзаводе приходится сливать колонну из-за остановки системы. Тут ущерб может отличаться не просто в разы - а на порядки.
Поэтому стандарт IEC 61131 - это не про то чтобы технологи и электрики программировали, а про то чтобы программа была проста настолько - насколько возможно, для избежания ошибок. И для удобства отладки. Поэтому надо программировать готовыми блоками из библиотек и не придумывать велосипеды.
И поэтому, если говорить про системы ПАЗ (противоаварийная защита) - там правила ещё жёстче. Можешь использовать только определённые блоки и всё. А чтобы не взорвалось ничего из-за неправильной программы. Цена ошибки слишком высока - поэтому вот так.
glazko Автор
19.05.2023 12:40+4Даже в общепроме огромное количество не таких уж и опасных техпроцессов, не говоря уже про BMS. Но даже если говорить о крайностях (нефтехим, ПАЗ), то такие программы перед ПНР тщательно проверяются по этому не вижу проблемы провести точно такие же FAT испытания для Python-программы
Crocodile77
19.05.2023 12:40FAT испытания затянуться могут если программа нестандартными блоками написана. А сроки то горят. И здесь как бы бету версию выкатить заказчику, как это делается сплошь и рядом в IT, не получится. Себе дороже будет если на производстве что-то пойдёт не так. Простой линии на автомобильном заводе стоит несколько лямов ))) Тут не забалуешь ))
MiraclePtr
19.05.2023 12:40+3Поэтому стандарт IEC 61131 - это не про то чтобы технологи и электрики программировали, а про то чтобы программа была проста настолько - насколько возможно, для избежания ошибок.
Но АСУТП - это не только нижний уровень с ПЛК, это и верхний уровень тоже. Там где SCADA (в которой для мнемосхем и отчётов нередко может быть заскриптована довольно сложная логика), плагины для OPC-серверов (для опроса всяких нестандартных железок), всевозможные программы-адаптеры (выгрузка данных в смежные системы)... Все это пишется не на МЭКовских языках, а на обычных ЯП общего назначения, но из-за низкого уровня инженерной культуры (в плане software engineering) в отрасли код там нередко такой, что без слез не взглянешь, а работает он только благодаря молитвам и невероятному везению.
vkni
19.05.2023 12:40+7Круто конечно на каком-нибудь Питоне писать проги для контроллеров, но нет, не получится натянуть сову на глобус.
Зачем Питон? Есть масса других более приспособленных для этого языков, в конце-концов, можно и отраслевой сделать, если так нужно.
И поэтому, если говорить про системы ПАЗ (противоаварийная защита) - там правила ещё жёстче. Можешь использовать только определённые блоки и всё. А чтобы не взорвалось ничего из-за неправильной программы. Цена ошибки слишком высока - поэтому вот так.
Вы не поверите, но Питон работает именно так — программа пишется из блоков. А то, что вы хотите — это верификация, системы типов и т.д. Но вы от этого ещё дальше, чем от Питона.
HabrMKC
19.05.2023 12:40+6Почему если цена ошибки чудовищна, так мало платят? вернее почему ктото вообще соглашается программировать такие линии?
ky0
19.05.2023 12:40+3Что мочь потом приходить в комментарии к статьям вроде этой и хлестать всех рукавами белого пальта :)
vassabi
19.05.2023 12:40+1возможно - потому что "цена ошибки" платится не теми, кто писал к ним код ?
Nansch
19.05.2023 12:40+3На самом деле выход из этого ада автоматизации есть. Даже с имеющимися возможностями программирования ПЛК от лидеров индустрии типа сименса, роквела и какого-нибудь омрона, можно продумывать архитектуру системы, внедрять модульный подход, разрабатывать программные интерфейсы к модулям, придерживаться функционального стиля даже в ладдере, уменьшать количество внутренних состояний, резать зависимости. По началу будет медленно, но в дальнейшем, когда на одном ПЛК допилите программный модуль до приличного состояния, а потом принесёте его в другой ПЛК и просто замените без правки кода, то почувствуете мощь такого подхода. Из-за того, что ПЛК позволяет программисту творить любую дичь, следование принятому стилю в коде является главным правилом. Основательно за этот подход топит в том числе автопром, типа Renault-Nissan, Siemens Automotive, CNOMO и т.п.
Radisto
19.05.2023 12:40+6Там, где специалистов в принципе много не требуется, зарплаты низкие и возможности работать на заграничного заказчика практически нет, то же самое в любой отрасли. Либо никакого сообщества, либо довольно токсичные междусобойчики. В моей специальности, к примеру, в точности так.
gmist
19.05.2023 12:40+3Ну, как говорится, не все так однозначно. Вот взять "огромное количество сред разработки" - не такое и огромное, если сравнивать с количеством web-фрейворков на JS, где каждый день выходит новый, с очередной революционной (той или иной степени) идеей. Да и урезанность ЯП в этой сфере - вещь относительная, ведь задачи на нижнем уровне, как правило, весьма однотипные, а если данные ушли наверх, то там уже делай с ними что хочешь и с помощью чего хочешь (порой даже за гранью добра - однажды видел развесистую статистическую систему, написанную на Visual Basic, которую тащили на своем горбу с середины 90-х). Но зачастую этого и не требуется, т.к. большинство задач вполне решаются в рамках выбранной экосистемы того или иного производителя, собрав простыню из FBD на десяток-другой экранов. Отсутствие разделения труда - тоже спорно. К примеру, еще лет 20 назад, когда я занимался АСУ ТП, у нас была четкая дифференциация штанов: монтажники, электрики, электронщики, наладчики, КИПиА, проектировщики, и отдельной кастой шел отдел инженеров и прочих программистов. Возможно, что в небольших компаниях еще можно встретить "фулл-стек" мастеров от АСУТП - от монтажных работ по пояс в нечистотах, до разработки драйверов какого-нибудь эзотерического оборудования (впрочем, и тут, скорее всего, придется работать в поле, т.к. железо будет в работе и никто не даст его для экспериментов в стерильную лабораторию). Но сомневаюсь, что в этом случае будет высокая производительность труда. Впрочем, возможно, что мне просто повезло с компанией (а точнее с региональным подразделением, где у нас уже тогда была и удаленка, и относительно свободный график, и машина с водителем, и бильярдная со штангой, и даже чайник с безлимитными печенюшками и 3-х литровой банкой заварки - все те "блага", которые лишь потом стали "стандартом" отрасли). Тем не менее, проблема разделения и условий труда решаема в пределах той или иной организации, было бы желание. Тоже самое касается качества кода и его сопровождения. 20 лет назад уже использовалась CVS везде, где можно было экспортировать в текстовый вид, а где нельзя - просто бинарными файлами, что при наличии документации и качественного комментирования коммитов давало хоть какое-то версионирование и уверенность в завтрашнем дне. Особенную радость в то время вызвало появление Tortoise CVS и затем SVN - даже проектантов удалось перетащить c VSS. Да и связь между удаленными офисами кое-как наладили, пусть и с ограничениями того времени - модемы на отправку, спутник на прием, ну и более-менее быстрый (по меркам того времени) Интернет как бонус. Поэтому
чисто там, где не мусоряткультура разработки есть там, где ей уделяют должное внимание. Ну а что касается открытых решений, то тут не поспоришь - как вспомню написание OPC гейтвейта, без возможности купить стандарт и имея под рукой только тулзу для тестирования интерфейсов OPC, так аж нехорошо становится. Но нужно ли это производителям ? Вот это вопрос.MiraclePtr
19.05.2023 12:40Ну а что касается открытых решений, то тут не поспоришь - как вспомню написание OPC гейтвейта
С этим в последние годы получше стало, кстати, начиная с OPC UA исходники референсных реализаций выкладываются в открытом виде на гитхабе. Да, под GPL-лицензией (коли хочешь другую - плати), но хотя бы можно подглядеть как сделано если что-то не ясно.
Yorique
19.05.2023 12:40С АСУТП умеренно все в порядке в России, а вот автор, кажется, чего-то не смог и озвучил истерику.
Особенно забавляет мнение о необходимости IOT(ага, с запретом не только на интернет, а даже доступа в смежный сегмент сети ради диагностики, выбиваемый месяцами с привлечением СБ) в промышленности, да еще и на базе Linux(sic!), ну да, нас сейчас заставляют это делать - без проблем, но как же взвоют слесари КИП эксплуатации потом, когда все это надо будет обслуживать. Сложно даже представить.
PS. асушники и не являются программистами, мы инженеры КИПиА с расширенным функционалом, не более.
Yorique
19.05.2023 12:40-7Кстати, минусы отлично демонстрируют доброжелательность коммунити "настоящих программистов" из комментария выше "какие зарплаты такое и коммунити", которыми наполнен хабр, более чем наглядно :) Довольно изящно получилось
MiraclePtr
19.05.2023 12:40+19Я думаю, минусы вам ставят потому что вы с первой же строчки вместо ответа по существу перешли на личности и применили демагогический прием. Это к вопросу об озлоблености вашего коммунити :) В других коммунити так не принято, отсюда и минусы.
Yorique
19.05.2023 12:40-6Возможно, но так-то мне казалось, что хабр - не жалобная книга, и тем более не средство оскорбления представителей целой отрасли, что совсем не помешало автору накропать эмоциональный опус, причем короче обычного новостного поста, и набирать плюсы от "коммунити". Грустно это.
Я в целом считаю, что позиция я Д'Артаньян, а вы все того этого самого, не должна приветствоваться нигде, но погляди ж ты, не так.
ky0
19.05.2023 12:40+14Как известно откуда-то из седых веков, достойным ответом на музыкальное произведение может быть только другое музыкальное произведение. Напишете релевантный ответ без "озвучивания истерик", как у ТСа и переходов на личности, как в ваших комментариях — и наверняка получите плюсов побольше, чем выдали этой статье.
Yorique
19.05.2023 12:40-10С одной стороны, а зачем плюсы? Предпочитаю читать, что видно по активности за 10 лет. Просто грустно видеть оскорбление профессии. А с другой стороны я также слышал, что не обязательно уметь готовить яичницу, чтобы оценить вкус. Вроде бы еще с лурка старого аналогия. Ну это в контексте аргументации класса "сперва добейся" как бы музыкального произведения.
Ну и в целом я написал ниже. Чистое АСУТП это до усрачки легко и просто, поэтому обязано оплачиваться меньше. Все справедливо. Кратко и точка(с)
:)
Newbilius
19.05.2023 12:40+10"Хабр - не жалобная книга" - это про то, что не надо сюда жаловаться о каком-то одном частном событии. А обсуждать проблемы системные - штука полезная, и вот этот пост именно про это.
glazko Автор
19.05.2023 12:40+1За годы МЭК парадигмы, выросло целое поколение инженеров, которым пришлось освоить программирования, но унизительные зарплаты, статус неполноценности языков и сред разработки озлобило их, некоторые буквально ненавидят ИТ-шников.
Я прекрасно понимаю и разделяю эту боль
vkni
19.05.2023 12:40+2из комментария выше "какие зарплаты такое и коммунити"
Работать забесплатно на дядю могут позволить себе только достаточно специфические люди. Они разные, но отличаются от тех, кто вынужден сидеть в том же банке (см. коммент выше), т.к. «семье нужны деньги». Поэтому хотите вы или нет, но да, контингент у вас должен быть специфическим.
Yorique
19.05.2023 12:40+4Не, там немного не так, забесплатно там не работают, там чудовищный скачок скорее, которого нет в обычном программировании. Вкратце джун асутп = меньше дворника, сеньор асутп = топ-миддл классики, да до сеньора классического варианта дорасти нет, но того и не требуется в отрасли, просто потому что тупо нет смысла - все настолько чудовищно примитивно, что сеньор рехнется от банальности задач.
И это главный аргумент, который автор не озвучил, асутп - это невероятно, до невозможности, ультимативно легко, поэтому и должно вознаграждаться меньше, вроде все справедливо.
MiraclePtr
19.05.2023 12:40+8все настолько чудовищно примитивно, что сеньор рехнется от банальности задач
асутп - это невероятно, до невозможности, ультимативно легко
С такими высказываниями нужно аккуратнее, на некоторых асутпшных ресурсах при озвучивании подобного даже в очень мягкой форме в ответ может произойти с десяток взрывов стульев, типа "ты чё, пёс, у меня тут прокатный стан, это тебе не джейсоны перекладывать" и "да ты сам даже пид-регулятор рассчитать не сможешь, щегол, куда тебе до нас" :)
vkni
19.05.2023 12:40+1просто потому что тупо нет смысла - все настолько чудовищно примитивно, что сеньор рехнется от банальности задач.
Значит там, скорее всего, не нужен человек. Но тут такая же последовательность, как с программистами «на Питоне»: дешёвый труд, много людей => нет необходимости автоматизировать (в Питоне это выглядит как ручное 100% покрытие кода тестами — в Хаскеле/F#/Kotlin/Swift/OCaml/SML для этого есть компилятор и типизация).
Вот народ рассказывает, что там всё должно быть очень просто, потому что должно быть сильно проверено и т.д. — из «большого программирования» есть такая мудрость, что эти проблемы часто решаются введением статической типизации, правильных абстракций и т.д.
Вполне возможно, что есть и сложные задачи, просто из-за того, что все привыкли решать простые, эти сложные задачи не видят.
vkni
19.05.2023 12:40+3асушники и не являются программистами, мы инженеры КИПиА с расширенным функционалом, не более.
Программирование – это просто умение читать и писать на формальных языках. Если умеете, то программист.
Yorique
19.05.2023 12:40+2Ну нет же, таким определением и музыкант - программист, причем даже куда больший чем мы - ведь у него алфавит куда короче.
Имхо программист - человек основная функция которого - генерация безошибочного текста, который может быть исполнен тем или иным вычислительным устройством и все.
У нас не так, да ты тоже генерируешь текст, но программа -вторична, основная задача - сделать так, чтобы оборудование работало без нареканий, и если не удается сделать это текстом, берешь провода и слегка меняешь конфигурацию исполнительных механизмов.
Например рядовая задача - в зависимости от контекста выбрать импульсный или непрерывный метод управления запорной арматурой на конкретном объекте, тут нужна отвертка, цэшка и клеммы с проводами.
Поэтому - инженер КИПиА сначала, а программист уже потом. В этом ключевая разница. Именно это я имел в виду.
Autonomnoe
19.05.2023 12:40+2Все именно так. Там где можно сделать релейно, лучше релейно, где можно сократить программу, лучше сократить. Программа должна быть максимально простой и самое главное должна работать предсказуемо. Если АСУТПшную задачу делает программист, от этого только больше проблем становится, он старается сделать свою работу, предусмотреть разные события и как они будут развиваться, а этого чаще всего делать не стоит. К решению инженерных решений нужно подходить с инженерным мышлением а не программиста.
petuhoff
19.05.2023 12:40+1Кстати да у нас был вариант самонастраиващийся системы которая опрашивала в сети контроллеры управления определяля что кому отправлять и формировала списки обмена и все это автоматически. Но на объекте всю красоту отключили и прешели на ручное формирования списков обмена сигналам в видет таблиц для каждого контроллера. Душниля инженеры удушили душевные порывы программиста.
vkni
19.05.2023 12:40+3Поэтому - инженер КИПиА сначала, а программист уже потом.
Ну, то есть, обычный сплав двух профессий. Владеть желательно обеими на достойном уровне.
victor_1212
19.05.2023 12:40+2> Программирование – это просто умение читать и писать на формальных языках. Если умеете, то программист.
если читать + писать, но язык необязательно формальный - тогда просто писатель или поэт :)
SpiderEkb
19.05.2023 12:40+2Позволю себе не согласиться. Определение очень неполное.
Хорошее FSD (ТЗ) - это не псевдокод, но описание потоков данных и правил, воздействующих на данные на разных этапах.
Соответственно, программист (хотя мне больше нравится - разработчик) ни в коем случае не переводчик с псевдокода на формальный язык, но, скорее, сценарист, который по заданному сюжету пишет подробный сценарий - кто где стоял, куда пошел, как посмотрел, что сказал и т.д.
Вообще, разработка это прежде всего умение разделить "большое и невозможное" на последовательность "малых и реализуемых".
Задача разработчика заключается в том, что описанные в FSD потоки данных и правила реализовать на формальном языке так, чтобы программа работала максимально эффективно. А это не только синтаксис формального языка, но и алгоритмы, структуры данных, умелое использование специфики платформы, на которой будет работать программа, там, где это нужно, в какой-то степени понимание общей архитектуры и окружений в котором все это будет работать.
И опыт разработчика не в том, чтобы знать "как надо" (этому как раз учат на курсах, в вузе и т.п.), но знать "как не надо в данном конкретном случае" (т.е. из нескольких возможных вариантов, сразу откинуть те, которые не годятся в данных конкретных условиях).
Все это, конечно, всего лишь мое частное мнение, основанное на 30+ лет опыта в "коммерческой разработке". На "абсолютную истину в последней инстанции" или "носителя сакральных знаний" ни в коей степени не претендую.
victor_1212
19.05.2023 12:40> скорее, сценарист, который по заданному сюжету пишет подробный сценарий - кто где стоял, куда пошел, как посмотрел, что сказал и т.д.
хорошее сравнение, однако наличие грамотного ТЗ (заданный сюжет) это сравнительно простой случай, если говорить про embedded sw чем сложнее система, тем большую роль играет знание предметной области, можно сказать этого никогда не бывает слишком много, кроме того для разработчика embedded sw по нынешним временам желательно иметь два образования - типа ms electrical engineering + ms computer science, распространено например в us, не удивлюсь если со временем вообще будет отдельная специальность типа ms embedded systems,
> Вообще, разработка это прежде всего умение разделить "большое и невозможное" на последовательность "малых и реализуемых".
тоже верно, хотя вероятно справедливо для любой инженерной работы
SpiderEkb
19.05.2023 12:40+2хорошее сравнение, однако наличие грамотного ТЗ (заданный сюжет) это сравнительно простой случай, если говорить про embedded sw чем сложнее система, тем большую роль играет знание предметной области, можно сказать этого никогда не бывает слишком много
Я с вами полностью согласен. Знание предметной области требуется много где.
Вот сейчас в банке работаю. "Разработка центральных банковских систем" - это фактически ключевая бизнес-логика, которая крутится на серверах в рамках АБС (Автоматизированной Банковской Системы). И тоже приходится вникать в предметную область, без этого очень сложно писать качественный и эффективный код. Тут требования к эффективности весьма высокие т.к. система относится во-первых к mission critical (цена простоя невыносимо высока как деньгах, так и в рисках - время недоступности нормируется минутами, дальше санкции и штрафы от регулятора), во-вторых - это высоконагруженная система. Но есть своя специфика. Например, на сервере одновременно крутится тысячи процессов. И ваша задача одна из них. Т.е. вы не можете использовать все ресурсы сервера, но постоянно должны следить за тем, чтобы уложиться в отведенное вам "окно" как по времени выполнения, так и по потребляемым ресурсам.
И здесь очень много команд, каждая из которых занимается своим направлением. Есть команды системы расчетов, модуля пластиковых карт, тарифного модуля, лимитного модуля и т.д. и т.п. Я вот по большей части занимаюсь комплаенсом и клиентскими данными. И неизбежно приходится вникать в то, как оно устроено в целом. Иначе, увы, никак. Просто тупо писать код, не понимая что он делает - ну такое себе... Нет, начинающие разработчики так и работают на первых порах, но им никто и не даст сложных и ответственных задач. Поначалу занимаются рутинными, а дальше как себя покажет.Плюс еще есть "непроектные", "технические" задачи. Но это уже "дело добровольное" - за это берется тот, кому это интересно и кто чувствует в себе силы этим заниматься (формально у нас допускается до 20% времени отводить на технические задачи, но, увы, не всегда получается...). Главным образом это касается разработки различного рода "низкоуровневых сервисов", которые потом будут использоваться много где. Тут уже надо вникать в особенности работы платформы (а у нас она ну очень специфическая) и ее потрохов - системные API и т.п.
А под грамотным ТЗ понимаю именно описания потоков данных и условий - что на входе, что на выходе. Наличие хорошего ТЗ очень повышает эффективность работы разработчика во-первых, а, во-вторых, это еще и документация по задаче. Через год (условно) к вам придут и скажут - "у нас тут бизнес-процесс поменялся (или регулятор новые требования ввел или законодательство поменялось) - нужно внести изменения". Без документации очень сложно бывает понять где именно что именно нужно поменять. Поэтому рабочий процесс уже выстроен примерно так - BRD (требования заказчика) -> ОТАР (архитектурное решение) -> FSD (ТЗ) -> разработка -> компонентное тестирование (на соответствие FSD) -> бизнес-тестирование (на соответствие BRD) -> нагрузочное, интеграционное тестирование (эффективность, интеграция в существующую систему, на копии промсреды) -> внедрение.
В целом не могу сказать что это проще или сложнее АСУТП. И там и там есть свои особенности.
victor_1212
19.05.2023 12:40+1интересно, спасибо за детали, подобными системами не занимался, как собственно и АСУТП, только сети и real time, embedded, последние 30+ лет в us
ps
представление о современной embedded system дает например высокопроизводительный router, это порядка сотни процессоров под управлением своих os, которые управляют несколькими сотнями IC, через которые идет основной поток пакетов из портов, при этом постоянно обмениваются сообщениями, служебными между собой, а также с другими router в сети (сетевые протоколы)
SpiderEkb
19.05.2023 12:40+1Ну я тоже не настоящий сварщик :-)
В АСУТП занимался "верхним уровнем". Сначала это был диспетчерский софт, который работает на компе и занимается "визуализацией" сообщений от устройств. Если просто, то приходит нечто типа такого: 5-е устройство на 3-м УСО 10-го шлюза, код 1. Надо посмотреть что это за устройство, где оно физически расположено и что такое "код 1" в его контексте. Выясняется это РКД (реле контроля дверей) пассажирского лифта в третьем подъезде по адресу Коммунистический тупик, до 15. Соответственно, выводим аварийное сообщение:
"Коммунистический тупик, д.15, 3-й подъезд, пассажирский лифт - Двери шахты открыты" и подсвечиваем объект на карте.
Ну там логирование еще всякое, возможность послать команды какие-то и т.д. и т.п.
Потом, по мере развития системы занимался т.н. "микроядром". Такой модуль, к которому подключаются с одной стороны IP-шлюзы (по UDP), с другой - интерфейсные клиенты (по TCP). Ядро - это и маршрутизатор (смотрит от кого что пришло и кому это надо переслать) и контроль состояния IP-шлюзов (если с ним нет обмена - ну хоть пингануть его, если не отвечает - сформировать аварийное сообщение что что-то не так) ну и там много всяких заморочек было.
Естественно, что и проектировать все самим приходилось - и протоколы обмена и классификацию устройств, архитектуру микроядра и системы на его основе... В этом тоже активно участвовал.
Ну а банк... Тут, конечно, БД. И платформа IBM i (коммерческие middleware сервера, высоконадежные, высокопроизводительные). Очень специфическая, ни на что не похожая (построена по принципу "все есть объект", своя файловая система, интегрированная в систему БД DB2, свои языки - основной - RPG - язык для коммерческих расчетов, аналог кобола, но развивается и нормальный такой процедурный язык типа Паскаля. Но есть и С/С++, есть CL - системный язык команд, на нем тоже можно небольшие программы писать.
Если в двух словах... Обработка больших объемов данных. Ну вот писал сервис комплаенс-проверок для системы контроля платежей. По оценкам в сутки проводится порядка 100млн бизнес-операций. Каждый платеж в система расчетов проходит через сервис проверок. Т.е. надо быстро его проверить и вынести решение - "все ок - пропускаем", или "что-то подозрительное - отправляем на ручной контроль с указанием что именно не понравилось".
Плотность вызовов и требования к быстродействию можете себе представить.
А еще требования к использованию ресурсов. На сервере одновременно крутится порядка 10тыс процессов (в сутки изменяется порядка 1.5Тб данных). И всем нужна память, всем нужен процессор. Да, это не домашний комп. Это IBM Power E980 120 процессорных ядер (там несколько процессоров на одной шине) по 8 потоков на ядро. 12Тб RAM, 400Тб на дисковых SSD массивах. Но все равно нагрузка велика (сопровождение говорило, что до 90% мощности сервера в пике доходит).
Или вот задачка - росфин регулярно присылает списки всяких злодеев, которым нельзя деньги переводить. Список - это XML мегабайт на 50. Его нужно разобрать и разложить по БД. А потом провести сверку всех клиентов активных (порядка 45млн) со всеми субъектами списка (несколько сотен тысяч) по ряду параметров (ФИО+ДР, ДУЛ, ИНН, адрес...). Если найдены совпадения, они фиксируются в т.н. стоплистах.
Делать "в лоб" - это на сутки работа. А нужно чтобы за 3-4 часа укладывалось. Значит, распараллеливаем - запускаем десяток фоновых заданий-обработчиков, организуем конвейер, головное задание выкладывает на него результат выборки, обработчики подхватывают и обрабатывают. И при этом следим за загрузкой машины (это всегда и везде). Чтобы не было лишних операций, чтобы не было лишних обращений к БД (что можно кешировать - кешируем), чтобы все выборки строго по индексам и т.д. и т.п. Короче там есть над чем голову поломать...
Часто прилетает от сопровождения "дефект производительности"
"Коллеги, сервис *** за последние 5 недель увеличил потребление процессорных ресурсов в 3 раза!!!
Он уже является 2-м по величине сервисом после *****.
В качестве альтернативы мы рассматриваем перенос запуска сервиса на резервный сервер, но там есть лаг по отставанию до 10 мин.
Заказчикам сервиса это может не понравиться :("С первого взгляда задачка казалась несложной. Ну неделя. Вместе с аналитикой.
Но... Хочешь рассмешить бога - поведай ему о своих планах.
Первый подход к снаряду не дал ожидаемого результата.
Сначала выявились тонкости в алгоритме.
Потом первое нагрузочное тестирование не показало желаемого улучшения. Уперлись в некоторые ограничения, накладываемые форматом БД где хранятся нужные данные. Ломали голову как обойти. Придумали. Реализовали. Стало лучше.
Потом еще увидели что при определенных вызовах есть оверкод в части лишних проверок того, что уже проверялось при прошлых вызовах. Добавили кеширование всего чего только можно.Но сделали
"Коллеги, доброе утро!
Спасибо!
Уже утром видим очень хороший результат!!!
Доработка сокращает потребление процессорных ресурсов почти в 10 раз!"Есть технические задачки. Те же конвейеры для параллельной обработки у нас сейчас реализованы на пайпах. Все неплохо, но пап не контролируемый - мы не знаем сколько в нем сообщений в любой момент времени. Это накладывает ограничения в плане контроля за обработчиками - справляются, не справляются... Может нужно один-два тормознуть (оставшиеся вывезут) чтобы нагрузку на машину снизить. Или наоборот запустить еще парочку...
На нашей платформе есть такой тип объекта - User Queue. Для конвейера самое оно. Быстрое, эффективное по ресурсам и при этом полностью контролируемое - в любой момент можно узнать сколько там сообщений (а это значит оценивать скорости заполнения очереди головным задание и разбора обработчиками), сколько памяти аллоцировано и т.д. и т.п.
Одна беда - вся работа с USRQ исключительно низкоуровневая, через MI (Machine Instructions) с кучей всяких "непонятных" операций типа "сначала получить системный указатель на объект, потом вызываем deqwait - чтение с таймаутом, елси в очереди ничего нет, оно выкинет системное исключение, его перехватываем, смотрим код, видимо это просто таймаут истек - все норм, не ошибка".
А для нормальной работы нужен качествtнный API - подключаемся к очереди по имени, подучаем handle, потмо с ним уже работаем (как с файлами) - послать, получить. Если там что не так - никаких исключений, возвращается т.н. "структурированная ошибка" (так на этой платформе принято - код ошибки + параметры, полный текст по коду можно получить специальным API - оно все хранится в т.н. message file).
Разрабатываем API. Потом на него навешиваем CL команды (да, это такой язык который можно расширять своими командами), потом еще делаем SQL интерфейсы для работы с очередью...
Короче говоря, банк - это сильно не только счета-проводки, но и очень много чего еще :-) И это "что-то еще" может быть весьма интересным с точки зрения разработки.
victor_1212
19.05.2023 12:40+1главное, судя по всему, Вам нравится, желаю успеха
SpiderEkb
19.05.2023 12:40Да, нравится.
В АСУТП нравились интересные задачи, требующие вдумчивого подхода и нестандартных решений. Держался там до последнего, не хотел уходить. Но пришлось. Близкого по теме ничего не подвернулось. Банки тогда в принципе не рассматривал т.к. не видел для себя интереса во всех этих "дебет-кредит, счета-проводки".
Позвали неожиданно - сами написали, пригласили на собеседование. Сходил, поговорил и понял вдруг что хочу тут работать.
И вот уже 6 лет и не жалею ничуть. Тот тоже есть интересные нестандартные вещи где нужно "мозг включать". Плюс платформа IBM i увлекла. Своей цельностью, продуманностью, огромным количеством предоставляемых возможностей.
Если на прошлой работе было просто удовольствие от самой работы, то тут и работа нравится и еще за это платят неплохо.
eteh
19.05.2023 12:40Подождите, АСУ это многогранная вещь — там может быть как и бэкенд написанный не на МЭК, так и просто система с HMI контроля и управления, в лучшем случае со SCADA, так и вообще железный ПАЗ на релюшках) Все эти уровни абстракций часть АСУ. И требования к персоналу по разработке и обслуживанию у них разные.
Sergo_Sergo
19.05.2023 12:40+4"Компании смогут изменить экономическую модель, что позволит платить Инженерам и Программистам АСУ ТП достойную заработную плату. "
Зачем платить? Зачем менять? Автор думает если АСУ - шные "рабы" будут привязаны к IIOT и кодить не на "61131", а на "условном Питоне" или любом другом "современном языке", то наступит рай.
У нас нет производства как такового - основного фактора приложения АСУ ТП, нет своей электроники с элементной базой, чтобы делать своё железо, те же контроллеры и промышленные ПК. Сам автор похоже потёрся немного с АСУ и ушёл/перешёл на javascript , может увидев ПЛК пару раз... И смотрит на эту сферу глазами условного "скадиста". Потому нужно начать с себя: Node Red c "малиной" ему в помощь. Чем не стартовая платформа для нового концепта в АСУ ТП?.. Сразу тебе и железо и софт со средой разработки...
Ну а пока и в рамках "61131" мало чего на 100% своего есть...
glazko Автор
19.05.2023 12:40+1Зачем платить? Зачем менять? Автор думает если АСУ - шные "рабы" будут привязаны к IIOT и кодить не на "61131", а на "условном Питоне" или любом другом "современном языке", то наступит рай.
Насчет рая не знаю, но я искренне убежден, что это сильно пофиксит зарплаты в АСУ ТП. Потому что если в спеки начнут закладываться IIOT - в сфере начнут задерживаться ИТ-шники и со временем это изменит сам подход к реализации проектов и взаимодействию специалистов в лучшую сторону
eteh
19.05.2023 12:40Ну извините, но по моему опыту (пара крупных проектов в нефтехиме) в асу тп есть и обычные программисты на классических языках и вообще очень сильное разделение труда. При высокой стоимости проекта и ответственности в фирме интеграторе у спецов зп +- одинаковые, но! таких проектов единицы на нашу страну(если берем РФ), а это уже другая болячка экономическая… Не суть важно на каком железе будет крутиться ОСРВ, самая суть АСУ ТП и каким яп программироваться, важно чтобы это было экономически обоснованно. Когда законы не предполагают ответственности за выбор системы АСУ — типа вы что нибудь предложите, такой ад и будет по финансам в отрасли.
thevlad
19.05.2023 12:40+4Думаю, это наиболее приближенный к реальности ответ, если рынок существует в таком плачевном состоянии, то это вопрос спроса. А спрос такой какой есть, потому что промышленность, главный заказчик этих разработок, в *опе. А остальное по большей части может решатся людьми, без привлечения специалистов, теми же технологами. Поэтому если спрос на специалистов и есть, то он очень нишевой.
Поэтому и решатся "проблемы АСУТП", могут только именно с этого конца(развития промышленности), а не какими-то мифическими "серебряными пулями" и и проектами.
VelocidadAbsurda
19.05.2023 12:40+3А он (IIOT) там реально (кроме «привлечь ИТ-шников») так нужен? Когда уходил из автоматизации (простенькой, HVAC, ушёл из-за скуки, примитивная логика, которую нужно проверять по 100500 раз) 20 лет назад - в ходу были контроллеры, отделённые от полноценного HMI, надёжные, как танк (приезжаешь на обслуживание через пол года, разблокируешь панель, а там то подменю, в котором оставил в прошлый приезд). Сейчас слушаю друга, бьющегося с «модным» железом, где и логика и «красота» на одном ядре и «можно как человек писать сценарии на JS, а не вот эти ваши дедовские диаграмки рисовать» - те же скучные техпроцессы, но уже со всякими «нужно перезагрузить/подождать» и (самое отвратное) заведомым принятием такого качества за норму.
LeetcodeM0nkey
19.05.2023 12:40+5Цените что имеете. Вырастут зарплаты - набегут смузихлёбы со своими аджайлами и "софтскилами" как мерилом профессионализма.
glazko Автор
19.05.2023 12:40+6Не вижу в этом ничего плохого, работал с такими ребятами - это всего безупречная реализация строго как прописал технолог в FDS. В отличии от "универсалов" которые всегда лучше технолога знают "как тут надо"
LeetcodeM0nkey
19.05.2023 12:40+1Скорее всего вы работали не с такими ребятами. Смузихлёбы водятся только там где много денег. Смузихлёб и "безупречная реализация" это ортогональные понятия. А неумение (и нежелание) делать всё как надо с лихвой компенсируется природным талантом красиво срать в уши почему всё сделано типа как надо или почему они ни в чём не виноваты.
MiraclePtr
19.05.2023 12:40+9Вы для начала уточните, что именно вы понимаете под словом "смузихлеб", а то очень похоже что вы выдумали соломенное чучело и активно с ним боретесь. В интернетах на айти-ресурсах (типа известного итальянского домена) этим словом обычно называют или CRUD'ошлепов на модных фреймворках, или приверженцев гибких методологий, или же это слово иногда просто используется программистами получающими меньше 200к в адрес программистов получающих больше 200к из зависти. Что конкретно вы в это слово вкладываете?
У меня кстати, есть история на эту тему.
Про смузи-компании и безупречные реализации
Моя жена - фулл-стэк разработчик, и на заре свой карьеры будучи джуном она попала в одну компанию, тип которых ласково в народе называют "галерами" - то есть компания сама ничего не производит и не продает, а занимается контрактной разработкой - приходит заказчик, просит разработать какой-то софт, сервис или фичу, а те ему любой каприз за деньги, по сути дела сдавая в аренду экспертизу своих программистов.
У них там в проекте были и аджайлы со скрамами по-полной (потому что заказчикам так удобно и нравится), и внимание к софт-скиллам (потому что программисты и тестировщики нередко контактировали напрямую с людьми заказчика), и модные фреймворки (об этом чуть позже). Денег платили тоже очень неплохо (долгое время з/п вообще была привязана к курсу доллара, и каждые пол года можно было запрашивать пересмотр если ситуация на рынке труда изменилась).
И вот, как ни странно, реализацию всего они старались делать может и не безупречно, но очень хорошо - с грамотной и гибкой архитектурой, тщательном покрытии тестами, следовании известным хорошим практикам. Там реально были solution architect'ы и лиды, которые занимались проработкой программного дизайна, очень больно били по рукам когда джуны и мидлы наделали какой-то говнокод или пытались схалявить.
А разгадка простая. Контора умеет считать деньги. Заказчик конторе платит за запиливание новых фич. Когда разработчик запиливает новую фичу - это приносит деньги. Когда разработчик не запиливает новую фичу - это убытки для компании. Когда заказчик недоволен - это риски для компании (он может решить прекратить сотрудничество и копания потеряет денежного клиента). Поэтому старались делать сразу очень хорошо - сразу строить грамотную и гибкую архитектуру чтобы можно было добавлять новые фичи без необходимости перепахивания всего каждый раз заново (заказчик за такое платить не будет, а зарплату программисту платить надо), покрывать все тестам чтобы избежать регрессий (заказчик будет недоволен, и опять же, за фикс багов заказчик отдельно не доплатит, а программиста надо кормить), и писать код так (best practices, популярные фреймворки, документация) чтобы если вдруг в проект пришел новый разработчик (например, привлекли на время из соседнего проекта когда срочно надо), то он смог быстро и легко разобраться в существующем коде и начать писать новый, и наоборот, при низкой загруженности можно было отправить своего программиста в помощь соседнему проекту.
И это была офигенная школа жизни на тему "как разрабатывать софт правильно", и все те зелёные джуны, пришедшие туда и прошедшие через нее, потом без проблем уходили на мидловые и в последствии синьорские позиции когда меняли работу. Хотя, казалось бы, то ещё смузи...
MiraclePtr
19.05.2023 12:40+3своими аджайлами
Сам по себе аджайл - при адекватном подходе штука очень хорошая, помогает решить ряд проблем и лучше выстроить процессы разработки, только не когда его используют как карго-культ типа "у всех аджайл, у нас тоже должен быть" слепо следуя каждой букве, а когда его применяют с умом и там где он подходит.
Мы в свое время в чисто-АСУТП предприятии, когда ещё даже слова такого как "аджайл" никто не знал, в итоге методом проб и ошибок сами пришли к процессам очень похожим на эти самые гибкие методологии, и это было действительно очень хорошо и для нас, и для заказчиков.
"софтскилами" как мерилом профессионализма.
Софтскиллы как единственное мерило профессионализма обычно никогда и не рассматривают, только как одно из. Важность софтскиллов начинаешь понимать, когда в команду внезапно пробирается мудак, который своим мудачеством медленно отравляет работу всей команды.
LeetcodeM0nkey
19.05.2023 12:40-3Важность софтскиллов начинаешь понимать, когда в команду внезапно пробирается мудак, который своим мудачеством медленно отравляет работу всей команды.
Притом этот мудак и считает себя самым софтскиловым, а любой кто с ним не согласен по любому вопросу - просто токсичный токсик.
MiraclePtr
19.05.2023 12:40+1не, при этом мудак обычно говорит "вы что, тупые, нахрен ваши софт-скиллы, мне работу работать важнее, щас я выдам", а то что из-за этого д'Артаньяна все остальные инженеры нормально свою работу работать не могут, его мало волнует :)
LeetcodeM0nkey
19.05.2023 12:40-3Обычно кто работает и реально выдаёт, тот заслуженное уважение и признание всей команды получает. Бывают люди "с тяжёлым характером", но, по мне, таких скорее редкость встретить чтобы делать из этого системную проблему.
MiraclePtr
19.05.2023 12:40+1"Реально выдает" - это по его личному мнению, а на деле реальность может немного отличаться и выдавать он будет в лучшем случае весьма средненько. А так да, тут проблема часто в "тяжёлом характере", в терминальных формах встречается это не то чтобы прям часто, но если уж встретится, то демотивировать или даже развалить коллектив очень даже может.
LeetcodeM0nkey
19.05.2023 12:40-1Ну то есть описали типичного такого "софтскиллового" смузихлёба. Реально умеет мало, но гонору на миллион. А когда кто-то пытается прямо дать ему понять что он просто мудак, то ессно этот храбрец "токсичный токсик" который типа всех демотивирует. Эдакий офисно-айтишный woke'изм: "это не я мудак, это вы расисты".
MiraclePtr
19.05.2023 12:40+1Не, не так - у таких мудаков "софтскиллс" - это вообще слово ругательное, себе они его никогда не припишут, и демонстрировать эти самые софт-скиллы (умение понятно и спокойно объяснять, стараться избегать конфликтов, уважение к окружающим, деловой этикет) они не будут (разве что в самом начале постараются, чтобы пролезть на позицию и пройти испытательный срок). То есть там ровно наоборот может быть чуть ли не прямым текстом "да, я токсик, вот такой какой есть, и чё вы мне сцуки сделаете, терпите меня, я вам тут работу выдаю".
А те, кого вы описали - их уже сотню лет как называют "пустобрехами" и "карьеристами", и бояться что такие "набегут" в асутп или эмбеддед не стоит - слишком поздно, их там уже встречается достаточно, как и в любых других отраслях.
Newbilius
19.05.2023 12:40+2А ещё бывает так, что подобный человек реально эффективно работает за двоих, а то и за троих... Только вот его подход к работе снижает работоспособность других 10-15 человек, так что проект в итоге от его участия проигрывает.
vassabi
19.05.2023 12:40выделить в отдельную команду, отбирать туда таких же единомышленников ?
MiraclePtr
19.05.2023 12:40С единомышленниками не получится - между собой перегрызутся. Типа как два петуха в одном курятнике.
Thomas_Hanniball
19.05.2023 12:40+2Это не в АСУ ТП зарплаты такие низкие, это просто в остальном IT они большие. Специалисты АСУ ТП получают ровно столько же, сколько и обычные инженеры на производстве.
IT — это же совсем другой мир, где балом правит масштабируемость решений, продажа услуг на международном рынке, многомиллиардные вливания $ от инвесторов, которые хотят создать второй google или как минимум в несколько раз преумножить свой капитал.
Sequoza
19.05.2023 12:40+3Это не в АСУ ТП зарплаты такие низкие, это просто в остальном IT они большие. Специалисты АСУ ТП получают ровно столько же, сколько и обычные инженеры на производстве
$80k в год?
Sequoza
19.05.2023 12:40+1Неужели я вас настолько разозлил, чтобы лезть в карму? Меня лишь смутила фраза, что в IT большие зарплаты. Они обычные. Для тех, кто работает на международном рынке. У моряков и пилотов, например, ситуация аналогичная.
Если брать инженеров в каком-нибудь, в каком-нибудь сименсе, то зп будет примерно равна зп местного прогера.
lehkap
19.05.2023 12:40+9Работал в сфере АСУ ТП после универа с 2013. До конца 2014 года, пока курс рубля был стабилен, у большинства инжинеринговых компаний бизнес-модель была рассчитана на то чтобы победить в тендере, получить скидос у поставщика оборудования, накрутить на официальную цену оборудования процентов 10-15, а проект, разработка SCADA и по для ПЛК, ПНР - это побочные темы, чтобы обеспечить выполнение условий тендера. Обслуживание отдельная тема, но корни таких успешных организаций уходили к какому-нибудь относительно крупному завду. Отсюда зарплаты и отрицательный отбор, тут надо отдать должное, что в этой сфере, с учетом отрицательного отбора, совсем тупые тут надолго не задерживались, но и таланты быстро разбегались, либо переходили в IT, либо в уходили в филиал поставщиков оборудования и там из инженеров в скором времени уходили в продажники(т.к. там денег больше, а в этой сфере хороший инженер может продать почти что угодно). Ну а тем кто остался, с теми бюджетами, которые выделяли на проектирование, развиваться и раскрывать свой потенциал - это сложная задача, т.к. кушать хочется, семья растет, ипотека давит. Плюс сфера очень инертная. Если рынок It на ковид(а это читаю было значимое событие для мира IT) реагировал почти мгновенно(3-6 мес.), то АСУ ТП потребовалось после событий 2014 года 3-4 года, чтобы перестроить свои бизнес-модели и начать продавать проекты, прокраммы для ПЛК, скады, сопровождения, и зарплаты относительно 2014 года наконец-то выросли в 2-3 раза. Но тем не менее они не дотягивают до ИТ, но спецу в АСУ нужно знать болше, ответственность больше, более строгий распорядок(нет гибгих начал дня и печенек с кофе), нет удаленки, зато есть командировки. Так что с тем интеллектом, который требует АСУТП нужно быть реальным фанатом, чтобы оставаться в сфере.
vassabi
19.05.2023 12:40+5спецу в АСУ нужно знать болше, ответственность больше, более строгий распорядок(нет гибгих начал дня и печенек с кофе), нет удаленки, зато есть командировки.
по идее - это должно было поднимать ЗП по сравнению с ИТ, в котором смузи и печеньки.
а получается наоборот.Тут огромное поле для психологов и экономистов - почему переход профессии в специфические требования (командировки, сторгий распорядок) - при том, что вроде бы повышают ценность специалиста, однако не повышают ЗП а понижают.
У меня две гипотезы:
1) происходит вендор-лок специалиста. (или картельный сговор работодетелей) Меньше мобильности по компаниям, меньше вариативности по зп (нет своего FAANG) - меньше сама ЗП в итоге по профессии.
2) происходит отбор специалистов по психологическим критериям. Т.е. большая строгость и распорядок дня (держание в ежовых рукавицах) приводит к тому, что в профессии остаются конформисты, с выученной беспомощностью в сторону условий труда. Которые компенсируют свою беспомощность "там" - в огромную активность "тут" (т.е. в своей профессиональной деятельности - "а зато я классный специалист", "а зато мы там блоху подковывали", "а мы из кизяка и палок дворец сделали" и т.д.). А активные и хотящие в сторону условий труда - сбегают и по профессии не работают.
Возможно, там другие причины, возможно и эти тоже. Но я не думаю, что радикальные меры "всех расстрелять"\"отнять и поделить" или "мышки станьте ежиками" будут работать. Для исправления придется находить какие-то "дела малых шагов" и быть готовым, что даже если мы найдем причину, то лечения может и не быть .... (вспоминается реклама экспедиции на южный полюс в 1913 году)
SpiderEkb
19.05.2023 12:40+2На мой взгляд тут "рыночек решает" (хоть я и не сторонник столь примитивизированного подхода).
Что есть "зарплата" в коммерческой (не бюджетной) сфере? Фактически это какая-то часть от того, что компания заработала на продукте и чем она готова поделиться с тем, кто этот продукт создает (за вычетом всех расходов). Это очень примитивно, на пальцах, но пусть так.
Чем выше прибыль в какой-то области деятельности, тем больше у компании "свободных денег" из которых она готова "отстегнуть" разработчику продукта (тут еще будет играть жадность, "рыночный уровень з/п" и т.п., но в целом так).
Понятно, что АСУТП очень специфическая область - клиенты там - промышленные предприятия, у них в принципе меньше свободных денег, а в расходах на АСУТП значительную часть еще оборудование составляет... Вот и получается, что разработчику остается не так ужи много...
В вебразработке, финтехе денег крутится в принципе больше. И та часть, что идет на оплату ПО там выше. Т.к. какой-нибудь сайт - это просто ПО, а не ПО + куча дорогого железа как в АСУТП.
Когда я работал в этой области, мы все железо делали сами. Во-первых, так сложилось исторически - когда начинали, готового в доступности не было, а когда появилось, у нас уже были свои наработки, более доступные по ценам. Во-вторых, наши клиенты просто не могли себе позволить подход от "интеграторов" - "купите наши контроллеры, потом к ним купите наши устройства, потом ко всему этому купите наше ПО, которое останется только настроить и за все это мы хотим 100500 денег". Мы же ориентировались на те устройства, которые уже есть у заказчика. И в конечном итоге пришли к тому, что можем подключить все, что управляется электричеством по проводам. Естественно, что софт писался с учетом всего этого. Например, там мог быть датчик типа "сухой контакт", нормальное состояние замкнутое, аварийным считается ситуация, когда он непрерывно разомкнут более 30-ти секунд. Т.е. замкнут или мигает - норма. Все это легко описывалось и конфигурировалось в рамках разработанной нами формальной классификации типов устройств. Для более сложных типов разрабатывали "драйвера" - модули со стандартным интерфейсом, полностью включающие в себя всю специфику работы с устройством и подключающиеся "на горячую" без остановки системы. Т.е. сначала физически подключается устройство (условно - к клеммам на УСО), потом уже на пульте диспетчера - "новое устройство", где расположено, к какому УСО подключено, тип (из стандартных, или "новый, вот драйвер") и конфигурация. После этого устройство начинало работать в системе.
Такой подход позволил вполне сносно держаться на рынке даже в условиях сравнительно небогатых и очень прижимистых, зарегулированных разными "тарифными комиссиями" клиентов (ЖКХ, УК...)
vassabi
19.05.2023 12:40+2что-то я подозреваю, что низкие зп - это до тех пор, пока пенсионеры и дешевые электрики\сантехники могут поддерживать всё это на ходу.
А потом - выход из строя техники ( авария, которую в отличии от предыдущих не удастся починить) поставит перед выбором: либо новые технологии (и другие деньги), либо "удобства во дворе" ...
SpiderEkb
19.05.2023 12:40Нет, там все хуже.
Во-первых, вам придется приспосабливаться к тому оборудованию, которое установил застройщик. И если застройщик поставил отечественные лифты с УБДЛ на борту, то или меняйте все лифты целиком, или ищите систему ЛДСС, которая может работать с УБДЛ. Не найдете - отключаете все лифты (по ПУБЭЛ) и пусть ходят пешком.
Во-вторых, вам никто не даст брать с квартиры по 5тр (условно) за лифт просто потому что у вас бродят идеи про "новые технологии" - есть тарифная комиссия которая устанавливает предельные расценки по всем позициям. А расценки таковы что... Порой вместо трех аварийных бригах денег хватает на содержание только одной.
И это реально проблема.
vassabi
19.05.2023 12:40+11) сделать свою "систему ЛДСС, которая работает с УБДЛ" - это имхо стандартная задача в ИТ.
2) а вот "есть тарифная комиссия которая устанавливает предельные расценки по всем позициям" - это да. Но когда лифты будут останавливаться пачками, то либо перейдут на "безлифтовые технологии физической культуры вертикального стадиона", либо сменят тарифы, либо придется субсидировать тарифы (по крайней мере на время перехода на новые рельсы) ...
YDR
19.05.2023 12:40В Казахстане, говорят, есть лифты с оплатой каждой поездки... Неужели энергетическая супердержава к этому идёт?
SpiderEkb
19.05.2023 12:40сделать свою "систему ЛДСС, которая работает с УБДЛ" - это имхо стандартная задача в ИТ.
Что мы и сделали. Были первыми. Потом еще появились.
Я просто к тому, что тут приходится все делать самому, а не через интегратора закупать готовые решения.
Но когда лифты будут останавливаться пачками, то либо перейдут на "безлифтовые технологии физической культуры вертикального стадиона", либо сменят тарифы, либо придется субсидировать тарифы (по крайней мере на время перехода на новые рельсы)
В стране розовых пони и белых единорогов, наверное, так и происходит. Но в реальном мире, увы... Мы тоже когда-то надеялись что так будет. Но так не стало. За те 25 лет, что я был в этой сфере.
vassabi
19.05.2023 12:40хм.
Но ведь если у вас она уже есть - то теперь вы и сами можете быть таким интегратором ;)
Мы тоже когда-то надеялись что так будет. Но так не стало. За те 25 лет, что я был в этой сфере.
техника стареет медленно ? Кстати в новостройках-то уже новые лифты ставят, там уже новые технологии. Или нет ?
SpiderEkb
19.05.2023 12:40Но ведь если у вас она уже есть - то теперь вы и сами можете быть таким интегратором ;)
Фактически так и есть. Эти системы начинались как штучные, сейчас это уже вполне нормальное "коробочное" решение с комплектом документации.
И в целом средняя лифтообслуживающая организация вполне способна смонтировать систему своими силами
В нашем случае заказчик говорит сколько него чего есть, исходя из этого формируется комплект. А дальше - разместить контроллеры, прикрутить к УСО конечные устройства, соединить УСО с IP-шлюзом линией RS-485, подключить IP-шлюзы к интеренету. Все остальное уже делается на компе в диспетчерской - загрузить карту "местности", указать обслущиваемые объекты на карте, сконфигурировать устройства подключенные. Это все уровень среднего эникейщика.
Другие системы примерно таким же образом собираются.
Кстати в новостройках-то уже новые лифты ставят, там уже новые технологии. Или нет ?
А УБДЛ и есть новые технологии. Это лифтовой контроллер - Устройство Безопасности и Диагностики Лифта.
Старые технологии (с которых мы начинали и которые в принципе тоже можем подкюлчать) - это два реле. РИТО (реле индикации точной остановки - лифт на этаже - замкнуто, между этажами - разомкнуто. Если разомкнуто непрерывно более 30сек - лифт завис между этажами) и РКД (реле контроля дверей - замкнуто - закрыты, разомкнуто - открыты. Елси разомкнуто более 2-х минут непрерывно - двери заклинило в открытом состоянии).
Ну в некоторых особо продвинутых советских лифтах еще был датчик пола. Использовался как источник дополнительной информации - есть в кабине люди или нет (если лифт завис между этажами).
По информации от этих трех устройств вполне себе можно было формировать аварийное сообщение типа: "Авария лифта. Лифт между этажами. Двери шахты закрыты. Кабина пуста." с указанием точного места (адрес, подъезд, пассажирский или грузовой лифт) и подсветкой его на карте.
Конечно, современные лифтовые контроллеры куда больше информации дают - там и скорость движения кабины и температура двигателя и стек отказов и время простоя за период и много чего еще.
Но каждый контроллер по своему протоколу работает и формат информации разный. У корейских один, у шнайдера другой, у отиса третий, у наших УБДЛ четвертый... Поэтому приходится под все известные типы добывать протоколы обмена, писать "драйверы"... Застройщики ведь ставят что им удобнее - предложил им отис хорошие условия - поставят отис. Не предложил - могут поставить что-то наше - Щербинка или "Карачаровский паравозолитейный". Там скорее всего какая-то из версий УБДЛ будет.
Ну и плюс еще дополнительные функции - охрана служебных помещений (машзал лифтов, электрощитовая..), дистанционные замки, переговорки со служебными помещениями (полудуплексная линия ГГС все равно есть на лифтах), видеонаблюдения, запись разговоров диспетчера с лифтами, дублирование пожарной сигнализации (она на пульт пожарной охраны идет прямо, но и в диспетчерскую тоже дублируется), контроль и ручное управление системой дымоудаления, контрооль и ручное управление освещением подъездов. Там много всякого хозяйства помимо ЛДСС.
И сейчас все УК работают с подобными системами. Потому что в СССР ведь как было - диспетчерская. В ней пульт ПД-32 на 32 лифта. Автоматики никакой. На каждый лифт 3 лампочки (РИТО, РКД, кнопка вызова) и кнопка подключение линии ГГС с кабиной. От каждой лампочки-кнопочки своя пара проводов. Соответсвенно, обслуживаются только те дома, что рядом с диспетчерской.
Современная УК - 3 дома тут, один дом там, 5 домов еще на другом конце города или в соседнем городе-спутнике вообще. И все это на одной диспетчерской висит.
"На земле" так - ставится IP-шлюз. К нему по 485 цепляются УСО на ближайших домах. Шлюз по UDP уже с ядром системы на диспетчерской связывается.
НА диспетчерской стоит интерфейсный клиент "рабочее место диспетчера". Туда вся информация поступает. Он в "монопольном режиме" подключен к ядру (т.е. второй такой клиент к ядру может только в пассивном режиме просмотра подключиться). Еще где-то, в лифтообслуживающей конторе стоят клиенты аварийных бригад. Там у каждой бригады свой набор лифтов за которые они отвечают и они получают информацию только от них). Все клиенты с ядром по TCP работают. Если еще административные клиенты, позволяющие конфигурировать систему. У меня был сервисный клиент, позволял в реальном времени видеть что на ядре происходит и брать оттуда сервисные логи (могли позвонить - "там какая-то фигня была вчера в 4 утра - глянь что это было по логам")
Всего там на диспетчерской бывает штук 20 IP-шлюзов и на каждом от 10-ти до 30-ти УСО висит. Одних лифтов в системе штук 300-500 запросто может быть... И все это распределено по огромной площади - город-миллионник + 1-2 города-спутника. УК одна, диспетчерская одна, а аварийщиков несколько - в городе 2-3 бригады, в спутниках по одной... И у каждой свой клиент висит и они сразу сами видят если где авария - диспетчеру от них только подтверждение надо - "видим, поехали". Но это тоже реализуется в той же системе - т.н. "обработка аврийного сообщения" - аварийщики жмут у себя кнопку что "бригада поехала" или "бригада на выезде, информацию передали, заедут", диспетчер у себя это сразу видит как допинфу к аварийному сообщению (т.е. клиенты через ядро не только с контроллерами, но и между собой могут общаться).
Я как раз в конец занимался разработкой вот этого ядра системы. Там много всяких заморочек было и п архитектуре и по реализации.
Клиентов другой человек писал. Я в UI не лез особо - не фанат этого дела, мне потроха интересны низкоуровневые. И логика нетривиальная. А логика там... Каждую нештатную ситуацию надо максимально диагностировать. Нельзя просто сказать "что-то пошло не так где-то". Надо максимально подробно выдать что и где.
Вот пример. Обмен между ядром и теми, кто к нему подключен был датаграммами. Каждая имеет свой уникальный идентификатор (для данного клиента или контроллера). И каждая требует подтверждения приема. Т.е. получил - быстро проверил что это что-то осмысленное (формат совпадает, CRC совпадает...) и посылаешь квиток с идентификатором датаграммы - "все ок, получил". Потому уже в обработку ее.
Если квиток не пришел в установленное время - будет перепосылка. Пока квиток не придет.
И вот ситуация - в IP-шлюза поперли дубли. Т.е. он фигачит один и тот же пакет не обращая внимания на квитки. А надо понимать, что приемник и передатчик на шлюзе - физически разные модули. Т.е. передатчик работает, а приемник гавкнулся (реально было пару раз). И он квитков не видит... Вот такой ситуацию надо распознать и сформировать на соотв. клиент аварийное сообщение с нужным кодом - "с такого-то шлюза дубли идут, возможен выход из строя приемника".
Ну и там еще много всякого веселого было... Шлюз не отвечает (нет связи). Посылаем сообщение. Потом вдруг проснулся... Опять посылаем сообщение...
LeetcodeM0nkey
19.05.2023 12:40-2по идее - это должно было поднимать ЗП по сравнению с ИТ, в котором смузи и печеньки.
а получается наоборот.Потому что шальные деньги QE и ZIPR попёрли в "интернет-магазины" и прочие "социальные сети для разглядвания котиков". Масса стартапов, да и те же FAANG, пачками пылесосили разрабов не потому что им что-то разрабатывать надо, а потому что надо осваивать свалившиеся бюджеты. Конечно звучит диковато для малого бизнеса который "на свои", но крупный бизнес и прочие венчуры живут совсем по другим законам. Сейчас этот краник перекрыли, так что зарплаты и занятость в секторе неизбежно придут к "средней по больнице". Тот же Твитор уволил 80% своего состава и наглядно показал чем там все на самом деле занимались за гигантские зарплаты.
Ar4uk_EI
19.05.2023 12:40+3Ну не знаю если честно... Что касается архитектуры и структурирования кода в асу тп, то это больше вопрос к себе и к компании где работаешь, я работал в больших компаниях мы занимались в основном черной металлургией, там требования достаточно высокие, кстати ни разу не видел что бы монтажник или технолог писали программу, я правда не понял крик души автора, как по мне все ок, по зарплатам, так как я мариуполец скажу так, в Украине за очень низкие, чуть больше слесаря, в РФ зп вполне на высоком уровне, понятно что ниже чем в ит, но все же. Что касается ЯП, по LD скажу так, его используют чаще всего по причине удобства анализа программы на действующей установке, я сам люблю больше st(scl), но чаще всего приходиться комбинировать при написании по, комменты и описания опять же или на совести программиста или обязательны, если по на какую нибудь доменную печь, касательно должен ли асушник знать технологию, ответ - нет, асушник это программист он работает по ТЗ от технологов/механиков/гидравликов, что касается разных ide, все они отличаются внешним видом, возможностями и главное работой с hardware, но как по мне в этом нет ничего страшного, я работаю с АВ, Сименс, дельтой, Овном, митсубаном, у всех свои ide и ничего, мне все по кайфу ))) главное отличие разработки в асу от ИТ это возможность постоянного мониторинга по, очень быстрой диагностикой алгоритмов для максимально быстрого решения проблем на работающем производстве, а внедрять технологии ИТ в асу, это как женить носорога с зеброй если честно...имхо
lehkap
19.05.2023 12:40Согласен по всем пунктам. Дебаг почти во всех популярных котроллерах это песня и во многих есть применение изменений налету, что тоже весомый плюс. Единственное не хватало системы контроля версий. Слышал что у siemens step 7 была какая-то система контроля версий, но это какая-то проприетарная платная прога. А у большинства сред "проекты" хранились в каком-то бинарном формате.
Как понимаю основное применение IT в АСУТП - это интеграция систем разных уровней в единую систему. Но это не то IT которое мы привыкли видеть с аджайлом, активной разработкой, кучей аналитиков и тестировщиков, а больше ближе к IT в формате 1С, только большими масштабами
pistoletov
19.05.2023 12:40Как писал автор о поизоде Iot в асу тп. Ребята сделали проект wirenboard. По сути Линукс ПЛК. Буду соседу умный дом на его базе строить. ПЛК в первую очередь должны быть сверхнадежными. Цена ошибки в этом софте может стоить очень дорого. Я embedder но пару раз имел дело с плк. Друг просил поменять программу работы станка. Потратил несколько вечеров на разобраться с алгоритмом работы станка. Узнал чтото новое, не скажу что эти знания мне понравились. Для единичных изделий плк самое оно.
XitroUtko
19.05.2023 12:40Вы прежде чем делать на его базе умный дом, посмотрите, какая уже версия железа у них. Все хочу тоже с ним поиграться, но это отталкивает - что делать , если вдруг железка помрет условно через 4 года? Уже не будет ПЛК v.7, а будет какая-нибудь v.9 . И что делать? переделывать шкаф/прогу под новую версию? или ждать, когда вам под заказ ее сделают?
У всех нормальных вендоров железо обычно поддерживается лет 5 минимум, а иногда и больше.
Лучше уж на каком-нибудь Овене (будь он неладен) делать проект - спецов, которые чуть что смогут откорректировать программу полно, софт бесплатен, железо всегда можно найти.
CrashLogger
19.05.2023 12:40+7Очень люблю железо и embedded разработку, испытал на себе все вышеописанное ) В итоге нашел для себя нишу на стыке Android и embedded - всякие системы умного дома, автомобили, POS-терминалы. Такой компромисс позволяет с одной стороны писать на нормальном языке в нормальной IDE за нормальные деньги, а с другой - ковыряться с железками, низкоуровневыми протоколами и иногда тыкать осциллографом в разные места )
victor_1212
19.05.2023 12:40+2правильное решение, желаю успеха,
если интересно можно попробовать api соорудить, типа абстрактное описание дома и окрестностей
solfir
19.05.2023 12:40Эх, материться хочется. Автор, похоже не видел настоящего АСУТП, раз называет языки урезанными. Да они специфичные. Но вполне себе полноценные. Ну не существует алгоритмов, которые нельзя на них реализовать. Либо эта задача не для ПЛК. Сложилось впечатление, что автор не видел сложных систем, поинтереснее уровня "котельная на умном реле ОВЕН".
Я тут в качестве хобби занялся ардуинами - и понял, что я не программист. Вместо двух кликов в мышки в Tia Portal, необходимо написать несколько строк кода. Да это же просто неудобно. Хотя ностальгия накатила, у меня когда-то ZX Spectrum был. Подключал TFT дисплейчик - и был удивлен, что нет никакой программы типа HMI, где накидал полей ввода-вывода, а оно само переменные привязало. Все ручками. А еще чтоб сменить надпись, нужно сначала предыдущую затереть текстом цвета фона. Ужас. А если фон - картинка, то эту проблему я не решил, может как-то и можно, но сходу не получилось. Про отладку молчу. Любой дебаг, который я видел - это издевательство. Ну тупо удобнее видеть алгоритм подсвеченный, чем прыгать по брейкпоинтам.
По поводу низких зарплат, проблему я решил. У меня, к слову была достаточно высокая, но хотелось больше. Уволился, зарегистрировал ИП и теперь я сам называю заказчику желаемую сумму. Причем еще ни разу сам не искал заказчиков, никакой рекламы. Конечно, это дается не просто так - нужен опыт. Большой опыт. И при этом все равно постоянно приходится что-то изучать. Потому что куча IDE, у каждого производителя свои приколы, тут автор прав. А еще АСУТП это не только программирование. Асушник - это и электрик и технолог и наладчик и механик еше наверное кто-нибудь.
Подытожу. Для каждой задачи есть свои инструменты. Иногда даже разные. Не нравится автору LAD, возьми какой-нибудь контроллер с С-подобными языками, такие существуют, Контел, например. Или любой микроконтроллер, придумай к нему обвязку и пиши на чем хочется. Хотя для современных задач может и не хватить микроконтроллера.
gregg666
19.05.2023 12:40+1Рынок АСУТП конкретно перевернулся... У нас на огромном предприятии везде eXpert SCADA (Италия), Sprecon V460, MicroScada PRO, все импортное, нет никакой документации или поддержки производителя, АДЪ какой-то.
xanto
19.05.2023 12:40У нас на огромном предприятии везде eXpert SCADA (Италия) .. нет никакой документации или поддержки производителя
С десяток лет назад внедряли обьекты на этой SCADA с оборудованием другого итальянского вендора (да и сейчас иногда всплывают доделки). В принципе, сейчас ещё остались кадры, работающие на рынке поддержки данных вендоров. Искать поддержки у производителя сейчас, думаю, нереально. Не сложилось как-то у обоих этих вендоров на нашем рынке, но, честно говоря, никакого сожаления, ибо оба решения далеки от идеалов.
a_titaev
19.05.2023 12:40+11АСУ ТП – это отрасль, которая без постоянного развития промышленного производства очень быстро сама себя «съедает». Требований для этого развития очень много, и при отсутствии почти любого – отрасль начинает загибаться. Например, обесценился ручной труд – автоматизация стала невыгодна, и приехали. Или нет увеличивающегося рынка сбыта, тоже плохо – все что можно автоматизировали, а дальше тупик (это, мне кажется, как раз наш случай). Тем более она очень зависит от поставок электронных компонентов (да и целых устройств начиная от ПЛК и кончая примитивными типа опторазвязок или реле) из-за рубежа. На этом фоне объясним и взлет зарплат IT. Если Вы, к примеру, хотите производить хлеб. Сначала наняли пекарей и работаете потихоньку. Потом решили снизить себестоимость – купили или заказали линию выпечки хлеба. Вот, заплатили асутпшникам, их работа. Но ОДИН раз. А дальше линия работает сама, требует минимум поддержки. Зачем Вам еще АСУ ТП ? Живете, деньги текут, яхта-вилла есть. Куда бы направить излишек ? Во вторую линию для расширения производства ? Да ну, дорого, еще и может не окупиться. Давай ITшников наймем, чтобы они повысили нам эффективность существующего производства: сделают бизнес-аналитику, найдут узкие места, добавят систему внутреннего документооборота, сделают интернет-магазин, где можно будет выбирать покупки. Это потребует 1/10 стоимости второй линии, но эта 1/10 может составить 100 млн, и разойдется между 10 человеками из IT-отдела. А новая линия стоила бы 1млрд и потребовала для своего создания 1000 специалистов АСУ ТП, которых может и не найтись вообще. У кого ЗП будет выше? И критерии сделанной работы в обоих случаях тоже несоизмеримы. Для того, чтобы работа программиста интернет-магазина была признана сделанной, необязательно, чтобы этот магазин «производил» покупателей. А для того, чтобы была признана работа АСУ ТП, обязательно, чтобы линия работала и производила булки.
У меня была какая-то надежда, что в связи с последними событиями что-то изменится, пойдут деньги в производство, обучение кадров. Но теперь понимаю, насколько «ребяческой» она была, и какой комплекс проблем препятствует этому развитию.victor_1212
19.05.2023 12:40> АСУ ТП – это отрасль, которая без постоянного развития промышленного производства очень быстро сама себя «съедает». Требований для этого развития очень много, и при отсутствии почти любого – отрасль начинает загибаться.
хорошее наблюдение, вероятно можно сказать что состояние дел АСУ ТП намного более точно отражает состояние промышленности, чем другие составляющие IT
panzerfaust
19.05.2023 12:40+10Огромное количество сред разработки PLC / HMI / SCADA («зоопарк»)
Работал я с ПЛК Honeywell Centraline. У этих клоунов для 4 контроллеров: Lion, Falcon, Hawk, Eagle - было 4 языка и соответственно 4 IDE. И самое смешное, что выходишь ты, знаток этого зоопарка, на рынок - и твой опыт там ни с чем не бьется и никому не нужен. А для компании отдельный квест найти тебе замену с опытом.
Отличный пример того, что когда не вырабатываются стандарты и кажды гребет под себя, то в итоге все в проигрыше.
Satyricon
19.05.2023 12:40+1Мои знания Modsoft и RS-Logix тоже теперь никому не нужны. Но я ушёл с АСУТП, поэтому это не проблема. Привет, Транснефть :)
x67
19.05.2023 12:40+10Все проще. Нет рынка. Нет потребности. Нет конкуренции. Нет необходимости развиваться чтобы конкурировать. Нет необходимости ебашить. Те, кто готов и могут ебашить и развиваться - уходят туда, где для этого возможности есть. Остаются те, кому норм.
То есть заказчикам норм. Исполнителям норм. Производителям норм. Так в чем проблема?
Когда-то давно, еще в 2015 году я вводил эти магические буковки в гугле, на хх.ру, в зарубежном интернете и не находил никаких вызовов для себя кроме финансовых. А теперь сравните с тем же IT - одни тут банк свой делают, другие беспилотные автомобили, третьи - продукт для АБ тестирования пилят. Везде высокие зарплаты, огромная потребность в кадрах, но и не меньшие требования и специфичные знания. Ты просто знаешь, что будешь ебашить, но это будет вознаграждено и финансово и морально.panzerfaust
19.05.2023 12:40+3То есть заказчикам норм. Исполнителям норм. Производителям норм
Воистину. Моя тогдашняя контора пилила АСУ для бытового климат-контроля. Начальник в 2015г на голубом глазу впаривал клиентам в качестве HMI промышленные резистивные панели 800х600. Им место в кочегарке, а не в модном лофте. Меня просто в ступор вводило, почему всем норм, почему у начальника хватает на это совести, а у заказчиков не хватает ума отказаться от этой дичи и потребовать реализацию HMI через iPAd.
vassabi
19.05.2023 12:40+2(побуду адвокатом дьявола :) )
1) а чем плохо решение "железо и экранчик" ?2) если раздавать через iPad то надо как-то ограничивать доступ. Экранчик физически ограничен.
saipr
19.05.2023 12:40-2Моя Родина – АСУ ТП — смертельно больна
Здесь же на Хабре есть статья с созвучным названием:
АСУ: от печали до радости. История российской автоматизации
В 50-е годы, когда в СССР зарождалась идея создания АСУ и начала активно развиваться кибернетика, всех этих ресурсов не хватало. Учёные того времени были не только сухими прагматиками, но и мечтателями — им хотелось позитивных изменений социо-экономических отношений, которые была призвана обеспечить АСУ.
flx0
19.05.2023 12:40+6Меня радует эта статья и комментарии к ней. Когда я работал с около-асушными вещами, неоднократно восклицал "Да для кого это вообще сделано?! Кому с этим может быть удобно работать?!". На что настоящие асушники отвечали что для них и им норм. Радует что и другим людям начинают закрадываться мысли что что-то с текущим состоянием АСУ не так.
Впрочем, главное "не так" в АСУ - это вендор-лок, вызванный жадностью производителей. Поэтому каких-то предпосылок для улучшения ситуации я не вижу.Nansch
19.05.2023 12:40+1Вендорлок уходит с опытом. Поработав с основными брэндами, становится понятно, что в общем-то везде одно и то же плюс нюансы реализации. Ситуация налаживается, даже IDE становятся все друг на друга похожими.
eteh
19.05.2023 12:40+1У адекватных вендоров да, но иногда эти нюансы могут доходить чуть ли не абсурда - пример есть одного вендора где писать нужно практически на чистом ассемблере и это не мэк язык, но они на рынке с советских времен.
xcs9
19.05.2023 12:40+4Пишем SCADA, много лет. Странное впечатление оставляют наши клиенты. Как будто год за годом в борозде, не поднимая головы, безрадостно, безнадежно утопая в рутине.. Сколько не пытался через техподдержку какой-то значимый фидбек получить - без толку. Такие мелочи просят.. просто удивительно, настолько все привыкли ко всяким костылям, обходным путям и т.п. Это не только к нашему продукту относится - такое впечатление, что люди иной жизни и не представляют..
Mitya78
19.05.2023 12:40+2Хотел ответить на первые комментарии, но пока ждал истечения времени для дозволенных речей, то дискуссия уже ушла далеко.
Поэтому просто изложу своё видение и мысли. Немного сумбура обо всём.
Первое, у самой отрасли особо проблем нет - АСУ развивается, как аппаратно, так и программно.
На Сименс я пишу в SCL, не вижу каких-то особых проблем с этим языком, уж точно логичнее многих, для "нормального" программиста точно не будет ничего сложного. Бекхофф вроде вообще позволяет на Си писать.
СКАДА так там часто либо тот же VBS, либо опять C.
В современных версиях ТИА Портал уже и контроль версий подвезли (правда визуализации это не касается), но мы пробовали командой так работать - не очень зашло, проще на объекте через МультиЮзер работать да версии плодить.
Не очень понял что хочет автор, перевести всех с ПЛК на сервера, где крутилась бы программа управляющая периферией?
Ну кто-то уже пробует так делать, в том году имел подробную беседу с "немцами", они как раз что-то делают подобное, пока только для Кодесис.
Да кто же против?! Когда компании по всему миру ждут поставок ПЛК, то неужто бы они против были? В прошлом мае был у словенцев, рассказывали что снимают старые S7-300 и переписывают под них программы, потому что новых контроллеров не достать.
И да, та немецкая компания очень хвасталась временем цикла менее 10мс при использовании их софта не серверах, что в общем-то не проблема для обычного контроллера.
На прошлой работе мой последний проект это был автоматический склад, на ПЛК S7-1517, так у нас на нём крутились сотни участков c моторами, тысячи датчиков, сканеров, общение с роботами, WCS... Да там ещё запас был.
И всё спокойно настраивается, конфигурируется удалённо, уже давно не надо джамера перетыкать.
Вот лично я большую часть своей карьеры просто программирую, за отвёртку последний раз брался чтобы починить автоматическое ведро в офисе.
У нас (не на одной работе) и монтажники и наладчики были, служба поддержки...
И про себя я не могу сказать, что какой-то переучившийся железячник, в нашем Политехе программированию контроллеров учили.
На первой работе по специальности как стартовал с S5 (читая Бергера) так и продолжаю по сей день.
Теперь заключительная часть, про зарплаты и не только.
На самом деле это не программисты ПЛК получают мало, это обычные программисты получают больше.
Тут конечно и меньшая масштабируемость, даже точно такая же линия ламинирования ДСП точно так же не заведётся сразу, а на чём-то типовом вроде насосных станций обычно много денег не поднять.
Да, я честно пытался посмотреть что там пишут люди в нормальном мире, у меня мозги заворачиваются, уж не знаю что тому главная причина.
Так что не могу сказать, что мои коллеги денег не хотят, я такого не видел. Я и сам вроде не отказываюсь. Ну наверное мои 150 т.р. на последнем месте работы в России это не зарплата для местной аудитории. Так и в Европе программисты ПЛК сотни тысяч не получают, и от страны очень сильно зависит.
И вот подхожу к главной проблеме работы программистом ПЛК, для меня так точно - командировки. Точнее командировки и командировки.
Я-то случайно попал в одно (гиблое как оказалось) место на тринадцать лет и забыл как оно бывает. А когда захотел выйти из пресловутой зоны комфорта, сразу вспомнил.
Когда я устраивался в Сименс и мне говорили про "выезды на объекты", а потом оказалось что из таких выездов работа и состоит на 90%, то я через неделю оттуда ушёл, из компании мечты-то.
Так что благодарен нынешней работе, и что в Европу смог переехать и что сижу на одном месте.
Извиняюсь за сумбур, через сутки может что ещё смогу ответить.
MiraclePtr
19.05.2023 12:40+4О да. И нередко эти "выезды на объекты" ещё означают «работа в офисе с 9 до 18, а в командировках длительностью по несколько недель — с 7 до 23, и не факт что вам сильно за это доплатят». Причем это все легально и полностью по ТК. Просто современный трудовой кодекс не регламентирует длительность и частоту командировок. Вообще никак. А в командировках фронт работ обозначен и должен быть выполнен, и в итоге у работника есть выбор: работать размеренно по 8 часов в день и увидеть свою семью только через месяц, или по собственному желанию и за свой счет впахивать сверхурочно, чтобы вернуться к жене и детям на две недели раньше. А еще есть третий вариант, после полугода издевательств послать всех в литую кружку, уволиться, и в следущий раз хорошо подумать, прежде чем подписываться на работу с командировками.
mayorovp
19.05.2023 12:40-1СКАДА так там часто либо тот же VBS, либо опять C.
Два устаревших языка, а вы их наличие выдаёте за что-то современное.
Си ещё держится как язык системного программирования, но для прикладных программ он устарел безнадёжно.
vassabi
19.05.2023 12:40командировки - это боль, да.
У меня родственник лет 10 томуназад - поработал годик на Сименс, и такую мотивацию от комадировок получил, что потом сбежал в мобильные разработчики.Даже свифт выучил с нуля (чтобы писать код на айфонах\айпадах, а не уставки в контроллерах тяговых подстанций у черта на куличках :) )
После чего нашел себе девушку (или она его наконец-то нашла между командировками), женился и сидит дома - растит дерево, пузо и детей.
frozzzen
19.05.2023 12:40+1Зачем АСУТП, если нет производства? Это первый вопрос. Объем рынка труда в российском АСУТП стремится к нулю, и "зарплаты" туда же. Следующий момент, а почему не "удалёнка"? А потому что не удалёнка. На реальном производстве можно удалённо нарулить такого, что три страховые компании разорятся. Необходимо иметь объект управления в физическом доступе, чтобы его автоматизировать. Ибо наш мозг постоянно пытается подменить реальный объект упрощёнными моделями. И на эти грабли лекго налететь. А "удалённо" налететь ещё легче.
Refridgerator
19.05.2023 12:40+1Особенность инженера АСУ ТП в том, что сам по себе он ничего не значит. На первом месте всегда производство. Уйдёт один инженер — нестрашно, придёт другой, свежевыпустившийся из института, готовый работать ради опыта, ну и зарплаты там таки выше чем у дворников и продавцов в макдональдсе. А не найдётся инженер — найдётся фирма, которая пообещает владельцу бизнеса увеличить прибыль в перспективе заменой системы автоматизации целиком на более "эффективную". Я видел такие контракты, эти фирмы не дураки и остаются в плюсе при любом раскладе. С другой стороны, владелец бизнеса готов отдать 100М чужим дядям, но не готов дать 1М местному Петровичу, который может сделать то же самое и даже лучше — потому что такая психология и правила игры в целом.
Если программист набрался опыта в условном гугле — он может применить этот опыт в своём стартапе или конкурирующем продукте. А инженер АСУ ТП — не может взять и построить ещё один металоперерабатывающий заводик. И даже не потому, что это совсем другой уровень знания и инвестиций, а ещё и не решается без участия властей и/или криминальных авторитетов.
Опять же уже упоминалось, что АСУ ТП это не так уж и сложно. Зоопарк оборудования и скада не такой уж и большой по сравнением с теми же JS-фреймворками, не говоря уже о всех библиотеках в целом. В АСУ ТП не нужно изобретать что-то новое. Нужен газоанализатор — купил газоанализатор. Нужен спектроанализатор — купил спектроанализатор. Не нужно вникать в теорию, как это всё работает. Нужно к MODBUS через OPC подключиться — и тут готовая программка найдётся.
Конечно, порог вхождения в АСУ ТП выше, чем у условного формо-писателя мышкой на шарпе. Но зато и предел развития ниже. Логика производства не меняется, любые изменения незначительны по сравнению в целом, новые компоненты и протоколы появляются не так уж часто. А как только иссякает поток новой информации — соответственно иссякает и возможность для профессионального развития. Потому и не уходят инженеры (и я том числе), потому что попадают в зону проф. комфорта. А те, кто уходят, обычно уходят в принципиально другую область (одно исключение знаю — бывший коллега трудится над тем самым роботом Фёдором).
ky0
Какие зарплаты — такое и комьюнити, не?
Willy64
Я правильно понимаю посыл, что АСУТПшники сами виноваты? А ИТшники, ставящие себя выше всего этого, понимают, что буквально их ежедневная жизнь зависит от АСУТП (электричество, отопление, без которого в России - смерть, вентиляция, которая по современным представлениям относится к системам жизнеобеспечения)?
ky0
Нет, вы понимаете неправильно (посыл моего комментария). Никто конкретно не виноват — и в то же время виноваты как работники, соглашающиеся выполнять такую важную и ответственную работу за гроши (релевантно также для учителей, врачей, пожарных и т. д.), так и работодатели, не способные почему-то начать получать достаточную для нормальных зарплат прибыль. Про государство, которое, по идее, должно заботиться о достойной жизни всех без исключения граждан, формируя комфортные для бизнеса условия уж не буду — тут всё понятно на текущем историческом отрезке, приоритеты другие.
Каким боком тут айтишники — не совсем понимаю. Если АСУТПшники варятся в собственном соку среди таких же озлобленных и токсичных коллег, но ничего с этим делать не собираются — чем мы, айтишники, можем помочь?
Kazikus
Подскажите, пожалуйста, есть ли в данной области фактор закупки оборудования за границей? Может поэтому нет большого спроса на специалистов. Нет конкурентного аукциона за кадры.
Про врачей и учителей не соглашусь. Хорошие врачи на вес золота. Получают соответственно. Когда прижмёт, люди отдают последнее. Бывают ситуации когда деньги есть, а не знаешь куда бежать с проблемой. Много шарлатанов и вымогателей без реального решения.
Про учителей. Есть ребята, которые способны вгрузить прикладную высшую математику за пару месяцев (при условии, что ученик не совсем бревно). Есть кто оперативно подготовит к экзамену. Был опыт с английским, когда активизировали разговорный за несколько месяцев.
Как и в любой профессии есть крутые спецы, а есть все остальные, которых легко заменить. Это и рождает цену. Если хотите продукт высокого качества (например, чадо в мфти), то за результат будешь готов платить (если есть возможность) . А научить складывать 2+2 много таланта не нужно. Научить мыслить и анализировать это уже дорогая услуга. Почему-то репетиторам мы готовы платить из своего кармана, а школьному учителю за каждый урок нет (групповое занятие).
Всё это хорошо видно по рынку спортивных тренеров. Кто-то ставит высокий ценник и к нему невозможно попасть, а кто-то перебивается случайными клиентами. У одного талант, опыт и качественный результат. У второго просто ещё один посредственный выпускник. Посредственный - нераскрытый потенциал.
С геройскими профессиями сложнее. Видимо нужна какие-то очень большие премии за настоящие поступки.
Люди выбрали рынок и капитализм. Рынок говорит, что базовый спрос за эту цену удовлетворён. Хочешь больше, плати больше.
avdosev
Хотите сказать, что во всем виноват железный занавес при ссср, поэтому теперь нужно сделать такой же чтобы неконкурентные разработки вывести на конкурентный уровень?
ru1z
Скорее фактор интереса развития образования и собственных специалистов, раз его нет, так и будут покупать в Китае.
Почему нет? Очень даже готовы. Это частное образование называется, но у людей денег нет. С частными школами, хорошими репетиторами и прочим, это как и должен быть капитализм, а то, что большинство людей имеет сейчас, больше похоже на противоположность, либеральный социализм в условиях общественного неравенства слоев, с как будто бы (представим) "бесплатной" школой, медициной и прочим.
Но в целом, это все снова разговоры о налогах, бюджетных средствах и о том, куда они на самом деле идут.
YDR
работодатели обычно получают нормальную прибыль. Вы на их автомобили посмотрите.
У государства тоже все хорошо.
(и тут такой мем с 2 собаками, смотрящими на Вас)
kilobait3
У пожарных плохая ЗП? Да ладно, они уже автомобили дешевле 2млн не берут. Как и вояки с жиру бесятся.
vyatkh1
Пермский край - 22000 руб./мес. Интересно какое авто на такую зп. Можно купить?
javalin
Извините, пожалуйста, а кто с вашей точки зрения виноват во бедах АСУТПшников?