Лучшие практики проверки и отображения состояния внешних устройств — не сводите всё к одному «Подключено»

Промышленные камеры, сканеры штрихкодов, ПЛК, измерительные приборы, принтеры, последовательные устройства, USB-устройства. В Windows-приложениях, которые работают с внешними устройствами, аварии довольно часто случаются не из-за самой неисправности, а потому что отображаемое на экране состояние расходится с реальностью.

Например, такие ситуации.

• ОС устройство видит, но его удерживает другой процесс, и пользоваться им нельзя
• open прошёл успешно, но возврат в исходное положение, прогрев или аутентификация ещё не закончены
• устройство физически на месте, но отвечать уже перестало
• поток получения данных умер, а на экране всё ещё висит последнее значение
• подключён не тот экземпляр или firmware, а на экране просто написано «Подключено»

Здесь нужно узнать не только, подключено ли устройство. Нужно понять, что сейчас можно безопасно сделать.

flowchart TB
    accTitle: Важно не подключение, а допустимые операции
    accDescr: В приложении, работающем с внешними устройствами, важно не только то, подключено ли устройство, но и что сейчас можно безопасно сделать. Аварии часто случаются раньше самой неисправности — из-за того, что отображение состояния расходится с реальностью.
    a1["«Подключено ли?»"] -.-> a2["Это только часть вопроса"]
    a3["«Что сейчас можно сделать безопасно?»"] --> a4["То, что нужно узнать на самом деле"]
    a4 -.-> a5["Если отображение расходится с реальностью, авария случается раньше"]

Рис. 1: Цель отображения состояния — не факт подключения, а то, какие операции сейчас безопасны.

Для кого эта статья и какие предпосылки

Термины, которые встречаются в статье

Слова, которые дальше идут по-английски, сначала сводим в одну строку.

1. Сначала вывод

Самое действенное правило при проверке и отображении состояния внешних устройств — не сводить состояние к одному boolean.

Как минимум эти оси стоит держать отдельно.

• Наличие: видит ли устройство ОС
• Установление сессии: выполнило ли приложение open / login / initialize
• Отзывчивость: отвечает ли устройство на heartbeat или status query
• Готовность к работе: может ли сейчас принять реальную операцию
• Актуальность данных: свежи ли значения на экране
• Соответствие конфигурации: тот ли это экземпляр, модель и firmware
• Исправность мониторинга: жив ли вообще путь наблюдения

Если совсем огрубить, получится так.

Наличие проверяет сторона ОС, возможность использования — сторона приложения, актуальность — сторона экрана.

Достаточно не смешивать эти три составляющие — и отображение состояния становится заметно стабильнее.

flowchart TB
    subgraph OS["Что может ответить ОС"]
        E["Наличие<br/>виден ли целевой interface"]
    end
    subgraph APP["Что может ответить только приложение"]
        S["Сессия<br/>выполнены ли open / login / initialize"]
        R["Отзывчивость<br/>отвечает ли на лёгкий запрос в срок"]
        F["Готовность к работе<br/>можно ли сейчас принять операцию"]
        C["Соответствие конфигурации<br/>тот ли экземпляр, модель, firmware"]
    end
    subgraph UIL["Что отвечает сторона экрана"]
        D["Актуальность данных<br/>свеже ли отображаемое значение"]
        W["Исправность мониторинга<br/>жив ли сам путь наблюдения"]
    end
    E --> S --> R --> F --> D
    C -.->|"если здесь расхождение,<br/>остальное не поможет"| F
    W -.->|"если остановилось,<br/>все оценки устаревают"| D

Рис. 2: Состояние не сводят к одному boolean, а держат как вопросы, на которые отвечает разный слой. Даже если верхний уровень выполнен, нижний из этого не следует.

Карта знаний этой статьи

В Windows-приложении, которое работает с внешним оборудованием, стержень — держать внутри раздельно семь осей состояния: наличие, установление сессии, отзывчивость, готовность функций, свежесть данных, совпадение идентичности и здоровье мониторинга. Если схлопнуть это в единое отображение «подключено», operator не сможет выбрать следующий шаг, поэтому UI показывают тремя слоями — сводка, причина, подробности — и формулировкой «состояние + причина + следующее действие». Свежесть данных судят не по настенным часам, а по монотонно возрастающей метке времени и freshness budget, чтобы избежать ложного суждения из-за рассинхрона часов с ValueTimestamp на стороне устройства. Рабочий поток мониторинга и UI разделяют через state store; подписку привязывают к Control.Disposed, чтобы вызов BeginInvoke во время уничтожения экрана не утягивал за собой рабочий поток мониторинга; повторное подключение делают с backoff, а flapping сглаживают до стабильного отображения.

