Что такое критический момент времени (critical instant) в контексте анализа

Soft

Firm

Hard

Missing a deadline is a total system failure.

Infrequent deadline misses are tolerable, but may degrade the system's quality of service. The usefulness of a result is zero after its deadline.

The usefulness of a result degrades after its deadline, thereby degrading the system's quality of service.

Firm СРВ является одним из классов систем реального времени. Firm СРВ терпима к редким невыполнениям дедлайна (в отличие от систем жесткого (hard) реального времени, в которых срыв дедлайна приводит к прекращению работы системы), но это может привести к потери качества услуг. Результат вычислений после дедлайна не представляет абсолютно никакой ценности.

163. Что определяет стандарт ARINC 653?

Стандарт разработан компанией ARINC (Aeronautical Radio, Inc.) в 1997 г. и определяет универсальный программный интерфейс APEX (Application/Executive) между ОС авиационного компьютера и прикладным ПО.

Стандарт требует, чтобы ОС РВ обеспечивали многоуровневое разделение (виртуализацию) вычислительного времени, памяти и периферийных ресурсов между приложениями при работе на однопроцессорной плате.

Одно из основных требований — архитектура изолированных виртуальных машин (MILS). Разделы (partitions) должны жестко изолироваться друг от друга с точки зрения используемого процессорного времени и оперативной памяти

164. Сколько категорий отказов ПО РВ предусматривает стандарт DO-178? В чём различие ПО разных категорий с точки зрения разработчика ПО?

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

ñ уровень A - ПО должно обеспечивать защиту от сбоев, приводящих к катастрофическим (catastrophic) последствиям;

ñ уровень B - опасным (hazardous) последствиям;

ñ уровень C - серьезным (major) последствиям;

ñ уровень D - незначительным (minor) последствиям;

ñ уровень E - не приводящих ни к каким последствиям.

165. Для какой сферы применения разрабатывались стандарты DO-178 и ARINC 653?

Военная и аэрокосмическая отрасли предъявляют жесткие требования к вычислительным средствам, влияющим на степень безопасности целевой системы. В настоящее время имеются следующие стандарты для ОСРВ в авиации – стандарт DO-178B и стандарт ARINC-653.(В 2003 г. принята новая редакция этого стандарта. ARINC-653 в качестве одного из основных требований для ОСРВ в авиации вводит архитектуру изолированных (partitioning) виртуальных машин)

LynxOS-178 - коммерческая ОСРВ для авиации.

166. Что означает акроним EAL в стандарте “Common Criteria”?

“Common Criteria” – стандарт, описывающий общие критерии для оценки безопасности информационных технологий.

В нем описаны процедуры для безопасного ПО.

EAL – уровни для оценки безопасности продукта. Чем выше уровень, тем выше безопасность.

· EAL1 – минимальная конфигурация;

· EAL2 – средний уровень защиты;

· EAL3 – хороший уровень, не прибегая к переработке системы;

· EAL4 – высокий уровень и доработка ОС.

167. Что определяет стандарт ГОСТ Р 51904?

ГОСТ Р 51904-2002. Настоящий стандарт распространяется на процессы разработки и документирования программного обеспечения (ПО) встроенных систем реального времени. Стандарт распространяется на все действия, имеющие отношение к разработке программного обеспечения.

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

168. Что такое Time Demand Analysis?

Метод Time Demand Analysis (TDA (Анализ требования времени)) позволяет получить оценку способности к планированию в системах реального времени с фиксированными приоритетами.

Функция требования времени

Функция требования времени w_i(t), представляет собой максимальное процессорное время, требуемое как задачей J_i1, так и всеми задач, что завершились до J_i1, и обозначается как функция от времени t с момента запуска J_i1.

169. Что такое фаза задачи?

Время запуска первой работы задачи.

или

Фаза задачи – задача в первый раз переходит в состояние готовности.

Время завершения этой работы называется critical instant задачи Ti. Что бы определить все ли работы встречают свои дедлайны, нам необходимо проследить что бы работа в Ti завершилась в critical instant

