Как стать автором
Обновить
20.51

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

Все об АСУ ТП

Сначала показывать
Порог рейтинга
Уровень сложности

Проектирование Информационных систем. Часть 7. Инжиниринг бизнес-процессов 7.2. Применение BPMN. Ресурсоемкость

Уровень сложностиСредний
Время на прочтение8 мин
Количество просмотров402

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

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

Читать далее

Новости

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

Уровень сложностиСредний
Время на прочтение6 мин
Количество просмотров231

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

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

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

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

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

Читать далее

Настройка SSH для коммитов в репозиторий

Уровень сложностиПростой
Время на прочтение4 мин
Количество просмотров1.3K

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

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

Читать далее

Классические языки программирования и IDE на пороге гибели, а новый рынок на миллиарды долларов пока свободен

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров42K

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

Читать далее

Проектирование Информационных систем. Часть 7. Инжиниринг бизнес-процессов заказчика 7.1. Применение UML Activity

Уровень сложностиСредний
Время на прочтение15 мин
Количество просмотров1.1K

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

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

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

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

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

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

Читать далее

Проектирование Информационных систем. Часть 6. Выявление функции системы. 6.2. Моделирование сервисов. Диаграммы IDEF0

Уровень сложностиСредний
Время на прочтение13 мин
Количество просмотров324

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

Читать далее

Проектирование Информационных систем. Часть 6. Выявление функции системы. 6.1. Теория систем

Уровень сложностиСредний
Время на прочтение14 мин
Количество просмотров1.6K

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

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

Читать далее

Современный умный птичник: хочу там жить

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров2.1K

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

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

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

Читать далее

Проектирование Информационных систем. Часть 5. Формализация потребностей заказчика

Время на прочтение16 мин
Количество просмотров1.3K

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

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

Читать далее

Лавандовый раф или стакан самогона: есть ли место на заводе хипстеру с макбуком

Уровень сложностиСредний
Время на прочтение13 мин
Количество просмотров8.8K

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

Приходит как-то молодой 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

Время на прочтение18 мин
Количество просмотров2.3K

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

Читать далее

Проектирование Информационных систем. Часть 4. Управление целями заинтересованных лиц

Время на прочтение16 мин
Количество просмотров1.5K

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

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

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

Читать далее

Философия программирования зашла в тупик

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров19K

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

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

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

Читать далее

Ближайшие события

Проектирование Информационных систем. Часть 3. Инфраструктура (ландшафт) для организации проектной деятельности

Уровень сложностиСредний
Время на прочтение15 мин
Количество просмотров1.8K

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

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

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

Читать далее

Проектирование Информационных систем. Часть 2. Введение в процесс формирования требований

Время на прочтение9 мин
Количество просмотров2.2K

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

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

Читать далее

Функциональная безопасность и анализ риска, комментарии инженера (часть 5)

Уровень сложностиСредний
Время на прочтение42 мин
Количество просмотров642

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

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

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

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

тут 30 станиц текста с формулами и графика

Функциональная безопасность и анализ риска, комментарии инженера (часть 4)

Уровень сложностиСредний
Время на прочтение34 мин
Количество просмотров449

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

Можно выделить следующие слои безопасности:

- совершенствование технологического процесса с целью исключения опасных факторов – уменьшить давление в системе, снизить объем опасных веществ, изменить технологическую схему, уменьшить количество оборудования…;

- ОСУП (организация системы управления процессом) – контроль состояния оборудования, контроль за технологическим процессом, уменьшить количество персонала в потенциально опасной зоне, построить эффективную систему обучения и инструктажей …;

