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

Привет, Хабр! Меня зовут Александр Коваленко, я младший научный сотрудник группы «ИИ в промышленности» в AIRI. В область наших интересов входит применение систем искусственного интеллекта в процессах различных предприятий. И, как и многие аспекты промышленной деятельности, промышленный ИИ может быть атакован злоумышленниками.  

Эта статья будет посвящена влиянию состязательных атак на системы диагностики неисправностей. Искусственный интеллект в нашем случае представлен классификаторами на основе нейронных сетей, а в качестве данных выступают сигналы с датчиков, образующих многомерные временные ряды. Я постараюсь объяснить, зачем вообще все это нужно, приведу обзор известных на сегодня методов состязательных атак и способов защиты от них, а также кратко расскажу про наши успехи, представленные в недавно опубликованной с коллегами из ИСП РАН статье Adversarial Attacks and Defenses in Fault Detection and Diagnosis: A Comprehensive Benchmark on the Tennessee Eastman Process.  

Приятного чтения!

Это история из цикла «как войти в IT», написанная старпером, ветераном броуновского движения, который помнит динозавров. Поэтому его опыт вхождения в ИТ никому не пригодится, но представляет интерес с точки зрения истории.  

Также поделюсь своим мыслями об интерфейсе инженерного ПО. Участвуя в разработках различного ПО, предназначенного для ускорения разработки сложных систем, периодически приходится выслушивать жалобы от новых пользователей на «кривой и устаревший» интерфейс ПО. Однако инженеры, погруженные в проблемы проектирования реальных железок, вообще не задают нам таких вопросов, либо потому, что уже искривили свои руки о кривой интерфейс, либо им это вообще неважно. Более того, есть два примера, когда реальные высокопрофессиональные инженеры в своей области предъявляли претензии обратного свойства, и первая версия кривая версия GUI была удобнее, а вот улучшения делали какие-то полупокеры. 

К написанию данного текста меня подтолкнула беседа с одним из крутых разрабов из «жирной» конторы, с которым мы пересеклись на яхте в Средиземном море. Узнав, что я тоже из Бауманки, и у меня свой бизнес, он заинтересовался и выспрашивал. Как я смог начать бизнес на софте, почему не пошел в большую контору, типа Yandex, Сбер и прочие. У него тоже знакомство с софтом началось как создание собственной разработки по анализу результатов металлургических испытаний в лаборатории, но закончилось работой прогером по найму. Попивая вино на яхте где-то между Турцией и Грецией в 2023 году, он предположил, что, возможно, если бы он продолжал писать софт для металлургических исследований, то, наверное, сейчас мог плавать на своей яхте, а не арендованной, и не около Турции, а на Карибах (но это не точно). А поскольку фарш невозможно провернуть назад, я решил описать свою историю успеха, так как она забавна и поучительна.

Наш предыдущий пост вызвал много вопросов. Мы были готовы к тому, что будут комменты по инструктажам по ТБ, вопрос об электронном подписании которых мы рассматривали и который может быть неоднозначным и дискуссионным. Однако не ожидали, что люди будут ставить под вопрос законность и саму возможность цифровой трансформации нарядной системы в России в рамках существующих законов. В этом посте попробуем обстоятельно ответить на вопросы, возникшие под предыдущим постом. По вопросам @Regennon@qyix7z@red_dragon и др.

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

Алгоритм очень простой: нужно замечать случаи, когда расход ресурсов превышает средний статистический.
Пример: В доме бабушки Марфы из соседней квартиры уже два часа подряд течет вода. Вряд ли она столько моется в душе или моет посуду. Скорее всего, у неё в доме прорвало воду (хотя её может прорвать до счетчика, тогда утечки мы не увидим) либо ей стало плохо и она не закрыла кран. Аналогичные случаи про газ и свет. Вряд ли вы будете готовить на плите несколько часов или не выключать свет, телевизор, прочие электроприборы больше 12 часов, для примера.

Резюмируем

Мартышка и АйТи: Парадокс сложной эффективности

Вы когда-нибудь задумывались, почему в IT всё циклично? Почему старые методы и технологии, которые когда-то были на пике популярности, возвращаются на сцену?