flowchart LR
    accTitle: Карта знаний: проверка и отображение состояния внешнего оборудования
    accDescr: Схема, которая показывает, как, держа раздельно семь осей состояния — наличие, установление сессии, отзывчивость, готовность функций, свежесть данных, совпадение идентичности и здоровье мониторинга — предотвратить ошибочные решения operator из-за единого отображения «подключено»
    multi_axis_device_state_model["многоосная модель состояния"]
    connected_label_oversimplification["сведение состояний к «подключено»"]
    operator_misjudgment["operator не может выбрать следующий шаг"]
    device_existence_state["наличие (ось состояния)"]
    device_session_state["установленная сессия (ось состояния)"]
    device_responsiveness_state["отзывчивость (ось состояния)"]
    device_readiness_state["готовность (ось состояния)"]
    data_freshness_state["свежесть данных (ось состояния)"]
    device_identity_match["совпадение identity (ось состояния)"]
    monitoring_health_state["здоровье мониторинга (ось состояния)"]
    three_tier_status_panel["трёхслойная панель: сводка, причина, детали"]
    status_message_three_elements["текст: состояние + причина + следующее действие"]
    startup_enumeration["перечисление при запуске"]
    arrival_removal_notification["уведомление arrival/removal"]
    heartbeat_polling["опрос по heartbeat"]
    freshness_budget["freshness budget"]
    monotonic_timestamp["монотонная метка времени"]
    wall_clock_drift["скачок wall-clock"]
    freshness_misjudgment["ошибка оценки свежести"]
    value_timestamp_clock_skew["расхождение часов с ValueTimestamp устройства"]
    stale_data_live_masking["показ stale data как актуальных значений"]
    device_key_instability["нестабильность идентификации экземпляра"]
    device_misidentification["перепутывание экземпляров устройств"]
    reconnect_backoff["переподключение с backoff"]
    reconnect_storm["шторм переподключений"]
    flapping_debounce["сглаживание flapping"]
    monitoring_worker_ui_separation["разделение worker мониторинга и UI"]
    ui_monitoring_coupling["мониторинг прямо на UI-потоке"]
    ui_disposal_race["гонка из-за BeginInvoke при уничтожении окна"]
    monitoring_worker_crash["остановка worker мониторинга (попутный сбой)"]
    control_lifetime_bound_subscription["снятие подписки по Control.Disposed"]
    stable_device_key["стабильный ключ идентификации устройства"]
    connected_label_oversimplification -->|"может вызвать"| operator_misjudgment
    multi_axis_device_state_model -->|"требует"| device_existence_state
    multi_axis_device_state_model -->|"требует"| device_session_state
    multi_axis_device_state_model -->|"требует"| device_responsiveness_state
    multi_axis_device_state_model -->|"требует"| device_readiness_state
    multi_axis_device_state_model -->|"требует"| data_freshness_state
    multi_axis_device_state_model -->|"требует"| device_identity_match
    multi_axis_device_state_model -->|"требует"| monitoring_health_state
    multi_axis_device_state_model -->|"предотвращает"| connected_label_oversimplification
    three_tier_status_panel -->|"снижает"| operator_misjudgment
    status_message_three_elements -->|"снижает"| operator_misjudgment
    startup_enumeration -->|"должен предшествовать"| arrival_removal_notification
    device_existence_state -->|"проверяется"| arrival_removal_notification
    device_responsiveness_state -->|"проверяется"| heartbeat_polling
    data_freshness_state -->|"проверяется"| freshness_budget
    freshness_budget -->|"требует"| monotonic_timestamp
    wall_clock_drift -->|"может вызвать"| freshness_misjudgment
    value_timestamp_clock_skew -->|"может вызвать"| freshness_misjudgment
    monotonic_timestamp -->|"предотвращает"| freshness_misjudgment
    stale_data_live_masking -->|"может вызвать"| operator_misjudgment
    device_key_instability -->|"может вызвать"| device_misidentification
    reconnect_backoff -->|"предотвращает"| reconnect_storm
    reconnect_storm -.->|"может вызвать"| operator_misjudgment
    flapping_debounce -.->|"снижает"| operator_misjudgment
    monitoring_worker_ui_separation -->|"предотвращает"| ui_monitoring_coupling
    ui_disposal_race -->|"может вызвать"| monitoring_worker_crash
    control_lifetime_bound_subscription -->|"снижает"| monitoring_worker_crash
    device_identity_match -->|"требует"| stable_device_key
    stable_device_key -->|"предотвращает"| device_misidentification
    monitoring_health_state -->|"проверяется"| monitoring_worker_ui_separation
    monitoring_worker_ui_separation -->|"требует"| control_lifetime_bound_subscription

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 31, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Почему «Подключено» опасно

Формулировка «Подключено» сама берёт на себя сразу несколько смыслов в одном слове.

На деле в ней смешаны как минимум такие вопросы.

1. Видит ли ОС interface целевого устройства
2. Смогло ли приложение выполнить для этого устройства open / login / initialize
3. Отвечает ли устройство на лёгкий запрос в пределах срока
4. Можно ли сейчас безопасно выполнить запрошенную операцию
5. Свежи ли значения на экране
6. Тот ли это экземпляр, модель и firmware

Смысл слова «доступно» меняется в зависимости от того, какие из этих шести условий выполнены.

Например, следующие четыре ситуации совершенно разные.

• Не подключено ОС вообще не нашла целевой interface
• Подключено / проверяется Физически видно, но инициализация или аутентификация ещё не закончены
• Подключено / недоступно Устройство отвечает, но не может работать из-за warming up, busy, interlock, отсутствия носителя и т. п.
• Значение устарело Раньше данные получались, но значение на экране уже вышло за freshness budget

Если всё это свести к «Подключено», оператор не поймёт, что делать дальше.

flowchart TB
    accTitle: Какие вопросы берёт на себя «Подключено»
    accDescr: Одно слово «Подключено» само берёт на себя несколько разных вопросов: видит ли устройство ОС, отвечает ли оно, можно ли выполнить операцию, свежо ли значение, тот ли это экземпляр. Если всё свести к одному слову, оператор не сможет решить, что делать дальше.
    b1["Видит ли ОС"] --> b4["Всё схлопывается в «Подключено»"]
    b2["Есть ли ответ и можно ли работать"] --> b4
    b3["Свежо ли значение и тот ли экземпляр"] --> b4
    b4 --> b5["Оператор не может решить следующий шаг"]

Рис. 3: Одно слово «Подключено» само берёт на себя несколько вопросов с разными ответами.

3. Какие состояния стоит разделить в первую очередь

Рекомендация такая: внутреннее состояние держать по нескольким осям, а в UI сводить по мере необходимости.

3.1 Оси, которые стоит держать отдельно внутри

Здесь важно разделять состояние, в котором плохо самому устройству, и состояние, в котором приложение его просто не наблюдает.

3.2 UI не обязан показывать всё в одной плоскости

Кажется, что много осей внутри перегрузят экран. Но UI не обязан показывать всё с одинаковым весом.

Рекомендуем три слоя.

• Сверху — сводное состояние
• Под ним — причина
• При необходимости — панель деталей

Например:

• Сводка: Подключено / недоступно
• Причина: Идёт прогрев Осталось около 18 с
• Детали: model serial firmware last heartbeat last frame time

При таком разделении объём информации можно увеличить, не теряя читаемости.

Каркас экрана выглядит примерно так.