- система сигнализации о приближении к опасным границам и квалификация операторов – наладить полноценную систему сигнализации, выделить сигнализации приоритета 1, которые требуют незамедлительных действий от операторов, постоянно и квалифицированно вести анализ срабатывания сигнализации, максимально исключить ложные срабатывания, наладить систему постоянных тренингов для поддержания необходимой квалификации операторов (в правильно построенной системе, сигнализации уровня 1 срабатывают крайне редко при реальной угрозе аварии, количество параметров для крупного объекта не превышает 10-50, каждое ложное срабатывание детально исследуется, программа подготовки и квалификация операторов должны обеспечивать корректные действия персонала при срабатывании сигнализации). В правильно построенной системе, сигнализации должны быть разделены на аварийные и информационные, с разной схемой визуализации и разными журналами, но на практике все сигнализации собирают в один перечень, называют «Перечень сигнализаций и ПАЗ», и в системе управления нет разницы между сигнализацией о перегреве реактора и сигнализацией о низкой температуре теплофикационной воды в операторной. В результате в общий журнал сигнализаций каждый день пишется по 1000 записей, 999 из которых не имеют какого-то смысла.

Читать далее

Функциональная безопасность и анализ риска, комментарии инженера (часть 3)

Уровень сложностиСредний
Время на прочтение15 мин
Количество просмотров484

В данной статье на примерах попробуем разобрать порядок построения системы безопасности технологического процесса на основе анализ рисков. Поскольку цель статьи постараться объяснить «нормальным инженерных языком» назначение и порядок создания системы безопасности технологических объектов на основе анализа рисков, придерживаться «процедур в соответствии с ГОСТ-МЭК..» и описывать процедуры я не буду.

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

В целом порядок создания системы безопасности будет следующим:

- исследуем риски, выявляем факторы риска, оцениваем значение;

- если значение риска превышает допустимое, разрабатываем дополнительные мероприятия (технологические, организационные и т.д.) для снижения риска до приемлемого;

- если технологическими и организационными решениями снизить риск до приемлемого не удается, переходим к созданию приборной системы безопасности (ПСБ), определяем контура безопасности, оцениваем требуемый уровень полноты безопасности (SIL) контуров, строим систему аварийного останова (ESD);

Читать далее

Функциональная безопасность и анализ риска, комментарии инженера (часть 2)

Уровень сложностиСредний
Время на прочтение13 мин
Количество просмотров484

Различие в подходах: нормы или анализ рисков.

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

Для обеспечения безопасности технологического процесса или технического устройства, снижения риска получения травмы или гибели до допустимого значения, возможны два подхода – выполнить технологический процесс в соответствии с «нормативными документами» или провести анализ рисков, выявить все источники и разработать компенсирующие мероприятия.

В бывшем СССР сложилась система норм и правил, которые жестко регламентировали требования, как организационные, так и технические. Эта система была унаследована и РФ. Достаточно посмотреть «Общие правила взрывобезопасности для взрывопожароопасных химических, нефтехимических и нефтеперерабатывающих производств» утверждены приказом Федеральной службы по экологическому, технологическому и атомному надзору от 15 декабря 2020 года № 533. Документ содержит 70 страниц ценных указаний. И таких «нормативных документов» у нас бесконечное количество, при желании можно найти «нормативку» на все случаи жизни. Соответственно проектировщику не надо понимать процесс, детально знать все особенности технологии, иметь опыт эксплуатации, достаточно просто найти нужную «нормативку» и выполнить все требования. Эксперт при проведении экспертизы проектной документации также проверяет технические решения на соответствие «нормативке», и инспектор Ростехнадзора тоже будет проверять объект на соответствие этой же «нормативке». При этом никого не волнует, на сколько обеспечена реальная безопасность технологического процесса (технологической установки), эффективность и достаточность принятых решений, возможность устойчивой работы оборудования и т.д. Соответствие нормам снимает ответственность за конечный результат со всех – проектировщиков, экспертов, инспекторов, и перекладывает всю ответственность на эксплуатацию, людей, которые непосредственно работают на технологической установке и реально рискуют своей жизнью.

действительно интересно?

Функциональная безопасность и анализ риска, комментарии инженера (часть 1)

Уровень сложностиСредний
Время на прочтение11 мин
Количество просмотров978

Что такое безопасность технологического процесса или технической системы (устройства), что такое риск и вообще зачем все это?

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

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

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

для тех, кому это интересно
1
23 ...