AetherONE™ · Приложение AMI для энергокомпаний

ОБЗОР ПРОДУКТА

Одно приложение. Шесть чётких зон ответственности.

AetherONE — полное приложение AMI для энергокомпаний в составе Aether Utility Platform. Оно объединяет AetherHES, AetherMDMS, AetherCIS, AetherGIS, AetherRevenue и AetherDispatch.

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

AetherUtilityConsole — единая точка входа во фронтенд. Управляющий слой контрактов и покрытия поддерживает схемы, покрытие и доказательства; это не седьмой бизнес-продукт и не общий бизнес-бэкенд.

Для кого предназначен

Руководители программ энергокомпаний и архитекторы AMI
Руководители продуктов, данных и интеграции

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

Обязанности и объём оценки

AetherHES: Утверждённый объём проектированияСвязь с устройствами, сбор, исходные записи и доказательства исполнения команд.; Доступно в этой редакцииЛокальный компонент с ограниченным объёмом для оценки; условия внедрения требуют приёмки для конкретного проекта.
AetherMDMS: Утверждённый объём проектированияКонтекст учёта с периодами действия, версии измерений, VEE, Usage, технические Bill Determinants и доставка.; Доступно в этой редакцииЛокальный компонент с ограниченным объёмом для оценки; условия внедрения требуют приёмки для конкретного проекта.
AetherCIS: Утверждённый объём проектированияИдентичность и жизненный цикл Party, Customer Account, Premise, Service Point, Service Agreement и Service Request.; Доступно в этой редакцииОценочный интерфейс с синтетическими данными; без реальной бизнес-эксплуатации и сохранения данных.
AetherGIS: Утверждённый объём проектированияРазрешение адресов и местоположений, зоны обслуживания, пространственные версии и версии топологии.; Доступно в этой редакцииОценочный интерфейс с синтетическими данными; без реальной бизнес-эксплуатации и сохранения данных.
AetherRevenue: Утверждённый объём проектированияПроектирование тарифов, финансового выставления счетов, платежей, задолженности, взаиморасчётов, предоплаты и STS.; Доступно в этой редакцииОценочный интерфейс с синтетическими данными; без реальной бизнес-эксплуатации и сохранения данных.
AetherDispatch: Утверждённый объём проектированияПолевые работы энергокомпаний: наряды, бригады, подрядчики, полевые доказательства и завершение.; Доступно в этой редакцииОценочный интерфейс с синтетическими данными; без реальной бизнес-эксплуатации и сохранения данных.
AetherUtilityConsole: Утверждённый объём проектированияВспомогательный единый фронтенд для навигации и объединения представлений только для чтения; без общего продуктового бэкенда.; Доступно в этой редакцииОбъединяет представления оценочных интерфейсов.
AETHER_UTILITY_PLATFORM: Утверждённый объём проектированияВспомогательный управляющий слой версионированных контрактов, покрытия функций, проверки проекций и доказательств поставки.; Доступно в этой редакцииОпределения контрактов и доказательства покрытия; без владения бизнес-записями.

Как связаны процессы

Оригинальные схемы и фрагменты интерфейса ниже — на английском. Сопроводительное описание объясняет их объём на языке страницы.

Проект нового обслуживания: заявка CIS, местоположение GIS, полевые работы Dispatch, установка MDMS и связь HES. — Проектный процесс. Показанные связи не означают работающую межпродуктовую интеграцию.

Проектная цепочка постоплаты: от декодированного показания через измерения, Usage и технический Bill Determinant до счёта Revenue и платежа. — Проектный процесс. Показанные связи не означают работающую межпродуктовую интеграцию.

Чёткие зоны ответственности продуктов

Customer Account и финансовый контекст: CIS отвечает за идентичность и жизненный цикл клиента/учётной записи. Revenue использует ссылки финансового контекста; документы не устанавливают их соответствие Customer Account в CIS.
Service Point и Metering Point: CIS отвечает за идентичность места обслуживания; MDMS — за объект учёта и установки. Наличие обеих ссылок не объединяет объекты и не означает связь один к одному.
Bill Determinant и финансовый счёт: MDMS предоставляет технические Bill Determinants. Revenue отвечает за финансовый расчётный счёт, счёт-фактуру, платёж и взаиморасчёты.
Service Request и Work Order: CIS отвечает за исходную заявку. Dispatch — за полевой наряд. Dispatch не является диспетчеризацией сети, SCADA или OMS.
Доказательства команд и бизнес-результат: Транспортное подтверждение, подтверждение устройства и совпадающее обратное считывание — отдельные доказательства HES. Итоговый бизнес-результат определяет ответственный бизнес-домен. Исходные байты устройства остаются закрытыми внутри HES.

Сценарии энергокомпаний

Новое обслуживание и установка

Заявка CIS → местоположение GIS → наряд и доказательства Dispatch → проверенная установка MDMS → связь HES и первое декодированное показание. Это целевой межпродуктовый результат поставки.

Замена счётчика и непрерывность

Dispatch предоставляет проверенные полевые доказательства. MDMS сохраняет старую и новую установки и ссылки соседних интервалов с происхождением.

Расчёты с постоплатой

Декодированные показания превращаются в версии измерений, принятые интервалы, Usage и технические Bill Determinants, прежде чем Revenue выставит счёт и сверит платёж.

Выдача токенов STS

Revenue отвечает за финансовое состояние/предоплату; платёж, токен, доставка и сверка — разные этапы. Текущая оценка не подтверждает производственную STS.

Сверка адреса и GNSS

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

Редакция и условия оценки

HES и MDMS предоставляют локальные компоненты ограниченной оценки; HES использует детерминированный имитатор адаптера. CIS, GIS, Revenue и Dispatch предоставляют оценочные или демонстрационные интерфейсы на синтетических данных.

Определения контрактов не доказывают развёрнутое соединение. Межпродуктовые сценарии — цели проектирования и поставки. Адаптеры устройств/систем, версии контрактов, аутентификация, изоляция арендаторов, доступность и производительность требуют приёмки для каждого проекта и продукта.

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

Редакция документов 2026.10 обозначает предоставленные материалы, а не коммерческий релиз или развёрнутую версию.

Документы продукта

Выберите язык, чтобы скачать соответствующую версию документа.

Техническое описаниеРусский · PDFРедакция документов 2026.10

Обсудить оценку ↗

Приложение AMI для энергокомпаний

Шесть бизнес-продуктов.

Головная система сбора данных

Управление данными счётчиков

Информационная система по клиентам

Географическая информационная система

Управление доходами

Диспетчеризация нарядов на работы