+-- Камера предыдущего этапа --------------------------------+
|
| [Сводка]  ! Подключено / недоступно
| [Причина]    Идёт прогрев - осталось около 18 с
|
| [Детали]  v Развернуть                    (по умолчанию свёрнуто)
|           model           ACME-CAM-2000
|           serial          A1B2C3
|           firmware        2.4.1
|           last heartbeat  10:23:41.512   (0.5 с назад)
|           last frame      10:23:41.402   (0.6 с назад)
|
+-----------------------------------------------------------+

Главное: чем ниже слой, тем меньше людей его читает — и это нормально. Сводку читает любой человек за одну секунду, причину — тот, кому нужно понять, почему всё стоит, детали открывает только тот, кто локализует проблему. Если исходить из этого, детали можно делать подробными, и экран не станет шумным.

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

flowchart TB
    accTitle: Три слоя: сводка, причина, детали
    accDescr: UI делят на три слоя: сверху сводное состояние, под ним причина, при необходимости панель деталей. Чем ниже слой, тем меньше людей его читает — и при такой предпосылке объём информации можно увеличить, не теряя читаемости.
    c1["Сводка: любой читает за секунду"] --> c2["Причина: кому нужно понять, почему стоит"]
    c2 --> c3["Детали: открывает только тот, кто локализует проблему"]
    c3 -.-> c4["Даже подробные детали не делают экран шумным"]

Рис. 4: Три слоя строят из предпосылки, что чем ниже слой, тем меньше читателей.

4. Лучшие практики проверки состояния

4.1 Перечисление при запуске и уведомления arrival / removal

Основа работы с внешними устройствами в Windows — при запуске перечислить уже существующие устройства, а дальше принимать уведомления arrival / removal.

Особенно важны три момента.

• Одних уведомлений недостаточно, чтобы найти уже существующие устройства
• Для связи во время выполнения естественнее interface class, а не setup class
• Уведомление remove и I/O error иногда приходят в разном порядке

Практическое правило простое.

1. Перечислить при запуске
2. Подписаться на уведомления
3. Получив уведомление, снова перечислить и сделать reconcile внутреннего состояния

flowchart TB
    accTitle: Практическое правило перечисления и уведомлений
    accDescr: Одних уведомлений недостаточно, чтобы найти уже существующие устройства, поэтому при запуске перечисляют, затем подписываются на уведомления arrival и removal, а при уведомлении снова перечисляют и делают reconcile внутреннего состояния.
    d1["1. Перечислить при запуске"] --> d2["2. Подписаться на уведомления"]
    d2 --> d3["3. При уведомлении снова перечислить и сделать reconcile"]
    d1 -.-> d4["Одних уведомлений недостаточно для уже существующих устройств"]

Рис. 5: Наличие держат тройкой: перечисление, уведомления и reconcile.

4.2 Разделяем «существует», «открывается», «отвечает» и «доступно»

Аварии с внешними устройствами учащаются, когда эти понятия смешивают.

• Существует ОС видит interface
• Открывается Можно получить handle / session без конфликта с другим процессом и без проблем с правами
• Отвечает Отвечает на лёгкий запрос в пределах timeout
• Доступно Может принять реальную операцию

Это четыре разных состояния.

flowchart TB
    accTitle: Наличие, открытие, ответ и доступность — это разное
    accDescr: Четыре разных этапа: наличие (ОС видит interface), открытие (можно получить сессию без конфликта и проблем с правами), ответ (лёгкий запрос возвращается в пределах timeout) и доступность (устройство принимает реальную операцию).
    e1["Существует"] --> e2["Открывается"]
    e2 --> e3["Отвечает"]
    e3 --> e4["Доступно"]
    e1 -.-> e5["Это четыре разных состояния"]

Рис. 6: От «существует» до «доступно» — четыре этапа проверки.

4.3 Сочетаем event и poll

На практике удобнее не опираться целиком только на события или только на опрос, а разделить: обнаружение — через event, проверку исправности — через poll.

• arrival / removal — event
• heartbeat / status query — poll
• оценка freshness — timestamp / sequence

Так проще отделить обнаружение подключения от фактической готовности к использованию.

flowchart TB
    accTitle: Обнаружение — event, исправность — poll
    accDescr: Не стоит выбирать что-то одно целиком. Удобнее разделение: обнаружение arrival и removal принимают событиями, проверку исправности через heartbeat и status query — периодическим опросом, актуальность — по timestamp или sequence.
    f1["Обнаружение arrival / removal"] --> f2["event"]
    f3["heartbeat / status query"] --> f4["poll"]
    f5["Оценка актуальности"] --> f6["timestamp / sequence"]

Рис. 7: event и poll не конкурируют: их выбирают по цели.

4.4 Отделяем мониторинг от UI

Если выполнять open / read / status query прямо в UI thread, интересы отображения и мониторинга быстро смешиваются.

Рекомендуем такую схему:

• воркер мониторинга обновляет state store
• UI подписывается на state store и рисует
• действия пользователя уходят в слой мониторинга как command

Так проще отдельно обрабатывать остановку мониторинга и остановку устройства.

flowchart TB
    accTitle: Мониторинг и UI разделяют через state store
    accDescr: Воркер мониторинга обновляет state store, UI подписывается и рисует, действия пользователя передаются в слой мониторинга как command. Такая односторонняя схема упрощает раздельный разбор остановки мониторинга и остановки устройства.
    g1["Воркер мониторинга"] -->|"обновляет"| g2["state store"]
    g2 -->|"подписка и отрисовка"| g3["UI"]
    g3 -.->|"действия уходят как command"| g1
    g2 -.-> g4["Пишет только воркер: односторонний поток"]

Рис. 8: Мониторинг и UI разделяют через state store и делают поток односторонним.

Каркас на C# занимает примерно столько (рассчитано на .NET 8 / C# 12). Приём простой: пишет только воркер мониторинга, UI только читает и рисует — односторонний поток.

using System;
using System.Collections.Concurrent;
using System.Collections.Generic;
using System.Linq;

public enum DeviceAvailability
{
    Unknown,        // ещё ни разу не наблюдали
    Absent,         // ОС не видит interface
    Initializing,   // идёт open / login / initialize
    Ready,          // можно принять операцию
    Unavailable,    // ответ есть, но busy / warming up и т. п.
    NotResponding,  // heartbeat не возвращается
    Mismatched,     // неожиданный экземпляр / firmware
}