Давайте разберёмся, что такое Парадокс сложной эффективности на простом примере, а также посмотрим, как это работает в IT последние 30 лет.

Компания Honeywell выпускает хорошие контроллеры для автоматизации и диспетчеризации промышленных объектов и коммерческой недвижимости.

В одном крупном московском ресторане предположительно из-за скачков напряжения сгорел контроллер Honeywell, но поскольку компания ушла с российского рынка, то встал вопрос технического сопровождения существующих решений, не говоря уже о новых проектах.

На помощь пришел интегратор и решил проблему. Интересно как? Ныряйте под кат.

PLC.JS — первый по настоящему свободно программируемый контроллер

Мы — небольшая команда инженеров в сфере автоматизации, и у нас есть мечта: чтобы инженерные профессии в сфере АСУ ТП стали престижными и уважаемыми в нашей стране.

Метод, который мы считаем наиболее эффективным в решении данной проблемы, — это снижение порога вхождения ИТ-специалистов в АСУ ТП и их «удержание» в отрасли с помощью популяризации GNU/Linux IIoT-устройств.

Только так, на наш взгляд, отрасль может стать привлекательной для молодых ИТ-шников и выйти на новый уровень.

Когда автоматизируешь какой-то производственный бизнес-процесс, нужны экспертные знания именно в предметной области. Приходится погружаться в химию и физику процесса. В результате решаешь комплексную инженерную задачу. Делать интернет-магазин тоже сложно, но для меня не так интересно с точки зрения расширения кругозора. В промышленности меня вдохновляет близость к процессам и потрясающая визуализация: ты видишь результат своей работы.

Много интересных кейсов связано с применением ИИ. Например, интеллектуальная видеоаналитика для оценки процента шлака в ковше и качества заготовки. С помощью ИИ нам удалось достичь точности 99,98% и низкого показателя ложных срабатываний. Нейросеть пропускает брак лишь в 0,02% случаев. Конечно, благодаря этому качество продукта выросло. Кроме того, мы получили объективный инструмент анализа. Система помогает человеку обнаружить отклонения и подсказывает об этом своевременно, что повышает выход годного. Если одна за другой идут бракованные заготовки, значит, где-то на предыдущем этапе нарушен техпроцесс, и коллегам нужно об этом сообщить.

Графические языки программирования

Изобретатели языка FORTRAN стремились создать такой язык программирования, который был бы понятен человеку. По сравнению с ассемблером FORTRAN более понятен, но все равно не так понятен, как английский. Поэтому движение к упрощению языков программирования продолжалось и дошло до того, что программы сегодня можно не писать текстом, а рисовать диаграммами.

Забавно, но это наглядное подтверждение, что развитие идет по кругу или, точнее, по спирали. Первобытный человек сначала рисовал истории на стенах, потом люди придумала алфавит, потом другие умные люди придумали формулы для математических расчетов, потом другие не менее умные придумали для них счетные машины, потом для счетных машин придумали алфавит – ассемблер, потом язык FORTRAN, и, наконец, появился графический язык диаграмм. Круг замкнулся! Люди вернулись к рисованию, но на другом уровне развития, а все потому, что это удобнее и экономит время на понимание. Очевидно, что рисунок понять легче чем текст, особенно когда текста многие килобайты, как в современных библиотеках и фреймворках, в которых сам черт ногу сломит. 

Что говорят стандарты?

Обратимся к  МЭК 61131-3. Там описано два чисто графических языка программирования:

 FBD (Function Block Diagram) — графический язык программирования стандарта МЭК 61131-3. Предназначен для программирования программируемых логических контроллеров (ПЛК). 

LD (Ladder diagram) — язык релейно-контактной логики.

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

Всем привет! На Хабре я новичок, решила поделиться своими скромными идеями и выслушать ваше мнение, возможно, вы дадите мне дельные советы.

Отработав три года, как инженер по нормированию труда, я поняла, что основная моя работа связана с тем, чтобы качественно и быстро обработать большие объёмы данных. Порой данных было так много, а времени просто не хватало, отчего зависал Excel или просто возникали ошибки в формулах.

