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

Многие из тех, кто подходил к нашему стенду на ЦИПРе в этом году, пытались угадать – «О, это Microsoft Flight Simulator?» или – «Вы что, игры разрабатываете?». Возможно, порой стоило согласиться – для непосвящённых наши демонстрации визуально больше похожи на игры. Но представьте себе игру, которая учитывает каждый параметр движения самолёта – от трения элеронов о воздух до запаздываний при передаче данных в системе управления. Игру, которая работает в режиме жёсткого реального времени и по мультиплексному каналу информационного обмена (МКИО) взаимодействует с бортовым оборудованием. Это уже не просто описание физики полёта, система управления или игра для PC. Это всё и сразу! Как так получается, мы с вами разберём по порядку:

В 1950 году математик по имени Клод Шеннон опубликовал в журнале статью «Как запрограммировать компьютер для игры в шахматы». В этой статье он подсчитал, что количество комбинаций в шахматах будет равно 10¹²⁰. Это на самом деле превосходит количество атомов в известной Вселенной, которое оценивается от 10⁷⁸ до 10⁸² атомов. Но среднестатистическому шахматисту для успешного старта не обязательно изучать все существующие варианты начала игры, а достаточно выбрать несколько популярных дебютов за каждый цвет. По факту это использование формализованных шаблонов успешных тактических позиций для достижения желаемых результатов.

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

Приспособленец (Flyweight) - структурный паттерн проектирования, который нужен для эффективной работы с большим количеством мелких объектов.

Основная идея: разделить общее состояние объектов и вынести его в отдельное место, чтобы не плодить кучу дубликатов данных и экономить место.

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

Одним из важнейших этапов в проектировании Информационной системы является выявление бизнес-объектов и их детализация на сущности Предметной области. По результатам этих активностей можно спроектировать модель хранилищ данных. Чаще всего такие работы выполняют параллельно с этапом описания бизнес-процессов.

Как всегда, объявим цели текущего шага: определить и задокументировать сущности Предметной области и способы их взаимодействия. Спроектировать модель хранилищ данных.

Таким образом мы расширяем наш домен решений, добавляя в него – модель данных.

Чтобы сложить картинку о бизнес-объектах области автоматизации, необходимо уметь описывать бесконечное разнообразие сущностей мира - конечными фразами.

Это можно сделать огрублено, приблизительно, упрощенно.

1)   Первый шаг упрощения основан на том, что все объекты различны, но одни отличаются друг от друга «слабо», «мало», «незначительно», другие — «сильно», «существенно».

2)   Второй шаг состоит в том, чтобы объединить все мало различающиеся объекты в одну группу, оставив вне ее все сильно различающиеся.

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

Для выражения различий между классами им присваиваются различные имена (названия, обозначения, символы, номера и т.п.).

Классифицировать можно не только объекты, но и свойства (цвета, звуки, силы, размеры и т.д.), и процессы (ходить, бегать, тянуть, есть, пить и т.д.). Таким образом, классификация сущностей исследуемой предметной области идентифицируется в виде названия некоторых классов.

Как мы перестроили производство под санкции и сохранили эффективность

Привет, Хабр!

С вами снова Дмитрий Лохов, генеральный директор TAPP Group. В прошлой статье я рассказывал о том, как внедрение нейросетевых технологий помогло нам добиться 15% роста извлечения полезных компонентов на обогатительных фабриках. Сегодня хочу поделиться еще более масштабным и сложным опытом — как наша компания и вся отрасль пережили санкционный шок 2022 года, научились работать в новых реалиях и даже нашли неожиданные возможности для развития в этих непростых условиях.

Я расскажу, какие решения сработали, а какие оказались тупиковыми, как менялась стратегия под давлением обстоятельств и какие уроки TAPP Group извлекла из этого кризиса.

Эта статья будет интересна:

Один из популярных инструментов BPMN (Business Process Model and Notation) — стандарт графического моделирования бизнес-процессов, разработанный Object Management Group (OMG). Он широко используется для визуализации, анализа и оптимизации процессов внутри организаций.

Но в отличие от прочих нотаций, BPMN может использоваться совместно со специальным BPM-движком (engine), встроенным в различные ИТ-платформы. То есть бизнес-процессы, описанные с помощью BPMN, не просто визуализируются, а управляют логикой выполнения в реальных ИТ-системах, превращая нотацию в исполняемый код, который интерпретируется движком, При этом продвигая процессы в соответствии с описанной в диаграммах бизнес-логикой, BPMN-движок следит за выполнением шагов, направляет задачи сотрудникам, вызывает API сервисов, генерирует события, фиксирует в Базе Данных (далее – БД) результат и тому подобное. Помимо того, такой инструмент выполняет мониторинг и логирование каждого запущенного экземпляра процесса и фиксирует прогресс и актуальные состояния в БД.

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

Привет, Хабр!

На связи Дмитрий Лохов. В прошлой статье я рассказывал, как мы внедряли VR‑тренажеры и сократили сроки обучения специалистов в 10 раз. Сегодня хочу продолжить тему цифровой трансформации и поделиться нашим следующим шагом — внедрением искусственного интеллекта на обогатительных предприятиях.