// Неизменяемый снимок для UI. record — чтобы сравнивать по значению
public sealed record DeviceSnapshot(
    string DeviceKey,                 // устойчивый ключ вроде serial number
    string DisplayName,
    DeviceAvailability Availability,
    string Reason,                    // причина вроде «идёт прогрев»
    DateTimeOffset? LastSuccessAt,    // время последней успешной наблюдения
    long Sequence,                    // порядковый номер со стороны устройства
    string FirmwareVersion);

public sealed class DeviceStateStore
{
    private readonly ConcurrentDictionary<string, DeviceSnapshot> _snapshots = new();

    public event Action<DeviceSnapshot>? Changed;

    // Вызывает только воркер мониторинга
    public void Publish(DeviceSnapshot snapshot)
    {
        _snapshots.TryGetValue(snapshot.DeviceKey, out var previous);
        _snapshots[snapshot.DeviceKey] = snapshot;

        // Уведомляем только при изменении. Если слать на каждый poll, UI будет перерисовываться зря
        if (previous != snapshot)
        {
            Changed?.Invoke(snapshot);
        }
    }

    public IReadOnlyList<DeviceSnapshot> Current() => _snapshots.Values.ToList();
}

На стороне UI подписку и возврат в UI-поток держат в одном месте.

using System;
using System.Windows.Forms;

public sealed class DeviceStatusPresenter
{
    private readonly DeviceStateStore _store;
    private readonly Control _uiContext;   // опора, чтобы вернуться в UI-поток
    private readonly Label _summary;
    private readonly Label _reason;

    public DeviceStatusPresenter(DeviceStateStore store, Control uiContext, Label summary, Label reason)
    {
        _store = store;
        _uiContext = uiContext;
        _summary = summary;
        _reason = reason;
        // Привязываем подписку к сроку жизни экрана. Если забыть вызвать Dispose,
        // обновления продолжат уходить в уже закрытую форму
        _uiContext.Disposed += (_, _) => Dispose();
        _store.Changed += OnChanged;      // если забыть подписку, экран не обновится
    }

    public void Dispose() => _store.Changed -= OnChanged;

    private void OnChanged(DeviceSnapshot snapshot)
    {
        // Воркер мониторинга продолжает работать и в момент закрытия экрана.
        // BeginInvoke после уничтожения handle бросает исключение, и оно
        // через Changed?.Invoke уходит на сторону воркера.
        // Получается поломка вида «закрыли экран — остановился мониторинг»
        if (_uiContext.IsDisposed || _uiContext.Disposing || !_uiContext.IsHandleCreated)
        {
            return;
        }

        try
        {
            if (_uiContext.InvokeRequired)
            {
                _uiContext.BeginInvoke(() => Render(snapshot));
                return;
            }

            Render(snapshot);
        }
        catch (ObjectDisposedException)
        {
            // Экран закрыли уже после проверки выше. Этот зазор принципиально не убрать,
            // поэтому принимаем его, отказавшись только от отрисовки. Мониторинг не останавливаем
        }
        catch (InvalidOperationException)
        {
            // Handle ещё не создан или уже уничтожен. То же самое
        }
    }

    private void Render(DeviceSnapshot snapshot)
    {
        _summary.Text = snapshot.Availability switch
        {
            DeviceAvailability.Absent => "Не подключено",
            DeviceAvailability.Initializing => "Подключено / проверяется",
            DeviceAvailability.Ready => "Доступно",
            DeviceAvailability.Unavailable => "Подключено / недоступно",
            DeviceAvailability.NotResponding => "Нет ответа",
            DeviceAvailability.Mismatched => "Неожиданное устройство",
            _ => "Проверяется",
        };
        _reason.Text = snapshot.Reason;
    }
}

Момент закрытия экрана — самое хрупкое место этой схемы. Changed?.Invoke(snapshot) вызывает обработчик синхронно из потока воркера мониторинга. Если вызвать BeginInvoke после того, как форму закрыли и handle элемента уничтожили, будет исключение, и это исключение через Publish уйдёт в воркер мониторинга. Уборка экрана роняет сам мониторинг. Симптом при этом — «при выходе иногда падает», поэтому условие воспроизведения трудно поймать.

Снять подписку в Dispose недостаточно. Если воркер уже начал Invoke в момент снятия, этот вызов уже не остановить. Есть три точки контроля.

• Привязать подписку к сроку жизни экрана. Снимать её автоматически в Control.Disposed, чтобы забытый Dispose не превращался в «продолжать слать в закрытую форму»
• Не слать в уничтожаемый или уже уничтоженный элемент. Смотреть IsDisposed / Disposing / IsHandleCreated и на месте отбрасывать
• Оставшийся зазор принимать исключением. Между проверкой и BeginInvoke закрытие принципиально возможно. Здесь перехватывают ObjectDisposedException и InvalidOperationException и отказываются только от отрисовки. Если не перехватить, мониторинг уйдёт вместе с экраном

Ключевое решение: «отрисовку в момент закрытия можно выбросить». У этого одного кадра нет ценности, а у живого воркера мониторинга — есть.

flowchart TB
    accTitle: Как закрытие экрана утягивает мониторинг
    accDescr: Changed вызывает обработчик синхронно из потока мониторинга, поэтому исключение BeginInvoke после уничтожения handle уходит через Publish в воркер и роняет мониторинг. Подписку привязывают к сроку жизни экрана, а оставшийся зазор принимают, отказавшись только от отрисовки.
    h1["Закрывают экран"] --> h2["BeginInvoke после уничтожения бросает исключение"]
    h2 --> h3["Исключение уходит в воркер мониторинга"]
    h3 --> h4["«Закрыли экран — остановился мониторинг»"]
    h4 -.->|"как не допустить"| h5["Привязать подписку к сроку жизни экрана"]
    h5 --> h6["Оставшийся зазор принять и отказаться только от отрисовки"]

Рис. 9: Один кадр в момент закрытия выбрасывают, чтобы сохранить воркер мониторинга.

