Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Надежность и диагностика автоматизированных систем. Курс лекций
.pdf
В сложных объектах могут возникать дефекты, не приводящие к
ν−λµ+λγ
2
0
γ
0
ν
отказу. В этом случае такой объект может быть описан графом
(
рис. 4.13). Здесь состояний четыре:
1
λ
0
4
ν
λ
µ
3
λ
λ
0
Рис 4. 13. Граф работы сложного объекта:
интенсивность восстановления; λ
µ –
γ
– интенсивность восстановления при отказах объекта;
0
интенсивность возникновения эффектов, не приводящих к отказу;
λ –
ν –
интенсивность проведения диагностирования
1. В объекте отсутствуют дефекты.
2.
В объекте появились дефекты, не приводящие к отказу.
3. В специальном контрольном режиме диагностики возникшие
дефекты устраняются.
4.
Отказ объекта, идет его восстановление.
В этом случае коэффициент готовности определяется по формуле
– интенсивность отказов;
0
))((
=K
г
000
0000
,
))()((
ν+λ+λν+µ+λλ+γ
где µ – интенсивность восстановления;
λ
– интенсивность отказов;
0
γ
– интенсивность восстановления при отказе объекта;
0
λ –
интенсивность возникновения дефектов, не приводящих к от-
казу;
интенсивность проведения диагностики.
ν –
81
При λ
[
]
<< λ, т.е. в случае когда отказы возникают значительно
0
реже, чем дефекты, не приводящие к отказу,
K .
г
2
λ+νµλ++νµν= )/1()/1(
Задачи при проектировании систем диагностирования можно
сформулировать следующим образом.
1.
Определить значение выбранного критерия при заданных показателях, характеризующих свойства объекта диагностики, технических средств диагностики и процесса диагностирования и использования объекта.
2.
Для заданного объекта и средств диагностики в предположении, что использование объекта диагностирования строго регламентировано, определить значение показателей, характеризующих процесс диагностирования, которые обеспечивает заданный показатель
организации объекта диагностирования.
3.
Для заданного объекта и технических средств диагностики наи-
лучшим образом (в определенном смысле) организовать процесс.
Для широкого класса технологических объектов целесообразно
оценивать абсолютное приращение эффективности объекта, достигаемое диагностированием:
∆E(t) = E
(t) – E(t),
д
где E(t) – эффективность объекта при отсутствии диагностирования;
E
(t) – то же при наличии диагностирования.
д
Часто можно использовать для оценки диагностирования приращение надежности объекта диагностирования, т.е.
∆E
где R
(t) и R(t) – вероятность безотказной работы с учетом и без уче-
д
(t) = Rд(t) – R(t)
1
та диагностирования.
Возможность такой оценки определяется тем, что эффективность
сложных систем определяется величиной R(t):
E(t) = E
(t)R(t), где E0(t) – эффективность объекта с идеальной на-
0
дежностью, R(t) – вероятность безотказной работы объекта.
Итак, вкратце разобраны основные вопросы организации диагностирования технологических систем. Более конкретно указанную
методику можно рассмотреть лишь при глубоком знании объекта
диагностирования, статистических данных о возникновении дефектов, приводящих и не приводящих к отказу объекта, а также экономических данных об объекте, технических средствах диагностирования и потерях, вызванных появлением дефектов и отказов.
82
5. НАДЕЖНОСТЬ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
5.1. Определение надежности
программного обеспечения
В
настоящее время одной из самых серьезных проблем использо-
вания ЭВМ является программное обеспечение в отношении его тестирования после создания для выявления и устранения возможных
ошибок. Но и после тестирования некоторые ошибки остаются необнаруженными.
Что такое ошибки в программном обеспечении? Существует несколько определений этого понятия, наиболее разумное из которых
дано в [10]. В программном обеспечении имеется ошибка, если оно
не выполняет того, что пользователю разумно ожидать от него. Отказ
программного обеспечения – это появление в нем ошибок. Слово
«разумное» вводится, чтобы исключить непредусмотренные про-
граммным обеспечением ситуации.
Второй термин, требующий определения, – это надежность программного обеспечения. Различные ошибки далеко не одинаковы по
их последствиям, поэтому надежность должна быть определена как
функция части ошибок, а также оценена их серьезность для пользователя. Определим надежность следующим образом: «Надежность
программного обеспечения есть вероятность его работы без отказа в
течение определенного периода времени, рассчитанная с учетом
стоимости для пользователя каждого отказа». Иногда даже крупный
просчет в проектировании может быть несуществен для пользователя, а самые незначительные ошибки могут приводить к катастрофическим последствиям.
Если рассматривать понятия надежности в отсутствие данных о
том, к чему может привести ошибка, то целесообразно под надежностью понимать некоторую количественную меру отсутствия в программе ошибок.
Имеется существенное различие в надежности аппаратуры и программного обеспечения. Как отмечалось в п. 2, кривая интенсивности отказов аппаратуры во времени имеет U-образную форму (приработка – нормальная эксплуатация – износ), а интенсивность отказов программного обеспечения падает со временем вследствие устранения ошибок (если программы не изнашиваются).
83
5.2. Тестирование программного обеспечения (ПО)
написании больших сложных программ неизбежно допуска-
При
ются ошибки независимо от того, насколько опытен программист. В
сложных программах обычно бывает много ветвлений, и проверить
правильность программы до внедрения ее в эксплуатацию при всех
возможных значениях входных данных бывает крайне затруднительно
или даже практически невозможно. Обеспечение надежности ПО –
задача более сложная, чем обеспечение надежности технических
средств. Ошибки в ПО обнаруживаются и исправляются как до начала
его эксплуатации, так и во время. Разработка ПО включает в себя проектирование как самой программы, так и тестов для ее проверки. Тестирование – это процесс исполнения программы с целью обнаружения
ошибок. Тестирование – процесс деструктивный, обратный созидательному процессу создания ПО (а большинство людей склонно к созидательному процессу). Следует также отметить, что к процессу тестирования нецелесообразно привлекать автора программы, так как
«свои» ошибки заметить значительно сложнее, чем «чужие».
В литературе по программированию можно встретить следующие
рекомендации для разработчиков программного обеспечения:
1. Программа должна быть легко читаемой людьми (а не ЭВМ).
2.
Следует использовать осмысленные имена переменных и ста-
раться избегать сходных имен.
3. Цифры в идентификаторах следует помещать только в конце и
избегать схожих по написанию цифр (О и 0, 1 и I, 2 и Z, 5 и S и т.п.).
4. Не использовать в идентификаторах ключевые слова.
5.
Избегать по возможности промежуточных переменных.
6.
Употреблять при написании выражений скобки даже в тех слу-
чаях, когда без них можно обойтись: например, не а/bc, a a/(bc).
7.
Не изменять значение параметра цикла в теле цикла.
8.
Не использовать метки, на которые нет ссылок.
9. Не писать «своих» программ вместо библиотечных.
10.
Не следует жертвовать легкостью чтения ради эффективности
программы.
11. Следует избегать различных «трюков» с целью упрощения
программ.
12. Не следует пренебрегать комментариями для переменных и
констант.
13.
Не следует использовать одно и то же имя переменной для
решения более чем одной задачи.
84
14. Проявлять осторожность с действиями над целыми (например,
I = 2*(I/2),
так как результат будет зависеть от четности или нечетно-
сти I).
15.
При сравнении чисел с плавающей запятой необходимо пом-
нить, что точность представления числа в ЭВМ конечна.
16. Следует избегать операторов типа GO TO, так как они ухуд-
шают осмысление программы.
Этот список рекомендаций может быть значительно расширен.
Язык программирования существенно влияет на надежность. Чем
«
выше» уровень языка, тем меньше можно сделать ошибок. Хотя
программирование на Ассемблере позволяет сделать самые экономичные программы (с точки зрения объема памяти и быстроты исполнения), при проектировании на Ассемблере программист тратит
большую часть времени не на решение задачи, а на «возню» с особенностями данной ЭВМ. Программы на языке высокого уровня легче понимать и видоизменять, количество операторов значительно
меньше, они дешевле при написании программ.
Языки высокого уровня лучше, чем Ассемблер работают со сложными структурами данных, а современные компьютеры создают высокие по эффективности объектные программы. В результате эффективность достигается разумным выбором алгоритмов и структур данных, а не за счет микроэффективности при использовании Ассемблера. В больших и сложных программах только небольшой процент
операторов целесообразно писать на машинном языке. В настоящее
время использование Ассемблера становится практически нецелесообразным за исключением случаев создания компиляторов и в ряде
других случаев.
В литературе по тестированию можно встретить несколько близких по значению терминов.
1. Тестирование – это процесс выполнения программы с целью
нахождения ошибки.
2.
Контроль – попытка найти ошибку, выполняя программу в тес-
товой или моделируемой среде.
3.
Испытание – попытка найти ошибку, выполняя программу в ре-
альных эксплуатационных условиях.
4.
Отладка – установление точной природы ошибки и последую-
щее ее устранение.
Процесс тестирования упрощается, если программа разбита на
модули. Рассмотрим, например, следующую программу:
85
X=(A+B)(C–D).
Данные A, B, C, D могут быть представлены в любом из четырех
обычно используемых кодов. Фактически вычисления выполняются
в «арифметике с плавающей запятой». Если программу тестировать
как единое целое, возможное число комбинаций данных, т. е. минимальное число проверяемых случаев для «полной» проверки, было
4
бы 4
=256.
Если программу структурировать и разбить на три независимых
модуля:
X
X
X
то как (1), так и (2) включают 2
=A+B; (1)
1
=C–D; (2)
2
3=X1X2
, (3)
2
= 4 комбинаций, а для (3) возможна
только одна комбинация данных. Таким образом, если сегменты проверены, то после их объединения общее число различных случаев
составит 16+16+1=33, что <<256 вариантов для неструктурированной
программы, т.е. на тестирование будет затрачено значительно меньше времени.
Существуют два типа ошибок:
1) синтаксические (нарушение правил языка), которые легко уст-
раняются при трансляции;
2)
логические (семантические или смысловые), которые приводят
к ошибкам вычислений. Их устранить можно только при тестировании с тщательно подобранными проверочными данными, для которых известны итоговые результаты, полученные при помощи либо
ручного вычисления, либо иным проверенным способом.
При тестировании больших программ практически невозможно
проверить все вероятные типы комбинаций данных и путей. Тестирование таких программ может показать только наличие ошибок, но
никогда не может служить доказательством их отсутствия.
Существуют два подхода к тестированию.
1.
Тестирование программы как «черного ящика», т.е. тестирование с управлением по входу-выходу (выход, как указывалось выше,
должен быть известен). Для входов используются все возможные для
данной программы наборы. Практически быть уверенным, что в программе нет ошибок при большом числе комбинаций входных данных, нельзя.
86
2. Тестирование программы как «белого ящика», т.е. тестирование
логики, внутренней структуры программы. Если в программе много
разветвлений, то исчерпывающее тестирование также практически
невозможно.
Таким образом, оба пути не дают 100 %-ной гарантии. Возможно,
что лучшим способом является сочетание этих двух подходов.
Хорошая программа должна:
•
обеспечивать легкость тестирования;
• занимать возможно минимальный объем памяти;
•
быстро работать;
•
обеспечивать легкость внесения изменений;
• быть ясной для чтения человеком.
Для создания легко тестируемых программ и простоты нахождения и исправления ошибок некоторые авторы считают целесообразным пользоваться методами структурного программирования [11].
При использовании этого метода сложное программное обеспечение
разрабатывается по принципу «сверху вниз», причем до создания
программ более низкого уровня производится тестирование более
высокого уровня. Так как в программы более высокого уровня поступают данные от программ более низкого уровня, используется
метод «заглушки», при котором имитируется подача сигнала от программ более низкого уровня.
5.3. Математические модели надежности
программного обеспечения
Самым
важным критерием надежности является число ошибок,
оставшихся после тестирования программы (с учетом их важности
для решаемой задачи).
Возможны также критерии, используемые в теории надежности,
такие как вероятность того, что программа будет выполняться в течение данного интервала времени, прежде чем обнаружится ошибка
заданной степени серьезности, или среднее время между отказами
программы, вызванными наличием в ней ошибок.
По аналогии с определениями надежности технических средств
можно ввести вероятность того, что в программе в интервале 0…t не
будет обнаружено ни одной ошибки R(t). Тогда величина F(t)= 1–R(t)
– есть вероятность, что ошибка в этом интервале появится.
Можно ввести понятие функции риска Z(t), т.е. условную вероятность, что ошибка появится в интервале t…t+∆t, при условии, что в
87
интервале 0…t ошибки не было. Так как R(0) = 1, то в соответствии с
табл. 2.1
t
⎛
⎜
−=
∫
⎜
0
⎝
⎞
⎟
dttZtR
)(exp)( . Ясно, что Z(t) является аналогом λ(t)
⎟
⎠
при рассмотрении отказов технических средств. По мере устранения
ошибок будет наблюдаться рост надежности ПО. Напомним, что в
аппаратной надежности обычно считается λ(t) = const.
Можно также предположить, что Z(t) пропорционально числу оставшихся ошибок, т.е. Z(t) = K(N–i), где N – неизвестное число первоначальных ошибок ПО; i – число обнаруженных ошибок; К – некоторая константа.
Модель надежности другого типа была предложена Майерсом [9].
Модель строится на статистическом материале. Перед тестированием
программа случайным образом засоряется некоторым количеством
известных ошибок. Далее делается предположение, что вероятность
обнаружения любых (умышленно внесенных и незамеченных) ошибок при тестировании одинакова и зависит только от их количества.
Тестируя и отсортировывая внесенные и незамеченные ранее
ошибки, можно оценить первоначальное число ошибок. Пусть N –
первоначальное число ошибок, а s – число внесенных ошибок и
пусть при тестировании обнаружено n и v ошибок, где n – число собственных, а v – число внесенных ошибок. Тогда оценка для N по ме-
sn
тоду максимума правдоподобия будет
N
= . Например, если
v
⋅
s = 20, n = 15, v = 5,
то 60
1520
=N .
=
5
Другая часть модели – проверка гипотезы о числе собственных
ошибок n. Примем, что в программе не более k ошибок, внесем еще s
ошибок и произведем тестирование, пока не обнаружим все s внесенных ошибок. При этом будет выявлено n собственных ошибок.
при1
>
1
при
kn
.
≤
kn
Уровень значимости:
⎧
⎪
=
C
s
⎨
⎪
ks
++
⎩
Величина С – это мера доверия, т.е. вероятность того, что модель
будет правильно отклонять любые ложные предположения.
Если k = 0, n = 4, все внесенные ошибки обнаружены и ни одной
исходной не встречено, то С = 0,8. Чтобы достичь уровня 95 %, надо
88
внести 19 ошибок. Напомним, что тестирование длилось до тех пор,
пока все внесенные ошибки не были обнаружены.
Процесс внесения ошибок в этой модели надежности является,
по-видимому, самым слабым местом, так как предполагается, что
вероятность обнаружения внесенных и собственных ошибок программы одинакова. Из этого следует, что вносить надо «типичные»
для данной программы ошибки. Для оценки числа ошибок N в программе может быть предложен следующий метод. Тестирование программы производится двумя независимыми группами, использующими несовпадающие наборы тестов.
Пусть первая группа обнаружила N
N
обозначим чмсло ошибок, обнаруженных обеими группами. При-
12
ошибок, а вторая N2. Через
1
мем за показатель эффективности тестирования отношение числа
обнаруженных ошибок к общему их числу, т.е.
E
= и
1
N
1
N
E
2
N
2
= .
N
Будем считать, что вероятность обнаружения любых ошибок одинаково, а следовательно, каждое подмножество набора ошибок N ап-
проксимацией всего множества. Отсюда следует, что
N
Аналогично
N
12
=
N
. Например, если одна группа тестирующих нашла 10 оши-
EE
21
E
12
. Из приведенных равенств следует, что
=
2
N
1
бок, а вторая 20, и из них 5 ошибок общие, то E
Е
=5:10=0,5 и следовательно, N =
2
5
= 40. Такими оценками
5,025,0
⋅
N
E
1
N
=5:20=0,25 и
1
121
==
N
2
N
следует пользоваться осторожно, поскольку новые методы программирования (например, структурное) дают значительно меньшее число ошибок. Следовательно, приведенные выше методы дают пессимистическую оценку числа ошибок.
Существуют и другие модели надежности программного обеспечения, в частности с использованием понятия «сложности» программы, поскольку между сложностью и надежностью программы существует тесная связь. Для знакомства с этими методами можно рекомендовать работу Т. Тейера и др. [10].
В качестве упражнения на тестирование программного обеспечения предлагается составить программу и произвести тестирование ее
для следующей задачи. При помощи генератора целых случайных чи-
89
.
сел с равномерным законом распределения (от 0 до 99) сгенерировать
три числа. Составить и протестировать программу, определяющую:
1)
могут ли эти числа быть сторонами треугольника;
2) если да, то определить, является ли треугольник равносторон-
ним, равнобедренным, разносторонним и не является ли полученный
треугольник прямоугольным.
При тестировании следует помнить, что стороны треугольника
могут быть только целыми числами.
Если эта задача окажется легкой, то составьте программу и тест
для решения квадратного уравнения Аx
2
+Вx+С= 0.
90
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]