Выгрузка циклов простоя из Балт-Систем через Python для OEE

[kirilljsx]

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

Почему Python - это не лишнее

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

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

Структура скрипта: от загрузки до расчёта

Всё начинается с экспорта данных из Балт-Систем. Стойка выдаёт логи в понятном формате - обычно это CSV или текстовый файл с временными метками и кодами событий. Первый модуль, который нужен - это data_loader, который читает исторические данные и преобразует их в формат, пригодный для обработки. Функция load_data_for_ticker считывает файл, парсит даты и устанавливает timestamp в качестве индекса.

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

Основные этапы обработки:

• Загрузка логов из Балт-Систем - читаем CSV или текстовый файл напрямую с АСУ станка или из папки экспорта
• Парсинг временных меток - преобразуем строки типа “2026-03-23 10:15:45” в объекты datetime для корректных вычислений
• Классификация событий - определяем, какой это цикл: рабочий, холостой ход, переналадка или поломка
• Расчёт длительности - вычисляем время каждого события и суммируем по категориям
• Сохранение результатов - выгружаем обработанные данные в структурированный формат

Логика расчёта OEE на основе циклов простоя

OEE - это перемножение трёх показателей: доступность оборудования (Availability), производительность (Performance) и качество (Quality). Нас интересует в первую очередь доступность - это как раз то, что показывает, сколько времени стойка была готова к работе против общего времени, когда она должна была работать.

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

Формула простая: (Общее время - Неплановый простой) / Общее время * 100%. Но это работает только если данные в логах правильно классифицированы. Вот почему на классификацию стоит обратить внимание.

Структура расчётов:

Показатель	Как считается	Источник данных
Общее время	От первого запуска до последнего события	Временные метки логов
Время резания	Сумма всех циклов с кодом “резание”	События с активной подачей
Холостой ход	Сумма движений без нагрузки, вращение шпинделя вхолостую	События с кодом холостого хода
Неплановый простой	Ошибки, блокировки, прерывания	События с кодами ошибок в логе
Доступность (%)	(Общее - Простой) / Общее * 100	Расчёт из выше перечисленного

Как структурировать Python-скрипт

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

Первый модуль - data_loader.py. Здесь только одна задача: загрузить сырые данные и привести их в порядок. Читаем CSV (или текстовый файл, или что там выгружает Балт-Система), парсим даты, убираем пропуски и помехи, устанавливаем timestamp в качестве индекса. Функция должна вернуть DataFrame, который готов к дальнейшей обработке. Вот и всё.

Второй модуль - event_classifier.py. Здесь живёт вся логика классификации. У вас есть коды событий из стойки? Создаёте словарь, где каждому коду соответствует категория. Временные промежутки без событий? Определяете пороги (если молчит дольше N секунд - это простой). Здесь же строите функции для расчёта длительности каждого события и группировки по типам.

Третий модуль - oee_calculator.py. Берёт уже классифицированные данные и вычисляет OEE, доступность и другие метрики. Просто арифметика, но структурированная и переиспользуемая.

Четвёртый модуль (опционально) - data_exporter.py. Выгружает результаты в нужном вам формате: JSON для API, CSV для экселя, HTML для отчётов. Визуализация помогает выявить ошибки в логике намного быстрее, чем просто глядеть на цифры.

Рекомендуемая структура папок и файлов:

• main.py - главный скрипт, который связывает всё воедино
• data_loader.py - загрузка и парсинг логов из Балт-Системы
• event_classifier.py - классификация событий по типам
• oee_calculator.py - расчёт OEE и производных метрик
• data_exporter.py - экспорт результатов в различные форматы
• config.py - конфигурационный файл с кодами событий, порогами, путями к файлам
• raw_data/ - папка с исходными логами из стойки
• processed_data/ - папка с обработанными данными (промежуточные результаты)
• reports/ - папка с итоговыми отчётами и графиками

Типичные грабли и как их обойти

Первая грабля - это кодировка файлов. Балт-Система может выгружать в Windows-1251, а вы читаете как UTF-8. Результат - крокодил вместо текста. Всегда указывайте encoding=‘cp1251’ или проверяйте, что именно выгружает ваша стойка.

Вторая - пропуски в данных. Линия может порваться, событие может не залогироваться, или был сбой в АСУ. Нужно уметь заполнять пропуски или как минимум их обнаруживать и логировать. Слепо доверять данным - это путь к неправильным расчётам OEE.

Третья - синхронизация времени. Если на станке и на сервере ползут разные часы, то временные последовательности событий будут нарушены. Перед обработкой убедитесь, что NTP настроена или хотя бы разница известна.

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

Пятая - исключение плановых остановов. Переналадка - это не простой, но как её отличить от внезапной поломки? Если нет отдельного кода события, придётся искать эвристики: длительность переналадки обычно фиксированная, или идёт после выполнения задания.

Частые ошибки при обработке:

• Не парсите даты вручную через split и индексы - используйте pd.to_datetime()
• Не игнорируйте часовые пояса, если стойка и сервер в разных регионах
• Не забывайте про микросекунды в timestamp - могут быть дубликаты по миллисекундам
• Не складывайте напрямую длительности событий без проверки пересечений
• Не забывайте о летнем/зимнем времени, если у вас есть переходы на сезонное время

Что дальше с этими данными

Расчёт OEE - это только начало. Когда скрипт работает стабильно и правильно считает, можно подумать о дальнейшей автоматизации. Интеграция с системой мониторинга через REST API, отправка уведомлений, когда OEE падает ниже порога, интерактивные дашборды для анализа тренда. Но это уже следующий уровень.

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