4.5 Freshness оценивают отдельно: «доходит ли» и «движется ли содержимое»

Оценки актуальности данных недостаточно, если смотреть только время приёма. Бывает поломка, при которой callback от SDK продолжает приходить, а timestamp или sequence значения уже стоит.

Поэтому разделяют свежесть приёма и свежесть содержимого.

using System;

public sealed record Reading(
    long Sequence,                  // порядковый номер со стороны устройства
    DateTimeOffset ValueTimestamp,  // время, которое устройство поставило на значение
    DateTimeOffset ReceivedAt,      // время приёма в приложении. Для экрана
    long ReceivedTicks);            // монотонная метка того же приёма. Для оценки

public enum Freshness
{
    Fresh,
    Stale,
    Unknown,
}

public static class FreshnessPolicy
{
    // freshness budget: если вышли за него, не показываем как live
    public static readonly TimeSpan Budget = TimeSpan.FromSeconds(5);

    /// <param name="lastAdvancedTicks">монотонная метка времени, когда последний раз продвинулся порядковый номер</param>
    /// <param name="nowTicks">монотонная метка времени на момент оценки</param>
    public static Freshness Evaluate(
        Reading? previous, Reading? current,
        long lastAdvancedTicks, long nowTicks, TimeProvider clock)
    {
        if (current is null)
        {
            return Freshness.Unknown;   // ещё ни разу не получили
        }

        if (clock.GetElapsedTime(current.ReceivedTicks, nowTicks) > Budget)
        {
            return Freshness.Stale;     // само значение уже не доходит
        }

        if (previous is null)
        {
            return Freshness.Fresh;     // в первый раз сравнивать не с чем, судим только по времени приёма
        }

        if (current.Sequence < previous.Sequence)
        {
            // Порядковый номер откатился. Подозреваем перезапуск устройства, замену экземпляра, повторную инициализацию SDK
            return Freshness.Unknown;
        }

        if (current.Sequence == previous.Sequence &&
            clock.GetElapsedTime(lastAdvancedTicks, nowTicks) > Budget)
        {
            // Приём идёт, содержимое не обновляется
            return Freshness.Stale;
        }

        return Freshness.Fresh;
    }
}

lastAdvancedTicks держат по своим часам, например так.

public sealed class FreshnessTracker(TimeProvider clock)
{
    private readonly object _gate = new();
    private Reading? _previous;
    private long _lastAdvancedTicks;

    // Вызывать на каждый приём. ReceivedAt и ReceivedTicks — запись одного и того же приёма
    public Reading Capture(long sequence, DateTimeOffset valueTimestamp) =>
        new(sequence, valueTimestamp, clock.GetLocalNow(), clock.GetTimestamp());

    public Freshness Observe(Reading current)
    {
        lock (_gate)
        {
            if (_previous is null || current.Sequence > _previous.Sequence)
            {
                _lastAdvancedTicks = current.ReceivedTicks;
            }

            var result = FreshnessPolicy.Evaluate(
                _previous, current, _lastAdvancedTicks, clock.GetTimestamp(), clock);
            _previous = current;
            return result;
        }
    }

    // Если приём полностью прекратился, Observe больше не вызовут.
    // Периодически вызывайте это из таймера и заново измеряйте «возраст» последнего значения.
    // Состояние не обновляется, поэтому вызывать можно сколько угодно раз
    public Freshness Reevaluate()
    {
        lock (_gate)
        {
            return FreshnessPolicy.Evaluate(
                _previous, _previous, _lastAdvancedTicks, clock.GetTimestamp(), clock);
        }
    }
}

Одним Observe молчание устройства не обнаружить. Observe вызывают только при приёме, и переданный тогда Reading только что создан. Разница между ReceivedTicks и текущим временем почти ноль, поэтому по этому пути Stale получается только в случае «приём идёт, порядковый номер не двигается». Когда callback от SDK полностью остановился — а это как раз самая важная поломка — Observe не вызывают, и экран замирает на последнем посчитанном Fresh.

Поэтому нужен вход, который переоценивает по циклу, независимому от приёма. Это и есть Reevaluate выше, его вызывают из таймера. Период делают короче budget (если budget 5 секунд, то примерно раз в секунду). Если взять ту же длительность, в худшем случае можно не заметить почти вдвое дольше budget.

flowchart TB
    accTitle: Одним Observe молчание не увидеть
    accDescr: Observe вызывают только при приёме, поэтому если callback от SDK полностью остановился, Observe больше не вызывают, и экран замирает на последнем Fresh. Поэтому из таймера вызывают Reevaluate по циклу, независимому от приёма, и заново измеряют возраст последнего значения.
    i1["callback полностью останавливается"] --> i2["Observe перестают вызывать"]
    i2 --> i3["Экран замирает на последнем Fresh"]
    i3 -.->|"мера"| i4["Вызывать Reevaluate из таймера"]
    i4 --> i5["Период короче budget"]

Рис. 10: Самое важное «полное молчание» оценка, завязанная на приём, не видит.

// System.Threading.Timer. Оценка идёт, даже если приёма нет.
// RenderFreshness — свой метод, который доводит результат до экрана тем же путём, что presenter в 4.4
_freshnessTimer = new Timer(
    _ => RenderFreshness(_tracker.Reevaluate()),
    null, TimeSpan.Zero, TimeSpan.FromSeconds(1));

Observe и Reevaluate могут прийти одновременно из разных потоков, поэтому внутренности FreshnessTracker защищают lock. Если это опустить, подмена и чтение _previous смешаются, и получится трудноуловимый дефект: иногда выходит оценка на одно поколение старше.

Здесь важно не брать разницу с ValueTimestamp. ValueTimestamp ставит часы устройства, и нет гарантии, что они совпадают с нашими. Если вычитать одно из другого, достаточно отстающих часов устройства, чтобы только что пришедшее значение стало stale, и наоборот — при спешащих часах остановившееся значение навсегда останется fresh. Budget нужно всегда накладывать на прошедшее время, измеренное своими часами. ValueTimestamp оставляют для экрана («какое время устройство считает временем значения») и как материал, чтобы вместе с порядковым номером заподозрить остановку на стороне устройства.

