Спросите подрядчика «а если пропадёт интернет» — услышите «всё будет работать». Ответ ничего не значит: у сторон разное представление о том, что такое «работать». Для подрядчика это «сервер не упадёт и данные не потеряются». Для владельца объекта — «вентиляция продолжит держать температуру, а насос не встанет».
Ниже — регламент: семь шагов от разговора до приёмки. В каждом шаге одно действие, один вопрос и признак уклончивого ответа. Идите по порядку. Пропустите первый шаг — на остальные получите правдоподобные, но непроверяемые ответы.
Шаг 1. Выяснить, где принимается решение
Выясните, кто отдаёт команду исполнительному механизму: контроллер в шкафу на объекте или сервер подрядчика. Всё остальное следует отсюда.
Вопрос: «Уставки, алгоритм регулирования и защиты лежат в контроллере на объекте или на вашем сервере?» Хороший ответ конкретен: логика и защиты в контроллере, сервер читает состояние и рисует картинку. Уклончивый переводит разговор на надёжность облака. Это ответ на другой вопрос.
Шаг 2. Получить перечень, а не заверение
Просите не обещание, а список: какие функции объекта где исполняются. Список короткий, его составляют за один разговор. Он и станет основанием для приёмки.
- •Поддержание уставок и регулирование,
- •Защиты и блокировки, останов по аварии,
- •Расписание и переход между режимами,
- •Аварийные уведомления людям,
- •Ручное управление оператором,
- •Отчёты, графики, архив показаний,
- •Изменение уставок и настроек.
Нормально, когда первые пункты живут на объекте, а уведомления и отчёты — на сервере. Ненормально, когда разделения в проекте нет вовсе. Признак: никто не может сказать, к какой половине относится конкретная функция.
Шаг 3. Спросить про историю за время обрыва
Пока связи нет, показания продолжают появляться. Спрашивайте тремя частями. Где копится буфер. На какую глубину он рассчитан. Что происходит после восстановления связи: история догоняет сервер или архив начинается с чистого листа.
Здесь же спросите про выгрузку. В каком формате вы заберёте свои данные и что для этого нужно сделать. Кнопка в интерфейсе и выгрузка по запросу годятся одинаково, если формат открытый, а порядок записан в договоре. Плохой ответ — без формата и без порядка: «понадобится — выгрузим».
Шаг 4. Спросить про команду, отданную в момент обрыва
Оператор нажал «включить», связь в этот момент пропала. Опасен не случай, когда команда не дошла. Опасен другой: дошла позже, когда объект уже перевели в другой режим руками.
Вопрос: «У команды есть срок годности и видит ли оператор, что команда не подтверждена оборудованием?» Правильный ответ описывает поведение системы: команда отбрасывается по времени либо доставляется осознанно, а на экране видно её состояние. Неправильный — снова про стабильную связь.
Шаг 5. Проверить вход на объект без облака
Проверьте, как попасть в систему, когда сервер подрядчика недоступен. Об этом вспоминают последним. Нужен локальный вход: панель в шкафу или страница на самом контроллере. И ваши собственные учётные записи, а не общие пароли исполнителя.
Единственная дверь в объект через личный кабинет подрядчика — автономность только на бумаге. Оборудование продолжит работать, но управлять им и видеть его вы не сможете. Что делать, когда исполнитель перестал отвечать, разобрано отдельно: что делать, если подрядчик пропал с проектом.
Шаг 6. Проверить отключением, а не разговором
Предыдущие шаги — слова. В факт их превращает одно испытание на приёмке. Отключите канал связи физически, а не программно, и зафиксируйте, что произошло.
| Что смотрим | Ожидаемый результат | Признак проблемы |
|---|---|---|
| Работа оборудования | Уставки держатся, режим не меняется | Переход в останов или в «безопасный режим» без причины |
| Локальная история | Показания пишутся на объекте | В архиве провал ровно по времени обрыва |
| Возврат связи | История догоняет сервер без пропусков | Догоняет частично или дублирует записи |
| Уведомления | Приходит сообщение о потере связи | Тишина: обрыв никто не заметил |
| Команды оператора | Видно, что команда не подтверждена | Команда «выполнена» при отключённом канале |
Результат оформите протоколом и включите в документы приёмки. Без протокола спорить будет не о чем: каждая сторона расскажет о том дне свою версию.
Шаг 7. Закрепить проверенное в документах
Перенесите в договор и в состав передаваемого то, что выяснили разговором. Минимум, который стоит требовать:
- •Описание обмена с оборудованием: протокол, адреса, единицы измерения,
- •Право выгрузить свои данные в открытом формате: формат и порядок записаны в договоре,
- •Локальный доступ на объект с вашими учётными записями,
- •Условия сопровождения после сдачи: кто, за какие деньги, с какой скоростью реакции,
- •Протокол испытания с отключением канала связи.
Система собственной разработки — добавьте к списку вопрос об исходниках. Способ не доводить дело до спора — депонирование исходного кода. Что бывает, когда исходников нет, а контроллер уже стоит на объекте, показывает разбор как восстанавливают прошивку без исходников.
Что это меняет на практике
Регламент из семи шагов не делает объект автономным. Он показывает, автономен ли он, — до того как деньги уплачены и оборудование смонтировано. В диспетчеризации мы держимся того же деления: управление остаётся на объекте, облако — витрина и история. Команда при обрыве не теряется: оборудование доберёт её, когда вернётся в сеть. Данные ваши, выгрузка по запросу. Что именно остаётся у заказчика после сдачи — что мы делаем и что остаётся у вас.
Частые вопросы
Диспетчеризация без интернета — это вообще возможно?
Да, и это обычный порядок вещей для инженерных систем: логика, уставки и защиты лежат в контроллере на объекте, а сервер нужен, чтобы смотреть и хранить историю. Интернет в такой схеме влияет на наблюдение и отчётность, но не на то, будет ли работать оборудование. Проверяется это не заверением, а отключением канала связи на приёмке.
Чем автономность отличается от резервного канала связи?
Резервный канал уменьшает вероятность обрыва, автономность отвечает на вопрос, что происходит, когда обрыв уже случился. Это разные вещи, и вторая не покупается первой. Если на вопрос про автономность отвечают про второй модем, вопрос остался без ответа.
Как проверить автономность при приёмке?
Физически отключить канал связи и зафиксировать пять вещей: оборудование продолжает держать уставки, локальная история пишется, после восстановления связи она догоняет сервер без пропусков, само пропадание связи попадает в уведомления, а команда оператора не показывается выполненной при отключённом канале. Результат оформляется протоколом и входит в документы приёмки, иначе проверять будет нечего.
Что делать с командой, которую оператор отдал во время обрыва?
Опасен не сценарий «команда не дошла», а сценарий «дошла позже, когда уже не нужна». Спросите, есть ли у команды срок годности и видит ли оператор, что команда не подтверждена оборудованием. Ответ должен быть про поведение системы, а не про то, что связь обычно не пропадает.
Что записать в договор, чтобы не остаться заложником подрядчика?
Описание обмена с оборудованием — протокол, адреса, единицы измерения, — право выгрузить свои данные в открытом формате с записанным в договоре порядком выгрузки и условия сопровождения после сдачи. Это то, что позволяет продолжить работу с другим исполнителем без переписывания системы заново.