Кто за что отвечает

Устройство отвечает за безопасный выход, станция — за координацию, приложение — за намерение пользователя.

worker — отдельный вычислительный помощник · ManualOverride — ручной режим; E0 сохраняет его до явного освобождения, временный lease относится к расширению E1 · snapshot — согласованный снимок состояния

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

Рассмотреть схему

Три уровня исполнения#

На микроконтроллере выполняются опрос датчиков, работа с контактами, ограничение длительности действия, физическая кнопка и заранее согласованный режим потери связи. Сеть может задержаться, но кнопка не должна ждать сетевой mutex. Локальная защита имеет приоритет перед командой сервера.

Станция хранит состав комнаты, роли пользователей, автоматизации и историю решений. Она объединяет наблюдения, выбирает действие и следит за выполнением. Linux предоставляет процессы, память, драйверы и сеть; собственная платформа Koobique отвечает за смысл физической системы, а не заменяет ядро Linux.

Приложение показывает подтверждённые состояния и отправляет намерения. Закрытие приложения не останавливает правило «при присутствии включать свет, когда темно». Потеря push-уведомления не означает потерю управляющей команды: это разные каналы с разными гарантиями.

Возможности вместо жёстких классов#

Устройство описывается набором функциональных каналов. Один узел может иметь temperature, illuminance, button и relay; другой — только occupancy. Для каждого канала нужны тип величины, единица, диапазон, доступные команды, частота или режим обновления, качество данных и версия описания.

Так приложение может построить стандартный элемент управления реле, не зная названия конкретной платы. Но дескриптор не получает права прислать исполняемый JavaScript или произвольный код интерфейса. Специальные экраны появляются в приложении как проверенные расширения, а не как содержимое пакета от неизвестного устройства.

Полезно разделить идентичность узла, физическое размещение и пользовательское имя. Перенос Sense из кабинета в коридор не создаёт новое устройство, но меняет контекст измерений. Переименование «лампа» в «основной свет» не должно ломать правило, которое ссылается на устойчивый идентификатор канала.

Слои состояния системы#

Эти сущности связаны, но не подменяют друг друга. Ток может течь через неисправную нагрузку. Люксометр может видеть дневной свет, хотя реле не включилось. Поэтому результат имеет уровень подтверждения, а интерфейс не обещает больше, чем известно.

Приоритеты и конфликтующие решения#

Предлагаемый порядок для первого кабинета: аппаратная защита → локальная кнопка и аварийное выключение → явное действие пользователя → обычная автоматизация. Это не вечный порядок для любого оборудования: он является политикой конкретного класса устройства. Например, противопожарная функция или защита от замерзания потребуют своей модели, а не изменения одного глобального числа приоритета.

Ручное действие создаёт ManualOverride на исполнительном узле. В E0 режим сохраняется до явного действия «Вернуть автоматику»; обычное правило его не снимает. Временный lease с видимым сроком можно добавить в E1 после отдельного определения часов и поведения при перезапуске. Для будущей опасной нагрузки локальное ограничение максимального времени включения задаётся независимо от ручного режима. Для лампы рабочего стола потеря датчика сама по себе не отменяет явно включённый свет.

Один процесс ядра, несколько изолированных служб#

Предлагается модульный Rust-монолит для реестра, состояний, политик и исполнения. Голосовой вывод, распознавание речи и потенциально нестабильные адаптеры работают отдельными процессами. Они получают ограниченные ресурсы и не владеют выходами напрямую.

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

Когда система растёт#

Следующие десять устройств добавляются через тот же реестр и протокол. Следующая комната добавляет область действия правил. Второй пользователь — отдельную идентичность и права. Второй хаб не должен автоматически становиться равноправным управляющим тем же реле: сначала требуется протокол передачи полномочий, иначе два восстановленных из копии сервера начнут бороться за выход.

Для первых экземпляров выбираем одну активную станцию на инсталляцию. Резервная копия предназначена для восстановления, а не для создания параллельного хозяина. Управляющий epoch и привязка к владельцу позволяют устройству отвергать старый контроллер после переноса.

Проверка архитектуры до корпуса#

На ПК запустить ядро и симулятор Actuator. Отключить клиент: правило продолжает работать. Остановить голосовой worker: ручные команды работают. Оборвать соединение с узлом: результат команды становится неизвестным, а не ложно успешным. Вернуть старый snapshot: он не становится свежим измерением.

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

Три архитектуры и осознанный выбор#

Самый короткий путь — отправлять все показания и команды пользователя в языковую модель, а ответ превращать в вызов устройства. Такой прототип впечатляет гибкостью, но связывает физическое действие с качеством текста, полнотой контекста и временем ответа. Отказ одного большого компонента становится отказом всей автоматизации.

Противоположный путь — конечные автоматы и жёсткие правила. Он хорош там, где ситуация исчерпывается несколькими состояниями. Для первого реле это необходимая основа. Но каждый новый тип помещения и исключение постепенно увеличивают число правил; понимание произвольной речи и адаптация к неизвестной лампе не появляются сами.

Для Koobique предлагается гибридная архитектура: проверяемая основа исполняет ограничения и простые сценарии; специализированные модели оценивают скрытое состояние и прогнозируют последствия; языковой слой помогает пользователю выразить цель. Ни одна модель не получает исключительного права определять, что является истинным и разрешённым.

Рассмотреть схему

Что означает «операционная система»#

Linux остаётся операционной системой вычислителя: загружает драйверы, распределяет память, запускает процессы. Koobique Core / физическая платформа — предлагаемое имя прикладной системной среды над Linux. Она распределяет доступ к физическим объектам, времени измерений, моделям и исполнительным устройствам. Это смысловой аналог ОС для физических процессов, а не заявление о написании собственного планировщика CPU.

В обычной ОС файл имеет имя и права. В Koobique физический объект имеет тип величины, расположение, источники наблюдения, допустимые воздействия и условия доверия. Потребность «освещение рабочего места» связывается не с произвольным реле, а с конкретным светильником и проверенным влиянием на выбранную плоскость измерения.

Пять разных документов о реальности#

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

Контуры с разной скоростью#

На устройстве остаются физическая кнопка, ограничения выхода и реакции на локальный отказ. На станции выполняются межустройственные сценарии, оценка состояния и журнал. Прогнозы и обучение работают медленнее и не блокируют эти задачи. В интерфейсе пользователь видит цель, ограничения и причины; телефон не является обязательным постоянно работающим сервером.

Не все задачи требуют миллисекунд. Контроль освещения чувствителен к заметной задержке; тепловой процесс часто меняется гораздо медленнее. Интервал измерения, срок свежести и вычислительный бюджет задаются для каждого процесса, а не глобальным параметром «самая высокая частота».

Физический процесс объединяет цель, модель и проверяемые условия исполнения. Замена модели сохраняет идентичность устройств, историю измерений и защитные правила.

Компоненты системы и области версионирования#

Сравнивать две голые ревизии недостаточно. Выход «39» из другой загрузки не продолжает прежнюю последовательность «38». Переименование лампы не меняет её физический канал; перенос датчика меняет размещение; смена хаба меняет доверие. В интерфейсе эти детали скрыты за понятными последствиями, но в журнале они сохраняются.