Промышленное программирование *

Сейчас рынок складской роботизации во многом строится на китайских роботах и готовых аппаратных решениях. И в этом нет ничего плохого: у китайских производителей сильная инженерная база, большой выбор техники и понятная экономика.

Но у такого подхода есть важная особенность, о которой часто вспоминают уже после покупки. За последние несколько лет мы не раз сталкивались с ситуацией, когда заказчик в попытке сэкономить фактически приобретает дорогой металлолом.

Логика на старте понятная:

На станах горячего проката металлургического комбината ЕВРАЗ НТМК прокатывают заготовки разных марок стали. В начале цикла их разогревают в печах до температуры, позволяющей придать нужный профиль. Печей несколько, они различаются конструкцией, состоянием, горелками и износом футеровки — это теплоизолирующий материал. Путь заготовки до первой клети стана тоже разный. Ещё на процесс влияют особенности серий заготовок, сортамента сталей, температуры перед посадом, текущее состояние агрегатов, время перевалки, плановые и внеплановые остановы.

Раньше операторы регулировали температуру, время нагрева, расход газа вручную, полагаясь на общую инструкцию, свой опыт и состояние печи (износ футеровки, работу горелок). В разных сменах был разный расход газа: где-то тратили меньше, где-то больше. А при смене сортамента (у нас 80+ видов заготовок) перерасход был почти гарантирован из-за затянутых переходных режимов. Мы стали смотреть, есть ли тут потенциал для экономии топлива.

Меня зовут Андрей Зотов, я начальник департамента инноваций ЕВРАЗа. В этой статье расскажу, как решили эту задачу с помощью обученной на наших данных рекомендательной системы с сердцем в виде математической модели. Заходите почитать, как это устроено.

Голосовое управление роботами часто выглядит как простая идея: человек произносит команду, робот ее распознает и выполняет действие. В бытовых сценариях мы уже привыкли к голосовым ассистентам, поэтому кажется логичным перенести тот же подход на складскую технику.

Несмотря на широкое применение систем параметрической диагностики и появившуюся тенденцию к внедрению систем предиктивной диагностики, количество отказов основного технологического оборудования на промышленных предприятиях России остаётся высоким. Зачастую причинами отказов являются несвоевременные и/или некорректные действия эксплуатационного персонала – это указывает на низкую квалификацию и/или дисциплину персонала. Практика показывает, что даже суровые наказания виновных в уже произошедшем отказе не повышают уровень дисциплины, так как такой подход не является системным – нарушения, не приведшие к отказу, не наказываются. Только системный подход к контролю эксплуатационного персонала позволяет исправить ситуацию.В статье описывается использование интегральных оценок для системного анализа эффективности действий сменного персонала. Эта статья ориентирована на технических руководителей промышленных предприятий.

Все промышленные компании, которые разрабатывают программно‑аппаратные комплексы (ПАК), могут получать IT‑льготы.

В этой статье разберём, как это работает, и почему выгодно зайти в реестр ПАК Минцифры уже в этом году.

В последнее время происходит фундаментальный сдвиг парадигмы от управления изменениями (проектами) к управлению ценностью (продуктами). Жесткие границы проектов (начало → конец) размываются, уступая место непрерывному потоку операционного производства (DevOps, продуктовая модель).

Если цель в классической модели ЖЦ - создать целевой продукт за конечное время, используя выделенные ресурсы, то в операционной деятельности - это постоянная и непрерывная поставка новый функциональности, добавляющей ценность заказчику от ее использования в ИТ-продукте. То есть стираются явные временные границы производства, “нарезанного” на проекты. Но это не значит, что прекращается измерение конечного успеха производства, просто диагностирование смещается из плоскости проектной деятельности в плоскость достижения бизнес-метрик. Что в свою очередь заставляет менять организацию производства, в частности: подходы к планированию и распределению бюджета (от фиксированных к периодическим), принципы формирования команд (от временных проектных к постоянным кросс-функциональным потоковым). Эти модели мы рассматривали ранее в “Части 2. Варианты организации производства”.

По существу, производство переходит после первого этапа внедрения минимальной функциональности (иногда MVP) в операционную деятельность, переплетаясь с процессами сопровождения. Зачастую операционка начинается еще до окончания формального конца проекта.