4 года назад, когда мы только начинали эксперименты с VR, главной проблемой была катастрофическая нехватка квалифицированных кадров. Наши VR‑решения позволили готовить специалистов быстрее и качественнее. Но со временем стало ясно: чтобы вывести производство на новый уровень, нужно идти дальше — сокращать зависимость от человеческого фактора.

В этой статье я хочу максимально подробно поделиться нашим опытом работы с промышленным ИИ:

Итак вам надо клонировать репозиторий с компанейского репозитория и git просит какие-то непонятные пароли.
Знакома ситуация?

В этой заметке я написал как настроить ssh ключи.

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

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

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

На текущем этапе проектирования воспользуемся Алгоритмизацией, еще одним приемом дисциплины «Системный Анализ».

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

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

1)    Экстраполяционная модель

Изучение способов выявления и формализации функций системы, особенно актуальны для современных тенденции ИТ-рынка, связанных с развитием Сервисных моделей и архитектуры микросервисов. Затронем тезисно эти подходы.

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

В результате этого оценивания уже можно “поиграть” показателями: время, ресурсы, качество (содержание) и приступить к подбору наиболее подходящего их сочетания. Так же, выявленные объемы и зависимости функциональности позволят делить будущий продукт на модули, подсистемы, контуры и прочие части, обеспечивая поэтапное воплощение, распределение ресурсов и ответственности, снижая риски провала благодаря дроблению. Для решения подобных задач нам очень пригодится умение эффективно определять Границы проекта и управлять ими.

Мы уже побывали в птичнике с автоматизацией в Казахстане. Теперь нас пригласили на еще более современный и интересный объект: исследовательский комплекс по выращиванию птицы.

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

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

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

Цель данной группы работ: собрать максимально полные и точные сведения о потребностях заказчика, которые они хотят удовлетворить при помощи разрабатываемого продукта

Привет, постоянные и не очень читатели!

Приходит как-то молодой IT-специалист со свежим стеком из Docker’ов, микросервисов и К8s на завод. В цеху сверкают панели управления, гудят моторы, а он пытается подключиться к этому промышленному добру.

И, внезапно (нет), оказывается, что привычный IT-стек здесь не работает — у заводчан свои протоколы, свои легенды и свои правила. Годами. Десятилетиями. Из уст в уста, от конунга к сыну и т.д. и т.п. Айтишник достаёт ноутбук, спрашивает, какая тут точка доступа, а в ответ — тишина. Только матёрый усатый автоматчик (спец по работе с автоматизированными системами на заводах) медленно поднимает глаза, откашливается и с лёгкой тоской в голосе говорит:

— Тут, сынок, Modbus по RS-485. Без TLS. Без DHCP. И если что, мы это на Delphi писали, в 2004-м.

И это ещё повезло, что на Delphi в 2004-м :) А могло быть написанно в другой стране (году этак в 1990-м) на паскале или фортране. Так и живут некоторые заводы, где вместо YAML — скрипты на паскале, вместо DevOps — старая добрая флешка с патчами, а вместо облачных масштабируемых серверов — шкаф с вентиляцией (в лучшем случае) и приклеенным на скотч листом: «Работает — не трожь!». Хотя по оценке того же Ростеха, если массово развернуть промышленный интернет вещей (IIoT) в разных секторах, это принесёт нашей экономике ~5,5 трлн рублей выгоды. Но пока такие цифры выглядят фантастикой.

В этой статье я расскажу о том, как сталкиваются два мира: IT и OT (Operational Technology). Какие сложности у айтишников в SCADA, почему интернет вещей часто работает без интернета, и как улучшение кибербеза может ухудшить его при внедрении IIoT.

Выбор SCADA системы определяет решение, которое скорее всего вы будете использовать в течение как минимум 10+ лет. Поэтому крайне важно понимать принципы выбора ПО. Предлагаем ознакомиться с мнением Роя Кока (Roy Kok) – инженера с более чем 30-летним опытом работы в области электротехники и промышленной автоматизации.

Одним из основных признаков системы, отличающим ее от #НЕСистемы, является подчиненность всей структуры некоторым целям. Проектная работа команды представляет собой тоже некую систему и, следовательно, должна «идти на поводу» у какой-то цели. Потому установив коммуникации между участниками проекта, начнем вместе с ними определять цели, которые каждое из заинтересованных лиц хочет достичь в результате создания нового продукта.

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

Поскольку мы постоянно оперируем очень сложными конструкциями и понятиями для эффективного управления ими, на протяжении всего курса мы будем использовать прием «Классифицирование» объектов анализа.

Никто давно не пытается выводить теорий о том как правильно писать код.

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

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

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

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

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

Для оптимизации хода освоения навыка формирования Требований к Информационной системе (далее - ИС), разберем сначала упрощенный процесс. Обсудим, как может происходить анализ системы и формирование требований к ней, используя прием реверс-инжиниринга. То есть, рассмотрим уже существующую систему и постараемся воспроизвести процесс формирования требований для ее создания

Чаще всего процесс формализации требований к целевой системе включает 3 этапа:

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

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

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

Весь перечень контуров безопасности сразу делим на две части: контура с целевым УПБ1 и ниже, и контура с целевым УПБ2,3. При объективно проведенном анализе рисков контуров УПБ3 будет очень ограниченное количество, обычно несколько единиц. Подобрать оборудование для обеспечения УПБ3 контура в целом достаточно сложно.