Программное обеспечение для
энергетики, мобильности и медиа
Мы работаем в четырёх областях, где данные поступают в реальном времени, протоколы промышленные, а ошибочные показания имеют операционные последствия. Выберите направление, наиболее близкое к вашей задаче — каждая страница описывает, что мы строим, и используемый стек.
Где мы работаем глубоко
Команда, уже владеющая протоколами, моделями отказов и операторской терминологией отрасли, не выставляет клиенту счёт за это обучение. Работа начинается на уровне интеграции, а не с первых принципов.
ПО для портфеля солнечных объектов→
Портфельный мониторинг для операторов PV: телеметрия инверторов в реальном времени, скорректированный по инсоляции коэффициент производительности, отчёты по выработке и основанные на правилах оповещения для нескольких площадок.
Управление и мониторинг BESS→
Диспетчерские представления батарейных блоков, PV-инверторов и DC-строк: потоки энергии в реальном времени, аналитика SOC/SOH, диагностика на уровне строк и основанные на правилах аварийные сигналы.
Платформы EV-зарядки→
Бэкенды CPO и EMSP, white-label управление зарядкой, интеллектуальная зарядка и балансировка нагрузки, а также маршрутное планирование для коммерческих EV-парков с несколькими остановками.
Видеоинфраструктура→
Конвейеры транскодирования и упаковки: ABR-лестницы, per-title кодирование, низколатентный HLS, multi-DRM доставка и аппаратно-ускоренное кодирование в масштабе.
Универсальные команды изучают область за ваш счёт
Большая часть затрат в промышленном программном проекте — не в коде, а в недопонимании. Команда, которая никогда не читала модель данных IEC 61850 или относится к сессии OCPP как к простому запросу/ответу, обнаруживает реальные требования во время интеграционного тестирования. Это самое дорогостоящее место для их выявления.
Работа в ограниченном числе областей позволяет нам отталкиваться от ограничений, а не от фреймворка. Мы знаем, какие поля телеметрии ненадёжны на практике, какие реализации вендоров отклоняются от спецификации и на какие показатели оператор смотрит в первую очередь.
- Поведение протоколов известно заранее, а не обнаруживается во время интеграции
- Модели данных спроектированы под реальные паттерны запросов, а не под универсальный CRUD
- Интерфейсы проверяются по тому, как работают операторы, а не как выглядят демо
- Режимы отказов и граничные случаи определяются на этапе архитектуры, а не после запуска
- Оценки основаны на реалиях области, а не на оптимистичных аналогиях
Что объединяет все четыре направления
Области различаются; инженерный фундамент — нет. Каждая платформа, которую мы создаём, опирается на одни и те же три уровня.
Приём телеметрии
Адаптеры протоколов, приём через брокер и поллинг, конвейеры обогащения данных и хранилище временных рядов, оптимизированное под реальные паттерны запросов операторов.
Интерфейсы операторского уровня
React-дашборды реального времени для людей, принимающих решения под временным давлением — сначала иерархия информации, потом выбор библиотеки графиков.
Производственные операции
Структурированное логирование, распределённая трассировка, оповещения и CI/CD-конвейеры с первого коммита — система остаётся поддерживаемой после передачи.
Не уверены, какой раздел подходит вашему проекту?
Опишите оборудование, протоколы и пользователей. Мы скажем, что является прямолинейным, что несёт риск и где мы уже это делали.