METHODOLOGY FOR STATISTICAL ASSESSMENT OF EMBEDDED LINUX SYSTEM READINESS IN A VIRTUAL TEST LOOP

УДК 004.415.53

Аннотация

Цель работы состоит в разработке прикладной методики статистической оценки готовности встраиваемой Linux-системы после запуска в виртуальном контуре. Методика предназначена для ситуаций, когда единичный запуск в контуре непрерывной интеграции (CI) не является достаточным основанием для вывода о стабильности конфигурации. В качестве методологической основы используется серия повторяемых запусков QEMU, потоковый разбор консольного журнала, модель наблюдаемых состояний готовности и формальный профиль допуска. Для каждого прогона фиксируются вердикт «успех/отказ», время достижения результата, достигнутая стадия и класс отказа. Для серии прогонов рассчитываются наблюдаемая частость успешных запусков, односторонняя нижняя доверительная граница вероятности успешного прохождения, медиана и хвостовые характеристики времени выполнения. Экспериментальная проверка выполнена на виртуальных профилях ARMv7, AArch64 и RV64. Показано, что серия N=500 при отсутствии отказов обеспечивает нижнюю 95 %-ю границу вероятности успешного прохождения 0,9940, что достаточно для предварительного критерия p_min=0,99. Практическая значимость результата состоит в том, что виртуальный контур позволяет массово фильтровать регрессии до переноса проверки на аппаратный стенд, но не заменяет валидацию полной загрузочной цепочки реального устройства.

Abstract

The purpose of this work is to develop an applied methodology for statistical assessment of embedded Linux system readiness after startup in a virtual test loop. The method targets cases where a single CI run is not a sufficient basis for judging configuration stability. The methodology combines repeated QEMU executions, streaming console log parsing, an observable readiness-state model, and a formal gate profile. For each run, the PASS/FAIL verdict, time to result, reached stage, and failure class are recorded. For a run series, the success ratio, one-sided lower confidence bound for pass probability, median time, and tail timing metrics are calculated. Experimental validation is demonstrated on virtual ARMv7, AArch64, and RV64 profiles. The results show that N=500 zero-failure runs provide a one-sided 95 % lower confidence bound of 0.9940 for pass probability, which is sufficient for a preliminary pmin=0.99 gate. The practical value of the approach is that the virtual loop can filter regressions at scale before hardware validation, while it does not replace validation of the full boot chain of a real device.

Ключевые слова: встраиваемые Linux-системы; QEMU; готовность ОС; статистическая валидация; консольные журналы; непрерывная интеграция; RISC-V.

Keywords: embedded Linux systems; QEMU; OS readiness; statistical validation; console logs; CI; RISC-V.

Введение

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

Существующие инфраструктуры, такие как KernelCI и LAVA, показывают практическую важность автоматизированных запусков, сбора журналов и раннего обнаружения регрессий [6; 7]. Однако сама инфраструктура запуска не снимает вопроса о критерии принятия решения: сколько повторов достаточно, какие маркеры считать обязательными, как учитывать хвосты распределения времени и как отделять отказ ядра от отказа пользовательской проверки.

Полная загрузочная цепочка реальной платформы включает ранний загрузчик, системный рантайм или прошивку, загрузчик ОС, ядро и пользовательское пространство [9; 3]. В виртуальном контуре часть ранних стадий может быть ненаблюдаема или заменена моделью эмулятора. Поэтому в данной работе предмет сознательно сужен: оценивается не корректность всей аппаратно-прошивочной цепочки, а готовность встраиваемой Linux-системы в виртуальном контуре после начала наблюдаемого интервала.

Цель работы – предложить методику статистической оценки готовности ОС, пригодную для предварительной проверки в контуре непрерывной интеграции. Для достижения цели решаются следующие задачи: определить наблюдаемые состояния готовности, описать декларативный профиль допуска, задать протокол серийных запусков, сформулировать статистические критерии и показать применение методики на виртуальных профилях ARMv7, AArch64 и RV64.

Материалы и методы

В качестве испытательного контура рассматривается запуск минимальной Linux-системы в QEMU. QEMU используется как средство системной эмуляции, предоставляющее виртуальную модель процессора, памяти и устройств для запуска гостевой ОС [10]. Такой контур удобен для массовых повторов, но его тайминги зависят от хоста, планировщика и реализации эмуляции, поэтому результаты не переносятся автоматически на физическое устройство.

Экспериментальная конфигурация задаётся набором фиксированных артефактов: версия ядра или идентификатор фиксации исходного кода, конфигурация сборки, образ корневой файловой системы, параметры запуска QEMU, профиль маркеров, набор быстрых проверок и версия анализатора журналов. Изменение любого элемента считается изменением экспериментальной конфигурации. Такой подход согласуется с общей идеей воспроизводимости, согласно которой результат должен зависеть от контролируемых входных данных, а не от случайного состояния окружения [11; 12].