Поэтому я решила хотя бы частично автоматизировать процесс расчета нормы времени на изготовление различного рода деталей.

Для начала у меня есть таблица Excel, где в левой части таблицы представлена выгрузка деталей из программ CAD. В моем примере это стандартные накладки, которым требуется фрезерная обработка.

У нас производство с небольшой город, и целая куча направлений: одно подразделение собирает роботов, другое занимается видеоаналитикой, кто-то делает лайтовый анализ данных, а кто-то шаманит с хардкорными дата-сетами. Работы всегда больше, чем рук. С точки зрения IT у нас большая ERP-система. Там крутятся закупки, планы производства, CRM, заказы, поставки и тому подобное. ERP отправляет запрос в MES, систему управления производством, которая формирует задания для смен. MES соединена с АСУТП, которая автоматизирует всё, вплоть до правильного раскроя металла. Далее контроллеры, исполнительные механизмы и датчики. Вокруг этого автоматизация кадров, электронные журналы и прогнозы спроса. Поэтому куда сейчас без IT? IT везде. Никто уже на бумажках работать не хочет и не может. И металл без IT не плавится. Чем сложнее установка, тем больше IT внутри.

Мы тестируем медицинское оборудование, поэтому знаем, какие требования закон предъявляет к процессу тестирования. Каждый протокол теста — это документ, который контролирующий орган может проверить.

Здесь упор делается на тщательно выверенные формулировки. Кроме того, отчет должен быть оформлен надлежащим образом.

В программировании микроконтроллеров приходится определять порядок инициализации прошивки. Порядок тут всегда имеет значение.

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

Чтобы всё это работало надо соблюдать правильный порядок инициализации.

В этом тексте я представил формальный алгоритм определения этого порядка.

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

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

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

Раньше для управления линиями устанавливали контроллер Delta и соответствующие модули, но с поставками сегодня очень большие проблемы: несмотря на наличие нескольких дилеров, сроки увеличились до полугода, цены стали космическими. Как уложиться в регламент и что со всем этим делать? 

Устав решать проблемы, инженеры Levrana Engineering решили сменить производителя контроллера и сопутствующего оборудования. В статье мы расскажем, какие подводные камни при это возникли и как с ними удалось справиться.

В этом тексте я написал о некоторых подходах к организации кода для микроконтроллеров.

Основная идея - массив наша основная скрепа.

Главные достоинства представленной архитектуры - это простота поддержки, сопровождения и масштабирования кодовой базы.

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

1. Мы живём в Липецке и хотели бы, чтобы он и дальше оставался самым чистым городом металлургов в России.
2. Это снижает КПД печи.

Мы живем в неспокойное время. Импортозамещение набирает обороты, но местами буксует как немецкий танк семейства кошачьих в украинской грязи. При чем даже за такое трудное и медленное движение вперед «спасибо» нужно сказать нашим уважаемым партнерам. Без них ничего бы не происходило вообще ничего от слова «совсем». Наши западные «партнеры» пытаются отрезать Россию от передовых инженерных технологий, и мы вынуждены, как те мыши из анекдота, «колоться, плакать», но пытаться съесть кактус.

...Гуд бай Америка о – о – о 

где я не буду никогда 

нас так долго лечили 

любить твои запретные плоды...

В статье мы расскажем как перестать любить Америку и полюбить Китай.

Привет, Хабр! Меня зовут Илья Ульянов, я архитектор информационных систем и руководитель проекта «Охота на риски» в ЕВРАЗе. Расскажу вам, что необычного в дизайне этого проекта. 

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

Заядлый геймер, выполняющий задания за вознаграждения и место в рейтинге, — далеко не первое, что ассоциируется с суровыми горняками и металлургами. Где видеоигры, а где техника безопасности и мониторинг инцидентов? Командная работа, ачивки, тематические сезоны — этого не может быть в цехах. Или может?

Реальность, как это нередко бывает, оказалась куда неожиданнее самых смелых предположений. Идея совместить две, казалось бы, слабо совместимые вещи принесла хорошие результаты. О том, как мы запустили мобильное приложение “Охота на риски”, рассказываем в этой статье.