планируемости задач по RMA и какую роль он играет в доказательстве возможности

планирования?

ЧМА Теорема 1A Для набора N независимых периодических задач, где Ci, Ti, и Bi, i = 1,2.... N,, являются временем выполнения, периодом и временем блокировки в самом плохом случае, соответственно, а критический срок выполнения равняется периоду задачи, задачи диспетчируемы согласно ЧМА, если следующее условие выполняется:

Более простое достаточное условие можно получить из вышеупомянутого набора неравенств. Его преимущество состоит в том, что оно содержит только одно, а не N неравенств.

ЧМА Теорема 2A

Для набора N независимых периодических задач, где Ci, Ti, и Bi, i= 1,2,.... N, являются временем выполнения, периодом, и временем блокировки в наихудшем случае соответственно, а критический срок выполнения равняется периоду задачи, задачи диспетчируемы согласно ЧМА, если следующее условие выполняется:

,

где минимум рассчитан как (k, l) Wi, и

Обратите внимание, это только достаточное условие, потому что значения Bi представляют собой время блокировки в самом плохом случае. Практически, некоторые из этих неравенств не могут быть выполнены, а набор задач может быть все еще диспетчируем, потому что фактические времена блокирования короче. Эмпирическое правило, данное в секции “Необходимое и достаточное условие для диспетчеризации с помощью ЧМА ” может быть использовано, если включить в него Bi.

171. Как называется международный стандарт, которому соответствует ГОСТ Р 15408?

Национальный стандарт безопасности ГОСТ/ИСО МЭК 15408 "Общие критерии оценки безопасности информационных технологий"

В 1999 г. Международная Организация по Стандартизации (ISO) приняла международный стандарт ISO 15408 под названием Общие критерии оценки безопасности ИТ (Common Criteria for Information Technology Security Evaluation или сокращенно - Common Criteria). Внушительных размеров тома Common Criteria содержат обобщенное формализованное представление знаний и опыта, накопленного в области обеспечения информационной безопасности на протяжении десятилетий.

172. Какой семитомный стандарт определяет комплекс требований к разработке ПО программно-аппаратных систем, связанных с безопасностью?

ГОСТ Р 15408

Стандарты безопасности

В связи со стандартами для ОСРВ стоит отметить широко известный стандарт критериев оценки пригодности компьютерных систем (Trusted Computer System Evaluation Criteria – TCSEC) [DoD85]. Этот стандарт разработан Министерством обороны США и известен также под названием "Оранжевая книга" (Orange Book – из-за цвета обложки).

В ряде других стран были разработаны аналогичные критерии, на основе которых был создан международный стандарт “Общие критерии оценки безопасности информационных технологий” (далее просто – Общие критерии) (Common Criteria for IT Security Evaluation, ISO/IEC 15408) [CC99].

В "Оранжевой книге" перечислены семь уровней защиты:

• А1 – верифицированная разработка. Этот уровень требует, чтобы защиту секретной и другой критичной информации средствами управления безопасностью гарантировали методы формальной верификации.

• В3 – домены безопасности. Этот уровень предназначен для защиты систем от опытных программистов.

• В2 – структурированная защита. В систему с этим уровнем защиты нельзя допустить проникновение хакеров.

• В1 – мандатный контроль доступа. Защиту этого уровня, возможно, удастся преодолеть опытному хакеру, но никак не рядовым пользователям.

• С2 – дискреционный контроль доступа. Уровень С2 обеспечивает защиту процедур входа, позволяет производить контроль за событиями, имеющими отношение к безопасности, а также изолировать ресурсы.

• С1 – избирательная защита. Этот уровень дает пользователям возможность защитить личные данные или информацию о проекте, установив средства управления доступом.

• D – минимальная защита. Этот нижний уровень защиты оставлен для систем, которые проходили тестирование, но не смогли удовлетворить требованиям более высокого класса.

Что касается Общих критериев, то в них введены похожие требования обеспечения безопасности в виде оценочных уровней (Evaluation Assurance Levels – EAL). Их также семь:

