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

В докладе расскажем о том, как работать с трафиком промышленных компьютерных сетей, использовать сигнатуры системы обнаружения вторжений (СОВ) и разрабатывать новые. Поделимся своими методами разбора промышленных протоколов и кейсами АСУ ТП.

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

На докладе вы узнаете:
1. почему специалистам ИБ важно смотреть на технологическую инфраструктуру с позиции «а что, если в нее уже проник злоумышленник», а не только использовать автоматическое реагирование на известные угрозы;
2. с каких самых распространенных угроз для технологического сегмента необходимо начинать ИБ-мониторинг;
3. как разработчикам прикладного ПО для технологического сегмента подготовить свое ПО, чтобы оно успешно интегрировалось с наложенными средствами ИБ.

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

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

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

АО «Еврохим» внедряет цифровизацию и IIoT для управления технологическими процессами, повышая эффективность производства. Основная проблема — большое количество ручных операций, что ведет к ошибкам и снижению производительности. При первом обследовании обнаружено, что около 50% контуров регулирования работают вручную, что значительно замедляет реакцию на изменения. Внедрение автоматических схем регулирования помогает стабилизировать параметры и снижает риски инцидентов.

Для мониторинга процессов разработана методика, которая отслеживает эффективность использования схем автоматического регулирования. Минимально контролируется 150 схем на каждом объекте. Использование автоматизации улучшает качество управления и повышает ключевые показатели производительности, в том числе увеличение извлечения полезных компонентов. В результате внедрения цифрового продукта мониторинга схем базового регулирования увеличилась включенность схем регулирования до 80%, что позволит принести более 120 млн руб. в год для одного ГОК.

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

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

Используя различные инструменты, я решал ту или иную задачу, но комплексно удалось объединить все преимущества лишь в самописном сканере. Бонусом получая подробную информацию о каждом хосте, я обогащаю результат другими средствами защиты и инвентаризации. В итоге получается подробная информация о хосте и корреляция хоста с другими системами, например, SIEM, AV, CMDB, DLP и др. В разрезе — вертикально IP, горизонтально открытые порты, службы, а также информация из других источников. Плюсы: бесплатно, удобно и в одном месте. Ценность данного метода состоит в скорости (скан проходит сеть 10.0.0.0/8 за 12 часов) и точности, каждый хост описан по ОС, портам, службам и др. Коммерческие и готовые бесплатные решения уступают в скорости или точности, или корректности.

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

Цели распределенной разработки:
* снижение календарных сроков разработки проекта на стадии MVP;
* снижение рисков недооценки подрядчиком границ и трудоёмкости проекта;
* снижение рисков незавершения всего проекта в случае прекращения работ с одним из подрядчиков.

Как ИИ внедряется в разработку в крупном производстве.

a. Люди и задачи: как выбирали команды разработки для пилота.
b. Амбассадоры ИИ по каждому стеку.
c. Информационная безопасность и ИИ.
d. Сложности и приживаемость. Как оценивать эффективность разработки с ИИ.
e. Как мы изменили SDLC-цикл по результатам пилота?

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

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

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

Рассказываем, как мы справились с этой задачей.

* Полтора производителя FC после тех самых событий больше не с нами, что дальше?
* Почему iSCSI, и в чём его маргинальность?
* Правильно готовим архитектуру L2, L3 static, L3 VRFs, L3 с хоста.
* Учитываем особенности ТОРП РЭП сетевого оборудования и СХД.
* Улучшаем сеть хранения данных с помощью: QOS, ECN, lossless, DCB, deep buffers и прочего тюнинга.
* Проводим испытания сети хранения данных на различных архитектурах L2 и L3.
* Немного слов об отечественных СХД и поддержку ими NVMe-oF (ROCEv2).

Рассказ об архитектуре продукта по приему, обработке, хранению и отправке телематических данных для автомобилей, производимых ПАО КамАЗ, — как и зачем мы собираем телеметрию с сотни тысяч автомобилей. Основные направления нашей работы: телеметрия, FOTA (firmware over-the-air), диагностика.

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

* Что такое распределенные системы управления (РСУ) в АСУ ТП, и как они взаимодействуют с SCADA;
* особенности реализации РСУ/SCADA Лацерта;
* когда возникают высокие нагрузки в РСУ;
* как устроена архитектура реального времени (АРВ), какие создает проблемы;
* как устроена событийно-управляемая архитектура (СОА), какие создает проблемы;
* могут ли сосуществовать АРВ и СОА в одном проекте, преимущества гибридной архитектуры;
* как влияют АРВ и СОА на консистентность РСУ;
* оркестрация и хореография сервисов АРВ, СОА;
* резервирование и отказоустойчивость сервисов АРВ, СОА.

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

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

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

