Министерство образования и науки Российской Федерации 
 
Сибирский федеральный университет 
 
 
 
 
 
 
 
А. А. Ступина, С. Н. Ежеманская 
 
 
 
ТЕХНОЛОГИЯ  
НАДЕЖНОСТНОГО ПРОГРАММИРОВАНИЯ  
ЗАДАЧ АВТОМАТИЗАЦИИ УПРАВЛЕНИЯ 
В ТЕХНИЧЕСКИХ СИСТЕМАХ 
 
Монография 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Красноярск 
СФУ 
2011 

УДК 62-192:681.51 
ББК 32.965 
         С88 
 
 
 
Рецензенты: А. Н. Антамошкин, доктор технических наук, профес-
сор кафедры системного анализа и исследования операций СибГАУ; 
И. Бубряк,  доктор инженерии  Оксфордского  открытого   универ-
ситета 
 
 
 
 
 
 
 
Ступина, А. А. 
С88  Технология надежностного программирования задач автома-
тизации управления в технических системах : монография /               
А. А. Ступина, С. Н. Ежеманская. – Красноярск : Сиб. федер.  
ун-т, 2011. – 164 с. 
ISBN 978-5-7638-2354-7 
 
 
В монографии освещены современные тенденции и направления развития 
в области надежностного программирования, которые позволят повысить произ-
водительность труда и заметно сократить сроки создания сложных комплексов 
программ информационно-управляющих систем. Рассмотренные модели и мето-
ды дают возможность учесть качественную информацию в рамках формального 
процесса оптимизации при решении задач многоатрибутивного выбора, что 
важно для такой области, как программная инженерия  N-вариантных  систем. 
Адресована специалистам по автоматизации управления, студентам и ас-
пирантам. 
 
 
УДК 62-192:681.51 
ББК 32.965 
 
 
 
ISBN 978-5-7638-2354-7 
 
 
 
                 © Сибирский федеральный  
                                                                                                         университет, 2011 

ОГЛАВЛЕНИЕ 
 
 
ВВЕДЕНИЕ……………………………………………………………… 
5
1. ПРОБЛЕМЫ ФОРМИРОВАНИЯ  
    ПРОГРАММНОЙ АРХИТЕКТУРЫ  
    ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ…………….. 
7
1.1. Создание программной архитектуры как этап  
       системного проектирования…………………………………….. 
7
1.2. Архитектурные компоненты системы………………………….. 
12
1.3. Базовый архитектурный модуль программной системы…….. 
21
2. ФОРМИРОВАНИЕ ГАРАНТОСПОСОБНОЙ  
    ПРОГРАММНОЙ АРХИТЕКТУРЫ  
    ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ…………….. 
26
2.1. Надежностное формирование программных архитектур……. 
26
2.2. Избыточное программирование гарантоспособных  
       программных компонентов…………………………………….. 
38
2.3. Применение методологии мультиверсий  
       для отказоустойчивого программного обеспечения…………… 
49
2.4. Модель надежности архитектуры программного  
       обеспечения ИУС………………………………………………… 
54
3. МОДЕЛИ И АЛГОРИТМЫ АНАЛИЗА РИСКА И УЧЕТА 
    НЕОПРЕДЕЛЕННОСТИ ПРИ ВЫБОРЕ ОБЪЕМА  
    ВВОДИМОЙ АРХИТЕКТУРНОЙ ИЗБЫТОЧНОСТИ………....... 
62
3.1. Выбор объема вводимой архитектурной избыточности  
       при полной неопределенности…………………………………. 
62
3.1.1. Выбор метода разработки гарантоспособных  
          компонентов системы и алгоритмы выбора решений… 
64
3.1.2. Экспертные оценки вероятности и их использование…. 
67
3.1.3. Функции полезности…………………………………….. 
69
3.2. Процедура определения дохода от информации…………….. 
71
3.2.1. Вариант реализации архитектурной избыточности  
          с максимальным выигрышем…………………………… 
72
3.2.2. Метод модельного прототипа…………………………… 
73
3.2.3. Математическое ожидание дохода  
          при полной информации………………………………… 
74
3.2.4. Процедура максимизации ожидаемой чистой  
          стоимости при разработке прототипа…………………. 
77
3.2.5. Формализация процедуры определения  
          математического ожидания дохода  
          от полной информации………………………………….. 
