Нетрудно заметить, что для соблюдения этого соотношения необходимо для каждого класса Pdass i найти такой класс P class ь чтобы соблюдалось соотношение P*^ i<^Pciass i=Pciass i или множество классов (P'class i^P'class • • O^P/ass i =
*
P class i •
В результате условие (5) можно переопределить как условие V ie 1, •.., N3 k,j, •.el, •..,M:
(P* и P* и "ini P = P (6)
y class k class j "'J class i class i' V
При соблюдении данного условия критическая ошибка первого рода не увеличивается.
Таким образом, рассмотренная система на основе технологии защиты от исследования не должна увеличивать критическую ошибку первого рода по сравнению с системой PHP-IDS. Из 70 правил регулярных выражений PHP-IDS было отобрано 57 нужных (удовлетворяющих критериям нарушения конфиденциальности, целостности и доступности), которые соответствуют функции ценности системы, и для них в соответствии с утверждением (6) найдены перекрывающие условия.
Таких условий 78. Они и легли в основу программной системы защиты от исследования вебсервера Reflexion Web [5]. Таким образом, удалось спроектировать программную систему защиты интернет-ресурсов, не увеличивающую количество уязвимостей (ошибок первого рода) по сравнению с признанным на сегодняшний день мировым лидером в области инструментов обеспечения безопасности веб-ресурсов, но при этом добавив не использованный им ресурс снижения преднамеренных рисков - применение методов защиты от исследования систем. Это является существенным
шагом в области формирования нового поколения систем интернет-безопасности.
Литература
1. Лакатос И. Доказательства и опровержения. Как доказываются теоремы. М.: Наука, 1967.
2. Стюгин М.А. Защита систем от исследования. Методы и модели построения защищенных систем и управления информацией в конфликте. Германия: LAP, 2011. 132 с.
3. Семенкин Е.С., Стюгин М.А. Защита от исследования и ее применение в системах безопасности // Вестн. СибГАУ. 2009. Вып. 2 (23). С. 66-70.
4. Стюгин М.А. Методы защиты от исследования систем // Информационные войны. 2009. № 4. С. 23-29.
5. PHP IDS, Web Application Security 2.0. URL: http:// phpids.org/ (дата обращения: 17.12.2012).
6. Семенкин Е.С., Стюгин М.А. Повышение информационной безопасности веб-сервера методом защиты от исследования // Программные продукты и системы. 2009. № 3.
7. Reflexion Web. URL: http://web.infosafety.ru/ (дата обращения: 17.12.2012).
References
1. Lakatos I., Proofs and Refutations: The logic of mathematical discovery. Cambridge, Cambridge University Press, 1976.
2. Styugin M.A., Zashchita sistem ot issledovaniya. Metody i modeli postroeniya zashchishchyonnykh sistem i upravleniya informatsiey v konflikte [Protection of system from research. Methods and models of protected systems creating and information management in conflict], Germany, LAP, 2011, 132 p.
3. Semenkin E.S., Styugin M.A., Zaschita ot issledovaniya i eyo primenenie v sistemakh bezopasnosti, 2009, no. 2 (23), pp. 66-70.
4. Styugin M.A., Informacionnye vojny, 2009, no. 4, pp. 23-29.
5. PHP IDS, Web Application Security 2.0, Availabel at: http://phpids.org/ (accessed 17 Dec. 2012).
6. Semenkin E.S., Styugin M.A., Programmnye produkty i sistemy, 2009, no. 3.
7. Reflexion Web, Availabel at: http://web.infosafety.ru/ (accessed 17 Dec. 2012).
УДК 681.3.06
КОНЦЕПТУАЛЬНЫЕ ОСНОВЫ ПОСТРОЕНИЯ АНАЛИЗАТОРА БЕЗОПАСНОСТИ ПРОГРАММНОГО КОДА
А.С. Марков, к.т.н., доцент, генеральный директор;
A.А. Фадин, руководитель департамента разработки;
B.Л. Цирлов, к.т.н., доцент, исполнительный директор (НПО «Эшелон», ул. Электрозаводская, 24, г. Москва, 107023, Россия,
[email protected], [email protected], [email protected])
Рассмотрены вопросы автоматизации процедур аудита безопасности исходных текстов программ и поддержки эксперта в принятии решений о наличии дефектов безопасности в исследуемом программном обеспечении. Проведен сравнительный анализ известных статических анализаторов программного кода. Обосновывается применимость статического сигнатурного анализа (по шаблону) для выявления дефектов и уязвимостей программ.
Предложены принципы построения и структура анализатора безопасности программного кода, сочетающего синтаксический и семантический анализ кода. Определены требования к базе сигнатур. Приведен алгоритм функционирования анализатора безопасности программного кода. Показана эффективность предложенного решения с точки зрения добавления новых языков и сред программирования, а также новых классов дефектов безопасности.
Приведен пример работы анализатора программного кода, демонстрирующий его эффективность при выявлении широкого класса дефектов и уязвимостей.
Ключевые слова: безопасность программ, аудит безопасности кода, статический анализ, сигнатурный анализ, дефекты безопасности, уязвимости, недекларированные возможности.
CONCEPTUAL FRAMEWORK OF BUILDING SECURITY CODE ANALYZER
MarkovA.S., Ph.D., Associate Professor; Fadin A.A., Head of Development;
Tsirlov V.L., Ph.D., Associate Professor, Executive Director (NPO «Echelon», 24, Elektrozavodskaya St., Moscow, 107023, Russia [email protected], [email protected], [email protected]) Abstract. The problems of software security audit automation and support of decisions about software defects are considered. A comparative analysis of known static code analyzers is done. The applicability of static signature analysis (on pattern) to identify defects and vulnerabilities are justified.
The principles of construction and structure of the security code analyzer that combines syntactic and semantic code analysis are proposed. The requirements for the signature database are described. The algorithm of the operation of the security code analyzer is given. The efficiency of the proposed solution in terms of adding new languages and programming environments as well as new classes of security defects is shown.
The example of the security parser code that demonstrates its effectiveness in identifying a broad class of defects and vulnerabilities is done.
Keywords: security software, security code review, static analysis, signature analysis, security flaws, vulnerability, undeclared possibilities.
Противоречие между затратами на блокирование критических уязвимостей ПО и требованиями по безопасности применения информационных систем определяет задачу внедрения эффективных средств аудита безопасности программ на начальных стадиях их проектирования и разработки. Опыт испытаний программных средств защиты информации и аудита безопасности программного кода показал, что наиболее эффективным подходом к выявлению дефектов безопасности программ является использование средств автоматизации статического анализа (инспектирования) безопасности кода [1]. Применение статического анализа кода также регламентировано рядом стандартов, включая руководящий документ Гостехкомиссии России. К сожалению, популярные статические анализаторы программного кода позволяют автоматизировать выявление ограниченного подмножества ошибок (например некорректности кодирования, мертвый код, ошибки портирова-ния), не касаясь явно вопросов безопасности программных систем. В данной работе рассматриваются реализационные основы анализатора безопасности программного кода, сочетающего синтаксический и сигнатурный (шаблонный) анализ текста программ с целью выявления всевозможных дефектов, влияющих на безопасность системы.
Средства статического анализа программного кода
Подходы к аудиту безопасности программ можно разделить на две основные категории: статический анализ и динамическое тестирование. Динамические методы наиболее востребованы при исследовании программ методом черного ящика, когда имеется доступ лишь к отдельным интерфейсам ПО. Указанные методы популярны при тестировании корректности и устойчивости функционирования программ, но малоэффективны при поиске ошибок, связанных с комбинациями редко
используемых входных данных, например ошибок, внесенных преднамеренно.
В случае полного доступа к программной системе и ее исходным текстам чаще всего применяются методы статического анализа, использующие исходные и загрузочные модули программного приложения и дополнительную информацию, связанную, как правило, со средой компиляции и выполнением программных компонентов. Достоинствами статического анализа кода являются отсутствие необходимости в астрономических прогонах программ при разных условиях функционирования и возможность добиться большей степени автоматизации проверок на наличие дефектов программ исходя из их конструктивных признаков.
Среди наиболее популярных анализаторов исходного кода выделим следующие: Qstudio, Understand for C, doxygen, Rational Rose, PVS-Studio, «АИСТ-С», «АК-ВС», Fortify, rats, FindBugs, которые можно классифицировать по их целевому назначению:
- расчет метрик и оценка качества кода;
- структурный анализ и документирование исходных текстов;
- метапрограммирование и содействие в пор-тировании кода;
- анализ соответствия исходных текстов требованиям нормативных документов по контролю отсутствия недекларированных возможностей;
- анализ дефектов и уязвимостей программного обеспечения.
Две последние категории анализаторов кода рассмотрим более подробно, так как их использование явно или неявно регламентировано российской нормативной базой. Такие анализаторы на основе проверки исходных текстов программ и различной проектной метаинформации, связанной с архитектурой приложений (зависимости, проектные файлы), позволяют эксперту получить перечень позиций в коде программы, где предположительно находятся потенциально опасные конструкции (ПОК). Это могут быть архитектурные
ошибки (например недостатки проектирования механизмов безопасности), некорректности кодирования (например ошибки переполнения буфера), а также ошибки, искусственно внесенные по халатности (фрагменты отладочного кода или фа-зинга) или целенаправленно (программные закладки). Заметим, что фрагмент кода с ПОК подлежит ревизии со стороны тестировщика, который окончательно идентифицирует дефект программы и возможность его реализации.
Основным недостатком известных анализаторов является не столько ограниченность применения (поддержка ограниченного множества языков, как правило, C/C++), сколько неспособность учитывать результаты собственного синтаксического анализа языка исходных текстов при поиске сигнатур. Этот недостаток не позволяет обеспечить открытую масштабированную архитектуру анализатора с точки зрения добавления новых языков и сред программирования, а также новых классов дефектов безопасности.
Следует отметить, что в литературе статический анализ программ часто понимают в узком смысле, а именно как синтаксический анализ кода. Наиболее известные примеры такого анализа -анализ дерева кода, потока управления, потока данных, потока данных с выбором пути [2, 3]. При этом достаточно часто недооценивается роль сигнатурного анализа (по шаблону [1]) в исследовании кода, который позволяет преодолеть ряд недостатков, присущих перечисленным выше подходам.
Главная проблема в том, что подавляющий пласт дефектов безопасности выявляется не на уровне, например, абстрактного дерева синтаксиса кода, а на уровне семантики, когда необходимо проверить такие высокоуровневые положения, как, например, было ли в этой области кода обращение к устаревшей функции API с указанием жестко прописанного пути к файлу. Данное утверждение можно легко и достаточно надежно проверить с помощью сигнатурного анализа. Попытка ориентироваться лишь на содержимое абстрактного синтаксического дерева кода приведет к сложности учета всех вариаций синтаксических конструкций, содержащих подобную ПОК. Кроме того, современные динамические языки программирования (Python, Perl) дают возможность менять дерево кода «на лету», что позволяет довольно эффективно бороться с подобным подходом к анализу. Направления, связанные с анализом потоков команд, достаточно часто пасуют перед современными сложными многопоточными программами, которым присущи метапрограммиро-вание, полиморфизм, динамические объекты. Они эффективны лишь при решении ограниченного круга задач поиска, например поиска упомянутых ранее некорректностей кодирования, ошибок пор-тирования и т.д.
Именно поэтому для преодоления недостатков, описанных выше, был разработан и апробирован анализатор безопасности кода, имеющий модульную структуру и реализующий преимущества совмещения результатов синтаксического и сигнатурного анализов исходных текстов с целью выявления ПОК.
Принципы работы анализатора безопасности кода
Разберем принципы работы данного анализатора, совмещающего результаты синтаксического и семантического анализа кода.
Совмещение результатов осуществляется на основе сравнения позиций элементов иерархического представления программы, полученных в результате лексического и синтаксического анализа, с позициями паттернов (шаблонов) конструкций, обнаруженных при сигнатурном анализе. Зная позиции (в файлах исходных текстов) каждого из элементов, эксперт может сопоставить узлы абстрактного синтаксического дерева найденным сигнатурам и на основе правил логического вывода оценить возможность нахождения в этом фрагменте исходных текстов потенциально опасных конструкций.
Для реализации указанных принципов был предложен анализатор безопасности кода со следующей структурой: CSA=(SDB, HDB, MLA, MSA, MSY, MLO, MRP), где SDB - БД сигнатур (паттернов) ПОК; HDB - БД структурной информации о коде (иерархического представления программы); MLA - программный модуль лексического анализа; MSA - программный модуль синтаксического анализа; MSY - программный модуль сигнатурного анализа; MLO - программный модуль логического вывода; MRP - программный модуль построения отчетов.
Рассмотрим алгоритм работы анализатора безопасности кода. Модули лексического и сигнатурного анализа принимают на вход исходные тексты программ, их бинарный код, а также общие сведения о декомпозиции ПО. На выходе генерируется отчет о ПОК, состоящий из перечня участков кода, где они предположительно находятся, и необходимые комментарии.
Для классификации и группировки различных видов потенциально опасных конструкций используется международная таксономия CWE (Common Weakness Enumeration), где наиболее полно перечислены дефекты в области безопасности ПО [4].
На рисунке 1 показана функциональная схема анализатора безопасности кода, решающего сформулированные выше задачи.
Прокомментируем функциональную схему анализатора. Задача лексического анализатора состоит в распознавании лексем в коде программы,
Рис. 1. Схема работы анализа безопасности кода
файлах конфигурации и бинарных файлах различного назначения. В данном случае лексема -это просто допустимая последовательность входных символов, которая может быть описана различными способами, например набором регулярных выражений.
Задача синтаксического анализатора заключается в том, чтобы на основе цепочки распознанных лексем сформировать в базе структурной информации дерево структурной декомпозиции программы, одной из ветвей которого является абстрактное синтаксическое дерево (дерево Канторовича [5]). Данный модуль, как правило, содержит в себе конечный автомат для распознавания цепочек лексем, который может быть реализован, к примеру, с помощью ЬЯ(1)-парсера, то есть синтаксического анализатора, выполняющего восходящий синтаксический разбор с предосмотром текста на один символ вперед. Надо сказать, что компилятор любого языка программирования содержит подобный модуль синтаксического разбора. К сожалению, большинство из этих модулей замкнуто и не позволяет выдать результат своей работы в унифицированном для обмена с другими программами виде. Кроме того, у средств аудита безопасности кода несколько иные требования к синтаксическому анализатору, например, он должен быть более толерантным к структуре исходных текстов и, встретив незнакомую лексему, попытаться продолжить анализ файла насколько это возможно, а не остановиться, выдав ошибку, как это сделает синтаксический анализатор из состава компиляторов.
Сигнатурный анализатор осуществляет сквозной поиск в исходных текстах программы паттернов ПОК, используя базу сигнатур, которая представляет собой набор следующих кортежей: ЖБ=(РЕ, БЬ), где РЕ - описание фрагмента ПОК (например, используя регулярные выражения); БЬ - оценка степени их опасности (например числовая шкала 1-10).
Модуль логического вывода сравнивает структурную информацию кода и данные сигнатурного анализа, на основе чего формирует заключение о возможности присутствия ПОК в том или ином участке кода.
Пример работы анализатора безопасности кода
Проиллюстрируем предложенный подход к поиску ПОК на следующем примере. Пусть имеется исходный текст абстрактного языка программирования:
Obj1() >> [func2(), 1602-3]
Obj2() << [! MAX_ALLOWED_VALUE), Obj3.func1(), NULL]
В лексическом анализаторе заданы некоторые определения лексем, причем для наглядности в виде текстовых описаний, а не как регулярные выражения, к тому же из них исключены разделители конструкций.
Лексема A - название идентификатора программы (переменная, функция и т.п.).
Лексема B - класс различного вида операций (+|*/>>).
Лексема C - класс префиксных операций (инверсия, разыменование и др. (! *~)).
Лексема D - пустой литерал (нулевое значение).
Лексема F - числовой литерал (значение).
При таких условиях исходный текст будет преобразован лексическим анализатором в цепочку лексем:
ABAFFBABCFAAD
В данном случае требуется найти потенциально опасные фрагменты кода, содержащие возможные дефекты безопасности.
Пусть синтаксический анализатор содержит некоторый набор правил вывода для построения дерева:
Правило 1: AB <Правило 2>
Правило 2: A
Правило 2: CF <Правило 4><Правило 5>
Правило 2: F <Правило 3>
Правило 3: FB
Правило 4: АА
Правило 5: D
Пример некоторого содержимого базы сигнатур (паттернов сигнатурного анализа):
Сигнатура № 1:
Если в коде встречается последовательность СВ, то, вероятно, здесь находится потенциально опасная конструкция № 2, опасность которой оценивается как 7 (по шкале 1-10).
Сигнатура № 2:
Если в коде встречается последовательность FB, то, вероятно, здесь находится потенциально опасная конструкция № 3 (использование побитовых операндов вместо логических), опасность которой оценивается как 7 (по шкале 1-10).
Зададим пример правила вывода, содержащегося в модуле логического вывода:
Уязвимость № 1:
Если внутри узла дерева типа «Правило 4» будет найдена сигнатура № 2, то выдаем на выход информацию о найденной уязвимости № 1 с коэффициентом 0,7.
Уязвимость № 2:
Если внутри узла дерева типа «Правило 2» будет найдена сигнатура № 2, то выдаем на выход информацию о найденной уязвимости № 2 с коэффициентом 0,8.
Если итоговый коэффициент уязвимости превысит 5, то эта информация попадает в отчет.
<...>
Рассмотрим работу анализатора безопасности кода (см. рис. 1) на входных условиях приведенного примера.
1. Для заданной последовательности лексем синтаксический анализатор сформирует соответствующее ей дерево структурной декомпозиции программы в базе структурной информации (рис. 2).
Правило 1 (1-3)
Программа
Правило 2 (4-6)
Правило 1 (7-13)
AB(1-2)
Правило 2 (3-3) A(3)
F (4)
N Правило 3 (5-6) FB (5-6)
- AB(7-8)
CF(9-10)
/
ч Правило 2 (9-13) \ Правило 4 (11-12)
— AA (11-12)
Правило 5 (13)
— D (13)
Рис. 2. Пример дерева синтаксического анализатора
На рисунке 2 показана иерархическая структура разобранной программы, в каждом из узлов которой будет содержаться либо номер правила, либо непосредственно распознанная цепочка символов. В скобках указаны номера символов во входной последовательности, которым соответствует данный узел иерархии. Эта информация не-
обходима для сопоставления результатов синтаксического и сигнатурного анализа; например, в случае настоящей программы координата задается в виде номера столбца и строки в коде либо как смещение от начала файла с исходными текстами.
2. Модуль сигнатурного анализа в 5-м и 6-м символах входной последовательности на основе базы сигнатур, представленной выше, обнаружит ПОК № 1 с оцениваемой опасностью 7.
3. Модуль логического вывода выполнит следующие действия:
- определит, что найденная ПОК № 1 относится к узлу дерева FB по ее координатам (5-6) (см. ранее содержимое цепочки выходных лексем);
- определит, что сработало правило для уязвимости № 55, то есть ПОК № 1 находится внутри узла «Правило 2»;
- вычислит итоговый коэффициент уязвимости (5,6), умножив степень ее опасности 7 на коэффициент правила по уязвимости 0,8;
- сформирует строку отчета, поскольку итоговый коэффициент (5,6) превышает пороговое значение фильтра 5.
4. Модуль построения отчета сформирует адрес участка (5-6) предполагаемой уязвимости № 2.
Рассмотренный в данной работе анализатор безопасности программного кода обеспечивает автоматизацию процедур аудита исходных текстов и поддержку эксперта в принятии решения о наличии дефекта безопасности в исследуемом программном приложении. Предложенный подход по сопоставлению результатов сигнатурного и синтаксических анализаторов позволяет, с одной стороны, оперативно обнаруживать типовые конструкции в коде на основе пополняемой базы паттернов, с другой - учитывать особенности синтаксических конструкций того или иного языка программирования.
Данный подход реализован при разработке средства анализа безопасности программного кода «АК-ВС», которое было апробировано при сертификационных испытаниях 73 программных средств защиты информации. В процессе работы со средством анализа и последующего рецензирования кода экспертами успешно выявлены множество уязвимостей программных систем (в основном связанных с переполнениями буфера, гонками, загрузкой недоверенных файлов) и программные закладки (парольные закладки, генераторы паролей, временные бомбы).
Литература
1. Марков А.С., Миронов С.В., Цирлов В.Л. Выявление уязвимостей в программном коде // Открытые системы. СУБД. 2005. № 12. С. 64-69.
2. Глухих М.И., Ицыксон В.М. Программная инженерия. Обеспечение качества программных средств методами статического анализа. СПб: Изд-во политехн. ун-та, 2011. 150 с.
3. Колосов А.П., Рыжков Е.А. Применение статического анализа при разработке программ // Изв. Тульского гос. ун-та. Сер.: Технич. науки. 2008. № 3. С. 185-190.
4. Марков А.С., Фадин А.А., Цирлов В.Л. Систематика дефектов и уязвимостей программного обеспечения // Безопасные информационные технологии: сб. тр. II НТК. М.: МГТУ им. Н.Э. Баумана, 2011. С. 83-87.
5. Канторович Л.В., Петрова Л.Т., Яковлева М.А. Об одной системе программирования // Пути развития советского математического машиностроения и приборостроения: Всесо-юз. конф. M.: ВИНИТИ. 1956. Ч. III. С. 30-36.
References
1. Markov A.S., Mironov S.V., Cirlov V.L., Otkrytye siste-my. SUBD, 2005, no. 12, pp. 64-69.
2. Glukhikh M.I., Itsykson V.M., Programmnaya inzhene-riya. Obespechenie kachestva programmnykh sredstv metodami staticheskogo analiza [Software engineering. Software quality assurance by static analysis methods], St. Petersburg, Techn. Univ., 2011, 150 p.
3. Kolosov A.P., Ryzhkov E.A., Izvestiya Tulskogo Gos. Univ., Tula, 2008, no. 3, pp. 185-190.
4. Markov A.S., Fadin A.A., Tsirlov V.L., Bezopasnye infor-matsionnye tekhnologii, Sbornik trudov II Konf. [Proc. 2nd All-Russian Conf. «Information security technology»], Moscow, Bauman MSTU, 2011, pp. 83-87.
5. Kantorovich L.V., Petrova L.T., Yakovleva M.A., Puti razvitiya sovetskogo matematicheskogo mashinostroenija i priboro-stroeniya, Vsesoyuz. Konf. [Proc. of Unit Conf. «The ways of development of Soviet mathematical engineering and instrumentation»], Moscow, VINITI, 1956, Part. III, pp. 30-36.
УДК 004.932
ПРОГНОЗИРОВАНИЕ ВРЕМЕНИ ОБРАБОТКИ ИЗОБРАЖЕНИЙ ДЕТЕРМИНИРОВАННЫМИ МЕТОДАМИ
(Научные исследования выполняются при финансовой поддержке грантов правительства Челябинской области и Магнитогорского государственного технического университета им. Г.И. Носова)
И.И. Мацко, аспирант; О.С. Логунова, д.т.н., профессор, доцент; И.А. Посохов, аспирант (Магнитогорский государственный технический университет им. Г.И. Носова, пр. Ленина, 38, г. Магнитогорск, Челябинская обл., 455000, Россия, [email protected], [email protected], [email protected])
Статья посвящена прогнозированию времени обработки изображений с объектами, характеризующимися случайным местом положения и нерегулярной формой. Приведена методика улучшения и сегментации изображения, уменьшающая шумы, возникающие при получении изображений в действующем металлургическом производстве. Представлено математическое описание алгоритмов, применяемых в методике. Получены результаты вычислительного эксперимента, проводимого с целью оценки скорости работы алгоритмов, определения зависимости данной скорости от конфигураций аппаратных платформ и характеристик изображения. Анализ приведенных результатов показал, что скорость работы алгоритмов имеет зависимость, близкую к линейной, от выбранного процессора и при этом практически не зависит от объема оперативной памяти. Описан набор возможных траекторий обработки изображений по исследуемой части методики. Представлены результаты прогнозирования времени обработки по траекториям изображений. Максимальная ошибка прогнозирования составила 0,5 с. Определено, что самые затратные по времени работы алгоритмы (эрозия и дилатация) быстрее выполняются на низкоконтрастных и темных изображениях, чем на высококонтрастных и светлых. Для повышения точности прогнозирования времени обработки предлагается выполнять предварительную группировку изображений по уровню яркости и контрастности и проводить статистическую обработку для каждой отдельной группы.
Ключевые слова: обработка изображений, вычислительный эксперимент, прогнозирование, автоматизация, оценка скорости.
IMAGE PROCESSING TIME PREDICTION USING DETERMINATE METHODS Matsko I.I., Postgraduate; Logunova O.S., Ph.D., Professor, Associate Professor; PosokhovI.A., Postgraduate (G.I. Nosov Magnitogorsk State Technical University, 38, Lenina Av., Magnitogorsk, Chelyabinsk Reg., 455000, Russia,
[email protected], [email protected], [email protected]) Abstract. The article is devoted to the forecast of processing time of images containing objects characterized by random location and irregular shape. The described method of image enhancement and segmentation is aimed at reduction of noise typical for a metallurgical plant. The authors introduce mathematical formulation of algorithms used in the method. They also carried out a computational experiment aimed at estimation of the algorithm operating speed and at finding correlation between that speed and hardware (platform) configuration and image characteristics. The analysis of the experiment results proved that the algorithm operating speed has almost linear relationship with the chosen processor and very little relationship with the RAM capacity. A number of possible trajectories of image processing are also described in the article. Maximum forecast error of the image processing time for different trajectories was 0,5 s. It was found that the most time consuming algorithms (erosion and dilatation) are work faster for low-contrast than for high-contrast images. They are also faster for dark than for light images. To improve the accuracy of the processing time forecast it was offered beforehand to categorize the images by the brightness and contrast level and to carry out statistical analysis for each separate group. Keywords: image processing, computing experiment, prediction, automation, performance estimation.