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

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

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

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

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

Для коммерческих бортовых систем этот процесс описан в ARP 4761 [31]. Одним из первых его шагов является оценка функциональных рисков системы (Functional Hazard Assessment, FHA), в результате которой для системы определяются риски. Затем FHA используется во время предварительной оценки безопасности системы (Preliminary System Safety Assessment, PSSA), чтобы определить, может ли система способствовать реализации какого-либо из этих рисков. Если это так, то PSSA предъявляет требования к безопасности при проектировании производных систем. Например, FHA для системы инкубатора было завершено до определения требований к термостату инкубатора и выявило такой риск:

H1. Длительное воздействие на младенца небезопасного тепла или холода

Классификация: вероятность катастрофы: <10^-9 за час работы

Предварительная оценка безопасности (PSSA) системы инкубатора (не термостата) определяет несколько способов реализации этого риска.

• Термостат может выйти из строя и слишком долго включать или выключать источник тепла.
  
• Датчик температуры может выдавать неправильную температуру на термостат.
  
• Интерфейс пользователя может предоставить термостату неправильный желаемый диапазон температур.
  
• Источник тепла может выйти из строя либо из-за слишком долгого включения или выключения, либо из-за недостаточной подачи тепла для поддержания желаемого температурного диапазона.
  

Дерево неисправностей, полученное в ходе PSSA системы инкубатора, показано на рисунке. Так как каждая функция системы может привести к H1, считаем, что для каждой функции вероятность сбоя должна быть менее 2×10^-10 за час работы.

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

Менее дорогостоящим решением может стать добавление функции мониторинга температуры (отслеживания температуры), которая активирует сигнал тревоги, если текущая температура в инкубаторе падает ниже или поднимается выше безопасного уровня.

Предварительная оценка безопасности системы (PSSA) показывает, что сочетание сигнала тревоги и наблюдения за младенцем со стороны медсестры защитит и от сбоя функции термостата, и от сбоя функции управления источником тепла. Это, однако, не защитит нас от вводящей в заблуждение функций датчика температуры или от неоднозначности пользовательского интерфейса. Сочетание сигнала и наблюдения будет достаточно, если термостат, источник тепла, и монитор будут иметь вероятность выхода из строя менее 10^-5 за час работы.

Итоговое дерево неисправностей, полученное в ходе этой PSSA, показано на рисунке 5.

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

Остальная часть примера будет посвящена функции термостата и функции отслеживания температуры. PSSA приводит к следующим производным требованиям безопасности к этим компонентам:

1. Инкубатор должен иметь независимую функцию термостата, которая поддерживает текущую температуру внутри инкубатора в желаемом диапазоне температур

Обоснование: Желаемый температурный диапазон будет установлен медсестрой в идеальное значение в зависимости от веса и состояния здоровья ребёнка. Термостат должен поддерживать текущую температуру в этом диапазоне при нормальной работе. Допустимая вероятность отказа: <10^-5 в час.

2. Инкубатор должен включать функцию независимого мониторинга (отслеживания температуры), которая активирует сигнал тревоги в течение 5 секунд всякий раз, когда

• Текущая температура внутри инкубатора падает ниже или поднимается выше безопасного диапазона
  
• Текущая температура помечена как недопустимая

Обоснование: Безопасный температурный диапазон устанавливается медсестрой в зависимости от веса и состояния здоровья ребёнка. Младенец должен быть извлечён из инкубатора в течение 15 секунд после того, как текущая температура упадет ниже или поднимется выше безопасного температурного диапазона. При обычном контроле, осуществляемом медсестрой, это может быть выполнено в течение 10 секунд, оставляя системе 5 секунд для активации сигнала тревоги. Желательно активировать сигнализацию за меньшее время.

Допустимая вероятность отказа: <10^-5 в час.

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

После предварительной оценки безопасности системы (PSSA) с учётом этой конструкции, решение было признано приемлемым при условии, что функция отслеживания температуры останется независимой. Чтобы избежать путаницы, функция термостата была переименована в функцию регулирования температуры, и термостат теперь рассматривается как комбинация функции регулирования температуры и функции отслеживания температуры.