В своём докладе я представлю сконцентрированный опыт, который мы получили за последние годы, расскажу, «как это было», что мы рекомендуем, и поделюсь хитростями, к которым мы прибегали. Совместно с владельцами внедряемых продуктов провёл десятки переговоров с интеграторами и вендорами, самостоятельно изучал рынок решений ECOM и CRM, составлял требования к ним и участвовал во внедрении продуктов в компанию на каждом из этапов. Поверьте, нам есть о чём рассказать!

Продуктовое управление лишь сравнительно недавно появилось в промышленности в РФ как ответ на повышение как глобальной, так и локальной конкуренции и соответствующую потребность в ускорении изменений, которые затронули даже самые консервативные сектора экономики. В передовых компаниях рынка роль владельца продукта уже претерпевает некоторые изменения, а где-то лишь зарождается, но вопросы вокруг роли не утихают никогда:
* какими навыками должен обладать такой специалист завтра?
* что важнее: hard или soft skills?
* как выбрать вектор развития?
и многие другие вопросы крутятся постоянно в голове продактов и их руководителей.

В докладе вы найдете ответы, а также:
* познакомитесь с рейтингом важнейших технических и софтовых компетенций продакта (основа — анализ опыта более 400 корпоративных продактов, более 200 из которых — из промышленности);
* узнаете о трендах развития профессии продакта как в РФ, так и в мире;
* сможете сравнить себя с портретом продакта промышленной компании 2025 с точки зрения ключевых топ-7 навыков;
* сможете увидеть свои зоны роста в продуктовом менеджменте и сможете сформировать свой личный план по развитию важнейших компетенций продакта на основе рекомендаций.

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

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

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

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

* Что такое сельское хозяйство 4.0?
* С чего начинается трансформация отрасли.
* Фреймворки тактик перевода «в цифру» (открытая экосистема, культура, сотрудничество, новые деньги и бизнес-модели).
* Discovery-цикл как один из элементов продуктовой стратегии, подходы к приоритизации бизнес-гипотез.
* Каким будет сельское хозяйство 5.0? Взгляд в будущее.

Расскажем о нашем движке Alpha.Historian для решения задач хранения исторических данных в проектах автоматизации на базе ПО Альфа платформа.

О целевых архитектурах, в которых применяется Альфа платформа, и задаче хранения истории:
* архитектура и специфика систем на базе Альфа платформы в АСУ ТП и системах диспетчеризации;
* что такое история в АСУ ТП?
* специфика использования истории в АСУ ТП: анализ ситуаций vs отчёты/аналитика.

Предыстория, альтернативы (в прошлом), предпосылки:
* "А у других...";
* опыт использования классических СУБД;
* иные альтернативы на момент начала разработки (в 2012 году).

Базовые требования, из которых мы исходили:
* компонент, интегрированный в Альфа платформу;
* нативный стек, минимизация внешних зависимостей;
* минимум конфигурации, отсутствие схемы, свободный бинарный формат;
* минимум усилий по обслуживанию;
* готовность к особенностям взаимодействия с источниками;
* эффективность записи, чтения, удаления;
* готовность к использованию в системах АСУ ТП и диспетчеризации большой информационной ёмкости.

Alpha.Historian как часть Альфа платформы, его место в общей архитектуре:
* как выделенный компонент в составе Альфа платформы;
* как базовая библиотека в имплементации других бинарных хранилищ в Альфа платформе.

Собственный движок СУБД в основе Alpha.Historian:
* как он устроен, что в его основе;
* общая логика работы.

Текущее состояние, возможности:
* производительность и эффективность хранения данных;
* администрирование, обслуживание;
* импорт/экспорт данных;
* сценарии применения: где, в каких рамках, примеры;
* предполагаемые пути развития.

Зачем кластеризовать PostgreSQL?
* Базовые сравнения с близкими аналогами (одиночный Pg/кластер Pg/Grenplum (от AD)).
* Чек-лист — если у вас что-то совпадает — (не) используйте кластеризацию.
* Замечательные возможности, которые предоставляет кластеризация.

Как кластеризовать PostgreSQL / обходим грабли.
* Кластер на коленке.
* Повышение плотности утилизации — «шахматка».
* PgBouncer — да, но нет.
* Fencing — не блажь, а суровая необходимость, настраиваем правильно.
* Кластер повышает отказоустойчивость, но не отменяет РК.
* Скорость РК как главный ограничитель размера БД.

