Как считать OEE по данным SCADA и 1С: формула, данные и интеграция

OEE часто пытаются считать из одного источника: либо из SCADA, либо из 1С. На практике оба подхода имеют ограничения.

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

Поэтому для производственного предприятия разумно разделить источники данных:

SCADA / PLC
   ↓
Факт работы оборудования
   ↓
Integration Layer
   ↓
OEE Engine
   ↑
1С:ERP
   ↑
Заказы / номенклатура / нормы / выпуск

Сам OEE обычно рассчитывается как произведение трёх факторов: Availability × Performance × Quality. Такой подход используется в промышленной аналитике, а ISO 22400 задаёт общий отраслевой подход к производственным KPI и их определению.

Что такое OEE

OEE — Overall Equipment Effectiveness, показатель общей эффективности оборудования. В классической модели он состоит из трёх множителей:

OEE = Availability × Performance × Quality

В процентах:

OEE [%] = A × P × Q

где:

• Availability — доступность оборудования;
• Performance — производительность относительно идеальной скорости;
• Quality — доля годной продукции.

Например, если доступность равна 90%, производительность 80%, а качество 98%:

OEE = 0.90 × 0.80 × 0.98
    = 0.7056
    = 70.56%

Важно не складывать эти три показатели. OEE является именно мультипликативным KPI: низкое значение одного фактора существенно снижает итоговую эффективность.

Почему одного OEE недостаточно

Само число OEE не объясняет причину потерь. Два станка могут иметь одинаковые 70%, но совершенно разные проблемы.

Оборудование	Availability	Performance	Quality	OEE
Станок A	70%	100%	100%	70%
Станок B	100%	70%	100%	70%
Станок C	100%	100%	70%	70%

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

Availability: как считать доступность

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

Типовая формула:

Availability =
Run Time / Planned Production Time

Например:

Плановое производственное время = 480 мин
Простой = 60 мин
Run Time = 420 мин

Availability = 420 / 480 = 87.5%

В промышленной аналитике важно заранее определить, что именно считается плановым временем. Плановые перерывы, отсутствие смены, профилактика и другие исключения могут быть вынесены за пределы доступного производственного времени. Конкретная методика должна быть закреплена в модели KPI предприятия. Siemens, например, отдельно выделяет planned production time, availability losses и другие категории потерь при расчёте OEE.

Какие данные для Availability взять из SCADA

SCADA или PLC обычно являются естественным источником событий состояния оборудования:

RUN
STOP
FAULT
IDLE
SETUP
MAINTENANCE
OFFLINE

Но одного статуса недостаточно. Нужно хранить время начала и окончания события:

equipment_event
----------------
equipment_id
state
started_at
finished_at
duration
reason_code

Тогда можно построить временную шкалу:

08:00 ───────── RUN ───────── 10:15
10:15 ──────── FAULT ──────── 10:40
10:40 ───────── RUN ───────── 12:00
12:00 ──────── SETUP ──────── 12:25
12:25 ───────── RUN ───────── 16:00

Из неё OEE Engine уже рассчитывает фактическое время работы и потери доступности.

Performance: как считать производительность

Performance показывает, насколько быстро оборудование производило продукцию относительно идеального темпа.

Одна из распространённых формул:

Performance =
Ideal Cycle Time × Total Count
--------------------------------
Run Time

Например, идеальный цикл — 30 секунд на изделие. За 6 часов фактической работы произведено 600 изделий.

Ideal Cycle Time = 30 сек
Total Count = 600
Run Time = 6 ч = 21 600 сек

Performance =
30 × 600 / 21 600
= 83.33%

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

Какие данные для Performance даёт SCADA

SCADA может передавать:

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

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

Quality: как считать качество

Quality показывает долю годной продукции в общем количестве произведённой продукции.

Quality =
Good Count / Total Count

Например:

Total Count = 1 000
Good Count = 970
Reject Count = 30

Quality = 970 / 1 000
        = 97%

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

Почему Quality чаще всего приходит из 1С, а не из SCADA

SCADA знает факт производства, но не всегда знает окончательный результат контроля качества.

1С или MES могут содержать:

