Главная | Обратная связь | Поможем написать вашу работу!

Отказоустойчивые архитектуры

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

Для построения отказоустойчивого оборудования обычно требуется много лет. Используемая в большинстве случаев технология устойчивого к сбоям оборудования базируется на методе тройного модульного резервирования, когда модуль оборудования дублируется три (иногда больше) раза. Выходные данные каждого модуля сравниваются: если один из модулей выходит из строя и на его выходе данные не совпадают с выходными данными других модулей, эти данные игнорируются. Если невозможно сразу восстановить сбойный модуль, система автоматически переконфигурируется, исключая поврежденный модуль. Далее система продолжает функционировать с двумя работающими модулями (рис. 18.3).

Рис. 18.3. Тройное модульное резервирование для обеспечения отказоустойчивости оборудования

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

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

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

Рис. 18.4. N-вариантное программирование

Рис. 18.5. Блоки восстановления

Опишем подходы к созданию отказоустойчивого программного обеспечения.

1. N-вариантное программирование. В соответствии с общей спецификацией различными командами разработчиков разрабатывается несколько версий программного обеспечения. Эти версии выполняются параллельно на отдельных компьютерах. Результаты их работы сравниваются с помощью системы согласования, результаты какой-либо версии, не совпадающие с двумя другими или не полученные вовремя, отвергаются. Это наиболее часто используемый подход к созданию отказоустойчивого программного обеспечения. Он используется в системах сигнализации на железных дорогах, в авиационных системах и в системах защиты реакторов [14, 15, 29*].

2. Блоки восстановления. В этом методе каждый программный компонент содержит тест, проверяющий его работу. Компонент также имеет подпрограмму, которая повторяет вычисления, если тест обнаружил неправильное выполнение. Но повторные вычисления выполняются другим модулем компонента, который намеренно построен на другой интерпретации требований, предъявляемых к компоненту. Таким образом, компонент имеет несколько модулей (блоков восстановления), выполняющих одинаковые функции, но реализующих разные алгоритмы. Поскольку модули выполняются последовательно, в рамках данного подхода нет необходимости дублировать аппаратные средства. Метод блоков восстановления описан в работах [288, 289, 8*].

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

1. Включение в системную спецификацию требований использовать при проектировании различные подходы. Например, можно потребовать, чтобы одна команда разработчиков использовала объектно-ориентированное проектирование, а другая – функционально-ориентированное.

2. Включение в спецификацию требований, чтобы для реализации были использованы различные языки программирования. Например, в системе с тремя версиями ПО для написания разных версий можно использовать языки программирования Ada, C++ и Java.

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

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

Каждая команда разработчиков должна работать со своей спецификацией (так называемой V-спецификацией), которую получают из общей спецификации системных требований [15]. Команды разработчиков каждой версии ПО должны работать изолированно, чтобы уменьшить вероятность появления в версиях одинаковых ошибок.

Многообразие версий, конечно, увеличит общую безотказность системы. Однако ряд экспериментов показывает: предположение о том, что различные команды разработчиков не сделают одинаковых ошибок, не всегда справедливо [200, 58, 214]. Различные коллективы разработчиков могут сделать одни и те же ошибки из-за одинаковых интерпретаций требований или вследствие того, что они независимо друг от друга используют одни и те же алгоритмы. Метод блоков восстановления уменьшает вероятность общих ошибок, поскольку блоки восстановления реализуют разные алгоритмы.

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

⇐ Предыдущая 126 127 128 129 130131132 133 134 135 Следующая ⇒