книги / Надежность и диагностика компонентов инфокоммуникационных и информационно-управляющих систем

параметр потока отказов блока W , параметр потока восстановления блока . Ремонт системы осуществляют три ремонтника.

Вариант 35. W = 10–2 ч–1, = 0,02 ч–1. Вариант 36. W = 10–2 ч–1, = 0,06 ч–1.

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

71

ТЕМА 9. РАСЧЕТ КОМПЛЕКСНОЙ НАДЕЖНОСТИ ВОССТАНАВЛИВАЕМЫХ СИСТЕМ С УЧЕТОМ НАДЕЖНОСТИ АППАРАТНОГО И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

вперечень либо вошла в искаженном виде. Отказ программного обеспечения – это проявление в нем ошибки.

Существуют три типа ошибок программирования:

– синтаксические ошибки;

– ошибки выполнения;

– семантические ошибки.

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

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

72

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

Семантические (смысловые) ошибки – это применение операторов, которые не дают нужного эффекта (например, (a–b) вместо (a+b)), ошибка в структуре алгоритма, в логической взаимосвязи его частей, в применении алгоритма к тем данным, к которым он неприменим и т.д. Правила семантики не формализуемы. Поэтому поиск и устранение семантической ошибки и составляют основу отладки.

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

Для того чтобы подробнее исследовать проблему ошибок в программном обеспечении (ПО), рассмотрим различные типы процессов перевода при его создании.

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

73

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

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

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

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

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

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

74

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

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

Другие источники ошибок – это неправильное понимание спецификаций используемой в системе аппаратуры, базового ПО (операционной системы), синтаксиса и семантики языка программирования.

И наконец, при непосредственном взаимодействии пользователя с ПО, если слабо разработан диалог человек – машина (отсутствие «дружественного интерфейса»), вероятность ошибки пользователя увеличивается. Ошибки пользователя ставят систему в новые, непредвиденные обстоятельства, увеличивая таким образом шансы проявления оставшихся в программе ошибок.

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

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

75

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

Все принципы и методы обеспечения надежности ПО в соответствии с их целью можно разбить на четыре группы: предупреж-

дение ошибок, обнаружение ошибок, исправление ошибок и обеспе-

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

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

–методы, позволяющие справиться со сложностью, свести

еек минимуму, так как сложность процесса – главная причина ошибок перевода;

–методы достижения большей точности при переводе;

–методы улучшения обмена информацией;

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

Очевидно, что предупреждение ошибок – оптимальный путь к достижению надежности ПО. Гарантировать отсутствие ошибок, конечно, невозможно. Другие три группы методов опираются на предположение, что ошибки все-таки будут.

76

Обнаружение ошибок. Если предполагать, что в программном обеспечении ошибки все-таки будут, то лучшая стратегия – включить средства обнаружения ошибок в само ПО. Такие методы часто применяются в аппаратуре. Это коды, обнаруживающие ошибки.

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

Исправление ошибок. После того как ошибка обнаружена, либо она сама, либо ее последствия должны быть исправлены программным обеспечением.

При проектировании систем аппаратурного обеспечения такой метод оказался плодотворным. При резервировании замещением некоторые устройства способны обнаружить неисправные компоненты и перейти к использованию идентичных запасов. Аналогичные методы неприменимы к программному обеспечению вследствие глубоких внутренних различий между отказами аппаратуры и ошибками в программах. Если некоторый программный модуль содержит ошибку, идентичные «запасные» модули будут содержать ту же ошибку.

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

Устойчивость к ошибкам. Методы этой группы ставят своей целью обеспечить функционирование программной системы при наличии в ней ошибок. Они разбиваются на три подгруппы: динамическая избыточность, методы отступления и методы изоляции ошибок.

77

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

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

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

При разработке сложных технических систем, состоящих как из аппаратной части, так и программного обеспечения, воз-

78

никает необходимость рассчитать комплексный показатель надежности системы, т.е. объединить показатели надежности аппаратной и программной подсистем.

Методика расчета количественной оценки комплексного показателя надежности системы подробно рассматривается в подразд. 3.4.5. учебного пособия [2].

Надежность программного обеспечения зависит как собственно от надежности программы, так и от надежности носителя программы, например ОЗУ или ПЗУ. Надежность носителя учитывается при расчете аппаратной части. Надежность собственно программного обеспечения учитывается различными моделями. Здесь выбирается простейшая модель. Ее использование будет показано на примере.

Алгоритм расчета состоит из следующих этапов.

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

На втором этапе составляется граф работоспособности объекта (методика приведена в предыдущей теме).

На третьем этапе по графу работоспособности составляют систему уравнений.

На четвертом этапе решаются системы уравнения, и находятся искомые вероятности пребывания объекта в состояниях работоспособности.

На пятом этапе рассчитывается коэффициент готовности системы как сумма вероятностей пребывания системы в работоспособных состояниях.

Пример. В качестве примера рассмотрим типовой приемный полукомплект системы телемеханики (тракт ТУ), структура которого приведена на рис. 9.1.

Приемный полукомплект тракта ТУ состоит из подсистемы передачи информации (ППИ), подсистемы распределения информации (ПРИ) и исполнительных механизмов ИМ (N = 10). Никакой избыточности с точки зрения надежности (резервирования, встроенных схем контроля) в системе нет.

79

ИМ N

Рис. 9.1. Структурная схема приемного полукомплекта телемеханики (тракт ТУ)

Этап 1. Предположим, что ИМ не интеллектуальные, т.е. не содержат контроллеров и встроенных программных средств. Пусть ИМ однотипные и имеют одинаковые интенсивности отказов и интенсивности восстановления, λ = 4,5∙10–5 1/ч и μ = 2 1/ч.

ППИ и ПРИ реализованы с использованием промышленных контроллеров, т.е. наряду с аппаратной частью в них «зашито» программное обеспечение. Надежность носителей ПО (ОЗУ, ПЗУ и т.д.) учтена при определении надежностных характеристик аппаратной части. Примем, что интенсивность отказов аппаратуры ППИ λап_ППИ = 10–7 1/ч, интенсивность восстановления аппаратуры ППИ μап ППИ = 0,4 1/ч, интенсивность отказов аппаратуры ПРИ λап_ПРИ = 10–7 1/ч, интенсивность вос-

становления аппаратуры ПРИ μап При = 0,7 1/ч.

Для ППИ и ПРИ дополнительно выделим надежностные характеристики программной составляющей – интенсивность отка-

зов ПО ППИ λпрг_ППИ, интенсивность восстановления ПО ППИ μпрг ППИ, интенсивность отказов ПО ПРИ λпрг_ПРИ и интенсивность

восстановления аппаратуры ПРИ ПО μпрг ПРИ.

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

80