• количество принятой продукции;
• брак;
• причину брака;
• результат операции контроля;
• переделку;
• возврат на предыдущую операцию.

Поэтому Quality часто удобнее рассчитывать после объединения производственного факта с данными учёта и контроля качества.

Какие данные брать из 1С

1С нужна прежде всего для бизнес-контекста и нормативной модели.

Данные 1С	Зачем OEE
Заказ на производство	Понять, в рамках какого заказа выполнялась работа
Номенклатура	Определить изделие
Технологическая операция	Связать факт с процессом
Рабочий центр	Связать производство с оборудованием
Норматив времени	Определить идеальный темп
Плановое количество	Сравнить план и факт
Фактический выпуск	Определить количество произведённого
Брак	Рассчитать Quality

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

Почему нельзя считать OEE только по данным 1С

Если в 1С есть документ выпуска, это ещё не означает, что мы знаем реальное время работы станка.

Например, в 1С зафиксирован выпуск:

Изделие X
Количество: 800 шт.
Смена: 8 часов

Но внутри смены оборудование могло:

• стоять 40 минут из-за неисправности;
• 20 минут ждать материал;
• 30 минут переналаживаться;
• работать на сниженной скорости.

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

Почему нельзя считать OEE только по SCADA

Обратная проблема возникает на уровне бизнес-контекста.

SCADA может знать:

Machine_17
RUN = 26 400 sec
Cycles = 1 800
Speed = 0.068 cycle/sec

Но без 1С или MES сложно определить:

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

Поэтому SCADA и 1С должны быть не конкурирующими источниками, а частями общей модели данных.

Как связать SCADA и 1С

Прямой обмен «SCADA → 1С → расчёт OEE» возможен, но для сложного предприятия лучше выделить интеграционный слой.

SCADA / PLC
     ↓
OPC UA / MQTT / API
     ↓
Integration Layer
     ↓
PostgreSQL
     ↑
1С OData / HTTP API
     ↑
1С:ERP
     ↓
OEE Engine
     ↓
Dashboard / BI / AI

Такой контур позволяет не нагружать оперативную 1С сырыми телеметрическими событиями.

Что хранить в OEE-контуре

Минимальная модель может выглядеть так:

equipment
----------
id
external_id
name
work_center_id

equipment_event
---------------
equipment_id
state
started_at
finished_at
reason_code

production_run
--------------
equipment_id
product_id
order_id
operation_id
started_at
finished_at

production_counter
------------------
equipment_id
timestamp
total_count
good_count
reject_count

oee_calculation
---------------
equipment_id
period_start
period_end
availability
performance
quality
oee

Важна связь equipment → work center → operation → product → order. Без неё OEE превращается в набор обезличенных процентов.

Mapping оборудования SCADA и 1С

Идентификаторы в SCADA и 1С редко совпадают автоматически.

SCADA
machine_id = CNC-17

        ↓ mapping

1С
Рабочий центр = Фрезерный центр №17

Поэтому нужен справочник соответствий:

equipment_mapping
-----------------
scada_id
plc_id
opc_node
one_c_work_center_id
name
active

Аналогично сопоставляются изделия, операции, линии, участки и причины простоев.

Как классифицировать простои

Просто факт остановки недостаточен для управленческого анализа. Нужно знать причину.

Категория	Пример
Equipment	Поломка станка
Material	Нет заготовки
Setup	Переналадка
Quality	Остановка для устранения дефекта
Operator	Нет оператора
Planning	Нет производственного задания
Maintenance	Плановое обслуживание
External	Нет электроэнергии или другого ресурса

Такая классификация позволяет перейти от вопроса «почему OEE низкий?» к вопросу «какие потери формируют OEE и кто отвечает за их устранение?».

Малые остановки и Performance Loss

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

Идеальный цикл: 10 сек
Фактический цикл: 13 сек

Performance Loss ≈ 23%

Аналогично нужно учитывать малые остановки, если методика OEE предприятия относит их к потерям производительности. В промышленной практике Performance Loss включает снижение скорости и small stops.

OEE по смене

Для оперативного управления удобно считать OEE по смене:

Смена №1
08:00 — 20:00

Availability   91%
Performance    84%
Quality        98%

OEE = 74.9%

