Интеграция оборудования Гарвекс: как описать передачу данных от удалённого контейнера

Зачем описывать передачу данных заранее

Когда оборудование находится на удалённом объекте, важно заранее договориться не только о том, какие сведения нужны, но и о том, откуда они поступают, куда передаются и кто отвечает за каждый участок. Такая схема помогает согласовать требования к интеграции до начала работ и не путать подтверждённые функции оборудования с пожеланиями заказчика.

Если речь идёт о контейнерной АЗС, то есть КАЗС, описание должно учитывать весь путь данных от точки отпуска топлива до места, где эти сведения будут просматривать или обрабатывать. Конкретная конфигурация, состав оборудования и способ связи зависят от проекта. Если нужных сведений нет в документации, их необходимо уточнить до выбора схемы.

В материалах Гарвекс для заправочного модуля указана беспроводная передача данных о заправках через GSM на удалённый сервер. Также описана интеграция «АЗС-Онлайн» со сторонним программным обеспечением по API. Эти сведения можно использовать как отправную точку для проектного описания, но не как подтверждение любой произвольной схемы подключения.

Сначала опишите источники и получателей данных

До обсуждения «шлюза топливных данных» составьте простой перечень участников процесса. Это может быть удобная таблица для заказчика, проектировщика и интегратора.

На этом этапе полезно отделить факты от предположений. Например, «данные о заправках передаются через GSM на удалённый сервер» — это характеристика, приведённая для заправочного модуля в документации Гарвекс. А конкретные параметры сети на объекте, состав дополнительных устройств и порядок обмена между ними нельзя считать установленными без подтверждения для выбранной конфигурации.

Как записать путь данных

Описывайте маршрут последовательно, от источника до конечного пользователя. Не добавляйте в схему промежуточные устройства, протоколы и функции, если они не подтверждены документацией для конкретного оборудования.

Для предварительного описания можно использовать такой шаблон:

1. Источник. Укажите устройство, в котором возникает информация, и назовите тип сведений, необходимых заказчику.
2. Передача с удалённого объекта. Запишите подтверждённый способ передачи. Для заправочного модуля в документации указана передача через GSM на удалённый сервер.
3. Приём и обработка. Укажите, какая система должна принять сведения. «АЗС-Онлайн» описан как серверное решение для обработки, хранения и передачи информации по топливным операциям.
4. Доступ к результату. Зафиксируйте, кому и для какой задачи нужны данные. Не следует обещать конкретный экран, отчёт или набор полей, если это не подтверждено для проекта.
5. Передача во внешнее ПО. Если требуется обмен со сторонней системой, отметьте необходимость согласовать интеграцию по API. Само наличие такой возможности не задаёт состав данных и порядок обмена для конкретного проекта.

В рабочем документе можно сформулировать это как ожидаемый маршрут: «Источник данных на удалённом объекте → согласованный канал передачи → серверное решение → просмотр или обмен со сторонним ПО». Это именно описание логики проекта, а не гарантия того, что любая комбинация оборудования заработает без дополнительной проверки.

Что указать о данных

Составьте перечень сведений, которые нужны пользователям. Для каждого пункта обозначьте, является ли он обязательным, кто его использует и каким документом или участником проекта подтверждается его получение.

Например, заказчик может запросить электронный журнал заправок или сведения, необходимые для учёта топливных операций. В материалах Гарвекс для заправочного модуля указано ведение электронного журнала заправок, а для «АЗС-Онлайн» — обработка и хранение информации по топливным операциям. Однако конкретный формат записи, перечень полей, периодичность обновления и правила выгрузки в эти сведения не включены. Их нельзя указывать как готовые характеристики без отдельного подтверждения.

Для каждого требуемого поля удобно добавить пометку:

• подтверждено документацией;
• требуется согласовать;
• не предусмотрено имеющимися сведениями.

Такой список снижает риск того, что в техническое задание попадут неподтверждённые требования.

Подключение периферии и роль шлюза

Подключение периферии АЗС следует описывать отдельно от передачи данных на сервер. Перечислите необходимое оборудование и задачу, которую оно должно решать, но не назначайте ему интерфейсы или совместимость без документации. Если планируется использовать оборудование стороннего производителя, не переносите на него характеристики решения Гарвекс и запросите подтверждение конкретной схемы интеграции.

Термин «шлюз топливных данных» тоже лучше раскрыть в техническом задании: что именно он должен принимать, куда передавать и кто определяет формат обмена. Не стоит считать, что шлюз уже включён в состав оборудования, поддерживает нужный канал связи или автоматически обеспечивает совместимость со всеми системами.

В документах Гарвекс описана интеграция «АЗС-Онлайн» со сторонним программным обеспечением по API. Это основание обсудить интеграцию, но не готовое описание API конкретной системы. Назначение, состав данных и условия обмена нужно согласовать для проекта.

Что проверить до запуска

Перед финальным согласованием схемы соберите ответы на вопросы:

• Где находится источник данных и кто отвечает за него на объекте?
• Какой способ передачи указан в документации выбранного решения?
• Какое ПО должно получить сведения?
• Какие данные нужны заказчику и какие из них подтверждены?
• Нужна ли интеграция со сторонней системой по API?
• Кто подтверждает доступность связи и проверяет передачу на объекте?
• Какие вопросы пока остаются открытыми?

Техническая документация и сведения о контроллерах доступны в разделе документов Гарвекс. Если в ней нет ответа о конкретной комплектации, периферии или условиях интеграции, эти параметры необходимо согласовать с компанией; связаться с ней можно через страницу контактов.

Вывод

Чтобы описать передачу данных от удалённого контейнера, зафиксируйте источник, подтверждённый канал, получателя, требуемые сведения и ответственных за проверку. Для решений Гарвекс в документации указаны передача данных заправок через GSM на удалённый сервер и интеграция «АЗС-Онлайн» со сторонним ПО по API. Остальные параметры следует проверять отдельно, не подменяя проектные требования предположениями.

Если вы готовите техническое задание или схему обмена, отправьте специалистам описание объекта, нужных данных и используемого ПО. Это поможет определить, какие пункты уже подтверждены, а какие нужно дополнительно согласовать.