Комментарии 43
"Приходит как-то айтишник на завод - а там зарплаты пятизначные". Вот эта ситуация действительно страшная.
Уже хотел написать едкий комментарий (потому, что этот ваш "интернет вещей и умный дом" - перегретая и токсичная тема), но автор вовремя опомнился и закончил вполне адекватными выводами.
Как старый автоматчик и асутпшник, вопрошаю в вакуум - а вы не пробовали нам платить больше чем грузчикам? Или отношение поменять?
Везде это такая нервная должность, а стек от глубокой электроники до скады. И нахрен оно надо? Оттого и текучка бешеная, деды уходят (я один из них) и жалеть не надо.
Откуда я ушел, вообще чуреков понабрали с зп х4 , которые выключатель от розетки не отличают. Ну удачи могу только пожелать. Если подобные вещи скоро в виде детских мультиков для детсадовцев начнут выпускать - сами напросились.
По моему асутэпэшному опыту- платить больше начинают только после того, как после очередной аварии из-за ветхости инфраструктуры увольняются последние деды, на которых наорали за просто так и с которыми руководство расстаётся "с облегчением" и мыслями о найме новых молодых-модных-молодежных человеков, которые не будут пилить мозг на тему обновления асутэпэшного оборудования, а привнесут глоток свежести в это "старческое болото" и поменяют всё неправильное и старое на правильное и новое.. Но вот засада- во первых новые люди не спешат наниматься за предложенные деньги, а во вторых, даже будучи нанятыми- ни бельмеса непонимают в адском легаси, описанном в статье и въезжают по паре месяцев, попутно устраивая простои изза экспериментов.. И если простой лишает фирму пол ляма баксов в сутки- сразу резко из ниоткуда возникают деньги и на сервера, и на оборудование и на софт и на людей..
И если простой лишает фирму пол ляма баксов в сутки- сразу резко из ниоткуда возникают деньги и на сервера, и на оборудование и на софт и на людей..
Вот прям жиза :)
Вот так вот все и есть, однако это не решает ни задачи "дедов" (я все для завода сделаю, а он мне денежку) , ни задачи завода, по сути. Пожар гасят нанятые за сверхдорого специалисты (мы, деды со стороны, какой сюр), но это временно. Если бы это был аутсорс - ну туда сюда еще можно понять, но когда сутки простоя линии стоят 15 млн и вы жопите мне заплатить 300 тр в моменте, за результат - этого я понять не могу. То есть когда я там официально работал, моя зп была 60 тр, вы наняли чуреков. на 200 тр которые нихрена не алё. Которые вчера максимум шкафы собирали. Инженеры электронщики? Да ладно, любой дурак справится. А я оказался невыгоден, ога, менеджеры заявок и премий с КТУ?
ТС это не про вас. Это про этих. Пусть теперь не найдут и за 400тр. Рынок открыт, молодым везде у нас дорога, ну вот хлебайте суки подавитесь.
Хоспади, ну вот хоть что-то адекватное в Корп блогах.
В промышленности нужно "чтоб работало", а не вот эти вот ваши модные штучки iot да через wifi. И второе - если сломалось, то чиниться в идеале должно моментально, дежурным электриком, без вызова сервис инженера из Москвы, который приедет через неделю-две.
Почему обязательно Delphi? Работаю c Modbus из C#, программы компилятся на arm и запускаются на одноплатниках. И куча дешевых китайских шлюзов RS485-TCP работают сутками напролет. Может нужно просто паутину иногда сгребать?
Если всё работает нормально, то зачем менять-то? Чтоб стильно-модно-молодёжно? Дык это и станки/котлы/реакторы тогда поменять неплохо б.
Delphi такой же молодой язык как и C#, как минимум моложе Питона (1995 и 1991 год соответственно). Также регулярно обновляется и также позволяет сборку под arm и другие процессоры.
Дельфи -- это Паскаль, а соответственно, один из самых старых пока ещё живых языков (1969 год, если память не изменяет). От того, что к нему добавили классы, он Паскалем быть не перестал. И да, старость сама по себе не означает, что язык плох -- вот только развивали его явно не так, как следовало бы. Хотя и сегодня, будь выбор, я предпочёл бы писать под МК на Паскале, а не на Це/Це++.
Не соглашусь, Pascal 70 года и Object Pascal (86 год) кардинально друг от друга отличаются, сильнее, чем C от C++. Не говоря уже о том, что Object Pascal основан на Clascal (Паскаль для Apple). Т.е. между ними даже отдельная итерация языка есть. Ну а Delphi ещё дальше ушел от Object Pascal. Настолько, что нет даже обратной совместимости. Т.е. старый код вполне может не компилироваться в новых версиях.
Я вот не помню, чтоб в Дельфях 15-20-летней давности были какие-то несовместимости с классическим Паскалем. Исключение -- это поддержка файлов и прочего ввода-вывода, но она в классическом Паскале просто никак стандартизирована не была, и в каждой конкретной реализации это делали по-своему. (Т.е. Read/Write были, а вот как открыть файл стандартным образом -- не было). Но она, по большому счёту, -- это библиотека поддержки языка, но не сам язык.
Ну а кардинальных отличий уж точно не было вообще. За исключением упомянутого открытия-закрытия файлов, программа, написанная на Паскале для СМ-1420 (надо полагать, краденый у ДЕКа), ничем не отличалась от той же программы, написанной на Турбо Паскале 3.0 на Роботроне-1715 или на Турбо Паскале для IBM PC.
Вот с Object Pascal, т.е. с последними ДОСовскими версиями Турбо Паскаля, возможно, совместимости и не было. Но, как я говорил, развитие Дельфей пошло совсем не туда, куда следовало бы: стали подражать Жабе и универсальный язык (по функционалу, а соответственно, и возможностям применения ничем не отличающийся от Це) превратили в хрен знает что. Развивать надо было примерно так же, как Це++, только с нормальным синтаксисом, а не с тем ужасом, что унаследован от Це и продолжает углубляться и расширяться.
По-моему язык развивается так как нужно. И Джавы в нем я не наблюдаю. Что именно по-вашему там не так?
Хотел дописать, что улучшить бы безопасность, но все написано до нас, ну и обсуждение.
Но в целом, все неплохо.
Насколько помню (давно уже Дельфями не пользуюсь), нет возможности создавать статические экземпляры классов (переменная типа "класс" реально является указателем на класс), т.е. навязывают динамическую память (в це++ ты сам определяешь, как тебе создавать экземпляр -- статически при трансляции с вызовом его конструктора до вызова main или динамически с помощью new). Освобождение памяти в каких-то случаях тоже выполняется автоматом, но уж не помню, в каких. Для высокоуровневого прикладного кода (а-ля Жаба) это, возможно, и нормально, но совершенно неприемлемо для низкоуровневых вещей, где контроль за всем подобным должен на все 100% оставаться за программистом -- как, собственно, это и было в классическом Паскале.
Сильно ограничены возможности переопределения операций по сравнению с це++ (ну и в принципе нет возможности определить свой оператор присваивания -- в це он операция, в Паскале -- оператор, но персонально для него можно было бы предусмотреть синтаксис определения своего).
Про шаблоны и говорить нечего -- крайне убогие генерики, мягко говоря, это не то.
В реализации юникодовских строк тоже что-то мне сильно не нравилось, но уж не помню, что именно (строки из Турбо Паскаля были вполне нормальными, но, понятное дело, сильно ограниченными -- а соответственно, не годятся для более современных применений).
Создания объектов на стеке нет, да, но это не мешает использовать record или на крайний случай object (не рекомендую).
Освобождение памяти в каких-то случаях тоже выполняется автоматом, но уж не помню, в каких
Освобождаются объекты только если они интерфейсные объекты, т.е. работают через RefCount.
Сильно ограничены возможности переопределения операций по сравнению с це++
Есть такая возможность. И не только переопределить, но и перегрузить.(док)
Про шаблоны действительно не стоит говорить, потому что шаблоны - это шаблоны, а дженерики - это дженерики. Шаблонов нет и не стоит их даже добавлять. А вот дженерики отлично вписались в синтаксис.
Реализация строк в Delphi такая, что я не задумываюсь он ней. И для всех строк использую string. В любых ситуациях, с любыми кодировками и т.д.
В этом примере Шарп не имеет преимуществ. Плюс в распространенности, минус в удобстве доступа к АПИ.
Как то через чур мрачно все описано. Имея за плечами многолетний опыт автоматизированного сбора данных с пром оборудования для последующего анализа и построения цифровых сервисов, могу сказать что и описанные в статье кейсы и те что остались за кадром технически не сложно и не относительно не дорого решаются начиная с применения Преобразователей интерфейсов RS485/RS232-Ethernet, opc da->ua тунеллеров, заканчивая самописными opc-серверами для древних устройств и СV пайплайнов для сбора данных со стрелочных аналоговых устройств, там где их замена на датчики сопряжена невозможностью внесения изменений непосредственно в конструкцию оборудования (ОПО). Главное чтобы было четкое понимание для чего это все.
У нас небольшое предприятие и смесь ПЛК: что-то с европы, что-то с Китая (клоны европейцев без документации), ОВЕН, ес-но, куда без него и что-то свое. Простые станки делаем сами и программируем тоже сами.
SCADA как таковой нет, но мы сами пишем веб-интерфейсы (там где надо) для инженера.
"Поэтому поколению постарше приходится объяснять, почему кибербез нужно делать правильно и со всей ответственностью" - поколение постраше просто наблюдало как каждые 5 лет сменялись подрядосы-безопасники, которые ставили свои поделки и исчезали через пару лет после очередного взлома. Поэтому проще отключить интернет и убрать кучу прокладок и проблем, которые всё равно не решаются из-за зоопарка технологий, которые всё равно взломают. В прочем такие практики применяются и не только на заводах, но и в структурах, в которых безопасности уделено ключевое внимание. Исходят от того, что всё равно поломают.
На самом-то деле, подключать к Интернету оборудование, которое непосредственно управляет техпроцессами -- решение, скажем так, крайне сомнительное независимо от мер безопасности. Максимум, что можно разрешить, -- это трансляцию показаний датчиков и т.п., но чтобы никаких управляющих действий извне предпринять было нельзя в принципе.
Ну а возможность физически подключиться к линии, скажем, RS-485... Если злоумышленник способен проникнуть на предприятие, чтобы сие совершить, что и всякие там шифрования не особо помогут: в конце концов, что мешает ему не к линии подключаться, а бомбу заложить? Тут вопрос решаться не на ИТ-уровне должен.
На самом-то деле, подключать к Интернету оборудование, которое непосредственно управляет техпроцессами -- решение, скажем так, крайне сомнительное независимо от мер безопасности.
Вот тоже думаю, зачем тех процессам на больших заводах нужен интернет, типа бесполезно, зато красиво, тоже не понимаю, везде круглосуточный сменный персонал, который за всем следит, ну разве что в диспетчерской должна быть вся картинка, но зачем ее выводить из вне, шоб начальство если что могло полюбопытствовать, ну так поиграются по началу, а потом это будет "пятой ногой"...
Другое дело, когда идет процесс который не требует участия человека, какая нить котельная, где нить в лесу или скажем как у меня было, подключил на 16 часов шланг и что возле него сидеть что ли, я могу спать лечь или по своим делам свалить на эти +/-16 часов, а если что меня система оповестит, что или процесс закончился или установка сломалась... :)
Ага. Приходит такой айтишник заниматься модным машинным обучением, начинает копаться и обнаруживает чуть ниже питона FORTRAN (иногда даже 77й) и кучу математических библиотек родом из 70х.
Это не про машинное обучение. Библиотеки примитивных операций (ATen) например написаны на C++ и CUDA. В норме даже туда лазить не надо, за редким исключением.На Фортране может быть написаны библиотеки матричных операций, но там уже всё оптимизировано до вас. Я за всю историю работы с ML и DL с 2012 года сталкивался с фортраном только один раз в проекте по физхимии, где нужно было считать сольватацию молекул 3D RISM.
А иногда вот сидишь и думаешь, а так ли нужна условная "безопасная безопасность" на станках и прочем? Задержки, отказы систем аутентификации-авторизации и т.д. В идеале если оператор допущен в машзал, то у него есть и квалификация и все остальное (в идеальном мире с крафтовым пивом), а дальше только включи станок и еbosch.
В условиях же полной автоматизации и промышленных роботов это больше имеет смысл, но опять же, чтобы свежеустановленный робот стянул свои настройки и рабочие программы с условного контроллера и перешел в режим "готов к работе" без сверхдолгих ковыряний с ним.
Однако в текущих условиях кажется единственное место где используется аутентификация и авторизация это максимум лицензионные ключи или токены, чтобы без них станок было не запустить или вообще удаленно погасить, ибо gtfo, вот почему. Очень хотелось бы в этом ошибаться.
Хотя по оценке того же Ростеха, если массово развернуть промышленный интернет вещей (IIoT) в разных секторах, это принесёт нашей экономике ~5,5 трлн рублей выгоды
Они не считали, сколько триллионов понадобится на закупку нового оборудования, прокладывание новых коммуникаций (замену забетонированной в стенах витухи на езернет-кабель или оптику), переподготовку обслуживающего персонала?
Учитывая, что на одной линии RS-485 может параллельно сидеть 3 десятка разных устройств, а на одном езернет-кабеле - только одно, это ещё потребует прокладывать гораздо больше кабелей...
Порадовал пост. Особенно в части кубернетисов и прочего интернетнооо и Клауд основанного чего скрипт Кидс с макбуками вроде как могут, но только если готовый докер образ откуда то скачать. А если оказывается что. Интернета нету - то все-приехали. Развернуть что-то локально это уже сверхзадача.
Кстати, посмотрите какие задержки с вашими современными протоками +ТСП/ИР будут по сравнению с простой передачей сигнала по медному проводу, который обычно напрямую от датчика к контроллеру / обработчику протягивают. Это реал тайм бэби :)
Мало того что задержка, она ещё и непредсказуемая.
Modbus тоже не моментально отвечает, особенно если как написали выше на один провод несколько десятков девайсов накинуть
Если на RS-485, то при правильном проектировании проблем всё равно не возникает: устройства ведь по своей инициативе на шину не лезут, а ждут, когда их спросят, а соответственно, никаких конфликтов, порядок операций на шине предопределён хостом. Задержка же с момента выдачи команды хостом до момента ответа устройства при нормально спроектированном устройстве вполне себе предсказуема. Ну а в TCP/IP слишком много сторонних факторов, которые вносят кучу неопределённости. Естественно, это не всегда является проблемой (чаще, наверное, даже не является: скажем, если ты опрашиваешь датчик раз в минуту, то, в общем-то, без разницы, придёт ответ секундой раньше или позже), но игнорировать подобное чревато.
Допустим, на заводе есть ПЛК (контроллер) и датчик температуры, оба на Modbus.
О-ля-ля, Мсье знает толк в извращениях. Понимаю, если на PROFIBUS PA или FF, но на модбасе?
Маск сделал следующие выводы (примерно, точную цитату из книги не помню, но донесу суть) — если ты автоматизируешь неидеальный или запутанный процесс, то ты просто ускоряешь хаос, а не работу.
Эта сентенция имела хождение задолго до того,как Маск стал известен. Еще в прошлом веке.
В формулировке "результат автоматизации бардака - автоматизированный бардак".
Еще встречалось " Автоматизация текущего положения без переборки бизнес-процессов позволит бизнесу быстрее принимать неправильные решения".
Описанное автором для большинства заводов уже сказка. Чаще всего если автоматизация есть, то там вообще аналоговые реле. Есть электрод. Есть/нет контакта - устройство включается/выключается. Всё. Никаких ассемблеров и прочих битов с байтами.
Лавандовый раф или стакан самогона: есть ли место на заводе хипстеру с макбуком