• EAL7 – самый высокий уровень предполагает формальную верификацию модели объекта оценки. Он применим к системам очень высокого риска.

• EAL6 определяется, как полуформально верифицированный и протестированный. На уровне EAL6 реализация должна быть представлена в структурированном виде, анализ соответствия распространяется на проект нижнего уровня, проводится строгий анализ покрытия, анализ и тестирование небезопасных состояний.

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

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

• EAL3 определяется, как методически протестированный и проверенный. На уровне EAL3 осуществляется более полное, чем на уровне EAL2, тестирование покрытия функций безопасности, а также контроль среды разработки и управление конфигурацией объекта оценки.

• EAL2 определяется, как структурно протестированный. Он предусматривает создание описательного проекта верхнего уровня объекта оценки, описание процедур инсталляции и поставки, руководств администратора и пользователя, функциональное и независимое тестирование, оценку прочности функций безопасности, анализ уязвимостей разработчиками.

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

173. Какие функции выполняет микроядро ОСРВ QNX Neutrino?

В QNX Микроядро выполняет две важнейшие функции:

• передача сообщений - Микроядро обеспечивает маршрутизацию всех сообщений между всеми процессами в системе;

• диспетчеризация - планировщик - это часть Микроядра, и он получает управление всякий раз, когда процесс изменяет свое состояние в результате получения сообщения или прерывания.

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

174. В чём различие между процессом и потоком в ОСРВ QNX Neutrino?

Различие между процессами и потоками

С помощью процессов можно организовать параллельное выполнение программ. Для этого процессы клонируются вызовами fork() или exec(), а затем между ними организуется взаимодействие средствами IPC. Это довольно дорогостоящий в отношении ресурсов процесс.

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

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

1. Процесс располагает определенными ресурсами. Он размещен в некотором виртуальном адресном пространстве, содержащем образ этого процесса. Кроме того, процесс управляет другими ресурсами (файлы, устройства ввода / вывода и т.д.).

2. Процесс подвержен диспетчеризации. Он определяет порядок выполнения одной или нескольких программ, при этом выполнение может перекрываться другими процессами. Каждый процесс имеет состояние выполнения и приоритет диспетчеризации.

Если рассматривать эти характеристики независимо друг от друга (как это принято в современной теории ОС), то:

• владельцу ресурса, обычно называемому процессом или задачей, присущи:

o виртуальное адресное пространство;

o индивидуальный доступ к процессору, другим процессам, файлам, и ресурсам ввода - вывода.

• Модулю для диспетчеризации, обычно называемому потоком или облегченным процессом, присущи:

o состояние выполнения (активное, готовность и т.д.);

o сохранение контекста потока в неактивном состоянии;

o стек выполнения и некоторая статическая память для локальных переменных;

o доступ к пространству памяти и ресурсам своего процесса.

Все потоки процесса разделяют общие ресурсы. Изменения, вызванные одним потоком, становятся немедленно доступны другим.

При корректной реализации потоки имеют определенные преимущества перед процессами. Им требуется:

• меньше времени для создания нового потока, поскольку создаваемый поток использует адресное пространство текущего процесса;

• меньше времени для завершения потока;

• меньше времени для переключения между двумя потоками в пределах процесса;

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

175. Кто такой С. Зыль?

Сергей Зыль - автор следующих книг.

Книга "QNX Momentics. Основы применения" (Сергей Зыль)

Книга «Проектирование, разработка и анализ программного обеспечения систем реального времени» (Сергей Зыль)

Книга "ОС реального времени QNX: от теории к практике". 2-е издание. (Сергей Зыль)

176. Кто является автором переводной книги по программированию систем реального времени в среде QNX Neutrino?

Сергей Зыль???

Кёртен, Р. Введение в QNX Neutrino 2: руководство по про-

граммированию приложений реального времени в QNX Realtime Platform/ Р. Кёртен – СПб.: Петрополис, 2001 - 480 с.

- СПб.:БХВ-Петербург, 2005 доп. тираж -400 с.

Дата добавления: 2014-12-24