Comments 316
Какие зарплаты — такое и комьюнити, не?
Я правильно понимаю посыл, что АСУТПшники сами виноваты? А ИТшники, ставящие себя выше всего этого, понимают, что буквально их ежедневная жизнь зависит от АСУТП (электричество, отопление, без которого в России - смерть, вентиляция, которая по современным представлениям относится к системам жизнеобеспечения)?
Нет, вы понимаете неправильно (посыл моего комментария). Никто конкретно не виноват — и в то же время виноваты как работники, соглашающиеся выполнять такую важную и ответственную работу за гроши (релевантно также для учителей, врачей, пожарных и т. д.), так и работодатели, не способные почему-то начать получать достаточную для нормальных зарплат прибыль. Про государство, которое, по идее, должно заботиться о достойной жизни всех без исключения граждан, формируя комфортные для бизнеса условия уж не буду — тут всё понятно на текущем историческом отрезке, приоритеты другие.
Каким боком тут айтишники — не совсем понимаю. Если АСУТПшники варятся в собственном соку среди таких же озлобленных и токсичных коллег, но ничего с этим делать не собираются — чем мы, айтишники, можем помочь?
Подскажите, пожалуйста, есть ли в данной области фактор закупки оборудования за границей? Может поэтому нет большого спроса на специалистов. Нет конкурентного аукциона за кадры.
Про врачей и учителей не соглашусь. Хорошие врачи на вес золота. Получают соответственно. Когда прижмёт, люди отдают последнее. Бывают ситуации когда деньги есть, а не знаешь куда бежать с проблемой. Много шарлатанов и вымогателей без реального решения.
Про учителей. Есть ребята, которые способны вгрузить прикладную высшую математику за пару месяцев (при условии, что ученик не совсем бревно). Есть кто оперативно подготовит к экзамену. Был опыт с английским, когда активизировали разговорный за несколько месяцев.
Как и в любой профессии есть крутые спецы, а есть все остальные, которых легко заменить. Это и рождает цену. Если хотите продукт высокого качества (например, чадо в мфти), то за результат будешь готов платить (если есть возможность) . А научить складывать 2+2 много таланта не нужно. Научить мыслить и анализировать это уже дорогая услуга. Почему-то репетиторам мы готовы платить из своего кармана, а школьному учителю за каждый урок нет (групповое занятие).
Всё это хорошо видно по рынку спортивных тренеров. Кто-то ставит высокий ценник и к нему невозможно попасть, а кто-то перебивается случайными клиентами. У одного талант, опыт и качественный результат. У второго просто ещё один посредственный выпускник. Посредственный - нераскрытый потенциал.
С геройскими профессиями сложнее. Видимо нужна какие-то очень большие премии за настоящие поступки.
Люди выбрали рынок и капитализм. Рынок говорит, что базовый спрос за эту цену удовлетворён. Хочешь больше, плати больше.
Подскажите, пожалуйста, есть ли в данной области фактор закупки оборудования за границей? Может поэтому нет большого спроса на специалистов. Нет конкурентного аукциона за кадры.
Хотите сказать, что во всем виноват железный занавес при ссср, поэтому теперь нужно сделать такой же чтобы неконкурентные разработки вывести на конкурентный уровень?
фактор закупки оборудования за границей
Скорее фактор интереса развития образования и собственных специалистов, раз его нет, так и будут покупать в Китае.
Почему-то репетиторам мы готовы платить из своего кармана, а школьному учителю за каждый урок нет
Почему нет? Очень даже готовы. Это частное образование называется, но у людей денег нет. С частными школами, хорошими репетиторами и прочим, это как и должен быть капитализм, а то, что большинство людей имеет сейчас, больше похоже на противоположность, либеральный социализм в условиях общественного неравенства слоев, с как будто бы (представим) "бесплатной" школой, медициной и прочим.
Но в целом, это все снова разговоры о налогах, бюджетных средствах и о том, куда они на самом деле идут.
работодатели обычно получают нормальную прибыль. Вы на их автомобили посмотрите.
У государства тоже все хорошо.
(и тут такой мем с 2 собаками, смотрящими на Вас)
Добрый день! Я, конечно, сам нарвался на минусы, написав такое на IT-шном ресурсе. Конечно, никто не виноват, так сложилась ситуация в отрасли, но от Вашего комментария не только мне стало обидно. Моя сфера деятельности затрагивает IT, АСУТП, коммуникации и строительство и только в сфере IT я вижу такой неприкрытый шовинизм, а в молодости и сам им страдал в полной мере.
Думаю, нет смысла в очередной раз раздувать тему о справедливости и зависимости зарплат от важности деятельности (старая тема про учителей и медиков). Есть и малооплачиваемые программисты, поддерживающие критическую инфраструктуру.
Извините, пожалуйста, а кто с вашей точки зрения виноват во бедах АСУТПшников?
А какие зп должны быть у инженеров АСУТП? Мы вот сейчас ищем себе Проектировщика на системы диспетчеризации, на 140тр на руки, ДМС и отсрочку от мобилизации не особо кандидатов. Весь hh уже перешерстили..(((
Я не знаю, какие. Но знаю, что, например, линукс-инженер с грейдом мидл в некоторых компаниях может с порога получать в полтора-два раза больше. На месте гипотетического "Проектировщика на системы диспетчеризации" - я бы крепко задумался :)
Проектировщик - это где-то уровень архитектора?
140тр по нынешним временам - это уровень среднего мидла, наверное... Архитектор начнется от 250-300. А то и выше.
И тут есть такой момент. Люди такого уровня, кто еще остался тут, на 99.9% неплохо трудоустроены и работу не ищут. И уж точно на hh не пасутся. Рекрутеры сами их вылавливают по различным сетям и форумам (тут на Карьере, SO, LI и т.п.) и уговаривают "хотя бы поговорить". Из личного:
Понимаю вас, вы не находитесь в активном поиске работы, Но предлагаю пообщаться, возможно, вас заинтересуют задачи, вы сможете сравнить условия и проект, и выбрать, что для вас интереснее. Вы от этого ничего не потеряете, а если все пройдет хорошо, получите оффер.
И тут еще приходится преодолевать инерцию - вот у меня тут все хорошо - и задачи интересные, и команда отличная, и руководство адекватное, и есть внятные перспективы роста, и по деньгам и плюшкам в целом все устраивает... И какой смысл бросать все это вот и ради лишних +10-15% к зарплате (ну пусть даже +20% - на текущем уровне даже это уже не критично) все бросать и бежать на новое место где бог его знает как все сложится и сколько проживет (и там эти самые +20% от сегодняшнего уровня могут затянуться на годы, а тут они же могут "прийти" через полгода-год).
Ну вот такая вот ситуация сейчас... Максимум что можете - взять человека без опыта и растить самим. Но тут риск что подрастет и свалит где платят больше. Куда ни кинь - всюду клин, как говорится...
спасибо, за подробный ответ, будем искать дальше)
Нет, проектировщик это не уровень архитектора. Это вообще про другое, это инженер, который разрабатывает документацию, чертежи, схемы, пояснительные записки и т.п. Может быть от 3й категории (типа джуниор) до ведущего инженера или главспеца (по вашему архитектор).
Ну вот у меня как раз коллега 3 месяца назад перебрался в Питер на примерно вашу зарплату. Правда, есть нюанс: а) здесь он был монтёром, работал недолго и опыта очевидно маловато б) он молодой горячий без детей и может позволить себе эксперименты. Ну и опыта соответственно как у молодого тоже маловато. Вопрос: как простимулировать взрослого человека с детьми и опытом в 10-1000x менять размеренную жизнь на приключения? И взрослый человек понимает к тому же, что "обещать не значит жениться".
Есть ответ - SimInTech! Вот пример разделения труда:
Доводилось мне для SimInTech модуль из матлаба портировать.
Извините, пригорело
ИМХО - язык крайне ограниченный и построен по принципу наибольшего удивления. Сообщения об ошибках при компиляции архинеинформативные и не дают совершенно никакой информации о самой ошибке.
Ну и отдельное неудовольствие - читать документацию для ЯПа SimInTech.
P.S. Открыл сохраненные три месяца назад ссылки на их доку - все протухли и ведут на заглавную страницу
UPD: Ну и да, это отличная иллюстрация тезиса статьи
разрабатывает свою «уникальную» IDE и урезанный язык программирования
Уникальная замена матлабу с преферансом и куртизанками, которую нужно везде использовать только потому, что она отечественная
Ну во первых SimInTech используют там где, Matlab Simulink просто не вывозит по своим возможностям. Например, в 2000-x, SimInTech (тогда это называлось ПК МВТУ) использовался для проектирвания и моделирования УСБТ управляющей системы безопасности технологи, для реактора черобыльского типа РБМК, с живым экспериментом на смоленской АЭС.
Потом была простая задача алгоритмы насосной перекачивающей станции (НПС) проверить. Это в 2008 у Вексельберга на ВСТО, у него тогда даже яйца фаберже были западные не говорял уже о софте. И матлаб с симулинком он тоже купил, только помер матлаб с simulink на половине алгоритмов одной НПС, а в SimInTech их собрали все полтора десятка, и он считал.
Солнечная батрея для спутника Решетнева году так в 2015, опять matlab с simulink пыхтел кряхтел, с трудом матрицу 100х100 ячеек посчитал и помер. В SimInTech мы просто памяти докупили для сревера и посчитал полную солнечную батарею с учетом затенения.
Ну а сомвсем недавно в 2022 Яндекс просил посчитать воздушное охлаждения дата центра где 8000 сервеных юнитов, в каждом из которы 4 вентилятора и два ПИД регулятора. Matlab и Simulink снова в пролете, заказ Yandex нам отдал.
Какая компиляция? Там нет никакой компиляции, для проверки запускай на расчет и смотри что происходит прямо на графической схеме, в этом и смысл стуркутрного програмирования в графическом виде. Если расчетная схема запустилась на расчет и выдала нужны результаты, то все решено можно заливать в контроллер, все скомпилируется без ошибок.
Ну а прямое сравнение лоб в лоб Simulink и SimInTech мы давно уже выложили в ютубе 6 прошло, до сих пор никто не может объяснить что там Simulink считает.
И кстати если не наравится встроенный язык программирования, никто не мешает собственные блоки делать на Си, примеры там есть.
Matlab Simulink просто не вывозит по своим возможностям
Не знаю, как там с расчетом реакторов, не владею предметной областью, но давайте сравним функционал SimInTech и Matlab на примере функции eig:
SimInTech
eig(M) – функция возвращает массив собственных чисел матрицы.
Matlab
e = eig(A) returns a column vector containing the eigenvalues of square matrix A.
[V,D] = eig(A) returns diagonal matrix D of eigenvalues and matrix V whose columns are the corresponding right eigenvectors, so that A*V = V*D.
[V,D,W] = eig(A) also returns full matrix W whose columns are the corresponding left eigenvectors, so that W'*A = D*W'.
The eigenvalue problem is to determine the solution to the equation Av = λv, where A is an n-by-n matrix, v is a column vector of length n, 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 matrices A and B.
[V,D] = eig(A,B) returns diagonal matrix D of generalized eigenvalues and full matrix V whose columns are the corresponding right eigenvectors, so that A*V = B*V*D.
[V,D,W] = eig(A,B) also returns full matrix W whose columns are the corresponding left eigenvectors, so that W'*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-n matrices, v is a column vector of length n, 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), where balanceOption is 'nobalance', disables the preliminary balancing step in the algorithm. The default for balanceOption is 'balance', which enables balancing. The eig function can return any of the output arguments in previous syntaxes.
[___] = eig(A,B,algorithm), where algorithm is 'chol', uses the Cholesky factorization of B to compute the generalized eigenvalues. The default for algorithm depends on the properties of A and B, but is generally 'qz', which uses the QZ algorithm.
If A is Hermitian and B is Hermitian positive definite, then the default for algorithm is 'chol'.
[___] = eig(___,outputForm) returns the eigenvalues in the form specified by outputForm using any of the input or output arguments in previous syntaxes. Specify outputForm as '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 располагается в США
Что-то мне подсказывает, что тут определенно есть какая-то связь с тем, что 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.
но "не сшмогла, я не шмогла"
Это называется «откат 50%+», нашли чем хвалиться.
У Yandeкса откат? Смешно. Там зарпалата инженера разработчика системы охлаждения дата центров, которму продавали Matlab примерно такой же по размеру, как наш с ними контракт на моделирование охлаждения дата центра, ему откат брать себе дороже.
Мы же не Exponenta которая в МГТУ им. Баумана больше чем на $1 000 000 (Миллион, Карал, баксов!) Matlab продавала.
В посте нет полного понимания проблемы программирования технологическими процессами. Написание программного обеспечения для полевого уровня АСУ ТП отличается от обычного 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, но до сих пор используют.
Что-то вы путаете. Идеи и практики из мира ИТ — они как раз про понятность кода, и про то что код не должен зависеть от IDE.
Это как раз в IEC 61131-3 из пяти языков три графических, программы на которых без подходящей им IDE даже не посмотреть.
кстати, подумалось, что современный "ограниченный ИИ с распознавалкой рисунков" - дает возможность рисовать код напрямую в графике, с трансляцией в какой-надо-код. Человеку надо будет только нарисовать, указать - во что это счастье передать и проверить результат в железе (на стенде).
Просто смотреть на программу управления технологическим процессом, очень часто бесмысленно без хорошего знания самой промышленной технологии. Ну например мне бесмысленно смотреть на программу управления химической колонны крекинга, там нужно лет 5 посидеть в университете над формулами органической химии, что понять есть ошибка в пересчете температуры и показания датчика в парциальное давление газовой фракции или нет. Поэтому графические языки и пременяются, что химик технолог мог пальчиком по линии провести и увидеть, что у него уставка по температуре не срабатывает на низком давлении, при снижении расходи ингибитора. Хотя нас Си будет нормальный рабочий код,даже структурно красиво оформленный.
ООП в графических языках програмирования
https://habr.com/ru/articles/736320/comments/#comment_25566424
в то же время, существует подход, позволяющий получить результат(найти проблему) без 5 лет органической химии. Главное, не выходить за рамки безопасных режимов работы.
Будьте любезны пояснить, каким макаром связь температуры с давлением газа из термодинамики превратились у вас в органическую химию и чему такому нужно учиться озвученные пять лет, чтобы показания манометра прочитать? « химик технолог мог пальчиком по линии провести» - вот этому?
В термодинамике обычно используется идеальный газ. В нефтехимии, наверное, есть своя специфика.
да, там в колонне и реакции происходят, в т.ч. каталитические, и тепло-массо-обмен, и фазовые переходы иногда, как я понимаю.
Я не нефтехимик (просто маску нашел), но как раз сейчас пробую разобраться в оборудовании и процессах, в т.ч. фракционном дистилляторе и Thermo TPDRO.
Давно хотел понять, как (и почему) ректификационная колонна делает 96% спирт :-) Вроде бы, понял.
слово "крекинг" сразу же намекает, что химия внутри будет меняться в процессе. Идеальным газом тут не пахнет (причем сам запах, скорее всего, присутствует)
Про понятность графического кода: ООП в графических языках.
Что Вы скажете на такое решение кодогенерации уровня бинарной логики, в концепте основная идея - автоматизация труда разработчика?
Отсутствие системности в принятии в автоматизации начнет приводить к крупным промышленным катастрофам.
главное - чтобы не в масштабах земного шара. Региональные - человечество переживет (хотя возможно это будет как крушение бронзовой эпохи :) но тем не менее)
Подпишусь под каждым словом. АСУТП - это вам не в "умный дом" поиграться, тут одна ошибка может стоить многих жизней. В управлении конвейерами. В вентиляции. В системе орошения. (Не дай бог!)В пожаротушении...
Это не для банков утилитки кропать, здесь за каждой строчкой кода - чья-то жизнь.
А платят - да, маловато. Но мы работаем. Ведь если не мы- то кто?
Это не для банков утилитки кропать, здесь за каждой строчкой кода - чья-то жизнь.
Что есть "утилитки для банков"? Всякие мобильные клиенты? Так он к банку весьма опосредовано относятся. Там нет никакой логики - им предоставляются готовые REST API - "вызови вот это получишь вот то". А вся логика в конечном итоге реализуется на самом нижнем уровне (ядро банковской системы)
Про банк уже писал в комментариях тут - когда оказываешься на уровне ядра, то обнаруживаешь что и платформа специфическая (можно погуглить про IBM i, бывшая AS/400) и языки специализированные (тот же RPG - тут как-то про него была статейка) и требования весьма специфические по производительности, ресурсам (писал в коментариях примеры решаемых задач).
И, к примеру, час недоступности банка оценивается этак миллионов в 25 только прямых финансовых убытков, не считая репутационных, штрафав от регулятора (время недоступности нормируется минутами, дальше уже штрафы вплоть до лишения лицензии).
Я не хочу сказать, что где-то проще или сложнее. Просто везде есть своя специфика.
И в АСУТП далеко не всегда речь идет о жизнях (да, такое там тоже есть) и в финтехе далеко не везде мобильные утилитки и джава... У нас, кстати, большая часть разработчиков - достаточно солидные люди от 40-ка и старше (я пришел в 52, сейчас 58, есть и постарше). Т.е. к "хипстерам-смузихлебам" ну никак не отнести. И каждый приходящий первые три месяца только проходит обучение работы на платформе нашей. А "в силу" более-менее входит где-то через год. Когда осовит все тонкости и особенности платформы, нюансы языка, весь набор "неформальных требований к раазработке".
Да, тут намного лучше с деньгами. Но не легче ни разу. Просто так никто не заплатит - каждую копейку отработать надо.
Лично я считаю, что те шесть лет что работаю тут, дали мне не меньше полезного опыта в разработке (не в плане каких-то конкретных навыков, но в плане подхода), чем предыдущие годы в АСУТП.
Но мы работаем. Ведь если не мы- то кто?
вот с одной стороны понимаю какой классный лозунг, но с другой стороны точит мысль "а чем это отличается от разводки? если люди там такие уникальные - почему нет переманивания ?"
Думаю, как уже написАли выше - своя специфика... Кстати, переманивание в пределах отрасли - есть. А вот выход из АСУТП в, например, банковскую систему будет несколько болезненным, как мне кажется. Другая организация работы, взаимодействия и т.д. Нужно будет учиться. Именно командной работе, например, и т.д.
А вот выход из АСУТП в, например, банковскую систему будет несколько болезненным, как мне кажется.
Лично для меня - да, была боль. Но основная боль была связана прежде всего с освоением новой платформы IBM i которая практически ничего общего с привычными виндой или линуксом не имеет. Там совершенно иные принципы построения самой системы (она "объектная" - "все есть объект"), там своя файловая система - там есть объект типа *FILE, но это вполне конкретный тип объекта, а не вообще все, что на диске лежит. Там нет GUI, вся работа в текстовом терминале, общения с системой посредством команд языка CL (референс по командам - 2300 страниц в pdf) плюс на нем же еще и программы писать можно (к тому же еще и компилируемые, с типизацией переменных, не скрипты) и можно расширять язык путем создания собственных команд.
Вторая боль - освоение нового языка - RPG. Специализированный язык для коммерческих расчетов с кучей тонкостей - работа с форматами даты и времени (которых там поддерживается очень много), работа с БД как нативными средствами языка (тут помогло то, что когда-то был опыт работы с БД через библиотеку Paradox Engine), так и встроенным в код SQL.
Куча новых сущностей таких как "группы активации", наличие разных моделей памяти, даже указатели разные могут быть - 64-битные или 128-битные...
Третья боль - осознание совершенно другой концепции разработки. В АСУТП привык что все ресурсы машины мои и заботится нужно только о скорости. А тут... Оно хоть и работает на 120-ядреной процессорной сборке по 8 потоков на ядро и оперативной памяти 12Тб, но одновременно на сервере крутится под 10 000 процессов. И каждая поставка проходит через нагрузочное тестирование где тебе могут сказать что "слишком много ресурсов на себе берешь". Т.е. здесь не понятия "абсолютной скорости", есть понятия "отведенное временное окно" в которое нужно уложиться и "допустимая нагрузка на процессор" в которую тое нужно укладываться.
Т.е. чуть больше вещей, о которых приходится думать при разработке.
На фоне всего это все остальное было уже так, семечки. В команде я и в АСУТП работал (т.к. железо сами разрабатывали, то и схемотехники были и программисты контроллеров и программисты верхнего уровня). Тем более, что "командных" задач у нас почти не бывает - каждую конкретную задачу делает один человек (два - аналитик + разработчик). Ну разве что ты не годами одно и то же пилишь выкатывая новые версии, а сегодня одно, завтра другое... Но на фоне всего вышесказанного это уже не боль :-)
Ну требования к коду выше - много "нефункциональных требований", жесткий кодревью. Но все это как-то легко уже зашло. Самое тяжелое было въехать в новую платформу и языки.
Третья боль - осознание совершенно другой концепции разработки. В АСУТП привык что все ресурсы машины мои и заботится нужно только о скорости.
А что насчёт watchdog? Любая операция должна выполняться быстро и не расходовать лишней памяти. Это вам не Ява/Шарп с, практически, неограниченными ресурсами и сборщиком мусора.
В команде я и в АСУТП работал (т.к. железо сами разрабатывали, то и схемотехники были и программисты контроллеров и программисты верхнего уровня). Тем более, что "командных" задач у нас почти не бывает - каждую конкретную задачу делает один человек (два - аналитик + разработчик).
Вы же не сферического коня в вакууме разрабатываете. Есть поставленные задачи, внутренний заказчик, жалобы на местах - здравствуй, командная работа.
А что насчёт watchdog? Любая операция должна выполняться быстро и не расходовать лишней памяти. Это вам не Ява/Шарп с, практически, неограниченными ресурсами и сборщиком мусора.
Это все верно. Я о том, что в АСУТП (там, где я работал по крайней мере) у вас фактически нет конкурирующих процессов. Т.е. "не расходовать лишней памяти" понятие достаточно условное. И первоочередным все-таки будет максимальная производительность.
А там где работаю сейчас память можно считать неограниченной - одной оперативки на сервере 12Тб И или только физическая оперативная память, на считая виртуальной. Да, там есть ограничение на 16Мб памяти на задание (job) но это касается статического выделения. Динамически же можно выделить куда больше (в модель памяти SINGLE LEVEL 16Мб одним куском, в TERASPACE - 2Гб одним куском).
Тоже самое касается ресурсов процессора - одно дело когда процессор работает только на вашу задачу и вы можете загружать его как считаете нужным и совсем другое, когда ваша задача всего лишь одна из десятков тысяч работающих одновременно и если вы начнете сильно грузить процессор, остальные начнут тормозить и это отрицательно скажется на работе всей системы в целом (нехорошие прецеденты были когда в период пиковой нагрузки одно из заданий пришлось останавливать руками т.к. оно стало тормозить остальные).
Т.е. тут приходится привыкать думать несколько иначе - всегда держать в голове понятия "выделенного временного окна" и "предельного уровня затрачиваемых ресурсов".
Причем, ресурсы процессора - это самое дорогое. Дисковые ресурсы - самое дешёвое.
Тоже самое касается ресурсов процессора - одно дело когда процессор работает только на вашу задачу и вы можете загружать его как считаете нужным и совсем другое, когда ваша задача всего лишь одна из десятков тысяч работающих одновременно и если вы начнете сильно грузить процессор, остальные начнут тормозить
Если вы увлечётесь на контроллере, то превысите время цикла. Поэтому, любое тяжеловесное действие надо дробить на небольшие части, каждую из которых необходимо выполнить за один цикл.
Достаточно просто дергать watchdog внутри цикла. Не на каждом обороте, но раз в нужное количество.
С точки зрения эффективности это куда лучше.
Аналогично было на Win3.11 - если вы уходите в долгий цикл, стстему фризит конкретно. Нужно дергать периодически функцию обработки сообщений.
В win9x на старых процессорах похожего (хоть и не на 100%) результата можно было добиться если внутри функции с основным циклом потока с высоким приоритетом не вызывать что-то, отдающее управление планировщику (Sleep, WaitForSingleObject/WaitForMultipleObjects..)
Так что это проблема не столько контроллеров или АСУТП, сколько подходов к разработке (как сейчас модно говорить, "паттернов", хоть и не люблю злоупотребления англицизмами без нужды).
На любой платформе приходится держать в голове много особенностей чтобы не получилась "фигня какая-то".
А вот выход из АСУТП в, например, банковскую систему будет несколько болезненным, как мне кажется.
Болезненно трудным. Всем опыт подавай. А кому в банке нужен опыт с АСУ ТП?
Болезненно трудным. Всем опыт подавай. А кому в банке нужен опыт с АСУ ТП?
Очень сильно зависит от. Я уже писал, что когда речь идет о каки-то мобильных клиентах, то от банка там будет только специфический набор REST API которые нужно дергать в разных ситуациях. И это не столько про банк, сколько про обычную мобильную разработку.
А вот если речь идет о серверах где крутится вся бизнес-логика, то там может быть и платформа специфическая и языки свои. И найти человека "с опытом" для этих языков и платформы "на улице" нереально - по нашим условиям (IBM i & RPG) таких по стране пара сотен наберется, вряд ли сильно больше.
И тут ищут именно разработчика, желательно с опытом разработки. Разработчик - это ведь не про язык, это про умение выбрать наиболее оптимальную стратегию решения конкретной задачи. Про подходы. Про структуры данных и алгоритмы. Про умение "разбить большое и невозможное на последовательность малых и реализуемых". Про умение алгоритмизировать задачу.
Т.е. когда говорят - "есть поток данных, есть черный ящик у которого на входе вот это, на выходе должно быть вот это, задача реализовать это ящик с таким набором граничных условий". Вот это - разработка. Конкретный язык, платформа - это всего лишь синтаксис который осваивается за несколько месяцев (у нас на обучение дается три месяца, разработчик с опытом справляется за полтора, максимум два).
Я вот в АСУТП много работа с многопоточной обработкой, обработкой данных в стиле "пришло по этому каналу, что-то делаем, отправляем в тот канал" - очень многое из подходов, шаблонов из той жизни нашло свое применений в текущих условиях. Где-то с каким-то коррективами, но вполне пригодилось.
А язык - это всего лишь набор слов. А "бизнес-логика" - это всего лишь правила трансформации данных, не более.
И тут ищут именно разработчика, желательно с опытом разработки.
С этим всё понятно. Проблема в том, что асушнике не желают видеть разработчика..
Что значит "не желают"? Техническое собеседование с командой и несколько правильных вопросов быстро все по местам расставляют.
Что значит "не желают"? Техническое собеседование с командой
Значит то, что на интервью даже не приглашают. "Нас впечатлил ваш опыт, но, мы предпочли другого/не знаем, как применить его в нашей компании".
Ну мне трудно судить - я не меняю работу каждые полгода.
У меня было так - проект загнулся "благодаря" смене руководства конторы под крышей которой мы работали (т.е. мы занимались разработкой, сборка железа была на их производственной базе, установка и последующее обслуживание в большей части их, где необходимо нас привлекали). Нам просто сказали "вы ребята крутые, сделали крутую штуку, мы сейчас ее продавать будем, но денег на разработку больше не дадим - хватит". А это означало сесть на голый оклад (там совсем копейки были т.к. основная часть шла в виде "ежемесячных премий").
Короче говоря, народ стал смотреть по сторонам. Я занимался поиском работы где-то 3-4 месяца. И что-то такое нашел даже. Какая-то мелкая контора писала плагины для системы архитектурного проектирования (подробности не помню уже) - С++ + Qt (в целом и то и другое для меня не было проблемной т.к. в проекте я занимался проектированием и разработкой "ПО верхнего уровня" - микроядро системы которое обеспечивало фильтрацию и маршрутизацию всех потоков данных, мониторинг состояния контроллеров верхнего уровня, реализацию отношения "многие-ко-многим" между контроллерами верхнего уровня и интерфейсными клиентами).
Новая работа была удаленной т.е. позволила бы мне остаться в той конторе (тупо в наглую там сидеть и получать з/п - увольнять нас было слишком дорого т.к. пришлось бы компенсации выплачивать - решили просто посадить на голый оклад - "сами уйдете").
Все уже порешили, тестовое сделал, им понравилось, дали доступы к репозиториям. И тут письмо из банка - "увидели ваше резюме, не хотите ли встретится поговорить". Я про банк вообще не думал (ну типа "счета-проводки - скучно все это"). Но решил просто ради любопытства сходить, "поводить жалом".
А надо сказать, что в банке том HR только отбирает резюме по формальным критериям и отдает их в команду. А там уже смотрят и говорят - "с этим хотим встретится". И встреча сразу с командой, с теми людьми, с кем потом работать. И без тестовых заданий, без олимпиадных задачек. Я рассказал что умею, чем занимался. Они рассказали чем они занимаются...
Спросили сколько денег хочется - сказал что есть уже договоренность примерно на такую сумму. Ответили "это реально".
И вышел я оттуда и понял что хочу тут работать. Просто люди понравились, интересно стало что там делают (со "счетами-проводками", кстати, не так много работаю, больше клиентские данные всякие).
И внезапно на следующий день письмо "вот вам анкета для СЭБ (Служба Экономической Безопасности) - надо заполнить и выслать". Как мне потом сказали, решение было моментальным - только я вышел и сразу "этого берем".
А дальше все быстро - безопасники пробили за пару дней, сходил еще к ним на собеседование (чисто формально, анкета прошла уже все проверки) и там уже "когда сможете выйти",
В целом считаю что повезло попасть в хорошее место. И по работе интересно и люди отличные и рост есть и по должности, и по деньгам (сейчас более чем втрое от того на что пришел). Ну и просто отношение нормальное - относятся как к ресурсу который надо эффективно использовать и сохранять (бонусы давать, з/п повышать чтобы налево не смотрел). Ну и все такое прочее.
тут одна ошибка может стоить многих жизней.
Не драматизируйте. Чаще всего это простой или выход из строя оборудования, что приносит неудобства разной степени тяжести (например, отсутствие воды или электричества), а также убытки на ремонт оборудования.
А платят - да, маловато. Но мы работаем. Ведь если не мы- то кто?
Кто? да хоть Пушкин..
У нас в Израиле автоматика - довольно узкая и не очень хорошо оплачиваемая ниша. Мне изрядно надоела, в первую очередь, нишевость, и я всячески пытаюсь из этой ниши вылезти.
В последнее время, мой подход таков: не хотите платить нормально - сношайтесь сами со своим добром, ищите джуниора задёшево и потом приходите переделывать :)
Пару лет назад видел SCADA сделанную на Microsoft Excel 97 на деревообрабатывающем комбинате. Ее функционал их устраивает за исключением поставленного пароля и не возможности внесения некоторых коррекций в формулу расчета
Excel-97 использовал короткий ключ шифрования, для него уже много лет есть утилиты практически мгновенно вытаскивающие пароль.
Вы отчет ВНИИА им. Духова читали на ваш симинтек?) Я люблю симинтек, и пользуюсь им (увы), я даже хорошо знаком человеком, который его создал (Козлов О.С.), но это же ад, просто ад
А где бы тоже почитать?
Я лично с тем кто проводил исследования SimInTech общался в ВИНИИА им. Духова. Вополне себе позитивное обещения, они сидели на дорогущем SCADE Esterel, от американской ANSYS. Они нам показали, как спокойно повторили, все что делали в SCADE Esterel, собрали сгенерировали Cи код скопилировали кода и даже сравнили его результат с скодом полученным из SADE Esterel. Заганали в свой контроллер и получили что код из SimInTech выполняется за 4 мс, а кода из SCADE 6 мс.
При это они даже ничего не спрашивали, не консультировались с нами, и даже не использовали специальный шаблон кода, который по правилам нужно формировать под конткретный контролле. То есть взяли версию с сайта попросили ключ и собрали сами под свой специфический контроллер программе. Если бы нас, как конслутатнотов пригласили, там бы вообще можно было сделать красиво.
Если у вас другие данные, то скорее всего их уже поправили заинтересованные в Esterel товарищи менегеры. У нас такое было с ЦАГИ в 2014 году, когда мы с инженерами повторили модель движенис самолета из Simulink в SimInTech, а потом почитали их отзыв что в SimInTech модель нельяз реализовать. Я звоню, спаршиваю:
-Как так невозожно?! Вы же саме ее в SimInTech сделали и сравнение тоже сделали?!
-Да, но начальство, ему позволнили и сказали, что вам надо ободрать, а мы люди подневольные, извини.
Вот пример с сверхззвковой ракетой.
У меня только такой слайд есть:
Все решил рынок. Рынок привел в АСУ ТП тех, кто там готов работать за те деньги, которые там готовы платить и использовать те инструменты, которые там есть. Всех, кроме отдельных энтузиастов, всё устраивает
Я учился в универе на АСУТП, но я миновал данный этап, увлекшись на последних курсах микроэлектроникой и программированием микроконтроллеров/DSP. На них ушло около 8 лет. Сейчас успешно вроде-бы вкатился в С++ (последние стандарты) и программирование под десктопы.
Все что вы написали чистая правда, теперь вспоминаю нашу действительность разработки на "железе" как страшный сон - только как хобби и не более того.
зарплаты, нередко ужасная культура разработки, местами озлобленное сообщество
Первого пункта достаточно, а остальное из него просто вытекает.
> у них во-первых просто нет необходимого багажа знаний именно по разработке ПО (и, например, понимания, почему необходима и какой должна быть грамотно сделанная архитектура программы, владения хорошими практиками разработки сложных программных систем
embedded-программирование это вообще самое сложное что бывает в разработке sw + одновременно самое простое, т.к. системы бывают разного уровня сложности, назначения и важности, поэтому супер трудно говорить сразу обо всем, эта тема знакома, т.к. занимаюсь примерно этим достаточно долго, привел бы такой пример - математика, это просто или сложно, очевидно зависит от уровня, и конечно не сводится к таблице умножения
Да ну в смысле. Задачи очень разные бывают, одно дело сделать девайс с каким нибудь тач экраном чтоб там плавно менюшки листались и совсем другое скоростной ШИМ контроллер, которому действительно каждый такт на счету, а совсем третье сделать прецизионный измеритель физ. величин. Для всех этих случаев нужен софт, только требования к нему могут быть совершенно разные
Самое интересное, что не только из него. Там своя атмосфера, так сказать.
Люди, которые в капиталистическом мире могут работать почти забесплатно, достаточно специфические. Тем более, что сейчас деньги — это мерило статуса. Вы, чтобы осознавать свой высокий статус специалиста, должны получать большую зарплату (дома можете её хоть сжигать).
Люди, которые в капиталистическом мире могут работать почти за бесплатно
Нормальные это люди. Может у них другого выходя нет? Хорошо быть молодым, сильным, целеустремлённым, необременённым долгами и обязательствами. И ведь у капиталиста мерило успеха те же деньги. А если он их раздаст в качестве зарплаты? И вот куда бедному крестьянину податься? (с)
И ведь у капиталиста мерило успеха те же деньги.
Это правящий класс, именно он и транслирует свои ценности на общество.
И вот куда бедному крестьянину податься?
Для начала снять розовые очки, пока их не разбили.
Изучать марксизм-ленинизм, устраивать профсоюзы, забастовки, стачки и т.д., и т.п.
Или идти в банк, чтобы уронить предложение на рынке раб. силы.
А во-вторых, там есть своеобразная профдеформация, очень долгое время встраиваемые системы были очень ограничены в вычислительных возможностях, нужно было экономить каждый байт и каждый такт, и в то же время по функционалу довольно они были относительно простые. Сейчас времена поменялись - у современных чипов даже стоящих копейки ТТХ весьма достойные, и в большинстве случаев уже нет нужды экономить каждый байт и каждый такт, зато важны читаемость, поддерживаемость и качество кода
Одно другого не исключает. Даже на современных чипах не стоит разбазаривать ни память, ни производительность (сторожевой таймер никто не отменял).
Ох... Как Вас понимаю...
Большую часть жизни отдал разработке системы мониторинга инженерного оборудования зданий. Применялось главным образом в ЖКХ - т.н. системы ЛДСС (лифтовая диспетчерская связь и сигнализация).
Нас была небольшая группа энтузиастов (в разработке в разные годы было задействовано 4-6 человек - это на все). Начинали году... в 93-м, по-моему. Когда никаких аналогов в тране не было вообще, а на диспетчерских стояли "шкафы" ПД-32 с лампочками и кнопочками и толстым пучком провдов (от каждой лампочки к каждому устройству отдельная пара шла). Т.е. с голой идеи. Вообще с ничего. Сами архитектуру придумывали, сами контроллеры проектировали и программировали (первые были на 8080), сами протоколы обмена (тогда еще все было на RS-485), пользовательский интерфейс, принципы формализации описания разных типов устройств...
Еще потом приходилось потенциальных клиентов уговаривать поставить систему - им "и так все хорошо".
Ладно хоть была "подпорка" - одна контора, которая лифты обслуживала - у них кой-какая база производственная была, монтажники ну и обслуживанием потом занимались...
Но развились как-то. Последняя версия системы уже вполне современная была - RS-485 остался на местных линиях. Между УСО (устройство сопряжения с объектом) и IP-шлюзом ("концентратор" к которому несколько ближайших УСО подключалось). Дальше уже UDP.
В центре всего - "микроядро". С одной стороны к нему по UDP IP-шлюзы, с другой, по TCP, интерфейсные клиенты (разного типа - диспетчер, администратор, аварийная бригада и т.п.). Ядро выполняло роль связки "многие-ко-многим", маршрутизатора, фильтра, монитора состояния IP-шлюзов и т.п. Контроллеры уже все модульные были, в основе STM32.
Денег, конечно, там немного было... Но... за идею работали - это же свое, выстраданое.
А потом в конторе руководство поменялось. Пришли "эффективные менеджеры". И сказали - "вы хорошую систему сделали, молодцы, теперь мы ее продавать будем, а дальнейшая разработка больше не нужна". Вот и сказке конец...
Короче, все разбежались. Сам теперь в банке (на удивление, ряд вещей, которые понял и освоил там, пригодились и тут, не в прямом смысле, но принципы, подходы...).
Спустя пять лет звонит директор бывший - "ай беда-беда, там проблемы какие-то, надо бы посмотреть, мы бы заплатили...". Я еще удивился - пять лет проработало вообще без никакой поддержки и сопровождения... Естественно, послал подальше - нет у меня времени уже вспоминать что там и как. Да и денег таких, за которые сейчас работаю у них нет...
Такая вот грустная история... Но не жалею ничуть. Весело было, увлекательно. Да и опыта приобрел немало на этой теме.
В этом наша основная проблема. Дефективные менегеры учатся у западных вендоров "продавать", а не разрабатывать, а инженегры считают продаванов справедливо дебилами. В итоге менегеры ни в зуб ногой в разработке и не могут построить полный цикл от разработки до продавать и рвать рынок. А ижненегры утекают в найм, туда где больше платят. Хотя по сути инженегр+продаван это и есть сикорский, боинг, форд и хьюлет с паккардом.
Катался я тут на яхте не так давно с инженегром из Yandex. Он мне сетовал за жизнь, что вот все есть, как специалист состоялся, но потолок, а хочется своего бизнеса. И даже вспоминает как будучи выпускником на коленке писал обработчик данных для эксперементов в металургии. Сейчас бы из этого можно было сделать узкоспециализированный инструмент и продавать по миру, но зарплата прогером на дядю пересилила тягу к инженерии.
Нет не совсем так. Продакт менегер, это кодер+продаван это другое, когда хозяину надоело самому вапаривать прогу и пинать кодеров, он повышает зарплату самому коммуникабельному из быдлокодеров и говорит, ты вот тебе палка - кодеров по голове бить и контакты заказчиков возми в службе поддержки, что бы они на тебя говно лили, ты теперь продакт менегер.
инженегр+продаван это другое. Например случае описанном выше, когда дефективные менагеры разработчиков железа турнули, инженер-продван не в другую контору ушел бы кодить на дядю, а свою контору откроет и бывших хозяев натянет на когалыгу. Поскольку у него и знания по железу и умение его делать.
Я тоже в прошлом АСУшник. Тоже спустя лет 8 с обьекта позвонили, типа что-то у них сломалось и надо бы помочь. На что было сказано: ребята, сорян, у меня nda по моим прошлым объектам, интеллектуальная собственность не моя, вам надо связаться с теми, с кем у вас договор заключен был на поставку и монтаж с наладкой. На самом деле я уже не хотел этим заниматься. Вспоминать, что там сделано и что можно сделать. На удивление мне с конторы позвонили. И мы не сошлись в сумме. Странно, правда? ?
В широко распространённом на данный момент ИТ (программировании облачных и web решений, разработке коробочных продуктов) один раз разработанный продукт может продаваться сильно более одного раза. Соответственно, маржинальность продукта (по крайней мере теоретически :) - достаточно высокая.
Поэтому есть возможность платить разработчикам достаточно много. Это тянет за собой рост зарплат и остальных программистов (работодателям, дабы найти приемлемого кандидата приходится поднимать ставку).
В остальных областях (включая АСУ ТП) ситуация остаётся классическая. Один раз сделали - один раз продали.
Продали контроллеры/SCADA'у в другое здание - их опять надо с нуля программировать. (Наработки, конечно, помогают, но программировать и отлаживать надо каждый раз).
Продать мозги инженера одну разработку много раз подряд - не получается. А трудоёмкость - ни разу не малая. Что делать - вопрос открытый.
PS. Такая маленькая фирма,как Bosch, в новой линейки своих контроллеров (X) сделала возможным программирование этих контроллеров не только на АСУ ТПшных языках, но и на обычных языках программирования...
Далеко не всегда. Есть АСУТП проекты, суть которых в серийном производстве систем автоматики - например, какой-нибудь шкаф управления замерной установкой с ПЛК, модулями ввода/вывода и панелью оператора внутри, который из года в год штампуют партиями по много сотен штук
Нюанс АСУ ТП в том, что нет такой вещи, как copy/paste. Какой-то компонент сняли с производства и перестали поставлять - приходится искать, чем заменить. А там может оказаться НО контакт вместо НЗ, например. И вот у вас появилась ещё одна ревизия серийного изделия.
Есть АСУТП проекты, суть которых в серийном производстве систем автоматики - например, какой-нибудь шкаф управления замерной установкой с ПЛК, модулями ввода/вывода и панелью оператора внутри, который из года в год штампуют партиями по много сотен штук,
Есть и более крупные проекты где не пара шкафов, десяток датчиков и сотня тэгов. Потом нормальная фирма занимающаяся разработкой и пуско-наладкой не делает проекты с нуля, имеет свои заготовки проектов, алгоритмов, HMI мнемосхем, мнемосимволов.
Согласен с автором в первой части статьи, но резюме странное. В основном достаточное финансирование есть только в крупных и средних проектах в нефтянке, химии, энергетике, а это объекты КИИ о каком IOT может идти речь не понятно.
Это тянет за собой рост зарплат и остальных программистов
(работодателям, дабы найти приемлемого кандидата приходится поднимать
ставку).
Короче, рынок опять не вывозит стратегически важные отрасли, такие как АСУ ТП. Ничего нового.
Нет, не следует. Посмотрите, скажем, на зарплаты школьных учителей, которые определяют какая будет рабочая сила через 20 лет. Отрасль, очевидно, стратегически важная, если государство собирается жить несколько дольше ближайших 2-3 десятков лет. И что?
В современном мире наоборот, чем меньше человек делает полезного для общества, тем больше он получает. А если он ещё и вредит... :-)
А причём здесь вообще школьные учителя?
кстати - учителя отличная аналогия АСУ ТП.
Бюджетники вне рынка.
ну да, они наверно паек получают от государства, поэтому не в курсе рыночных цен. (сарказм)
Там такой же рынок труда, как и везде - просто рынок картельный : школы держат зп учителей на одинаковом уровне, и это читается нормальным. Переходы учителей между школами затруднены.
Специалистов базового уровня до сих пор много выпускается педУнами и педИнами, поэтому рынок труда перенасыщен младшими специалистами (и они в итоге работают не по специальности).
Традиции круговой поруки.
Есть частные учебные заведения + немногие исключения из правил (но гораздо больше людей в этой профессии ИМХО работают репетиторами)
что еще ?
Я думаю - это дает достаточно много аналогий с АСУшниками (ок, у учителей - практически нет дальних командировок :D ) ...
И то, учителя всё-таки ухитряются и на этом рынке находить альтернативы, ну да вы сами их назвали – частные заведения и фриланс (репетиторство).
Ну видите, вы уже согласились, что там рынок. У АСУТПшников точно также есть теоретическая возможность перейти на JS и перетаскивать JSON'ы. Всё абсолютно аналогично.
Знаю множество людей, которые не верят, что IT-шники получают 200-300к.
Я ИТшник и не верю что ИТшники получают по 200-300к и хорошо знаю, что зп. 20-30тыр в норме вещей. Итшник ИТшнику - рознь.
Я ИТшник и не верю что ИТшники получают по 200-300к
Я ITшник. Не в Москве. Альфа-Банк, управление разработки центральных банковских систем (т.е. ядро АБС и то, что на серверах крутится). Не Москва. 100% удаленка уже более 3-х лет. Когда пришел в 17-м году на должность ведущего, было 60 на руки + бонусы + ДМС + НС (страховаие жизни и нетрудоспособности). Сейчас по должности главный разработчик. 200 на руки + бонусы (регулярные квартальные) + ДМС + НС.
Ну плюсом еще какие-то плюшки есть (типа свой коворкинг в Сочи оплата разных курсов, раз в год участие в профильной конференции на 100% за счет банка, еще что-то там такое...)
В 17-м году когда уходил из АСУТП - там было 30 на руки с перспективой что будет еще меньше. Да, было интересно, да, было жалко бросать т.к. много сил вложено туда было. Но устал.
В ьанке поначалу (где-то первые полгода) было очень тяжело. Потом местами скучновато т.к. много рутинных задач (ну типа "неопытный"). Пришлось проявлять "проактивность", доказывать что могу больше. Сейчас рутины мало - тут хорошо то, что тебя стараются использовать эффективно - загружать тем, с чем не каждый справится. В результате 90% задач реально интересные и нестандартные.
При этом скажу, что понимаю и уважаю тех, кто работает "от души" за небольшие деньги просто потому что считает это "своим делом"
"Выжать" ресурс по-максимуму
Какие предприятия строить кроме газа/нефти?
Микроэлектронику?
А куда эту микроэлетронику продавать?
Кто ее купит?
Тут была на хабре новость про отечественное оптоволокно.
Так его теперь некуда продавать(кроме 2 стран).
Мы же про Россию, верно?
Мы практически про все капиталистические страны.
А причём здесь вообще школьные учителя? Речь шла о рынке. Бюджетники вне рынка.
Внутри, просто наниматель — монополист, точно также срезающий косты на раб. силе. У нас капитализм, если вы не знали. Да, какие-то рудименты совка остались, но их всё меньше и меньше.
Совершенно верно, разница между совком и гос. капом только в постановке цели. В гос. капе цель — прибыль нанимателя.
В каждом уставном документе, любого коммерческого предприятия, первым пунктом идёт статья - цели предприятия. В это пункте на первом месте стоит - получение прибыли. Дальше должна идти цитата Томаса Джозефа Даннинга, но за неё - расстрел на месте :)
А вы попробуйте сейчас другую цель указать, например, некоммерческое общество. Сильно удивитесь, что это трудно.
Жена пыталась, на третей попытке плюнули.
Да нет никакого расстрела. У меня сейчас карма +27, а голосов 129 — сейчас красных и белых примерно поровну, поэтому мы можем не бояться слива.
Собственно вот за эти комменты с конкретно отрицательными голосами я ничего в карму не получил — кто хотел поставить мне минусы, тот давно их поставил.
Не совсем так. Предприятия были государственными, да. Но эти предприятия между собой за рабочую силу конкурировали.
Была даже биржа труда, мой батя с неё и попал на работу в 1975 году.
Возможно, из этого следует, что они не такие уж стратегически важные? :)
А футбол является стратегически важным?
Почему у футболистов такие высокие зарплаты?
Вы, возможно, хотели сказать, что у некоторых – весьма немногих, на самом деле, – самых популярных футболистов высокое денежное вознаграждение?
У каких инженеров АСУ вы найдете такую же зарплату как у звезд футбола?
Ответ — никаких.
Все равно звезда АСУ не получит столько сколько звезда футбола.
Такова специфика деятельности, единицы получают всё, остальные – хорошо если хоть что-то.
Так почему они футболисты столько получают?
Значит кто то за это много платит.
Тогда на выходе мы получаем что в нынешней системе экономики, футбол цениться выше чем Инженер АСУ.
Значит футбол более стратегически важнее направление чем инженер АСУ.
Сравнивать подобные отрасли с тем же АСУ ТП – не очень-то логично.
Почему?))) Вполне логично.
Значит футбол более стратегически важнее направление чем инженер АСУ.
Ногомяч — это, во первых, шоу-бизнес. А в шоу-бизнесе очень быстрая оборачиваемость денег. Это не завод, который если начать строить прямо сейчас, то затраты отобьются лет через 10.
Ну так-то да.
Английский «Манчестер Сити» возглавил список самых доходных клубов мира. По итогам сезона-2020/2021 доход «горожан» составил 664,9 миллиона евро. Второе место занял мадридский «Реал» с выручкой в 644,9 миллиона евро. Тройку лидеров замкнула мюнхенская «Бавария» (611,4 миллиона евро).
Мы не сеем и не пашем. Прибыль наше всё. (сарказм)
Возможно, из этого следует, что они не такие уж стратегически важные? :)
А вы скажите сами: энергетика, водоснабжение, нефтедобыча, металлургия и т.д. - они стратегически важные или не очень?
1. В АСУ ТП полно продукции, которая продается серийно, да по высокой цене. А уж оборудование, в котором приборы АСУ ТП используются, порой настолько серьезное, дорогое и приносящее космическую прибыль (за счет которой между прочим держится вся экономика РФ, типа, нефтегаза), что IT-шка рядом не стоит по значимости.
2. Зарплата в рыночной экономике никогда не зависит от прибыли, а зависит она от того же рынка - рынка труда. У АСУ ТП рынок труда локальный, российский, малооплачиваемый. У IT-шки российский рынок труда находится в сильнейшей зависимости от международного рынка. Эта зависимость вызвана возможностью удаленной работы и легкой релокации за счет релевантного опыта для IT во всем мире. Правда влияние международного рынка труда постепенной снижается в РФ после начала определенных событий.
Вы посмотрите сколько стоит в каждом конкретном случае электронный документооборот именно частное внедрение.
То, что продают один раз.
И ведь платят.
По идее АСУ ближе к деньгам, чем "классическое ИТ", почему там мало денег платят я не очень понимаю.
5 лет назад пытался проконсультироваться в эмбеддед. Ничего сложного, просто час поговорить по Скайпу. Просто поговорить. Без гарантий, без решений, просто чуть вникнуть и высказать свое мнение, дать советы. Был готов заплатить за этот час авансом 100$. И консультироваться в будущем. Написал паре десятков специалистов. Ни один не согласился.
У них там нищенские зарплаты, да ?
В пересчёте на 160 рабочих часов в месяце у меня получается 16000$...
По идее АСУ ближе к деньгам, чем "классическое ИТ", почему там мало денег платят я не очень понимаю.
Потому что в интересах капиталиста платить раб. силе как можно меньше. Если рынок раб. силы позволяет установить зарплату в 0, так и будет. Абсолютно вне зависимости от прибыли предприятия.
Блин, вы же всю жизнь при капитализме живёте, а рассуждаете как замшелый совок из 70х.
У них там нищенские зарплаты, да ?
Там специфические люди, которые согласны на эти зарплаты при том, что всегда могут пойти в банк. Значит, им деньги не нужны. Вот вы это и выяснили.
Не нужно ещё забывать о когнитивных искажениях.
Я это включил в специфичность. Но да, конечно причин множество.
А меня в свое время еще и гордость за специальность была очень развита, на все предложения бросить эти ядерно-реакторыне расчетные программы и идти кодировать в торговле или там банках, я принципиально не велся, только хард кор, только ядерные реакторы и атомные подводные лодки. При этом для своих первых работодателей в 2000-х, я был меркантильной сволочью требующих денег постоянно и много. И сейчас таких людей которым идея важнее денег встречаю не редко в самых разных отраслях. Им бы еще деньги научится выколачивать из менегеров, но не учат этому в школах к сожалению.
Теперь все пойдут в банк который грабит людей, а производство разрабатывать не надо? Хорошо, что ваше время уходит.
/ Продать мозги инженера одну разработку много раз подряд - не получается.
не вполне согласен. там, где решение сильно привязано к условиям заказчика, типа складских конвейерных систем - да.
Там где есть повторяющиеся, более - менее одинаковые по функционалу решения (из того,что знаю, это например: системы управления на АЗС, с/х фермах, машинах в пищевой промышленности) можно делать "коробочный продукт" и зарабатывать на продаже копий, как в классическом ИТ.
Чем я сейчас и занимаюсь. Не с такими правда заработками, как в ИТ, это правда. Но мне это ближе.
ПЛК должен быть простым как топор и таким же надёжным. Не нравиться идея "конечного автомата" - отсутствия переполнения стека и отсутствие "нескучных обоев"? 24*7*365 работа таких устройств. Отказоустойчивые процессоры, качественные входы-выходы занимающие большую часть устройства. Вставшая колом технологическая линия, или всё производство - это "мелочи" по сравнению с отвалившимся Wi-Fi или утёкшим паролем от тиктока) Зарплаты в АСУ были копеечные ещё в "аналоговую" эпоху. Работает ведь? Не ломается? За что платить лишнее? Предлагаете разрушить парадигму - "надёжность прежде всего" ?
Отказоустойчивые процессоры, качественные входы-выходы занимающие большую часть устройства.
Это скорее обязательное условие для модулей ввода-вывода чем к управляющему устройству. К тому же можно сделать IOT в точно таком же, промышленном исполнении (IIOT)
В плк уже давно есть модульные системы. Ремонтопригодность и расширяемость выше, отказоустойчивость ниже. То что работает в "чистом цехе" отвалится в автомобиле или агрессивной среде с непредсказуемыми последствиями. Минимум итераций и соединений- максимум надёжности. В промэлектронике был момент когда вся бригада была на вызовах месяцами пока не занялись пропайкой "пистонов" межслойных соединений контроллеров из Пензы. Акустическое давление рядом с работающим станком - вибрации даже через пол передавались. Стоять рядом с станком и ждать когда залипнет выход - тащить в лабу - пропаивать? Одного спирта на отмывку лака литры ушли ), в брак процентов 30 попало. Эх времена были)
Ну вот лично мне за 10 лет ковыряния ПЛК не нравятся урезанные IDE кучи производителей, гды ты завязан только на реализованные ими блоки. Пример из классики — типа декларативные ЯП и императивные… Мне зачастую гораздо проще написать (или применить готовые) свои обработчики RS-485 для разных типов датчиков, 4...20 входов/выходов, чем юзать не пойми что "любезно" подсунутое мне производителем. Финансово тут есть вопросы — есть компании интеграторы — там тоже не во всех адекватные труду зарплаты, а есть компании пользователи — там вообще треш по уровню зп… Потому потихоньку под менторством родственника синьора учу джаву) Реально удобство IDE для джавы и IDE для пром программирования это небо и земля.
В одной игре за 2 года патчами "улучшающими производительность" превратить мой комп в тыкву ради удобства группы "разработчиков" - это одно дело. Перенести такую практику в мир автоматизации - уже другое. Можно встретить электрика в тёмном и не электрифицированном переулке и стать "героем" - инженером досрочно)
ЗП низкие. Если есть желание зарабатывать больше - лучше сменить профиль. Но сама профессия хорошая и самое главное нужная, хоть и не заметная).
ПЛК должен быть простым как топор и таким же надёжным. Не нравиться идея "конечного автомата" - отсутствия переполнения стека и отсутствие "нескучных обоев"? 24*7*365 работа таких устройств. Отказоустойчивые процессоры, качественные входы-выходы занимающие большую часть устройства.
Уже несколько лет работаю с Windows-контроллером (Beckhoff) и, до сих пор, не могу понять и привыкнуть. Он может в синий экран упасть, стартует не моментально..
Не всё так просто на первый взгляд, как считает автор. Круто конечно на каком-нибудь Питоне писать проги для контроллеров, но нет, не получится натянуть сову на глобус. Слишком разные требования к системам из IT и из промышленности в плане ошибок. Одно дело подзавис сервер или на сайте окошко не там всплыло, другое дело - встала автоматическая линия, или на химзаводе приходится сливать колонну из-за остановки системы. Тут ущерб может отличаться не просто в разы - а на порядки.
Поэтому стандарт IEC 61131 - это не про то чтобы технологи и электрики программировали, а про то чтобы программа была проста настолько - насколько возможно, для избежания ошибок. И для удобства отладки. Поэтому надо программировать готовыми блоками из библиотек и не придумывать велосипеды.
И поэтому, если говорить про системы ПАЗ (противоаварийная защита) - там правила ещё жёстче. Можешь использовать только определённые блоки и всё. А чтобы не взорвалось ничего из-за неправильной программы. Цена ошибки слишком высока - поэтому вот так.
Даже в общепроме огромное количество не таких уж и опасных техпроцессов, не говоря уже про BMS. Но даже если говорить о крайностях (нефтехим, ПАЗ), то такие программы перед ПНР тщательно проверяются по этому не вижу проблемы провести точно такие же FAT испытания для Python-программы
FAT испытания затянуться могут если программа нестандартными блоками написана. А сроки то горят. И здесь как бы бету версию выкатить заказчику, как это делается сплошь и рядом в IT, не получится. Себе дороже будет если на производстве что-то пойдёт не так. Простой линии на автомобильном заводе стоит несколько лямов ))) Тут не забалуешь ))
Про нестандартные блоки вы хорошо подметили, только в АСУ ТП у каждой уважаемой компании свои "уникальные наработки блоков”, которые правда не прокомментированы, не версифицированы, но за то обвешаны Know-how protection, т.е. в реальности все это довольно сомнительного качества
И я даже не говорю про модульные блоки типа "конвейер, вентустнова, насосная станция" где действительно есть вариативность, речь про самые простые вещи типа клапана или мотора.
Уверен, если бы не IEC 61131 все "примитивы АСУ ТП" (датчик, мотор, клапан, и т.д) уже давно были бы “выгравированы в граните Github” под любой современный язык программирования и тогда можно было бы этим гордиться
Вы же знаете, что НАСА для шаттлов проводила испытания. При этом там было не то, чтобы много кода.
И при этом в НАСА была вторая независимая команда, проводящая испытания уже после первых испытаний.
И вы ведь знаете, что пару критичных ошибок они поймали ? Ошибок, которые могли привести к катастрофе.
И где гарантия, что их не больше ?
Никакие испытания не дают гарантии. Чем сложнее алгоритмы тем больше шанс незапланированного факапа.
После этого НАСА спонсировала Ivory Language и Copilot
https://github.com/GaloisInc/ivory
https://github.com/copilot-language/copilot
Круто конечно на каком-нибудь Питоне писать проги для контроллеров, но нет, не получится натянуть сову на глобус.
Зачем Питон? Есть масса других более приспособленных для этого языков, в конце-концов, можно и отраслевой сделать, если так нужно.
И поэтому, если говорить про системы ПАЗ (противоаварийная защита) - там правила ещё жёстче. Можешь использовать только определённые блоки и всё. А чтобы не взорвалось ничего из-за неправильной программы. Цена ошибки слишком высока - поэтому вот так.
Вы не поверите, но Питон работает именно так — программа пишется из блоков. А то, что вы хотите — это верификация, системы типов и т.д. Но вы от этого ещё дальше, чем от Питона.
Почему если цена ошибки чудовищна, так мало платят? вернее почему ктото вообще соглашается программировать такие линии?
Что мочь потом приходить в комментарии к статьям вроде этой и хлестать всех рукавами белого пальта :)
возможно - потому что "цена ошибки" платится не теми, кто писал к ним код ?
А вы часто, как сотрудник, платите за свои ошибки?
депремирование было, но сфера деятельности не опасна, так что штрафовали за мелкие касяки)
А вы часто, как сотрудник, платите за свои ошибки?
Тот кто платит за этот код, тоже редко платит за ошибки. За них платят простые работяги, часто очень страшную цену. И не надо говорить, что хозяева материально заинтересованы. Всегда можно срезать премию со всего коллектива, в назидание и компенсировать этим убытки.
Почему если цена ошибки чудовищна, так мало платят? вернее почему ктото вообще соглашается программировать такие линии?
Потому, что этот кто-то когда-то, по неосторожности, залез в эту нишу. Позже осознал, какую ошибку сделал. А потом пойди ещё вылези.
На самом деле выход из этого ада автоматизации есть. Даже с имеющимися возможностями программирования ПЛК от лидеров индустрии типа сименса, роквела и какого-нибудь омрона, можно продумывать архитектуру системы, внедрять модульный подход, разрабатывать программные интерфейсы к модулям, придерживаться функционального стиля даже в ладдере, уменьшать количество внутренних состояний, резать зависимости. По началу будет медленно, но в дальнейшем, когда на одном ПЛК допилите программный модуль до приличного состояния, а потом принесёте его в другой ПЛК и просто замените без правки кода, то почувствуете мощь такого подхода. Из-за того, что ПЛК позволяет программисту творить любую дичь, следование принятому стилю в коде является главным правилом. Основательно за этот подход топит в том числе автопром, типа Renault-Nissan, Siemens Automotive, CNOMO и т.п.
Там, где специалистов в принципе много не требуется, зарплаты низкие и возможности работать на заграничного заказчика практически нет, то же самое в любой отрасли. Либо никакого сообщества, либо довольно токсичные междусобойчики. В моей специальности, к примеру, в точности так.
Ну, как говорится, не все так однозначно. Вот взять "огромное количество сред разработки" - не такое и огромное, если сравнивать с количеством web-фрейворков на JS, где каждый день выходит новый, с очередной революционной (той или иной степени) идеей. Да и урезанность ЯП в этой сфере - вещь относительная, ведь задачи на нижнем уровне, как правило, весьма однотипные, а если данные ушли наверх, то там уже делай с ними что хочешь и с помощью чего хочешь (порой даже за гранью добра - однажды видел развесистую статистическую систему, написанную на Visual Basic, которую тащили на своем горбу с середины 90-х). Но зачастую этого и не требуется, т.к. большинство задач вполне решаются в рамках выбранной экосистемы того или иного производителя, собрав простыню из FBD на десяток-другой экранов. Отсутствие разделения труда - тоже спорно. К примеру, еще лет 20 назад, когда я занимался АСУ ТП, у нас была четкая дифференциация штанов: монтажники, электрики, электронщики, наладчики, КИПиА, проектировщики, и отдельной кастой шел отдел инженеров и прочих программистов. Возможно, что в небольших компаниях еще можно встретить "фулл-стек" мастеров от АСУТП - от монтажных работ по пояс в нечистотах, до разработки драйверов какого-нибудь эзотерического оборудования (впрочем, и тут, скорее всего, придется работать в поле, т.к. железо будет в работе и никто не даст его для экспериментов в стерильную лабораторию). Но сомневаюсь, что в этом случае будет высокая производительность труда. Впрочем, возможно, что мне просто повезло с компанией (а точнее с региональным подразделением, где у нас уже тогда была и удаленка, и относительно свободный график, и машина с водителем, и бильярдная со штангой, и даже чайник с безлимитными печенюшками и 3-х литровой банкой заварки - все те "блага", которые лишь потом стали "стандартом" отрасли). Тем не менее, проблема разделения и условий труда решаема в пределах той или иной организации, было бы желание. Тоже самое касается качества кода и его сопровождения. 20 лет назад уже использовалась CVS везде, где можно было экспортировать в текстовый вид, а где нельзя - просто бинарными файлами, что при наличии документации и качественного комментирования коммитов давало хоть какое-то версионирование и уверенность в завтрашнем дне. Особенную радость в то время вызвало появление Tortoise CVS и затем SVN - даже проектантов удалось перетащить c VSS. Да и связь между удаленными офисами кое-как наладили, пусть и с ограничениями того времени - модемы на отправку, спутник на прием, ну и более-менее быстрый (по меркам того времени) Интернет как бонус. Поэтому чисто там, где не мусорят культура разработки есть там, где ей уделяют должное внимание. Ну а что касается открытых решений, то тут не поспоришь - как вспомню написание OPC гейтвейта, без возможности купить стандарт и имея под рукой только тулзу для тестирования интерфейсов OPC, так аж нехорошо становится. Но нужно ли это производителям ? Вот это вопрос.
С АСУТП умеренно все в порядке в России, а вот автор, кажется, чего-то не смог и озвучил истерику.
Особенно забавляет мнение о необходимости IOT(ага, с запретом не только на интернет, а даже доступа в смежный сегмент сети ради диагностики, выбиваемый месяцами с привлечением СБ) в промышленности, да еще и на базе Linux(sic!), ну да, нас сейчас заставляют это делать - без проблем, но как же взвоют слесари КИП эксплуатации потом, когда все это надо будет обслуживать. Сложно даже представить.
PS. асушники и не являются программистами, мы инженеры КИПиА с расширенным функционалом, не более.
Кстати, минусы отлично демонстрируют доброжелательность коммунити "настоящих программистов" из комментария выше "какие зарплаты такое и коммунити", которыми наполнен хабр, более чем наглядно :) Довольно изящно получилось
Возможно, но так-то мне казалось, что хабр - не жалобная книга, и тем более не средство оскорбления представителей целой отрасли, что совсем не помешало автору накропать эмоциональный опус, причем короче обычного новостного поста, и набирать плюсы от "коммунити". Грустно это.
Я в целом считаю, что позиция я Д'Артаньян, а вы все того этого самого, не должна приветствоваться нигде, но погляди ж ты, не так.
Как известно откуда-то из седых веков, достойным ответом на музыкальное произведение может быть только другое музыкальное произведение. Напишете релевантный ответ без "озвучивания истерик", как у ТСа и переходов на личности, как в ваших комментариях — и наверняка получите плюсов побольше, чем выдали этой статье.
С одной стороны, а зачем плюсы? Предпочитаю читать, что видно по активности за 10 лет. Просто грустно видеть оскорбление профессии. А с другой стороны я также слышал, что не обязательно уметь готовить яичницу, чтобы оценить вкус. Вроде бы еще с лурка старого аналогия. Ну это в контексте аргументации класса "сперва добейся" как бы музыкального произведения.
Ну и в целом я написал ниже. Чистое АСУТП это до усрачки легко и просто, поэтому обязано оплачиваться меньше. Все справедливо. Кратко и точка(с)
:)
"Хабр - не жалобная книга" - это про то, что не надо сюда жаловаться о каком-то одном частном событии. А обсуждать проблемы системные - штука полезная, и вот этот пост именно про это.
За годы МЭК парадигмы, выросло целое поколение инженеров, которым пришлось освоить программирования, но унизительные зарплаты, статус неполноценности языков и сред разработки озлобило их, некоторые буквально ненавидят ИТ-шников.
Я прекрасно понимаю и разделяю эту боль
из комментария выше "какие зарплаты такое и коммунити"
Работать забесплатно на дядю могут позволить себе только достаточно специфические люди. Они разные, но отличаются от тех, кто вынужден сидеть в том же банке (см. коммент выше), т.к. «семье нужны деньги». Поэтому хотите вы или нет, но да, контингент у вас должен быть специфическим.
Не, там немного не так, забесплатно там не работают, там чудовищный скачок скорее, которого нет в обычном программировании. Вкратце джун асутп = меньше дворника, сеньор асутп = топ-миддл классики, да до сеньора классического варианта дорасти нет, но того и не требуется в отрасли, просто потому что тупо нет смысла - все настолько чудовищно примитивно, что сеньор рехнется от банальности задач.
И это главный аргумент, который автор не озвучил, асутп - это невероятно, до невозможности, ультимативно легко, поэтому и должно вознаграждаться меньше, вроде все справедливо.
просто потому что тупо нет смысла - все настолько чудовищно примитивно, что сеньор рехнется от банальности задач.
Значит там, скорее всего, не нужен человек. Но тут такая же последовательность, как с программистами «на Питоне»: дешёвый труд, много людей => нет необходимости автоматизировать (в Питоне это выглядит как ручное 100% покрытие кода тестами — в Хаскеле/F#/Kotlin/Swift/OCaml/SML для этого есть компилятор и типизация).
Вот народ рассказывает, что там всё должно быть очень просто, потому что должно быть сильно проверено и т.д. — из «большого программирования» есть такая мудрость, что эти проблемы часто решаются введением статической типизации, правильных абстракций и т.д.
Вполне возможно, что есть и сложные задачи, просто из-за того, что все привыкли решать простые, эти сложные задачи не видят.
асушники и не являются программистами, мы инженеры КИПиА с расширенным функционалом, не более.
Программирование – это просто умение читать и писать на формальных языках. Если умеете, то программист.
Ну нет же, таким определением и музыкант - программист, причем даже куда больший чем мы - ведь у него алфавит куда короче.
Имхо программист - человек основная функция которого - генерация безошибочного текста, который может быть исполнен тем или иным вычислительным устройством и все.
У нас не так, да ты тоже генерируешь текст, но программа -вторична, основная задача - сделать так, чтобы оборудование работало без нареканий, и если не удается сделать это текстом, берешь провода и слегка меняешь конфигурацию исполнительных механизмов.
Например рядовая задача - в зависимости от контекста выбрать импульсный или непрерывный метод управления запорной арматурой на конкретном объекте, тут нужна отвертка, цэшка и клеммы с проводами.
Поэтому - инженер КИПиА сначала, а программист уже потом. В этом ключевая разница. Именно это я имел в виду.
Все именно так. Там где можно сделать релейно, лучше релейно, где можно сократить программу, лучше сократить. Программа должна быть максимально простой и самое главное должна работать предсказуемо. Если АСУТПшную задачу делает программист, от этого только больше проблем становится, он старается сделать свою работу, предусмотреть разные события и как они будут развиваться, а этого чаще всего делать не стоит. К решению инженерных решений нужно подходить с инженерным мышлением а не программиста.
Кстати да у нас был вариант самонастраиващийся системы которая опрашивала в сети контроллеры управления определяля что кому отправлять и формировала списки обмена и все это автоматически. Но на объекте всю красоту отключили и прешели на ручное формирования списков обмена сигналам в видет таблиц для каждого контроллера. Душниля инженеры удушили душевные порывы программиста.
Поэтому - инженер КИПиА сначала, а программист уже потом.
Ну, то есть, обычный сплав двух профессий. Владеть желательно обеими на достойном уровне.
> Программирование – это просто умение читать и писать на формальных языках. Если умеете, то программист.
если читать + писать, но язык необязательно формальный - тогда просто писатель или поэт :)
Позволю себе не согласиться. Определение очень неполное.
Хорошее FSD (ТЗ) - это не псевдокод, но описание потоков данных и правил, воздействующих на данные на разных этапах.
Соответственно, программист (хотя мне больше нравится - разработчик) ни в коем случае не переводчик с псевдокода на формальный язык, но, скорее, сценарист, который по заданному сюжету пишет подробный сценарий - кто где стоял, куда пошел, как посмотрел, что сказал и т.д.
Вообще, разработка это прежде всего умение разделить "большое и невозможное" на последовательность "малых и реализуемых".
Задача разработчика заключается в том, что описанные в FSD потоки данных и правила реализовать на формальном языке так, чтобы программа работала максимально эффективно. А это не только синтаксис формального языка, но и алгоритмы, структуры данных, умелое использование специфики платформы, на которой будет работать программа, там, где это нужно, в какой-то степени понимание общей архитектуры и окружений в котором все это будет работать.
И опыт разработчика не в том, чтобы знать "как надо" (этому как раз учат на курсах, в вузе и т.п.), но знать "как не надо в данном конкретном случае" (т.е. из нескольких возможных вариантов, сразу откинуть те, которые не годятся в данных конкретных условиях).
Все это, конечно, всего лишь мое частное мнение, основанное на 30+ лет опыта в "коммерческой разработке". На "абсолютную истину в последней инстанции" или "носителя сакральных знаний" ни в коей степени не претендую.
> скорее, сценарист, который по заданному сюжету пишет подробный сценарий - кто где стоял, куда пошел, как посмотрел, что сказал и т.д.
хорошее сравнение, однако наличие грамотного ТЗ (заданный сюжет) это сравнительно простой случай, если говорить про embedded sw чем сложнее система, тем большую роль играет знание предметной области, можно сказать этого никогда не бывает слишком много, кроме того для разработчика embedded sw по нынешним временам желательно иметь два образования - типа ms electrical engineering + ms computer science, распространено например в us, не удивлюсь если со временем вообще будет отдельная специальность типа ms embedded systems,
> Вообще, разработка это прежде всего умение разделить "большое и невозможное" на последовательность "малых и реализуемых".
тоже верно, хотя вероятно справедливо для любой инженерной работы
хорошее сравнение, однако наличие грамотного ТЗ (заданный сюжет) это сравнительно простой случай, если говорить про embedded sw чем сложнее система, тем большую роль играет знание предметной области, можно сказать этого никогда не бывает слишком много
Я с вами полностью согласен. Знание предметной области требуется много где.
Вот сейчас в банке работаю. "Разработка центральных банковских систем" - это фактически ключевая бизнес-логика, которая крутится на серверах в рамках АБС (Автоматизированной Банковской Системы). И тоже приходится вникать в предметную область, без этого очень сложно писать качественный и эффективный код. Тут требования к эффективности весьма высокие т.к. система относится во-первых к mission critical (цена простоя невыносимо высока как деньгах, так и в рисках - время недоступности нормируется минутами, дальше санкции и штрафы от регулятора), во-вторых - это высоконагруженная система. Но есть своя специфика. Например, на сервере одновременно крутится тысячи процессов. И ваша задача одна из них. Т.е. вы не можете использовать все ресурсы сервера, но постоянно должны следить за тем, чтобы уложиться в отведенное вам "окно" как по времени выполнения, так и по потребляемым ресурсам.
И здесь очень много команд, каждая из которых занимается своим направлением. Есть команды системы расчетов, модуля пластиковых карт, тарифного модуля, лимитного модуля и т.д. и т.п. Я вот по большей части занимаюсь комплаенсом и клиентскими данными. И неизбежно приходится вникать в то, как оно устроено в целом. Иначе, увы, никак. Просто тупо писать код, не понимая что он делает - ну такое себе... Нет, начинающие разработчики так и работают на первых порах, но им никто и не даст сложных и ответственных задач. Поначалу занимаются рутинными, а дальше как себя покажет.
Плюс еще есть "непроектные", "технические" задачи. Но это уже "дело добровольное" - за это берется тот, кому это интересно и кто чувствует в себе силы этим заниматься (формально у нас допускается до 20% времени отводить на технические задачи, но, увы, не всегда получается...). Главным образом это касается разработки различного рода "низкоуровневых сервисов", которые потом будут использоваться много где. Тут уже надо вникать в особенности работы платформы (а у нас она ну очень специфическая) и ее потрохов - системные API и т.п.
А под грамотным ТЗ понимаю именно описания потоков данных и условий - что на входе, что на выходе. Наличие хорошего ТЗ очень повышает эффективность работы разработчика во-первых, а, во-вторых, это еще и документация по задаче. Через год (условно) к вам придут и скажут - "у нас тут бизнес-процесс поменялся (или регулятор новые требования ввел или законодательство поменялось) - нужно внести изменения". Без документации очень сложно бывает понять где именно что именно нужно поменять. Поэтому рабочий процесс уже выстроен примерно так - BRD (требования заказчика) -> ОТАР (архитектурное решение) -> FSD (ТЗ) -> разработка -> компонентное тестирование (на соответствие FSD) -> бизнес-тестирование (на соответствие BRD) -> нагрузочное, интеграционное тестирование (эффективность, интеграция в существующую систему, на копии промсреды) -> внедрение.
В целом не могу сказать что это проще или сложнее АСУТП. И там и там есть свои особенности.
интересно, спасибо за детали, подобными системами не занимался, как собственно и АСУТП, только сети и real time, embedded, последние 30+ лет в us
ps
представление о современной embedded system дает например высокопроизводительный router, это порядка сотни процессоров под управлением своих os, которые управляют несколькими сотнями IC, через которые идет основной поток пакетов из портов, при этом постоянно обмениваются сообщениями, служебными между собой, а также с другими router в сети (сетевые протоколы)
Ну я тоже не настоящий сварщик :-)
В АСУТП занимался "верхним уровнем". Сначала это был диспетчерский софт, который работает на компе и занимается "визуализацией" сообщений от устройств. Если просто, то приходит нечто типа такого: 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 интерфейсы для работы с очередью...
Короче говоря, банк - это сильно не только счета-проводки, но и очень много чего еще :-) И это "что-то еще" может быть весьма интересным с точки зрения разработки.
главное, судя по всему, Вам нравится, желаю успеха
Да, нравится.
В АСУТП нравились интересные задачи, требующие вдумчивого подхода и нестандартных решений. Держался там до последнего, не хотел уходить. Но пришлось. Близкого по теме ничего не подвернулось. Банки тогда в принципе не рассматривал т.к. не видел для себя интереса во всех этих "дебет-кредит, счета-проводки".
Позвали неожиданно - сами написали, пригласили на собеседование. Сходил, поговорил и понял вдруг что хочу тут работать.
И вот уже 6 лет и не жалею ничуть. Тот тоже есть интересные нестандартные вещи где нужно "мозг включать". Плюс платформа IBM i увлекла. Своей цельностью, продуманностью, огромным количеством предоставляемых возможностей.
Если на прошлой работе было просто удовольствие от самой работы, то тут и работа нравится и еще за это платят неплохо.
В АСУТП занимался «верхним уровнем». Сначала это был диспетчерский софт, который работает на компе и занимается «визуализацией» сообщений от устройств.…
Ну там логирование еще всякое, возможность послать команды какие-то и т.д. и т.п.… занимался т.н. "микроядром". Такой модуль, к которому подключаются с одной стороны IP-шлюзы (по UDP), с другой — интерфейсные клиенты (по TCP). Ядро — это и маршрутизатор… проектировать все самим приходилось — и протоколы обмена и классификацию устройств, архитектуру микроядра и системы на его основе… В этом тоже активно участвовал.
Такой себе АСУТПшный уровень… тут embedded + настоящий_программист — сам себе создал АСУТПшные шалабушки, сам их применил…
А был бы опыт только с DBшечками, CiCode, OPC, Modbus, 4-20 мА… хз пригодилось бы это банку…
Ну в 1993-м году такая реальность была... Что-то готовое было экзотикой - особого выбора не было, а цены запредельные по тем временам (а поскольку тему эту пропихивали с нуля - клиенту "и так хорошо" было, то пилотный объект вообще ставили за счет конторы с единственным условием что этот объект контора потом на обслуживание берет уже за деньги). Это потом тема раскрутилась, конкуренты появились, клиенты поняли что обслуживание такой системы дешевле выходит и деньги на установку отбиваются. А тут еще пошли домовые теплоэнергоконтроллеры (тогда с мобильным интернетом туго было и варианты были или самим по подвалам бегать показания снимать, или ставить нашу систему, подключать их и данные для коммерческого учета сами в диспетчерскую прилетают) - ТЭКОНы, ТСТ - стали их подключать в систему и получать с них "архивы" (хоть часовые, хоть суточные, хоть месячные (эти для учета обязательно, остальное по желанию). Плюс мгновенные значения в любой момент - давление ХВС, температура и давление ГВС, температура на входе и выходе отопления, напряжение в сети по каждой фазе, аварийные сигналы о выходе параметра за установленные границы...
Потом, правда, теплоконтроллеры отпали - мобильный инет стал доступен, контроллеры сразу снабжались GSM модемом и все эти данные уже отдельно собирались поставщиками ресурсов.
Первые контроллеры на 8080 делали :-) Потом, правда, шарахнулись в дургую сторону и попробовали Octagon MicroPC, но они оказались избыточными для наших задач и вернулись обратно, правда, уже на STM32 + MOXA (485 <-> UDP) на IP-шлюзах.
А когда появилось что-то готовое, у нас уже была куча своих наработок которые для нашей конкретной задачи были и дешевле и проще в применении к нашим задачам. Ну и UI уже был разработан свой - там же не технологи, бабушки сидят. Им надо чтобы просто и понятно - вот тебе список сообщений аварийных, вот тебе карта района (делал утилитку которая с серверов 2GIS брала тайлы, клеила карту в нужном масштабе...) с приявязкой и подсветкой всех объектов обслуживаемых - тырц по объекту и получи все что на нем стоит с текущим состоянием.
Т.е. уже смысла не было дергаться куда-то в сторону какого-нибудь Адвантека и иже с ним.
А был бы опыт только с DBшечками, CiCode, OPC, Modbus, 4-20 мА… хз пригодилось бы это банку…
Тут спорный вопрос, да... Может помогло то, что банк работает на платформе IBM i (AS/400 - ни на винду, ни на никсы не похожа вообще никак и ничем) и основной язык - RPG. Платформа специфическая, язык специализированный (и за пределами этой платформы его почти нет - были попытки сделать VisualRPG, но как-то все заглохло еще в начале нулевых).
Т.е. тут ищут просто людей с опытом разработки. Которые думают как разработчик - умеют задачу алгоритмизировать, умеют писать эффективный код и все такое вот... А потом 2-3 месяца обучение платформе, языку. Где-то через год получается уже такой себе крепкий мидл...
А "готовых" - на всю страну несколько сотен. Альфа, Райф, Росбанк из банков (ну может еще кто-то есть, не в курсе), может еще кто-то из крупных контор... Пара-тройка "вендоров" (BTC, Cinimex, OTP вроде бы...). Вот и все... Не так давно два разработчика ушло и... оп-па - они же но уже на аутстаффе работают от вендора...
Может быть все вот это сыграло...
.
Позволю себе не согласиться. Определение очень неполное.
Это же эпатаж был.
Подождите, АСУ это многогранная вещь — там может быть как и бэкенд написанный не на МЭК, так и просто система с HMI контроля и управления, в лучшем случае со SCADA, так и вообще железный ПАЗ на релюшках) Все эти уровни абстракций часть АСУ. И требования к персоналу по разработке и обслуживанию у них разные.
"Компании смогут изменить экономическую модель, что позволит платить Инженерам и Программистам АСУ ТП достойную заработную плату. "
Зачем платить? Зачем менять? Автор думает если АСУ - шные "рабы" будут привязаны к IIOT и кодить не на "61131", а на "условном Питоне" или любом другом "современном языке", то наступит рай.
У нас нет производства как такового - основного фактора приложения АСУ ТП, нет своей электроники с элементной базой, чтобы делать своё железо, те же контроллеры и промышленные ПК. Сам автор похоже потёрся немного с АСУ и ушёл/перешёл на javascript , может увидев ПЛК пару раз... И смотрит на эту сферу глазами условного "скадиста". Потому нужно начать с себя: Node Red c "малиной" ему в помощь. Чем не стартовая платформа для нового концепта в АСУ ТП?.. Сразу тебе и железо и софт со средой разработки...
Ну а пока и в рамках "61131" мало чего на 100% своего есть...
Зачем платить? Зачем менять? Автор думает если АСУ - шные "рабы" будут привязаны к IIOT и кодить не на "61131", а на "условном Питоне" или любом другом "современном языке", то наступит рай.
Насчет рая не знаю, но я искренне убежден, что это сильно пофиксит зарплаты в АСУ ТП. Потому что если в спеки начнут закладываться IIOT - в сфере начнут задерживаться ИТ-шники и со временем это изменит сам подход к реализации проектов и взаимодействию специалистов в лучшую сторону
Ну извините, но по моему опыту (пара крупных проектов в нефтехиме) в асу тп есть и обычные программисты на классических языках и вообще очень сильное разделение труда. При высокой стоимости проекта и ответственности в фирме интеграторе у спецов зп +- одинаковые, но! таких проектов единицы на нашу страну(если берем РФ), а это уже другая болячка экономическая… Не суть важно на каком железе будет крутиться ОСРВ, самая суть АСУ ТП и каким яп программироваться, важно чтобы это было экономически обоснованно. Когда законы не предполагают ответственности за выбор системы АСУ — типа вы что нибудь предложите, такой ад и будет по финансам в отрасли.
Думаю, это наиболее приближенный к реальности ответ, если рынок существует в таком плачевном состоянии, то это вопрос спроса. А спрос такой какой есть, потому что промышленность, главный заказчик этих разработок, в *опе. А остальное по большей части может решатся людьми, без привлечения специалистов, теми же технологами. Поэтому если спрос на специалистов и есть, то он очень нишевой.
Поэтому и решатся "проблемы АСУТП", могут только именно с этого конца(развития промышленности), а не какими-то мифическими "серебряными пулями" и и проектами.
А он (IIOT) там реально (кроме «привлечь ИТ-шников») так нужен? Когда уходил из автоматизации (простенькой, HVAC, ушёл из-за скуки, примитивная логика, которую нужно проверять по 100500 раз) 20 лет назад - в ходу были контроллеры, отделённые от полноценного HMI, надёжные, как танк (приезжаешь на обслуживание через пол года, разблокируешь панель, а там то подменю, в котором оставил в прошлый приезд). Сейчас слушаю друга, бьющегося с «модным» железом, где и логика и «красота» на одном ядре и «можно как человек писать сценарии на JS, а не вот эти ваши дедовские диаграмки рисовать» - те же скучные техпроцессы, но уже со всякими «нужно перезагрузить/подождать» и (самое отвратное) заведомым принятием такого качества за норму.
Цените что имеете. Вырастут зарплаты - набегут смузихлёбы со своими аджайлами и "софтскилами" как мерилом профессионализма.
Не вижу в этом ничего плохого, работал с такими ребятами - это всего безупречная реализация строго как прописал технолог в FDS. В отличии от "универсалов" которые всегда лучше технолога знают "как тут надо"
Скорее всего вы работали не с такими ребятами. Смузихлёбы водятся только там где много денег. Смузихлёб и "безупречная реализация" это ортогональные понятия. А неумение (и нежелание) делать всё как надо с лихвой компенсируется природным талантом красиво срать в уши почему всё сделано типа как надо или почему они ни в чём не виноваты.
Важность софтскиллов начинаешь понимать, когда в команду внезапно пробирается мудак, который своим мудачеством медленно отравляет работу всей команды.
Притом этот мудак и считает себя самым софтскиловым, а любой кто с ним не согласен по любому вопросу - просто токсичный токсик.
Обычно кто работает и реально выдаёт, тот заслуженное уважение и признание всей команды получает. Бывают люди "с тяжёлым характером", но, по мне, таких скорее редкость встретить чтобы делать из этого системную проблему.
Ну то есть описали типичного такого "софтскиллового" смузихлёба. Реально умеет мало, но гонору на миллион. А когда кто-то пытается прямо дать ему понять что он просто мудак, то ессно этот храбрец "токсичный токсик" который типа всех демотивирует. Эдакий офисно-айтишный woke'изм: "это не я мудак, это вы расисты".
А ещё бывает так, что подобный человек реально эффективно работает за двоих, а то и за троих... Только вот его подход к работе снижает работоспособность других 10-15 человек, так что проект в итоге от его участия проигрывает.
Это не в АСУ ТП зарплаты такие низкие, это просто в остальном IT они большие. Специалисты АСУ ТП получают ровно столько же, сколько и обычные инженеры на производстве.
IT — это же совсем другой мир, где балом правит масштабируемость решений, продажа услуг на международном рынке, многомиллиардные вливания $ от инвесторов, которые хотят создать второй google или как минимум в несколько раз преумножить свой капитал.
Это не в АСУ ТП зарплаты такие низкие, это просто в остальном IT они большие. Специалисты АСУ ТП получают ровно столько же, сколько и обычные инженеры на производстве
$80k в год?
Неужели я вас настолько разозлил, чтобы лезть в карму? Меня лишь смутила фраза, что в IT большие зарплаты. Они обычные. Для тех, кто работает на международном рынке. У моряков и пилотов, например, ситуация аналогичная.
Если брать инженеров в каком-нибудь, в каком-нибудь сименсе, то зп будет примерно равна зп местного прогера.
Работал в сфере АСУ ТП после универа с 2013. До конца 2014 года, пока курс рубля был стабилен, у большинства инжинеринговых компаний бизнес-модель была рассчитана на то чтобы победить в тендере, получить скидос у поставщика оборудования, накрутить на официальную цену оборудования процентов 10-15, а проект, разработка SCADA и по для ПЛК, ПНР - это побочные темы, чтобы обеспечить выполнение условий тендера. Обслуживание отдельная тема, но корни таких успешных организаций уходили к какому-нибудь относительно крупному завду. Отсюда зарплаты и отрицательный отбор, тут надо отдать должное, что в этой сфере, с учетом отрицательного отбора, совсем тупые тут надолго не задерживались, но и таланты быстро разбегались, либо переходили в IT, либо в уходили в филиал поставщиков оборудования и там из инженеров в скором времени уходили в продажники(т.к. там денег больше, а в этой сфере хороший инженер может продать почти что угодно). Ну а тем кто остался, с теми бюджетами, которые выделяли на проектирование, развиваться и раскрывать свой потенциал - это сложная задача, т.к. кушать хочется, семья растет, ипотека давит. Плюс сфера очень инертная. Если рынок It на ковид(а это читаю было значимое событие для мира IT) реагировал почти мгновенно(3-6 мес.), то АСУ ТП потребовалось после событий 2014 года 3-4 года, чтобы перестроить свои бизнес-модели и начать продавать проекты, прокраммы для ПЛК, скады, сопровождения, и зарплаты относительно 2014 года наконец-то выросли в 2-3 раза. Но тем не менее они не дотягивают до ИТ, но спецу в АСУ нужно знать болше, ответственность больше, более строгий распорядок(нет гибгих начал дня и печенек с кофе), нет удаленки, зато есть командировки. Так что с тем интеллектом, который требует АСУТП нужно быть реальным фанатом, чтобы оставаться в сфере.
спецу в АСУ нужно знать болше, ответственность больше, более строгий распорядок(нет гибгих начал дня и печенек с кофе), нет удаленки, зато есть командировки.
по идее - это должно было поднимать ЗП по сравнению с ИТ, в котором смузи и печеньки.
а получается наоборот.
Тут огромное поле для психологов и экономистов - почему переход профессии в специфические требования (командировки, сторгий распорядок) - при том, что вроде бы повышают ценность специалиста, однако не повышают ЗП а понижают.
У меня две гипотезы:
1) происходит вендор-лок специалиста. (или картельный сговор работодетелей) Меньше мобильности по компаниям, меньше вариативности по зп (нет своего FAANG) - меньше сама ЗП в итоге по профессии.
2) происходит отбор специалистов по психологическим критериям. Т.е. большая строгость и распорядок дня (держание в ежовых рукавицах) приводит к тому, что в профессии остаются конформисты, с выученной беспомощностью в сторону условий труда. Которые компенсируют свою беспомощность "там" - в огромную активность "тут" (т.е. в своей профессиональной деятельности - "а зато я классный специалист", "а зато мы там блоху подковывали", "а мы из кизяка и палок дворец сделали" и т.д.). А активные и хотящие в сторону условий труда - сбегают и по профессии не работают.
Возможно, там другие причины, возможно и эти тоже. Но я не думаю, что радикальные меры "всех расстрелять"\"отнять и поделить" или "мышки станьте ежиками" будут работать. Для исправления придется находить какие-то "дела малых шагов" и быть готовым, что даже если мы найдем причину, то лечения может и не быть .... (вспоминается реклама экспедиции на южный полюс в 1913 году)
На мой взгляд тут "рыночек решает" (хоть я и не сторонник столь примитивизированного подхода).
Что есть "зарплата" в коммерческой (не бюджетной) сфере? Фактически это какая-то часть от того, что компания заработала на продукте и чем она готова поделиться с тем, кто этот продукт создает (за вычетом всех расходов). Это очень примитивно, на пальцах, но пусть так.
Чем выше прибыль в какой-то области деятельности, тем больше у компании "свободных денег" из которых она готова "отстегнуть" разработчику продукта (тут еще будет играть жадность, "рыночный уровень з/п" и т.п., но в целом так).
Понятно, что АСУТП очень специфическая область - клиенты там - промышленные предприятия, у них в принципе меньше свободных денег, а в расходах на АСУТП значительную часть еще оборудование составляет... Вот и получается, что разработчику остается не так ужи много...
В вебразработке, финтехе денег крутится в принципе больше. И та часть, что идет на оплату ПО там выше. Т.к. какой-нибудь сайт - это просто ПО, а не ПО + куча дорогого железа как в АСУТП.
Когда я работал в этой области, мы все железо делали сами. Во-первых, так сложилось исторически - когда начинали, готового в доступности не было, а когда появилось, у нас уже были свои наработки, более доступные по ценам. Во-вторых, наши клиенты просто не могли себе позволить подход от "интеграторов" - "купите наши контроллеры, потом к ним купите наши устройства, потом ко всему этому купите наше ПО, которое останется только настроить и за все это мы хотим 100500 денег". Мы же ориентировались на те устройства, которые уже есть у заказчика. И в конечном итоге пришли к тому, что можем подключить все, что управляется электричеством по проводам. Естественно, что софт писался с учетом всего этого. Например, там мог быть датчик типа "сухой контакт", нормальное состояние замкнутое, аварийным считается ситуация, когда он непрерывно разомкнут более 30-ти секунд. Т.е. замкнут или мигает - норма. Все это легко описывалось и конфигурировалось в рамках разработанной нами формальной классификации типов устройств. Для более сложных типов разрабатывали "драйвера" - модули со стандартным интерфейсом, полностью включающие в себя всю специфику работы с устройством и подключающиеся "на горячую" без остановки системы. Т.е. сначала физически подключается устройство (условно - к клеммам на УСО), потом уже на пульте диспетчера - "новое устройство", где расположено, к какому УСО подключено, тип (из стандартных, или "новый, вот драйвер") и конфигурация. После этого устройство начинало работать в системе.
Такой подход позволил вполне сносно держаться на рынке даже в условиях сравнительно небогатых и очень прижимистых, зарегулированных разными "тарифными комиссиями" клиентов (ЖКХ, УК...)
что-то я подозреваю, что низкие зп - это до тех пор, пока пенсионеры и дешевые электрики\сантехники могут поддерживать всё это на ходу.
А потом - выход из строя техники ( авария, которую в отличии от предыдущих не удастся починить) поставит перед выбором: либо новые технологии (и другие деньги), либо "удобства во дворе" ...
Нет, там все хуже.
Во-первых, вам придется приспосабливаться к тому оборудованию, которое установил застройщик. И если застройщик поставил отечественные лифты с УБДЛ на борту, то или меняйте все лифты целиком, или ищите систему ЛДСС, которая может работать с УБДЛ. Не найдете - отключаете все лифты (по ПУБЭЛ) и пусть ходят пешком.
Во-вторых, вам никто не даст брать с квартиры по 5тр (условно) за лифт просто потому что у вас бродят идеи про "новые технологии" - есть тарифная комиссия которая устанавливает предельные расценки по всем позициям. А расценки таковы что... Порой вместо трех аварийных бригах денег хватает на содержание только одной.
И это реально проблема.
1) сделать свою "систему ЛДСС, которая работает с УБДЛ" - это имхо стандартная задача в ИТ.
2) а вот "есть тарифная комиссия которая устанавливает предельные расценки по всем позициям" - это да. Но когда лифты будут останавливаться пачками, то либо перейдут на "безлифтовые технологии физической культуры вертикального стадиона", либо сменят тарифы, либо придется субсидировать тарифы (по крайней мере на время перехода на новые рельсы) ...
В Казахстане, говорят, есть лифты с оплатой каждой поездки... Неужели энергетическая супердержава к этому идёт?
сделать свою "систему ЛДСС, которая работает с УБДЛ" - это имхо стандартная задача в ИТ.
Что мы и сделали. Были первыми. Потом еще появились.
Я просто к тому, что тут приходится все делать самому, а не через интегратора закупать готовые решения.
Но когда лифты будут останавливаться пачками, то либо перейдут на "безлифтовые технологии физической культуры вертикального стадиона", либо сменят тарифы, либо придется субсидировать тарифы (по крайней мере на время перехода на новые рельсы)
В стране розовых пони и белых единорогов, наверное, так и происходит. Но в реальном мире, увы... Мы тоже когда-то надеялись что так будет. Но так не стало. За те 25 лет, что я был в этой сфере.
хм.
Но ведь если у вас она уже есть - то теперь вы и сами можете быть таким интегратором ;)
Мы тоже когда-то надеялись что так будет. Но так не стало. За те 25 лет, что я был в этой сфере.
техника стареет медленно ? Кстати в новостройках-то уже новые лифты ставят, там уже новые технологии. Или нет ?
Но ведь если у вас она уже есть - то теперь вы и сами можете быть таким интегратором ;)
Фактически так и есть. Эти системы начинались как штучные, сейчас это уже вполне нормальное "коробочное" решение с комплектом документации.
И в целом средняя лифтообслуживающая организация вполне способна смонтировать систему своими силами
В нашем случае заказчик говорит сколько него чего есть, исходя из этого формируется комплект. А дальше - разместить контроллеры, прикрутить к УСО конечные устройства, соединить УСО с 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-шлюза поперли дубли. Т.е. он фигачит один и тот же пакет не обращая внимания на квитки. А надо понимать, что приемник и передатчик на шлюзе - физически разные модули. Т.е. передатчик работает, а приемник гавкнулся (реально было пару раз). И он квитков не видит... Вот такой ситуацию надо распознать и сформировать на соотв. клиент аварийное сообщение с нужным кодом - "с такого-то шлюза дубли идут, возможен выход из строя приемника".
Ну и там еще много всякого веселого было... Шлюз не отвечает (нет связи). Посылаем сообщение. Потом вдруг проснулся... Опять посылаем сообщение...
я на Ютубе заглядываю в блог мастера по лифтам, очень интересно. Я с 3х лет по лифтовым шастаю, (с бабушкой ходил, оставить меня некому было).
Названий не знаю, но когда в 20 летнем возрасте мы лифтовые использовали для протяжки П-296 для домашней сети (пока не запретили), с удивлением вспомнил, что нужно сделать, чтобы лифт по этажам перемещать или двери открыть закрыть (пробовать не стал, так что не знаю, полные у меня знания, или нет).
А сейчас лифтов тех давно уж нигде нет, наверное...
А сейчас лифтов тех давно уж нигде нет, наверное...
Да черт его знает... В какие-то годы по всей стране была федеральная программа по замене старых лифтов.
Там и с новыми хватает проблем... Построят новостройку, поставят лифт... А потом дом дает усадку и шахта уходит от вертикали... Лифт начинает, как говорили наши монтажники, "боком ходить". И при этом тросом "пилит" шкив - приходится раз в пару месяцев менять шкивы.
Иногда направляющие пилит (вроде бы в Алых Парусах когда лифт упал проблема была в этом - противовес с направляющих сошел и по кабине ударил, подробностей не помню уже сейчас).
Но это все чисто механические проблемы, на АУТПШные...
по идее - это должно было поднимать ЗП по сравнению с ИТ, в котором смузи и печеньки.
а получается наоборот.
Потому что шальные деньги QE и ZIPR попёрли в "интернет-магазины" и прочие "социальные сети для разглядвания котиков". Масса стартапов, да и те же FAANG, пачками пылесосили разрабов не потому что им что-то разрабатывать надо, а потому что надо осваивать свалившиеся бюджеты. Конечно звучит диковато для малого бизнеса который "на свои", но крупный бизнес и прочие венчуры живут совсем по другим законам. Сейчас этот краник перекрыли, так что зарплаты и занятость в секторе неизбежно придут к "средней по больнице". Тот же Твитор уволил 80% своего состава и наглядно показал чем там все на самом деле занимались за гигантские зарплаты.
Вы правильно написали, что настройка SCADA и разработка для ПЛК зачастую рассматриваются как второстепенные задачи, которые желательно бы скинуть на кого-то за копейки. В итоге конечный заказчик получает кое-как работающую систему, а инженер - низкую з/п. Как разорвать этот круг - и есть, на мой взгляд, главная проблематика данной статьи. Пока ничего лучше не могу придумать, чем пожелание специалистам не соглашаться работать, если клиент и работодатель не готовы платить.
Ну не знаю если честно... Что касается архитектуры и структурирования кода в асу тп, то это больше вопрос к себе и к компании где работаешь, я работал в больших компаниях мы занимались в основном черной металлургией, там требования достаточно высокие, кстати ни разу не видел что бы монтажник или технолог писали программу, я правда не понял крик души автора, как по мне все ок, по зарплатам, так как я мариуполец скажу так, в Украине за очень низкие, чуть больше слесаря, в РФ зп вполне на высоком уровне, понятно что ниже чем в ит, но все же. Что касается ЯП, по LD скажу так, его используют чаще всего по причине удобства анализа программы на действующей установке, я сам люблю больше st(scl), но чаще всего приходиться комбинировать при написании по, комменты и описания опять же или на совести программиста или обязательны, если по на какую нибудь доменную печь, касательно должен ли асушник знать технологию, ответ - нет, асушник это программист он работает по ТЗ от технологов/механиков/гидравликов, что касается разных ide, все они отличаются внешним видом, возможностями и главное работой с hardware, но как по мне в этом нет ничего страшного, я работаю с АВ, Сименс, дельтой, Овном, митсубаном, у всех свои ide и ничего, мне все по кайфу ))) главное отличие разработки в асу от ИТ это возможность постоянного мониторинга по, очень быстрой диагностикой алгоритмов для максимально быстрого решения проблем на работающем производстве, а внедрять технологии ИТ в асу, это как женить носорога с зеброй если честно...имхо
Согласен по всем пунктам. Дебаг почти во всех популярных котроллерах это песня и во многих есть применение изменений налету, что тоже весомый плюс. Единственное не хватало системы контроля версий. Слышал что у siemens step 7 была какая-то система контроля версий, но это какая-то проприетарная платная прога. А у большинства сред "проекты" хранились в каком-то бинарном формате.
Как понимаю основное применение IT в АСУТП - это интеграция систем разных уровней в единую систему. Но это не то IT которое мы привыкли видеть с аджайлом, активной разработкой, кучей аналитиков и тестировщиков, а больше ближе к IT в формате 1С, только большими масштабами
Как писал автор о поизоде Iot в асу тп. Ребята сделали проект wirenboard. По сути Линукс ПЛК. Буду соседу умный дом на его базе строить. ПЛК в первую очередь должны быть сверхнадежными. Цена ошибки в этом софте может стоить очень дорого. Я embedder но пару раз имел дело с плк. Друг просил поменять программу работы станка. Потратил несколько вечеров на разобраться с алгоритмом работы станка. Узнал чтото новое, не скажу что эти знания мне понравились. Для единичных изделий плк самое оно.
Вы прежде чем делать на его базе умный дом, посмотрите, какая уже версия железа у них. Все хочу тоже с ним поиграться, но это отталкивает - что делать , если вдруг железка помрет условно через 4 года? Уже не будет ПЛК v.7, а будет какая-нибудь v.9 . И что делать? переделывать шкаф/прогу под новую версию? или ждать, когда вам под заказ ее сделают?
У всех нормальных вендоров железо обычно поддерживается лет 5 минимум, а иногда и больше.
Лучше уж на каком-нибудь Овене (будь он неладен) делать проект - спецов, которые чуть что смогут откорректировать программу полно, софт бесплатен, железо всегда можно найти.
PLC - как раз для унификации...
Единичные проекты тоже можно, но основная фишка в том, что "реакции на раздражитель" всегда описаны, предсказуемы и управляемы.
ПЛК изначально сделаны для упрощения управления относительно стандартными процессами.
Очень люблю железо и embedded разработку, испытал на себе все вышеописанное ) В итоге нашел для себя нишу на стыке Android и embedded - всякие системы умного дома, автомобили, POS-терминалы. Такой компромисс позволяет с одной стороны писать на нормальном языке в нормальной IDE за нормальные деньги, а с другой - ковыряться с железками, низкоуровневыми протоколами и иногда тыкать осциллографом в разные места )
Эх, материться хочется. Автор, похоже не видел настоящего АСУТП, раз называет языки урезанными. Да они специфичные. Но вполне себе полноценные. Ну не существует алгоритмов, которые нельзя на них реализовать. Либо эта задача не для ПЛК. Сложилось впечатление, что автор не видел сложных систем, поинтереснее уровня "котельная на умном реле ОВЕН".
Я тут в качестве хобби занялся ардуинами - и понял, что я не программист. Вместо двух кликов в мышки в Tia Portal, необходимо написать несколько строк кода. Да это же просто неудобно. Хотя ностальгия накатила, у меня когда-то ZX Spectrum был. Подключал TFT дисплейчик - и был удивлен, что нет никакой программы типа HMI, где накидал полей ввода-вывода, а оно само переменные привязало. Все ручками. А еще чтоб сменить надпись, нужно сначала предыдущую затереть текстом цвета фона. Ужас. А если фон - картинка, то эту проблему я не решил, может как-то и можно, но сходу не получилось. Про отладку молчу. Любой дебаг, который я видел - это издевательство. Ну тупо удобнее видеть алгоритм подсвеченный, чем прыгать по брейкпоинтам.
По поводу низких зарплат, проблему я решил. У меня, к слову была достаточно высокая, но хотелось больше. Уволился, зарегистрировал ИП и теперь я сам называю заказчику желаемую сумму. Причем еще ни разу сам не искал заказчиков, никакой рекламы. Конечно, это дается не просто так - нужен опыт. Большой опыт. И при этом все равно постоянно приходится что-то изучать. Потому что куча IDE, у каждого производителя свои приколы, тут автор прав. А еще АСУТП это не только программирование. Асушник - это и электрик и технолог и наладчик и механик еше наверное кто-нибудь.
Подытожу. Для каждой задачи есть свои инструменты. Иногда даже разные. Не нравится автору LAD, возьми какой-нибудь контроллер с С-подобными языками, такие существуют, Контел, например. Или любой микроконтроллер, придумай к нему обвязку и пиши на чем хочется. Хотя для современных задач может и не хватить микроконтроллера.
Рынок АСУТП конкретно перевернулся... У нас на огромном предприятии везде eXpert SCADA (Италия), Sprecon V460, MicroScada PRO, все импортное, нет никакой документации или поддержки производителя, АДЪ какой-то.
У нас на огромном предприятии везде eXpert SCADA (Италия) .. нет никакой документации или поддержки производителя
С десяток лет назад внедряли обьекты на этой SCADA с оборудованием другого итальянского вендора (да и сейчас иногда всплывают доделки). В принципе, сейчас ещё остались кадры, работающие на рынке поддержки данных вендоров. Искать поддержки у производителя сейчас, думаю, нереально. Не сложилось как-то у обоих этих вендоров на нашем рынке, но, честно говоря, никакого сожаления, ибо оба решения далеки от идеалов.
АСУ ТП – это отрасль, которая без постоянного развития промышленного производства очень быстро сама себя «съедает». Требований для этого развития очень много, и при отсутствии почти любого – отрасль начинает загибаться. Например, обесценился ручной труд – автоматизация стала невыгодна, и приехали. Или нет увеличивающегося рынка сбыта, тоже плохо – все что можно автоматизировали, а дальше тупик (это, мне кажется, как раз наш случай). Тем более она очень зависит от поставок электронных компонентов (да и целых устройств начиная от ПЛК и кончая примитивными типа опторазвязок или реле) из-за рубежа. На этом фоне объясним и взлет зарплат IT. Если Вы, к примеру, хотите производить хлеб. Сначала наняли пекарей и работаете потихоньку. Потом решили снизить себестоимость – купили или заказали линию выпечки хлеба. Вот, заплатили асутпшникам, их работа. Но ОДИН раз. А дальше линия работает сама, требует минимум поддержки. Зачем Вам еще АСУ ТП ? Живете, деньги текут, яхта-вилла есть. Куда бы направить излишек ? Во вторую линию для расширения производства ? Да ну, дорого, еще и может не окупиться. Давай ITшников наймем, чтобы они повысили нам эффективность существующего производства: сделают бизнес-аналитику, найдут узкие места, добавят систему внутреннего документооборота, сделают интернет-магазин, где можно будет выбирать покупки. Это потребует 1/10 стоимости второй линии, но эта 1/10 может составить 100 млн, и разойдется между 10 человеками из IT-отдела. А новая линия стоила бы 1млрд и потребовала для своего создания 1000 специалистов АСУ ТП, которых может и не найтись вообще. У кого ЗП будет выше? И критерии сделанной работы в обоих случаях тоже несоизмеримы. Для того, чтобы работа программиста интернет-магазина была признана сделанной, необязательно, чтобы этот магазин «производил» покупателей. А для того, чтобы была признана работа АСУ ТП, обязательно, чтобы линия работала и производила булки.
У меня была какая-то надежда, что в связи с последними событиями что-то изменится, пойдут деньги в производство, обучение кадров. Но теперь понимаю, насколько «ребяческой» она была, и какой комплекс проблем препятствует этому развитию.
> АСУ ТП – это отрасль, которая без постоянного развития промышленного производства очень быстро сама себя «съедает». Требований для этого развития очень много, и при отсутствии почти любого – отрасль начинает загибаться.
хорошее наблюдение, вероятно можно сказать что состояние дел АСУ ТП намного более точно отражает состояние промышленности, чем другие составляющие IT
Огромное количество сред разработки PLC / HMI / SCADA («зоопарк»)
Работал я с ПЛК Honeywell Centraline. У этих клоунов для 4 контроллеров: Lion, Falcon, Hawk, Eagle - было 4 языка и соответственно 4 IDE. И самое смешное, что выходишь ты, знаток этого зоопарка, на рынок - и твой опыт там ни с чем не бьется и никому не нужен. А для компании отдельный квест найти тебе замену с опытом.
Отличный пример того, что когда не вырабатываются стандарты и кажды гребет под себя, то в итоге все в проигрыше.
Все проще. Нет рынка. Нет потребности. Нет конкуренции. Нет необходимости развиваться чтобы конкурировать. Нет необходимости ебашить. Те, кто готов и могут ебашить и развиваться - уходят туда, где для этого возможности есть. Остаются те, кому норм.
То есть заказчикам норм. Исполнителям норм. Производителям норм. Так в чем проблема?
Когда-то давно, еще в 2015 году я вводил эти магические буковки в гугле, на хх.ру, в зарубежном интернете и не находил никаких вызовов для себя кроме финансовых. А теперь сравните с тем же IT - одни тут банк свой делают, другие беспилотные автомобили, третьи - продукт для АБ тестирования пилят. Везде высокие зарплаты, огромная потребность в кадрах, но и не меньшие требования и специфичные знания. Ты просто знаешь, что будешь ебашить, но это будет вознаграждено и финансово и морально.
То есть заказчикам норм. Исполнителям норм. Производителям норм
Воистину. Моя тогдашняя контора пилила АСУ для бытового климат-контроля. Начальник в 2015г на голубом глазу впаривал клиентам в качестве HMI промышленные резистивные панели 800х600. Им место в кочегарке, а не в модном лофте. Меня просто в ступор вводило, почему всем норм, почему у начальника хватает на это совести, а у заказчиков не хватает ума отказаться от этой дичи и потребовать реализацию HMI через iPAd.
(побуду адвокатом дьявола :) )
1) а чем плохо решение "железо и экранчик" ?
2) если раздавать через iPad то надо как-то ограничивать доступ. Экранчик физически ограничен.
а чем плохо решение "железо и экранчик"
Вообще речь шла про управление климатом в особняке на около-Рублевке. Вы себе представляете промышленный HMI в тех интерьерах? Зачем там вообще дубовое искро- и взрывозащитное устройство промышленного назначения?
Во-первых, как я уже говорил, резистивный экран. По экрану натурально надо бить кулаком, чтобы что-то нажать.
Во-вторых, тулкит в принципе не позволял изобразить вменяемый UI. 16 цветов, прямоугольники, символы - все. И еще для кириллицы шрифты только с засечками.
В панельках + железе как таковых ничего плохого нет. В итоге-то мы, инженеры, продавили тему прекратить впаривать клиентам всякую дичь. Стали использовать панельки Weintek.
резистивный экран. По экрану натурально надо бить кулаком, чтобы что-то нажать… тулкит в принципе не позволял изобразить вменяемый UI. 16 цветов, прямоугольники, символы — все. И еще для кириллицы шрифты только с засечками.
таки да, не все дизайнерские закидоны можно реализовать ( у того же выпадающего списка не изменить внешний вид, как в том же HTML через CSS) и фон не сделать прозрачным и он будет выделяться в окне/мнемосхеме… (хотя… если в ПЛК можно нарисовать веб морду, то на панели можно смотреть через объект WEB браузер)
только хотел написать, что у того же Weintek есть и с емкостным экраном и внешний вид у них вполне себе лакшари (та же cMT3162X) + есть вариант с безэкранной с выходом HDMI, куда вы можете подключить свой любимый 52 дюймовый монитор и тачскин подключить по USB…
и тут вижу:
Стали использовать панельки Weintek.
ну всё ОК…
Моя Родина – АСУ ТП — смертельно больна
Здесь же на Хабре есть статья с созвучным названием:
АСУ: от печали до радости. История российской автоматизации
В 50-е годы, когда в СССР зарождалась идея создания АСУ и начала активно развиваться кибернетика, всех этих ресурсов не хватало. Учёные того времени были не только сухими прагматиками, но и мечтателями — им хотелось позитивных изменений социо-экономических отношений, которые была призвана обеспечить АСУ.
Меня радует эта статья и комментарии к ней. Когда я работал с около-асушными вещами, неоднократно восклицал "Да для кого это вообще сделано?! Кому с этим может быть удобно работать?!". На что настоящие асушники отвечали что для них и им норм. Радует что и другим людям начинают закрадываться мысли что что-то с текущим состоянием АСУ не так.
Впрочем, главное "не так" в АСУ - это вендор-лок, вызванный жадностью производителей. Поэтому каких-то предпосылок для улучшения ситуации я не вижу.
Вендорлок уходит с опытом. Поработав с основными брэндами, становится понятно, что в общем-то везде одно и то же плюс нюансы реализации. Ситуация налаживается, даже IDE становятся все друг на друга похожими.
У адекватных вендоров да, но иногда эти нюансы могут доходить чуть ли не абсурда - пример есть одного вендора где писать нужно практически на чистом ассемблере и это не мэк язык, но они на рынке с советских времен.
даже IDE становятся все друг на друга похожими.
у кого что на что и в чём становится похожим?
Вендор лок? Разве он есть? Программы прекрасно портируется с одной платформы на другую благодаря стандартам на языки программирования (сам лично переносил с древнего Honeywell TDC3000 на Siemens S7-400 + WinCC), оборудование можно ставить любое пока оно поддерживает нужную полевую шину/сеть (опять был опыт Сименсовских приводов и ПЛК Ален-Бредли).
сам лично переносил с древнего Honeywell TDC3000 на Siemens S7-400 + WinCC
А вот у меня был проект на S5, в котором использовались функции, неподдерживаемые в S7, а логика была непростая. Миграция была болью :)
бывает, что у каждого вендора свои нестандартные расширения языков… Формально языки одни и те же, а по факту «в лоб» перенести между железками нельзя, нужно адаптировать… очень много.
и тут на сцену выходит CODESYS… не?
Нестандартные расширения стандартных языков? Можете привести примеры? Я имел дело с железками от Siemen, Allen-Bradly, Modicon, Honeywell, и вроде LAD он везде LAD.
переносил с древнего Honeywell TDC3000 на Siemens S7-400 + WinCC
у ханивел тоже данные в DBшках хранятся и динамические графические объекты на кастомных объектах?
Нет, там данные в общей памяти контроллера, DB это вообже фишка исключительно Siemens (я думаю они ее у Allen-Bradley PLC-5 передрали, а потом не смогли отказатся). Динамические графические объекты на кастомных объектах это вы о блоках ПЛК что при компиляции проекта создают графические обьекты в HMI? Если да, то нет, HMI в TDC3000 просто имел доступ ко всем переменным в ПЛК.
Пишем SCADA, много лет. Странное впечатление оставляют наши клиенты. Как будто год за годом в борозде, не поднимая головы, безрадостно, безнадежно утопая в рутине.. Сколько не пытался через техподдержку какой-то значимый фидбек получить - без толку. Такие мелочи просят.. просто удивительно, настолько все привыкли ко всяким костылям, обходным путям и т.п. Это не только к нашему продукту относится - такое впечатление, что люди иной жизни и не представляют..
Хотел ответить на первые комментарии, но пока ждал истечения времени для дозволенных речей, то дискуссия уже ушла далеко.
Поэтому просто изложу своё видение и мысли. Немного сумбура обо всём.
Первое, у самой отрасли особо проблем нет - АСУ развивается, как аппаратно, так и программно.
На Сименс я пишу в SCL, не вижу каких-то особых проблем с этим языком, уж точно логичнее многих, для "нормального" программиста точно не будет ничего сложного. Бекхофф вроде вообще позволяет на Си писать.
СКАДА так там часто либо тот же VBS, либо опять C.
В современных версиях ТИА Портал уже и контроль версий подвезли (правда визуализации это не касается), но мы пробовали командой так работать - не очень зашло, проще на объекте через МультиЮзер работать да версии плодить.
Не очень понял что хочет автор, перевести всех с ПЛК на сервера, где крутилась бы программа управляющая периферией?
Ну кто-то уже пробует так делать, в том году имел подробную беседу с "немцами", они как раз что-то делают подобное, пока только для Кодесис.
Да кто же против?! Когда компании по всему миру ждут поставок ПЛК, то неужто бы они против были? В прошлом мае был у словенцев, рассказывали что снимают старые S7-300 и переписывают под них программы, потому что новых контроллеров не достать.
И да, та немецкая компания очень хвасталась временем цикла менее 10мс при использовании их софта не серверах, что в общем-то не проблема для обычного контроллера.
На прошлой работе мой последний проект это был автоматический склад, на ПЛК S7-1517, так у нас на нём крутились сотни участков c моторами, тысячи датчиков, сканеров, общение с роботами, WCS... Да там ещё запас был.
И всё спокойно настраивается, конфигурируется удалённо, уже давно не надо джамера перетыкать.
Вот лично я большую часть своей карьеры просто программирую, за отвёртку последний раз брался чтобы починить автоматическое ведро в офисе.
У нас (не на одной работе) и монтажники и наладчики были, служба поддержки...
И про себя я не могу сказать, что какой-то переучившийся железячник, в нашем Политехе программированию контроллеров учили.
На первой работе по специальности как стартовал с S5 (читая Бергера) так и продолжаю по сей день.
Теперь заключительная часть, про зарплаты и не только.
На самом деле это не программисты ПЛК получают мало, это обычные программисты получают больше.
Тут конечно и меньшая масштабируемость, даже точно такая же линия ламинирования ДСП точно так же не заведётся сразу, а на чём-то типовом вроде насосных станций обычно много денег не поднять.
Да, я честно пытался посмотреть что там пишут люди в нормальном мире, у меня мозги заворачиваются, уж не знаю что тому главная причина.
Так что не могу сказать, что мои коллеги денег не хотят, я такого не видел. Я и сам вроде не отказываюсь. Ну наверное мои 150 т.р. на последнем месте работы в России это не зарплата для местной аудитории. Так и в Европе программисты ПЛК сотни тысяч не получают, и от страны очень сильно зависит.
И вот подхожу к главной проблеме работы программистом ПЛК, для меня так точно - командировки. Точнее командировки и командировки.
Я-то случайно попал в одно (гиблое как оказалось) место на тринадцать лет и забыл как оно бывает. А когда захотел выйти из пресловутой зоны комфорта, сразу вспомнил.
Когда я устраивался в Сименс и мне говорили про "выезды на объекты", а потом оказалось что из таких выездов работа и состоит на 90%, то я через неделю оттуда ушёл, из компании мечты-то.
Так что благодарен нынешней работе, и что в Европу смог переехать и что сижу на одном месте.
Извиняюсь за сумбур, через сутки может что ещё смогу ответить.
СКАДА так там часто либо тот же VBS, либо опять C.
Два устаревших языка, а вы их наличие выдаёте за что-то современное.
Си ещё держится как язык системного программирования, но для прикладных программ он устарел безнадёжно.
командировки - это боль, да.
У меня родственник лет 10 томуназад - поработал годик на Сименс, и такую мотивацию от комадировок получил, что потом сбежал в мобильные разработчики.
Даже свифт выучил с нуля (чтобы писать код на айфонах\айпадах, а не уставки в контроллерах тяговых подстанций у черта на куличках :) )
После чего нашел себе девушку (или она его наконец-то нашла между командировками), женился и сидит дома - растит дерево, пузо и детей.
Бекхофф вроде вообще позволяет на Си писать.
За 5 лет работы с Beckhoff он мне уже осточертел :) Контроллер на винде - это извращение. Только на них все сейчас переходят. Писать на Си для него не вижу большого смысла - онлайн не зайти потом.
СКАДА так там часто либо тот же VBS, либо опять C.
Это вы про WinCC. А у других свои заморочки. Кстати, после нескольких тысяч строк на VBS (который ещё и урезанный по функциональности) я понял, что правильно оно расшифровывается, как "Visual BullShit" :))
И вот подхожу к главной проблеме работы программистом ПЛК, для меня так точно - командировки. Точнее командировки и командировки.
Вот она, самая проблема :)
Beckhoff он мне уже осточертел :)… Писать на Си для него не вижу большого смысла
не-не-не… настоящий программист должен написать свой ПИД-регулятор, свой обработчик прерываний, свой Modbus, переписать printf(), в программе на си обязательно использовать указатели…
а не эти ваши… гламурные LD/FBD\ST…
Зачем АСУТП, если нет производства? Это первый вопрос. Объем рынка труда в российском АСУТП стремится к нулю, и "зарплаты" туда же. Следующий момент, а почему не "удалёнка"? А потому что не удалёнка. На реальном производстве можно удалённо нарулить такого, что три страховые компании разорятся. Необходимо иметь объект управления в физическом доступе, чтобы его автоматизировать. Ибо наш мозг постоянно пытается подменить реальный объект упрощёнными моделями. И на эти грабли лекго налететь. А "удалённо" налететь ещё легче.
В SCADA еще и дизайн максимально всратый повсеместно.
А вот за всратый дизайн пусть заказчик тоже ответит, которому "да и хрен с ним с дизайном, нам работать надо, давайте уже сдавайте и погнали". Сейчас всё есть, чтобы красоту навести, только за неё платить человекочасами никто не хочет. Хотя... да и хрен с ним с дизайном-то, всё что нам надо - функциональность и удобство в оперативном управлении.
В SCADA еще и дизайн максимально всратый повсеместно.
какие эскизы мнемосхем утвердили — такие и получили…
Особенность инженера АСУ ТП в том, что сам по себе он ничего не значит. На первом месте всегда производство. Уйдёт один инженер — нестрашно, придёт другой, свежевыпустившийся из института, готовый работать ради опыта, ну и зарплаты там таки выше чем у дворников и продавцов в макдональдсе. А не найдётся инженер — найдётся фирма, которая пообещает владельцу бизнеса увеличить прибыль в перспективе заменой системы автоматизации целиком на более "эффективную". Я видел такие контракты, эти фирмы не дураки и остаются в плюсе при любом раскладе. С другой стороны, владелец бизнеса готов отдать 100М чужим дядям, но не готов дать 1М местному Петровичу, который может сделать то же самое и даже лучше — потому что такая психология и правила игры в целом.
Если программист набрался опыта в условном гугле — он может применить этот опыт в своём стартапе или конкурирующем продукте. А инженер АСУ ТП — не может взять и построить ещё один металоперерабатывающий заводик. И даже не потому, что это совсем другой уровень знания и инвестиций, а ещё и не решается без участия властей и/или криминальных авторитетов.
Опять же уже упоминалось, что АСУ ТП это не так уж и сложно. Зоопарк оборудования и скада не такой уж и большой по сравнением с теми же JS-фреймворками, не говоря уже о всех библиотеках в целом. В АСУ ТП не нужно изобретать что-то новое. Нужен газоанализатор — купил газоанализатор. Нужен спектроанализатор — купил спектроанализатор. Не нужно вникать в теорию, как это всё работает. Нужно к MODBUS через OPC подключиться — и тут готовая программка найдётся.
Конечно, порог вхождения в АСУ ТП выше, чем у условного формо-писателя мышкой на шарпе. Но зато и предел развития ниже. Логика производства не меняется, любые изменения незначительны по сравнению в целом, новые компоненты и протоколы появляются не так уж часто. А как только иссякает поток новой информации — соответственно иссякает и возможность для профессионального развития. Потому и не уходят инженеры (и я том числе), потому что попадают в зону проф. комфорта. А те, кто уходят, обычно уходят в принципиально другую область (одно исключение знаю — бывший коллега трудится над тем самым роботом Фёдором).
Особенность инженера АСУ ТП в том, что сам по себе он ничего не значит.
А кто такой "инженер по АСУТП"?
Далеко не всегда ведь в АСУТП есть возможность купить комплект готовых устрйоств + готовых контроллеров + ПО. Бывают ситуации, когда все приходится делать самим под конкретные условия.
Писал уже здесь - нам приходилось ориентироваться на подключение того, то уже есть на объектах заказчика. А там полно такого, чем готовые контроллеры какого-нибудь Адвантекса просто не умеют работать. Плюс еще для заказчика Адвантекс - лишком дорого.
Готовое ПО по большей части ориентировано на работу с технологическими схемами. Т.е. за пультом там предполагается инженер-технолог. А у нашего заказчика в диспетчерской или тетя нежного предпенсионного возраста, или девочка недавно после школы... Им нужен крайне простой, понятный и "человекоориентированый" интерфейс. Как там у Стругацких -
"лифт должен выдерживать прямое попадание самого необученного академика" (с)
Вот и получается что нет универсального "инженера АСУТП". Есть команда, состоящая из
разработчик микроконтроллеров (схемотехник, цифровая часть)
схемотехник аналоговой части (блоки питания, лили ГГС...)
программист микроконтроллеров
разработчик ПО верхнего уровня (то, что на компе работает - логика, UI, работа с БД устройств, логами и т.п.)
И каждый из этих людей ориентирован на работу с плотном взаимодействии с остальными. Один он не сделает ничего. Все вместе - сделают продукт.
А те, кто уходят, обычно уходят в принципиально другую область
А я думал мой случай уникален. Видимо, нет.
А кто такой «инженер по АСУТП»?Очевидно ж,
1) образование (код ОКПДТР 42525, если правильно нашёл),
2) должность.
Сам я тоже не настоящий сварщик и числюсь как инженер-программист, но контактировать как с оборудованием, так и с настоящими инженерами приходиться в первую очередь. Работа в том и заключается, чтобы решать проблемы/задачи, не решаемые средствами Simatic. Поэтому полное понимание происходящего на низком и железном уровне — это только начало. А зарплата даже меньше, потому что вредность не та.
Далеко не всегда ведь в АСУТП есть возможность купить комплект готовых устрйоств + готовых контроллеров + ПО. Бывают ситуации, когда все приходится делать самим под конкретные условия.
Железо самим делать под единичный проект на отдельно взятом заводе стоит только от полной безысходности. Жлобство руководства завода - это не полная безысходность :)
А я думал мой случай уникален. Видимо, нет.
Рано или поздно, любому надоест плавать в луже.
Верное замечание про предел развития. По моим наблюдениям в сфере управления зданиями, из-за низкой стоимости энергии в нашей стране заказчикам автоматики практически не нужны продвинутые алгоритмы и анализ энергоэффективности, предсказание отказов, не нужен долговременный сбор данных для анализа. В корпорациях экономия энергии приводит к снижению бюджета, а значит вредна. Частники же вместо оптимизации расхода энергии просто отключают оборудование или переводят его в ручной режим. В таких условиях увеличивать доход можно только увеличением объемов работ, а не увеличением сложности задач, что и приводит к остановке развития специалистов.
Слышал про Сибур, что у них как раз все хорошо в этом плане, но устроиться туда не удалось, что может и к лучшему, так как все, кто хвалил эту организацию, оттуда все-таки через несколько лет работы уходили из-за чрезмерной нагрузки или слишком частых командировок.
Может, но какой смысл менять шило на мыло за ту же зарплату? Ну вот звали меня в Ёбург-ское отделение Сименса работать, так там даже двукратного увеличения зарплаты не предлагали (для начала) — вообще ноль мотивации, с учётом необходимости переезда и ипотеки на 20+ лет.
А конкурирующие интеграторы в моём городе успешно прогорели, что было вполне предсказуемо (и туда тоже звали).
Не знаю как сейчас, но в 17-м году, когда работу менял, рынка вакансий в этой области не было практически совсем.
За 3-4 месяца по профилю не нашлось вообще ничего. Просто по разработке - да. Немножко телекома. И все. Единственное предложение более-менее по профилю пришло где-то через полгода, но я тогда уже нашел работу.
Вал предложений по мобильной и вебразработке. Но это не мое от слова свосем.
Но ведь есть еще огромное количество фирм, занимающихся контрактной разработкой и поддержкой систем АСУ ТП для разных заказчиков
В нагрузку прилагаются постоянные поездки в различные жопы мира :)
Опять же уже упоминалось, что АСУ ТП это не так уж и сложно.
Ну, как несложно.. Автоматчик процесс знает местами получше технолога ;)
Конечно, порог вхождения в АСУ ТП выше, чем у условного формо-писателя мышкой на шарпе.
Существенно выше. Тут ещё и аппаратную часть знать надо, и руками уметь.
Если программист набрался опыта в условном гугле — он может применить этот опыт в своём стартапе или конкурирующем продукте. А инженер АСУ ТП — не может взять и построить ещё один металоперерабатывающий заводик.
не нуачо…
АСУ ТП это не так уж и сложно. Зоопарк оборудования и скада не такой уж и большой… В АСУ ТП не нужно изобретать что-то новое. Нужен газоанализатор — купил газоанализатор. Нужен спектроанализатор — купил спектроанализатор. Не нужно вникать в теорию, как это всё работает. Нужно к MODBUS через OPC подключиться — и тут готовая программка найдётся.
да-да… манагеры так и мыслят… че так долго? там кнопку на форму бросить и в продакшен… какой жопомесяц ??? чтобы завтра было готово!!!111 (с)
Ну да. Вот вы писали, как проект в OpenSCADA сделали. А я саму скаду (не эту) сделал, в одного и практически с нуля. Насколько был в этом смысл — ну можно например по скриншоту трендов оценить:
А я саму скаду (не эту) сделал, в одного
н-да… секретная что ли?
В открытом доступе да, нет, и смысла выкладывать нет тоже.
Какой нафиг вендорлок, когда у них, судя по всему, полные исходники?
когда у них, судя по всему, полные исходники?
и много желающих/способных в них копаться, если Refrigerator перестанет с ней возится ?
Для программиста копаться в чужом коде - это часть повседневной работы. Мне даже как-то приходилось декомпилировать dll, чтобы исправить в ней ошибку.
Истину глаголешь!
У меня сейчас больше половины задач связаны с доработкой уже имеющегося кода. Обычно три причины:
(наиболее частая) необходимость внесения изменений в логику работы модуля - изменились внешние требования, изменился бизнес-процесс, изменился набор данных - вариантов много
(вторая по частоте) необходимость оптимизации модуля - модуль был написан давно и эффективность его работы всех устраивала, но со временем объемы данных кратно выросли и время работы модуля начала выходить за рамки отведенного для него временного окна
(не слишком часто, но бывает) исправление дефекта промсреды - в каких-то определенных условиях (на каком-то наборе данных) модуль работает некорректно
Во всех трех случаях приходится вникать в чужой код и логику работы. Да, у нас все документировано, на все есть актуальные FSD. Но далеко не всегда удается с первого взгляда сопоставить код и FSD. Особенно там, где логика сложная а код написан максимально эффективно (а это часто приводит к неочевидным реализациям - различные "хитрые" алгоритмы, кеши и т.п.). Посему в своей команде стараемся вставлять в код пункты из FSD в виде комментариев к блокам кода, которые этот пункт реализуют. Ну и актуализировать FSD по уже работающему коду с тем, чтобы было максимально просто сопоставить документацию и код.
Эта проблема называется "легаси", но никак не "вендорлок"
Нет, не по этому. Просто конкретно вам она не пригодится, поскольку пишется как SDK для программиста, хорошо знакомого с ООП и SQL. Это значит, что нет готовых решений на все случаи жизни, нет графического редактора с картинками на все случаи жизни, нет встроенного СУБД. Идеология построения совсем другая. Если на WinCC вы кладёте индикатор на форму и привязываете к нему теги для значения и статуса, не думая о нюансах, то здесь наоборот — привязывается отслеживание изменения конкретного тега и по событию вызывается функция для изменения значений контрола или каких-то других внутренних состояний. Если хочется, как на WinCC — ну ок, нужно просто самостоятельно определить такие контролы и организовать дополнительный слой абстракции, который при старте формирует список или граф связей и автоматически их разруливает. Если нужно сделать алармы — нужно самому выбрать СУБД, продумать структуру таблиц, триггеров и процедур и самому их насоздавать, а также написать скрипт на слегка расширенном варианте SQL (заточенном конкретно для взаимосязи с PLC) куда, откуда и по какой логике передавать данные. Рантайм тоже отсутствует, каждая задача — это конкретный .exe-шник, который запускается либо как обычная программа, либо как служба.
без вас оно не живёт…
когда на условную wincc можно пригласить любого школьника…
"как орут медведи" больше всего подходит...
Эта тема поднимается уже не первый и не второй раз, и главная проблема известна Это
унизительные заработные платы
Со всем остальным вполне можно жить.
Насчёт сообщества - у Сименса был отличный русскоязычный форум, пока его не грохнул один админ. Восстанавливать его не стали.
Помнится в середине 90-х я лично создавал в активном тогда еще FIDONet (кто помнит) эхоконференцию RU.SCADA (в дополнение к существующей на тот момент RU.EMBEDDED). Вроде даже там какая-то движуха была...
Эта тема поднимается уже не первый и не второй раз, и главная проблема известна Это
унизительные заработные платы
хабр — не жалобная книга! зачем сюда об этом писать ???
но форум был знатный… количество топиков по WinCC 6.0 (тогда еще ) вызывало очевидный вопрос «как оно вообще работает ??11!!, бедные выньсисятники ....»
Мне не с руки здесь заниматься саморекламой, потому как работаю над проблемой (это не про ИИ), а от философии, которую со времен 1-го процессорного устройства уровня бинарной логики с подачи Била с его предшественниками, сами себе могучие кодеры вбили в свои и прочие головы, о том, что машинный язык, в том виде его придуманной абстракции, прежде всего нужен для для создания исходника под определенные конечные задачи, что стало наследием и предметом гордости целых поколений разрабов и эта хворь пустила глубокие корни. Вредная привычка кодить на себе любимом языке, неважно ценой имеет одно оправдание - так ведь оно же заработало и не падает и не валит окружение и как быстро в реальном времени и т.д. и т.п.....
Почему разрабы с появлением языков не подумали на каком то этапе своих историй, что все же имеет смысл написать ядро и дальше его развивать под комфортный кодогенратор (понимаем фреймворк) где и мал и велик, чувствовали бы себя там комфортно и общались с системой на вербальном уровне без всех этих экспертов, тестировщиков и прочих гуру курсо устроителей.
Та же винда позволяет сегодня старикам пенсионерам иметь минимальный для них набор комфорта, почему так не подошли к среде для разработки автоматики (робототехники), а сколько сегодня талантливейших специалистов в своей области упирается лбом в стену, когда свои идеи нужно воплотить в код и нажать на кнопку старт?
Моя Родина – АСУ ТП — смертельно больна