78
 

3.2.6. Формализация процедуры определения  
          математического ожидания дохода  
          от неполной информации……………………………….. 
80
3.3. Рекомендации по применению процедуры  
           в рамках экспресс-анализа……………………………………… 
83
3.4. Решение критичных задач ИУС на гарантоспособных  
       программных архитектурах……………………………………. 
86
3.4.1. Структурно-избыточные программные архитектуры: 
          анализ осуществимости решения задач………………... 
86
3.4.2. Процедуры надежностного формирования  
          программных архитектур ИУС………………………… 
88
3.4.3. Однокритериальное формирование состава  
          мультиверсий…………………………………………….. 
96
3.4.4. Многокритериальное формирование состава  
          мультиверсий…………………………………………….. 
101
4. МНОГОАТРИБУТИВНОЕ ФОРМИРОВАНИЕ  
    N-ВАРИАНТНЫХ ПРОГРАММНЫХ СТРУКТУР  
    МУЛЬТИВЕРСИОННЫХ СИСТЕМ……………………………….. 
107
4.1. Модель Боэма оценки стоимости разработки  
       программного обеспечения…………………………………….. 
107
4.2. Многоатрибутивный метод принятия решений  
       на основе качественной информации………………………….. 
113
4.3. Многоатрибутивный метод принятия решений  
       на основе качественной и количественной информации……… 
122
4.4. Выбор варианта модульных структур N-вариантных  
       программных систем……………………………………………. 
128
5. ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ СИСТЕМЫ  
    ФОРМИРОВАНИЯ  ГАРАНТОСПОСОБНОЙ  
    ПРОГРАММНОЙ АРХИТЕКТУРЫ……………………………….. 
134
5.1. Экспресс-анализ архитектуры программного обеспечения…. 
134
5.1.1. Системы автоматизации проектирования  
          программных средств……………………………………. 
134
5.1.2. Методы достижения высокого качества  
          проектирования комплекса программ…………………. 
136
5.1.3. Процедуры экспресс-анализа эффективности  
          функционирования архитектуры ПО………………....... 
138
5.2. Пример анализа архитектуры программного комплекса……. 
140
5.2.1. Исходные параметры компонентов  
          уровней архитектуры……………………………………. 
141
5.2.2. Анализ результатов……………………………………… 
142
ЗАКЛЮЧЕНИЕ………………………………………………………….. 
146
БИБЛИОГРАФИЧЕСКИЙ СПИСОК…………………………………. 
147

