Содержание к диссертации
Введение
1 Архитектура автоматизированной системы диспетчерского управления 16
1.1 Исследование типовых моделей построения АСДУ 16
1.2 Требования к разрабатываемой АСДУ 22
1.3 Предлагаемая архитектура АСДУ 32
2 Метод построения открытой модульной многоплатформенной SCADA-системы 39
2.1 Сравнительный анализ операционных систем 39
2.2 Требования к информационной безопасности и открытости 41
2.3 Разработка динамического программного интерфейса 47
2.4 Применение SCADA-системы 64
3 Метод обработки данных, основанный на использовании варианта трёхзначной логики 66
3.1 Предпосылки и история создания 66
3.2 Таблицы истинности 74
3.3 Применение метода 76
4 Методы оценки основных характеристик надежности 78
4.1 Метод оценки по информации, сохраняемой системой управления версиями 83
4.2 Сравнение результатов 95
4.3 Имитационная модель 102
4.4 Метод оценки надежности на основе теории нечетких множеств 110
5 Практическое использование результатов 118
5.1 Исторические предпосылки модернизации АСДУ движением поездов 118
5.2 Разработанная архитектура АСДУ 121
5.3 Моделирующий комплекс 125
5.4 Автоматизированная система диспетчерского управления движением поездов Новосибирского метрополитена 126
Заключение 128
Список литературы
- Требования к разрабатываемой АСДУ
- Требования к информационной безопасности и открытости
- Таблицы истинности
- Метод оценки надежности на основе теории нечетких множеств
Введение к работе
Актуальность работы. Среди широкого спектра автоматизированных систем диспетчерского управления (АСДУ) особое место занимают программно-аппаратные комплексы, предназначенные для использования на объектах повышенной опасности, таких как предприятия атомной и химической промышленности, транспортные комплексы, объекты военного назначения и т. п., нарушения в работе которых представляют прямую угрозу жизни и здоровью людей. Помимо высокой надежности при работе в штатном режиме подобные системы должны обеспечивать предсказуемо-безопасное поведение в случае выхода из строя отдельных компонентов.
В отличие от полностью автоматической системы АСДУ предполагает первостепенное и активное участие человека, осуществляющего функции оперативного управления, поэтому анализ отдаваемых им команд и блокирование ошибочных действий в режиме реального времени является необходимым условием обеспечения безопасности, позволяющим уменьшить влияние так называемого «человеческого фактора».
В настоящее время многие предприятия нуждаются в модернизации разработанных много лет назад и уже морально устаревших систем управления. Также не менее часто, чем отжившее свой век оборудование и программное обеспечение (ПО), на практике встречается построенная на основе достаточно современных компонентов так называемая лоскутная автоматизация, представляющая собой набор разнородных слабо связанных информационных подсистем, следствием чего является низкая скорость обмена данными, дублирование, увеличение времени обработки, снижение уровня контроля ситуации и, в конечном итоге, общая неэффективность системы управления. В то же время интенсивное усложнение и увеличение масштабов производства приводит к необходимости использования интегрированных средств, построенных на основе современных достижений вычислительной техники.
Ограничения, наиболее важные из которых перечислены выше, а также перечень требований, регламентируемых государственными, отраслевыми и внутренними стандартами предприятий, не позволяют найти приемлемое универсальное решение среди существующих, поэтому становится актуальной проблема разработки и исследования моделей и методов построения автоматизированных систем диспетчерского управления, удовлетворяющих поставленным условиям, включая экономическую целесообразность.
В процессе решения основной задачи особое внимание должно быть уделено анализу различных характеристик создаваемой системы, основными из которых являются надежность, безопасность и живучесть. И если в случае аппаратной части, составленной из стандартных компонентов, можно воспользоваться предоставляемыми производителями данными о среднем времени наработки на отказ, сроке службы и т. п., то для программной части использование статистического подхода, по крайней мере на первом этапе, неприменимо ввиду уникальности разработки и планируемого штучного использования. Эти обстоятельства приводят к необходимости исследования методов оценки параметров подобных систем с учетом имеющейся зачастую косвенной или неполной информации.
Целью диссертационной работы являлись разработка и исследование методов построения автоматизированных систем диспетчерского управления повышенной надёжности. В соответствии с поставленной целью требовалось решить следующие задачи:
исследовать типовые модели систем диспетчерского управления, выделить стандартные элементы и создать на их основе архитектуру автоматизированной системы диспетчерского управления с повышенным уровнем надежности и безопасности;
разработать открытую модульную многоплатформенную SCADA-систему (Supervisory Control And Data Acquisition - диспетчерское управление и сбор данных), поддерживающую предложенную архитектуру АСДУ и предназначенную для создания многоуровневых программных комплексов с распределённым резервированием;
осуществить анализ характеристик разработанных архитектуры и программного обеспечения на основе предложенных способов оценки надежности, учитывающих экспертные данные и информацию о процессе создания программного обеспечения, а также разработать имитационную модель, предназначенную для анализа сценариев отказа оборудования и программного обеспечения;
реализовать предложенные решения в виде программных комплексов при построении АСДУ движением поездов Новосибирского метрополитена, в частности, создать на основе разработанной SCADA-системы программное обеспечение автоматизированных рабочих мест оперативного и эксплуатационного персонала.
Научная новизна. Предложена архитектура АСДУ, основанная на использовании равноправных асинхронно работающих узлов и обеспечивающая высокий коэффициент готовности, многоуровневый контроль действий оператора, возможность динамического изменения конфигурации и повышенную живучесть системы.
Предложен метод построения модульной SCADA-системы на основе разработанной концепции динамического программного интерфейса, позволяющий создавать программные комплексы со сложными логическими зависимостями между частями, составляя динамическую конфигурацию из подгружаемых модулей, а также использовать программное обеспечение с открытым исходным кодом.
Предложен метод обработки данных на основе варианта трёхзначной логики, позволяющий наряду с точными данными оперировать неполной и недостоверной информацией, унифицируя и упрощая запись логических выражений.
Предложен метод оценки основных характеристик надежности программного обеспечения по информации, сохраняемой системой управления версиями, позволяющий учесть особенности индивидуальной истории создания продукта, такие как скорость внесения изменений в текст программы, интенсивность выявления ошибок, их тип и потребовавшееся на исправление время, полнота предоставленных спецификаций и частота появления новых требований в процессе разработки.
На основе теории нечетких множеств разработан способ уточненной оценки коэффициента готовности системы, учитывающий экспертные поправки к среднему времени наработки на отказ и продолжительности ремонтов.
Методы исследования. Для решения поставленных задач использовались методы теории управления, теории надежности, элементы теории нечетких множеств, математической логики и теории массового обслуживания, а также имитационное моделирование.
Практическая значимость и внедрение результатов. Разработанные архитектура и программное обеспечение могут быть использованы при создании многоуровневых распределенных автоматизированных систем диспетчерского управ-
ления с повышенными требованиями к надежности и безопасности, а также возможностью поэтапной модернизации путем интеграции с существующими программно-аппаратными комплексами.
На основе предложенной архитектуры разработана система диспетчерского управления движением поездов Новосибирского метрополитена. Программное обеспечение, созданное с помощью разработанной SCADA-системы, функционирует на станциях «Березовая роща», «Маршала Покрышкина», «Площадь Гарина— Михайловского», «Заельцовская» и «Красный проспект».
Основные положения, выносимые на защиту:
разработанная архитектура автоматизированной системы диспетчерского управления обеспечивает более высокий коэффициент готовности по сравнению с классической схемой «основной-резервный»;
предложенный метод обработки данных на основе варианта трёхзначной логики позволяет унифицировать и упростить запись логических выражений при обработке неполной и недостоверной информации;
разработанный метод расчета основных характеристик надежности программного обеспечения по информации, сохраняемой системой управления версиями, позволяет оценить остаточное количество ошибок ПО;
предложенный метод оценки параметров надёжности, разработанный на основе
теории нечетких множеств, позволяет наряду со статистическими распределе
ниями учитывать предоставляемую экспертами неточную информацию.
Апробация работы. Основные результаты работы были изложены и обсужда
лись на следующих научно-технических конференциях и семинарах:
VI Международный семинар «Распределенная обработка информации», Новосибирск, 1998 г.;
the IASTED International Conference "Automation, Control, and Information Technology (ACIT 2002)", Новосибирск, 2002 г.;
the Second IASTED International Multi-Conference 'Automation, Control, and Applications (ACIT-ACA 2005)", Новосибирск, 2005 г.;
VII, VIII, IX и X Международные конференции «Проблемы управления и моделирования в сложных системах», Самара, 2005-2008 гг.;
Международная школа-конференция молодых ученых «Информационно-коммуникационные системы», Новосибирск, 2006 г.;
научно-практическая конференция молодых ученых и студентов НГУ и ИАиЭ СО РАН «Информационно-вычислительные системы анализа и синтеза изображений», Новосибирск, 2006 г.;
IV Всероссийская школа-семинар молодых ученых «Проблемы управления и информационные технологии», Казань, 2008 г.;
VII Международная конференция памяти академика А. П. Ершова «Перспективы систем информатики», Новосибирск, 2009 г.
Публикации. По результатам выполненных в диссертационной работе исследований и разработок опубликовано 17 печатных работ, включая три статьи в рекомендованных ВАК журналах.
Личный вклад автора. Все выносимые на защиту положения и результаты диссертационной работы получены и разработаны автором лично или при его непосредственном участии.
Структура и объем работы. Диссертация состоит из введения, пяти глав, за-
Требования к разрабатываемой АСДУ
Еще одна интересная тенденция, наиболее ярко проявившаяся в, электроэнергетике — это замещение классического централизованного RTU набором интеллектуальных электронных устройств (Intelligent Electronic Device — IED) [11], которые обеспечивают низкоуровневую локальную обработку информации и самостоятельно оперативно реагируют на изменение ситуации, что позволяет не только снизить требования к пропускной способности каналов связи с центральным диспетчерским пунктом, но и значительно повысить скорость реакции системы управления. В 2004 году Международной электротехнической комиссией (МЭК) в качестве единого стандарта обмена данными и организации систем связи интеллектуальных устройств электрических станций и подстанций принят открытый стандарт МЭК 61850 [12], который обладает целым рядом нововведений: отделяет собственно данные (информацию) от методов ее передачи; определяет точные модели данных и методы,работы с ними, обеспечивая их, возможное расширение; определяет единый- язык конфигурирования устройств и-использование широко распространенных протоколов Ethernet и ТСРЯР, одновременно обеспечивая открытость будущих концепций связи [13]; поддерживает свободное распределение функций и их комбинацию для различных устройств, а также способы передачи данных от одного устройства другому на одном («горизонтальные» связи) и нескольких («вертикальные» связи) иерархических уровнях [14] (типовая схема подключения IED приведена на рис. А2 в Приложении А). Хотя данный стандарт и разработан для использования на электроэнергетических объектах, сам подход и вытекающая из него архитектура нижнего уровня системы управления обладают заметными преимуществами и после соответствующей доработки могут занять достойное место в ряду АСДУ общего назначения.
Master Terminal Unit осуществляет управление высокого уровня, как правило, в режиме мягкого (квази)реального времени [15], что позволяет использовать на узлах не только операционные системы реального времени (ОСРВ), такие как QNX, OS9, LynxOS, VxWorks, VRTX (обзор ОСРВ приведен в [16]), но и привычную для пользователей и обслуживающего персонала операционную систему Windows. Нужно отметить, что, хотя это и является наиболее распространенным подходом [17], даже в системах мягкого реального времени операционная CHCTeMa.Windows может быть использована только при выполнении целого ряда рекомендаций и ограничений [18].
Одна из основных функций MTU — это обеспечение интерфейса между человеком-оператором и системой (Human Machine Interface). Целый ряд исследований выявил непосредственную связь между удобством интерфейса и безопасностью системы [19], тем самым продемонстрировав необходимость применения, принципиально новых подходов к разработке АСДУ, с ориентацией в первую очередь на человека-оператора (Human-Centered Design), в отличие от традиционного подхода, уделяющего основное внимание выбору и разработке технических средств [20].
В зависимости от конкретной системы MTU может быть реализован в самом разнообразном виде: от одиночного компьютера с дополнительными устройствами подключения к каналам связи до больших вычислительных систем (mainframe) и объединенных в локальную сеть рабочих станций и серверов. В настоящее время основной тенденцией является использование готовых коммерческих SCADA-систем (Supervisory Control And Data Acquisition — диспетчерское управление и сбор данных), таких как WinCC, InTouch, TRACE MODE, GENESIS32, iFIX, на х86-совместимых компьютерах под управлением операционной системы MS Windows. Это диктуется логикой современного бизнеса, повышающего требования к интенсификации труда программистов, отметим, что даже некоторые фирмы, до сих пор поддерживавшие SCADA-системы на базе ОС реального времени; начали менять ориентацию, выбирая системы на платформе Windows [21]; очевидно, подобное сокращение затрат на разработку, имеет и обратную сторону: надежность систем, работающих под управлением ОС Windows, далека от идеальной, при этом возникают значительные проблемы с обеспечением информационной и антивирусной защиты, решение которых в свою очередь сопряжено с появлением часто неприемлемых временных задержек [22] (более подробно данный аспект рассмотрен в главе 2).
Замечание относительно термина «SCADA-система»: в настоящее время существует двоякое толкование данного понятия, эта разница, наиболее ярко проявляется при сравнении российских и зарубежных источников.
Во-первых, так называют класс систем управления, предназначенный для автоматизации территориально распределенных (до десятков и тысяч километров) технологических объектов, таких как трубопроводные системы, системы распределения электроэнергии, ирригационные системы и т. п. В момент своего появления (70-е гг) термин SCADA противопоставлялся термину DCS (Distributed Control System — распределённая система управления), обозначавшему класс систем управления, предназначенных для автоматизации локальных производств (например, нефтеперерабатывающие и химические установки). Поэтому на тот момент основной отличительной особенностью SCADA-систем являлось отсутствие возможности оперативного обмена данными между RTU иначе, чем посредством передачи через MTU, а также низкопроизводительные и ненадежные каналы передачи данных. Применение современных высокоскоростных систем связи в настоящее время значительно уменьшило актуальность подобной классификации. В качестве примера SCADA-систем в этой трактовке термина можно привести такие продукты как OaSYS фирмы Telvent и RTAP фирмы Verano.
Во-вторых, так называют программный комплекс, предназначенный для реализации человеко-машинного интерфейса (ЧМИ) (в зарубежных источниках,— HMI Human-Machine Interface, например, InTouch, WinCC, GENESIS32 и т. д.). В определенный момент производители подобных программных продуктов начали именовать их SCADA-системами, это название прижилось, и большинство специалистов области АСУ ТП (особенно в России) сегодня принимают именно это толкование термина «SCADA-система».
Требования к информационной безопасности и открытости
Серьёзным препятствием на пути использования. СОМ в гетерогенных средах, являетсянеспособность модели функционировать как. цельное и.комплекс-ное решение под. управлением операционных систем, отличных от Windows: необходимые службы и серверы, такие как MTS (Microsoft Transaction Server) и MSMQ (Microsoft Message Queuing) реализованы исключительно для данной конкретной операционной системы.
CORBA лишена этого недостатка: в этой модели изначально была заложена многоплатформенность и поддержка множества популярных языков программирования без необходимости каких-либо изменений в них. Поэтому реализации CORBA могут использоваться с произвольными компиляторами, средствами разработки и операционной системой. Интересно отметить, что объектный брокер запросов реализован на большем числе платформ Microsoft, чем сама СОМ, включая Windows 3.1, Windows 95, Windows NT 3.5, Windows 4.0 и DOS [81].
Несмотря на различия, как в CORBA, так и в СОМ функциональность объекта предоставляется клиенту посредством обращения к абстрактным интерфейсам, определяющим набор методов, которые реализуют присущие данному классу объектов функции. В CORBA интерфейс объекта задается с помощью определенного OMG языка описания интерфейсов (ШЬ — Interface Definition Language). Тип объекта — это тип его интерфейса, при этом сам интерфейс идентифицируется именем, представленным цепочкой символов. В СОМ объект характеризуется своим классом, представляющим собой реализацию некоторого множества интерфейсов, при этом для идентификации классов и интерфейсов используются уникальные идентификаторы (UUID), а сам объект в СОМ1.— это экземпляр класса. Если в модели интеграции объектов CORBA язык ГОЬ играет фундаментальнуюроль, то Microsoft IDE (MIDL) — лишь один из возможных способов определения интерфейсов объекта и не определяет общего набора типов данных, доступных различным языкам программирования.
В предлагаемой концепции динамического программного интерфейса набор методов и членов класса-модуля, в отличие от CORBA и СОМ, не является статическим, а может при необходимости динамически изменяться в процессе функционирования программы, что позволяет изменять конфигурацию системы без перезапуска всех компонентов. Отсутствие поддержки многоплатформен-ности в модели СОМ с одной стороны, и требовательность к ресурсам существующих реализаций CORBA (что особенно важно учитывать при разработке встраиваемых систем), а также отмечаемая многими специалистами низкая производительность при работе в территориально распределенных сетях [82] — с другой, и привели к необходимости разработки и использования лишенной данных недостатков концепции динамического программного интерфейса при создании модульной многоплатформенной SCADA-системы, представленной в данной работе.
Запуском модулей SCADA-системы занимается специальная программа (runner), которая в соответствии со своим конфигурационным файлом загружает необходимые модули, записывает в журнал принимаемые от них системные и отладочные сообщения, а также обеспечивает перезапуск модуля в случае его сбоя или остановки.
В рамках такой модели крах любой части программного комплекса не приводит к потере данных, и после перезапуска компоненты функциональность полностью восстанавливается, а поскольку взаимодействие модулей осуществляется по протоколу TCP/IP, появляется возможность развертывания распределенной системы с резервированием»всех программ на нескольких компьютерах таким образом, что выход из строя любого из них не приводит к заметным последствиям.
Модуль графического интерфейса пользователя viewer реализует набор встроенных и динамически определяемых функций. Конфигурационный файл модуля, как и прочие конфигурационные файлы системы, имеет формат XML и содержит описания отображаемых объектов различных типов (таких как "page", "label", "svg", "clock"), их характеристики (расположение на странице, размеры и т. д.), а также сценарии поведения этих объектов. Модуль использует объектно-ориентированную графическую библиотеку GTK+, которая обеспечивает SCADA-системе современный интерфейс (интернационализация, локализация, специальные возможности, темы внешнего вида и т. п.), существует на всех популярных платформах, таких как GNU/Linux и Unix, Windows, Mac OS X, и благодаря лицензии GNU LGPL может бесплатно использоваться в коммерческих приложениях.
Поддержка открытых стандартов существенно сокращает время разработки приложений за счет возможности выборапрограммы, наиболее подходящей для решения возникшей задачи. Например, поскольку все конфигурационные файлы системы, включая описания отображаемых на экране объектов, основаны на формате XML, разработчику предоставляется возможность выбора не только оптимального в каждом конкретном случае приложения-редактора (например, свободно распространяемые sodipodi и inkscape для SVG-изображений (Scalable Vector Graphic — масштабируемая векторная графика, стандарт W3C), draw и dia для XML описания интерфейса пользователя; автоматическое создание конфигураций посредством XSLT преобразований и т. д.), но и системы управления версиями (Git, Subversion .CVS H т. п.) для работы со всеми файлами.программ-ного продукта, включая графическую информацию? [83].
Таблицы истинности
В соответствии с ГОСТ 27.301-95 [93] по основным принципам расчета свойств, составляющих надежность (а также комплексных показателей надежности объектов), различают: методы прогнозирования, которые основаны на использовании для оценки ожидаемого уровня надежности объекта данных о достигнутых значениях и выявленных тенденциях изменения показателей надежности объектов, аналогичных или близких к рассматриваемому по назначению, принципам действия, схемно-конструктивному построению и технологии изготовления, элементной базе и применяемым материалам, условиям и режимам эксплуатации, принципам и методам управления надежностью. структурные методы расчета, основанные на представлении объекта в виде логической (структурно-функциональной) схемы, описывающей зависимость состояний и переходов объекта от состояний и переходов его элементов с учетом их взаимодействия, и выполняемых ими функций в объекте с последующим описанием построенной структурной модели адекватной математической моделью и вычислением показателей надежности объекта по известным характеристикам надежности его элементов. физические методы расчета, которые основаны на применении математических моделей, описывающих физические, химические и иные процессы, приводящие к отказам объектов (к достижению объектами предельного состояния), вычислении показателей надежности по известным парамет-рамнагруженности объекта,.характеристикам примененных вобъекте веществ и материалов с учетом особенностей его конструкции и технологии изготовления. Поскольку автоматизированные системы диспетчерского управления чаще всего представляют собой уникальные разработки, не имеющие точных аналогов, а анализ всех происходящих в системе физических процессов нецелесообразен, то наиболее применимыми остаются структурные методы расчета, в рамках которых оценка показателей надежности обычно не вызывает особых сложностей, если известны архитектура системы и характеристики составляющих ее частей, а также если принять ряд предположений относительно математической модели поведения объекта; при этом зачастую можно воспользоваться уже готовыми методикамирасчетов [48]. Например, ГОСТ Р 51901.15-2005 [94], описывающий применение марковских методов для вычисления наиболее важных показателей надежности (в случае восстанавливаемой системы—средней наработки на отказ и коэффициента готовности, для невосстанавливаемой — вероятности безотказной работы в течение заданного; времени и средней наработки до первого отказа), содержит ряд предположений;.связанных с вероятностями, в частности: переходы между состояниями являются; статистически: независимыми событиями, интенсивность отказов:Л и интенсивность восстановления fi постоянны, вероятности перехода из одного состояния в другое в малом интервале времени At задаются величинами XAt и fiAt.
К сожалению, обоснованность столь широкого набора упрощений (например, предположения о независимости отказов) зачастую является спорной; к тому же подобные универсальные методики позволяют получить лишь І приблизительные значенияшоказателей надежности всего программно-аппаратного комплекса поскольку не позволяют учесть множество существенных;параметров конкретной системы, ив особенности характеристики уникального программного обеспечения. Более того, оценки надежности автоматизированных систем управления имеет свою специфику, определенную в ГОСТ 24.701-86 [95], которая состоит в том, что помимо показателей, характеризующих надежность реализации функций системы, также используются показатели, характеризующие опасность возникновения аварийных ситуаций как в течение некоторого заданного интервала времени нормального функционирования системы, так и в результате воздействия на систему внеишего экстремального фактора (средняя наработка системы до возникновения в ней j-й аварийной ситуации при нормальных условиях функционирования АСУ — TaBj; вероятность возникновения в системе j-й аварийной ситуации в течение заданного времени г при нормальных условиях функционирования АСУ — QJ{T) , вероятность возникновения в системе j-й аварийной ситуации в результате воздействия 5-го экстремального воздействующего фактора ф8 — Q3{4 a}) В качестве предварительной базовой оценки одного из комплексных показателей надежности — коэффициента доступности автоматизированной системы диспетчерского управления с архитектурой, представленной на рис. 2, рассмотрим часть схемы, состоящую из компьютеров и маршрутизаторов, каждый из которых либо исправен (с вероятностями РСо = PCl — Рс и Рто = Рпч = Рт), либо — нет. Тогда система находится в рабочем состоянии (т. е. в состоянии передавать команды) с вероятностью
Метод оценки надежности на основе теории нечетких множеств
Хотя для рассматриваемого в качества примера-периода тестирования программного обеспечения станции «Заельцовская» условие уменьшения со временем интенсивности обнаружения ошибок выполняется (как будет отмечено ниже, во многом благодаря использованию методики «разработки через тестирование»), то для многих современных программных продуктов это не так, а следовательно применение модели Джелински—Моранды и ее близких аналогов может привести к неверным оценкам. Например, для одного из наиболее качественно сопровождаемых продуктов корпорации Microsoft Windows NT 4.0 в [119] приведены данные, демонстрирующие рост интенсивности обнаружения ошибок при выпуске обновлений многочисленные факты внесения новых ошибок при исправлении найденных- (подтверждающие таблицы вынесены в Приложение D).
Помимо измерительных существует большое количество так называемых статистических моделей надежности, разработанных для оценки количества ошибок программного обеспечения по результатам тестирования. Среди них наиболее известной является модель Миллса ([120]), основанная на идее искусственного внесения в программу определенного количества преднамеренных ошибок («подсев ошибок») перед началом тестирования, затем, пользуясь предположением о равной вероятности обнаружения искусственно внесенных и собственных ошибок, выводится оценка первоначального количества ошибок N = nS/s, где S — количество внесенных ошибок, s — число найденных внесенных ошибок, п — число найденных собственных ошибок (существует несколько вариаций данной модели; например, модель Липова [116]). Еще одна известная статистическая модель [ 103] предлагает проведение тестирования программы двумя независимыми группами испытателей, использующими разные наборы тестов. При этом общее количество ошибок в программе оценивается как N = п\п іІП\ч, где щ и П2 — число ошибок обнаруженных соответственно первой и второй группами, а пм — число ошибок обнаруженных обеими группами. Недостатками этих методов являются низкая точность, вызванная предположением о равновероятности обнаружения разнотипных ошибок, также трудноформализуемый процесс внесения ошибок в первом случае, и повышенные трудозатраты при работе двух групп испытателей — во втором.
Наконец, еще один класс представляют так называемые эмпирические модели надежности, основанные на анализе накопленной информации о характеристиках ранее разработанных программ. Наиболее простые эмпирические модели связывают число ошибок в программном обеспечении с его объемом. На-прмер, фирма IBM использует модель, которая оценивает число ошибок в различных редакциях операционной системы как N = 23Мю + 2М\, где Мю — число модулей, потребовавших 10 и более исправлений, a Mi — число модулей, в которых было обнаружено менее 10 ошибок [104]. Аналогично, модель Хол-стеда оценивает количество ошибок в программе как N = У/ЗООО, где V — «объем» программы, рассчитанный по формуле V — (N\ 4- N2) log2(ni + 712), где N\ — общее количество операторов программы; N2 — общее количество операндов в программе; п\ — число отличающихся операторов; п2 — число отличающихся операндов [102]. Экспериментальная проверка этих моделей для оценки количества ошибок использующегося в качестве примера программного обеспечения станции «Заельцовская» показала значительную неточность данных методов.
Очевидно, что накопленные данные о предыдущих разработках (как в случае модели IBM) не всегда применимы к последующим, поскольку при создании очередного программного продукта используются другие спецификации, возникают отличающиеся по сложности новые задачи, меняется коллектив разработчиков и т. д., поэтому заложенные в расчетах постоянные коэффициенты (23Мю + 2Мь У/3000) и приводят к такой низкой точности результата.
Предложенный в диссертационной работе метод оценки надежности по информации, сохраняемой системой управления версиями, лишен этого недостатка, позволяя учесть уникальную историю разработки конкретного программного продукта.
В процессе исследования предложенного метода оценки надежности выявлено, что проекты, использующие методику «разработки через тестирование» (Test-Driven Development), демонстрируют заметно лучшие характеристики,, в частности, значительно меньшее количество ошибок на момент начала.тестирования. Это объясняется тем, что первоочередное внимание при данной методике разработки уделяется созданию автоматизированных модульных проверок (Unit Tests), выполняющихся после любого завершенного изменения текста программы. Тем самым значительно снижается вероятность внесения ошибок как в процессе исправления обнаруженных проблем, так и при добавлении новой функциональности, что подтверждено многочисленными опубликованными результатами исследований ([121, 122, 123]).
Предложенный метод позволяет получить числовые оценки основных характеристик надежности программного обеспечения, таких как количество невы-явленных ошибок, среднее время наработки на отказ, коэффициент готовности системы, вероятность опасного отказа за интересующий период времени и т. д., по информации, сохраняемой системой управления версиями; дополнительно продемонстрирован способ оценки количества времени, необходимого для поиска и исправления ошибок с целью достижения требуемых эксплуатационных характеристик.
В этом разделе представлена имитационная модель, разработанная для анализа сценариев отказа оборудования и программного обеспечения, которая учитывает влияние внешних факторов на надежность аппаратного и программного обеспечения и позволяет получить числовые оценки таких параметров, как максимальное ихреднее времена потери управления, количество и продолжительность сбоев различного типа, влияние диверсификации ПО на коэффициент готовности системы и т. д.
Похожие диссертации на Разработка и исследование моделей и методов построения автоматизированных систем диспетчерского управления