Tantor PipelineDB — это форк расширения PipelineDB для PostgreSQL. PipelineDB позволяет обрабатывать данные в реальном времени, используя только SQL. Но, к сожалению, данный интересный проект был закрыт в 2019 году, и с тех пор код не обновлялся. Мы в команде Tantor Labs используем PipelineDB более 5 лет и развиваем его самостоятельно.

В докладе хотелось бы рассказать:
* о том, как устроен Tantor PipelineDB,
* какие задачи для работы с time series-данными решает,
* о портировании на новые версии PostgreSQL/Tantor (до 16 версии включительно),
* о доработках для эффективного сжатия и партиционирования,
* о планах на будущее и open source.

Путь компании СИБУР с использованием open source-инструмента для обеспечения качества данных после ухода вендора.

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

А теперь самое интересное: как запустить процесс при слабой культуре в управлении качеством данных на уровне сквозных процессов через все системы компании?

1. Особенности построения хранилища данных на производственном предприятии.
2. Что может пойти не так при построении хранилища данных? Показываем на своем примере.
3. Чем поможет автоматизация управления структурой хранилища данных на примере управления детальным слоем.
4. Каким у нас получился фреймворк для управления структурой детального слоя. Его свойства и ограничения.
5. Какие еще фреймворки нужны для управления всем хранилищем в целом. Какие из них нам удалось внедрить себе в работу.

* Какие перед нами стояли задачи по сохранению, обработке и анализу технологических данных.
* Особенности наших данных.
* Как мы пришли к решению пойти в облако.
** Первый вариант архитектуры on-premise.
** Неопределенности 2022.
** Если идти в облако, то PaaS/SaaS.
* Ограничения безопасников — деформация архитектуры на принцип «выпушиваем данные снизу вверх».
* Какую в итоге сделали архитектуру.
** Подготавливающие компоненты локально — от источника до стейджинга (Airflow, Kafka).
** В облаке — от стейджинга до витрины (Greenplum, S3, Airflow).
* Что у нас получилось и нам нравится, а что не очень.

0. Что такое программное обеспечение, результаты интеллектуальной деятельности и нематериальные активы (НМА) с юридической точки зрения?
1. Появление нематериального актива и повышение капитализации за счет НМА.
2. Как разработчик участвует в создании НМА, и какая ему от этого выгода?
3. Как разработчику читать юридические документы и на что обращать внимание в первую очередь?
4. Все в совокупности необходимо, в том числе и для включения в Реестр российского ПО (реестр Минцифры). Это, в первую очередь, важно для субъектов КИИ, которые должны осуществить переход на отечественный софт в сроки, установленные Правительством. Ближайший срок — 2025 год.
(Государство не собирается послаблять ограничения для субъектов и объектов КИИ. У России стоит цель до 2030 года сформировать свой технологический суверенитет). В первую очередь для реестра принципиален набор компонентов, используемых в ПО, т. е. техстек. Проверка техстека осуществляется экспертами и этому уделяется большое количество времени.
5. Что такое техстек в призме Минцифры? Как сделать техстек «чистым»? Виды лицензий на ПО и их отличия.
6. Опенсорс более коварный, чем кажется на первый взгляд. Расскажем про все виды open source-лицензий и о рисках использования компонентов для бизнеса (не только через призму Минцифры РФ).

1. Ключевые метрики здоровья IТ-систем, или Почему классического мониторинга недостаточно.
2. Основные подходы к определению корневых причин инцидентов.
3. Как сквозная наблюдаемость делает жизнь инженеров проще.
И все это на примерах реальных кейсов внедрения мониторинга в одной из крупнейших индустриальных компаний.

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

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

Рост любой компании сопровождается ростом ее IТ-инфраструктуры: с каждым днем приложений от разных поставщиков становится все больше и больше. Цифровизация любого бизнеса предусматривает внедрение нового программного обеспечения. Возникает потребность интеграции приложений между собой и данных из различных источников для оптимизации бизнес-процессов и расходов на содержание IТ-ландшафта. На помощь приходят различные решения, в том числе интеграционные платформы. Спираль эволюционных подходов к построению интеграционных взаимодействий от простых интеграций напрямую «точка – точка», интеграций через средний слой: брокеров «издатель – подписчик», через корпоративные сервисные шины (ESB), ETL-инструменты и интеграционные платформы. Потребности бизнеса порой меняются до окончания интеграционных работ. Как же тогда покрыть более сложные архитектурные долгострои, такие как Data Mesh, Data Fabric или Data Vault?