Но для анализа тренда лучше хранить расчёты и на более детальном уровне:

• час;
• смена;
• сутки;
• заказ;
• изделие;
• операция;
• рабочий центр;
• производственный участок.

OEE по изделию

Один и тот же станок может иметь разный OEE при выпуске разных изделий.

Изделие	A	P	Q	OEE
A	95%	92%	99%	86.5%
B	88%	73%	97%	62.2%

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

OEE и bottleneck-анализ

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

Поэтому OEE лучше использовать вместе с анализом загрузки и bottleneck:

SCADA
  ↓
OEE
  ↓
Loss Analysis
  ↓
Capacity
  ↓
Bottleneck Analysis
  ↓
Production Planning

Это особенно важно для APS: планировщику нужно знать не только эффективность отдельного оборудования, но и влияние ограниченного ресурса на общий поток производства.

OEE и 1С:ERP

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

Поэтому 1С может выступать источником контекста и нормативной модели, а SCADA — источником фактической телеметрии оборудования.

OEE Engine: отдельный сервис

Для крупного производства расчёт OEE удобно вынести в отдельный сервис.

OEE Engine
├── Event Aggregator
├── Run Detector
├── Availability Calculator
├── Performance Calculator
├── Quality Calculator
├── Loss Classifier
├── KPI Calculator
└── Report Builder

Тогда алгоритм расчёта можно менять независимо от оперативной 1С и SCADA.

OEE и PostgreSQL

PostgreSQL удобно использовать как аналитический контур для хранения событий, производственных запусков, счётчиков и результатов расчётов.

SCADA
 ↓
Event Stream
 ↓
PostgreSQL
 ↑
1С
 ↑
Business Context
 ↓
OEE Engine
 ↓
PostgreSQL
 ↓
BI / Dashboard / AI

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

OEE в реальном времени

Если события SCADA поступают практически без задержки, можно строить near-real-time dashboard:

Станок №17
──────────────
Availability   93%
Performance    81%
Quality        99%
──────────────
OEE            74.5%