Заказчики все реже соглашаются на чистый Fixed Price (классический проект). Растет доля:

Эта статья является продолжением серии для демо-проекта на базе OpenPLC. В предыдущей части были рассмотрены программирование Raspberry Pi Pico W в режиме Modbus RTU/TCP Slave, управление реле через Ladder-диаграмму. Теперь пришло время добавить в схему CAN-шину.
Что добавляется в этой части: узел Pico W получает модуль MCP2515 и подключается к CAN-шине. Для этого в OpenPLC Editor написан пользовательский функциональный блок, который работает поверх ардуино-библиотеки и предоставляет доступ к CAN-шине из обычной Ladder-программы через глобальные переменные-маркеры %MW.

Итак, в первой части я смело пообещал вторую статью «из одних картинок», но… мой маленький часовой кукушонок настолько похужал и возмудел за прошедшее время, что пришла пора знакомиться с ним, можно сказать, заново. Оптимизация не пощадила практически ничего, и, хотя я там же в камментах бо́льшую часть перемен отразил — всё равно надо начать с того, что же в сумме у нас получилось.

Что общего между крышечкой от колы, трубой в ванной, медицинской маской и подгузником Huggies? Полипропилен — один из самых популярных пластиков в мире.

Привет! Меня зовут Игорь, недавно я побывал на одном из заводов — «Томскнефтехим».

В предыдущей статье мы подключили CAN bus к STM32-IHM03, настроили базовую коммуникацию и запустили управление PMSM-двигателем. Теперь пришло время расширить проект — добавить в него периферийный микроконтроллер в качестве удалённого I/O-узла и организовать логику управления с помощью OpenPLC.

В этой статье мы рассмотрим, как подключить Raspberry Pi Pico W по Modbus RTU к одноплатному компьютеру Orange Pi, запрограммировать микроконтроллер в среде OpenPLC Editor на языке контактно-релейных схем (LD) и удаленно управлять реле по Modbus. Попутно разберёмся с настройкой шилда RS485 CAN HAT, адресацией пинов и регистров.

В предыдущей статье "Облако своими руками для расчета пространственных стержней методом конечных элементов на Node js, React js и Three js" представлен краткий обзор облачного SPA приложения ammonit3d по моделированию пространственных стержневых систем (ферм, балок, рамных и связевых конструкций, опор ЛЭП) методом конечных элементов с численно-аналитическим решением для каждого конечного элемента, в основе которого математическая модель Эйлера-Бернулли - механическая модель упругой балки или стержня длиной L с заданной изгибной жёсткостью EJ на которую действуют сосредоточенная сила F или момент M, а также распределённая сила q(x) или момент m(x) по длине стержня, продольная ось которого x1, вертикальная x2 проходит через начало стержня и x3 направлена на нас из точки пересечения x1, x2. Полагая сечения плоскими до и после изгиба при одноосном деформированном состоянии в рамках краевой задачи линейной теории упругости, уравнение упругой оси стержня можно представить в виде обыкновенного неоднородного дифференциального уравнения 4-го порядка:

Современное производство формирует большие объемы разнородных данных на всех этапах жизненного цикла изделия. Практическая ценность больших данных в производстве заключается в возможности их анализа и использования для принятия решений. В этой связи Data Science рассматривается как ключевой инструмент, интеграция которого в производственные процессы позволяет извлекать практическую ценность из больших данных и повышать эффективность производства.

В статье рассматриваются принципы и ключевые понятия цифрового производства. Приведены основные направления применения Data Science в цифровом производстве, а также рассмотрены проблемы и перспективы его развития.

В СИБУРе я отвечаю за разработку сервиса видеоаналитики. По сути, это система, которая в реальном времени обрабатывает видеопоток с камер на нефтехимических предприятиях. Камеры следят за технологическим процессом: считают продукцию на конвейере, определяют уровень жидкости в колбах, проверяют наличие касок на людях. Результат нужен в течение пяти секунд, потом уже поздно.

Представьте: пациент приходит на приём. Врач выслушивает жалобы и назначает обследование. Температура, общий анализ крови, рентген грудной клетки, УЗИ, мазок из горла – стандартная карточка. Часть из этого действительно нужна. Часть – назначается по привычке, «чтобы не пропустить».