И эти «свои часы» тоже нельзя сводить к вычитанию DateTimeOffset. Это настенные часы (wall clock): они прыгают при синхронизации NTP, ручной установке и переходе на летнее время. Если время откатилось, прошедшее время становится отрицательным, и устройство уже отключено, а состояние остаётся Fresh. Если время ушло вперёд, только что пришедшее значение в тот же миг становится Stale. Чем дольше экран работает без перезапуска — например, сутки, — тем чаще на это наступают.

Поэтому для оценки budget используют монотонно возрастающую метку времени. TimeProvider.GetTimestamp() возвращает высокоточное значение на базе Stopwatch, а GetElapsedTime(начало, конец) даёт прошедшее время между двумя точками (см. источники в главе 10; начиная с .NET 8). Настенные часы ReceivedAt оставляют только чтобы показать на экране «принято в 10:15:03» и не подпускают к оценке «сколько секунд прошло». Ещё одно достоинство TimeProvider — его можно подменить тестовыми часами.

flowchart TB
    accTitle: Актуальность оценивают монотонными часами
    accDescr: Настенные часы прыгают при NTP и ручной установке, поэтому вычитание по ним даёт Fresh при уже отключённом устройстве или Stale сразу после приёма. Budget оценивают монотонной меткой времени, а время приёма по настенным часам оставляют только для отображения.
    j1["Настенные часы прыгают из-за NTP и ручной установки"] --> j2["Прошедшее время становится отрицательным или завышенным"]
    j2 --> j3["Оценка актуальности ошибается"]
    j3 -.->|"поэтому"| j4["Оценивают монотонной меткой времени"]
    j4 --> j5["Время приёма по настенным часам оставляют только для экрана"]

Рис. 11: Основа оценки актуальности — не измерять «сколько секунд прошло» настенными часами.

В таком виде UI, получив Freshness.Stale, может сразу применить подход из 5.3: «показать age рядом со значением» и «исключить из решения о готовности к операции».

Unknown держат отдельно от Stale, чтобы не смешивать ещё неизвестно и устарело. Первое, возможно, рассосётся, если подождать. Второе ожиданием не лечится.

4.6 Делаем идентификацию экземпляра устойчивой

Если вести состояние только по внешним идентификаторам вроде friendly name или COM3, экземпляры легко перепутать.

Надёжнее держать внутри ключи, которые не плавают, например:

• serial number
• logical device id
• stable device path
• собственный ID экземпляра со стороны устройства

5. Лучшие практики отображения

5.1 Сводная таблица решений

5.2 Формулировка: «состояние + причина + следующее действие»

Одних слов Ошибка или Сбой для экрана мало. Сообщение лучше собирать из трёх элементов — тогда оператору проще не растеряться.

• Состояние: что происходит
• Причина: почему сделан такой вывод
• Следующее действие: что нужно сделать

Например:

• Подключено / недоступно - идёт прогрев - подождите примерно 18 с
• Нет ответа - heartbeat timeout - проверьте кабель и питание
• Неожиданное устройство - нужен Firmware 2.1.0 - проверьте целевое устройство

Если сравнить с формулировками, которые часто видят на площадке, сразу видно, чего не хватает.

Общее у примеров переписывания одно: может ли оператор по одному этому экрану решить следующий шаг. Если получается написать только «обратитесь в поддержку», дело не в формулировке — не хватает проектирования состояний.

flowchart TB
    accTitle: Формулировка: состояние + причина + следующее действие
    accDescr: Одних «ошибка» и «сбой» мало. Если собрать три элемента — что происходит, почему так решили и что делать дальше — оператор может решить следующий шаг по одному экрану.
    k1["Состояние: что происходит"] --> k4["Формулировка, в которой оператор не теряется"]
    k2["Причина: почему так решили"] --> k4
    k3["Следующее действие: что сделать"] --> k4
    k4 -.-> k5["Можно ли решить следующий шаг по одному экрану"]

Рис. 12: Качество сообщения оценивают по тому, собраны ли три элемента.

5.3 Не скрывайте устаревшие данные

Последнее известное значение (last known value) полезно. Но безопаснее не выдавать его за живое (live) значение.

Рекомендуем:

• timestamp рядом со значением
• отображение возраста значения (age)
• менять цвет или метку, когда значение становится stale
• исключать из решения о готовности к операции после заданного времени

5.4 Меняем место отображения в зависимости от важности

Строка состояния (status bar) удобна, но её легко не заметить. Критичный сбой не стоит оставлять только в уголке status bar.

• Незначительные изменения состояния: status bar
• Предупреждения, при которых работу ещё можно продолжать: inline notice
• Сбои, из-за которых нужно остановить операции: основная область, диалог, баннер

Такое разделение выглядит естественно.

5.5 На экране нескольких устройств разделяйте сводку и детали

Если постоянно показывать полные детали по всем устройствам, экран становится нечитаемым.

• Сверху — общая сводка
• Ниже — строка по каждому устройству
• При выборе — панель деталей

Три уровня помогают одновременно видеть общую картину и разбирать отдельные случаи.

Каркас экрана выглядит так.

+-- Список устройств ----------------------------------------+
|
| [Общая сводка]  Доступно 6 / 8      Внимание 1      Сбой 1
|
| [Строки устройств]
|     Состояние   Отображаемое имя    Причина             Обновлено
|     --------    ---------------     ----------------    --------
|     Доступно    Камера пред. этапа  -                   0.5 с назад
|     Доступно    Принтер этикеток    -                   1.2 с назад
|   > Недоступно  Инспекционная кам.  Идёт прогрев        0.6 с назад   <- выбрано
|     Нет ответа  Сканер штрихкодов   heartbeat timeout   48 с назад
|
| [Панель деталей]  Инспекционная камера
|     serial A1B2C3 / firmware 2.4.1 / осталось около 18 с
|     [ Переподключить ]   [ Открыть журнал ]
|
+------------------------------------------------------------+

Такая трёхуровневая схема на одном экране закрывает сразу три роли: кто смотрит только общую сводку (можно ли сегодня гонять линию), кто смотрит строки (какое устройство стоит) и кто смотрит панель деталей (что сделать, чтобы починить).