Current state: RUN
Current order: 00001245
Product: Деталь А
```
                

Но realtime-показатель нужно отличать от окончательного закрытого KPI смены. Пока смена продолжается, значения могут изменяться.

Что делать с историческими перерасчётами

Производственные данные могут корректироваться после завершения смены: оператор исправил причину простоя, контроль качества подтвердил брак, в 1С изменился выпуск.

Поэтому OEE Engine должен уметь пересчитывать закрытые периоды:

Raw Events
    ↓
Business Context
    ↓
OEE Calculation v1
    ↓
Correction
    ↓
OEE Calculation v2
    ↓
Audit History

Желательно хранить версию расчёта и источник изменения, а не просто перезаписывать старое значение.

Как интегрировать SCADA через OPC UA

Если оборудование публикует данные через OPC UA, integration gateway может подписываться на необходимые узлы и преобразовывать их в унифицированные производственные события.

PLC
 ↓
OPC UA Server
 ↓
OPC UA Client
 ↓
Integration Gateway
 ↓
Normalized Event
 ↓
OEE Engine

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

Как интегрировать SCADA через MQTT

Если оборудование или edge-шлюз публикует события через MQTT, архитектура может выглядеть так:

Equipment
   ↓
Edge Gateway
   ↓
MQTT
   ↓
Message Broker
   ↓
OEE Consumer
   ↓
PostgreSQL
   ↓
OEE Engine

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

Как связать OEE с 1С через OData

Если 1С предоставляет стандартный OData-интерфейс, integration service может получать бизнес-данные через HTTP и преобразовывать их в собственную модель.

1С:ERP
 ↓
OData
 ↓
Symfony / Go
 ↓
DTO
 ↓
OEE Context
 ↓
OEE Engine

Такой подход позволяет не привязывать OEE Engine к внутренней структуре конфигурации.

Подробнее о стандартном API 1С мы разбирали в статье «1С OData: как работать с API 1С и интегрировать внешние системы».

Какие KPI можно получить кроме OEE

После накопления событий из SCADA и бизнес-контекста из 1С можно рассчитывать дополнительные показатели:

• MTBF — среднее время между отказами;
• MTTR — среднее время восстановления;
• время простоев по причинам;
• время переналадок;
• выпуск на рабочий центр;
• отклонение фактического цикла от норматива;
• план/факт выпуска;
• потери из-за брака;
• потери из-за отсутствия материалов;
• загрузка критических рабочих центров.

ISO 22400 предназначен именно для системного определения и использования KPI производственного управления, а отдельные документы серии описывают KPI и вопросы сбора данных для их расчёта.

OEE и AI

После того как OEE рассчитан детерминированно, AI можно использовать для анализа причин. Например:

OEE Engine
    ↓
Availability = 82%
Performance  = 91%
Quality      = 98%
    ↓
Loss Analysis
    ↓
Business Tools
    ↓
LLM
    ↓
«Основная потеря за смену —
простой оборудования из-за
ожидания материала.»

AI не должен сам придумывать OEE или пересчитывать производственную статистику по неструктурированным данным. Он должен получать уже рассчитанные показатели и объяснять их с помощью контролируемых инструментов.

Business Tools для AI-аналитика производства

get_oee()
get_oee_losses()
get_downtime()
get_cycle_time()
get_quality_losses()
get_production_plan()
get_production_fact()
get_material_shortages()
get_bottlenecks()

Тогда руководитель может спросить:

«Почему OEE участка снизился
вчера относительно прошлой недели?»

а AI получает структурированные показатели и строит объяснение на их основе.

Минимальный MVP OEE

Для первого проекта не нужно подключать весь завод. Достаточно одного участка и нескольких станков.

Production-grade архитектура

┌─────────────────────┐
│     SCADA / PLC     │
│ states / counters   │
└──────────┬──────────┘
           │
     OPC UA / MQTT
           │
           ▼
┌─────────────────────┐
│ Integration Gateway │
│ normalize / map     │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│     PostgreSQL      │
│ events / counters   │
│ production runs     │
└──────────┬──────────┘
           │
           ▲
           │
┌──────────┴──────────┐
│       1С:ERP        │
│ orders / operations │
│ products / norms    │
│ quality / output    │
└─────────────────────┘
           │
           ▼
┌─────────────────────┐
│     OEE Engine      │
│ A / P / Q / losses  │
└──────────┬──────────┘
           │
      ┌────┴─────┐
      ▼          ▼
 Dashboard      AI
      │          │
      └────┬─────┘
           ▼
     Management / MES

Типичные ошибки при расчёте OEE

Ошибка	Последствие
Считать OEE только из выпуска 1С	Не видны реальные простои и потери скорости
Считать OEE только из SCADA	Не хватает бизнес-контекста и данных качества
Не определить плановое производственное время	Availability считается неоднозначно
Использовать среднюю скорость вместо идеального цикла	Performance становится методологически спорным
Не различать good и total count	Quality рассчитывается неверно
Не классифицировать простои	OEE показывает процент, но не объясняет потери
Не связать SCADA ID с рабочим центром 1С	Невозможно корректно объединить данные
Хранить только итоговый OEE	Нельзя пересчитать KPI после исправления исходных данных
Передавать всю телеметрию в 1С	Создаётся лишняя нагрузка на оперативный контур
Давать LLM самой считать OEE	Теряется воспроизводимость расчёта

Итог

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

Базовая формула:

OEE = Availability × Performance × Quality

При этом источники данных удобно разделить:

SCADA
→ состояния оборудования
→ простои
→ циклы
→ скорость
→ фактический выпуск

1С
→ заказы
→ изделия
→ операции
→ нормативы
→ рабочие центры
→ план
→ качество / выпуск

        ↓

OEE Engine
        ↓

Availability
Performance
Quality
        ↓
OEE
        ↓
Loss Analysis
        ↓
Bottleneck / APS / AI

Для небольшого производства расчёт можно реализовать непосредственно в существующей производственной системе. Для крупного предприятия рациональнее выделить отдельный аналитический контур: SCADA → Integration Layer → PostgreSQL → OEE Engine → BI/AI, используя 1С как источник бизнес-контекста и учётных данных.

В итоге OEE становится частью замкнутого производственного контура: план → производство → факт → OEE → анализ потерь → bottleneck → перепланирование.