Теперь вопрос: можно ли математически доказать какие симптомы несут реальную информацию о диагнозе, а какие – просто "шум"? Можно ли взять таблицу пациентов и получить на выходе точный ответ – вот эти три признака обязательны, этот четвёртый заменяем, а пятый почти бесполезен?

Оказывается, можно. И для этого не нужны нейросети, градиентный бустинг или сотни тысяч записей. Достаточно бинарной матрицы, красивой идеи из теории множеств и нескольких строк кода.

Сразу сделаю честную оговорку: я не врач и не претендую на медицинскую точность. Таблица пациентов в этой статье составлена по общедоступным представлениям из интернета – какие симптомы обычно сопровождают грипп, бронхит, пневмонию. Настоящие врачи составят такую матрицу куда точнее – на основе реальной клинической практики, статистики, протоколов. Моя цель другая: показать как математика может помочь врачу структурировать знания и найти в них закономерности. Не заменить клиническое мышление – а дать ему инструмент.

Медицина здесь – удобный и понятный пример. Тот же подход работает в промышленной диагностике, в анализе анкет, в задачах отбора признаков для машинного обучения, в системах поддержки принятия решений. Математика универсальна – меняется только предметная область.

В этой статье мы возьмём таблицу из 12 пациентов и 7 симптомов, переберём все возможные комбинации признаков, найдём те наборы которые позволяют однозначно поставить диагноз – и посчитаем вектор значимости каждого симптома. Реализацию сделаем в среде Engee на языке Julia.

В АСУТП разработчику как правило приходится иметь дело с Legacy. Оборудование работает десятилетиями, системы управления стареют вместе с ним. Это не отменяет потребности в периодической модернизации, которая, за давностью времен, прошедших со времени первоначальной установки, зачастую превращается в восхитительный квест. Когда собираются вместе три «Всадника Апокалипсиса» Индастриал-дева: Сименс, Майкрософт и Хьюлетт-Паккард, скучно долго не будет.

В этом тексте я написал про то, как составить крохотный, но очень полезный загрузчик.

В программировании на STM32 бывает нужно сделать так, чтобы загрузчик оказался не в начале Flash памяти, а в конце.

Поэтому надо написать отдельную крохотную прошивку первичного загрузчика, которая при старте передает управление на другой адрес в физической памяти.

Современная разработка погрязла в driven, first и based подходах, недавно этот зоопарк пополнился еще одним заморским зверем под названием AI-driven (пусть меня простят свидетели AGI, но я сознательно не выделяю этот подход на фоне остальных и в конце объясню почему). Но не пытаются ли все эти подходы на самом деле решить одну и ту же проблему, известную еще с середины прошлого века, проблему "абстрактного перехода"?

CoreBus — кроссплатформенный терминал для работы с COM-портами и TCP-сокетами с поддержкой протоколов Modbus TCP / RTU / ASCII и много чего еще.

Приложение развивается уже довольно давно. Но была одна фича, которой не хватало, чтобы сделать CoreBus по-настоящему универсальным терминалом. Мне об этом писали еще с первых релизов. В личных сообщениях и в комментариях к статьям. Эта идея формулировалась по-разному, но суть была одна.

И поэтому хочу представить вам новый режим - "Modbus мониторинг"!

Недавно я опубликовал мнение о фундаментальной экономической модели разработки ПО, которая не способствует (и объективно не должна способствовать) массовому переходу с C/C++ на «безопасные» языки программирования Экономика безопасности кода или почему Rust не нужен.

Но чтобы оставаться честным перед читателями, решил опубликовать и статью-контраргумент с описанием обратной стороны медали, то есть почему C++ всё равно будет рано или поздно заменён, а заодно попробовать разобрать, каким будет новый язык программирования, который неминуемо придёт на смену C++.

Запуск нового устройства — это всегда выбор. Один из первых и самых непростых вопросов, с которым сталкиваются как стартаперы, так и крупные компании при выводе нового продукта на рынок: стоит ли разрабатывать уникальный корпус с нуля или лучше использовать готовое покупное решение?

Кажется, что для опытных разработчиков ответ очевиден, но на деле он далеко не однозначен. Чтобы этот вопрос не стал для вас камнем преткновения, давайте разберем несколько практических примеров. Наш обзор поможет вам взвесить все «за» и «против» и принять верное решение.