Однако традиционные подходы к интеграции, такие как ESB, EAI, а также ETL, имеют свои ограничения. В условиях растущих объемов данных и необходимости быстрой адаптации к изменениям, компании все чаще обращаются к более современным приложениям — платформенным решениям. Платформы позволяют наладить процесс интеграции и устранить беспорядок, который может возникнуть при использовании «зоопарка» различных интеграционных приложений и избыточных финансовых затрат.

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

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

Какой дистрибутив Java вы используете для разработки и запуска Java-приложений?
OpenJDK — услышим мы в ответ в 90% случаев.

Ответ одновременно верный и неверный. OpenJDK — это проект, а точнее, набор проектов с открытым исходным кодом, в рамках которых происходит развитие Java-технологий. Но, как правило, на проде мы не используем проект OpenJDK или его исходный код. На проде мы используем готовую к работе программу, которая основана на проекте OpenJDK, но кто же произвел эту программу, этот дистрибутив OpenJDK?

Мы в Axiom JDK уже более четверти века занимаемся разработкой OpenJDK и производством промышленного дистрибутива Java SE.

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

Задача: создание комплексного программного продукта, включающего:
* задачи сбора и произвольной конфигурации данных технического учёта энергоресурсов, АСУ ТП, MES;
* визуализацию и контроль параметров (диспетчерский уровень);
* ведение нормативно-справочной информации, отчётность.

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

В докладе будут представлены:
* архитектурные решения системы энергоменеджмента с учётом минимизации затрат на переход к новому ПО;
* технические решения переноса функционала нативных приложений на web.

Расскажем про наш опыт разработки OCR-решения для распознавания документов. Обсудим подходы к применению машинного обучения в прикладных задачах в рамках больших проектов, рассмотрим проблематику работы с ресурсами и данными, коснёмся вопросов правильного масштабирования.

Экскурс в отраслевую разработку, и почему мы пришли к собственным решениям. В докладе будут рассказаны причины и показаны примеры появления коммерческих продуктов в ГК «Росатом».

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

Рассмотренные вопросы:
* с чего начали вывод продуктов? Аналитика рынка;
* что нужно для эффективного выхода на рынок на собственном примере;
* чем гордимся, на чём учимся и какими выводами хотим поделиться

1. Важность процесса цифровизации опасных работ на промышленных предприятиях.
2. Выбор технического стека для автоматизации промышленной безопасности.
3. Реализация бизнес-процессов на базе Camunda.
4. Особенности технической реализации проекта.
5. Результаты разработки системы.

Цифровая трансформация в НЛМК и проектирование Технологической Платформы для разработки продуктов как основы для ее реализации.

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

Почему поднять giltlab или Kubernetes — это еще не сервис. Какие критерии и паттерны мы используем для создания сервиса платформы. Каким образом масштабироваться и дойти до self-service. Эффекты от платформы, и что было бы, если бы нас не было.

Сейчас использование ML и AI стало практически обязательным пунктом любой программы цифровизации. Компании промышленного сектора экономики — одни из самых активных «юзеров» машинного обучения в своих продуктах.
Предсказать лучшее месторождение? Предугадать, когда оборудование выйдет из строя? Все это и не только нам помогает делать искусственный интеллект и машинное обучение.

А что, если злоумышленник уже использует уязвимости в моделях, чтобы «жить» в вашей инфраструктуре? Или подменяет их так, что вы не видите?

Поговорим о том, как современный DevSecOps работает с уязвимостями в моделях и куда движется отрасль защиты именно от этого типа проблем. Расскажу про «идеальные» конвейеры MLOps и внедрение практик безопасности в них. Покажу, что делаем мы, и поделюсь подходами, которые не могут не сработать.

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

В данном докладе мы поговорим о том, каким образом организовать процесс работы с инцидентами заказчиков, правильно разграничить зону ответственности между внедрением и R&D, сопроводить его техническими инструментами, чтобы всё работало как часы.

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

Но как внедрять контейнеризацию и Kubernetes, когда нет релевантного опыта? Как строить кубы отказоустойчивыми, управляемыми и безопасными? Как приземлять это внутрь существующей команды, и что, в конце концов, делать — пробовать варить кубы самостоятельно или внедрять готовые платформы?

В докладе расскажу:
* каким образом крупная металлургическая компания без собственного штата разработчиков пришла к пониманию, что без Kubernetes их дальнейшая жизнь невозможна (или как минимум крайне не удобна);
* как выглядел путь от базовой идеи — «пора что-то менять» к тому, что получилось в итоге;
* как выбирали: делать самим vs взять готовое;
* какие подводные камни словили в процессе реализации и на что стоило бы обратить внимание на старте;
* что получилось и куда двигаться дальше.

