Технология надежностного программирования задач автоматизации управления в технических системах

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

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