Урок 2: Shell + C3 AI — самый детальный архитектурный кейс промышленного AI

Чему вы научитесь

• Разбирать кейс Shell + C3 AI как архитектуру платформы, а не как красивый PdM-слайд
• Видеть, какие слои нужны для industrial AI at scale: ingestion, lakehouse, model factory, serving и action path
• Понимать, почему Shell сумел перейти от единичных моделей к тысячам production-сценариев
• Переводить западный reference stack в российский on-prem вариант без C3 AI, Databricks и Azure
• Избегать типовой ошибки «сначала купим модель, потом разберёмся с данными»

Если нужен один публичный кейс, который объясняет, как industrial AI выглядит на масштабе реальной process company, то это Shell + C3 AI. Здесь хорошо не только число моделей, но и дисциплина построения платформы: data layer, фабрика моделей, контур эксплуатации и механизм превращения prediction в рабочее действие.

Почему этот кейс стал каноническим

Официальный блог C3 AI фиксирует у Shell 10 000+ единиц оборудования под predictive maintenance, 3 млн+ data streams, 20 млрд строк данных в неделю и 15 млн+ предсказаний в день. Там же сказано, что в проде работает 10 000+ production-grade ML models (C3 AI, 07.03.2022).

Для управленческой и архитектурной работы в этом уроке держимся официальной цифры C3 AI — 10 000+ production-grade ML models (C3 AI).

Архитектура Shell + C3 AI по слоям

flowchart LR
    A[Historian / OT / sensors] --> B[Ingestion layer]
    B --> C[Azure + Databricks + Delta Lake]
    C --> D[Feature engineering and data products]
    D --> E[C3 AI model factory]
    E --> F[Registry and serving]
    F --> G[Predictions and anomaly scores]
    G --> H[Alerts dashboards work orders]
    H --> I[Maintenance and operations teams]
    I --> J[Feedback loop]
    J --> D
    C --> K[Kongsberg digital twin / asset context]
    K --> E

Главная мысль схемы: Shell масштабировал не отдельную модель, а конвейер. Именно поэтому новые use cases там можно разворачивать не месяцами, а днями и неделями.

Что делает этот стек production-grade

1. Единая модель актива

Shell не оставил данные в виде несвязанных тегов. Для predictive maintenance мало знать, что у вас есть вибрация и температура. Нужно понимать, что это именно этот компрессор, на этом объекте, в этом режиме и в этой технологической цепочке. Эту роль играет контекстный слой вокруг digital twin и enterprise data model.

2. Фабрика моделей, а не hand-made data science

Если у вас сто активов и десять data scientists, ручная разработка ещё как-то возможна. Если у вас 10 000+ единиц оборудования и 10 000+ production models, без стандартизации training, testing, deployment и monitoring система разваливается организационно раньше, чем технически.

3. Action path как часть архитектуры

Shell подчёркивает не только training and run millions of models, но и экономику: lower costs, fewer production interruptions, less unplanned downtime and extended asset life (C3 AI). Это возможно только потому, что prediction встроен в operating model.

Что из этого можно буквально взять на свой НПЗ

Именно поэтому для российского предприятия главный урок Shell — не «нам нужен C3 AI», а «нам нужна platform discipline».

Минимальная воспроизводимая версия для РФ

Если отрезать недоступные компоненты, базовый on-prem эквивалент выглядит так.

Такой стек сам по себе слабее по полировке, чем Shell platform. Но он доступен, управляем и не ломается на российском санкционном контуре. Практически он разбирается в p.9/06, а выбор контуров — в p.2/05.

Где компании ошибаются, когда пытаются «сделать как Shell»

Есть ещё три типовых ошибки.

• Сразу идти в 1000 моделей без нормализации тэгов и единиц измерения.
• Строить prediction без связи с EAM, CMMS или рабочими нарядами.
• Оценивать проект по точности модели, а не по времени до action и avoided downtime.

Как собирать аналог без иллюзий

1. Начните с asset class, а не со всего предприятия. Один тип компрессоров, насосов или теплообменников — правильный первый шаг.

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

3. Постройте model factory раньше, чем portfolio. Если каждая модель деплоится вручную, дальше десяти use cases вы не дойдёте.

4. Сразу проектируйте feedback loop. У alert должен быть исход: ложный сигнал, подтверждённый риск, выполненный ремонт, фактический отказ.

5. Не тащите облачную архитектуру в контур, где она недопустима. Для КИИ и чувствительных активов это отдельный стоп-фактор — см. p.3/02.

Зачем этот кейс нужен директору НПЗ

Не для того, чтобы покупать C3 AI. А для того, чтобы увидеть правильный порядок слоёв:

1. Data foundation.
2. Context and asset model.
3. Model factory.
4. Serving and monitoring.
5. Action path.

Если этот порядок нарушить, industrial AI останется серией красивых pilots. Если сохранить, даже более скромный российский стек может повторить логику Shell на меньшем масштабе.