Этапы методики эксперимента

1) Цель и задачи эксперимента: оценить устойчивость достижения состояния готовности ОС, определить наблюдаемые состояния, сформировать критерий допуска и локализовать возможные отказы.

2) Варьируемые факторы: архитектурный профиль, версия ядра и параметры профиля допуска. Контролируемыми факторами являются образ корневой файловой системы, версия QEMU, параметры запуска, набор проверок и состояние вычислительного хоста.

3) Средства и количество измерений: системный эмулятор QEMU, средство захвата консольного журнала и анализатор событий. Серия N=100 используется для оценки распределения времени, серия N=500 — для доверительной оценки вероятности успешного прохождения при отсутствии наблюдаемых отказов.

4) Порядок проведения: каждый запуск начинается из одинакового исходного состояния; после запуска QEMU фиксируется первый наблюдаемый маркер, далее журнал собирается до итогового состояния «успех» или «отказ», после чего сохраняются журнал и структурированный отчёт.

5) Обработка и анализ результатов: рассчитываются частость успешных запусков, доверительная граница вероятности успеха для большой серии, медиана, 95-й и 99-й процентили времени, а также распределение отказов по стадиям и классам.

Модель готовности задаётся конечным автоматом:

Здесь S — множество наблюдаемых состояний, Σ — множество событий из консольного журнала и результатов проверок, δ — функция переходов, s₀ — начальное состояние наблюдаемого интервала, F — множество принимающих состояний. Для каждого состояния вводится инвариант: обязательный маркер, запрет критических сообщений и предельное время достижения состояния.

Таблица 1. Наблюдаемые состояния готовности ОС

Источник: составлено автором

Профиль допуска содержит список обязательных маркеров, предельные времена состояний, запрещённые сообщения, набор быстрых проверок и правила классификации отказов. В качестве быстрых проверок могут использоваться минимальные тесты пользовательского пространства или специализированный набор таких проверок; пример подобного инструмента приведён в [1]. Для расширенного уровня допуска допустимо подключение набора самопроверок ядра kselftest, но в рассматриваемой версии методики используются только короткие проверки готовности [5].

Каждый прогон описывается бинарным исходом и временем достижения результата:

Для серии из N запусков число успешных прогонов X и наблюдаемая частость успешных запусков ν определяются выражениями:

Величина ν является частостью, вычисленной по конечной выборке, а p обозначает неизвестную вероятность успешного прохождения. Для малых серий приводится только частость; для большой серии дополнительно строится доверительная граница вероятности p. При X=N односторонняя 95 %-я нижняя граница вероятности успеха равна:

Соответственно, односторонняя 95%-я верхняя доверительная граница вероятности отказа равна q_U=1−p_Lq.  Использование доверительной границы, а не только наблюдаемой частости, уменьшает риск принять нестабильную конфигурацию как устойчивую [2].

Времена достижения результата не предполагаются нормально распределёнными. Поэтому для анализа используются медиана, 95-й и 99-й процентили, бутстрэп-интервалы и непараметрическое сравнение распределений [4; 8]. Статистически значимое отличие рассматривается как регрессия только тогда, когда оно превышает инженерно заданный допуск по частости успешных запусков или по хвосту распределения времени.

Таблица 2. Правила принятия решения в виртуальном контуре непрерывной интеграции

Источник: составлено автором

Результаты и обсуждение

Экспериментальная проверка выполнена для трёх виртуальных профилей: ARMv7, AArch64 и RV64. Измеряемая величина определялась как время от начала наблюдаемого интервала до появления итоговой строки быстрой проверки готовности. Внешняя сеть в критерий результата не включалась; сетевые действия, если они присутствуют в профиле, должны выполняться только внутри изолированного контура эмуляции.

Первая серия использовалась для оценки распределения времени достижения результата. Для каждого профиля выполнено N=100 запусков; для сопоставления использовалась ветка stable-6.17. По этой серии вычислялись среднее значение и 95-й процентиль, которые удобны для первичной оценки хвостовых задержек. Значения приведены в таблице 3.

Таблица 3. Время достижения результата в виртуальном контуре, N=100

Источник: составлено автором

По данным таблицы 3 AArch64-профиль в выбранной конфигурации QEMU имеет наименьшее среднее время достижения результата. RV64-профиль показывает более выраженный хвост задержек: при близком порядке среднего времени 95-й процентиль достигает 2,139 с. Этот вывод относится только к выбранной эмуляционной конфигурации. Он не доказывает аппаратного преимущества или недостатка какой-либо архитектуры, потому что виртуальный контур измеряет поведение конкретной модели запуска.

Рисунок 1. Нижняя 95 %-я граница вероятности успешного прохождения при отсутствии отказов

