При автоматизации производственных линий часто возникает задача непрерывного сбора телеметрии с десятков и сотен датчиков (температура, давление, счетчики выпуска, скорость линий). На горизонте нескольких лет объем таких данных легко достигает десятков и сотен миллиардов записей (до десятков терабайт сырой информации). При этом от системы управления на базе 1С требуется оперативное получение срезов за смену, проведение расследований инцидентов за произвольные периоды и реакция на сигналы оборудования (например, автоматическая печать этикеток или паспортов изделий).
Разберем по шагам, почему типовые механизмы платформы 1С не подходят для прямого сохранения высоконагруженного потока телеметрии, какую архитектуру внешнего контура выбрать и как организовать взаимодействие между датчиками, внешним хранилищем и 1С.
Попытка записывать сотни и тысячи измерений в секунду напрямую в таблицы 1С (например, в регистры сведений) быстро приводит к деградации производительности всей информационной базы. Выясним основные причины:
Главное архитектурное правило: сырые данные телеметрии никогда не должны храниться в основной рабочей базе 1С. В 1С загружаются только агрегированные показатели, итоговые срезы за смену или результаты точечных аналитических выборок.
Для надежной обработки больших потоков данных разделим систему на три изолированных контура: сбор и буферизация, долгосрочное хранилище (Data Storage) и бизнес-логика в 1С.
OPC UA, MQTT, Modbus TCP).Apache Kafka или RabbitMQ), откуда консьюмер сбрасывает записи в базу данных пакетами (batch-insert по 5 000–50 000 строк).ClickHouse — обеспечивает компрессию данных в 5–10 раз и сверхбыструю обработку аналитических агрегатов по миллиардам строк за миллисекунды;TimescaleDB (на базе PostgreSQL) — автоматически разбивает данные по временным партициям (гипертаблицам) и поддерживает привычный SQL-синтаксис;Партиционированные файлы — специализированная запись в бинарные или текстовые файлы с разделением по суткам/сменам и индексами, если требуется изолированное архивное хранилище.Рассмотрим, как 1С может штатно и производительно обращаться к внешнему массиву информации для решения оперативных и аналитических задач.
Платформа 1С:Предприятие предоставляет штатный объект метаданных ВнешниеИсточникиДанных. Он позволяет через драйвер ODBC подключиться к внешней СУБД (PostgreSQL, ClickHouse, MS SQL) и работать с ее таблицами в языке запросов 1С.
// Пример получения агрегированных данных из внешнего источника за смену
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Датчики.ИдентификаторДатчика КАК Датчик,
| СРЕДНЕЕ(Датчики.Значение) КАК СреднееЗначение,
| МАКСИМУМ(Датчики.Значение) КАК МаксЗначение,
| КОЛИЧЕСТВО(Датчики.Значение) КАК КоличествоИзмерений
|ИЗ
| ВнешнийИсточникДанных.ТелеметрияПроизводства.Таблица.ПоказанияДатчиков КАК Датчики
|ГДЕ
| Датчики.Период МЕЖДУ &ДатаНачала И &ДатаОкончания
|СГРУППИРОВАТЬ ПО
| Датчики.ИдентификаторДатчика";
Запрос.УстановитьПараметр("ДатаНачала", НачалоДня(ТекущаяДата()));
Запрос.УстановитьПараметр("ДатаОкончания", КонецДня(ТекущаяДата()));
РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();
Пока Выборка.Следующий() Цикл
// Обработка сводных показателей и запись в документы/регистры 1С
КонецЦикла;
Если внешнее хранилище (например, ClickHouse) поддерживает нативный HTTP-интерфейс, наиболее легким и независимым решением является выполнение прямых HTTP-запросов из 1С с получением ответа в формате JSON.
// Получение среза данных через HTTPСоединение
HTTPСоединение = Новый HTTPСоединение("clickhouse-server.local", 8123);
ЗапросSQL = "SELECT sensor_id, avg(val) FROM telemetry.sensor_log WHERE event_date = today() GROUP BY sensor_id FORMAT JSON";
HTTPЗапрос = Новый HTTPЗапрос("/?query=" + ЗапросSQL);
Ответ = HTTPСоединение.ОтправитьДляОбработки(HTTPЗапрос);
Если Ответ.КодСостояния = 200 Тогда
ЧтениеJSON = Новый ЧтениеJSON;
ЧтениеJSON.УстановитьСтроку(Ответ.ПолучитьТелоКакСтроку());
Данные = ПрочитатьJSON(ЧтениеJSON);
ЧтениеJSON.Закрыть();
// Дальнейшая обработка полученного массива структур в 1С
КонецЕсли;
Разберем сценарий, когда датчик фиксирует событие (например, сход готовой продукции с конвейера), и требуется без участия оператора быстро сформировать и напечатать документ (паспорт партии, маркировочный ярлык).
Вместо циклического опроса базы данных со стороны 1С реализуем событийно-ориентированный подход (Event-Driven):
HTTPСервис (Webhook).ТабличныйДокумент и отправляется на печать без вывода диалоговых окон.
// Метод обработчика HTTP-сервиса 1С
Функция ВыполнитьАвтопечатьПоСигналу(Запрос)
ТелоСтрокой = Запрос.ПолучитьТелоКакСтроку();
ЧтениеJSON = Новый ЧтениеJSON;
ЧтениеJSON.УстановитьСтроку(ТелоСтрокой);
ПараметрыСобытия = ПрочитатьJSON(ЧтениеJSON);
ЧтениеJSON.Закрыть();
// Формирование макета и прямая печать на принтер
ТабДок = Новый ТабличныйДокумент;
Макет = ПолучитьОбщийМакет("ПаспортИзделия");
ОбластьШапка = Макет.ПолучитьОбласть("Шапка");
ОбластьШапка.Параметры.НомерПартии = ПараметрыСобытия.НомерПартии;
ОбластьШапка.Параметры.ДатаВыпуска = ТекущаяДатаСеанса();
ТабДок.Вывести(ОбластьШапка);
ТабДок.ИмяПринтера = "Zebra_Production_Line_1";
ТабДок.Напечатать(РежимИспользованияДиалогаПечати.НеИспользовать);
Ответ = Новый HTTPСервисОтвет(200);
Ответ.УстановитьТелоИзСтроки("{""status"": ""printed""}");
Возврат Ответ;
КонецФункции
При проектировании систем с объемами в десятки и сотни миллиардов записей ключевым фактором является четкое разделение ответственности компонентов: промышленный агент отвечает за стабильный съем сигналов, специализированная аналитическая СУБД — за компактное хранение и агрегацию временных рядов, а 1С:Предприятие — за бизнес-логику, учет и событийные процессы.