Это привело к созданию диаграммы зависимостей верхнего уровня для термостата, как показано на рисунке 6.

На рисунке функциональность термостата была распределена на две функции: «‎Регулирование температуры» и «‎Отслеживание температуры», реализация которых должна быть независимой (то есть каждая функция выходит из строя независимо от другой). Регулировка температуры управляет источником тепла и гарантирует, что текущая температура остается в пределах желаемого температурного диапазона.

Регулятор нагрева активирует сигнал тревоги в пользовательском интерфейсе всякий раз, когда текущая температура опускается ниже или поднимается выше безопасного температурного диапазона.

При рассмотрении измеряемых и изменяемых переменных для этих функций становится очевидным, что границы системы были изменены. Теперь в интерфейсе пользователя есть измеряемая переменная «‎Безопасный температурный диапазон».

Кроме того, «‎Статус термостата» был переименован в «Статус функции регулирования температуры» и была введена новая изменяемая переменная «Статус функции отслеживания температуры». Это необходимо, поскольку общее состояние термостата теперь определяется двумя независимыми функциями. Кроме того, обратите внимание, что отображаемая переменная температуры передается в интерфейс только с помощью функции регулирования температуры, поскольку её значение не может влиять на какие-либо опасные условия, и оно может быть предоставлено одним источником.

Эти изменения требуют пересмотра общего описания системы, границ системы, концепции эксплуатации и ограничений. В общее описание системы в краткий обзор необходимо добавить дополнительные функции настройки безопасного температурного диапазона и активации сигнализации. Кроме того, в список целей системы следует добавить новую цель — предупредить медсестру, если младенцу станет слишком холодно или слишком жарко. Эти дополнения обсуждаются в приложении A.1.

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

Произведя предварительную оценку безопасности системы (PSSA), вы уже начали рассмотрение того, как следует обрабатывать сбои. Это подходящее время, чтобы вернуться назад и расширить варианты использования исключительными случаями.

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

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

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

По мере выявления исключений следует задумываться о том, могут ли они быть причиной рисков, выявленных оценкой функциональных рисков системы (FHA). Примеры юскейсов-исключений и ссылки на них приведены в приложении A.2 для термостата инкубатора и в приложении B.2 для системы управления полётом.

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

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

По мере добавления новых переменных следует проявлять осторожность, чтобы быть уверенным, что все ограничения определены и задокументированы. Они могут быть довольно подробными. Например, теперь существует ещё несколько взаимосвязей, которые интерфейс пользователя должен поддерживать между безопасным диапазоном температур и желаемым диапазоном температур. Они задокументированы в приложении A.3.

Диаграмма зависимостей на рисунке 2 должна быть заменена пересмотренной диаграммой зависимостей термостата на рисунке 6, а также диаграммами зависимостей, созданными для функции регулирования температуры и функции отслеживания температуры. Диаграмма зависимостей для функции регулирования температуры показана на рисунке 7.

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

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

Кроме того, была добавлена новая функция «‎Обнаружение сбоя регулятора». Эта функция отвечает за обнаружение внутренних сбоев с помощью самопроверки или других проверок.

Также были добавлены внутренние переменные «‎Внутренний сбоя регулятора» и Сбой интерфейса регулятора", а также атрибут состояния текущей измеряемой переменной температуры. Эти зависимости были добавлены, чтобы указать, как обрабатывать сбои в измерении измеряемых переменных или внутренние сбои функции регулирования температуры. Их использование будет объяснено далее в разделе 2.7.

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

Диаграммы на рисунках 6, 7 и 8 показывают, как функции термостата инкубатора связаны друг с другом через иерархию функций и через зависимости данных. Эта структура была получена из оригинальной логической архитектуры, разработанной в ходе функционального анализа (рис. 2) при обработке полученных требований к безопасности. Другие ограничения, такие как необходимость интеграции с унаследованной системой или выполнение конкретных ограничений по реализации, могут оказать аналогичное влияние на интересующую нас архитектуру системы.

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

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

Далее к разделу 2.7