Вторая серия предназначалась для оценки наблюдаемой частости успешных запусков и нижней доверительной границы неизвестной вероятности успешного прохождения. Для каждого профиля выполнено N=500 запусков без наблюдаемых отказов. Такой результат не означает доказанную безотказность: он только задаёт верхнюю границу вероятности отказа на выбранном доверительном уровне. Итоговые значения приведены в таблице 4.

Таблица 4. Частость успешных запусков и доверительная оценка по серии N=500

Источник: составлено автором

Результаты таблицы 4 достаточны для предварительного критерия p_min=0,99, но недостаточны для критерия p_min=0,995: нижняя граница 0,9940 находится ниже такого порога. Это важно практически: 500 успешных запусков подряд выглядят убедительно для человека, но формально оставляют ненулевую область неопределённости. Для более жёсткого допуска нужен больший объём серии или дополнительная аппаратная проверка.

Таблица 5. Влияние объёма серии на границу вероятности отказа при X=N

Источник: составлено автором

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

Ограничение текущей экспериментальной части состоит в отсутствии отдельной серии негативных сценариев. Серии без отказов полезны для оценки верхней границы вероятности отказа, но они не демонстрируют чувствительность классификатора к конкретным дефектам. Для усиления дальнейшей версии работы необходимо добавить внесение искусственных отказов: удаление обязательного маркера, искусственную задержку процесса PID 1, имитацию аварийного завершения ядра, провал монтирования каталога /proc и отрицательный результат одной быстрой проверки. Без такой серии методика остаётся ограниченной демонстрацией успешных прогонов и требует дальнейшего подтверждения чувствительности к отказам.

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

Заключение

Предложена методика статистической оценки готовности встраиваемой Linux-системы в виртуальном контуре. Методика включает модель наблюдаемых состояний, декларативный профиль допуска, потоковый разбор консольных журналов, классификацию отказов и статистические правила принятия решения по вероятности успешного прохождения и времени достижения результата.

Экспериментальная проверка на виртуальных профилях ARMv7, AArch64 и RV64 показала применимость подхода для предварительной проверки в контуре непрерывной интеграции. Серия N=100 позволяет анализировать распределение времени и хвостовые задержки, а серия N=500 при отсутствии отказов даёт одностороннюю 95 %-ю нижнюю границу вероятности успешного прохождения 0,9940. Это достаточно для предварительного порога p_min=0,99, но недостаточно для более жёстких критериев.

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

Список литературы:

1. Belykh A. RISC-V Linux Smoke Test Suite (project repository) [Электронный ресурс]. URL: https://github.com/R2DXT/RISC-V-Linux-Smoke-Test-Suite (дата обращения: 20.06.2026).
2. Brown L.D., Cai T.T. DasGupta A. Interval Estimation for a Binomial Proportion // Statistical Science. – 2001. – № 2. – P. 101⁠–⁠133. – DOI: 10.1214/ss/1009213286.
3. Das U-Boot Project. U-Boot Documentation: SPL/TPL and boot flow [Электронный ресурс]. URL: https://docs.u-boot.org/ (дата обращения: 20.06.2026).
4. Efron B., Tibshirani R.J. An Introduction to the Bootstrap. New York: Chapman & Hall/CRC, 1993. 456 P.
5. Kernel.org. Linux Kernel Selftests (kselftest): documentation [Электронный ресурс]. // Kernel.org. URL: https://docs.kernel.org/dev-tools/kselftest.html (дата обращения: 20.06.2026).
6. KernelCI. KernelCI documentation: mission and testing ecosystem [Электронный ресурс]. URL: https://docs.kernelci.org/ (дата обращения: 20.06.2026).
7. LAVA. Bootloader/Firmware Testing and Recovery: documentation [Электронный ресурс]. URL: https://docs.lavasoftware.org/lava/bootloaders.html (дата обращения: 20.06.2026).
8. Mann H.B., Whitney D.R. On a Test of Whether One of Two Random Variables is Stochastically Larger than the Other // Annals of Mathematical Statistics. – 1947. – № 1. – P. 50–60. – DOI: 10.1214/aoms/1177730491.
9. OpenSBI Project. OpenSBI Documentation: firmware architecture and platforms URL: https://github.com/riscv-software-src/opensbi (accessed 20.06.2026) (дата обращения: 20.06.2026).
10. QEMU Project. QEMU System Emulation documentation URL: https://www.qemu.org/docs/master/system/index.html (accessed 20.06.2026) (дата обращения: 20.06.2026).
11. Reproducible Builds. Reproducible Builds: definition and best practices URL: https://reproducible-builds.org/ (accessed 20.06.2026) (дата обращения: 20.06.2026).
12. The Yocto Project. Reproducible Builds (Test Manual) URL: https://docs.yoctoproject.org/test-manual/reproducible-builds.html (accessed 20.06.2026) (дата обращения: 20.06.2026).