Строки удобнее поднимать сбои наверх. Но если порядок меняется каждую секунду, легко нажать не туда, поэтому сортируют уже по зафиксированному состоянию после сглаживания флаппинга (см. 6.2).

flowchart TB
    accTitle: Три уровня закрывают три роли читателя
    accDescr: Экран нескольких устройств делят на три уровня: сверху общая сводка, ниже строки устройств, при выборе панель деталей. Так один экран закрывает тех, кто смотрит, можно ли гонять линию, какое устройство стоит и что сделать, чтобы починить.
    m1["Общая сводка"] -.-> m2["Можно ли сегодня гонять линию"]
    m1 --> m3["Строки устройств"]
    m3 -.-> m4["Какое устройство стоит"]
    m3 --> m5["Панель деталей"]
    m5 -.-> m6["Что сделать, чтобы починить"]

Рис. 13: Экран нескольких устройств собирают из трёх уровней под разных читателей.

6. Лучшие практики переподключения и эксплуатации

6.1 Переподключение делают с backoff

Когда устройство перестало отвечать, безопаснее не долбить переподключением в самом коротком цикле.

• Это нагружает device / driver / SDK
• Заливает логи
• Усиливает кратковременную нестабильность
• Сильно дёргает UI

Реалистичный подход:

• сразу повторить попытку в первый раз
• при неудаче постепенно увеличивать интервал
• задать верхний предел
• дать и ручную кнопку Переподключить

Если нарисовать состояния и условия переходов, видно, где работают backoff и предел переподключений.

stateDiagram-v2
    [*] --> Unknown
    Unknown --> Absent: не находится при перечислении
    Unknown --> Present: перечисление при запуске / уведомление arrival
    Absent --> Present: уведомление arrival
    Present --> Absent: уведомление removal (из любого состояния)
    state Present {
        [*] --> Detected
        Detected --> Opening: open / login / initialize
        Opening --> Ready: инициализация и проверка конфигурации прошли
        Opening --> Fault: инициализация не удалась (есть смысл повторить)
        Opening --> Mismatch: неожиданный экземпляр, модель, firmware
        Ready --> Busy: warming up / выполняется / interlock
        Busy --> Ready: можно принять операцию
        Busy --> Fault: ошибка I/O
        Ready --> Fault: ошибка I/O / нет ответа зафиксировано
        Fault --> Reconnecting: выдержать backoff
        Reconnecting --> Opening: время ожидания истекло
        Reconnecting --> RetryExhausted: достигнут предел переподключений
        Fault --> Opening: переподключить вручную
        RetryExhausted --> Opening: переподключить вручную (автоматически не возвращается)
        Mismatch --> Opening: исправить конфигурацию и переподключить вручную
    }

Рис. 14: На этой схеме только срок жизни подключения и сессии, актуальность данных не входит. Актуальность — отдельная ось от готовности к работе (рис. 2), и она может устареть одинаково и в Ready, и в Busy. Если смешать её в это состояние, легко получить путаницу вроде «во время выполнения значения оборвались, а после восстановления стало Ready». На экране состояние этой схемы и оценку актуальности из раздела 4.5 держат отдельно и сочетают. Даже исчерпав предел повторных попыток, не опускают в Absent (не подключено), а оставляют в RetryExhausted, из которого автоматически не выходят, — устройство может быть видно и при этом сломано, а надпись «не подключено» подтолкнёт к неверной операции восстановления. Несовпадение конфигурации повторными попытками тоже не лечится, поэтому его выводят из цикла автоматического переподключения.

6.2 Сглаживаем флаппинг

При плохом контакте USB или кратковременном обрыве сети состояние быстро скачет туда-сюда. Если сырые события сразу отдавать в UI, читать это крайне неудобно.

Поэтому удобнее такое разделение:

• во внутреннем журнале оставлять сырые события как есть
• в UI выдерживать короткий период подтверждения, затем фиксировать отображение
• но критичный сбой показывать сразу

flowchart TB
    accTitle: Флаппинг сглаживают, затем фиксируют отображение
    accDescr: При флаппинге из-за плохого контакта или кратковременного обрыва состояние быстро скачет. Сырые события оставляют в журнале, UI фиксирует отображение после короткого периода подтверждения, а критичный сбой показывают сразу.
    n1["Состояние быстро скачет туда-сюда"] --> n2["Сырые события оставляют в журнале как есть"]
    n1 --> n3["UI фиксирует отображение после периода подтверждения"]
    n3 -.-> n4["Критичный сбой показывают сразу"]

Рис. 15: Сырые события — в журнал, в UI — сглаженное зафиксированное состояние.

6.3 Минимальный набор данных для журнала

Улучшение отображения состояния почти всегда идёт вместе с проектированием журнала.

Особенно важен журнал переходов состояния.

6.4 Не путайте остановку мониторинга с остановкой устройства

• цикл poll умер из-за исключения
• callback SDK перестал вызываться
• acquisition worker завис в deadlock
• обновление state store просто прекратилось

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

Поэтому исправность пути мониторинга лучше держать отдельной осью.

flowchart TB
    accTitle: Остановку мониторинга не выдавать за остановку устройства
    accDescr: Если умер цикл poll или остановился callback, устройство может быть живо, а приложение его не наблюдает. Показ как «не подключено» или «нет ответа» выглядит как проблема устройства, поэтому исправность пути мониторинга держат отдельной осью.
    p1["Цикл poll умер из-за исключения"] --> p3["Устройство живо, но наблюдать нельзя"]
    p2["Останавливаются callback или worker"] --> p3
    p3 --> p4["Надпись «Не подключено» выглядит как проблема устройства"]
    p4 -.->|"поэтому"| p5["Исправность мониторинга держат отдельной осью"]

Рис. 16: «Не наблюдаем» не смешивают с «устройству плохо».

7. Что легко упустить по типам устройств

7.1 USB- и PnP-устройства

• Одних уведомлений недостаточно, чтобы найти already existing device
• Во время выполнения естественнее interface class, а не setup class
• Составное устройство (composite device) может отдавать несколько interface
• Уведомление remove и I/O error иногда приходят в разном порядке

