Система специализированных сервисов
RIC разделяет подключение устройств, обработку данных, хранение, автоматизацию и доступ приложений между отдельными сервисами. Каждый решает свою задачу; совместная работа строится на обмене сообщениями, вызовах программных интерфейсов и общей модели объектов.
Rightech IoT Core / карта взаимодействий
Общий контрактМодель объектаМодели из RIC Store ↗
Параметры · типы · единицыЕдиный смысл данных для сервисов и приложений
Команды · аргументыОписание доступных операций оборудования
Специализированные сервисы. Общая модель объекта.Шлюз связывает оборудование с платформой. Сервисы обмениваются сообщениями и вызывают операции через описанные интерфейсы.
01Подключение
Шлюзы работают с протоколами оборудования; ric-auth проверяет доступ устройств.
02Обмен сообщениями
Брокер AMQP связывает сервисы через подписки.
03Обработка и применение
Обработчики, состояние, история и сценарии используют сообщения согласно настройкам.
04Доступ и управление
API связывает приложения с объектами; сервис команд передаёт операции шлюзам.
↔ Прокрутите схему, чтобы увидеть все связи
Сообщения и телеметрияВызов командыРасширение операцииПроверка доступа
Данные и контекстСервисы обращаются к нужным им хранилищам
01 / хранениеГорячий кэшТекущее состояние объектов и оперативный доступ
02 / хранениеХранилище временных рядовИстория телеметрии, графики и анализ за период
03 / хранениеХранилище сущностейПроекты, модели, объекты и настройки
04 / хранениеОбъектное хранилищеФайлы, прошивки и сформированные материалы
Доступ к секретам и картографическим данным обеспечивают специализированные компоненты установки.
Специализированные сервисы Геоданные, уведомления, отчёты и работа с оборудованием
ric-geoГеоданныеГеозоны, маршруты и картографические данные
ric-notifyУведомленияПередача сообщений во внешние каналы
ric-reportsОтчётыПодготовка документов по данным за период
ric-otaОбновление устройствУдалённая доставка прошивок поддерживаемому оборудованию
ric-botsСимуляторыЭмуляция устройств для проверки обмена
ric-lora-stackLoRaWANИнтеграция устройств через сетевой стек
В архитектуре предприятия RIC связывает оборудование и локальную автоматизацию с прикладными системами. Один программный слой объединяет данные нескольких площадок и распределённых активов. Локальные регуляторы и системы защиты сохраняют свои задачи рядом с оборудованием.
Свобода выбора устройств и протоколов
RIC не ограничивает проект одним производителем или фиксированным списком оборудования. Сетевое устройство подключается через протокольный адаптер; оборудование с локальными интерфейсами — через шлюз площадки. Для нового протокола можно разработать адаптер и включить его в тот же тракт данных и команд.
Готовые протокольные интеграции
MQTT / MQTTS · CoAP · LwM2M · WebSocket · LoRaWAN
Wialon · Teltonika · Galileosky · Navtelecom · Queclink · Concox
В платформе уже есть адаптеры стандартных и специализированных протоколов. В документации указаны точки подключения, версии и поддерживаемые возможности. Modbus и KNX доступны по запросу.
Если у устройства свой формат
Пользовательский обработчик разбирает данные внутри поддерживаемого транспорта: например, бинарный пакет в MQTT. Если требуется другой сетевой обмен, добавляется протокольный адаптер. Для интеграции нужны описание протокола, способ доступа и тестовые пакеты или само устройство.
После преобразования данные становятся параметрами модели. Например, два датчика передают температуру в разных форматах и единицах, а обработчики приводят её к общему параметру в °C. Один сценарий контроля температуры можно применять к обоим объектам — правила приложения опираются на смысл данных.
Слабая связанность и контракты
У потока телеметрии и вызова конкретной операции разные требования к взаимодействию. RIC использует асинхронную шину сообщений и RPC-интерфейсы для соответствующих задач.
Брокер сообщений AMQP
Сервис публикует сообщение в обменник. Брокер маршрутизирует его в очереди, на которые подписаны потребители. Издателю не требуется напрямую вызывать каждого получателя.
Так разделяются приём данных и их дальнейшее использование. Новый потребитель подключается через маршрутизацию и подписку: протокольному адаптеру не нужно знать его адрес и способ обработки. Очереди позволяют участникам обрабатывать поток в своём темпе в пределах настроенной ёмкости и пропускной способности.
Вызовы сервисов: gRPC / Protobuf
RPC-интерфейсы описывают доступные методы, структуру запросов и ответов. По определениям Protobuf создаётся код взаимодействия для разных языков программирования.
Например, сервис команд предоставляет операцию отправки команды объекта. Вызывающая сторона работает с её интерфейсом; подготовка команды выполняется внутри сервиса. Компоненты можно развивать отдельно, сохраняя совместимость опубликованного контракта.
Три уровня контрактов
- Протокол устройства задаёт формат сообщений, идентификацию, параметры и допустимые команды оборудования.
- Модель объекта связывает протокольные данные с именованными параметрами, типами, единицами измерения и командами. Этим описанием пользуются интерфейс, обработчики и сценарии.
- Программные интерфейсы задают взаимодействие сервисов и приложений: внутренние RPC-вызовы и внешний REST API.
Контракт включает и смысл операции: что означает результат, какие ошибки возможны, допустим ли повторный вызов. Схема сообщения описывает его структуру; правила обработки определяются соответствующим сервисом и протоколом.
От протокола к данным и действиям
Подключение и нормализация
Протокольные адаптеры ric-gate принимают данные оборудования и приводят их к внутреннему представлению. ric-auth участвует в проверке доступа устройств. Объект связывает подключение с моделью и проектом, поэтому последующие компоненты работают с параметрами объекта и его контекстом.
Обработка и автоматизация
Обработчики данных
ric-handler выполняет пользовательские функции над входящими параметрами: преобразует значения, фильтрует данные и рассчитывает производные показатели. Входы и выходы обработчика связываются с параметрами модели.
Команды и обратная связь
Приложение или сценарий → ric-cmds → протокольный шлюз → устройство. Сервис команд использует описание команды в модели, подготавливает её параметры и передаёт запрос по каналу подключения. Ответ оборудования возвращается по входящему тракту.
Приём запроса платформой, доставка сообщения и выполнение действия устройством — разные этапы. Способ сопоставления ответа с командой и возможность повторной отправки зависят от протокола и смысла операции.
Состояние, история и контекст
Для разных задач используются разные представления данных. Быстро прочитать текущий параметр, построить график за месяц и изменить модель объекта — разные операции с разными требованиями к хранению.
AI ready: от данных оборудования к действию
Для AI нужны данные с понятным смыслом: что измерено, на каком объекте, в каких единицах и когда. RIC собирает телеметрию разнородного оборудования, связывает её с моделью объекта и сохраняет историю. Это основа для подключения внешних ML-моделей и AI-сервисов к реальным процессам.
- 01 / ДАННЫЕСобрать и подготовитьАдаптеры принимают данные устройств. Обработчики приводят значения к нужным единицам и рассчитывают производные показатели.
- 02 / КОНТЕКСТСохранить смыслИдентификатор объекта, параметры модели, временные метки и история связывают измерения с оборудованием и его состоянием.
- 03 / АНАЛИЗПодключить AI-модельСервис аналитики получает данные через API. Интеграцию можно собрать в n8n или собственном приложении, выбрав модель под задачу.
- 04 / ДЕЙСТВИЕИспользовать результатВебхук обработчика записывает результат в параметры объекта. Сценарий уведомляет оператора, создаёт задание технику или отправляет команду.
Архитектура интеграции: RIC подготавливает данные и исполняет настроенные
сценарии; выбранная AI-модель выполняет анализ во внешнем сервисе.
Пример — оценка состояния насоса. Внешняя ML-модель анализирует историю вибрации, температуры и нагрузки и возвращает оценку отклонения. RIC сохраняет её как параметр объекта; сценарий при заданном пороге создаёт задание на осмотр. Алгоритм, пороги и качество прогноза проверяются на данных конкретного оборудования.
Та же основа подходит для AI-помощника: приложение передаёт языковой модели выбранные параметры и историю для подготовки объяснения или сводки. Доступ к данным и управляющим операциям задаётся правами API-клиента и правилами интеграции. Аналитический сервис можно развивать отдельно, сохраняя согласованный формат результата для сценариев RIC.
Открытость и расширение
Открытость RIC выражается в поддержке протоколов оборудования, программных интерфейсах и способах расширения прикладной логики. Устройства разных производителей и внешние приложения подключаются через эти точки взаимодействия.
API для собственных приложений
ric-web предоставляет пользовательский интерфейс и внешний REST API. Собственные приложения могут работать с объектами, данными и командами в пределах выданных прав. Модели задают параметры и команды, которые используются и в интерфейсе RIC.
Логика решения отдельно от ядра
Модели описывают объекты, обработчики преобразуют данные, автоматы задают сценарии. Actions добавляют пользовательский код для прикладных операций в отдельной среде выполнения. Обработчик входящих параметров и Action имеют разные задачи и способы запуска.
Эти механизмы позволяют адаптировать решение через настройки и прикладной код. Новый протокольный адаптер или изменение внутренних сервисов относятся к разработке платформы. Доступность Actions и других дополнительных сервисов определяется составом установки.
Стандартные средства взаимодействия
MQTT и HTTP на стороне подключений, AMQP в шине сообщений, gRPC/Protobuf во внутренних интерфейсах и HTTPS для внешнего API дают разработчикам знакомые инструменты интеграции. Набор поддерживаемых протоколов позволяет выбирать оборудование под задачу, а модель — согласовывать его данные с приложением.
Готовые приложения и экосистема
Модель объекта служит общей основой для интерфейсов и автоматизации. Команда может начать с приложений RIC, перенести конфигурации из RIC Store и подключить собственные системы через API.
RIC App — оборудование под рукой
Мобильное приложение для Android и iOS: список объектов, актуальные параметры и отправка настроенных команд. Поддерживает подключение к собственному серверу RIC.
Инженер использует ту же модель объекта, что и веб-интерфейс: описание параметров и команд уже подготовлено в платформе.
RIC Service — работа выездных техников
Приложение для Android связывает задания по обслуживанию с оборудованием: техник видит заявки, принимает их в работу и меняет статус. В платформе настраиваются назначение заданий и отчёт о выполнении.
Сценарий RIC может создать задание по событию оборудования. Так данные устройства становятся основанием для конкретного действия сотрудника.
RIC Store — конфигурации для повторного использования
Каталог моделей устройств, обработчиков и готовых решений со сценариями и связями между компонентами. Выберите подходящий состав, импортируйте его в проект и адаптируйте под свою задачу.
Одна конфигурация может стать основой нескольких внедрений — в облаке Rightech или собственной установке RIC.
API и n8n — связь с информационными системами
Готовый коннектор Rightech для n8n позволяет работать с объектами, телеметрией и командами в сценариях интеграции. Например, связать событие оборудования с CRM, отчётом или уведомлением.
Для собственной разработки доступен REST API. Прикладная система обращается к объектам и операциям RIC через интерфейс платформы.
Масштабирование и эксплуатация
Масштабирование по компонентам
Нагрузка распределяется по разным частям системы: шлюзы обслуживают подключения, обработчики выполняют вычисления, хранилища принимают записи и обслуживают запросы. Сервисная архитектура позволяет подбирать ресурсы и число экземпляров для отдельных компонентов с учётом их способа распределения работы.
Число устройств — один из входных параметров расчёта. Для выбора конфигурации также учитываются частота и размер сообщений, сложность обработчиков, интенсивность команд, сроки хранения и запросы пользователей. Брокер и хранилища входят в общий расчёт пропускной способности.
Kubernetes ready
RIC поставляется для контейнерного развёртывания в Kubernetes. Helm описывает состав установки и её конфигурацию. Команда эксплуатации работает с привычными манифестами, ресурсами и репликами сервисов.
Доступность всей системы зависит также от конфигурации брокера, баз данных и сетевых связей. Для рабочей установки определяются резервирование, резервное копирование, мониторинг и порядок восстановления. Гарантии доставки сообщений задаются конкретным трактом обработки и его настройками.
Мультитенантность и доступ
Пространство проекта
Проекты разделяют объекты, настройки и доступ пользователей внутри одной установки. Это позволяет интегратору вести решения разных заказчиков, а предприятию — организовывать работу подразделений и команд.
Изоляция проектов реализуется на уровне платформы. Выделенное размещение выбирается отдельно, когда требуется собственная инфраструктура.
Разрешения и подключения
Доступ пользователей и API-клиентов определяется назначенными правами. Устройство проходит проверку при подключении, а поддерживаемый способ аутентификации зависит от протокола.
Для защищённых соединений используются TLS и, в поддерживаемых вариантах подключения, сертификаты X.509. Эти механизмы настраиваются для соответствующих точек доступа.
Размещение и технические материалы
В облаке Rightech команда работает с проектом в подготовленной инфраструктуре. При развёртывании on-premise сервисы и данные размещаются в инфраструктуре заказчика, а параметры установки согласуются с его требованиями к сети, ресурсам и эксплуатации.