Между «давайте этим займёмся» и «о, смотрите, какая гламурная ML-модель» лежит очень много того, про что не рассказывают. Сейчас расскажу.
Вначале у нас была банда энтузиастов из разных подразделений: несколько человек из ИТ, АСУТП, технологи со знанием статистики — чтобы смотреть с разных углов и видеть всё в целом, насколько это возможно. Начали с оценки перспектив. Они были необъятные — наше производство размером с небольшой город. Стали формироваться подразделения и направления: кто-то пошёл собирать роботов, кто-то в видеоаналитику, кто-то в лайтовый анализ данных, кто-то в самый хардкор — в дата-сатанизм. Работы у нас всегда больше, чем рук.
И на каждой из этих дорожек нас поджидали свои чудеса и сюрпризы.
Вот, к примеру, видеоаналитика:
- Мы поняли, что ML в 50% задач не нужны. Нужна, например, камера, которая по цвету определяет, где есть железка, и смотрит её геометрию в реальности. Всё. Или другая камера, которая следит, чтобы в нужной зоне ничего не шевелилось.
- Всё это прекрасно до первого солнечного зайчика. ML отлично показывают себя там, где вам лень строить крышу или ставить прожектор над конвейером.
- У нас была идея, что мы можем сами в нейросети. Чуть не написали свой сервис для распознавания номеров вагонов. Казалось, делов-то на 20 минут, а у подрядчика это стоит 25 копеек за фото. Сделали свой, сферические вагоны в вакууме он определял хорошо. Потом приехало вот это:
А потом внезапно пошёл дождь. Знаете что? Вагоны под дождём становятся мокрыми. Это было неожиданно. Ещё они бывают после снега, битые, немытые, обновлённые криворукими малярами и ПРОЧИЕ. И в солнечных зайчиках тоже.
Мы накалывались на получении данных (кто сказал, что прошивка станка без костылей?), на роботизации, инфраструктуре, связи, на всём. Мы облазили весь завод, испачкались в солидоле, мазуте и масле. Но стали делать то, что должны, — оптимизировать мир.
Получение данных
Одна из первых вещей, которые нам были нужны, — это дата-сеты с оборудования. Ну знаете, телеметрия, параметры заказа, вот это всё.
В цеху данные используются, цех автоматизирован. Вот, например, есть очень хорошо цифровизированный стан-5000, всё очень чётко и данные классные, но усреднённые. То есть вместо лога там одно число: в среднем на единицу продукции, а хочется глубже, детальнее.
Все исходные данные тоже есть, они складываются в базу. Точнее, на самом деле там две базы.
Они друг с другом связаны линками как сиамские близнецы. Одна без другой не работает. Их в своё время не разделили, а сейчас никто и не вспомнит, почему так произошло.
Там то самое махровое легаси, которое никогда никого не отпустит. На заводе сменится поколение, все будут ездить на электромобилях, а эти базы так и будут работать вместе в паре, и никто их не разделит. Казалось бы, надо рефакторить, вот только у нас завод.
И сюрприз: у рефакторинга нет экономического эффекта с точки зрения производственного подразделения. Его никто не умеет считать, хотя подозревают, почему обычные изменения достаточно дороги. Их как раз умеют оценивать. Однако чётко обосновать с калькулятором в руках, насколько будет дешевле после рефакторинга, никто не может. Процессно-бюрократическая составляющая не даёт это на системном уровне исправлять.
А работать-то надо! Ок, есть боевые базы, которые около АСУТП. Так вот, если туда запустить храброго пользователя с кривым SQL, а ещё хуже — подрядчика или студента, то не иллюзорен риск, что база превратится в тыкву. А вместе с ней остановится производство. И это не гипотеза.
Угадайте, кстати, как мы это узнали.
На что вообще похож завод с точки зрения ИТ
Есть большая система ERP, где крутятся закупки, планы производства и прочие числа. С ERP работают клиенты: закупки, CRM, здесь деньги, заказы, поставки и тому подобное.
ERP спускает конкретный запрос в MES, систему управления производством. MES дробит стратегию на конкретные задания для смен.
Если MES соединена с АСУТП, то это всё автоматизируется вплоть до правильного раскроя металла и прочих оптимизаций. Дальше первый уровень — контроллеры, исполнительные механизмы, датчики. Вокруг этого всего всякие автоматизации кадров, электронные журналы, закупки, прогнозы спроса и так далее.
А теперь про анализ технологии и как у нас дела с источниками:
- ERP нам совсем не подойдёт — там хорошо выверенные данные, но в очень крупной детализации (на заказ, например).
- В базах MES обычно детализируется до единицы продукции, но не всегда глубже. То есть там не всегда сохраняются все нужные данные. И ещё туда не подключишь мощные аналитические запросы. Базы начинают тормозить, а вместе с ними и производство в базах MES-уровня.
- Базы АСУТП самые лучшие, и данные там самые крутые, но к ним и подключиться сложно, и данные быстро удаляются. Потому что это боевые базы, к которым напрямую обращается производство, и если что-то пойдёт не так, любой баг будет стоить большие миллионы денег.
То есть первая задача для того, чтобы можно было работать с данными, — хоть куда-то их вытащить. Причём желательно не просто агрегаты типа «среднее отклонение за час», а прямо сырые данные телеметрии оборудования, увязанные с данными производственного задания и замеров того, что выходит из станков. То есть это сбор данных, соединение их в одно хранилище и какая-то обработка.
Ещё один уровень сложности в том, что оперативные базы производства используются только и исключительно для нужд производства. Там не накапливается история. Чтобы база хорошо работала, из неё регулярно удаляют данные. Не удаляют только то, что должно храниться по закону или контракту пять лет. А нам эти данные тоже важны.
Хранилище технологических параметров для нужд техперсонала уже было. Его сделали технологи сами, без архитектора, и сделали хорошо. Оно продолжает работать успешно, но достигло своего потолка производительности. Позже туда пришёл архитектор, пришли мои коллеги, кое-что переделали, и оно круто ведёт себя под нормальным ИТ-контролем уже. Но там предел возможностей — традиционная база данных, Oracle с оптимизацией на небольшие участки, из которых можно собрать быстрые задания. Это не подходит для join'ов по всей базе, которыми так славятся дата-сатанисты.
Соответственно, мы понимаем, что надо что-то с этим делать, и стартуем процесс модернизации платформы технологических данных.
Как тащили
Опять же, тут должна быть красивая история, как мы героически ворвались и нечеловеческим усилием развернули модный кластер. В целом начало-то хорошее: надо вытаскивать оперативные данные и откладывать куда-то в сторону. Всё для старта есть, завод хорошо автоматизирован, просто надо сделать отдельную систему.
Но жизнь — боль, поэтому кое-что пошло не по плану.
Для начала в феврале 2022 года, когда мы уже нашли подходящее железо, внезапно стало нужно искать другое. Кстати, с софтом мы оказались сразу очень продуманными: вендорский иностранный не рассматривался в принципе в первых приоритетах, только опенсорс или отечественный. Ну отечественный — это, как правило, какие-то форки опенсорса, которые нормально поддерживаются
Проектная работа она такая, да. Важно понимать бизнес и уметь доказывать, что «да ёлы-палы, это просто нужно» выражается деньгами или чем-то ещё понятным, а не ощущением. Так мы потихоньку стали менеджерами. Ну, по крайней мере, я-то точно.
Дальше начались кадровые проблемы у подрядчиков. Мелочей на самом деле была куча, некоторые мелочи были размером с дом. Вроде бы всё простое, но каждым вопросом надо заниматься. Прилагать усилия. Одна только неопределённость требований стоила многих дней точно. Иногда хотелось вернуться в свой уютный свитер и в тишине писать код на Питоне, а не письма на русском. Но нет, хотелось довести проекты.
Но перехожу к сути.
Мы пошли в историю гибридной архитектуры, где сбор и первичная обработка проходит локально на заводе, а хранение и аналитика в облаке. Безопасники ожидаемо посмотрели на нас косо, но понимая, что если процесс нельзя предотвратить, то лучше его возглавить, наложили ряд ограничений. Так, например, появилось прямое соединение между нашим оборудованием и оборудованием Яндекса по оптике, и все наши ценные данные путешествуют именно по нему.
Само хранилище в облаке — это симбиоз S3-хранилища для хранения тяжёлых файлов (в основном временных рядов) и Greenplum для хранения реляционных данных и для пользовательского доступа.
Наш стек Питон, знаем про Spark и кучу джавовских балалаек, но по факту большая часть кода — на Питоне, это наш осознанный выбор на текущий момент. На Питоне пишет бизнес, на Питоне пишется большая часть дата-инженерии, там же компьютерное зрение с теми же данными работает. На Питоне же имеет смысл делать разработку приложух бека.
Работаем по самым цифровизованным цехам, потому что с них проще всего начать и проще всего получить вещественный результат. Вещественный результат — это когда производство понимает, зачем нужны айтишники, и начинает верить в то, что с нами мир становится лучше.
Ну или, по крайней мере, выгоднее.
Некоторые дата-сеты получаются легко, а некоторые с огромным трудом. У нас, например, есть один сет, которого на производстве ждали восемь лет и где разработчик чуть не сошёл с ума.
Сейчас он вернётся в реальный мир и напишет, наверное, что может пойти не так с данными на заводе. Но сразу предупреждаю: все, кто его слушал до этого, тоже чуть не сошли с ума.
В общем, в какой-то момент мы собрали для производства нужные данные, показали эффект и доказали, что мы для чего-то нужны. Производство обрадовалось. Чтобы как можно быстрее достичь результата, мы строили многие вещи по принципу «Долой дедукцию — гони продукцию».
Это когда то, что работает и приносит пользу сейчас — лучше, чем что-то очень крутое и идеальное потом. Вот и делали порой дендро-фекальным методом по ситуации. То есть после того, как всё заработало хоть как-то, нужно было ещё всё это отрефакторить и отмасштабировать.
До сих пор сидим рефакторим то, что тогда накодили, кстати. Некоторые временные участки кода оказались очень живучими. Работают, пользу свою несут.
Так мы всей нашей дружной командой от айтишников до технологов добываем данные, на основе которых аналитики и дата-сайенсеты всех мастей ищут закономерности и делают выводы. Наши данные позволяют буквально двигать науку: те же дата-сатанисты с инженерами нашли уже несколько моментов, которые поменяли их представление о физике процессов. Они там разрабатывают новые технологии на базе того, что мы им поставляем. И это результат.
Давайте вернёмся к видеоаналитике
Заводу нужен результат. Всегда речь про практический результат, а не красоту решения задачи.
Вот железяка, про которую я рассказывал вначале:
Рабочий день CV: надо померить изгиб железяки на конце листа, чтобы понять его влияние на технологию
На неё смотрит камера, видит границу красного и не красного и измеряет изгиб (красное — это горячий металл, на черно-белом фото выше он выглядит белым, а желтая линия — это тот самый изгиб). Никаких нейросетей. Пока нет. Сейчас решили, что может оказаться надёжнее отличить рулон от фона при любых условиях освещения с помощью нейросети, поэтому сейчас прикручиваем нейросеть.
А вот ещё пример, где без нейросетей не обойтись.
Кран с магнитом поднимает лом из вагона и нужно делать снимки слоёв выгрузок. Детектируем магнит, детектируем вагон, и как только фиолетовая рамка выехала из зелёной, делаем снимок слоя. Зачем? А затем, чтобы передать это другим нейросетям, которые определят вид лома и уровень его засорённости всякой дрянью, которая в печке превратится не в жидкую сталь, а в дым (который металлурги называют ласково угар), чтобы не платить продавцам лома за эту дрянь по цене лома.
Есть более сложные решения на базе нейросетей и больших моделей, например, сортировка всяких штук или выделение героев без каски и перчаток. Причём у нас есть те, кто делает что-то для своего цеха, есть те, кто делает масштабируемые решения для всего завода (обычно затрагивающие несколько разных камер разных цехов) и тому подобное.
Эта камера следит и подтверждает, что техника безопасности у нас на высшем уровне
Предположим, вам нужна видеоаналитика там, где, кроме железяк на конвейере могут ехать солнечные зайчики. И от брака их никак не отличить. В этом месте вы как инженер можете предложить два решения:
- ML-модель, отделяющую железяки от зайчиков.
- Кожух на конвейер, чтобы закрыть его от солнца.
Или вот не зайчики, а к примеру капли воды. Была у ребят в соседнем подразделении задача по определению наличия стружки на полосе металла. Стружка — это плохо и никому не нужно.
Убирать её потом больно и тяжело. Когда она только появляется, то увидеть её можно, с этим можно жить — кратковременно остановить станок, убрать стружку и всё хорошо. Потом внезапно оказалось, что вместе со стружкой на металле могут быть капли, которые безумно на неё похожи.
Что ребята попробовали? Они попробовали смотреть на тень. Если у капли есть тень, то, скорей всего, она не капля. Но оказалось, что разводы очень похожи на тень. Тогда начали следить за тем, чтобы на нескольких кадрах тень поворачивалась. В целом идея-то правильная — подставить дополнительные подсветки.
В общем, ML-модель часто оказывается дешевле, но иногда и наоборот — простой фонарь решает все проблемы.
В целом вообще любая видеоаналитика оказывается очень крутой: прототип делается за две недели любой задачи. Очень вдохновляет. Чух-чух, красивая картинка, квадратики, зоны, защитил презентацию. Потом полгода обрабатываешь исключения. Добро пожаловать в реальность, Нео.
Ну про вагоны вы уже знаете. 25 копеек за фото на начало того проекта казались нам грабежом, поэтому мы решили писать сами. Через месяц мы подумали и решили, что есть некоторые темы, где лучше платить 25 копеек. Несмотря на то что у нас на тот момент уже были шесть крутых спецов по CV.
Реанимация идей
Ещё одно направление — регулярная проверка того, что хотят рабочие и что за идеи были записаны раньше. Потому что в 2020 году мы успели сказать, что технически невозможно сделать очень много вещей, которые оказались реальными в 2023-м. Ну вот взять тот же голосовой ввод, один из самых парадоксальных проектов производства. Всегда было дешевле поставить ещё одного человека, который слушает, что ему говорят, и нажимает на кнопки. Но вот вдруг оказалось, что Алиса на производстве тоже пригодится. Точнее, спичкит Яндекса.
И так надо с каждой идеей, которая когда-то казалась нереальной.
Вместе с реанимацией идей надо проверять то, что не делают обычные подразделения.
Конкретно искать задачу, которую можно решить на производстве, анализировать эффект, пробовать делать прототип. То есть есть прямо команда, у которой задача — помочь идее не сдохнуть. Или найти сдохшую и оживить, вывести до состояния старта проекта.
Прочее
Ещё одно направление у нас так и называется — прочее. Лингвистические проекты, AR, VR, визуализация звука — всё это позарез нужно заводу, потому что даёт эффект. Роботизация, имитационное моделирование, всякие штуки типа чат-ботов для офиса и так далее. Всё чаще в цеху можно заметить человека в очках дополненной реальности.
В общем, поле всё ещё больше и мы всё ещё очень быстро растём.
Чего достигли
Где-то научились делать решения, которые дают эффект здесь и сейчас. Где-то поняли, что правильная архитектура важна, и научились строить системы. Где-то знаем, как находить компромиссы и из палок и известного связующего вещества делать прототипы. Где-то строим монументально на века.
Научились разговаривать с людьми, понимать, что они хотят, показывать результат. Научились работать с бизнесом и инженерными центрами. Мы подносим патроны, они внедряют.
Но, пожалуй, самое важное, чего мы добились, — появилась уверенность в себе. Мы теперь не боимся влезать в задачи, потому что знаем, что сделаем. С бизнесовой точки зрения самый крутой результат, которого мы смогли добиться, — в том, что мы достаточно полазили по заводу и достаточно испачкались мазутом и маслом до уровня, что можем написать ТЗ для любого подрядчика, который придёт внедрять. Это реально круто. И это многого стоит.
Сейчас у нас много вакансий. Ищем дата-сайентистов, архитекторов, аналитиков данных, спецов поддержки, экспертов ИИ, бизнес-экспертов, да вообще много кого. Вот тут все вакансии. Гламура не будет. Флёра цифровизации и смузи — ну порционно раз в неделю на общем созвоне. Но точно будет тяжело. Местами так, что захочется плакать, но надо будет терпеть. Потому что заводу нужен результат.
Комментарии (227)
taras_82
31.10.2023 07:11+107Как же классно читать про что-то настоящее! Вы бы знали, это как глоток свежего воздуха.
А то несколько утомили статьи о том, как я выгорел в 125 раз.
SpiderEkb
31.10.2023 07:11+23Или "как мы синие кнопочки с прямыми углами креативно заменили на зеленые со скругленными". И все это "херак-херак и в продакшн".
taras_82
31.10.2023 07:11+2А у меня мысль возникла, что все это спланировано. Типа теория заговора и вот это вот все.
Щас объясню: люди занимались себе кнопочками, формочками, распознованием капчичек, руку набивали на том, что сломать не жалко. А сейчас их пустили на реальное производство. И заметьте: всем только хорошо от такого подхода. Автор вон описал в статье, что случается, если запустить храброго пользователя с кривым SQL в АСУ ТП.
Rive
31.10.2023 07:11+4Возможно, просто доля реального производства стала больше (а значит, и заметнее).
UGivi
31.10.2023 07:11+7Или "денег нет, вендоров нет, надо превозмогать". Такое и раньше было, но точечно (ещё раньше - больше, но они заменялись на готовые или допиливаемые готовые), многим (даже тем, кому нельзя сотрудничать с) было проще, дешевле и надёжнее взять иностранные решение от инетграторов с поддержкой, чем самому набивать шишки, некоторые шишки набили и боятся снова (когда 20 раз подряд стукнулся мизинцем, подгибаешь пальцы даже в пустой комнате). Вопрос в том, что сейчас много предприятий, с которыми сотрудничать - как в РКН работать, потому лучше уж рисовать круглые кнопочки в форме котёнка или чем там модно заниматься (не знаю, пока есть ещё не шибко загаженные ниши в Народном Хозяйстве, хотя от некоторых "заманчивых" предложений пришлось отказаться, не останется - придётся вспомнить что инженер должен уметь работать руками, не впервой).
urvanov
31.10.2023 07:11+6Или "как мы синие кнопочки с прямыми углами креативно заменили на
зеленые со скругленными". И все это "херак-херак и в продакшн".
GospodinKolhoznik
31.10.2023 07:11+42Затем эти статьи и пишут. Как раньше писали романтические статьи о комсомольцах-добровальцах на стройках века. Мол хватит в душном городе сидеть, приезжаю сюда к нам, тут у нас тайга, товарищество, песни под гитару и трудовой подвиг во славу красного знамени.
Suharkov
31.10.2023 07:11+7тут у нас тайга, товарищество, песни под гитару и трудовой подвиг во славу красного знамени...
И комсомолки?
wepp
31.10.2023 07:11+58вам же написали, "товарищество"
nikolz
31.10.2023 07:11+5и товарищи комсомолки
jobless
31.10.2023 07:11+3Романов П. "Суд над пионером." http://az.lib.ru/r/romanow_p_s/text_2705.shtml
nikolz
31.10.2023 07:11Да это рассказ из будущего (...27 год) , только зеркальное отражение.
jobless
31.10.2023 07:11+1У него есть будущее по ближе. 1925-й http://az.lib.ru/r/romanow_p_s/text_2501.shtml
PabloP
31.10.2023 07:11+9Спасибо тем кто это знамя поднял, и тем кто во славу ему потрудился на славу. До сих пор основная инфраструктура Советских времен.
barbaris76
31.10.2023 07:11+6...а сколько костей лежит под фундаментом этой основной инфраструктуры - да кто ж их считал, зеков этих.
Bonstor
31.10.2023 07:11-1Действительно. Весь совок на костях построили. Так на костях строили, что население везде росло.Но вы не подумайте, просто расстреливать не успевали. Благо сейчас весь этот ужас закончился.
Репрессий и политических посадок нет, население растет, наука развивается, каждый второй самолет в мире производят у нас.
Нет? Да не может быть, ведь рыночек же должен был порешать.....
restruct
31.10.2023 07:11+9Так на костях строили, что население везде росло. Но вы не подумайте, просто расстреливать не успевали.
Налог на бездетность в СССР ввели именно потому, что население безудержно росло? И росло оно настолько безудержно, что налог отменили только в лихие 90-е?
P.S. Ослоумие «тупачок-гобля-стайл» демонстрирует окружающим задержку умственного развития, а не чувство юмора (жёстко привязанное к уровню интеллекта).
mayorovp
31.10.2023 07:11-1Понятия не имею, вводили этот налог для того чтобы население безудержно росло или по совершенно посторонним соображениям. Точно так же я не знаю как реально этот налог влиял на демографическую ситуацию. Однако, наличие этого налога никак не отменяет того факта, что да - население безудержно росло.
grisha9
31.10.2023 07:11-1О как! оказывается все дело в законе. Удобная позиция, найти какой-то факт и полагать что дело только в нем и озвучивать факт только на половину. Что его отменили только в лихие 90-ые. А то что его ввели в ноябре 1941 года, то да, эта дата ни о чем не говорит.
А население росло потому что оно было уверено в завтрашнем дне. А заводы и вся инфраструктура которая была построена в СССР этому способствовала. И росло население с середины 20-ых годов(можете посмотреть в википедии), не смотря на первые самые тяжелые пятилетки и репресии второй половины 30х.
MiraclePtr
31.10.2023 07:11+9Так на костях строили, что население везде росло.
У вас грубая логическая ошибка. В данном случае из одного не следует другое, точно так же как один приведенный факт не опровергает другой.
Репрессий и политических посадок нет, население растет, наука развивается, каждый второй самолет в мире производят у нас.
Вам знакомо понятие "аксиома Экскобара"? Вот тут оно актуально как никогда.
ruslan_sverchkov
31.10.2023 07:11+1В нищих странах оно ещё быстрее росло, зато в богатых странах даже падало) второй демографический переход, будь он неладен
KsandrFreeman
31.10.2023 07:11+8Некоторые считали, с этим можно ознакомится в прекрасных документалках Плохого Сигнала.
С полным перечнем материалов и ссылок к каждой.
SevAnt
31.10.2023 07:11+2Я слышал что везде те кто сейчас у власти любят ругать тех кто был до них, особенно если нынешнее не блещут достижениями. А если посмотреть на то как любят ругать прошлый строй, на Соловей ТВ то к тому за что они его ругают и как надо относится с осторожностью, может где-то нам врут
tandzan
31.10.2023 07:11+11Воу, воу, полегче, кто нибудь впечатлительный прочитает и правда пойдет в заводское IT.
RalphMirebs
31.10.2023 07:11+1А как решали задачу с номерами вагонов, мусором в ломе и браком на ленте до внедрения камер и распознавания образов и насколько это было эффективно? Было больше сотрудников или больше брака?
mikerosoft Автор
31.10.2023 07:11+13Решали с помощью оптических схем и нейросетей биологического происхождения, т.е. человеков. Не то что бы это было совсем неэффективно... Главная проблема — непредсказуемо. Хочу распознаю, не хочу — не распознаю. Тут успеваю, тут не успеваю.
GospodinKolhoznik
31.10.2023 07:11Ну так есть же способы двойного независимого контроля. Если один контролер что то не распознал, но второй контролер распознал, то с первого спросят "как так получилось?"
Xexa
31.10.2023 07:11Очевидно что нет. Достаточно оглянуться на своих коллег...
Люди работают на одном заводе, в одном цеху. Живут в одном городе(зачастую районе/доме). И вполне себе очевидно образуются дружеские отношения с вытекающими из этого. Это если они вообще не родственники изначально.
Т.е как один мог работать или не работать, так и двое будут делать.
Удалённая работа если только будет организована и из разных городов люди будут сидеть перед мониторами и контролировать - может. Но до этого пока не дошли.
GospodinKolhoznik
31.10.2023 07:11-1То, что они будут пытаться договориться друг с другом, это первое что придёт в голову их менеджеру. Ну и не так уж и сложно всё органиовать таким образом, чтобы они не могли и не хотели мухлевать.
not-allowed-here
31.10.2023 07:11+11попробуйте.....
как много вам Открытий Чудных, готовит - постижения сей путь.....
Нет ничего изобретательнее человека который занимается тупой, однообразной, рутинной работой, а уже если там Коллектив...... и вся сила этого Коллективного Ума направлена только на одно не работать!
или что хуже украсть..... Поверьте найдут способы и договорятся, и объяснят, и помогут....
и что Гораздо хуже нарушать ТБ..... да Идиоты - это к сожалению большинство нашего и не только населения, и да надо ХОРОШО помнить что мы тоже не исключены из этого подмножества....
про по бухать, по курить и по нюхать я вобще молчу.... и да новомодные алкотестеры/наркотестеры на КПП уже тоже научились Обходить.....
Devdmitry
31.10.2023 07:11Не всегда вопрос в желании обмануть или украсть - не все так относятсяк работе и обязанностям. Есть человеческий фактор - "не распознал" или "не успел".
Ставить ещё одного контроллера это +1 ставка на смену с таким же фактором риска, что экономически не целесообразно. Поэтому если проблему решать, то средствами, способными эти риски снизить.
not-allowed-here
31.10.2023 07:11Есть человеческий фактор - "не распознал" или "не успел". Ставить ещё одного контроллера это +1 ставка на смену с таким же фактором риска, что экономически не целесообразно.
о чем и речь - 2 человека на смену в 3-4 смены + 1-2 бригадира.... и внезапно ИТ-отдел даже с их крутыми спецами уже и не так дорого оказывается.....
Поэтому если проблему решать, то средствами, способными эти риски снизить.
именно так - и тут автоматизация процесса гораздо дешевле выходит....
Не всегда вопрос в желании обмануть или украсть - не все так относятся к работе и обязанностям.
к сожалению и в большинстве случаев при появлении реальной возможности будет именно так....
olartamonov
31.10.2023 07:11+5Ваше предложение удвоить размер ФОТ может не найти поддержки у руководства.
GospodinKolhoznik
31.10.2023 07:11+1Руководство может и поддержать, если им объяснить что зато не придётся тратить ФОТ на машин лёрнингистов и дата сатанистов.
not-allowed-here
31.10.2023 07:11если бы удвоить + 2 сотрудника да в три, а то и в 4 смены тк работа требует концентрации + им нужен бригадир, а то и 2 и это уже внезапно 7-10 человек......
pavelsha
31.10.2023 07:11+1Разные бюджеты... Не пересекаются. Поэтому результат сокращения одного типа ФОТ не доберется во второй тип ФОТ. Скорее осядет в финблоке или ещё где-то как премии за экономию
atshaman
31.10.2023 07:11Неа. Не прокатит. Ушел датасатанист в отпуск - никто и не заметил. Собрался цеховой - надо замену искать. Опять же, по ОТ и ПБ риски итэшечник край палец в тарелке с манной кашей сломает (Ну или с лестницы упадет, когда с телефоном в руке на обед поскачет - ну, это если с удаленки забрать) - а на собственно производстве мноооого чего случиться может. Опять же, "за цЫфровизацию и четвертую промышленную революцию" на каком форуме рассказать нельзя будет - да и просто карманы разные - "проектный офис цифровой трансформации" сплошь и рядом не с завода кормится, а с управляющей организации, да и ИТ-служба много где в отдельное юрлицо выведена.
Не вариант, в общем.
mikerosoft Автор
31.10.2023 07:11+2Конечно, есть. Там где что-то очень ответственное, так и бывает. Ну и плюс там самые натренированные и ответственные "естественные нейросети".
pavelsha
31.10.2023 07:11Ой, Михаил, биологическая оптическая система - это же широкие возможности по настройке.... Причем входные параметры и сигналы самые разные, а зависят от очень неоднозначных вещей.
Всё-таки получилось решить организационно вопрос с неприятием бездушных механизмов? Или сложилась ситуация как на Борском стекольный заводе лет 20-25 назад: есть работающие качественные регрессионные модели, но технологии всё равно управляют речами для стекла на глаз? А ВУЗ и завод дальше копают мат моделирование, защищая с каждым годом новые диссертации?
mikerosoft Автор
31.10.2023 07:11Неприятие бездушных механизмов — наша суровая действительность. В каждом конкретном случае способ убеждения свой: где-то удается объяснить и показать на практике, где-то кнут, где-то пряник. А иногда приходится признать, что бездушная машина реально ничего не понимает в жизни и ее надо на свалку.
nikolz
31.10.2023 07:11+1Возможно лом стоил копейки. А мусор дядя Вася и не приходовал. А когда дядя Вася ушел на пенсию, то пришлось нанимать ИИ.
pavelsha
31.10.2023 07:11Лом бывает разного сорта. И чистые сорта стоят дорого. Деньги в переработке металлолома крутятся большие. У Михаила, наверное, есть актуальный источник под рукой и он меня поправит. Но я помню, что на 60-70% изделия из металла сделаны из лома. (Да и твой Ауди, и хендай соседа и Лада тестя сделаны из одинакового "мусора").
Поэтому Дядя Вася успешно обучил молодых приемке, оценке и сортировка перед пенсией. Но ещё он научил мухлевать и филонить. С этим и борятся при помощи ИИ.
nikolz
31.10.2023 07:11Да, из металлолома получать сталь значительно дешевле, чем из руды.
Доля лома в производстве одной тонны стали постоянно растет. В 1995 г. расход лома составлял 283 кг/т, в 2010 г. – 287 кг/т, и постепенно он приближается к 300 кг/т. Это далеко не 60-70%
Если из руды, то основной состав шихты, как правило, составляет 55 % чугуна и 45 % металлолома. Для производства тонны чугуна требуется около 1,5 тонны этого руды и около 450 тонн кокса.
Но как по-вашему сколько мусора содержится в привозимом металлоломе?
Полагаю, что металлолом выгружают электромагнитом. И сколько мусора притянет электромагнит?
Поэтому, металлолом скорее приписывают, а не разбавляют бумагой, землей и травой.
--------------------
А еще есть такая информация к размышлению:
Из-за несовершенства технологического процесса при выплавке стали образуются технологические отходы, доля которых в настоящее время составляет около 15–20 % и снизилась с 25–30 % при разливке в изложницы после повсеместного внедрения непрерывной разливки стали. В металлообрабатывающих отраслях образуются отходы металлообработки, возвращающиеся на повторное использование в виде лома для выплавки стали. При выплавке стали часть железа теряется со сталеплавильным шлаком, в котором содержание железа (как, например, в электросталеплавильных шлаках) достигает 35 % и более. Чтобы не терять это железо, необходимо извлекать его из текущих шлаков и перерабатывать шлаковые отвалы, тем самым пополняя ресурсы вторичных металлов и одновременно улучшая экологическую обстановку.
kenoma
31.10.2023 07:11+2Мы создали для РЖД систему распознавания номеров АРНВ, у нас огроменные датасеты, хитрые нейронки с собственными трюками и пачка эвристик и все это работает лучше попсовых йол. Но ресурсов на создание такой сетки у нас ушло огромное количество при всем при том, что еще есть куда улучшаться.
konst90
31.10.2023 07:11+6А вот интересно -не дешевле ли было эти ресурсы пустить в создание и поддержание нормально читаемых надписей, чтобы обойтись простой системой распознавания и заодно упростить жизнь тем, кто будет писать свои системы?
lorc
31.10.2023 07:11+5Вы еще предложите наносить машиночитаемую маркировку /s
konst90
31.10.2023 07:11Разве что по принципу почтового индекса. То есть так, чтобы читать её могли и человек, и машина.
inkelyad
31.10.2023 07:11+2<после небольшого гугления>
А точно нужно? Ну и спецификация (pdf), если я правильно гуглил. C человеко-читабельностью тут не выглядит, что очень хорошо. Но активно пользуются.
kenoma
31.10.2023 07:11Надпись и без этого по трафарету сделана. На конвертах индексы в относительно лабораторных условиях считываются при хорошем освещении, на приемлемой скорости и т.д. А тут вагон в естественных условиях, со снегом, дождем. разливами нефтепродуктов, угольной пылью и т.д. Собственники стараются делать читаемые номера основные и дублирующие, но кто может гарантировать, что с номером ничего не случится в процессе эксплуатации?
SpiderEkb
31.10.2023 07:11+3Сам когда-то с железом дело имел. Оно, конечно, куда проще было - система мониторинга инженерного оборудования зданий в ЖКХ (главным образом - ЛДСС (Лифтовая Диспетчерская Связь и Сигнализация). Но свои приколы там были.
Когда начинали все это в 92-93гг, аналогов не было в стране. Все сидели на ПД-32 (Пульт Диспетчера, 32 лифта) - огромный шкаф с лампочками и кнопочками где от каждой лампочки до конечной релюшки (а в те время вся автоматизация лифта была на двух реле - РИТО - Реле Индикации Точной Остановки и РКД - Реле Контроля Дверей) шла отдельная пара. И всем было "и так все хорошо, зачем вся эта бесовщина с компьютерами какими-то"...
Сейчас банк, там свои приколы. В частности подходы к рефакторингу - "Ты представляешь объем ретестов после всего этого? И вообще - сколько на этом заработает банк?". Хотя у нас еще все не так плохо - есть проект по оптимизации старого кода в той части, что на данный момент не отвечает текущим объемам выросшей клиентской базы. Т.е. работа идет... Но в целом подход "не болит - не трогай".
Так что в общем и целом понятен консерватизм в тех областях, что связаны с реальным производством.
И задачи, связанные с "откинуть текущие данные куда-то пока не исчезли" у нас тоже есть в достаточном количестве. И есть методы решения таких задач. Равно как и создания различных "витрин" где содержится оперативный срез текущего состояния для быстрого к нему доступа (например, чтобы избежать запросов с агрегированием по всяким "историческим" таблицам там, где нужно быстро получить текущие данные, но при этом нужно и историю хранить).
micronull
31.10.2023 07:11+7сколько на этом заработает банк?
А потом появляется какой-то, образно говоря, жёлтый банк с шустрым приложением и откусывает приличную часть рынка.
SpiderEkb
31.10.2023 07:11+1Да не так много он откусывает. Можно посмотреть рейтинги, там все видно.
А уж если говорить о приложении, то оно, строго говоря, вообще не про банк. Оно бесконечно далеко по количеству промежуточных слоев от реальных серверов где все хранится и крутится.
И основные деньги банк делает на "жирных" корпоративных клиентах, а не условном Васе с движением по счету в 30-50тр в месяц.
micronull
31.10.2023 07:11+2А уж если говорить о приложении, то оно, строго говоря, вообще не про
банк. Оно бесконечно далеко по количеству промежуточных слоев от
реальных серверов где все хранится и крутится.Я как раз про то что без нормальной инфраструктуры современное приложение не напишешь.
Либо будет на костылях и\или тормозить, плюс долгое внедрение нового и доработка старого функционала.
И основные деньги банк делает на "жирных" корпоративных клиентах, а не условном Васе с движением по счету в 30-50тр в месяц.
Пассую, но при таких вводных странно что у нас в стране у банков одни из самых передовых приложений в мире и очень сильная конкуренция.
Зачем развивать приложения и вбухивать деньги?
SpiderEkb
31.10.2023 07:11+7Либо будет на костылях и\или тормозить, плюс долгое внедрение нового и доработка старого функционала.
Любой функционал в приложении определяется тем, что ему предоставит АБС на центральном сервере. Там (если очень примитивно) - есть REST API которым пользуется приложение. Есть набор WEB-сервисов к которым обращаются REST API. Каждый сервис имеет свой сервис-модуль на центральном сервере. Т.е. чтобы внедрить "креативную фичу" в приложении нужно всю цепочку спроектировать и разработать. При том, что у центральных серверов и без того забот хватает - там одних платежей сотни миллионов штук в сутки проходит и каждый надо прогнать через комплекс проверок прежде чем пропустить (или отправить на ручной контроль в финмон). А всего одновременно крутится тысячи, если не десятки тысяч бизнес-процессов одновременно.
И тут еще очень много зависит от нагрузки. Когда у нас было 30млн клиентов (по основной таблице) нагрузка была одна. Когда стало 50млн, нагрузка стала совсем другой и многие процесс потребовали вдумчивой оптимизации. Когда я пришел в банк в 17-м году, нагрузочным тестированием мало кто одумлялся. Сейчас это обязательно (более того, нам дали инструмент для первичного самостоятельного нагрузочного теста и прежде чем выводить на НТ сами проверяемся на предмет узких мест. И задач по оптимизации сейчас достаточно много - есть понятие "дефект производительности". Этого да от сопровождения прилетает что-то типа
Коллеги, сервис *** за последние 5 недель увеличил потребление процессорных ресурсов в 3 раза!!!
Он уже является 2-м по величине сервисом после *****.
В качестве альтернативы мы рассматриваем перенос запуска сервиса на резервный сервер, но там есть лаг по отставанию до 10 мин.
Заказчикам сервиса это может не понравиться :(И с этим приходится что-то делать...
Пассую, но при таких вводных странно что у нас в стране у банков одни из самых передовых приложений в мире и очень сильная конкуренция.
Тут все просто. Банки крайне консервативны. У наших банков был очень высокий старт - по сравнению с западными, где история цифровизации началась значительно раньше, у наших намного меньше легаси кода (я, к примеру, не уверен что где-то у нас используется COBOL, хотя на западе его полно и избавляться от него крайне дорого и долго - был пример Банка Содружества Австралии и Океании где попробовали "перейти на новый технологический стек" - обошлось это в 5 лет - с 2012 по 2017 и $750млн. Других таких "героев" я не знаю...).
Но общий принцип такой - в первую очередь устойчивость и надежность, потом эффективность (скорость, ресурсопотребление...) И только потом все остальное. Любое изменение кода тащит за собой длинную цепочку различных тестов (компоненты, бизнес, интеграция, нагрузка, техтест на прелайве...). Потому что отказ одной системы это уже потери в деньгах и репутации. Если отказ одного потащил за собой что-то еще - это уже катастрофа т.к. может повлечь за собой санкции регулятора (штрафы и т.п.). Поэтому любое внедрение только после тщательного тестирования и обязательно с перечислением возможных рисков и планом отката на случай если что пошло не так. Более менее серьезные дефекты промсреды обязательно выносятся на комиссию по инцидентам.
В общем, там все очень сложно...
Я как раз про то что без нормальной инфраструктуры современное приложение не напишешь.
Естественно. Поэтому любое решение всегда согласуется многими архитекторами разных систем - где и как его реализовать.
Зачем развивать приложения и вбухивать деньги?
Это просто один из элементов сервиса. И не такие деньги в него вбухиваются. И отдача от затрат всегда тщательно просчитывается. Но... сравните (хотя бы) объемы активов "желтого банка" (начало второй десятки в рейтинге) и банков из топ-5. Там разница в разы.
А у нас, к примеру, вбухивают не только в приложение (которое по каким-то там рейтингам считается одним из лучших), но и в офисы - был недавно - "phygital office" - там и биометрия (если сдавал - тебя камера на входе сама распознает, никаких талонов не надо) и обслуживание персональное (приходишь, садишься за столик, к тебе менеджер с ноутом подходит и решаете вопросы все с ним).
Видимо, это тоже считается окупающим себя.
micronull
31.10.2023 07:11Спасибо за развёрнутый ответ.
SpiderEkb
31.10.2023 07:11+3Ну я не знаю за все, просто в общих чертах представляю как у нас (хотя многие аспекты весьма поверхностно т.к. много команд, направлений, и это только по центральным системам, с которыми просто не сталкивался по работе - в основном с клиентскими данными, разными комплаенс-проверками дело имею).
Но общую позицию обрисовал - прежде всего надежность и считают деньги - сколько это будет стоит и сколько принесет прибыли. Отсюда консерватизм.
Мы вообще работаем на платформе IBM i (сервера IBM PowerS). Кроме нас, насколько знаю, еще Райф и Росбанк на ней сидят. Это специальные коммерческие middleware сервера. Да, дорого. Но офигенная производительность и надежность. Один сервер - 16 12-ядреных SMT8 (8 потоков на ядро) процессоров Power9 (Е980), 12Тб оперативки и 400Тб SSD массивы. Операционка очень мощная, интересная и ни на что не похожая ("все есть объект"). Основной язык тоже специализированный для коммерческих расчетов - RPG (мне лично нравится в плане решения поставленных задач), хотя есть и С/С++ (для всяких низкоуровневых вещей используем).
Мне, кстати, предлагали стать "архитектором направления" (комплаенс) - попробовал и категорически отказался. Ну не мое это от слова совсем. Сплошные встречи, согласования и т.д. и т.п. Такое ощущение, что время (и жизнь) как вода в песок уходит.
Так что я уж лучше в разработке останусь. Оно хоть как-то душу греет.
ALexhha
31.10.2023 07:11Мы вообще работаем на платформе IBM i (сервера IBM PowerS)
а вас не прессуют на предмет импортозамещения и все должно быть только отечественной разработки ?
SpiderEkb
31.10.2023 07:11+5Мне про то неизвестно.
Точно что отечественных аналогов нет и не предвидится. Поменять полностью АБС - см. выше про Банк Австралии.
Тут такая специфика... Работаешь немножко как на какой-нибудь БЭСМ-6 или Эльбрусе (советском) - есть эмулятор терминала IBM5250, вся работа в нем. Все, что делаешь, всегда делаешь в рамках своего "задания" (job). Зашел терминалом - вот тебе интерактивное задание. Второе окно терминала открыл - это уже другое задание.
Примерно так выглядит
Общение с машиной путем команд (системный язык CL, впрочем, на нем можно и программки писать - статическая типизация, компилируемый, все дела). Можно свои команды создавать (если есть какая-то программа, то можно обернуть поверх нее команду).
Программа вызывается через CALL <имя программы> PARM(<список параметров через пробелы>)
Команда - <имя команды> <список параметров в виде <имя параметра(<значение параметра>)>>
Если для команды не указал что-то из обязательных параметров - выведет "интерфейс"
Файлов, папок в привычном понимании нет - есть "объекты" (у каждого - имя, тип, набор атрибутов, для каждого типа системой предусмотрен набор разрешенных с ним действий).
Вместо папок - "библиотеки". Вместо PATH - "списки библиотек поиска" - LIBL (туда можно в любой момент добавлять, удалять, менять порядок элементов).
Короче, все "не как у людей", но очень мощно и куча возможностей.
ALexhha
31.10.2023 07:11+2Я так понимаю, что штуки типа IBM PowerS без саппорта со стороны IBM особого смысла не имеют, а насколько знаю IBM ушла. Как выкручиваетесь ?
SpiderEkb
31.10.2023 07:11+2Ну как-то оно все работает :-) У нас еще и RHEL и SLES есть где-то на внешних системах...
Подробности как именно, сами понимаете, никто не будет оглашать во всеуслышание.
Но факт в том, что оно работает. Это в принципе не та система, которую надо пинать постоянно. В мире (по отдельным слухам) есть экземпляры, которые работаю на очень старых версиях, поддержка которых давно прекращена, но они продолжают работать.
У нас стоит версия ОС 7.4. И сервера 9-го поколения. Актуальная на сегодняшний день - версия 7.5. и 10-е поколение. Да, мы не можем официально купить Power10 или проапгредиться на 7.5. И TR (Technical Refresh - минорные обновления версий) официально не получаем. Но лицензии все у нас в свое время были закуплены бессрочные, по железу тоже какие-то запасы есть, так ничего не остановилось.
Все исходники АБС давно выкуплены у разработчика, так что тут тоже своими силами вполне справляемся.
Мигрировать куда-то - это точно непосильная и неподъемная задача.
Так что...
VSOP_juDGe
31.10.2023 07:11жесткий конечно вендор-лок. Интересно, что будет с этой системой, если санкции за 10 лет не отменят
SpiderEkb
31.10.2023 07:11+1Да ничего не будет. Лицензии бессрочные, сервера от внешнего мира полностью изолированы (т.е. к ним нет удаленного доступа извне, общение с внешним миром или через ESB шину или через очереди).
Ну и "параллельный импорт" тут тоже работает (без подробностей, которые мне неведомы, но по некоторым признакам таки да).
Что реально потеряли - раньше могли вызвать аудиторов для консультации "что можно улучшить", сейчас приходится самим. Но тут уже накоплен большой опыт, так что потеря не критичная.
В остальном же - это очень надежные системы, которые десятилетиями работают без необходимости серьезно в них вмешиваться. Именно на этом они и держаться - надежность и производительность.
krids
31.10.2023 07:11+1На одном крупном промышленном предприятии в 2019 году выключили IBM pSeries 690 запущенную в.. 2003ем. 10 лет (если не больше) работала без IBM-суппорта. "Фирма веников не вяжет, фирма делает гробы" ;) Правда именно такие hi-end "гробы" IBM больше не делает.
Devdmitry
31.10.2023 07:11+2Это по этому обычные рублёвые переводы даже внутри одного банка между клиентами занимают до 3х банковских дней? ????
SpiderEkb
31.10.2023 07:11+1Это где? У нас моментально проходят. Даже переводы на тот же сбер "по номеру телефона" (не СБП) меньше минуты. у уже внутри банка вообще мигом.
Может быть по номеру счета есть какие-то особенности - тут не в курсе (это команда Системы Расчетов работает, я в команде ядровых систем и в основном по комплаенсу и клиентским данным работаю).
Да, была задача по проверкам в рамках контроля платежей. Там суть в том, что есть набор проверок - если все прошло - платеж уходит. Если что-то не так - на ручной контроль в финмон. Но для внутрибанковских платежей там все достаточно просто - и плательщик и получатель клиенты банка, к ним уровень доверия достаточно высокий и про них все известно - они все регулярно по спискам росфина проверяются, мутных всяких личностей еще там выявят.
Но как у других все это реализовано не в курсе.
sv91
31.10.2023 07:11А сколько раз у вас перевод занимал 3 дня? Я делал такие переводы (именно по реквизитом, не через сбп), все доходило в течении часа
SpiderEkb
31.10.2023 07:11Честно сказать, у меня были ситуации когда в другой банк на ЮЛ по номеру счета только на следующий день уходило, до этого висело "операция в обработке".
Но когда между ФЛ "по номеру телефона" внутри банка (ну скажем, когда с коллегами кому на ДР скидываемся, или еще что) или в сбер (по дому мастера вызовешь, расплачивается с ним) - там мигом пролетает. Причем, вне зависимости, настроено СБП или нет.
sim31r
31.10.2023 07:11Пополнение кредитной карты может быть с задержкой, но это и не проблема, там скорость не важна.
YMA
31.10.2023 07:11что у нас в стране у банков одни из самых передовых приложений в мире и очень сильная конкуренция.
Там "полянка" поделена ещё много лет назад, сформировалась определённая культура и только редкие дикие финтех стартапы баламутят болото. А у нас пруд со щуками, который только сравнительно недавно по мировым меркам стал более-менее прозрачным.
Поэтому у меня в доме в магазинчике с одной кассой стоит биометрический терминал Сбера. И им уже пользуются, видел вчера вечером. И он работает :)
Alexsey
31.10.2023 07:11+3Поэтому у меня в доме в магазинчике с одной кассой стоит биометрический терминал Сбера
Кстати задался тут вопросом а кто разработчик этой штуки и что там с безопасностью. У нас же вроде все компании-разработчики платежных терминалов ушли с рынка, а тут внезапно появляется новый непонятный девайс от сбера, который может мало того что биометрию, так еще и беконтактную оплату картами. И никаких опознавательных знаков кроме логотипа сбера на корпусе. Не понятно.
GidraVydra
31.10.2023 07:11+2Не беспокойтесь, ведь у Сбера же никогда не было крупных утечек персональных данных (сарказм).
SpiderEkb
31.10.2023 07:11+1За Сбер не скажу, но по тому, как устроено у нас могу сказать что слить клиентскую базу с сервера почти нереально.
Во-первых, это терабайты данных, раскиданных по многим таблицам - надо делать какую-то объемную выборку, которая будет работать не один час (и это будет замечено сопровождением которое постоянно мониторит что там на сервере крутится, следит за нагрузкой и т.п. - новое задание, которое жрет ресурсы будет быстро обнаружено).
Во-вторых, доступ к боевому серверу с такими правами есть у крайне ограниченного круга людей. Т.е. сразу спалится человек.
Т.о. все потенциальные утечки - это какие-то куски данных с которыми работают какие-то сотрудники в рамках своих должностных обязанностей (т.е. по работе какую-то выборку сделал и заодно ее скопировал себе куда-то), но никак не "вся база". Тут уже безопасники какие-то меры предпринимают (а они предпринимают, это совершенно точно), но что и как - не в курсе.
VSOP_juDGe
31.10.2023 07:11да, всю базу сложно вытащить. А вот пробить конкретного человека легко, такие услуги и продают на форумах в даркнете
SpiderEkb
31.10.2023 07:11Ну это несколько иной случай. Такое да, можно. Но это не массовый слив данных.
Впрочем, с этим тоже борются.
Devdmitry
31.10.2023 07:11У Сбера есть ит-дочка Сбертех, которая работает над их сервисами, вероятно это их творение.
Да и nfc сейчас модно и мало кого удивишь - все привыкли вроде.
rg_software
31.10.2023 07:11Зачем развивать приложения и вбухивать деньги?
Мне кажется, тут схема, описанная в книге "Дилемма инноватора". Банк-стартап таргетирует те слои клиентов, которые просто не интересны большим игрокам. Если у вас, условно, сто человек в штате, то можно жить и на частных клиентах, которые оценят хорошее приложение. Ровно так же работали, например, ранние производители карт флеш-памяти, которые не годились практически ни для чего из-за низкого объёма и высокой цены. (Ниша была в устройствах малого размера на микроконтроллере). В итоге флеш вошёл в меинстрим, но гарантии тут нет, и банк пока что вполне может жить с приложением, сделанным по остаточному принципу.
nikolz
31.10.2023 07:11Чем меньше движений клиентами по счету , тем больше прибыль.
Банк делает прибыль на том, что дает деньги одних клиентов в долг другим клиентам.
В современной экономике "тощие" клиенты через банки дают в долг "жирным", а не наоборот, как было сто лет назад.
SpiderEkb
31.10.2023 07:11+1Насколько я понимаю, там все намного сложнее. И так сразу не разобраться :-)
Кроме кредитов есть еще эквайринг, оплата РКО и т.п. Но тут я не спец - это уже экономика, так что не буду даже "оценочных суждений" высказывать дабы не уподобляться диванным экспертам, которые вчера все были эпидемиологи, а сегодня стали военными экспертами :-)
Могу только сказать, что банк посильно развивает как сервисы для физиков, ИП и самозаняты, так и бизнес-сервисы для малого, среднего, корпоративного бизнеса, стремится к сотрудничеству с регионами (кредитование, зарплатные проекты). Но это все так, на уровне того, что в корпоративных сервисах пишут в виде "достижений".
GidraVydra
31.10.2023 07:11+2Если посмотреть рейтинги и финотчетности, то там как раз видно, что основные деньги крупные банки зарабатывают именно на условном Васе. Крупные корпоративные клиенты обслуживаются в своих кэптивных банках. А ещë там видно, что условный желтый банк откусил очень много у тех конкурентов, которые находятся в рыночных условиях.
Сравнивать же с зеленым или синим банками, которые свои активы получили по наследству, крышуются государством, накачиваются админресурсом и эмиссионной ликвидностью, абсолютно некорректно. Их заслуги в размере их активов - ноль.
SpiderEkb
31.10.2023 07:11Ну мы не зеленый и не синий банк. По наследству ничего не получали.
Да и не думаю, что стартовый капитал желтого банка со школьных времен на завтраках сэкономлен :-)
Все крупные современные состояния нажиты самым бесчестным путем
:-)
Но, повторюсь, я не экономист и спорить о том, на чем банк больше всего зарабатывает аргументированно не могу. Просто по рейтингам вижу размеры активов, прибыль и т.п.
wepp
31.10.2023 07:11Судя по цитатам, кто-то видимо не понимает, что движение денежных средств не только в одну сторону происходит.
IamSVP
31.10.2023 07:11Добавьте тег "обработка изображений*", иначе я чуть не пропустил пост)
P.S. а вы все еще используете YOLOv4 в своих решениях?!
piton_nsk
31.10.2023 07:11+18Сейчас у нас много вакансий.
Разработчик C#
от 100 000 до 140 000 ₽ на руки
Требуемый опыт работы: 3–6 лет
Вакансия опубликована 12 октября 2023 в Москве
ALexhha
31.10.2023 07:11+33Ну по крайней мере не соврали, в заголовке так и сказано - "Приходите к нам на завод, у нас тяжело"
me21
31.10.2023 07:11+4Так и есть, мой опыт схож. Но у меня начальник адекватный, вышестоящему руководству сказал: "мы будем выполнять свои обязанности. Но если вы нам не можете платить по рынку, не мешайте нам зарабатывать недостающие деньги".
AnimeSlave
31.10.2023 07:11Байка из предыдущего места работы. Один из бывших (ушёл на повышение) Главных инженеров был согласен подписать на проектную работу по внедрению 1С ERP ООО открытое руководителем отдела ИТ, моим непосредственным начальником. И даже была договорённость с руководством завода таким финтом. Потому что зарплату не хотели повышать, так как управляющая компания поставила запрет на повышение зарплат работникам выше определённой планки. У них был типа расчёт бюджета на год на следующие три года. И этот бюджет превышать было нельзя без разрешения учредителя. А внедрение 1С ERP подходило под инвестиционную проектную работу и тем самым можно было подзаработать. В итоге ничего не случилось, так как проект утонул в бюрократии
UFO_01
31.10.2023 07:11+11IT отдел на подобных предприятиях — как обслуживающий персонал, который на прибыль производства влияет не так уж сильно чтобы тратиться на них
Devdmitry
31.10.2023 07:11+1Это жестокая реальность. Поэтому есть ощущение, что произврдству лучше субподряды заключать с ИТ-компаниями для решения проблем автоматизации, а у себя содержать небольшой штат тех.обслуживания этих решений.
alexEtse
31.10.2023 07:11тут несколько уровней этой проблемы:
1. Для не-ИТ компаний ИТ - это расходная, а не доходная, часть бюджета. Потому её стремятся сокращать.2. Но поскольку без ИТ работать не выходит, то это ИТ надо где-то брать.
3. При фултайм-занятости собственное ИТ выходит дешевле аутсорсного.
4. Но не всегда есть чем занять на фултайм ИТ-специалистов "по профилю". Если "не по профилю" - то есть и ИИ-систему написать, и картридж поменять, и кабель протянуть, и снег убрать, и вагон разгрузить, и это всё в одно лицо - то это пожалуйста, это с радостью займут фултайм... Только спецы по замене картриджей обычно не могут в серьёзный программизм, а серьёзные программисты не хотят в замену картриджей.
Вот потому и получается описанное - что-то серьёзнее обслуживания отдаётся на аутсорсинг, а иногда и обслуживание тоже.
domix32
31.10.2023 07:11Мне интересно а какие кейсы есть для AR на производстве? Не безкасочникам же каски дорисовывать.
Suharkov
31.10.2023 07:11+2Пожалуйста:
Например, на нескольких заводах «Роснефти» сотрудники больше года уже используют AR-приложения, которые позволяют сократить сроки строительства и реконструкции объектов, снизить операционные затраты, а также повысить эффективность работы сотрудников.
Кейс с «Собакой». Эта история — хороший пример, как AR-технология помогает справляться с целым спектром задач, типичных для промышленного предприятия.
В сочетании с программным обеспечением для 3D-моделирования и информационным моделированием зданий (BIM) промышленные компании могут создавать подробные интерактивные модели проектов и представлять их клиентам в начале проекта.
Прототип AR-помощника для РЖД. Решение содействует сотрудникам в проведении операций по обслуживанию электродвигателей.
И по ту сторону границы:
Among those adopting AR is the world’s largest military contractor, Lockheed Martin Corp., which is working with software developer Scope AR to develop how-to manuals that include animations for assembling spacecraft components.
Vodafone employees have been enthusiastic about the TechSee implementation. They report feeling empowered to help customers, especially in situations where the issue is complicated to describe or when there is a language barrier.
domix32
31.10.2023 07:11То есть по большей части либо планирование, либо эксплутационный справочник/инструкция. Понял принял.
Зачем AR в военке понятно.
mikerosoft Автор
31.10.2023 07:11+1Самый востребованный сценарий — удаленный эксперт. Опытная голова, сидящая в заводоуправлении или дома
в выходнойна удаленке, помогает неопытным рукам на месте в цеху что-то сделать или проинспектировать.
AnimeSlave
31.10.2023 07:11+11Вы этой статьёй мне такой флешбек устроили с предыдущего места работы. Я думал написать такую же статью. Огромное количество идей умерло потому, что не было людей, которые бы понимали, что это нужно. Особенно в руководстве таких людей не хватает. Заводу в большей части не нужны новомодные веянья IT. Но часто нужно, чтобы как у «западных партнёров», чтобы всё было автоматизировано, чтобы работников было минимум, чтобы обслуживалось быстро. И связано это с возрастом руководителей, или владельцев бизнеса «дядек из 90-х». Первые не понимают для чего это нужно, а вторые - понимают, но слишком жадные, чтобы идти на траты, которые не вернутся
Yuriy_krd
31.10.2023 07:11+1а вторые - понимают, но слишком жадные, чтобы идти на траты, которые не вернутся
Так, может, тогда не надо вкладываться в то, что не вернется ?
not-allowed-here
31.10.2023 07:11+2а как угадать? ROI он очень ветреный в таких инновациях - ОЧЕНЬ часто прогноз то хороший.... но вот как будет в реальности не всегда предсказуемо ибо реальный НИОКР иногда совсем не окупается.....
AnimeSlave
31.10.2023 07:11+4Простите, что отвечаю вопросом на вопрос. А как тогда развиваться, если денег на развитие не выделяются?
А теперь сам ответ на вопрос. Я был свидетелем того, как вкладывали деньги в проект, который по бумагам выглядел максимально прибыльным в кратчайшие сроки. Там было всё хорошо. И этот проект внедрялся под руководством непосредственно самого руководства завода. Этот проект конкурировал с проектом разработанным отделом, в котором я работал на тот момент. Проект отдела был забракован именно из-за того, что он не окупался. Детали я опускаю. По итогу проект руководства превысил бюджет на треть. Его тянули все, чтобы он хотя бы дошёл до стадии промышлено-опытной эксплуатации, так как проект был нужен руководству. На этой стадии выявили кучу проблем, которые нужно было исправлять, но для исправления требовались ещё вложения, на которые уже руководство не согласилось. С подрядчиком, выполнявшим работы судились за плохой результат. Суд проиграли, так как по бумагам всё соответствовало проекту.
Проект отдела же не мог окупаться, так как он фактически заменял старое оборудование, которое работает и приносит прибыль, на новое оборудование, которое приносит ту же прибыль. Новое оборудование с дополнительными возможностями, которые в будущем давали возможность реализовать новые проекты, которые точно так же, не принесут прибыли, но произойдёт смена старого оборудования новым с новыми возможностями. И предполагалось, что уже после смены всего старого оборудования улучшать техпроцессы, что в свою очередь улучшает качество продукции, ускоряет производство, удешевляет производство за счёт лучшего контроля. То есть вся эта комплексная работа, итогом которой предполагалась модернизация завода, растягивалась на 10 лет. В такой долгий период никто не даст гарантий, что что-то окупится, что что-то пойдёт не так. И поэтому ожидать от такого проекта прибыли глупо. Но и ничего не делать тоже глупо. Потому что вопрос окупаемости обоюдный, будет ли завод со старым оборудованием окупаться в следующие 10 лет, и риторический
Yuriy_krd
31.10.2023 07:11В такой долгий период никто не даст гарантий, что что-то окупится, что что-то пойдёт не так
Вообще я вот именно это и имел ввиду. Если Вложиться в развитие, которое принесет ничтожную прибыль или, с высокой долей вероятности, вообще ее не принесет - так делать не стоит. А если модернизировать либо полный цикл процессов, либо ключевые точки, которые, с высокой вероятностью помогут улучшить множество процессов, то я только "за" такую модернизацию. Все же, по моему мнению, отбросив явные форс-мажорные обстоятельства, можно посчитать примерную прибыль от той или иной модернизации.
AnimeSlave
31.10.2023 07:11Если Вложиться в развитие, которое принесет ничтожную прибыль или, с высокой долей вероятности, вообще ее не принесет - так делать не стоит.
Несколько ошибочное понимание. Здесь проблема не в неокупаемости, а в отсутствие доверия. Руководство не стало полагаться на людей, знающих завод, тех, кто хорошо понимал что и как работает. Правильнее было бы перефразировать ваш тезис в «Не стоит вкладывать в проекты, которые сам не понимаешь, особенно, когда не знаешь людей, которые этот проект внедряют»
not-allowed-here
31.10.2023 07:11+1эт еще повезло если старые производственные цепочки сохранить удалось при такой модернизации.....
есть куча отрицательного опыта когда само начало такой модернизации приводило не просто к разрушению цепочек, но и к банкротству всей организации.....
AnimeSlave
31.10.2023 07:11Форс-мажоры тоже влияют на ситуацию. Но как я писал выше вопрос, а как тогда развиваться? Волков бояться, в лес не ходить. Потому-то многие производства застряли в прошлом веке, так как модернизации оборудования нет. Говорят о модернизации постоянно. В новостях, то и дело мелькают сюжеты. А толку-то? Болтать - не мешки ворочать. Без модернизации самой модернизации не будет. На заводе, где я работал тоже была тема - «Год модернизации производства». Обосраться только успели за год. ERP внедряли почти пять лет. ТОиР внедряли два года, при том, что он уже был, делали переход на 1С ТОиР. Чтобы объединить процессы, и сэкономить на обслуживании отдельной системы, выкинув необходимость в отдельном специалисте
SpiderEkb
31.10.2023 07:11+9Наша история (кратко).
В далеком 1992-м году брат одного знакомого (учились на одной кафедре, он на год меня старше), работавший тогда коммерческим директором в конторе по монтажу и обслуживанию лифтов обратился с вопросом - а нельзя ли это хозяйство реализовать на высоком идейно-художественном уровне с применением современных технологий. Т.е. не тянуть от пульта ПД-32 в диспетчерской от каждой лампочки отдельную пару проводов до каждой релюшки не лифте, а чтобы и проводов поменьше и все на компе было - карта района, дома, лифты, чтобы сообщения что где стряслось человеческим языком...
Ну посидели, подумали, аналогов нет. Надо с нуля. Выстроили арзитектуру. Контроллеры самодельные, на 8080 (92-й год однако...). Три уровня - Головной (он по RS232 к компу), "магистральные" (уже RS485), "домовые"... К ним уже "клеммные доски" для подключения устройств. Софт диспетчера на компе под Win 3.11 (92-й год...)
Договорились, что контора финансирует, делает (небольшая производственная база у них была), монтирует и обслуживает. Мы занимаемся разработкой железа и софта.
Примерно через год-полтора выкатили пилотную версию. На все - две пары. Одна под данные, вторая под голосовую связь (с кабиной лифта). Потом искали кто согласится себе это чудо поставить. Нашли объект на условиях что контора за свой счет все делает, но потом берет объект на обслуживание (уже за деньги).
Все заработало, дальше уже стали развиваться. Появилась потребность в потребность в подключении домовых энергоконтроллеров (чтобы данные по общедомовому потреблению сами в диспетчерскую прилетали), еще что-то...
В конечном итоге все это развивалось и развилось до достаточно неплохого уровня - контроллеры на STM32, два уровня - УСО (устройство сопряжения с объектом) с набором клеммных модулей под разные типы устройств, IP-шлюзы (с одной стороны к ним УСО по RS485, другой сторону в инет смотрят по UDP). Голос по VoIP, возможность подключения видеонаблюдения и все дела. Вместо головного контроллера на компе работает "микроядро" к которому с одной стороны подключаются IP-шлюзы по UDPБ с другой, по TCP, интерфейсные клиенты (разных типов - администрирование и конфигурация, диспетчер, аварийные бригады...). Ядро реализует отношение "многие-ко многим", занимается фильтрацией-маршрутизацией, отслеживаете состояние IP-шлюзов и прочее и прочее.
Там уже была разработана классификация устройств, формализация их свойств, возможность подключения устройств "на горячую" без остановки системы, добавление новых типов устройств и т.п.
В разработке системы нас было от 4-х до 8-ми человек в разное время. Уже и конкуренты появились, которые по нашим следам шли.
К тому времени в конторе поменялось руководство, да и саму контору "прицепили" в качестве "структурного подразделения" к другой (достаточно бандитской, надо сказать).
И вот к моменту, когда была готова "коробочная версия" с полной документацией по монтажу, обслуживанию и эксплуатации и ее можно было просто продавать, нам сказали - "вы ребята, конечно, молодцы, но больше нам нафиг не нужны, мы теперь все это будем сами продавать, а вы свободны"...
Аргументы что система должна развиваться и поддерживаться иначе все это долго не проживет во внимание не принимались. "Ну вот там поставили, тут поставили - оно же все работает само, чего там поддерживать-то?"
На том все и закончилось в 2017-м году... Разошлись кто куда. Я в банк вот попал... Тут, конечно интересно (с учетом того, что попал в команду ядровых систем - это самое-самое сердце банка, центральные сервера и все такое), и команда отличная и руководство мегаадекватное и по деньгам все очень хорошо, но все равно иногда ностальгия прихватывает по той работе. Все-таки там что-то такое было... Какое-то "свое дело". Хоть и не всегда сытно (всякое бывало), но горели всем этим... Но вот так все уныло закончилось...
Лет пять там все точно проработало. В прошлом году звонили мне (я как раз микроядром занимался) - "там проблемы какие-то вдруг на одном объекте проявились, не посмотрел ли бы ты, мы бы заплатили..." Но тут уже обида взяла (расстались нехорошо - пытались всей командой в одну контору похожего профиля уйти, директор узнал, связался с ними, обгадил - типа зачем вам эти бездельники, сидят не делают ничего, только денег просят постоянно) - сказал что мой час сейчас стоит столько-то, вспоминать все это, поднимать старые исходники, про которые уже пять лет как забыл, что-то там править - неделя минимум, а с учетом что все это во внерабочее время, то умножаем на два (наши стандартные здесь расценки - есть вдруг что-то срочно в выходные делать, то двойная оплата идет). Так что извините, но у вас столько денег нет сколько это стоит.
SergeyMax
31.10.2023 07:11+1Так что извините, но у вас столько денег нет сколько это стоит.
Я не знаю, как там именно в лифтовом бизнесе, но обычно у бизнеса гораздо больше есть, когда на клиентском объекте проблемы.
SpiderEkb
31.10.2023 07:11+2Все, что связано с ЖКХ в глубокой ж... Там цены регулируются тарифными комиссиями и не соответствуют реальным затратам.
Rampages
31.10.2023 07:11+1Эта статья зашла очень хорошо, если вы напишете свою не намного хуже (а может даже лучше), то думаю желающих её почитать найдется много :)
Ну вы главное акцент на на руководстве делайте, а на решениях, которые приходилось делать в угоду руководству или другим факторам (отутствие бюджета, отсутствие доступных технологий на рынке, невозможность приобрести лицензии на ПО, низкая квалификация сотрудников и т.п. и т.д.).
Еще интересно почитать откуда берутся эти "как у западных партнеров", это какие-то виды предрассудков или промышленный шпионаж? или может тупо экскурсии по зарубежным заводам и попытка воспроизвести технлогии которыми не обладаешь?
VVitaly
31.10.2023 07:11-4:-) У вас проблемы с внедрением? А не пробовали делать нормальную аналитику?
К приведенному в статье примеру. Никто же и никогда не догадывался что бывают "солнечные зайчики" или "мокрые и грязные вагоны"... Это же просто "вершина аналитической мысли", и аджайл тут не поможет! :-)
inkelyad
31.10.2023 07:11+1Сделали свой, сферические вагоны в вакууме он определял хорошо. Потом приехало вот это:
Интересно, что дешевле (по отросли, у отдельного завода итд) - пытаться распознавать такое, или как только перестало распознаваться, так отправлять человека, чтобы от нормально нарисовал машинно-читабельный баркод подходящей краской, подходящим размером и подходящим кодированием, что защищает от всех этих зайчиков.
konst90
31.10.2023 07:11Может оказаться, что вагоны чужие, и ничего рисовать на них нельзя. И даже подновлять нельзя.
inkelyad
31.10.2023 07:11+2Выписываем штраф этому 'кому-то' за несоответствие тары ГОСТ номер.... (да, я фантазер, не понимающий реальной жизни)
kenoma
31.10.2023 07:11Иногда придется штраф выписывать самим себе, собственником вагона может быть ваше же предприятие из-за бюрократических препонов клавшее болт на правила нанесения трафаретных надписей на вагоны.
McKinseyBA
31.10.2023 07:11Хорошая статья. Пара вопросов:
S3 в частном корпоративном или стороннем облаке?Прочитал ответ в статьеGP - ванильный или аренадатовский?В целом тоже понятноХранилище, наверное "по звезде"?
В вакансии BI-аналитика Tableau, а на схеме только DataLens - чего еще нет на схеме компонентов?
По нынешним временам стэк прямо оптимальнейший из "без танцев" доступного
mikerosoft Автор
31.10.2023 07:11+1Да
На схеме платформа технологических данных. Вокруг ещё много чего есть. Например, tableau. Оно сейчас в основном используется для верхнеуровневой отчётности над SAP HANA и ограничено в масштабировании. Да и вообще, те данные которые собираются в техплатформе интересны много кому: всем интересны детали.
SeApps
31.10.2023 07:11А вы учитываете риск, что tableau ушел из России и может не продлить лицензию? Или у вас какой-то обходной путь? Или просто долго заменять?)
omgiafs
31.10.2023 07:11+1Кстати про номера вагонов. Почитайте про историю изобретения штрих-кодов.
И не ходите по чужим граблям.
Refridgerator
31.10.2023 07:11Ещё есть варианты с радио-метками, по две штуки на вагон. Дёшево, сердито, и направление движения вагона заодно можно отследить.
SergioT4
31.10.2023 07:11Посмотрите блог от НЛМК, там и про штрих и про радио для вагонов и т.п. было обжёвано уже.
Refridgerator
31.10.2023 07:11Зачем мне чужой блог, если я уже сам, своими руками, писал алгоритм слежения за вагонами? Правда, без нейросетей на питоне с биг дата и прочими новомодными технологиями - но зато и облака не требуются, чтобы все эти биг дата хранить. В обычную СУБД на обычном ПК всё помещается.
SergioT4
31.10.2023 07:11По вашему комментарию не понятно, абстрактные конструкции или реальный опыт.
Если я уже сам, своими руками, писал алгоритм слежения за вагонами
С использованием радио меток? Вагоны то не принадлежат заводу, как гарантировать, что все вагоны которые к вам приезжают, имеют радио метку.
inkelyad
31.10.2023 07:11+3Вагоны то не принадлежат заводу, как гарантировать, что все вагоны которые к вам приезжают, имеют радио метку.
Я продолжу быть непонимающим.
Есть два варианта.
1) Метка нужна нам самим внутри чтобы разобраться, что где стоит и что куда уехало на нашей территории. Вешаем (съемную, любой конструкции, хоть радио, хоть здоровенный лист с цифрами) метку на входе и снимаем на выходе.
2) Метка нужна для того, чтобы убедиться, что к нам приехал тот самый вагон, что нам кто-то прислал. Метку вешает тот, кто посылает. Возможно, договариваясь с владельцем вагонов. Который, в общем-то сам должен быть заинтересован в том, чтобы было хорошо, понятно и надежно помечено, что вагоны - именно его.
SergioT4
31.10.2023 07:11+3Я продолжу быть непонимающим.
Это как в анекдоте "ну и где альтернатива? -Утки!"
Если есть существующая маркировка, которая на 99% удовлетворяет и подходит для реализации существующими техническими решениями - то зачем выдумывать новые процессы? Для исключений (когда не распознаётся), надо запасной вариант иметь. В случаях с радиометками он тоже необходим. Пусть реже, но будут случаи отказов чтения метки.
Ну или если хочется на перспективу поработать, тогда надо собирать межотраслевую коммисию и вырабатывать стандарты и принять план их реализации РЖД и владельцами подвижного состава.
kenoma
31.10.2023 07:11Метки надо успевать считывать, если вагоны едут быстро, ваш способ не работает.
Refridgerator
31.10.2023 07:11Быстро, это сколько - 100 км/час? Не ездят на производстве вагоны с такой скоростью, и нет причин считать, что оптический считыватель с частотой кадров в 1/60 секунды (в лучшем случае) будет работать более надёжно. Пруфов с вращающимися винтами самолёта навалом. И, на непрерывном производстве вагоны ещё и ночью ездят. Как обстоят дела с оптическим распознаванием в условиях недостатка освещения?
kenoma
31.10.2023 07:11+1А человеку как считывать номер? Наличие человеко-читаемого номера на вагоне это залог того, что можно в случае отказа на дороге разрулить ситуацию вручную. Дублирование номера штрихкодом ненадежная процедура уже сама по себе.
omgiafs
31.10.2023 07:11+4Тут как в анекдоте - или крестик, или трусы.
Если ставим человека, то нафиг не нужен штрих-код. Если железяка - то она лучше читает штрих-коды, чем номера.
В идеале нужно дублировать: номер, а выше/ниже - штрих-код. И желательно, чтобы размеры и высота нанесения штрих-кода были (наверное, уже) регламентированы ГОСТ. И человекам удобно, и роботам проще без всякой биг-даты-сатанизма номера читать, буквально сканером.
Объяснение номерного дуализма - простое. Далеко не везде есть сканеры. Но сейчас, как и всю нашу жизнь - эпоха перемен. Поэтому людей на чтении номеров будет всё меньше, сканеров - всё больше. Поэтому именно сейчас (ближайшие лет 50 минимум), нужен именно дуализм. Это как воздух - вам он может не нравиться, но вы не можете им не дышать.
Затраты на краску, израсходованную на штрих-код, на порядки меньше затрат на датасатанизм, выстроенный для того, чтобы читать_номера_вагонов. Читать номера нейронкой - это оверинжиниринг в чистейшем виде. Оккам уже океан выплакал с современной "компьютерной инженерии", которая, ИМХО, погрязла в объёмах данных, плюнув на оптимизацию. Ну вот это самое классическое "писать браузер на C" против "писать браузер на Электроне".
konst90
31.10.2023 07:11+3Есть такая проблема, да. В прочностных расчётах её же регулярно наблюдаю - когда вместо простого аналитического метода используется тяжёлый численный без необходимости.
Картинка
MIKEk8
31.10.2023 07:11Кроме того двойной контроль. Если распознанный номера и штрихкода не совпадают, то дёргать человека чтоб проверял. Это в БД дублирование данных - это не консистентно, а в реальном мире один источник легко повреждается, и лучше иметь ещё один.
lazy_val
31.10.2023 07:11@mikerosoft На схеме среди источников данных не увидел SAP. Его прибили / не используется / прячется за
Oracle (3 БД)?mikerosoft Автор
31.10.2023 07:11+1Для нужд технологии SAP практически не нужен. А то что нужно, обычно доставляется до MES-систем классической интеграцией. И там уже доступно для ETL.
Moog_Prodigy
31.10.2023 07:11+40Всю жизнь не вылажу с заводов. Описанное автором - это проблемы верхних этажей) У нижних этажей проблемы похлеще будут, и все это - многогранное АСУТП:
Технологи валят на асушников за брак
Рабочие валят на асушников за брак
Древнее оборудование настолько древнее что приходится пылесосить авито на предмет старых компов
Древние системы под ДОС в настройках все запаролены, приходится изобретать системы взлома паролей. Это касается не только компьютерных систем но и например банальных терморегуляторов. За свои деньги покупается плата реле на известном китайском сайте (ИКС) , контакты реле подпаиваются к кнопкам, пишется самописная программа для перебора паролей, напротив экрана ставится видеорегистратор и вперед щелкание релюшками. Примерно на третий день ТРМ-ки или привода с запароленными настройками сдаются. Никто ж не предполагал, что кто-то будет сидеть и перебирать пароли с неудобной клавиатуры из 3 кнопок.
Крайнее недоверие людей к автоматике, имеющее под собой основание - сырые решения, некомпетентные технологи (а те валят на асушников), просто закоснелось рабочей мысли "я вот раньше там краник поворачивал ровно на столько, а теперь стоит хрень, что то показывает, вот брак и идет!". Между тем рабочие этим очень хорошо умеют прикрывать свои косяки, поэтому приходится ставить перед щитами, пультами и подобными вещами видеокамерами со своим хранилищем. И потом по мановению руки почти 70% отказов и брака исчезают сами собой.
Импортозащемление. Галимая китайская поделка повалила к нам, бренды отвалились, а ведь на том же сименсе работает куча промышленности первой категории (или как его там). Что же в основном предлагают китайцы? Ну в первую очередь это галимые датчики. Во вторую - это клоны сименса и мицубиши непонятно как среверсенные (допустим), с ними даже работает официальное ПО, но это все для ПЛК старых версий. А вот привода китайцы пока еще не научились импортозащемлять у нас. И это опять же головная боль асушников.
Зарплаты. На вахте при пусконаладке можно рубить хорошее бабло, чего не скажешь о заводе. Есть стеклянный потолок. Условно в нашей глубинке это 110 - 130 т.р. Но вилка начинается от 20. Кому то покажется для глубинки это прям много, но следующий пункт.
Личная жизнь оказывается лишним звеном в этой пищевой цепи. Особенно на производствах непрерывного цикла, ты будь готов что в выходной, что в отпуске - всегда рвануть на работу, потому что какие то параметры вышли из нормы, технологи трубку не берут, быстро приехал.
-
Перегорание и увольнение, с желанием в дальнейшем заниматься чем-то попроще, да хоть кассиром работать. Потому что вот вообще ВСЕ проблемы принято сваливать на асутп. Ибо их не понимает начальство (такое начальство почти везде), их не понимают рабочие (от них и не стоит этого ждать). Их не понимают отдел закупок "а чего это вы зипов на 20 млн заказали, не опупели ли?", их не понимают охранники, когда асушник тащит из дома самодельный программатор, тупо потому что на фирменный денег не дадут, а перепрошить микруху надо еще вчера. Их не понимают всякие местные айтишные структуры типа сисадминов, потому что очень много хитрого ПО - пиратское, а оформлять это дело на бумаге никто не желает. Их не понимают механики, которые вечно любят любую поломку списать на ПЛК, их даже электрики не понимают, потому что реле - оно понятно что реле, а вот эта непонятная хрень на экране - как она связана с реле, и вообще как реле связано с браком за прошлый месяц? Оно рабочее! Значит включалось и выключалось когда не надо! Это ваше. Любимое перетягивание одеяла заводских структур в случае асутп превращается в картинку, где один мужик тянет Боинг на канате. Стоит только добавить, что мужику поставлена задача разогнать самолет до взлетной скорости, а там двигатели запустит и сам взлетит.
Ну, вот вам еще чуть чуть незамутненной правды жизни. Заводы - это круто. Но не асутп.
Debianer70
31.10.2023 07:11+5Вот подпишусь под каждым словом. Сам асушник нижнего уровня. Всё так и есть. Зато от скуки уж точно не захиреешь, каждый день взрыв мозга и с разных, неожиданных сторон. Приходится и руками работать и головой думать/изобретать.
taras_82
31.10.2023 07:11-3Отличное средство для выгоранцев, или выгорастов.))))
Указанным категориям не возбуждаться с минусами. Лучше прислушаться к мнению врача!)
M_AJ
31.10.2023 07:11+6Ну да, постоянные проблемы, авралы и стрессовые ситуации это же отличное средство от выгорания. Надеюсь никогда не попасть к вам на прием, если вы действительно врач.
taras_82
31.10.2023 07:11-2Не переживайте, не попадете. Я работаю там, где мужики настолько суровы, что лечат от выгорания врача... самогоном, да. И иногда гитарой.
M_AJ
31.10.2023 07:11+6лечат от выгорания врача... самогоном, да
Я много лет на производстве отработал, не надо мне рассказывать про "суровых мужиков" советующих лечить стресс самогоном/водкой, я видел много таких не со стороны, а изнутри коллектива, и видел чем такое "лечение" порой заканчивается.
taras_82
31.10.2023 07:11То есть такой литературный прием, как гипербола Вам не знаком? А также такие общечеловеческие понятия как ирония, сарказм, ну и юмор, в конце концов.
Ну что ж, это печально. Я надеюсь, Вы не из России сейчас пишите. Воспринимать российскую действительность без изрядного чувства юмора сложно. В этом я с Вами согласен.
AleVaKa
31.10.2023 07:11+2Поверьте, выгорают там ещё как.
С таким отношение на заводах к АСУТП, даже на богатых нефтяных и газовых, многие хотят просто бросить всё и бежать, но страшно, «стабильность». А «программисты» АСУТП никому в «обычном» понимании программистов не нужны - не считается релевантным опытом.
Я вот почти 15 лет выдержал, больше не могу- последний год совсем не хочется видеть заводы, аппаратные залы, контроллеры. Тем более сейчас вместо привычных брендов всякое китайское начали завозить, совсем тоскливо стало.
taras_82
31.10.2023 07:11-6Да я живу в одной комнате с асушниками, наслышан. Просто утомили рассказы про выгорание человеков, весь день пиксели возящих по экрану. Ладно бы они алгоритмы новые изобретали, холдный термояд разрабатывали, а то копипастой в большинстве своем занимаются.
Вообще, IT стало в значительной степени тем, чем условные офисные планктонины были еще пару-тройку лет назад - просто способом хоть чем-то занять человека, дать ему видимость работы и на бедность деньжат подкинуть.
АСУТП хоть чем-то реальным занимаются. ИМХО, совсем бросать это дело не стоит, зарплаты скоро выровняются.SpiderEkb
31.10.2023 07:11+3Просто утомили рассказы про выгорание человеков, весь день пиксели возящих по экрану.
Так от того и выгорание. Однообразность и монотонность работы. Все одинаковое, все по типовым шаблонам.
И сколько бы за это ни платили, это унылый вариант работы.
MiraclePtr
31.10.2023 07:11ИМХО, совсем бросать это дело не стоит, зарплаты скоро выровняются.
Я такое уже лет десять, а то и 15 слышу, и что-то они не то что не выравниваются, а наоборот, разрыв становится еще сильнее.
taras_82
31.10.2023 07:11Я абсолютно согласен, что такая проблема существует. Может быть, вот такие статьи и помогут ее решить. Некоторые начальники тоже хабр почитывают. Это я вам точно говорю.
mayorovp
31.10.2023 07:11+3Да я живу в одной комнате с асушниками, наслышан. Просто утомили рассказы про выгорание человеков, весь день пиксели возящих по экрану. Ладно бы они алгоритмы новые изобретали, холдный термояд разрабатывали, а то копипастой в большинстве своем занимаются.
Возможно что термояд разрабатывать эмоционально проще чем "возить по экрану пиксели".
Термояд - игрушка дорогая, её на последние деньги не разрабатывают. Термояд - штука долгая, её разработать уже вчера не требуют. Термояд - штука престижная и крутая. Соответственно, у разрабатывающего термояд есть гордость за свою работу и время на отдых от неё.
У "возящего пискели по экрану" есть пять горящих задач в бэклоге, которые должны быть сделаны вчера и которые может сделать только он, и когда он завершает одну из них - появляется следующая, такая же срочная. Чтобы уйти в отпуск, нужно напрячься и закрыть все их них, только тогда можно отдохнуть уж две недели, после которых в беклоге будут ждать очередные пять горящих задач.
taras_82
31.10.2023 07:11+2У "возящего пискели по экрану" есть пять горящих задач в бэклоге, которые должны быть сделаны вчера и которые может сделать только он, и когда он завершает одну из них - появляется следующая, такая же срочная.
А вот тут есть повод приостановиться и подумать над тем, кому эти задачи вообще нужны, кому будет плохо, если их не сделать, и кому хорошо, если сделать. Только подумать глобально, а не в духе: "Ай, начальство заругает".
И вот на этом этапе, может быть к кому-то придет осознание: да ну нафик, может лучше на завод.mayorovp
31.10.2023 07:11+1А на заводе что, лучше?
atshaman
31.10.2023 07:11+1По разному. В целом, именно для IT'шников сколько-нибудь прилично "считать\нормировать время" не умеют, или умеют очень и очень фигово, с обеспечением равномерного потока задач тоже не очень, чтобы очень - из-за этого выходят разновсяческие перекосы от "плевания в потолок с 9 до 6" до хронической перегрузки - что вносит дополнительную "Эм" - "Мотивирующую" составляющую.
AnimeSlave
31.10.2023 07:11+4АСУТП хоть чем-то реальным занимаются. ИМХО, совсем бросать это дело не стоит, зарплаты скоро выровняются.
С развала СССР об этом говорят, и о деятельности специалистов в АСУ, и о зарплатах. Когда заводы приватизировали. Когда кризисы целых три штуки прошли. Когда ковид прошёл. Пока вы сами не будете работать инженером АСУиТП, вы никогда не поймёте проблем этой области
Wan-Derer
31.10.2023 07:11вместо привычных брендов всякое китайское начали завозить
Самое время делать своё, а не мучаться завозным. Тем более знаешь каким оно должно быть, а каким не должно :)
ALexhha
31.10.2023 07:11Самое время делать своё, а не мучаться завозным. Тем более знаешь каким оно должно быть, а каким не должно :)
там не все так просто, а точнее - все совсем не просто. Даже обычные реле и переключатели сделать сложно, а сделать массово/дешево и надежно на порядок сложнее
Wan-Derer
31.10.2023 07:11Если бы было просто, китайцы уже делали бы хорошо. А сложная вещь - как раз направление роста. В контроллерах нет никакой науки, надо просто собрать требования, посмотреть на прототипы и сделать не хуже. Люди, которые понимают в той или иной части этих контроллеров, у нас есть. Те кто делает не "так же внешне", а кто понимает зачем и почему сделано так, а не иначе. Осталось только собрать этих людей вместе и поставить им задачу.
MiraclePtr
31.10.2023 07:11+2"Знать, каким должно быть" и "смочь сделать самим как надо" - к сожалению, очень разные вещи. А без бюджета и экспертизы на выходе может получиться не меньшее говно, да еще и втридорога.
AnimeSlave
31.10.2023 07:11+9Древние системы под ДОС в настройках все запаролены, приходится изобретать системы взлома паролей.
О, да! Я сам на предыдущем месте работы взломал все запароленные ПЛК и SCADA системы, что использовались на тот момент. В моём случае было оправдание данному действию. Предыдущие работники отдела АСУ, те кто работали задолго до моего прихода, просрали всё что можно. Ни исходников, ни паролей, ни инструкций. Подписывали акты приёмки работ без уточнения, что всё будет передано им же для обслуживания. Подрядчики таким образом, по официальной версии, хотели защитить интеллектуальную собственность. Но по факту хотели посадить завод на договора обслуживания, когда выяснилось, что самостоятельно обслуживать оборудование на заводе не получится. А ведь всё это можно было обговорить ещё на этапе разработки проектов и учесть при подписании договоров. По итогу работники отдела АСУ до меня приняли великолепное решение - забить хер на обслуживание этих агрегатов. Так завод проработал 5 лет. Отдел АСУ к тому времени два раза сменился. На второй раз уже взяли на работу меня. Я тогда знатно офигел от бардака. И ломание ПЛК и SCADA - это была попытка бардак поправить. Часть подрядчиков, которые внедряли АСУ уже обанкротились и закрылись, поэтому получить от них какую-то информацию было уже не возможно. И заменить оборудование не представлялось возможным на тот момент, так как часть технологических процессов уже было завязанно на запароленное оборудование. Замену оборудования предполагалось реализовать уже после разбирания бардака. Чтобы можно было понимать как и на что менять.
Условно в нашей глубинке это 110 - 130 т.р.
Это у вас хорошая глубинка. В нашей глубинке я на страте получал 28т.р., это было в 2015 году. И к моменту увольнения в 2022 году - 51т.р. Выше нигде не платили. При том, что я был инженером по автоматизации, то есть ИТР. Завод, где я работал, был очень «веселым». Рабочие профессии по задумке руководства должны были получать больше чем ИТР, чтобы тем самым привлекать новых работников и оттока не было. Только рабочим платили всё равно меньше, чем у некоторых конкурентов, куда естественно работники уходили при удобном случае. А так как руководство слово своё держало, то ИТР платили ещё меньше. На что жаловались все ИТР ниже начальника цеха. В этой прослойке работников текучка была сильная. Оставались в основном те, кто либо никому был не нужен, либо для «перспектив» в будущем
Vladekk
31.10.2023 07:11+2Жесть просто. Неужели у программистов вариантов нет, что они согласны работать в таких условиях?
AnimeSlave
31.10.2023 07:11+3Зависит от ситуации. Когда это первая работа по специальности, то это «норма». Когда другой работы для программистов попросту нет, то же относительно «норма». Сейчас, с наличием удалёнки стало проще с поиском работы в глубинках. Я так работу поменял. Работаю на удалёнке теперь. А раньше либо так, либо переезд в другой город. И переезд в другой город это большие первоначальные траты, на которые ещё надо заработать, и лотерея с поиском работы для иногородних
Turist1971
31.10.2023 07:11В провинции очень мало вакансий у программистов, и самые денежные в моем районе это как раз на успешных заводах.
MiraclePtr
31.10.2023 07:11+1Один из главных плюсов профессии программиста - в том, что он не привязан к локации работодателя.
daggert
31.10.2023 07:11+2Тоже тот еще миф. Сколько знакомых программистов, особенно во всяких крупных корпорациях - единицы не привязаны к месту. У остальных либо правила безопасности, либо просто необходимость офисной работы в опенспейсе. Только парочка людей работающих в чем-то вроде смузи-стартапа работают удаленно, но там и зарплаты на порядок ниже чем у погромиста из финтеха.
SpiderEkb
31.10.2023 07:11+2Альфа Банк. С марта 2020-го на удаленке. Всех устраивает. Никто в офис обратно не гонит. Более того, сказали - кто хочет может отказаться от офисного компа совсем в пользу работы на виртуалке (VDI) или попросить перенести его на ферму (удаленная работа через RDP). Кто хочет - работайте на своем компе через VPN (но там есть ограничения по доступу к тестовым серверам).
Я в результате работаю на своем через VPN на 90%, что надо на сервере - через VDI (приспособил под VDI терминал старенький ноут по линухом). От офисного отказался совсем.
Moog_Prodigy
31.10.2023 07:11Я же указал что вилка зарплат начинается от 20 т.р. на полную занятость. Так что у вас еще нормально))
AnimeSlave
31.10.2023 07:11+1Начинаться вилка может и с МРОТ. У нас есть одно предприятие - местный аэропорт, где за МРОТ набирают работников каждый год. Очень смешно читать их вакансии. Работать-то идут не за МРОТ, а за максимально возможную по рынку в конкретной глубинке. И если у вас в глубинке возможно на АСУиТП заработать, грубо сокращая, 100т.р. в месяц, то у нас в глубинке этого сделать было нельзя, так как таких зарплат не было даже на крупных предприятиях. Максимальную сумму, которую я слышал от коллег по цеху, работавших как раз на одном из крупных предприятий, куда я хотел устроиться в бытность, была 80т.р. И это ведущему специалисту. И это были слухи, так как реальных цифр я не видел. В расчётках, что я видел своими глазами фигурировали 50-60т.р. Может быть что-то проектное было, и таким образом закрывали большие цифры, но это не стабильный заработок, а единичная премия.
100т.р. в месяц у нас могли получать 1С-ники, зная их рынок. Но я знаю несколько из них, и зная, что 1С-ники с радостью уйдут с завода, когда поднаберутся опыта (что знакомые и сделали, уйдя во франшизу), то врядли на заводе в нашей глубинке им платили 100т.р. Вообще не поверю
Devdmitry
31.10.2023 07:11Вот это "боль" инженеров асутп) С нетерпением жду от вас статей по проблемам асутп и их решениям)
Так может, корень зла как раз в асутп и находится? И начинать надо не с AR очков и распознавания картинок на Питоне, а проблем модернизации, мониторинга и контроля АСУТП?
Moog_Prodigy
31.10.2023 07:11+4Проблема не в асутп как области, а в том, как на нее смотрят остальные участники производства, начиная от собственника предприятия и заканчивая работягами. Как показывает опыт, им это в пень никому не уперлось еще с 50 годов (нет, я не такой древний, просто об этом уже тогда были звоночки, об этом писали в книгах и газетах, при этом плк и эвм еще особо не было, всякие командоаппараты и диспетчеризация, и называлось это немного по-другому).
Асутп - это сплав кучи технологий. Это программирование, электроника, механика, немного IT на уровне сисадмина - кое какой софт абы как не поставишь, там надо с бубном работать уметь, знать сети и их топологию, тут не езернет а профибас, понимать надо! Это еще и навыки следственных мероприятий... В итоге тебя ненавидят и делают козлом отпущения примерно все. Ну почти. Встречаются грамотные руководители, но их очень мало, и их наверху тоже не понимают.
Раз тогда асу не нужно, то зачем его все повсеместно внедрить то хотят? А ответ прост: карго культ. Ровно такой же культ как внедрение канбана, 5С и прочего мозголюбления участникам рабочего процесса. Потому что у конкурентов внедрили, кучу людей сократили, автоматика все сама. Ага. Купят дорогущую линию за очень крупные деньги, а потом внезапно дилер за диагностику хочет много, давайте нашего асушника припряжем, он шарит. А там все в паролях и на удаленный сервер телематику шифрованную шлет. Не оставили ни прошивок, ни таблиц настроек, сославшись на ноу хау. А ты после работы оставайся, производство то непрерывное.
AnimeSlave
31.10.2023 07:11+1Дай я тебе хоть в карму плюсану, чтобы брата по оружию поддержать. Я отмучился, сменил работу
GeorgeGutsol
31.10.2023 07:11+3В АСУТП главный и жирный минус - это зарплаты, везде средняя зарплата у инженера-программиста ниже, чем у backend-программиста. Поэтому и свалил от туда. Хотя надо признать, что сложность самих языков программирования у backendа выше, чем у языков в МЭК 61131-3.
Moog_Prodigy
31.10.2023 07:11Ладно бы просто инженер-программист. А то еще надо и в электронике шарить, порой даже на уровне приводов, сверху все приправлено плисинами и "академическими" аналоговыми схемами по 100 штук ОУ в одном устройстве, включенные хрен знает по какому принципу (ненормальное программирование знаете? Вот это про электронику). это не ардуино, и не усилитель и не гитарная примочка. Эта схема может управлять приводом в мегаватт мощи, и что случись..не надо об этом думать даже. Сложность асутп не стоит преуменьшать, потому что кто-то программы пишет в офисе, а кто-то и программы пишет и зашивает и налаживает это все, и бегает вечно помогает ошибку сбросить, а вот привод компрессора крякнул, что то с силовым модулем, это уже тянет на разборки минимум неделя. А какая неделя если даже пописать некогда сходить. А еще и каждого носом тыкнуть в косяк (большинство "поломок" это и не поломки вовсе), а заявки то летят пачками, начали внедрять электронные заявки ну тогда я и ушел. Любая тварь могла там заявок насоздавать, ну когда их набралось под 200 на одного меня, я не выдержал. Так работать - себя не уважать.
sim31r
31.10.2023 07:11Эта схема может управлять приводом в мегаватт мощи
Тут с отладкой сложнее как минимум. Не протестировать как юнит отдельный.
atshaman
31.10.2023 07:11+3А еще просто совершенно зашкаливающее количество мозго...гм...любли на пустом месте. Из любви к искусству, да. Заполнять доски, проводить линейные обходы, обклеивать ступеньки скотчем, "непрерывно улучшать процессы" (заполнения досок и обклеивания скотчем, преимущественно), ставить личные цели и отчитываться об их достижении, непрерывно развиваться (не забывая согласовывать индивидуальные планы развития и отчитываться об их выполнении), проходить инструктажи и сдавать экзамены по их результатам, подавать рационализаторские предложения (А давайте вот урну у заводуправления поставим. Ой, она больше 20 тысяч - не проходит по условиям, найдите дешевле. Да, вот вы. Сами-сами и найдите. Вы же идею выдвинули? Проработайте!) - при этом рядом обязательно найдется комсомолец-молодец за "5Эс, 6сигм, ПэЭсЭс" и вот это все, который...
И все это за каких-нибудь 30-50 тысяч, в условиях вида "когда идет дождь через дырку в крыше в кабинет капает" и пока образовавшаяся лужа не дойдет до удлиннителя и не долбанет уборщицу... впрочем, и после этого всем пофиг - разве что удлиннитель на скотч повыше прицепят.
Тьфу. Как вспомню - так вздрогну.
Moog_Prodigy
31.10.2023 07:11Ага, эти 5С порядком уже охренели, тут на предприятии ажно два случая ЧП за год (каждый = инвалидность) а они ходят крошки на столах выискивают, а в цех мы не пойдем, там нам мордочку начистят. От работяг до начальства. И правильно же сделают. Зато пыль на мониторе - предписание, устранить. Понаберут бесполезных, потом хоть изнутри запирайся, а им надо доказывать своб полезность. В тех цехах вообще болт на ТБ ложили, сам неоднократно видел кучкой сложенные за прессом оптические датчики безопасности. И в схему лазил - они закорочены все. Так что эти системщики пятиэсники - на производстве наипервейшие вредители! Знайте, и запоминайте.
mishkin79
31.10.2023 07:11+4Восторженно описывать костыли и дурдом на травмоопасном и сложном производстве(которое должно сразу проектироваться и внедрятся с учётом стандартов в отрасли)? Ваши решения пройдут хоть какие этапы сертификации? Куда потом обращаться и искать ответственных? На HH.ru? Очень странный оптимизм внедрения аппаратно-программных решений. Станки с помоек в некомплекте пришли?(там где я работал целые производственные линии с свалок Европы и дружественных республик привозили и в строй пускали). С копанием в прошивках плк, корочением концевиков(придумали буржуи всякого - станок с открытым силовым шкафом ошибку отрабатывает). Самим не надоело фигнёй заниматься? Извините. На шизанутый оптимизм уже коротить под вечер начинает.
lazy_val
31.10.2023 07:11Такое ощущение что комментарий в неправильной ветке оказался (здесь такое случается регулярно).
Он ведь не про исходную статью, а про комментарий выше.
Или нет?
ripvam
31.10.2023 07:11Статья фантастическая. Я на хабре только ради нее зарегистрировалась, чтобы подписаться на вас и не потерять. Сказывается, вероятно, любовь к заводам. У меня два за плечами)
SergioT4
31.10.2023 07:11+1про вагоны вы уже знаете. 25 копеек за фото на начало того проекта казались нам грабежом, поэтому мы решили писать сами. Через месяц мы подумали и решили, что есть некоторые темы, где лучше платить 25 копеек.
Если сами сделали,а потом переключились на вендора - то было бы интересно узнать, каково было качество распознования на самописном движке, против решения от вендора.
RomanSeleznev
31.10.2023 07:11Кстати, с софтом мы оказались сразу очень продуманными: вендорский иностранный не рассматривался в принципе в первых приоритетах, только опенсорс или отечественный
Софт для АСУ ТП тоже отечественный? Не Siemens какой-нибудь?
mikerosoft Автор
31.10.2023 07:11+1Тут про построение платформы техданных. В АСУТП конечно же все не так радужно и прекрасно... Хотя и там сейчас ребята стараются соскочить с иглы.
Obormottt
31.10.2023 07:11+3Наконец-то хорошо написанная статья, да ещё и вменяемым человеком на интересную тему.
но, как говорится, хорошая попытка, товарищ военком, но нет.
igorts
31.10.2023 07:11+1Молодцы ребята, интересно и технологично.
Есть еще одна тема - контроль достоверности первичных измерительных систем это датчики, измерительные трансформаторы и тд
Особенно актуальна проблема для больших систем, на тех же трубопроводах в системах линейной телемеханики десятки тысяч сигналов и измерений, на которые опираются система АСУТП и MES . При таком количестве в постоянном режиме будут врать сотни и тысячи датчиков.
Поверять их на регулярной основе и оч дорого и физически проблематично, нужны умные системы. Из за такой природы низовых данных зачастую приходиться накручивать ручную верификацию данных (типа АРМ ручного ввода, где диспетчер подтверждает полученные из систем телемеханики данные). Такая ситуация более характерна для распределенных территориально систем, месторождения, линейные участки трубопроводов и тд
Мы в свое время в рамках создаваемых систем делали простые функции контроля, например из серии что давление в трубе от насосной станции должно падать, если наоборот, значит ктото из двух датчиков врет и тд
Интересно было бы прикрутить современные технологии анализа данных к решению такого рода задач.
zatim
31.10.2023 07:11+1Мне кажется, простыми функциями контроля можно все решить. Во-первых, мажоритарное дублирование датчиков. Во вторых, все параметры так или иначе взаимосвязаны - если по двум трубам что то втекает, а по трем вытекает, то суммарные расходы первых должны равняться суммарным расходам вторых, про давление вы опять же написали. Ну и все в таком духе. Я даже не говорю про простой контроль исправности датчиков. Он уже давно аппаратный и автоматический в большинстве систем.
igorts
31.10.2023 07:11+1Был такой пример - выявили сломавшийся датчик температуры, начали смотреть дальше - оказалось все датчики одной партии вышли из строя в течении короткого периода.
SpiderEkb
31.10.2023 07:11+1Мы как-то столкнулись с забавной ситуацией - приходит пакет от контроллера. Отправляешь подтверждение что пакет принят. Приходит опять пакет с тем же ID. Опять подтверждение - "да принял уже...". Опять пакет, опять дубль... Потом поняли - у контроллера приемник и передатчик физический разнесены. Передатчик работает, приемник гавкнулся. Т.е. он пакет отсылает, на квитка на него не видит. Начинает перепосылки, квитка нет. В конечном итоге встает на паузу.
В итоге стали эти ситуации отслеживать - если пошли дубли, то сначала пытаемся "пинговать" контроллер, если не отвечает (не слышит "пингов"), генерируем отдельное аварийное сообщение - "подозрение на неисправность приемника".
igorts
31.10.2023 07:11буквально вчера, идут по modbus ошибки контрольной суммы, объект под землей, в шахте, ну думаю наводки в кабеле, но попробовали поиграться с параметрами опроса, сделали задержу 500 мс, между запросами - и все нормализовалось, судя по всему контроллеру крышу сносило при быстром опросе...
Ryav
31.10.2023 07:11+3Ну вот почему в развитых странах специалистам в сфере автоматизации нормально платят, а в РФ жалкие гроши? Жду, когда большинство переквалифицируется в нечто лайтовое и зарплаты в отрасли наконец-то пойдут вверх.
Статья хорошая, но не желаю вам привлечь хоть кого-нибудь с такими зарплатами.
igorts
31.10.2023 07:11+1Насчет жалких грошей с чего вы взяли?
Автоматизацией более 20 лет занимаюсь, с банками конечно не сравниться, но точно не гроши!
AnimeSlave
31.10.2023 07:11+2Ну вот почему в развитых странах специалистам в сфере автоматизации нормально платят, а в РФ жалкие гроши?
Банальная жадность. Не редко учредители компании (владелецы бизнеса), которая владеет заводом, или руководство этого самого завода это «дядьки из 90-х». У таких людей не редко на уровне конституции мышления такое. Их практически невозможно перевоспитать
MiraclePtr
31.10.2023 07:11+11Как человек, довольно долгое время проработавший программистом в промышленности, могу сказать - ну нахер.
Начать можно с АСУ ТП, а именно, программирование под ПЛК и всякие СКАДы. Само программирование в плане количества кода, абстракций, потоков данных и алгоритмов там довольно примитивное. Я бы сказал, АСУТП в сравнении даже с обычным энтерпрайзным веб-бэкендом - это как сборка конструктора Лего в сравнении со сборкой настоящего автомобиля. Но зато часто требуется очень широкий спектр знаний в электронике, электротехнике, теории автоматического управления, и в самой области процессов, которые вы автоматизируете (например, нефтехимии, металлопроката или пищевого производства). Довольно серьезные требования к надёжности, высокая цена ошибки. Короче говоря, знаний нужно очень много и очень разных, ответственность большая, а денег за это платят меньше чем джуну-фуллстеку на галере. Sad but true. Поэтому люди массово убегают из АСУТП даже в тот же вебдев, а остаются либо идейные, либо те кому лень поднять попу и что-то поменять.
С просто программированием на производствах (например всяких ERP, системах учёта, и т.д.) тоже не все хорошо. Во-первых, нередко руководство просто не представляет специфику рынка, и думает, что рыночные зарплаты программистов мало чем отличался от зарплаты любых других инженеров - что мы и видим по скинутому выше примеру на HH, где разработчику-шарписту (не джуну!) на заводе предлагают аж 100 тысяч рублей. И это в Москве. А даже если с зарплатами нормально, то ментально руководство обычно застряло в 90-х, а то и в 80-х годах со всеми вытекающими. Удалёнка, хомофис, раз работа не связана с поддержкой пользователей и железом? Никакого хомофиса, дорогой, каждый день приезжай обязательно, ну разве что может быть по пятницам не надо, если у начальника настроение хорошее. Гибкий рабочий график? Нет, ровно в 8 утра чтобы был на проходной, опоздаешь хоть на минуту - минус из премии. Отпуска планировать в начале года, потом поменять может не получится. Огромное количество всяких вышестоящих Алексей Ивановичей и Михаилов Петровичей, с каждым из которых надо все согласовывать. Если где-то фак-ап то начинается форменный цирк с массовым написанием служебок и спихиванием вины на соседний отдел... А если работа связана с командировками и разъездами по объектам... Нет уж, плавали-знаем, ни за какие деньги.
Vladekk
31.10.2023 07:11+5Круто, конечно, но сразу вопрос: зачем идти туда, где известно, что тяжело?
Стоит ли тратить свою жизнь, что зарабатывать другим деньги?
SpiderEkb
31.10.2023 07:11+1На самом деле зачастую тяжело - это интересно. Если всю жизнь сидеть и джейсончики туда-сюда перекладывать да кнопочки на формочках перекрашивать - мало что выгоришь быстро, так еще и тупеешь от монотонности.
Я выше про свою историю писал. И тяжело было и денег не всегда много... Но это было интересно и много чегготдало в плане профессионального развития.
MiraclePtr
31.10.2023 07:11Если всю жизнь сидеть и джейсончики туда-сюда перекладывать да кнопочки на формочках перекрашивать - мало что выгоришь быстро, так еще и тупеешь от монотонности.
Вы так говорите, как будто в IT-мире есть только две альтернативы - или тупо перекладывать джейсончики, или упахиваться на заводе (нередко за совершенно не соответствующие сложности работы деньги).
SpiderEkb
31.10.2023 07:11+1Я не конкретно про завод, но про "легко-трудно". Про то, что не стоит трудностей бояться, в них развитие.
У нас тоже нелегко. Первые полтора-два месяца просто Адъ - когда во всю это хтонь ускоренными темпами въезжаешь.
Потом, когда до определенного уровня доходишь и на тебя начинают кидать "задачки со звездочкой" и их у тебя в работе 2-3 "проектных" и одна "техническая" мозги просто кипят. Сделал одно, отдал в тест, переключаешься на другое (а оно совсем другое) - вникаешь туда, что-то придумываешь как все это лучше реализовать), тут с теста прилетает отбивка - нужно что-то где-то поправить - опять обратно лезешь...
Но в этом жизнь, ее так живут.
medvedel
31.10.2023 07:11+1На самом деле большинство АйТишников будут сидеть и стараться не связываться с реальными проблемами от них независящими за малые деньги.
Я даже сейчас ладно перешел с позиции где я что-то понимаю, на позицию где интересно и я мало чего понимаю пока, но в зарплате я не потерял.
Как ни крути, можно "спокойно перекладывать кнопочки" и набираться ума слушая лекции, а если еще деньги платят так вполне нормальный Бизнес.
Или?
raskal
31.10.2023 07:11@mikerosoft вам, коллеги, не мешало бы верстку на сайте поправить. Потому что по вашему мнению Благовещенск находится вот здесь
А на самом деле он находится в 6.5 тысячах километрах от этой точки. Статья, меж тем, неплохая, спасибо большое.
MiraclePtr
31.10.2023 07:11+2Все у них правильно. В России есть два Благовещенска, и это не шутка.
raskal
31.10.2023 07:11Если быть точнее, то в РФ есть два Благовещенска - один на Амуре, один в Башкортостане. А в том месте, где у них на карте написано "Благовещенск" находится, кажется, станица Благовещенская.
MiraclePtr
31.10.2023 07:11+1Точка у них на карте точка стоит как раз в Башкортостане, пусть и не совсем правильно (Благовещенск чуть севернее Уфы, а у них отмечен где-то на юго-востоке региона), но там ошибка всего в сотню километров, при таком масштабе можно простить.
FullMetalSqui
31.10.2023 07:11замечательная статья, давно так с упоением не вчитывался в текст, спасибо. мечтаю когда-нибудь реализовать проект по цифровазиции производства, но пока не удается состыковать готового к такому приключению клиента и компетенции в производстве(интегратор)
guility
31.10.2023 07:11Во-первых, привет коллегам от ML-команды Евраза =)
Во-вторых, классный рассказ про нюансы, мы что-то подобное регулярно рассказываем заказчикам "почему это так дорого" =)
В-третьих, что таки у вас по экосистемным решениям? =)
sherbinko
31.10.2023 07:11Тут много комментариев пишут о том, что зарплаты маленькие и печенек нет.
Но с другой стороны, а возможно ли как-то по-другому, с учётом того что упомянутые решения не выходят за пределы одного предприятия?
Скажем, когда я рисую кнопку на форме, этой кнопкой пользуются миллионы человек и даже если каждый заплатит по копейке, то уже хорошо.
Разве место программиста не в тех компаниях, которые ставят своей задачей максимально широкое распространение кода? Это кстати может быть сам завод, если бы он догадался продавать вышеупомянутые решения другим предприятиям в своей области.
Другими словами, для блага всего человечества, разработчики должны перейти к подрядчику, а завод - заплатить эти 25 копеек за распознавания номера на вагоне.
А на предприятии должны остаться люди которые умеют адаптировать существующий софт и дёшево/быстро реализовывать специфические нужды
ne555
На слог Каменистого смахивает:)