7.2 Последовательные устройства

Одного появления COMx недостаточно, чтобы успокоиться.

• Порт есть, но целевое устройство к нему не подключено
• Порт открыт другим процессом
• Устройство уже перестало отвечать
• read / write зависают по timeout

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

7.3 Сетевые устройства

Успешный ping не стоит отождествлять с тем, что устройство доступно приложению.

Есть несколько этапов:

• Разрешается ли имя
• Устанавливается ли TCP-соединение
• Проходит ли handshake на уровне приложения
• Готов ли status (ready)
• Свежи ли значения

flowchart TB
    accTitle: От успешного ping до «можно пользоваться» есть этапы
    accDescr: У сетевых устройств есть этапы: разрешается ли имя, устанавливается ли TCP, проходит ли handshake на уровне приложения, готов ли status, свежи ли значения. Успешный ping не равен доступности.
    q1["Имя разрешается"] --> q2["TCP устанавливается"]
    q2 --> q3["Handshake на уровне приложения проходит"]
    q3 --> q4["status готов (ready)"]
    q4 --> q5["Значения свежие"]
    q1 -.-> q6["Успешный ping ≠ можно пользоваться"]

Рис. 17: До «можно пользоваться» у сетевого устройства пять этапов.

7.4 Камеры и измерительные приборы, зависящие от SDK

Безопаснее не считать устройство живым (live) только потому, что приходят callback SDK.

• Останавливается сам поток callback
• Кадры приходят, но timestamp не двигается
• Поток изображения идёт, а канал управления мёртв
• После reconnect повторное применение настроек ещё не закончено

Такое бывает, поэтому спокойнее иметь и представление об исправности, независимое от самого SDK.

8. Чего делать не следует

• Сводить состояние к трём вариантам: Подключено / Не подключено / Ошибка
• Считать, что одних уведомлений достаточно, чтобы найти и already existing device
• Считать успешный open автоматически равным Доступно
• Показывать last known value так, будто оно fresh
• Не показывать timestamp
• Выполнять open / read / status query в UI thread
• Повторять попытки в самом коротком цикле
• Показывать критичный сбой только в status bar
• Путать Не подключено и Мониторинг остановлен
• Идентифицировать экземпляр только по friendly name или COM3

9. Итог

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

Особенно работает такое разделение.

Устройство существует Наше приложение может его открыть Оно отвечает Эта операция сейчас возможна Значения на экране свежие

Разделяйте эти пять пунктов.

На этой основе практические ориентиры примерно такие.

• При запуске — перечисление, дальше — уведомления
• Готовность к использованию определять по heartbeat и device-specific status
• К отображаемым значениям давать timestamp и age
• Критичный сбой выводить туда, где его трудно не заметить
• Сбои системы мониторинга не выдавать за сбои устройства

На практике гораздо важнее не сама возможность написать «Подключено», а то, насколько редко это отображение расходится с реальностью.

10. Источники

• Microsoft Learn, TimeProvider Class (GetTimestamp возвращает высокоточное значение на базе Stopwatch; GetElapsedTime(Int64, Int64) даёт прошедшее время между двумя точками)
• Microsoft Learn, CM_Register_Notification
• Microsoft Learn, Registering for Notification of Device Interface Arrival and Device Removal
• Microsoft Learn, Registering for Device Notification
• Microsoft Learn, Comparison of setup classes and interface classes
• Microsoft Learn, Device Information Sets
• Microsoft Learn, SetupDiEnumDeviceInterfaces
• Microsoft Learn, Communications functions
• Microsoft Learn, ClearCommError
• Microsoft Learn, COMMTIMEOUTS structure
• Microsoft Learn, WaitCommEvent
• Microsoft Learn, Monitoring Communications Events
• Microsoft Learn, Status Bars (Design basics)
• Microsoft Learn, UX checklist for desktop applications

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Почему недостаточно показывать состояние устройства как «Подключено»?

Формулировка «Подключено» сводит в одно сразу несколько разных вопросов: видит ли устройство ОС, смогло ли приложение выполнить open, отвечает ли устройство, можно ли сейчас выполнить операцию, актуально ли значение на экране, тот ли это экземпляр. Например, «Не подключено», «Подключено / проверяется», «Подключено / недоступно» и «Значение устарело» — это разные состояния. Если все их свести к «Подключено», оператор не поймёт, что делать дальше.

Как внутри приложения разделять состояние внешнего устройства?

Держите оси отдельно: наличие (видит ли устройство ОС), установление сессии (выполнены ли open/login/initialize), отзывчивость (отвечает ли на heartbeat), готовность к работе (можно ли сейчас принять операцию), актуальность данных (свежи ли значения на экране), соответствие конфигурации (тот ли экземпляр и firmware) и исправность мониторинга (жив ли сам путь наблюдения). Грубо: наличие проверяет сторона ОС, возможность использования — сторона приложения, актуальность — сторона экрана. В UI удобнее три слоя: сводка, причина и детали.

Обнаружение устройства и проверку исправности лучше делать через события или через опрос?

Не стоит выбирать что-то одно целиком. На практике удобнее разделение: обнаружение — через event, проверку исправности — через poll. Arrival/removal принимают уведомлениями о событиях, heartbeat и status query — периодическим опросом, актуальность — по timestamp или sequence. Одних уведомлений недостаточно, чтобы найти уже существующие устройства, поэтому правило такое: при запуске перечислить, затем подписаться на уведомления, а при уведомлении снова перечислить и привести внутреннее состояние в соответствие (reconcile).

Как реализовать переподключение к устройству, которое перестало отвечать?

Не стоит долбить самым коротким циклом — нужен backoff. Реалистичная схема: сразу повторить попытку в первый раз, при неудаче постепенно увеличивать интервал, задать верхний предел и дать ручную кнопку «Переподключить». Самый короткий цикл нагружает устройство и SDK, заливает логи и усиливает кратковременную нестабильность. Для флаппинга — когда при плохом контакте USB состояние быстро скачет туда-сюда — на стороне UI полезно выдержать короткий период подтверждения, прежде чем зафиксировать отображаемое состояние.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.