CC BY
72
символов (на рис. 5 большим прямоугольником показана выделяющая ячейка, меньшим прямоугольником выделена область, внутри которой ищется локальный минимум плотности точек изображения).
Рис. 5. Сегментация текстовых зон
Пусть !Ы(1, у) - изображение группы символов, где I = 1, 2, ..., НО;у = 1, 2, ..., ЖО, здесь НО - высота группы символов, ЖО - ширина группы символов. Вычислим массив средних значений яркости пиксельных столбцов в изображении группы символов:
SО_COL(j) = sum(IM(i, у)) / НО,
где i = 1, 2, ..., НО.
Далее в этом массиве найдем номера столбцов, которые входят в текущую область на правой границе выделяющей ячейки и для которых значения элементов мас-
сива минимальны. Сделаем предположение о том, что эти столбцы представляют собой местоположение связующего символы элемента и происходит коррекция выделяющей ячейки до этого местоположения, а также закраска цветом фона границы выделяющей ячейки. В результате получаются новые параметры выделяющей ячейки, которые заносятся в таблицу для дальнейших операций, и происходит сегментация изображения текстовых зон на отдельные зоны содержащие символы. Последующие параметры выделяющей ячейки (длина, ширина) выбираются как средние между всеми параметрами ячеек, занесенных в таблицу. Таким образом происходит сегментация изображений групп символов на отдельные символы и получается набор сегментированных изображений, которые в дальнейшем могут быть использованы в системе распознавания.
Предложенный выше метод адаптивного выделения символов рукописного текста может эффективно применяться в различного рода системах распознавания и анализа документов, содержащих изображения рукописных символов и текста. Кроме того, этот метод позволяет осуществлять определение угла поворота изображения документа и тем самым обеспечивать дополнительную коррекцию изображения. В настоящее время ведется апробация метода в составе автоматизированного комплекса распознавания документов, содержащих рукописные символы и текст.
A. N. Goroshkin
ADAPTIVE ALLOCATION OF SYMBOLS OF THE HAND-WRITTEN TEXT
The method of hand-written text images segmentation on separate text zones is considered. The method of text zones segmentation on separate symbols with using adaptive procedure of allocating cell tuning is resulted. And also the method of image rotation angle definition is considered.
ХЦК 681.3
И. А. Капчинский, А. С. Кузнецов, А. В. Штенцель
ПРИНЦИПЫ ФОРМИРОВАНИЯ МУЛЬТИВЕРСИОННОГО ПРОГРАММНОГО КОМПЛЕКСА
Рассмотрена методология мультиверсионного программирования, гарантирующая, что ошибки одной из версий не приведут к нарушению процесса управления сложными объектами, к которым предъявляются жесткие требования по надежности и автономности функционирования.
Программные средства, использующиеся в системах управления и информационных системах, обладают всеми свойствами сложных систем: они содержат большое количество (сотни и тысячи) компонентов - модулей, тесно взаимодействующих в процессе решения общей целевой задачи. Программный комплекс (ПК) имеет единую цель функционирования - обработку информации и принятие решений для управления объектами. Для обеспечения взаимодействия компонентов в едином комплексе широко используются иерархические структуры с несколькими уровнями группирования и подчиненности модулей, каждый из которых имеет свою целевую задачу и спе-
цифический частный критерий качества, как правило не совпадающий с критерием эффективности всего комплекса. Однако частные критерии качества модулей и групп программ играют подчиненную роль относительно критериев качества всего ПК и должны способствовать получению их допустимых или экстремальных значений.
Иерархическая структура широко используется при анализе критериев качества всего ПК и его частей. Создание сложных систем с заданными характеристиками при ограниченных ресурсах требует проведения определенного комплекса мероприятий для достижения поставленной цели, получившего название «проект». Целенаправ-
ленное управление проектом предназначено для пропорционального распределения ресурсов между работами по созданию системы на протяжении всего цикла проектирования, вплоть до внедрения системы в серийное производство [1; 2].
В условиях современного динамического развития общества, усложнения технической и социальной инфраструктуры информация становится таким же стратегическим ресурсом, как и традиционные материальные и энергетические ресурсы. Современные информационные технологии, позволяющие создавать, хранить, перерабатывать и обеспечивать эффективные способы представления информационных ресурсов потребителю, стали важным фактором жизни общества и средством повышения эффективности управления всеми сферами общественной деятельности. Стремительное развитие глобальных информационных и вычислительных сетей ведет к изменению фундаментальных парадигм обработки данных, которые можно охарактеризовать как переход к распределенным ресурсам и создание инфраструктуры для свободного доступа к ним. На первое место в современном информационном обществе выходят технологии использования распределенных информационно-вычислительных ресурсов.
Практически все большие программные системы являются распределенными. Распределенной называется такая система, в которой обработка информации сосредоточена не на одной вычислительной машине, а распределена между несколькими компьютерами. При проектировании распределенных систем, которое имеет много общего с проектированием любого другого программного обеспечения, следует учитывать ряд их специфических особенностей [3].
До недавнего времени все большие системы в основном являлись централизованными, которые запускались на одной главной вычислительной машине (мэйнфрейме) с подключенными к ней терминалами. Терминалы практически не занимались обработкой информации, и все вычисления выполнялись на главной машине. Разработчикам таких систем не приходилось задумываться о проблемах распределенных вычислений и обеспечения их надежности. Но сейчас все обстоит иначе, и проблема формирования мультиверсионного программного обеспечения для реализации распределенных вычислений
приобрела большую актуальность. Основной задачей является оптимизация версионного состава программного комплекса, в качестве критерия которой обычно выбирают надежность комплекса.
Все принципы и методы обеспечения надежности в соответствии с их целью можно разбить на четыре группы: предупреждение ошибок, обнаружение ошибок, исправление ошибок и обеспечение устойчивости к ошибкам [4]. К первой группе относятся методы, позволяющие минимизировать или вообще исключить ошибки. Методы второй группы сосредоточивают внимание на функциях самого программного обеспечения, помогающих выявлять ошибки. К третьей группе относятся функции ПК, предназначенные для исправления ошибок или их последствий. Четвертая группа связана с устойчивостью к ошибкам - мерой способности программного комплекса продолжать функционирование при наличии ошибок.
Концепция мультиверсионного программирования, как подход к реализации программной отказоустойчивости была введена А. Авижиенисом в 1977 г. [5]. Употребляемый в литературе термин «N-версионное программирование» (N-Version Programming, NVP) является эквивалентным и многократно фигурирует в сокращенных обозначениях данной методологии.
Мультиверсионное программирование было определено А. Авижиенисом как независимая генерация N > 2 функционально эквивалентных программ в соответствии с идентичными исходными спецификациями на проектирование ПК (рис. 1). Для этих N программ предоставлены средства конкурентного исполнения, по ходу которого в точках перекрестного контроля (cross-check points, cc-points) программами генерируются векторы сравнения (comparison vectors, c-vectors). Составляющие векторов сравнения и контрольные точки генерации векторов сравнения предварительно определены еще на этапе исходных спецификаций.
Под независимой генерацией программ в данном контексте понимается организация проектирования ПК с тем, чтобы каждая группа из N вовлеченных в разработку отдельных программных модулей не взаимодействовала с другой по отношению к процессу реализации ПК (рис. 2). По возможности каждая из групп разработчиков должна использовать различные алгоритмические, инструментальные и языковые средства проектирования.
Версии
—ГГ" / \
* *
K
■™ГГ" / \
* *
K
Рис. 1. Структура мультиверсионного программного комплекса
В последующие годы многочисленные теоретические и прикладные исследования в области методологии мультиверсионного программирования выявили три его элемента, которые являются базовыми при синтезе отказоустойчивого программного обеспечения:
- процесс исходной спецификации и мультиверсионного программирования (NVP), который предполагает гарантию независимости и функциональной эквивалентности N индивидуальных процессов программирования;
- результат процесса мультиверсионного программирования - мультиверсионное программное обеспечение (N-Version Software, NVS), для которого имеются в наличии средства конкурентного исполнения со специфическими точками контроля и векторами сравнения;
- внешние средства поддержки исполнения версий ПО (N-Version Executive, NVX), которые обеспечивают выполнение NVS и предусматривают алгоритмы принятия решений (decision algorithms) в контрольных точках.
Все эти элементы NVP объединены целью независимой и конкурентной генерации функционально эквивалентных программных компонентов (версий), после исполнения которых и будет принято решение о правильности функционирования ПО (конечно, в этих элементах совершенно нет необходимости в случае использования одной версии программы). Таким образом, концепция мультиверсионного программирования как подход к созданию отказоустойчивого ПО вводит такие новые направления исследований в области инжиниринга программного обеспечения, как NVP, NVS и NVX.
Первые предложения по применению множественных версий ПО начали появляться по мере развития компьютерной техники и эволюции методов и средств обнаружения и исправления ошибок еще в начале 1970-х гг Первоначально возник термин «избыточное программирование» (redundant programming) [6] с решающей функцией, аналогичной мажоритарной схеме голосования в технических системах, и лишь позднее при систематиза-
ции этот метод был переименован в мультиверсионное программирование (NVP).
Другое не менее известное направление развития отказоустойчивого ПО - использование блока восстановления (Recovery Block Approach, RB), ставшего результатом долговременных исследований в области вычислительных систем высокой надежности, инициированных Б. Ранделлом [7]. Схема с восстановительным блоком (рис. 3) соответствует методу динамической избыточности в технике и подразумевает наличие M > 2 альтернатив и приемочного теста (acceptance test), причем RB в большей степени направлен на подавление ошибок в системах реального времени при корректной работе аппаратных средств.
По аналогии с многоканальными аппаратными средствами, работающими в критических условиях с повышенными требованиями по отказоустойчивости (наземные и бортовые комплексы управления летательными аппаратами, включая космические, компьютеризированные средства управления атомными реакторами и другими опасными для жизни людей объектами), также предоставляющими собой N > 2 аппаратных блоков, для NVP необходимо расширение простого ПО путем добавления в него избыточных версий программных блоков [8]. Наличие избыточных компонентов предполагает компенсацию тех версий программ, у которых в контрольных точках обнаружены сбои, отказы или ошибки. Следует отметить, что существенным отличием аппаратных средств от программного обеспечения является неэффективность метода простого дублирования для поддержания устойчивости к ошибкам в программном комплексе. Это связано с тем, что простое дублирование элементов, эффективное против случайных ошибок, имеющих физическую природу, в технических системах, не эффективно при отказах программного обеспечения, так как оно предопределяет дублирование не обнаруженных на этапе отладки («спящих») ошибок в программах. Поэтому N про-
СИ
X,a
xb
xc
с
j-й модуль мультиверсионного
по
Версия 1
Версия 2
Версия 3
Среда исполнения
Функция поддержки исполнения
Алгоритмы решения [
-► X,a
с
xb
xc
Расширения программного модуля дХя отказоустойчивого исполнения
Рис. 2. Модель мультиверсионного ПК при n = 3 20
граммных версий должны разрабатываться отдельно и независимо друг от друга, что и соответствует концепции проектирования избыточного программного обеспечения.
Однако наличие N > 2 избыточных версий программных модулей еще не обеспечивает устойчивость ПК к отказам, так как необходимо еще и наличие среды исполнения (Execution Environment, EE) для NVS. Как отдельные версии ПО, так и среда исполнения должны отвечать следующим требованиям:
- среда исполнения должна предусматривать функции поддержки исполнения N > 2 версий программных компонентов в режиме контроля ошибок;
- индивидуальные спецификации версий ПО должны определять способы достижения отказоустойчивого исполнения, которые поддерживаются в среде исполнения;
- наилучший исход NVP должен минимизировать вероятность необнаружения (или невозврата для схемы с блоком восстановления) ошибочного исполнения муль-тиверсионного программного компонента в отличие от обычной программной системы.
Общим для методологии мультиверсионного программирования и схемы с восстановительным блоком является наличие двух или более избыточных компонентов (в NVS они названы версиями, а в RB - альтернативами с приемочным тестом). А основное отличие заключается в методе, с помощью которого принимается решение о результатах работы программ: для мультиверси-онного программирования это решающий алгоритм, который функционирует в составе среды исполнения, для схемы с блоком восстановления - приемочный тест результатов работы одной из альтернатив, который специфичен для каждого отдельного приложения и, кроме того, может и не являться частью среды исполнения. Возможны различные комбинации базовых схем, а также расширение функций среды исполнения как для мультиверси-онного программирования (например, многоуровневый решающий алгоритм, общий или индивидуальный восстановительный блок для мультиверсионной программы), так и для схемы с блоком восстановления (напри-
мер, кэш-память для восстановления программных компонентов, многоуровневый иерархический приемочный тести т. д.).
Однако реализация восстановительного блока в обоих подходах имеет свои ограничения: в ИВ-схеме ошибки, которые не будут обнаружены приемочным тестом, не приведут к переключению на восстановление при функционировании ПО; в NVS-схеме переключение на восстановление будет неверным, если большинство версий предоставит ошибочный результат в точке восстановления. Очевидно, что ИВ- и NVS-модели сближаются, если приемочный тест выполняется с использованием NVS-метода, а решающему алгоритму NVS предшествует приемочный тест, а также в случае когда решающий алгоритм не способен сделать выбор.
После определения основных элементов мультиверси-онного программирования отметим его проектные этапы:
- спецификация версий NVS-систем ПО с учетом требований к их дальнейшему конкурентному исполнению в ЕЕ-среде с использованием внешних средств поддержки исполнения NVX;
- непосредственно этап программирования, связанный с выполнением основного требования NVP - максимальной независимости исходов процесса и, соответственно, версий ПО;
- создание №УХ-систем среды исполнения программных компонентов мультиверсионного ПО с высокой надежностью и эффективными показателями по времени исполнения, что особенно важно для использования муль-тиверсионных ПК в комплексах управления системами реального времени.
Первый этап основывается на применении системы спецификаций мультиверсионного ПО, названной У-спе-цификацией (У^рес), которая будет определять следующие характеристики:
- функциональное предназначение с учетом ограничений по времени исполнения, исходных данных и начального состояния версии;
- требования по внутреннему контролю ошибок и тестированию версий модуля;
Рис. 3. Модель схемы ПК с восстановительным блоком
- требования по диверсификации программирования;
- контрольные точки (сс-points), в которых для контроля всех версий предполагается применение решающего алгоритма NVX-среды;
- точки восстановления (recovery points, r-points), в которых осуществляется применение блока восстановления ошибочно выполненных версий;
- параметры решающего алгоритма NVX-среды, используемые в каждой сс- и r-points;
- возможные исходы исполнения в NVX-среде, включая случай когда решающий алгоритм не способен принять решение.
Что касается систем поддержки мультиверсионного исполнения, то в их основные функции входят:
- решающий алгоритм или множество алгоритмов;
- входные последовательности данных для всех версий;
- внутриверсионная коммуникация;
- синхронизация исполнения версий (если позволяет аппаратно-программный комплекс) при жестких временных ограничениях;
- локальное управление исполнением каждой версии;
- глобальное исполнение мультиверсионного ПК в совокупности с решающими функциями восстановления ошибочных версий по точкам востановления (локальный восстановительный блок в составе среды мультиверси-онного исполнения).
Смысл проектной парадигмы мультиверсионного программирования проиллюстрируем с учетом их взаимосвязи с традиционными этапами жизненного цикла ПО. Парадигма проектирования мультиверсионных ПК преследует достижение следующих целей:
- уменьшения вероятности проектных недочетов, ошибок и несообразностей в процессе разработки и тестирования мультиверсионных ПК;
- устранения большинства ошибок, обнаруженных на этапе проектирования, в независимо генерируемых версиях программ и установления причин ошибок, не отслеженных на этапе проектирования;
- минимизации вероятности выдачи совершенно идентичных ошибочных результатов двумя или более программными версиями.
Необходимость применения специально организованного сопровождения мультиверсионного ПК - это требование для реализации диверсификации методов проектирования для каждой из версий, что является ключевым моментом парадигмы мультиверсионного программирования. Выбранный метод проектирования версии
должен обеспечивать полную независимость (с учетом ошибок ПО) всех конкурентно разрабатываемых версий; максимально способствовать разнообразию всех версий каждого программного модуля; вырабатывать эффективный механизм обнаружения ошибок и восстановления (восстановительный блок).
Итак, можно отметить, что в настоящее время муль-тиверсионное программирование является возможной альтернативой и дополнением методов тестирования и доказательства правильности программ, обеспечивая высокий уровень надежности исполнения критичных по сбоям и ошибкам программных компонентов. Наконец, на этапе сопровождения отказоустойчивого ПО при его развитии и модификации основное внимание должно быть направлено на разработку V-спецификаций, что позволяет привлекать к разработке мультиверсионных компонентов специалистов из отрасли приложения проектируемой системы и основное внимание уделять разработке надежного программного обеспечения.
Библиографический список
1. Гантер, Р. Методы управления проектированием программного обеспечения : пер. с англ. / Р. Гантер, Е. К. Масловский. М. : Мир, 1981.
2. Танненбаум, Э. Распределенные системы. Принципы и парадигмы / Э. Танненбаум, М. Ван Стен. СПб. : Питер, 2003.
3. Соммервилл, И. Инженерия программного обеспечения / И. Соммервилл. М. : Вильямс, 2002.
4. Майерс, Г. Надежность программного обеспечения / Г. Майерс ; пер. с англ. Ю. Ю. Галимова ; под ред.
В. Ш. Кауфмана. М. : Мир, 1980.
5. Avizienis, A. On the implementation of N-version programming for software fault-tolerance during execution / A. Avizienis, L. Chen // Proc. IEEE COMPSAC-77, Nov. 1977. Р. 149-155.
6. Avizienis, A. Fault tolerance and fault intolerance: complementary approaches to reliable computing / A. Avizienis // Intern. Conf. on Reliable Software, Apr. 1975. P. 458-464.
7. Лебедев, В. А. Параллельные процессы обработки информации в управляющих системах / В. А. Лебедев,
Н. Н. Трохов, Р. Ю. Царев ; НИИ систем упр., волновых процессов и технологий. Красноярск, 2001.
8. Kovalev, I. V. System of Multi-Version Development of Spacecrafts Control Software / I. V. Kovalev. Sinzheim : Univ. Verl., 2001.
I. A. Kaptchinsky, A. S. Kuznetsov, A. V. Shtentsel
FORMATION METHODS OF THE MULTI-VERSION PROGRAM COMPLEX
The multi-version programming methodology is considered. This method guaranties the control process realization in spate of version errors. This situation is characteristic for complex objects which operate under the conditions of autonomy.