ВВЕДЕНИЕ 
 
 
Современная тенденция к расширению сферы работ по автома-
тизации технологических процессов (ТП) относится как к отраслям 
промышленности с дискретным характером производства, так и к 
управлению на транспорте. Успехи разработок и промышленного вы-
пуска средств микропроцессорной вычислительной техники создают 
прочную основу для проектирования и внедрения информационно-
управляющих систем (ИУС) с высокими показателями экономично-
сти и надежности.  
Для рассматриваемого класса автоматизированных систем 
управления (АСУ) при определении состава технических средств и 
технологий акцент делается, прежде всего, на российские разработки 
и предприятия. 
Специфичность области применения – управление техническим 
объектом, функционирующим в реальном времени и реализующим 
технологический процесс, – порождает целый ряд проблем в про-
граммировании ИУС. Однако на современном этапе развития различ-
ные подходы к программированию систем управления имеют тенден-
цию к сближению, а подходящей базой для этого может стать унифи-
кация архитектуры ИУС. Более того, известно, что в технологии мно-
гоуровневого программирования используется концепция архитекту-
ры связи открытых систем, предложенная международной организа-
цией стандартов в качестве эталонной модели построения систем об-
работки данных. Применение ее в приложении к ИУС впервые было 
рассмотрено в работах И.М. Шенброта, М.В. Антропова и К.Я. Дави-
денко. 
Такие показатели качества управляющих программ, как кор-
ректность и помехоустойчивость, определяют надежность программ-
ной архитектуры ИУС. В работе под корректностью понимается спо-
собность программы давать с большой вероятностью правильные ре-
зультаты при всех комбинациях исходных данных, допустимых в 
рамках постановки задачи. Помехоустойчивость – способность про-
граммы с большой вероятностью обнаруживать ошибки, возникаю-
щие в процессе выполнения, и блокировать или уменьшать их вред-
ное влияние.  
Для формирования гарантоспособной программной архитектуры 
ИУС большое значение имеют также время отклика (время реакции 

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

1. ПРОБЛЕМЫ ФОРМИРОВАНИЯ  
ПРОГРАММНОЙ АРХИТЕКТУРЫ  
ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ 
 
 
Вычислительные комплексы завоевали прочные позиции в сис-
темах автоматизации производств и технологических процессов, их 
интенсивное развитие диктуется постоянно растущими потребностя-
ми общества в решении все более сложных задач.  
Расширение исследований в этой области привело к разработке 
ряда методов проектирования и к появлению множества средств для 
автоматизации отдельных технологических операций создания архи-
тектуры программного обеспечения (ПО). Причем средствами авто-
матизации необходимо обеспечить весь жизненный цикл программ-
ного средства, начиная c формирования исходных требований и кон-
чая завершением промышленного производства и эксплуатацией. 
 
 
 
1.1. Создание программной архитектуры  
как этап системного проектирования 
 
 
Внедрение прогрессивных современных технологий позволит 
повысить производительность труда и заметно сократить сроки соз-
дания сложных комплексов программ ИУС. Важное значение имеют 
надежность и обеспечение высокого качества программ. Рост воз-
можностей программ приводит к быстрому увеличению объемов раз-
работок, широте их применения, а также к возрастанию важности вы-
полняемых ими функций в системе. Использование вычислительных 
систем приобретает особое значение при длительной эксплуатации в 
условиях экстремальных нагрузок, а также в областях, где ошибки 
могут привести к таким последствиям, как опасность для жизни чело-
века или большие материальные потери. Характеристики программ 
влияют на экономические показатели предприятий и отраслей, так как 
все больше изменяют технологический и технический уровни произ-
водств и средств автоматизации. 
Среди основных направлений повышения надежности архитек-
туры ПО наиболее перспективным считается разработка методов пре-

дотвращения как самих ошибок, так и условий для их возникновения 
в процессе проектирования ПО. Одним из таких решений является 
структурный подход [122]. Суть структурного подхода – сокраще-
ние ошибок в программах путем их локализации, уменьшения трудо-
емкости их выявления и исправления за счет четких и упорядоченных 
структуры и связей комплекса программ, структурная организация 
процессов проектирования и разработки всех компонентов комплекса.  
Структурный подход – это методология анализа и уточнения 
знаний применительно к объекту путем последовательной, иерархи-
ческой детализации его составляющих. Он опирается на декомпози-
цию объектов по тем или иным признакам, на упорядочение входя-
щих компонентов, организацию их рациональных связей, применение 
модульно-иерархической структуры объекта. Конкретная реализация 
и содержание структурного подхода определяются принадлежностью 
проектируемого объекта к той или иной области и спецификой этой 
области.  
Так, при создании радиоэлектронной аппаратуры структурный 
подход опирается на широко развитые автоматизированные методы 
конструирования различных компонентов, организацию четких и оп-
ределенных связей между частями аппаратуры, обеспечение автоном-
ности и максимальной независимости каждого компонента. Процесс 
создания программных средств, в отличие от аппаратуры, методиче-
ски развит в целом значительно слабее, а применительно к методоло-
гии создания программ ИУС появляются дополнительные проблемы: 
поскольку подобные системы имеют большое число связанных между 
собой компонентов, а также зависимости компонентов друг от друга, 
то возможным становится распространение сбоя от компонента, в ко-
тором он произошел, к другим компонентам. 
Как уже отмечалось, одним из важнейших показателей оценки 
качества проектируемого ПО и его гарантоспособности является на-
дежность, которая определяется как свойство объекта выполнять за-
данные функции, сохраняя во времени значения установленных пока-
зателей. Применительно к современному представлению о надежно-
сти программ следует признать тот факт, что при разработке про-
грамм можно стремиться только к минимизации появления ошибок, а 
не к их полному отсутствию. В связи с этим надежность программ 
трактуется как вероятность появления ошибки в программе по мере 
поступления на ее вход разнородных данных. 

До сих пор надежность программ связывалась с методами от-
ладки и тестирования, степенью и качеством отлаженности программ, 
что вполне отвечает смысловому содержанию понятия «надежность». 
Но с появлением проблем при разработке больших и сложных про-
грамм встает вопрос об увеличении надежности систем на уровне   
архитектуры, что позволит, не повышая надежности отдельных ком-
понентов, повысить надежность системы в целом, избежать распро-
странения ошибки по компонентам системы, а также ускорит процес-
сы поиска, анализа и устранения последствий сбоя в процессе экс-
плуатации. 
Широкое применение средств вычислительной техники породи-
ло понятие «архитектура ПО», которое, несмотря на свою распро-
страненность, воспринимается, как правило, интуитивно и употребля-
ется чаще всего при сравнении вычислительных машин. 
Под архитектурой ПО, как и вообще любых других средств 
переработки информации, понимают в узком смысле совокупность их 
свойств и характеристик, призванных удовлетворить запросы пользо-
вателей.  
Рассмотрим процесс создания архитектуры комплекса программ 
ИУС как этап проектирования системы. 
Разработка архитектуры – это процесс разбиения большой 
системы на более мелкие части [82]. Для обозначения этих частей 
придумано множество названий: программы, компоненты, подсисте-
мы и уровни абстракции. 
Процесс разработки архитектуры – шаг, необходимый при про-
ектировании комплекса программ (КП) ИУС, но не обязательный при 
создании простой программы. Если внешние спецификации описы-
вают КП, то следующий шаг проектирования – разработка архитекту-
ры, а за ним – проектирование структуры программы. Если же внеш-
ние спецификации описывают простую программу, разработка архи-
тектуры системы необязательна. Очевидно, возникает проблема, как 
различать комплексы программ и простые программы. Точных опре-
делений этих понятий нет. Словарь здесь бесполезен, потому что все 
объекты, от операционной системы до подпрограммы и цикла, удов-
летворяют определению комплекс программ. 
КП ИУС представляет собой набор решений множества различ-
ных, но связанных между собой задач. Так, операционная система, 
система резервирования авиабилетов или система управления базами 
данных – все это примеры КП, и поэтому они должны пройти процесс 

разработки архитектуры. Программа редактирования текстов в систе-
ме разделения времени, компилятор, программа учета товаров явля-
ются примерами отдельных программ, и в них этап разработки архи-
тектуры отсутствует.  
Рассмотрим основные подсистемы программной архитектуры 
ИУС, которая работает в реальном времени и является модульной, 
иерархической и распределенной по территории. Архитектура данно-
го ПО строится из четырех основных подсистем [160]: 
– ПО поддержки системы; 
– обрабатывающее ПО (включая обработку запросов оператора, 
выработку управляющих воздействий и т.д.); 
– ПО сопровождения; 
– администрирующее ПО. 
ПО поддержки системы предоставляет рабочую среду, интер-
фейс для контроля аппаратного обеспечения и интерфейс с систем-
ными данными. 
Сервисное ПО, которое присутствует во всех программных сис-
темах, выполняет функции, общие для многих приложений. 
Программы сопровождения, которые в основном присутствуют 
в подсистеме, обрабатывающей запросы пользователей, описывают 
свойства или функции системы. 
Таким образом, компоненты архитектуры ПО выполняют раз-
ные функции и служат различным целям. 
Основная задача архитектуры – это обработка запросов опера-
тора и выработка управляющих воздействий или рекомендаций. Она 
включает идентификацию поступающих запросов, установление ка-
нала связи на время соединения и разъединение по окончании сеанса 
связи. Обработка пользовательских запросов использует различные 
компоненты архитектуры ПО и включает процессы и сообщения, вы-
полняющие различные функции и использующие различные ресурсы 
системы. Программные архитектуры ИУС, работающих в реальном 
времени, требуют администрирования и обслуживания, что также 
предполагает использование различных ресурсов. 
Как показано в работах [119, 158], архитектура должна удовле-
творять строгим требованиям надежности для выполнения различных 
функций и запросов пользователей (см. также [114, 117]). Надежность 
архитектуры включает как надежность центрального ядра системы, 
так и надежность индивидуальных элементов, предоставляемых поль-
зователю. Сбой отдельного элемента приводит к неработоспособно-

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

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

 
Рассмотрим основные принципы выделения иерархических 
компонентов программной архитектуры ИУС.