1С как центр управления объектами физического мира
Практический опыт интеграции 1С ERP, Home Assistant, машинного зрения, IoT-оборудования и искусственного интеллекта
Можно ли использовать 1С не только для регистрации уже совершившихся операций, но и как верхний уровень системы, которая наблюдает за физическим объектом, получает телеметрию, анализирует изображение, принимает решение и управляет оборудованием?
Для проверки этой идеи был создан работающий демонстрационный стенд. В качестве объекта выбран аквариум — компактная модель реального технологического процесса, где есть контролируемая среда, камера, датчики, исполнительные устройства, регламентные операции, история состояний и необходимость принимать решения.
Результатом стала не отдельная обработка для вызова ChatGPT, а комплексная система: 1С объединяет данные Home Assistant, изображение с IP-камеры, историю наблюдений, настройки и промпты, обращается к модели с поддержкой машинного зрения, сохраняет результат и при необходимости передает управляющую команду физическому устройству.
Что показано в проекте
В проекте реализован полный цикл «наблюдение → анализ → решение → действие → регистрация результата». Система уже включает не одну демонстрационную кнопку, а набор взаимосвязанных подсистем:
- основное рабочее место оператора в 1С ERP;
- мобильное рабочее место;
- получение актуального снимка с IP-камеры;
- хранение изображения и истории наблюдений;
- получение температуры и состояний устройств;
- учет энергопотребления;
- ручное управление оборудованием;
- автоматический запуск по расписанию;
- несколько сценариев AI-анализа;
- настраиваемые промпты, вынесенные из программного кода;
- мультимодальный запрос: текст, структурированные данные, изображение и файл инструкций;
- журнал обращений к искусственному интеллекту;
- хранение ответов и исходного контекста;
- проверка результата внутренними правилами 1С;
- передача команд через REST API Home Assistant;
- интеграция оборудования разных производителей;
- эмуляция оборудования для разработки и тестирования;
- регистрация выполненных действий;
- отчеты и анализ накопленной истории;
- возможность расширения на другие физические объекты.
Ключевой результат проекта: 1С выступает не заменой контроллера или системы автоматики, а функциональным и управленческим уровнем, который связывает технические сигналы с регламентами, историей, ответственностью пользователей и бизнес-логикой.
Видеодемонстрация. В публикации будут размещены четыре видеофрагмента, показывающие фактическую работу системы: интерфейс 1С, получение изображения, данные Home Assistant, обращение к AI, автоматический режим и управление оборудованием.
Почему возникла эта идея
Системы 1С традиционно находятся в центре учетного контура предприятия. В них уже содержатся нормативно-справочная информация, документы, планы, лимиты, задания, история операций и ответственность пользователей. Одновременно вокруг предприятия существует другой контур — физический: датчики, камеры, счетчики, электроприводы, климатическое оборудование и технологические установки.
Обычно эти контуры существуют раздельно. Оборудование управляется своей автоматикой, данные мониторинга находятся в отдельной системе, а 1С получает лишь итоговые документы. Но современная интеграционная архитектура позволяет связать их значительно теснее.
Ключевая идея проекта: 1С может не только учитывать результат технологического процесса, но и участвовать в самом цикле наблюдения, анализа, принятия решения и управления.
Почему центральным звеном выбрана 1С
Для непосредственного управления датчиками и реле существуют специализированные платформы. Поэтому задача не состояла в том, чтобы заменить средствами 1С контроллер, SCADA-систему или Home Assistant.
Роль 1С в этой архитектуре другая — объединить технические сигналы с бизнес-контекстом. Именно в 1С удобно хранить:
- описание объектов и оборудования;
- допустимые диапазоны параметров;
- регламенты обслуживания;
- планы и фактические операции;
- историю состояний и инцидентов;
- связь технических событий с документами, затратами и ответственными лицами;
- правила, по которым AI должен интерпретировать наблюдаемую ситуацию.
Таким образом, 1С не конкурирует с уровнем технической автоматики, а становится системой более высокого уровня — центром координации, учета и принятия решений.
Эволюция роли 1С: от учета и ERP к координации данных, AI и физических объектов.
Архитектура решения
Архитектура построена по модульному принципу. Каждый компонент решает свою задачу и может быть заменен без пересмотра всей системы.
Общая архитектура демонстрационного стенда.
| Компонент | Назначение |
|---|---|
| 1С ERP | Рабочее место оператора, хранение параметров, истории и правил, запуск сценариев, регистрация решений. |
| Home Assistant | Унификация доступа к устройствам разных производителей и выполнение управляющих команд. |
| IP-камера | Получение изображения контролируемого объекта. |
| OpenAI API / ChatGPT Vision | Совместный анализ изображения, текущих параметров и текстового задания. |
| Исполнительные устройства | Включение и отключение оборудования, выполнение физического действия. |
| Регламентные задания 1С | Автономный запуск цикла без участия оператора. |
Полный цикл работы
- 1С запрашивает в Home Assistant состояния устройств и показания датчиков.
- Система получает актуальный кадр с IP-камеры.
- Из параметров объекта, истории наблюдений, изображения и текста промпта формируется единый запрос.
- Запрос передается модели с поддержкой анализа изображений.
- Ответ AI возвращается в 1С и сохраняется вместе с исходными данными.
- На основании ответа и внутренних правил 1С формирует рекомендацию либо управляющее действие.
- Команда передается через Home Assistant исполнительному устройству.
- Факт действия регистрируется в 1С.
Важно, что AI не обращается к оборудованию напрямую. Управляющая логика и контроль выполнения остаются на стороне корпоративной системы. Это делает архитектуру понятнее, управляемее и безопаснее.
В системе предусмотрены также отдельные журналы, настройки промптов, история наблюдений, параметры объекта, средства тестирования и эмуляции оборудования. В статье показаны только основные экраны, чтобы не превращать публикацию в полную пользовательскую документацию.
Такой интерфейс особенно важен для реальных проектов: специалисту не нужно отдельно открывать систему видеонаблюдения, панель Home Assistant, журнал AI и учетную систему. Технические и бизнес-данные собраны в одном контексте.
Из рабочего места можно получить новый кадр, обновить данные оборудования, запустить один из сценариев анализа, просмотреть заключение модели, выполнить разрешенное действие вручную либо передать управление регламентному заданию.
Главная форма — это не просто демонстрационный экран. Она объединяет основные функции системы и дает оператору целостную картину происходящего. На одном рабочем месте доступны изображение объекта, текущие параметры, история, результаты AI-анализа и команды управления.
Рабочее место оператора: система целиком в одном интерфейсе
Home Assistant как интеграционный слой
Одна из самых содержательных частей проекта — построение интеграционного контура вокруг Home Assistant. Эту часть нельзя сводить к установке «умного дома». Здесь Home Assistant работает как универсальный IoT-шлюз между 1С и физическим оборудованием.
Практическая проблема состоит в том, что устройства разных производителей используют разные протоколы, облачные сервисы, шлюзы, способы авторизации и модели данных. Создавать в 1С отдельный драйвер для каждой розетки, камеры, датчика или климатического устройства было бы дорого и плохо масштабировалось бы.
Home Assistant берет на себя нижний интеграционный уровень: подключает оборудование, приводит его к единой модели сущностей и предоставляет стандартный REST API. Для 1С конкретное устройство превращается в понятный набор состояний и сервисов управления.
Настроенные интеграции образуют единый слой доступа к устройствам и сервисам разных производителей.
Оборудование сгруппировано по физическим зонам, что облегчает сопровождение и масштабирование.
В одной зоне объединены климатическое оборудование, камера, исполнительные механизмы, розетки и шлюзы.
Температура и управление кондиционером доступны как сущности Home Assistant и далее — через единый REST API.
В демонстрационном контуре объединены:
- Яндекс.Станция и связанные с ней сущности, включая получение температуры и управление климатическим устройством;
- Tuya и исполнительный механизм Finger Robot;
- Shelly Plug — состояние нагрузки и накопленное энергопотребление;
- Broadlink как инфракрасный шлюз;
- ONVIF/IP-камера Tiandy и получение изображения;
- шлюзы и дополнительные сущности Home Assistant.
Тем самым проект демонстрирует отдельную инженерную компетенцию: настройку Home Assistant, работу с интеграциями, устройствами, сущностями, сервисами, токенами и REST API, а также построение архитектуры, в которой 1С не зависит от конкретного производителя оборудования.
Практический эффект: при замене датчика, розетки или исполнительного механизма в первую очередь меняется настройка Home Assistant. Предметная логика, сценарии и журналы в 1С могут остаться прежними.
Машинное зрение: изображение как часть бизнес-контекста
Одних числовых датчиков не всегда достаточно. Некоторые состояния проще обнаружить визуально: наличие объекта, изменение внешнего вида, положение механизма, загрязнение, протечку, дым, посторонний предмет или отклонение поведения.
В проекте IP-камера формирует текущий снимок. Снимок передается в 1С, отображается в рабочем месте и далее включается в запрос к модели с поддержкой Vision.
Рабочее место 1С: изображение с камеры, параметры объекта и результат анализа находятся в одном интерфейсе.
Принципиально важно, что изображение анализируется не изолированно. Вместе с ним передается структурированный контекст: температура, режим работы оборудования, допустимые пределы, история операций и задача анализа. Поэтому модель получает не просто фотографию, а описание текущей технологической ситуации.
Как формируется запрос к искусственному интеллекту
Запрос состоит из трех независимых частей:
- Промпт — роль модели, задача, ограничения и формат ожидаемого ответа.
- Структурированные данные — значения параметров, настройки и история.
- Изображение — актуальный кадр контролируемого объекта.
Упрощенно передаваемый контекст можно представить так:
{
"object": "Аквариум",
"limits": {
"temperature_min": 18,
"temperature_max": 23
},
"current_state": {
"temperature": 21,
"equipment": "on",
"energy_kwh": 28.006119
},
"recent_events": [
{"temperature": 22, "feeding": true},
{"temperature": 21, "feeding": false}
],
"task": "Оценить состояние объекта и вернуть рекомендации"
}
Это не точный экспорт внутренней структуры обработки, а сокращенная иллюстрация принципа. В реальной системе состав контекста определяется настройками и задачей анализа.
Промпт-инструкции как настраиваемая бизнес-логика
Один из важных архитектурных выводов проекта: текстовое задание модели не должно быть жестко зашито в программный модуль.
Промпт является частью бизнес-логики. Он может изменяться по мере накопления опыта, появления новых требований, смены модели или предметной области. Поэтому промпты и параметры анализа хранятся как настройки системы.
Это дает несколько преимуществ:
- изменение правил анализа не требует обновлять конфигурацию;
- можно вести несколько сценариев для разных объектов;
- эксперт предметной области может участвовать в настройке логики;
- модель AI остается заменяемым компонентом;
- можно сравнивать разные варианты промптов и сохранять историю изменений.
Код в такой архитектуре отвечает прежде всего за оркестрацию: собрать данные, сформировать запрос, вызвать сервис, проверить ответ, применить правила и зарегистрировать результат. Смысловая часть анализа в значительной мере переносится в настраиваемый контекст.
Полный исходный код сознательно не приводится. Цель статьи — показать работающую архитектуру и ключевые инженерные решения, а не заменить публикацией техническую документацию проекта.
Для разработчика здесь важна не конкретная команда кондиционеру, а общий шаблон: адрес сервиса, Bearer Token, JSON-тело запроса, выполнение HTTP-вызова и анализ ответа. По той же схеме реализуются включение розетки, запуск исполнительного механизма и получение состояний сущностей.
Фрагмент вызова REST API Home Assistant для установки температуры климатического устройства.
Управляющие команды передаются через сервисы Home Assistant. В показанном примере 1С формирует JSON с идентификатором сущности и целевой температурой, затем вызывает сервис климатического устройства методом POST.
В этом проекте промпт — не вспомогательная строка, скрытая внутри модуля, а самостоятельный элемент настройки системы. Он описывает предметную ситуацию, признаки, правила принятия решения и формат результата. Инструкция пишется обычным русским языком и понятна специалисту, который знает предметную область, но не обязан знать язык 1С или устройство API.
Определение необходимости кормления
Модель должна оценить поведение рыб, наличие остатков корма и вернуть строго формализованное решение: кормить или не кормить.
Принятие решения по температуре
Инструкция использует переданные из 1С параметры и историю, задает алгоритм выбора действия и требует вернуть результат только в JSON.
Например, инструкция по кормлению содержит не абстрактное пожелание «посмотри на рыб», а конкретные наблюдаемые признаки и правило разрешения противоречий:
Оцени состояние рыб и дна.
Признаки голода и беспокойства:
— рыбы активно двигаются;
— несколько рыб находятся у поверхности;
— заметна сильная рябь или всплески воды;
— рыбы ориентированы к центру кормления или друг к другу.
Признаки того, что кормить не нужно:
— на дне или в толще воды хорошо видны гранулы корма;
— видны остатки несъеденного корма.
Если заметны остатки корма — считать, что кормить не нужно,
даже если рыбы активны.
Если остатков корма не видно и присутствуют признаки активного
поиска пищи — считать, что рыбы голодны.
Верни только одно значение:
000 — не кормить;
111 — кормить.
Во второй инструкции модель получает уже не только текст, но и файл данных из 1С: допустимый диапазон температуры и последние строки истории. На основании этих данных ей задается алгоритм выбора управляющего воздействия. Результат возвращается в машинно-читаемом формате:
{
"Температура": 0
}
Принципиальный момент: экспертные знания выражаются естественным языком, но результат при необходимости жестко формализуется. Человек описывает бизнес-ситуацию и правила, а система получает однозначное значение или JSON, пригодный для дальнейшей автоматической обработки в 1С.
Веб-сервер как репозиторий инструкций
Для хранения и доставки промптов используется веб-сервер. Перед обращением к OpenAI система получает актуальный текст инструкции по HTTP, добавляет к нему данные объекта и, если это предусмотрено сценарием, изображение с камеры.
Текстовая инструкция на веб-сервере
→
Загрузка инструкции в 1С по HTTP
→
Данные, история и изображение
→
Запрос к OpenAI
→
Формализованный ответ и решение в 1С
Такое решение отделяет инфраструктурный программный код от предметных знаний. Код отвечает за получение данных, выполнение HTTP-запросов, контроль формата ответа и регистрацию результата. Содержание интеллектуального задания хранится отдельно и может изменяться независимо от конфигурации.
- для изменения критериев анализа не требуется обновлять конфигурацию 1С;
- одна программная реализация может использовать разные инструкции для разных объектов и сценариев;
- промпты можно централизованно хранить, версионировать и оперативно заменять;
- в настройке системы может участвовать специалист предметной области;
- при смене модели или уточнении правил изменяется инструкция, а не вся интеграция.
По сути, веб-сервер выполняет роль внешнего репозитория знаний. В традиционной системе поведение определяется главным образом программным кодом. Здесь существенная часть интеллектуального поведения задается текстовыми инструкциями, которые загружаются во время выполнения.
Управление Home Assistant из 1С
На скриншоте видны основные элементы интеграции: структура запроса Responses API, типы input_text, input_image, input_file, указание модели и заголовок авторизации.
Фрагмент формирования мультимодального запроса: текст, изображение, файл инструкций и Bearer-авторизация.
Запрос формируется непосредственно в 1С и содержит несколько типов входных данных. В него включаются текстовая инструкция, актуальное изображение и отдельный файл с правилами анализа. Это позволяет отделить программный механизм от изменяемой методики работы модели.
Мультимодальный запрос к OpenAI
Пользовательский интерфейс скрывает обычную, но достаточно насыщенную интеграционную работу: HTTP-запросы, JSON, авторизацию по токену, передачу двоичных данных, обработку ответов и регистрацию ошибок.
Что находится под капотом
Роль AI и границы его полномочий
В проекте AI используется не как безусловный контроллер, а как интеллектуальный аналитический компонент. Он может:
- оценить изображение;
- сопоставить визуальные признаки с числовыми параметрами;
- обнаружить противоречие или нетипичную ситуацию;
- сформировать объяснение;
- предложить дальнейшее действие.
Но окончательная управляющая команда проходит через правила 1С. Для реального промышленного применения этот принцип необходимо сохранить и развить: критические ограничения, блокировки и аварийные сценарии должны оставаться детерминированными и не зависеть от свободного текстового ответа модели.
Практически это означает разделение решений на три уровня:
| Уровень | Пример | Способ обработки |
|---|---|---|
| Информационный | Комментарий о состоянии объекта | AI формирует заключение для оператора. |
| Рекомендательный | Предложение выполнить операцию | Оператор подтверждает действие. |
| Автоматический | Допустимая операция в безопасном диапазоне | 1С проверяет правила и передает команду устройству. |
Автоматический режим
Интерактивная демонстрация важна, но для технологического процесса более интересен автономный режим. В системе реализован запуск через регламентные задания 1С.
По расписанию выполняется тот же цикл:
получение данных → снимок → формирование контекста → AI-анализ → проверка правил → действие → регистрация результата.
Такой подход позволяет использовать стандартные механизмы платформы: расписания, журнал регистрации, разграничение прав, фоновые задания и хранение истории. При этом технические операции не отрываются от корпоративной информационной системы.
Мобильное рабочее место
Оператор технологического объекта часто находится рядом с оборудованием, а не за стационарным компьютером. Поэтому рабочее место было адаптировано для мобильного клиента 1С.
Один из экранов мобильного рабочего места.
С мобильного устройства можно просматривать параметры и историю, получать изображение, запускать анализ, читать рекомендации и выполнять разрешенные управляющие действия. Это не отдельное приложение с собственной логикой, а другой интерфейс той же информационной системы.
Что в проекте является наиболее важным
Отдельные технические элементы сами по себе не уникальны. REST API, получение изображения, фоновые задания и вызов AI уже применяются во многих решениях. Основная ценность проекта — в объединении этих элементов в законченный управленческий цикл.
Для меня наиболее важными стали следующие выводы:
- 1С может работать не только с документами, но и с текущим состоянием физического объекта.
- Home Assistant позволяет быстро отделить бизнес-логику от зоопарка оборудования.
- Изображение становится еще одним видом первичного факта, который можно связать с данными учета.
- AI полезен не сам по себе, а как часть правильно организованного контекста и управляемого процесса.
- Промпты и правила анализа целесообразно рассматривать как изменяемую бизнес-логику.
- Решение должно поддерживать как интерактивную работу оператора, так и автономный режим.
От демонстрационного стенда к реальным проектам
Аквариум специально выбран как компактный объект, на котором можно без значительных затрат показать полный цикл. Однако архитектура переносится на более серьезные задачи.
Примеры направлений, в которых может использоваться аналогичная архитектура.
Наиболее очевидные области применения:
- сельское хозяйство: теплицы, инкубаторы, рыбоводство, контроль микроклимата и кормления;
- промышленность: мониторинг оборудования, визуальный контроль, сопровождение регламентных операций;
- инженерные системы: котельные, холодильные установки, вентиляция, насосные группы;
- складская инфраструктура: температура, влажность, энергопотребление, контроль состояния зон хранения;
- коммунальное хозяйство: счетчики, диспетчеризация, выявление отклонений и формирование заданий;
- техническое обслуживание: связь показаний и изображений с заявками, ремонтами, затратами и историей объекта.
В реальном проекте бытовые компоненты демонстрационного стенда будут заменены промышленными контроллерами, надежными каналами связи, специализированными датчиками и средствами резервирования. Но логика верхнего уровня сохранится: 1С получает технологические факты, связывает их с бизнес-данными и управляет процессом принятия решений.
Что осталось за рамками публикации
Эта статья не является пошаговым учебником и не содержит полный исходный код обработки. Цель публикации — показать архитектуру, работающий результат и ключевые инженерные решения.
За рамками первой версии остаются:
- полный код обмена с Home Assistant;
- детали формирования мультимодального запроса OpenAI API;
- механизм загрузки и хранения изображений;
- настройка профилей безопасности и фоновых заданий;
- обработка ошибок и повторные попытки;
- формат хранения истории наблюдений;
- проектирование детерминированных защитных правил.
При интересе к теме отдельные технические элементы можно разобрать в последующих публикациях. Но уже сейчас демонстрационный стенд подтверждает главное: описанная схема работает как единая система, а не как набор несвязанных экспериментов.
Заключение
Проект начинался с простого вопроса: может ли 1С выйти за границы традиционного учетного контура и стать центром управления объектами физического мира?
Практическая реализация показала, что это возможно. Платформа 1С может объединить данные оборудования, изображение, искусственный интеллект, действия оператора и автоматические сценарии. При этом она сохраняет свои сильные стороны: структурированный учет, бизнес-логику, права доступа, историю, регламентные задания и связь технических событий с деятельностью предприятия.
Наиболее перспективным мне представляется развитие подобных решений в проектах технологической автоматизации — прежде всего в сельском хозяйстве, промышленности и сопровождении инженерного оборудования. Здесь особенно востребованы специалисты, которые одновременно понимают возможности 1С, интеграционную архитектуру, AI и логику реальных физических процессов.
Об авторе
Горский Михаил Арнольдович — функциональный архитектор 1С с опытом работы более 25 лет, аналитик и разработчик.
Профессиональные интересы: архитектура корпоративных систем, интеграция 1С с внешними платформами и оборудованием, искусственный интеллект, IoT, автоматизация технологических процессов.
Рассматриваю постоянную работу в команде интегратора, развивающего направления 1С + AI, промышленной или сельскохозяйственной автоматизации, мониторинга и сопровождения оборудования.
Ссылки на видео демонстрацию:
Демонстрация работы системы (полная версия, VK)
Демонстрация работы системы (полная версия, RuTube)
Вступайте в нашу телеграмм-группу Инфостарт