Реализация исполняемого знания как детерминированного вычислительного ядра и детерминированного ядра безопасности
Авторский коллектив
- Прозоров А.А., Директор по технологиям РТЛАБ, архитектор Сбертех, ap@rtlab.ru;
- Нгуен И.Х., Инженер-разработчик РТЛАБ, инженер-разработчик Сбертех, inguen@rtlab.ru;
- Нужный А.С., Руководитель группы вычислительных методов РТЛАБ, старший научный сотрудник Института проблем безопасного развития атомной энергетики РАН, к.ф.-м.н., anuzhny@rtlab.ru;
- Бахвалов И.М., Генеральный директор РТЛАБ Онкология, ibakhvalov@rtlab.ru;
- Никитин Т.Н., Генеральный директор РТЛАБ Анестезиология, tnikitin@rtlab.ru;
- Марочко М.А., Инженер-разработчик РТЛАБ Анестезиология, mmarochko@rtlab.ru;
Аннотация
Цель: Скомпилированное исполняемое знание становится заслуживающим доверия только тогда, когда среда, которая его использует во время выполнения, является детерминированной, ограниченной, пригодной к выполнению аудита и явно показывает, что она не авторизует. В статье определяется архитектура времени выполнения, в которой детерминированное вычислительное ядро и детерминированное ядро безопасности выполняют скомпилированное знание через анализ без сохранения состояния, не становясь авторизованной семантикой.
Материалы и методы: Статья является методологической системной работой с ограниченными доказательствами реализации, полученными из планирования вычислительного ядра, спецификаций границы времени выполнения, спецификаций планировщика и управления, спецификаций скомпилированного пакета, спецификаций доказательств выполнения и материалов трассируемости безопасности. Внешние стандарты задают рамку дисциплины жизненного цикла, управления рисками, трассируемости в системе качества, доказуемого происхождения данных, аналогий аудита, канонических дайджестов и артефактов, ограниченных схемами.
Результаты: Метод разделяет авторизованную семантику, доказательства релиза и развертывания, проверку хоста сервиса, библиотеку вычислительного ядра времени выполнения, выполнение запроса без сохранения состояния, доказательства аудита и отладки, а также последующую проекцию доказательств выполнения. Он определяет границы ответственности вычислительного ядра, ядра безопасности, хоста сервиса и поверхностей доказательств, а затем иллюстрирует цепочку на нейтральном с точки зрения безопасности примере длительности сигнала.
Заключение: Анализ без сохранения состояния позволяет скомпилированному исполняемому знанию выполняться как детерминированное вычисление в пределах запроса, сохраняя отдельные полномочия семантики, релиза, хоста и времени выполнения. Ядро безопасности обеспечивает допустимость выполнения с политикой «при ошибке — стоп» и доказательства, но не заменяет клиническую валидацию или регуляторное одобрение.
Ключевые слова: исполняемое знание; вычислительное ядро; ядро безопасности; библиотека времени выполнения; анализ без сохранения состояния; детерминированное выполнение; выполнение с политикой «при ошибке — стоп»; доказательства выполнения; пригодность к выполнению аудита
Сокращения и терминология
Детерминированное вычислительное ядро: Подсистема детерминированных вычислений, которая валидирует каталог времени выполнения в памяти, строит неизменяемый вычислительный движок, выполняет один нормализованный запрос, управляет отложенными и зафиксированными фактами в пределах запроса, собирает ответ, переносит ссылки на термины времени выполнения и выпускает детерминированные доказательства.
Детерминированное ядро безопасности: Подсистема детерминированного управления во время выполнения, которая обеспечивает разрешение привязок, проверку предварительных условий, проверку применимости, область действия модуля и лицензии, политики пропуска, деградации и прерывания, а также отказ по политике «при ошибке — стоп». В анализе без сохранения состояния она управляет допустимостью выполнения и доказательствами; нижестоящие контуры анализатора с сохранением состояния могут также использовать ее для применения команды с участием человека в контуре. Она не является системой клинической валидации.
Анализ без сохранения состояния: Режим времени выполнения, в котором библиотека вычислительного ядра времени выполнения исполняет один нормализованный запрос по неизменяемому каталогу времени выполнения в памяти, использует только изменяемое состояние в пределах запроса, возвращает детерминированный ответ и доказательства и не хранит изменяемое клиническое состояние между запросами.
Хост сервиса: Граница процесса или сервиса, которая отвечает за транспорт, декодирование, доступ к файлам, сетевой доступ, секреты, выбор источника пакета, контекст релиза и развертывания, проверки дайджеста или подписи, проверки схемы и проекцию выходов времени выполнения во внешние темы или хранилища.
Авторизованный снимок: Ограниченная, идентифицированная дайджестом семантическая основа, принятая путем авторизации для скомпилированного артефакта времени выполнения. Это семантический вход компиляции, а не источник смысла, выбираемый во время выполнения.
Скомпилированный пакет: Связанная дайджестом проекция времени выполнения, полученная из авторизованной семантики и выхода компилятора. Она несет каталог времени выполнения и проекции доказательств, потребляемые хостом сервиса и библиотекой вычислительного ядра времени выполнения.
Доказательства релиза и развертывания: Доказательства для рецензента, которые показывают, какой скомпилированный пакет, квитанции, отпечатки конфигурации и контекст развертывания образуют ограниченный набор исполнения для развертывания, воспроизведения и рецензирования.
Каталог времени выполнения: Декларативное представление выполнения в памяти, производное от скомпилированного пакета. Оно описывает исполняемые единицы, зависимости, порядок уровней и ярусов, привязки, ссылки на термины времени выполнения, политики управления, шаблоны аудита и шаблоны отладки.
Неизменяемый вычислительный движок: Совместно используемый между запросами объект времени выполнения, построенный из валидированного каталога времени выполнения. Он содержит неизменяемые данные плана, производные от каталога, и не удерживает данные запроса или изменяемое клиническое состояние.
Точка входа выполнения конвейера: Публичная точка входа для выполнения запроса в библиотеке вычислительного ядра времени выполнения. Она принимает нормализованный запрос и возвращает владеющий ответ вместе с доказательствами.
Запрос конвейера и ответ конвейера: Запрос является одним нормализованным вызовом, который содержит идентификаторы запроса, отпечатки конфигурации, входы сигналов и контекста, а также активную область времени выполнения. Ответ является владеющим контейнером для выходов, метаданных выполнения, событий аудита, трассы отладки, маркеров деградации и материала детерминированного хеша.
Событие аудита: Долговечная запись доказательств, используемая для пригодности к выполнению аудита, рецензирования релиза и реконструкции инцидентов. Трасса отладки может ссылаться на события аудита, но не заменяет их.
Трасса отладки: Диагностические доказательства в пределах запроса, которые объясняют управляющие решения, проверенные контракты, причины пропуска, деградации или прерывания, поведение замещающих тел без вывода и порядок выполнения. Она не является неотменяемым аудитом.
Неотменяемая запись аудита: Долговечная запись аудита, чье доказуемое происхождение, привязка к дайджесту или контексту и публикация с добавлением записей делают ее непригодной для незаметной реконструкции из трасс отладки. Это доказательственное понятие пригодности к аудиту, а не юридическое утверждение о неоспоримости.
Ссылка на термин времени выполнения: Скомпилированный идентификатор термина, переносимый через каталог времени выполнения, нормализованный запрос, ответ, ссылки аудита и отладки и проекцию доказательств. Объединения с реестром и трассой остаются ответственностью сопутствующей статьи о трассируемости терминов.
Применение команды с участием человека в контуре: Нижестоящий путь анализатора с сохранением состояния, в котором ядро безопасности управляет применением команд, акцептованных человеком. Это не часть обычного анализа без сохранения состояния.
Проекция доказательств выполнения: Последующая нормализация ответа, аудита, отладки, метрик, результатов и поверхностей повторного прогона в проверяемые артефакты доказательств выполнения.
ПнД (PHI): Персональные данные о здоровье. В этой статье термин обозначает сырые поля, идентифицирующие пациента, и сопоставимые повторно идентифицируемые полезные данные, которые не должны попадать в трассу отладки.
Замещающее тело медицинского алгоритма: Ограниченный исполняемый замещающий компонент, который проверяет контракты времени выполнения и выпускает доказательства, но намеренно не производит клинических фактов или заключений.
Управляемая деградация: Объявленная политика времени выполнения, находящаяся в валидированном каталоге времени выполнения или конфигурации времени выполнения, привязанной к релизу, и допускающая ограниченный деградированный ответ только тогда, когда каталог, запрос и решение ядра безопасности явно делают этот деградированный путь видимым. Она отличается от отказа по политике «при ошибке — стоп» при нарушениях целостности или допустимости.
Детерминированный хеш: Канонический дайджест по запросу, идентификатору активного каталога, идентификатору плана выполнения, итоговым зафиксированным фактам, отсортированным причинам деградации и другим зафиксированным контрактом детерминированным входам, исключая изменчивые поля времени.
Публичный текст рукописи следует двум инвариантам. Во-первых, он использует описательные термины архитектуры времени выполнения вместо идентификаторов реализации. Во-вторых, он использует термин «анализ без сохранения состояния» вместо внутренних меток режимов времени выполнения.
Введение
Исполняемое знание проходит через несколько преобразований, прежде чем влияет на поведение во время выполнения. Формальная семантика авторизуется, компилируется, проецируется в артефакты времени выполнения, выпускается в релиз, развертывается, загружается хостом сервиса и наконец выполняется для конкретного запроса. Дефект на любой границе может создать видимость выполнения знания, хотя фактически система запускает устаревшее, неполное, неподдерживаемое или недостаточно доказанное поведение.
Эта статья рассматривает часть цепочки, относящуюся ко времени выполнения. Библиотека вычислительного ядра времени выполнения исполняет валидированный каталог в памяти под явной границей хоста сервиса. Авторизованная семантика остается за управляемым графом и цепочкой происхождения компилятора; доказательства релиза и развертывания идентифицируют ограниченный набор исполнения; транспорт и выбор источника остаются ответственностью хоста. Вычислительное ядро отвечает за детерминированное выполнение запроса без сохранения состояния, а ядро безопасности отвечает за допустимость выполнения, управляемую деградацию и управление по политике «при ошибке — стоп».
Вклад статьи состоит в повторно используемом системном паттерне реализации исполняемого знания как детерминированного вычислительного ядра и детерминированного ядра безопасности. Паттерн намеренно узок; полные отсутствия утверждений собраны в разделе ограничений.
Сопутствующие статьи
Сопутствующая статья «Исполняемое знание как объект медицинской информатики в надзорной экосистеме операционной и отделения реанимации и интенсивной терапии» объясняет, почему супервизору нужны исполняемое знание и ограниченное поведение в контуре исполнения у постели пациента. «Замкнутый цикл управления формализуемым знанием в клинических информационных системах» отвечает за метод управления с единой авторизованной семантикой. «Формальное представление знаний как входной и внутренний языки компилятора знаний в системах клинического назначения» отвечает за языковые уровни компилятора и понижение представления. «Сквозная трассировка кодифицированных терминов для отладки и аудита компилятора и исполняемых модулей» отвечает за реестр терминов и объединение с трассами. «Контур авторизации и диагностики как универсальная инфраструктура разработки и управления исполняемым знанием» отвечает за закрытие диагностического контура с помощью Рабочего стола после того, как доказательства выполнения выявляют потребность в управляемом уточнении.
Нижестоящие системные статьи отвечают за контуры хостинга и релиза. «Реализация потокового анализатора для смеси именованных признаков и осциллограмм» и «Анализатор на основе правил без сохранения состояния для смеси именованных признаков и осциллограмм» отвечают за архитектуру потокового анализатора и анализатора без сохранения состояния. «Автоматический релиз доверенных исполняемых модулей анализатора из доверенного снимка знаний в замкнутом цикле» и «Непрерывная цепочка доверия при автоматическом релизе исполняемых модулей анализатора в замкнутом цикле» отвечают за автоматизацию релиза и непрерывность цепочки доверия. «Мгновенная оценка состояния здоровья на примере интерпретации смеси именованных терминов и осциллограмм ЭКГ» отвечает за предметную инстанциацию ЭКГ и использование клинического графа знаний.
Материалы и методы
Это методологическая системная статья с ограниченными доказательствами реализации. Внутренняя авторская основа включает планы реализации вычислительного ядра, постановки проблемы и реализации вычислительного ядра, спецификации границы времени выполнения, спецификации планировщика, спецификации управляющих алгоритмов, спецификации памяти и трассы отладки, спецификации скомпилированного пакета, спецификации доказательств выполнения, материалы трассируемости безопасности и общий канон терминологии мгновенной оценки состояния здоровья (IHA). Эти внутренние материалы формируют архитектурное изложение, но не являются публичными ссылками.
Внешние источники задают рамку, а не продуктовые утверждения. IEC 62304 задает дисциплину жизненного цикла программного обеспечения [1]. ISO 14971 задает рамку управления рисками для связанных с безопасностью границ времени выполнения [2]. ISO 13485 задает управление трассируемостью в системе качества [3]. PROV-O и FHIR AuditEvent задают аналогии доказуемого происхождения данных и структурированного медицинского аудита [4,5]. RFC 8785 задает канонизацию JSON для дайджестов и воспроизводимых квитанций [6]. JSON Schema 2020-12 задает артефакты доказательств и пакетов, ограниченные схемами [7].
Метод разделяет четыре уровня. Семантический уровень авторизует и компилирует знание в дисциплине жизненного цикла и трассируемости системы качества [1,3]. Уровень релиза и развертывания выбирает и проверяет ограниченный набор исполнения. Уровень хоста сервиса отвечает за транспорт, декодирование, выбор источника и внешнюю проекцию. Уровень библиотеки времени выполнения выполняет анализ без сохранения состояния, исполняя валидированный каталог в памяти с состоянием в пределах запроса и детерминированными доказательствами.
Обзор жизненного цикла времени выполнения
Ось жизненного цикла представлена как нисходящий поток артефактов и ответственности:
Рисунок 1. Жизненный цикл и поток владения от скомпилированного пакета к проекции доказательств. Диаграмма показывает нисходящий путь от авторизованных и выпущенных артефактов времени выполнения к проверке хостом сервиса, материализации каталога в памяти, выполнению вычислительным ядром, созданию ответа, доказательствам аудита и отладки и проекции доказательств выполнения.
Рисунок 1 подчеркивает владение на этапах жизненного цикла. Авторизованный снимок и скомпилированный пакет устанавливают скомпилированную основу выполнения, а доказательства релиза и развертывания показывают, какой пакет принят для контура исполнения. Хост сервиса проверяет выбранный пакет, проверяет доказательства схемы и дайджеста, материализует представление каталога, нормализует запрос и передает структуры в памяти библиотеке вычислительного ядра времени выполнения. Артефакты, ограниченные схемами, и канонические дайджесты делают эту передачу воспроизводимой [6,7]. Вычислительное ядро валидирует каталог, строит неизменяемый вычислительный движок, выполняет один запрос через анализ без сохранения состояния и выпускает владеющий ответ. События аудита, трасса отладки и проекция доказательств выполнения затем делают выполнение рецензируемым, не превращая данные отладки в авторитет аудита или поведение времени выполнения в авторизованную семантику.
Таблица 1: Компоненты, ответственность и границы полномочий
Таблица 1. Компоненты, ответственность и границы полномочий
| Компонент | Ответственность | Потребляет | Производит | Граница полномочий |
|---|---|---|---|---|
| Авторизованная семантика и компилятор | Управлять авторизованной семантикой и производить скомпилированные артефакты времени выполнения | Состояние авторизованного графа, входы компилятора, доказательства валидации | Авторизованный снимок, скомпилированный пакет, квитанции происхождения | Отвечает за семантический смысл, тогда как выполнение запроса остается ниже по цепочке |
| Доказательства релиза и развертывания | Идентифицировать ограниченный набор исполнения, принятый для развертывания, воспроизведения и рецензирования | Скомпилированные артефакты, квитанции, выбор развертывания, доказательства рецензента | Ссылки релиза и развертывания, дайджесты манифеста, идентификатор принятого пакета | Устанавливает контекст развертывания, тогда как изменения семантики остаются управляемыми выше по цепочке |
| Хост сервиса | Отвечать за транспорт, декодирование, выбор источника, проверку схемы и дайджеста, секреты, внешнюю проекцию, материализацию времени выполнения и жизненный цикл сервиса | Выпущенный пакет, конфигурация развертывания, входы нормализованного запроса | Представление каталога времени выполнения, нормализованный запрос, спроецированные доказательства | Отвечает за операционную интеграцию, тогда как клинические вычисления остаются внутри границы времени выполнения |
| Детерминированное вычислительное ядро | Выполнять один нормализованный запрос по неизменяемому каталогу в памяти | Представление каталога времени выполнения, нормализованный запрос, конфигурация времени выполнения, ссылки на термины времени выполнения | Владеющий ответ, детерминированный хеш, доказательства в пределах запроса со ссылками на термины времени выполнения | Отвечает за вычисление без сохранения состояния, тогда как авторизованная семантика остается вне библиотеки |
| Детерминированное ядро безопасности | Обеспечивать допустимость выполнения, управляющие шлюзы, проверки привязок, область действия модуля и поведение по политике «при ошибке — стоп» | План движка, контекст запроса, зафиксированные факты, ссылки на политики | Решения run/skip/degrade/abort/fail-closed, управляющие факты, структурированные отказы | Отвечает за шлюзы управления рисками без сохранения состояния; применение команды с участием человека в контуре остается задачей анализатора с сохранением состояния |
| Поверхность аудита | Сохранять долговечные доказательства для пригодности к выполнению аудита и реконструкции | Решения выполнения, ссылки ответа, ссылки контекста времени выполнения, материал аудита | События аудита, ссылки аудита и неотменяемые записи аудита при долговечной публикации | Долговечный аудит остается отличным от диагностической трассы |
| Поверхность трассы отладки | Объяснять выполнение в пределах запроса для диагностики и сравнения повторных прогонов | Управляющие решения, проверки контрактов, ссылки узлов плана | События отладки со стабильными идентификаторами, кодами причин и безопасными полезными данными | Диагностическая трасса остается отделенной от сырых ПнД, полезных данных сигналов и секретов |
| Хосты потокового анализатора и анализатора без сохранения состояния | Размещать нижестоящие операционные контуры поверх библиотеки времени выполнения | Библиотека времени выполнения, контекст развертывания, потоковый вход или вход в пределах одного запроса | Поведение и доказательства, специфичные для анализатора | Принадлежит нижестоящим системным статьям, а не этой статье |
Детерминированное вычислительное ядро
Детерминированное вычислительное ядро является подсистемой детерминированного выполнения. Оно валидирует каталог времени выполнения в памяти, выводит неизменяемый план выполнения, принимает один нормализованный запрос, создает изменяемое состояние в пределах запроса, выполняет работу в детерминированном порядке, фиксирует отложенные факты только на барьерах видимости, собирает владеющий ответ и выпускает детерминированные доказательства.
Ключевой принцип проектирования состоит в разделении общего неизменяемого состояния движка и изменяемого состояния в пределах запроса. Неизменяемый вычислительный движок можно повторно использовать между запросами, потому что он содержит данные плана, производные от каталога, логические ключи порядка, метаданные привязок, шаблоны аудита, шаблоны отладки и управляющие метаданные. Контекст запроса содержит рабочие данные, отложенные записи, снимки зафиксированных фактов, буферы аудита, буферы отладки, управляющие факты и хранилище, принадлежащее ответу. Изменяемое клиническое состояние не переходит из одного запроса в следующий.
Планирование является детерминированным. Порядок выполнения выводится из порядка уровней, ярусов расписания, зависимостей и стабильных логических ключей. Наблюдаемый порядок выходов, последовательность аудита, последовательность отладки и хеш ответа не должны зависеть от настенного времени, идентификатора потока, порядка очереди, адреса указателя или итерации по хеш-таблице. Будущая оптимизация или параллельное выполнение могут быть допущены только если они сохраняют те же зафиксированные факты, порядок аудита, порядок отладки и хеш ответа для того же запроса, каталога и конфигурации.
Ссылки на термины времени выполнения переносятся как доказательственные идентификаторы, а не интерпретируются как авторизованная семантика. Вычислительное ядро может сохранять эти скомпилированные идентификаторы через валидацию каталога, выполнение запроса, сборку ответа, материал аудита, трассу отладки и проекцию доказательств выполнения. Оно не объединяет их с реестром или трассой во время выполнения; такое диагностическое объединение принадлежит сопутствующей методике трассируемости терминов.
Отложенные записи являются центральной частью контракта вычислительного ядра. Исполняемые единицы не записывают напрямую в снимок зафиксированных фактов. Они помещают записи в буферы в пределах запроса, затем барьерная фиксация детерминированно объединяет отложенные записи. Нижестоящие единицы видят только зафиксированные факты. Пути пропуска, отмены, деградации и прерывания отбрасывают или сохраняют отложенные записи только согласно объявленной политике и правилам доказательств.
Детерминированное ядро безопасности
Детерминированное ядро безопасности является подсистемой управления во время выполнения. Оно допускает или отклоняет работу, применяет шлюзы времени выполнения и записывает, почему путь был выполнен, пропущен, деградировал, прервался или завершился отказом по политике «при ошибке — стоп». Его ответственность включает разрешение привязок, проверку предварительных условий, применимость по возрасту, полу и контексту, область действия модуля и лицензии, валидацию зависимостей, валидацию ярусов расписания, управляющий поток правил и условий, видимость отложенных записей, выпуск управляющих фактов и решения сборки ответа.
Его поток решений явный. Входами являются план движка, контекст запроса, зафиксированные факты, область действия модуля и лицензии, метаданные привязок и объявленные политики. Шлюзы проверяют доступность привязок, предварительные условия, применимость, область действия модуля, согласованность расписания, объявленные чтения и записи и обязательства по доказательствам. Результирующий класс решения является одним из run, skip, degrade, abort или fail closed. Каждое решение выпускает управляющие факты и доказательства отладки, связывается с аудитом, когда требуется событие аудита, и ограничивает сборку ответа так, чтобы ответ показывал, завершился ли запрос нормально, деградировал по объявленной политике, был прерван или завершился отказом по политике «при ошибке — стоп».
Детерминированное ядро безопасности является поверхностью управления рисками во время выполнения [2], а не клиническим валидатором. Оно может показать, что запрос выполнялся в пределах объявленных контрактов времени выполнения, что неподдерживаемые условия были отклонены или деградировали, что замещающие тела медицинских алгоритмов не выпускали клинических фактов и что управляющие решения были отражены в доказательствах. Клиническая эффективность, диагностические пороги и продуктовые утверждения требуют отдельных медицинских, валидационных, качественных и управленческих доказательств.
Роль ядра безопасности в этой статье — допустимость без сохранения состояния. Нижестоящий анализатор с сохранением состояния может переиспользовать управление ядра безопасности для применения команд, акцептованных человеком, в контуре с участием человека, но этот путь не является частью обычного анализа без сохранения состояния и не превращает библиотеку времени выполнения в субъект человеческого решения.
Поведение по политике «при ошибке — стоп» является поведением ядра безопасности по умолчанию при нарушениях целостности и допустимости. Управляемая деградация уже: она разрешена только тогда, когда объявленная политика в валидированном каталоге времени выполнения или конфигурации времени выполнения, привязанной к релизу, допускает ограниченный деградированный ответ, а деградированное состояние видно в метаданных ответа, управляющих фактах, ссылках аудита, когда они применимы, и доказательствах отладки. Необъявленная деградация не является альтернативой выполнению с политикой «при ошибке — стоп». Когда каталог времени выполнения имеет неправильную форму, зависимость не разрешена, обязательная привязка неизвестна, требуемое клиническое тело недоступно, запрос нарушает ограничения формы или обязательные доказательства отсутствуют, система отказывается от частичного авторитетного вывода и вместо этого выпускает структурированную диагностику.
Детерминированное вычислительное ядро и детерминированное ядро безопасности внутри библиотеки времени выполнения
Рисунок 2. Детерминированное вычислительное ядро и детерминированное ядро безопасности внутри библиотеки времени выполнения. Диаграмма разделяет построение неизменяемого движка, выполнение без сохранения состояния в пределах запроса, шлюзы ядра безопасности, отложенные записи, барьерные фиксации, сборку ответа и выпуск доказательств.
Рисунок 2 получает валидированное представление каталога времени выполнения от хоста сервиса. Библиотека времени выполнения строит по этому каталогу неизменяемый вычислительный движок и создает контекст без сохранения состояния для одного вызова. Ядро безопасности проверяет привязки, предварительные условия, применимость, область действия модуля и объявленные управляющие политики до запуска детерминированных вычислительных шагов. Вычислительные шаги помещают записи в буферы в пределах запроса. Барьерные фиксации делают отложенные факты видимыми в детерминированном порядке, после чего сборка ответа создает владеющий ответ и детерминированный хеш. Если шлюз отклоняет выполнение, ядро безопасности выпускает доказательства пропуска, деградации, прерывания или отказа по политике «при ошибке — стоп» вместо допуска частичного или неподдерживаемого вывода.
Граница хоста сервиса / библиотеки времени выполнения
Хост сервиса отвечает за все, что зависит от операционной среды. Он выбирает выпущенный пакет согласно доказательствам развертывания, проверяет доказательства дайджеста и схемы [6,7], читает файлы при необходимости, управляет сетевым входом, отвечает за безопасность транспорта, владеет секретами, декодирует внешние полезные данные, нормализует запросы и проецирует выходы времени выполнения в каналы аудита, отладки, результатов, метрик или доказательств. Он выбирает и проверяет выпущенный пакет, но не владеет семантическим смыслом или выполнением в памяти. Он может размещать потоковые или пакетные контуры, но эти контуры являются нижестоящими вопросами.
Библиотека вычислительного ядра времени выполнения отвечает только за выполнение в памяти. Она получает материализованное представление каталога времени выполнения и нормализованный запрос, валидирует допустимость каталога для своего контракта выполнения, создает или использует неизменяемый вычислительный движок, выполняет анализ без сохранения состояния и возвращает владеющий ответ вместе с доказательствами в пределах запроса. Доступ к среде, выбор источника и обработка учетных данных остаются ответственностью хоста сервиса.
Эта граница предотвращает расползание семантического владения. Если бы библиотека времени выполнения выбирала или аутентифицировала собственный источник авторизованной семантики, она стала бы конкурирующей поверхностью авторизации. Если бы хост сервиса создавал клинические факты вне вычислительного ядра, детерминированные доказательства выполнения фрагментировались бы. Граница удерживает хост ответственным за операционную интеграцию, а библиотеку времени выполнения - за детерминированное выполнение запроса.
Доказательства анализа без сохранения состояния
Текущий срез доказательств поддерживает утверждение об анализе без сохранения состояния, а не утверждение о продуктовом клиническом покрытии. Он показывает реализованный артефакт библиотеки вычислительного ядра, детерминированное встроенное выполнение, состояние в пределах запроса, поведение неизменяемого движка, алгоритмы плоскости управления, замещающие тела медицинских алгоритмов, которые намеренно не выпускают клинических фактов, трассу отладки, доказательства аудита и управления и одно продвинутое нейтральное с точки зрения безопасности тело длительности сигнала.
Ограниченная цепочка доказательств намеренно узкая. Реализованный артефакт библиотеки принимает материализованный каталог времени выполнения, валидирует допустимость каталога, создает или переиспользует неизменяемый вычислительный движок, выполняет один нормализованный запрос через анализ без сохранения состояния, создает отложенные записи, фиксирует их на барьере, выпускает доказательства отладки и аудита, проецирует доказательства выполнения и задействует нейтральное с точки зрения безопасности тело длительности сигнала. Эта цепочка поддерживает утверждение об архитектуре времени выполнения, оставляя готовность к производственной эксплуатации, клиническое покрытие и доказательство цепочки релиза вне области статьи.
Тело длительности сигнала намеренно скромное. Оно демонстрирует управляемую привязку тела, объявленные записи, детерминированное выполнение и выпуск доказательств для нейтрального с точки зрения безопасности примитива. Оно не валидирует диагностическую интерпретацию ЭКГ, классификацию ритма, выявление ишемии, клиническую достаточность или диагностическое покрытие уровня продукта.
Остаточные разрывы остаются видимыми. Покрытие тел клинических алгоритмов ограничено. Покрытие производственными фикстурами, доказательства безопасности памяти и обнуления, формальная клиническая валидация, более широкие доказательства развертывания и доказательства будущей оптимизации или параллельного выполнения находятся вне текущего утверждения об анализе без сохранения состояния. Поэтому статья рассматривает доказательства реализации как ограниченные и ориентированные на рецензента.
Таблица 2: Доказательства анализа без сохранения состояния и остаточные разрывы
Таблица 2. Доказательства анализа без сохранения состояния и остаточные разрывы
| Элемент доказательств | Текущее утверждение | Значение для рецензента | Остаточный разрыв |
|---|---|---|---|
| Реализованный артефакт библиотеки вычислительного ядра | Существует артефакт библиотеки времени выполнения для детерминированного выполнения вычислительного ядра | Статья подтверждена реализацией, а не только концептуальна | Не демонстрирует готовность к производственному развертыванию |
| Неизменяемый вычислительный движок | Состояние движка выводится из каталога времени выполнения и совместно используется между запросами | Изменяемое клиническое состояние между запросами находится вне движка | Требуются продолжающиеся тесты соответствия по мере расширения формы каталога |
| Состояние в пределах запроса | Рабочие данные, отложенные записи, зафиксированные факты, буферы аудита, буферы отладки и хранилище ответа ограничены запросом | Анализ без сохранения состояния ограничен одним нормализованным запросом | Доказательства безопасности памяти, утечек и обнуления должны созреть для производственных утверждений |
| Детерминированный порядок | Порядок уровней, ярусов, зависимостей и логических ключей управляет порядком ответа, аудита и отладки | Сравнение повторных прогонов может отличить изменения поведения от шума планирования | Будущая оптимизация или параллелизм требуют доказательств эквивалентности |
| Шлюзы ядра безопасности | Привязка, предварительные условия, применимость, область действия модуля, пропуск, деградация, прерывание и решения fail-closed доказаны | Неподдерживаемые пути выполнения могут быть отклонены или объяснены | Покрытие шлюзов должно расти вместе с реальными клиническими телами |
| Замещающие тела медицинских алгоритмов | Замещающие тела валидируют контракты и поведение доказательств без клинических выходов | Управление временем выполнения можно тестировать до завершения клинических тел | Из замещающих тел не заявляется клиническое диагностическое покрытие |
| Нейтральное с точки зрения безопасности тело длительности сигнала | Один продвинутый примитив демонстрирует привязку тела, объявленные записи и детерминированные доказательства | Демонстрирует путь времени выполнения для реального тела | Не валидирует более широкую интерпретацию ЭКГ |
| Доказательства аудита и отладки | Поверхности аудита и отладки записывают поведение времени выполнения с различной ответственностью | Рецензенты могут отделить долговечный аудит от диагностической трассы | Трасса отладки не должна рассматриваться как реконструированный аудит |
Доказательства, аудит и трасса отладки
Доказательства выполнения имеют несколько поверхностей, потому что одна поверхность не может безопасно выполнять все задачи. Библиотека времени выполнения выпускает детерминированный материал аудита во время сборки ответа. Хост сервиса или поверхность аудита публикует этот материал в долговечную инфраструктуру аудита, где он может стать неотменяемой записью аудита согласно контракту добавления записей, дайджестов и хранения в конкретном развертывании. Трасса отладки является диагностическим доказательством в пределах запроса для сравнения повторных прогонов, проверок контрактов, кодов причин, управляющих решений и объяснений отсутствия вывода. Проекция доказательств выполнения нормализует эти и другие наблюдаемые поверхности в нижестоящие артефакты доказательств.
Трасса отладки дополняет аудит, но не заменяет его. Когда событие аудита существует, трасса отладки может нести стабильные ссылки на него. Если событие аудита или ссылка на аудит отсутствует, хост сервиса и нижестоящие инструменты не должны реконструировать их из трассы отладки. Это правило сохраняет целостность аудита и предотвращает незаметное превращение диагностических деталей в авторитет. Словарь доказуемого происхождения данных и практика структурированных событий аудита задают различие между цепочкой происхождения доказательств и артефактом, который несет конкретную запись аудита [4,5].
Полезные данные доказательств должны быть ограничены с точки зрения приватности и безопасности. Трасса отладки может содержать стабильные идентификаторы, имена контрактов, ссылки на дескрипторы или правила, ссылки на дайджесты, коды причин, счетчики, решения планирования и управляющие решения. Она не должна содержать сырые выборки сигналов, сырые поля ПнД, имена пациентов, секреты, TLS-материалы, учетные данные брокеров сообщений, материалы аппаратных ключей, сырые полезные данные запроса или файловые пути, раскрывающие секреты.
Семантика политики «при ошибке — стоп»
Выполнение с политикой «при ошибке — стоп» не позволяет частичному или неподдерживаемому поведению выглядеть как корректный клинический вывод. Ядро безопасности останавливается по этой политике, когда невозможно установить целостность времени выполнения, допустимость каталога, форму запроса, доступность обязательной привязки, управляющие доказательства или обязательства трассировки. Управляемая деградация используется только для объявленных, ограниченных политических путей, чье деградированное состояние видно поверхностям ответа, аудита и отладки. Результат с отказом по политике «при ошибке — стоп» остается полезным доказательством: он объясняет, почему запрос не произвел нормальный ответ, и дает диагностическим поверхностям достаточно структуры для разбора.
Таблица 3. Карта условий политики «при ошибке — стоп»
| Условие | Этап обнаружения | Поведение времени выполнения | Выпущенные доказательства | Значение для рецензента |
|---|---|---|---|---|
| Несоответствие схемы или дайджеста каталога | Проверка хостом сервиса или валидация каталога времени выполнения | Отклонить основу времени выполнения | Структурированная ошибка запуска или каталога, ссылки аудита/отладки при наличии | Проблема релиза, развертывания или целостности артефакта |
| Дублирующийся идентификатор | Валидация каталога времени выполнения | Отклонить создание движка | Диагностика дублирующегося идентификатора | Проекция каталога недопустима |
| Неразрешенная зависимость | Валидация плана движка | Отклонить создание движка | Диагностика зависимости | Скомпилированный граф выполнения неполон |
| Цикл зависимостей | Валидация плана движка | Отклонить создание движка | Диагностика цикла | Порядок выполнения не может быть детерминированным |
| Недопустимый ярус расписания | Валидация плана движка | Отклонить создание движка | Диагностика яруса расписания | Контракт порядка времени выполнения имеет неправильную форму |
| Неизвестная привязка | Разрешение привязки ядром безопасности | Отказ по политике «при ошибке — стоп», когда привязка обязательна; управляемая деградация только по объявленной политике | Диагностика привязки, управляющий факт | Время выполнения не может диспетчеризовать объявленную исполняемую единицу, если политика явно не ограничивает деградированный путь |
| Требуемое клиническое тело недоступно | Разрешение привязки ядром безопасности | Отказ по политике «при ошибке — стоп» для затронутого пути выполнения | Диагностика отсутствия вывода или недоступного тела | Утверждение о клиническом выходе заблокировано |
| Недопустимая форма запроса | Валидация запроса | Отклонить запрос или прервать выполнение | Диагностика формы запроса | Вход недопустим для анализа без сохранения состояния |
| Отсутствующее обязательное событие отладки | Валидация доказательств | Пометить доказательства выполнения как неполные или отказать запросу согласно политике | Диагностика разрыва трассы отладки | Доказательства повторного прогона и покрытия неполны |
Рабочий пример времени выполнения
Рассмотрим нейтральный с точки зрения безопасности примитив длительности сигнала. Скомпилированный пакет содержит строку каталога времени выполнения для тела длительности сигнала, ссылки на термины времени выполнения для скомпилированной идентичности, участвующей в запросе, объявленную запись в факт качества, представляющий длительность сигнала в миллисекундах, управляющие метаданные, шаблоны аудита, шаблоны отладки и метаданные привязки. Доказательства релиза и развертывания идентифицируют выбранный пакет, а хост сервиса проверяет доказательства схемы и дайджеста перед материализацией представления каталога времени выполнения.
Библиотека вычислительного ядра времени выполнения получает представление каталога и нормализованный запрос. При создании движка вычислительное ядро валидирует идентификатор каталога, порядок зависимостей, метаданные ярусов расписания, объявленные чтения и записи, доступность привязок и требования к шаблонам отладки/аудита. Неизменяемый вычислительный движок записывает детерминированный план. Данные запроса в этом движке не сохраняются.
Во время выполнения запроса без сохранения состояния контекст запроса содержит входящие метаданные сигнала, снимок зафиксированных фактов, буфер отложенных записей, буфер аудита, буфер отладки и хранилище, принадлежащее ответу. Ядро безопасности допускает примитив длительности сигнала только если его предварительные условия, область действия модуля и контракт привязки выполнены. Если применим объявленный путь управляемой деградации, ответ записывает это состояние; иначе нарушения целостности и допустимости приводят к отказу по политике «при ошибке — стоп». Детерминированный вычислительный шаг вычисляет примитив длительности, помещает объявленный факт качества в отложенную запись и выпускает события отладки для старта, проверки входного контракта, проверки выходного контракта и завершения. На барьере отложенная запись фиксируется в детерминированном порядке.
Сборка ответа читает зафиксированные факты и производит владеющий ответ с метаданными выполнения, состоянием деградации при наличии, ссылками на термины времени выполнения, материалом аудита, трассой отладки и детерминированным хешем. Хост сервиса публикует материал аудита через поверхность аудита и проецирует ответ, ссылки аудита и ссылки отладки в нижестоящие доказательства выполнения. Этот пример демонстрирует путь времени выполнения для нейтрального с точки зрения безопасности примитива: привязку скомпилированного каталога, планирование неизменяемого движка, выполнение запроса без сохранения состояния, отложенную запись и барьерную фиксацию, детерминированную сборку ответа и проекцию доказательств. Он не валидирует синусовый ритм, ишемию, морфологию или любое более широкое диагностическое заключение ЭКГ.
Цепочка доказательств для запроса без сохранения состояния
Рисунок 3. Цепочка полезных данных доказательств для запроса без сохранения состояния. Диаграмма прослеживает один нормализованный запрос от идентификатора запроса, отпечатка конфигурации и дайджеста выбранного пакета через выполнение без сохранения состояния, хеширование ответа, доказательства аудита и отладки, ссылки на термины времени выполнения, проекцию доказательств выполнения и передачу в диагностический контур.
Рисунок 3 фокусируется на полезных данных доказательств одного запроса, а не на полном потоке владения жизненным циклом. Цепочка начинается с идентификатора запроса, отпечатка конфигурации и дайджеста выбранного пакета. Хост сервиса превращает внешний вход в нормализованный запрос и материализует представление каталога времени выполнения. Библиотека вычислительного ядра создает или переиспользует неизменяемый движок, а затем создает контекст в пределах запроса для анализа без сохранения состояния. Решения ядра безопасности определяют, какие вычислительные шаги могут выполняться, пропускаться, деградировать, прерываться или завершаться отказом по политике «при ошибке — стоп». Сборка ответа производит детерминированный хеш ответа, ссылки на термины времени выполнения, материал аудита и трассу отладки. Затем хост сервиса проецирует ссылки аудита, ссылки отладки, хеши ответа и ссылки на термины времени выполнения в доказательства выполнения и, при необходимости, передает доказательства в диагностический контур.
Ограничения и отсутствия утверждений
Эта статья не делает утверждения о клинической эффективности и не делает утверждения о валидации уровня регистрационного досье. Она не утверждает автономную диагностику, полное покрытие алгоритмов ЭКГ, готовность к полному производственному развертыванию или закрытие полного продуктового обоснования безопасности. Она не утверждает, что библиотека вычислительного ядра времени выполнения выбирает, загружает, авторизует или аутентифицирует авторизованную семантику. Она не утверждает, что библиотека времени выполнения читает файлы, получает доступ к сети, использует брокеры сообщений, обрабатывает секреты или владеет доказательством цепочки релиза.
Детерминированное ядро безопасности является механизмом допустимости и доказательств времени выполнения, а не заменой клинической валидации, одобрения системы качества или утверждения управления рисками. Нейтральный с точки зрения безопасности пример длительности сигнала демонстрирует ограниченный путь времени выполнения, а не диагностическую достаточность. Трасса отладки является диагностическим доказательством, а не неотменяемым аудитом, и она не должна раскрывать сырые полезные данные сигналов, сырые ПнД, учетные данные или пути, несущие секреты.
Пакетный и потоковый хостинг являются нижестоящими вопросами. Эта статья определяет границу библиотеки времени выполнения, которую такие хосты могут использовать; она не утверждает масштабируемость хоста сервиса, потоковое планирование, пакетную оркестрацию или непрерывность цепочки релиза.
Заключение
Детерминированное вычислительное ядро и детерминированное ядро безопасности образуют связующее звено времени выполнения между скомпилированным исполняемым знанием и выполнением, пригодным к аудиту. Вычислительное ядро превращает неизменяемый каталог времени выполнения и один нормализованный запрос в детерминированный анализ без сохранения состояния. Ядро безопасности управляет допустимостью выполнения, поведением по политике «при ошибке — стоп» и доказательствами. Вместе они сохраняют отдельные полномочия семантики, релиза, хоста и времени выполнения, предоставляя рецензентам достаточно доказательств, чтобы понять, что выполнялось, почему оно выполнялось, что было отклонено и что остается вне текущего утверждения.
Авторская основа
Статья опирается на внутреннюю документацию проекта HealthOS: спецификации, схемы и реестры, задающие авторизованную семантику и её скомпилированную форму, на среду выполнения и инструменты, дающие доказательства выполнения, и на смежные статьи серии, объединённые общим каноном терминологии. Это рабочие источники, которые обосновывают инженерные решения и удерживают единство терминологии в серии. Они остаются внутренней авторской основой, а не публичными ссылками, и не приводятся как ссылки на репозиторий в тексте.
Конфликт интересов
Рукопись описывает реализацию определенного аспекта платформы HealthOS, а именно: границы библиотеки времени выполнения для вычислительного ядра и ядра безопасности.
Финансирование
Финансирование работ со стороны РТЛАБ.
Литература
- IEC 62304:2006/AMD 1:2015, Medical device software - Software life cycle processes. International Electrotechnical Commission.
- ISO 14971:2019, Medical devices - Application of risk management to medical devices. International Organization for Standardization.
- ISO 13485:2016, Medical devices - Quality management systems - Requirements for regulatory purposes. International Organization for Standardization.
- T. Lebo, S. Sahoo, and D. McGuinness, eds., PROV-O: The PROV Ontology. W3C Recommendation, 2013. https://www.w3.org/TR/prov-o/
- HL7 International, FHIR Resource AuditEvent, Release 4. https://hl7.org/fhir/R4/auditevent.html
- A. Rundgren, B. Jordan, and S. Erdtman, JSON Canonicalization Scheme (JCS). RFC 8785, 2020. https://www.rfc-editor.org/rfc/rfc8785
- JSON Schema, Draft 2020-12. https://json-schema.org/draft/2020-12