От сигнала датчика к работе инженера
Допустим, датчик насоса передал превышение температуры. Сигнал появился на графике, а диспетчеру ещё нужно найти аппарат, проверить свежесть показания и оформить задание инженеру. При разработке платформы мониторинга оборудования мы предлагаем пройти этот путь целиком: от сообщения устройства до подтверждённого действия службы. Так можно проверить, где потребуется автоматизация и какие решения останутся за сотрудником.
Для связи датчиков с системой технического обслуживания и ремонта (ТОиР) нужны источник сообщений, реестр оборудования и система заданий. Между ними мы предлагаем серверный сервис: он сохраняет исходное сообщение, проверяет данные, применяет согласованное правило и связывает событие с заданием. Кабинет показывает сотруднику основание решения и результат обмена.
Начинаем с одного типа устройства и одного правила реакции. Ниже разберём поля события, привязку к аппарату, повторы и поздние сообщения. Контракт события и матрица исключений помогут подготовить требования к разработке и принять первую версию на понятных примерах.
В этом маршруте различаем три результата: сообщение сохранено, задание создано, работа подтверждена. У каждого свой идентификатор и время. Тогда диспетчер видит, например, что сигнал принят, но передача в сервисную систему ещё ожидает проверки.
- Принимаем событие. Сохраняем источник, исходное сообщение и время получения.
- Проверяем данные. Выясняем, известно ли устройство, пригодны ли значение и временные отметки для выбранного правила.
- Находим актив. Связываем устройство с обслуживаемым аппаратом, его площадкой и ответственной службой.
- Применяем правило. Создаём задание, дополняем открытое или передаём исключение диспетчеру.
- Подтверждаем результат. Сохраняем номер задания, решение сотрудника и выполненное действие.
История сигнала и история работы связаны идентификаторами; сотрудник может проследить основание задания.
Связанные системы: наш опыт в Бакаеве
В «Бакаеве» мы связали приложение, админ-панель и 1С через сервер синхронизации. Фотография, изменённая в админке, обновляется в 1С. Заказ из приложения меняет остатки в админ-панели и учёте, а изменения из 1С доходят до приложения.
Реальный проект 13FOX · ритейл
Каталог и учёт связаны
Мы помогли перенести локальную 1С в облако и настроили обмен с мобильным магазином.
Контракт события сохраняет происхождение данных
Контракт события — договорённость о полях сообщения и их смысле. Мы составляем его по обезличенному примеру данных устройства или API провайдера. Исходное сообщение сохраняем отдельно от подготовленных для обработки полей: при разборе ошибки можно увидеть, что прислал источник и как система это истолковала.
Устройство и актив могут иметь разные номера. Датчик заменили, а насос остался тем же; шлюз передаёт показания нескольких аппаратов. Поэтому привязку ведём в реестре с датой действия и ответственным за изменение. При неизвестной привязке предлагаем отправлять событие на сверку.
| Поле или группа | Что согласуем | Зачем службе |
|---|---|---|
| Источник и устройство | Провайдер, идентификатор устройства, подтверждение отправителя, канал и версия формата | Понять происхождение и выбрать правильную обработку |
| Идентификатор события | Область уникальности, срок хранения и поведение после перезапуска устройства | Узнать повтор ранее принятого сообщения |
| Актив и привязка | Как устройство связано с аппаратом и когда привязка действует | Создать работу на нужное оборудование и площадку |
| Значение и единица | Название параметра, единица, допустимый формат и отсутствие значения | Применить правило к сопоставимым данным |
| Время | Время источника, время приёма, часовой пояс и допустимая задержка | Отличить свежий сигнал от поздней доставки |
| Статус данных | Код качества, его смысл и решение при неизвестном статусе | Не запускать реакцию на непригодное показание |
| Решение обработки | Версия правила, причина решения, номер задания или исключения | Проследить путь от сигнала до действия сотрудника |
Если источник не выдаёт устойчивый номер события, способ распознавания повторов потребуется спроектировать отдельно. Проверяем последовательность сообщений, поведение при перезапуске и доступные признаки. Одинаковые значения температуры в разное время могут быть самостоятельными показаниями; объединять их только по значению опасно.
Время и доставка меняют решение по сигналу
В OPC UA DataValue предусмотрены значение, StatusCode, время источника и время сервера. StatusCode описывает возможность сервера предоставить значение; при коде ошибки значение следует игнорировать. Эти поля полезны для оценки пригодности данных, если ваш источник их передаёт и обработчик учитывает. Точность датчика проверяют отдельно по документации оборудования.
Время источника рекомендуется связывать с последним изменением значения или статуса; оно может отсутствовать. Время сервера отражает получение значения либо момент, когда сервер знал о его актуальности. Поэтому старая отметка источника сама по себе ещё не доказывает задержку доставки: значение могло долго оставаться неизменным. В контракте отдельно согласуем, чем источник подтверждает свежесть данных.
Например, сервер получил сначала нормальное показание, затем более старое сообщение о превышении. Мы предлагаем сохранить оба события, отметить задержку и применить согласованную политику поздних данных. Старое отклонение может потребовать анализа истории; актуальный статус аппарата должен меняться по явному правилу. При недостоверных часах устройства отдельно выбираем способ упорядочивания.
Для MQTT уровни QoS задают правила доставки между отправителем и получателем. QoS 1 допускает повторы, QoS 2 предусматривает однократную доставку в рамках протокольного обмена. Это описано в спецификации MQTT 5.0, разделе 4.3. Создание задания во внешней системе требует собственного контроля результата: протокольное подтверждение не удостоверяет выполненную сервисную операцию.
Повтор передачи и продолжение отклонения обрабатываем отдельно. Повтор узнаём по совпадению согласованного идентификатора или набора признаков события. Для продолжающегося отклонения согласуем границы эпизода: когда оно началось, когда считается завершённым и когда новое показание дополняет открытое задание.
Правило реакции определяет задание и ответственного
В условном сценарии с насосом правило может требовать превышения согласованной границы в течение заданного периода при допустимом статусе данных. Сам порог, длительность, режимы оборудования и условия возвращения к норме определяет техническая служба по применимой методике производителя. Мы переводим утверждённые условия в проверяемую логику и сохраняем версию правила рядом с решением.
Задание получает аппарат, площадку, причину, ссылку на события и ответственного. Если по тому же эпизоду уже есть открытая работа, правило может дополнять её новыми показаниями. Для передачи в CRM или ТОиР согласуем поля, права, статусы и способ поиска ранее созданного задания. При необходимости сотрудники работают в приложении сервисного инженера.
Когда ответ на создание задания потерялся
Допустим, сервисная система создала задание, но наш сервер не дождался ответа. Сохраняем состояние «результат передачи требует сверки». Если API позволяет, передаём вместе с запросом идентификатор операции и по нему ищем созданное задание. После сверки решаем, нужно ли повторять запрос. Когда такой проверки нет, проектируем доступный механизм сверки или передаём ситуацию диспетчеру. Этот сценарий входит в приёмку интеграции.
Возврат параметра к норме записываем в историю эпизода. Закрытие задания отдельно фиксирует, кто проверил аппарат, что сделал и чем подтвердил результат. Так служба различает восстановившийся сигнал и завершённую работу. Состав обмена и проверок обсуждаем при проектировании API-интеграции.
Матрица исключений: что увидит диспетчер
До разработки интерфейса предлагаем заполнить эту матрицу на сообщениях вашего источника. В ней у каждого исключения есть решение системы, понятный сотруднику статус и проверяемый результат. Согласованные ожидания затем становятся сценариями приёмки.
| Ситуация | Предлагаемая реакция | Что проверяем |
|---|---|---|
| Повтор сообщения | Связать с уже принятым событием, сохранить факт повтора | Повтор по согласованному ключу не создаёт второе задание |
| Старый сигнал после нового | Пометить как поздний; обработать по политике времени | История сохранена, актуальный статус не перезаписан молча |
| Низкое или неизвестное качество | Остановить автоматическую реакцию, показать причину проверки | Сотрудник видит исходный статус и дальнейшее действие |
| Нет привязки к активу | Отправить на сверку реестра оборудования | Задание не оказалось на случайном аппарате |
| Нет ожидаемых сообщений | Показать потерю связи или отсутствие ожидаемых данных | У последнего показания видно время; отсутствие сообщений не помечает аппарат исправным |
| Работа по эпизоду уже открыта | Дополнить её либо создать отдельную по утверждённому правилу | Причина выбора записана и доступна диспетчеру |
| Ответ внешней системы потерян | Сверить результат передачи перед повтором | Есть найденный номер задания или явное исключение для сотрудника |
Для контроля отсутствия сообщений сначала выясняем, как источник должен сообщать о своей доступности. Периодическая телеметрия и отправка только при изменении требуют разных ожиданий. Если значение меняется редко, отсутствие новых измерений само по себе недостаточно: согласуем отдельный признак связи и время ожидания.
Первая версия принимается на одном маршруте
Мы предлагаем проверить один тип аппарата, одно правило и одну систему заданий. На испытаниях используем обычное событие, его повтор, позднее сообщение и сбой обмена. В каждом случае прослеживаем исходные данные, решение правила и конечный номер задания либо причину остановки.
- Сообщение с допустимыми данными связано с нужным аппаратом и ответственным.
- Одновременные повторы проверены вместе с обычным повтором после пропавшего ответа.
- Перезапуск обработчика сохраняет возможность сверить незавершённую передачу.
- Неизвестное устройство и непригодные данные видны в очереди проверки.
- Пользователь видит только разрешённые ему аппараты и задания.
- После работы инженера история содержит автора, действие, время и связь с основанием задания.
Если владельцу оборудования нужен доступ к истории, документам и обращениям, его интерфейс строим поверх согласованных прав и статусов. Этот состав разобран на странице кабинета владельца оборудования. Для внутреннего пилота сначала достаточно подтвердить путь до сотрудника службы.
Что влияет на состав разработки и смету
Оценку начинаем с сообщения устройства, реестра активов и нынешнего порядка сервисной работы. Проверяем документацию протокола, доступность API, ограничения хранения и предполагаемый поток данных. Если устройство уже готово, основной объём может приходиться на сервер приёма, проверку событий, обмен с заданиями и интерфейсы команды.
В состав работ включаем описание контракта, адаптер источника, реестр привязок, правила реакции, журнал обработки, интеграцию заданий и сценарии приёмки. Отдельно согласуем размещение, доступы, резервное копирование, наблюдение за сбоями и сопровождение. На объём влияют число форматов сообщений, качество реестра, возможности внешней системы и правила разграничения доступа между клиентами.
Мобильное приложение добавляем, когда сотруднику нужно просматривать задания и подтверждать работу на объекте. Прогноз отказов требует отдельной проверки истории измерений и подтверждённых неисправностей. Для первой версии реакции на известное событие можно согласовать явные правила и проверить их на ваших данных.
Вопросы перед интеграцией телеметрии
Можно ли начать, если устройства уже готовы?
Да. Пришлите обезличенный пример сообщения, описание устройства и доступную документацию обмена. Мы проверим, какие поля доступны для привязки, времени и реакции, и предложим состав серверной части и интеграции.
Нужно ли заменять действующую CRM или ТОиР?
Сначала проверяем её API, права и модель заданий. Если система позволяет создать, найти и обновить нужную работу, предлагаем интеграцию. Ограничения обмена могут потребовать доработки, отдельного модуля или участия диспетчера.
Как избежать повторных заданий?
Согласуем идентификатор или набор признаков для распознавания события, границы эпизода отклонения и идентификатор запроса в систему заданий. Проверяем повторы, параллельную обработку и потерю ответа после создания работы. Возможности сверки зависят от источника и API получателя.
Можно ли закрывать работу после нормализации параметра?
Это отдельное правило службы. Мы предлагаем фиксировать нормализацию сигнала и подтверждение работы сотрудником раздельно, чтобы история показывала и состояние данных, и выполненное действие.
Разберём путь от события до сервисного задания
Пришлите пример сообщения, описание устройства и одно правило реакции. Разберём происхождение данных и предложим контракт события, маршрут задания и тест исключений.