Департаменты IТ и ИБ уже приняли, адаптировали виртуализацию и виртуальные машины в свой технологический стек и процессы. Но время неумолимо бежит вперед и приводит индустрию к контейнеризации, контейнерам, оркестраторам (Kubernetes). Давайте проведем между ними параллели, чтобы понять, где они сходятся, а где расходятся. Это позволит понять разницу, преимущества и недостатки, на основании которых можно эффективно играть и использовать их как порознь, так и совместно во благо безопасности.
 
1. О виртуализации:
• О контейнеризации
• Об оркестрации
** Kubernetes — PaaS
• Защита/изоляция данных
** вопросы восстановления данных
2. Защита/изоляция сети
• Защита подсетей versus NetworkPolicy
• Гранулярность контроля и ZeroTrust
3. Защита/изоляция окружений выполнения (runtime)
• Изоляция гипервизора versus изоляция контейнеров
• RuntimeClass в Kubernetes
4. Обслуживание
• Нужно ли решать организационные проблемы техническими методами?
5. Заключение

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

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

1. Генеративная технология, и почему она интуитивно понятна.
2. Сценарии применения использования языковых моделей для создания подсказчиков ТОиР.
- Анализ поломок.
- Разработка актов по простою.
- Актуализация тех. карт для выявления доп. мер по ремонту.
- Работа с экспертными правилами.
- Процесс управления качеством.
3. Демо по одному из кейсов.

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

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

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

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

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

Да, у нас нет GPU, но мы справляемся и экономим на ресурсах. В своем докладе я покажу, что можно сделать с моделями, чтобы облегчить жизнь нам и CPU. Я расскажу и покажу реальные задачи, с которыми столкнулся СИБУР, и о том, как наша команда успешно преодолела все вызовы с помощью ускорения моделей.

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

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

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

Решение задач по оптимизации технологического процесса на основе ML/DL позволяет компаниям выявлять узкие места, повышать эффективность и тем самым значительно снижать расходы. Вы услышите о подходе к анализу промышленных данных за 10 лет, а также о реализации методов, которые помогли разработать модель электропотребления на 3 года вперед на основе помесячного электропотребления установкой (MAPE = 2,3%) и достичь положительных результатов в рамках проекта.

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

Беспилотники все активнее внедряются в различные отрасли, строительство — не исключение. За счет съемки с дрона можно регулярно, оперативно и прозрачно получать снимки актуального состояния стройплощадки. А машинное обучение и фотограмметрия помогут автоматизировать процесс обнаружения и подсчета материалов, даже если они складируются стопками.

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

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

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

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

В нашем докладе мы покажем долгий и тернистый путь внедрения искусственного интеллекта на горно-обогатительном комбинате (ГОКе), расскажем про алгоритмы и технологии, которые напрямую влияют на плановые показатели фабрики, а также покажем, какую экономическую выгоду приносит внедрение искусственного интеллекта на производстве.

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

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

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

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

Рассказ о пути внедрения ИИ в процессы тестирования в компании «Дом. РФ Технологии», такие как:
1. тестирование требований;
2. разработка тестовых кейсов;
3. разработка API автотестов;
4. разработка отчетной документации для заказчика (ПМИ).

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

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

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

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

Обсудим, кто же все-таки должен решать, какой технологии быть, а какой — не миновать? CEO, CTO или доменный эксперт?
И в конце попробуем понять, почему самые «стоящие» компании 21-го века сплошь «технологические» и какие перспективы в связи с этим есть у промышленных компаний по «масштабированию технологий» в 2024 году и не пора ли нам выйти на новый уровень?

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

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

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

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

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

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

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

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

Часто бывает, что на производстве получить достаточное количество данных для обучения нейронных сетей просто невозможно. В таких случаях на помощь приходит Zero-Shot Learning и технологии генерации синтетических данных.

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

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

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

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

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

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

Но какой инструмент позволит работать с YAML как с кодом и позволит выйти за рамки обычной шаблонизации?

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

CUE реализует простой подход работы с YAML как с кодом, а при интеграции с Golang вполне легко можно создать свой инструмент, позволяющий обеспечить не только работу с шаблонами K8s, но и автоматизировать валидацию, генерацию YAML и его дальнейшую поставку на кластер с учетом всех особенностей архитектуры и текущих версий релизов на кластере. На примере организации структуры репозитория расскажу про важность согласованности локального и удаленного хранилищ, создав которую, можно автоматизировать многие промышленные процессы с помощью CUElang.

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

Я разберу популярные способы деплоя на кластер. Покажу типовые проблемы, возникающие при обновлении базы данных, и пути их решения. Также разберемся, чем обновление NoSQL-баз данных отличается традиционных реляционных баз.

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

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

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

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