Наблюдение — больше, чем число
Как система отличает свежий факт от поздно доставленной истории?
Физическая платформа начинается с того, что не теряет смысл измерения при передаче, хранении и повторной обработке.
Пусть датчик измерил температуру, потерял Wi-Fi и прислал запись через минуту. Время доставки новое, но сама температура относится к прошлому. Для графика запись полезна; для немедленного решения её может быть недостаточно.
Поэтому у наблюдения есть собственная временная область и происхождение. Перезагрузка датчика начинает новую эпоху его часов. Пропуск, насыщение и недостоверная калибровка передаются явно, а не заменяются нулём или бесконечно повторяемым последним значением.
Число 23,4 без единицы, места и времени почти бесполезно. Оно может означать температуру воздуха, температуру платы, старое значение после reboot или результат активного нагрева датчика. В Koobique наблюдение является полноценной записью с происхождением и качеством, а не парой name/value.
Минимальная схема наблюдения#
| Группа | Поля | Для чего нужны |
|---|---|---|
| Источник | device_id, channel_id, boot_id, sequence | Дедупликация и различение перезапусков |
| Группа | Поля | Для чего нужны |
|---|---|---|
| Величина | quantity, value, unit, range | Предотвращение смешения разных измерений |
| Время | device_monotonic, received_at, интервал измерения | Порядок, возраст и оценка задержки |
| Качество | valid, stale, saturated, sensor_error, transitional | Безопасный выбор входов решения |
| Метод | calibration_id, hardware_rev, firmware_rev | Воспроизводимость и сравнение |
| Контекст | placement_id, room_id, operating_mode | Интерпретация физической точки |
Единицы лучше нормализовать в доменной модели, сохраняя исходное представление для диагностики. Нельзя смешивать °C и абсолютную температуру без явного преобразования, lux и raw ADC, проценты яркости и электрическую мощность. Проверка диапазона не должна молча обрезать невозможное значение до допустимого: иногда это признак неисправности.
Два времени и интервал#
На устройстве измеряются монотонный счётчик и boot_id. На станции — время получения и собственные монотонные часы. Календарное UTC полезно для истории, но не является единственной основой порядка. Если часы датчика неизвестны, это отражается как неопределённость, а не маскируется временем получения.
Для lux время относится к интервалу интегрирования. Для температуры — к моменту получения результата после измерительной операции. Для события кнопки важен фронт, а не момент отправки пакета. Эти различия особенно заметны при синхронизации нескольких сенсоров.
Станция может оценивать смещение часов через обмен timestamp и RTT, но односторонняя задержка остаётся неопределённой при асимметрии. В модели хранится оценка ошибки. Нельзя уверенно упорядочить два физических события, если разница между ними меньше неопределённости времени.
Свежесть зависит от процесса#
Температуре комнаты допустим больший возраст, чем событию кнопки. Для спящего датчика отсутствие heartbeat в течение нескольких секунд может быть нормой. Поэтому TTL данных задаётся по каналу и режиму, а не одним глобальным числом.
Истёкший TTL меняет качество наблюдения. Значение можно продолжать показывать как последнее известное, но с возрастом. В автоматизацию оно попадает только по разрешённой политике. «Нет свежей температуры» не означает 0 °C, а «нет пакетов радара» не означает пустую комнату.
Обработка пропусков и выбросов#
Не все выбросы ошибочны: резкое освещение фонариком — реальное событие. Для диагностики сохраняются raw и причина фильтрации. Обычный график может показывать сглаженный ряд, но алгоритм не должен незаметно терять физические скачки, важные для сценария.
Пропуск не всегда интерполируется. Для визуализации короткого пропуска температуры линейная линия допустима с отметкой; для команды реле интерполяция между OFF и ON бессмысленна. У агрегата хранятся число образцов, минимум, максимум, среднее и доля валидных данных.
Происхождение решения#
Оценка «человек присутствует» ссылается на использованные наблюдения и версию алгоритма. Решение «включить свет» ссылается на оценку, lux, политику и состояние ManualOverride. Это создаёт цепочку объяснения: пользователь видит не просто «автоматизация сработала», а причину.
Пересчёт старой истории новой моделью создаёт новую производную версию, не переписывая исходные наблюдения. Иначе сравнить улучшение алгоритма невозможно. Данные можно экспортировать в открытом формате вместе с описанием единиц и качества; собственный протокол не должен превращать архив в закрытую загадку.
Приватность физического мира#
Присутствие и голос относятся к личной жизни даже без камеры. Предлагается хранить минимально необходимое: события и признаки по умолчанию, сырое аудио — только в явно включённом диагностическом режиме. Удаление пользователя и очистка истории имеют понятные границы.
Администратор хоста технически имеет более широкие возможности, чем пользователь приложения. Если в будущем потребуется защита личных данных от владельца станции, понадобится отдельное шифрование и перераспределение вычислений; обычный ACL внутри Core не решает эту задачу.
Проверка качества данных#
Искусственно передать старый timestamp, повтор sequence, новое boot_id, насыщенное lux и heater-флаг. Проверить, что график, автоматизация и журнал различают эти случаи и не превращают их в одинаковое «валидное число».
Запись измерения сохраняет значение и то, что было известно системе в момент решения. Это позволяет проверить действие по доступным тогда основаниям.
Минимум, который нельзя выбросить ради компактности#
Предлагаем логический объект Observation: идентичность канала, объект наблюдения, величина и единица, значение или явный статус отсутствия, номер последовательности и перезапуска, время/интервал измерения, время получения станцией, качество, ревизия размещения и калибровки. На проводе постоянные поля можно вынести в согласованный дескриптор канала.
Разделение сенсора, наблюдаемого свойства и физического объекта имеет готовый словарь в SOSA/SSN. [101] Мы используем эти идеи для совместимого смысла, но не обязуем микроконтроллер передавать RDF или длинные URI в каждом пакете. Обозначения свойств и действий из WoT Thing Description полезны для внешнего описания устройства; они не заменяют модель его воздействия на среду. [102]
| Группа | Обязательный смысл |
|---|---|
| Кто и что | Устройство, канал, объект, измеряемая величина, профиль схемы |
| Значение | Число/событие, единица, диапазон; пропуск не равен нулю |
| Когда | Часы источника, интервал интеграции, неопределённость времени, получение станцией |
| Качество | Исправность, насыщение, срок свежести, признаки восстановления |
| Происхождение | Перезапуск, последовательность, калибровка, размещение, преобразование |
| Связь с действием | Ссылка на известное событие/команду, но не автоматическое объявление причинности |
Четыре времени вместо одной даты#
Время среды — когда происходило наблюдаемое явление. Часы устройства — чем это время было отмечено. Время получения — когда станция увидела пакет. Время решения — на какой снимок знаний опирался исполнитель. Для датчика с интеграцией явление относится к интервалу, а не точке.
Метки относятся к конкретному boot_id и режиму тактирования. Для кратких сроков Linux используется CLOCK_BOOTTIME, учитывающий suspend; произвольный Rust Instant или CLOCK_MONOTONIC не считается эквивалентом без проверки реализации. После resume/reboot краткоживущие предложения инвалидируются, если их актуальность не доказана. UTC служит истории и календарным правилам, но не оживляет старый outbox. [145]
Расчётный бюджет часов: при начальной границе 10 мс и доказанной для данного режима относительной ошибке 20 ppm за 30 с добавится 0,6 мс. Это только арифметический пример. Он не назначает точность внутреннему RTC RC-генератору C6 и не переносится в light/deep sleep. Рабочий профиль измеряет дрейф, температуру и смену источника; неопределённая граница означает запрет срочного действия, а не нулевую ошибку. [146]
Поздние записи и окончательность#
В потоке выделяем события, пригодные для актуального управления, и историческую досылку. Для оценщика задаём окно допустимого опоздания. Приход новой записи может уточнить прошлую оценку, но не должен тихо сделать вид, что исполнитель знал её раньше.
Храним decision_snapshot_id: идентификатор снимка состояния и версий моделей. Он позволяет воспроизвести логику на доступной тогда информации. Исторический пересчёт создаёт новую оценку со ссылкой на старую, а не стирает основание первоначального действия.
Свежесть зависит от действия#
Температура десятисекундной давности может быть достаточна для графика, но не для особого процесса с быстрым нагревом. Для управления освещением важно и время измерения, и то, менялась ли лампа после него. Поэтому паспорт процесса задаёт условия свежести относительно среды и действий, а не только универсальный TTL.
KQIP связывает значение с согласованным контрактом наблюдения. Метаданные версионируются. Если старое устройство не передаёт сведения, необходимые для конкретного управления, область разрешённой автоматизации сужается.
Разобранный путь одного наблюдения#
Пусть Sense начинает измерение на отметке своих часов 120,000 с и заканчивает на 120,015 с. Запись получает boot_id и номер 1042. Станция принимает её позже. Она сохраняет исходный интервал и отдельно свою оценку того, как он соотносится с локальной шкалой времени. Числа в этом примере иллюстрируют договор, а не паспорт длительности любого режима SHT45.
Для графика допускается поздняя вставка в историю. Для автоматизации вычисляется возраст с учётом временной неопределённости и политики процесса. Если данных недостаточно, решение становится ограниченным или откладывается. Следующий этап — оценка состояния — ссылается на ID этой записи, поэтому причину решения можно восстановить.
Один словарь полей на узле и в журнале#
Нормативные имена E0: channel_id, sample_seq, sample_start_us, sample_end_us, boot_id, status, flags, descriptor_revision, placement_revision. Единственный status — VALID, INVALID или WARMING; независимые flags уточняют heater, saturation, delayed и другие зарегистрированные условия. Флаг не делает INVALID пригодным. Старые имена из учебных файлов преобразуются явным адаптером версии, а не принимаются как скрытые синонимы.
Временная метка получения сервером не подставляется вместо интервала измерения. Для старого буфера после reboot неизвестное соответствие UTC остаётся неизвестным. Порядок внутри boot можно сохранить даже без даты; порядок между разными устройствами и загрузками требует свидетельств. Алгоритм привязки шкал и сроков описан в главе 22.
Что считать свидетельством света после команды#
Машинное условие пригодности: совпадают канал, placement_revision, профиль лампы и калибровка; качество допустимо; нижняя граница начала измерения позже верхней границы момента действия плюс проверенное время установления; внутри интервала не было другого воздействия, меняющего тракт. Если интервал пересекает переключение, отсчёт не подтверждает установившийся эффект.
Даже пригодный рост lux может быть вызван солнцем или другой лампой. EffectEvidence хранит альтернативные объяснения и силу свидетельства. Если датчик тока не установлен, UI пишет «контроль тока не предусмотрен», а не ждёт его вечно. Историческое VERIFIED относится к конкретному эпизоду; состояние комнаты спустя минуту оценивается заново.
Свидетельство эффекта как проверяемая запись#
Для эпизода исполнения сохраняются command_id, сообщённый момент действия с границей ошибки времени, требуемое время установления и используемые наблюдения. Свидетельство также указывает channel_id, ревизии размещения и калибровки, профиль нагрузки и известные вмешательства. Эти поля позволяют проверить, относится ли измерение к данному действию. Если часть сведений неизвестна, запись сохраняет этот предел вместо автоматического VERIFIED.
Причинный вывод сильнее совпадения во времени. Лампа могла включиться одновременно с открытием шторы; тогда рост lux совместим с несколькими объяснениями. Для проверки предполагаемого вклада полезен разрешённый чередующийся опыт OFF/ON с контролем фоновых изменений и остановкой по ручному действию. Полученный коэффициент действует только для испытанных размещения, сенсора и светильника. Электрическую исправность нельзя окончательно вывести из одного оптического наблюдения.