страница 1
 
Раздел 5
|
| Автоматика. Управление.
Энергетика |
УДК 693.34:519.87
|
|
Н.И. КАРАСЁВ
Н.И. ТОМИЛОВА
| Методы декомпозиции гидравлических цепей теплоснабжающих систем |
Декомпозиционно-топологический подход к построению и исследованию моделей больших систем базируется на концепциях диакоптики Г. Крона [1], которая предполагает достаточно общие процедуры расчленения системы на части, исследование частей, а затем решение задач анализа и синтеза исходной большеразмерной системы на основе частных решений выделенных малых частей. В современной теории гидравлических цепей вопросы анализа и синтеза по частям практически мало исследованы.
Описанный в работе [2] топологический подход к декомпозиции больших гидравлических систем не пригоден для широкого класса реальных открытых, закрытых и открыто-закрытых двухтрубных систем теплоснабжения мегаполисов (СТМ), поэтому возникает потребность поиска новых подходов в методологии построения математических и информационных моделей гидравлических цепей СТМ на основе расчленения и последующего объединения её частей. Анализ принципов построения технологических структур и требований к программной реализации процесса имитационного моделирования режимов СТМ позволил предложить следующий единообразный подход к их декомпозиции. Исходя чисто из технологических и организационных соображений трубопроводные сети СТМ разделяют на магистральные и распределительные, поэтому гидравлическую сеть СТМ целесообразно расчленить на магистральные и распределительные подсистемы, или фрагменты по узлам присоединения распределительных сетей к магистральным. Упомянутые узлы присоединения будем называть «граничными узлами» гидравлических цепей выделенных фрагментов СТМ. Каждая распределительная трубопроводная цепь имеет пару граничных узлов, а магистральная — содержит столько пар граничных узлов, сколько к ней присоединено распределительных фрагментов, выделенных на этапе декомпозиции исходной гидравлической цепи СТМ. В каждом из выделенных фрагментов введем дополнительные переменные, обеспечивающие эквивалентность параметров состояния (параметров режима) в исходной и расчленённой цепи.
На рисунке 1 приведены схемы декомпозиции гидравлических цепей СТМ, иллюстрирующие предложенный подход для цепей СТМ с фиксированными нагрузками. Эквивалентность параметров состояния исходной и расчленённой цепей обеспечивается посредством соответствующих отношений, налагаемых на дополнительные переменные в сечениях исходной цепи. Для СТМ с фиксированными нагрузками потребителей условия эквивалентности параметров состояния будут иметь вид:
 (1)
где  — соответственно эквивалентные узловые расходы в граничных узлах подающего и обратного трубопроводов магистральной цепи;
 — соответственно расход на участках распределительной цепи, инцидентных её граничным узлам на подающем и обратном трубопроводах;
 — соответственно давление в граничных узлах подающего и обратного трубопроводов магистральной цепи;
 — давление в граничном узле обратного трубопровода распределительного фрагмента;
Hp — напор эквивалентного источника энергоносителя на входе распределительного фрагмента.
Рисунок 1 — Декомпозиция гидравлической цепи СТМ с фиксированными нагрузками потребителей
Для СТМ с фиксированными гидравлическими сопротивлениями потребителей условия эквивалентности параметров состояния будут иметь вид:
 (2)
где rm, rp — соответственно, эквивалентное гидравлическое сопротивление обобщенного потребителя в магистральной цепи и входное гидравлическое сопротивление распределительного фрагмента.
Таким образом, при декомпозиции цепей с фиксированными нагрузками потребителей связи между выделенными фрагментами эквивалентируются соответственно узловыми расходами энергоносителя в граничных узлах магистрального фрагмента и включением эквивалентного источника напора между граничными узлами распределенного фрагмента.
В цепях с фиксированными гидравлическими сопротивлениями потребителей связи между фрагментами обеспечиваются включением между граничными узлами магистрального фрагмента эквивалентного гидравлического сопротивления «обобщенного» потребителя, а между граничными узлами распределительного фрагмента — эквивалентного источника напора. «Обобщенным» будет называться потребитель, эквивалентно представляющий все виды теплопотребления соответствующего распределительного фрагмента.
Описанный подход к декомпозиции СТМ назовем первым уровнем декомпозиции, т.к. он расчленяет системы на технологически разнородные подсистемы: магистральные фрагменты, где сосредоточены источники теплоснабжения с их подпиточными узлами; опорный узел системы, задающий масштаб давления в её узлах; магистральные насосные станции трубопроводной сети и распределительные фрагменты, где сосредоточены реальные потребители и средства поддержания их режима.
Но стремление повысить эффективность численного моделирования режимов СТМ диктует необходимость использования второго уровня декомпозиции, который можно будет распространить на любой из выделенных фрагментов. При численном моделировании гидравлических режимов СТМ наибольшие вычислительные трудности возникают при решении большеразмерных систем нелинейных алгебраических или трансцендентных уравнений состояния.
Эквивалентное упрощение структуры этих систем и уменьшение количества уравнений в системе возможно за счет «существенных» нелинейностей. Узлы присоединения этих нелинейностей также назовем граничными узлами. «Существенными» будем считать такие нелинейные объекты гидравлической цепи, которые значительно усложняют процесс решения нелинейных уравнений состояния как за счет усложнения структуры, так и за счет увеличения количества этих уравнений.
В гидравлических цепях реальных СТМ такими элементами являются дроссельные регулирующие клапаны регуляторов расхода, давления, температуры энергоносителя, а также гидравлические сопротивления потребителей. Регулирующие клапаны являются нелинейными объектами с переменными гидравлическими сопротивлениями, которые порождают в нелинейных уравнениях состояния переменные коэффициенты, существенно усложняющие процесс их решения. Так как потребители размещены по периферии трубопроводной сети, то они, как правило, формируют независимые контуры с большим числом элементов.
Формально процедура декомпозиции второго уровня, названная методом «выделения существенных нелинейностей», сводится к реализации теоретико-графовой операции удаления заданных ветвей направленного графа исходной гидравлической цепи и показана на рисунке 2.
После удаления существенных нелинейностей исходный граф фрагмента гидравлической цепи G(M, N) на множествах M узлов и N участков превращается в суграф G'(M, N'), в общем случае состоящий из l компонентов связности, где l >= 1. Каждую i-ю компоненту связности суграфа  будем называть i-м фрагментом второго уровня декомпозиции. Каждую i-ю выделенную нелинейность будем называть i-м выделенным фрагментом второго уровня декомпозиции.
Рисунок 2 — Декомпозиция гидравлической цепи
СТМ методом «выделения существенных
нелинейностей»
Условия эквивалентности параметров состояния режима во фрагментах второго уровня декомпозиции единообразны для всех видов выделяемых нелинейностей и приведены к граничным узлам. Например, для
граничных узлов 9-10 (рисунок 2) условия эквивалентности будут иметь вид:
 (3)
где q9, q10, qpp — соответственно узловые расходы в базовом фрагменте второго уровня декомпозиции и расход через регулирующий клапан выделенного регулятора расхода;
P9, P10 — давления в граничных узлах базового фрагмента;
HЭ — эквивалентный источник давления на входе выделенной нелинейности.
Таким образом, гидравлическая связь между фрагментом второго уровня декомпозиции выполняется через эквивалентные узловые расходы в соответствующих граничных узлах базового фрагмента и эквивалентные источники напора в каждом выделенном фрагменте.
При практической реализации второго уровня декомпозиции методом «выделения существенных нелинейностей» можно использовать следующие неформальные соображения:
- С увеличением количества выделенных нелинейностей увеличивается общее количество фрагментов. При этом структура уравнений состояния в соответствующих фрагментах упрощается и снижает их порядок. Однако одновременно усложняется структура вычислительного процесса за счет организации последовательного порядка обработки фрагментов;
- Декомпозиция фрагмента СТМ методом «выделения существенных нелинейностей» остается эффективной до тех пор, пока экономия вычислительной системы от упрощения моделей подсистем превосходит дополнительные затраты на организацию их взаимной обработки в определенном порядке. При этом для исходной цепи фиксированной структуры существует такое количество выделенных нелинейностей, когда декомпозиция второго уровня обеспечивает повышение эффективности вычислительных процессов и их практическую реализацию в среде вычислительной системы;
- Практическая реализация метода «выделения существенных нелинейностей» возможна в среде соответствующей программной системы, которая обеспечивает возможность ведения и сохранения внутриматричной базы данных с описанием исходной гидравлической цепи и всех её выделенных фрагментов, а также возможность автоматизированного выполнения условий эквивалентности фрагментов и совместного решения уравнений состояния фрагментов гидравлической цепи.
Предложенный подход к декомпозиции СТМ одинаково эффективен как для задач анализа, так и для задач синтеза, решаемых численными методами, и не противоречит сложившейся технологической и организационной декомпозиции СТМ.
СПИСОК ЛИТЕРАТУРЫ
1. Крон Г. Исследование сложных систем по частям — диакоптика. М.: Наука, 1972. 542 с.
2. Мешалкин В.П., Кафаров В.В., Каплинский В.Я. Метод анализа больших гидравлических цепей // Энергетика и транспорт. Изд. АН СССР. 1984. № 1. С. 115-122.
УДК 378(075.8)
|
|
Б.В. КОШЕКОВА
Е.А. ЯРОВАЯ
| Идентификационный компаратор для установления степени эквивалентности сравниваемых сигналов |
Операция сравнения является важнейшей измерительной и информационной процедурой, реализуемой на аппаратном уровне с помощью специальных устройств, называемых компараторами. Принцип действия компаратора может быть описан уравнением [1]:
 (1)
где U1(t), U2(t) — входные сравниваемые сигналы;
Um — уровень условной логической единицы;
Sign[...] — символ операции определения знака;
Uout — уровень выходного сигнала компаратора.
В соответствии с данным соотношением следует, что компаратор определяет знак мгновенной разности входных сигналов, поэтому его нельзя непосредственно использовать для сравнения формы сигналов или их характеристик.
Для расширения функциональных возможностей сравнения сигналов по их форме предлагается модернизировать уравнение (1) следующим образом:
 (2)
где Id{...} — символ операции идентификации соответствующего сигнала U1(t) или U2(t), в результате выполнения которой формируется идентификационное число S1 или S2.
Основным свойством идентификационного числа S является его масштабная инвариантность, в соответствии с которой:
 (3)
где A, B, C — некоторые константы, определяющие, соответственно, размах, временное смещение и постоянную составляющую сигнала U(t).
Другими словами, идентификационное число измеряет только форму и нечувствительно к линейным преобразованиям функции U(t). Компаратор, обладающий данным свойством, назовем идентификационным (IdC).
Анализ уравнения (2) с учетом свойства (3) позволяет обобщить принцип эквивалентности сигналов и сформулировать его следующим образом: любые сравниваемые сигналы эквивалентны в идентификационном смысле, если они имеют равные идентификационные числа (4).
 (4)
Символ «≡» обозначает идентификационную эквивалентность в отличие от знака равенства «=», обозначающего математическую эквивалентность.
В результате исследований идентификационный компаратор (ИК) (рисунок 1) выполнен в среде LabVIEW-7.1 и состоит из двух идентификационных тестеров, например, S-типа и устройства сравнения. Идентификационные тестеры выбраны из библиотеки виртуальных инструментов анализа и синтеза формы сигналов [2]. Принцип работы S-тестеров, предназначенных для измерения формы, описан в [3].
Рисунок 1 — Структура программного кода
идентификационного компаратора
Устройство сравнения состоит из вычитателя, измерителя модуля, делителя, блока сравнения типа «больше», блока сравнения типа «меньше или равно» и переключателя.
На входы InputArray-1 и InputArray-2 подаются сравниваемые сигналы в виде массивов выборочных реализаций. На выходах идентификационных тестеров формируются соответствующие идентификационные числа S1 и S2, которые сравниваются устройством сравнения. Сравнение производится путем вычисления относительной разности идентификационных чисел вида:
 (5)
которая подается на выход DeltaNum для дальнейшего непосредственного измерения, либо сопоставляется с некоторым контрольным значением δ0, задаваемым со входа InputDelta. Если δ ≤ δ0, то на выходе Boolean формируется логический сигнал типа TRUE, в противном случае — логический сигнал типа FALSE. Таким образом, в ИК предоставляется возможность регулировать допустимую погрешность сравнения компаратора.
Особенности практического применения идентификационного компаратора иллюстрируются на модели виртуального прибора M-proba.vi (рисунок 2).
Данный прибор содержит два функциональных генератора FGen_3.vi и исследуемый компаратор S-Compare.vi, которые установлены в цикле с заданным числом повторений. Это необходимо для того, чтобы промоделировать непрерывный режим работы ИК. С помощью генераторов с панели управления (левая часть рисунка 2) на входах ИК можно задавать:
- периодические сигналы прямоугольной (Squ), синусоидальной (Sin), треугольной (Tri) и пилообразной (Saw) формы с различным числом периодов;
- случайные сигналы с различными законами распределения: двумодальным (2mod), арксинусным (asin), равномерным (even), треугольным (simp), нормальным (gaus), двусторонним экспоненциальным (lapl), Коши (kosh), Пуассона (poisson), гамма-2 (gamma-2), биномиальным (binom), Бернулли (bernulli).
В качестве выходной информативной величины ИК выступает среднее за время действия входного сигнала значение погрешности сравнения (OutNum-1). В таблице 1 представлены результаты измерения погрешности сравнения в случае, когда на один вход ИК подается прямоугольный периодический сигнал или случайный сигнал с двумодальным распределением, а на другой вход — различные случайные сигналы. Объем выборки N = 10000 — количество отсчетов, полученных при дискретизации сигнала; количество реализаций L = 100 — число сгенерированных выборок объема N.
В таблице 2 представлены результаты сравнения периодических сигналов.
Рисунок 2 — Виртуальный прибор для исследования идентификационного компаратора
Таблица 1 — Результаты измерения погрешности сравнения прямоугольного периодического или случайного
(с двумодальным распределением) с различными случайными сигналами
№ п/п
|
Вид первого входного сигнала (N = 10000 — объем
выборки, L = 100 — количество реализаций)
|
Погрешность сравнения, %
|
для сигнала типа Squ
|
для сигнала типа 2mod
|
1
|
2mod
|
0
|
0
|
2
|
Asin
|
7,6
|
7,6
|
3
|
Even
|
25
|
25
|
4
|
Simp
|
50
|
50
|
5
|
Gaus
|
70
|
70
|
6
|
Lapl
|
85
|
85
|
7
|
Kosh
|
100
|
100
|
8
|
Poisson
|
70
|
70
|
9
|
Gamma-2
|
76
|
76
|
10
|
Binom
|
0
|
0
|
11
|
bernulli
|
0
|
0
|
Полученные данные подтверждают предварительное предположение о том, что идентификационный компаратор позволяет сравнивать сигналы по форме распределения их мгновенных значений. При этом погрешность сравнения так упорядочивает форму распределения в диапазоне от 0 до 100 %, что самыми «младшими» оказываются 2mod, binom, bernulli распределения, а самым «старшим» — распределение Коши.
Таким образом, можно говорить о том, что понятие идентификационной эквивалентности является более общим по отношению к понятию математической эквивалентности, поскольку позволяет реализовать измерение сигналов в целом, а не их мгновенных значений.
Предлагаемый идентификационный компаратор для установления эквивалентности двух сравниваемых сигналов может применяться в интеллектуальных системах измерения, управления, контроля и диагностики, работающих в режимах интерактивного и автоматического распознавания и идентификации сложных сигналов.
Таблица 2 — Результаты измерения погрешности сравнения периодических сигналов
№ п/п
|
Вид первого входного сигнала
(кол-во периодов от 1 до 4999 в объеме выборки N = 10000)
|
Погрешность сравнения,
% для сигнала типа Squ
|
1
|
Squ
|
0
|
2
|
Sin, Cos
|
7,6
|
3
|
Tri, Saw
|
25
|
СПИСОК ЛИТЕРАТУРЫ
1. Лачин В.И., Савелов Н.С. Электроника: учеб. пособие. Ростов н/Д: Феникс, 2001. 448 с.
2. Кликушин Ю.Н. Технологии идентификационных шкал в задаче распознавания сигналов: монография. Омск: Изд-во ОмГТУ, 2006. 96 с.
3. Кликушин Ю.Н., Кошеков К.Т. Методы и средства идентификационных измерений сигналов: монография. Петропавловск: Изд-во СКГУ им. М. Козыбаева, 2007. 186 с.
УДК 004.415.53
|
|
Л.Г. ЗАРТЕНОВА
В.Б. ОРЕШКИНА
| Анализ работоспособности как часть процесса разработки программного обеспечения |
Для создания программного продукта, удовлетворяющего всем требованиям качества, нужно представить его себе именно в конечном виде, описать в соответствующих документах, установить требования к функциям и те критерии, по которым в дальнейшем будет оцениваться его качество. Спроектировав и создав макет, перейти к программированию и к эксплуатации готового продукта.
Если программный продукт обладает малым количеством функций и пишется одним-двумя программистами, то так поступить можно, но если программный продукт предназначен для выполнения большого количества функций и разрабатывается большой группой (больше 5 человек), то велика вероятность ошибок. В этом случае необходима такая часть цикла разработки программного обеспечения (ПО), как тестирование.
Тестирование готового продукта предполагает проверку на соответствие тем требованиям, которые были предъявлены к нему на этапе проектирования. Если продукт прошел проверку, то его можно передавать в эксплуатацию, если нет — продукт возвращается на доработку в отдел программирования. На практике процесс проверки-доработки повторяется не один раз.
Зачем выделять процесс тестирования в отдельную ступень разработки ПО? Программист, написав код, проверяет его. В процессе программирования существуют свои методы тестирования написанного кода, например, Unit-тестирование. Но программист смотрит на разрабатываемую программу «изнутри», тестировщик — «снаружи», поэтому не знает, как на уровне кода организована работа каждой функции. Тестировщик должен понимать бизнес-логику работы тестируемой программы, он с позиции конечного пользователя оценивает функциональность программы, корректность ее визуального восприятия и удобство работы с ней, ее быстродействие. Он обязан проверить программу в максимально возможном количестве ситуаций, которые могут возникнуть при работе с ней. Например, насколько корректно отреагирует программа, если ввести неверные данные или неожиданно отключить электроэнергию.
В процессе разработки ПО тестированию подвергается не только готовый продукт, но и постановочный документ, в котором описываются требования к программному продукту. Постановочный документ тестируется параллельно и программистом, и тестировщиком, допущенные в нем ошибки исправляются, разрешаются возникающие вопросы и разногласия, и только после этого начинается процесс программирования.
Согласно данным статистики, если исправление ошибки, найденной на этапе постановки, обходится фирме-разработчику в 5 тнг., исправление ошибки, найденной на этапе программирования-тестирования — в 10 тнг., то исправление ошибки, найденной на этапе эксплуатации — уже в 500 тнг. Качественное тестирование постановочных документов и готового продукта важно осуществить еще до их ввода в эксплуатацию.
Процесс тестирования становится профессиональным.
Специалистов тестирования сегодня обучают лишь в некоторых развитых странах Запада, в нашей стране каждая софтверная компания занимается обучением персонала самостоятельно в ходе рабочего процесса. Перед тем, как быть принятым на работу, сотрудник отдела тестирования проходит двух-трех месячный испытательный срок, в течение которого его обучают основам процесса тестирования. Если по окончании испытательного срока сотрудник покажет положительные результаты и проявит необходимые качества, то будет взят на работу.
Какими же качествами должен обладать хороший тестировщик? Во-первых, это должен быть специалист информационных технологий с высшим образованием. Также хорошему тестировщику не обойтись без таких качеств, как наблюдательность, усидчивость, коммуникабельность, умение работать в команде, умение ясно и грамотно излагать свои мысли (чем точнее и короче описана найденная ошибка, тем меньше времени потратит программист на ее исправление).
Тестирование проводится по заранее написанному тестировщиком сценарию, позволяющему четко отследить, какая функция, каким способом и с каким результатом была протестирована. Такой подход исключает вероятность того, что какая-либо функция останется не проверенной.
Всякое тестирование вновь созданного программного продукта начинается с того, что тестировщик знакомится с постановочной документацией, внимательно изучает все требования, предъявляемые к программе и, на основании требований и бизнес-логики тестируемой программы, составляет сценарий, по которому он будет осуществлять проверку.
На начальном этапе проверки программный продукт, как правило, тестируется методом минимального приемочного теста (этот метод еще называют «дымовым» или поверхностным тестированием). Такой метод предполагает тестирование только самых основных функций, без работоспособности которых дальнейшее тестирование не имеет смысла. Допустим, покупая в магазине калькулятор, вы обнаружили, что у него не работают кнопки сложения и вычитания. В этом случае вы едва ли сочтете нужным проверять, работает ли функция извлечения квадратного корня, а просто вернете калькулятор продавцу и попросите другой. Так же поступает и тестировщик: обнаружив неработоспособность основных функций, он не переходит к дальнейшему тестированию, а осуществляет возврат программы в отдел разработки для исправления ошибок.
Если же результаты «дымового» тестирования оказались положительными, тестировщик переходит к более детальному тестированию, называемому функциональным тестированием. В процессе такого тестирования проверке подвергаются уже все функции программы (возвращаясь к примеру с калькулятором, если у выбранного вами калькулятора корректно работают четыре основные операции, то вы перейдете к проверке работы функций памяти, возведения в степень, извлечения корня и т.п.).
Функциональное тестирование проводится с нескольких точек зрения или, можно сказать, делится на несколько типов. Например, если рассмотреть методы проверки при минимальном приемочном тестировании, то тестирование в нем проводится только вводом в программу заранее верных данных и совершением верных действий (т.е. пытаясь проверить работоспособность, например, нового электрочайника, вы сначала наливаете в него воду, а потом включаете в сеть, а не наоборот). Если же рассматривать функциональное тестирование, то проверку вполне логично проводить, вводя в программу не только заведомо верные, но также заведомо неверные данные и смотреть, как отреагирует на них программа. Это могут быть отрицательные значения (для числовых полей), ввод в числовые поля буквенных и прочих символов, ввод символов, количество которых превышает допустимую длину, граничные значения (стоящие на начальной и конечной границах допустимого для ввода диапазона).
После такого тестирования программный продукт возвращается на доработку, а после доработки вновь подвергается тестированию.
Цикл «тестирование-доработка-тестирование» на практике повторяется много раз. Целью доработки, если только это не конечная версия продукта, является не только исправление найденных ошибок, но и добавление нового функционала. Причиной такого «поэтапного» написания программ является большой объем функций, которыми программа должна обладать. Раз за разом проводимое тестирование называется регрессионым (лат. regressio — обратное движение). Регрессионное тестирование ставит целью проверить, исправлены ли старые ошибки и не сделаны ли новые. Если рассматривать процентное соотношение разных видов тестирования в течение всего цикла реализации программного продукта, то регрессионное составляет около 65-70 %.
Наряду с функциональным тестированием, программный продукт также подвергается стрессовому и нагрузочному тестированию. Эти два метода тестирования проводятся уже на этапе проверки конечной версии.
Стрессовое тестирование предполагает проверку работоспособности программного продукта в нетипичных обстоятельствах. Например, как поведет себя программа при неожиданном отключении электроэнергии, при разрыве связи в сети, при превышающем критическую норму количестве пользователей или заявок в очереди и т.п.
Нагрузочное тестирование призвано проверить программу «на прочность», т.е. при критических, находящихся на границе возможностей нагрузках.
Например, предполагается, что программа должна корректно обслуживать одновременно 1000 пользователей. Эмуляция работы 998, 999 и 1000 пользователей будет являться нагрузочным тестирование, а эмуляция 1001, 1002 и т.д. пользователей будет уже стрессовым тестированием.
Все вышеописанные методы относятся к так называемому «ручному» тестированию. На сегодняшний день вершиной развития технологий проверки программных продуктов является автоматизация процесса тестирования.
Тестирование само по себе является слабоалгоритмизируемым процессом, но развитие современных технологий все же позволяет автоматизировать некоторые его части. Применяя соответствующие программные инструменты, можно автоматизировать процесс регрессионного, стрессового и нагрузочного тестирования.
Автоматизация состоит из двух этапов: написания скрипта — набора команд, описывающих действия, которые необходимо выполнить компьютеру над тестируемой программой и запуска этого скрипта на выполнение. Процесс написания скрипта есть программирование, поэтому требует от тестировщика более высокой квалификации (он должен быть знаком с азами программирования), значительных трудовых и временных затрат. Окупаемость этих затрат очень высока — при автоматизации действия с тестируемой программой выполняет компьютер, значит, процесс идет в несколько раз быстрее — те функции, на тестирование которых вручную уходило несколько часов, при автоматизации — не более получаса. Кроме того, автоматизированная проверка позволяет избежать ошибок, обуславливаемых человеческим фактором.
На сегодняшний день автоматизация в софтверных компаниях нашей страны находится на ранней ступени развития, но можно утверждать, что дальнейшее развитие автоматизации позволит улучшить как качество процесса тестирования, так и качество разрабатываемых программных продуктов.
Выводы:
1. Процесс тестирования является неотъемлемой частью разработки ПО.
2. Выявление ошибок экономически выгодно на этапе тестирования.
3. Автоматизация снижает затраты и повышает качество тестирования ПО.
УДК 006.05(574)
|
|
А.К. КУСАИНОВ
| Международная практика и внедрение системы технического регулирования в Республике Казахстан |
Реорганизация действующей системы технического регулирования мотивирована предстоящим вступлением Казахстана в ВТО и в значительной степени изменениями законодательства стран СНГ и Восточной Европы — основных торговых партнеров.
В связи с этим при создании новой системы технического регулирования максимально учитывались требования Соглашения ВТО по техническим барьерам в торговле.
Международная система технического регулирования четко разделяет требования к продукции на две части: первая — это безопасность, за что отвечает государство, вторая — потребительское качество продукции, не влияющее на безопасность, требования к которым диктует рынок.
Обязательные требования устанавливаются в так называемых «технических регламентах», принимаемых на уровне нормативных правовых актов: законов, директив, предписаний.
Требования стандартов и других документов, содержащих технические нормы, носят рекомендательный характер. Примером развитого технического законодательства может служить законодательство Европейского Союза.
Действовавшая в республике система технического регулирования безопасности и качества продукции и услуг не обеспечила единую систему взаимоувязанных мер:
- национальное законодательство в области стандартизации регулировало общественные отношения и не содержало технических норм и требований к конкретным объектам;
- обязательные технические нормы были установлены в стандартах и других документах: СанПиН, СНиП, экологических, пожарных, ветеринарных, энергетических, транспортных правилах, что создает сложности производителям и расширяет возможности государственного контроля;
- существовавшая нормативная база содержала не только показатели безопасности для жизни и здоровья граждан, охраны окружающей среды, но и обязательные требования по качеству, что также противоречило международной практике, где качество обеспечивает производитель, а оценивает только потребитель;
- отсутствие должной координации и согласованности уполномоченных органов, принимающих обязательные документы, приводило к дублированию в техническом регулировании.
Реформирование национальной системы технического регулирования осуществлялось синхронно с учетом межгосударственных тенденций.
Переход на новую систему технического регулирования должен быть завершен до 2010 г. Такой срок определили государства СНГ на основе проведенного анализа действующей нормативной базы в рамках Межгосударственного Совета по стандартизации, метрологии и сертификации.
В рамках МГС разработано и принято на Совете глав правительств «Соглашение об основах гармонизации технических регламентов государств-участников СНГ».
Соглашение способствует проведению согласованной технической политики в области технического регулирования государствами-участниками СНГ.
Для практической реализации основных положений Соглашения была реализована «Межгосударственная программа разработки первоочередных межгосударственных моделей технических регламентов на 2004-2007 гг.»
Основой при разработке межгосударственных моделей технических регламентов являются европейские директивы, международные стандарты. Казахстан выступил инициатором и ответственным исполнителем отдельных межгосударственных технических регламентов.
Проводилась своеобразная «обкатка» и сверка верности выбранной модели ТР и на многочисленных двусторонних переговорах, проводимых со странами дальнего и ближнего зарубежья.
К примеру, на очередном 53-м заседании Генеральной Ассамблеи ИСО в Буэнос-Айресе были проведены встречи с представителями 22 стран мира, также была использована трибуна Генеральной Ассамблеи, в которой участвовало более 130 стран мира, и нами были вынесены основные два проблемных вопроса, для решения которых необходимо содействие руководства ИСО.
Первый. В связи с переходом на систему технического регулирования проведение семинаров по данной проблематике в странах СНГ.
Второй. При подготовке экспертов по международным стандартам серии 14000 и экспертов по международным стандартам приводить анализ рисков контроля критических точек.
По приглашению Казахстанской стороной Генеральный Секретарь ИСО посетил нашу страну с официальным визитом, имел встречу с Премьер-Министром, на которой обсуждался вопрос о проведении в перспективе Генеральной Ассамблеей ИСО в Казахстане. Он высоко оценил работу, проводимую в республике по внедрению системы ТН, отвечающей международным требованиям.
На сегодняшний день принято 19 технических регламентов и 21 находится на стадии разработки (перечень прилагается). В 2008 г. к принятию готовится 36. На сегодняшний день 1 300 предприятий внедрили Систему Менеджмента Качества серии ИСО 9001.
Вышеизложенное выполнено за пять лет.
ВЫВОДЫ
1. Разработана Методология технического регулирования в Республике Казахстан, устанавливающая четырехуровневую иерархию документов технического законодательства.
2. В рамках этой методологии впервые предложен и введен в Республике Казахстан новый вид документов — технические регламенты, в которых четко прописываются только вопросы безопасности продукции и/или процессов ее жизненного цикла, отличающихся от других нормативных правовых актов Республики Казахстан как содержанием, так и структурой построения.
3. Для разработки технического регламента предложены новые подходы и методы:
1) подходы к идентификации проблемы, определения объекта технического регулирования;
2) метод оценки опасности производственного объекта;
3) методы по включению:
- конкретных технических требований в технические регламенты;
- существенных требований в технические регламенты;
4) подходы по включению в технические регламенты центрального принципа — презумпции соответствия, для чего предложен и введен в Республике Казахстан гармонизированный стандарт, новый вид стандарта, обеспечивающий выполнение требований технического регламента;
5) подходы по включению в технические регламенты требований по подтверждению соответствия и его гармонизации с модульным подходом;
6) методы гармонизации национальных и корпоративных стандартов с международными стандартами, используемые при практическом внедрении Модели технического регулирования, в том числе при составлении проекта программы разработки первоочередных технических регламентов.
4. Впервые разработана научная основа технического регулирования в виде Концепции технического регулирования, определяющей основные понятия, цели, принципы технического регулирования и устанавливающей требования: к техническим регламентам, стандартизации, подтверждению соответствия, аккредитации органов по подтверждению соответствия и лабораторий, а также государственный контроль за соблюдением технических регламентов и ответственности государственных органов и хозяйствующих субъектов за несоблюдение законодательства в области технического регулирования.
Концепция легла в основу законопроекта Республики Казахстан «О техническом регулировании» и явилась центральным элементом Модели технического регулирования в Республике Казахстан.
Таблица 1 — Информация о принятых технических регламентах
№ п/п
|
Наименование технического регламента
|
Дата, № ППРК о принятии
технических регламентов
|
1
|
2
|
3
|
1
|
Требования к выбросам вредных (загрязняющих) веществ автомобильной техникой, выпускаемой в обращение на территории Республики Казахстан
|
Постановление Правительства Республики Казахстан от 29 декабря 2007 г. № 1372
|
2
|
Требования к безопасности при проектировании автомобильных дорог
|
Постановление Правительства Республики Казахстан от 31 марта 2008 г. № 307
|
3
|
Требования к безопасности при эксплуатации автомобильных дорог
|
Постановление Правительства Республики Казахстан от 27 марта 2008 г. № 294
|
4
|
Требования к безопасности зданий и сооружений и прилегающих территорий
|
Постановление Правительства Республики Казахстан от 6 марта 2008 г. № 227
|
5
|
Безопасность строительных материалов, изделий и конструкций
|
Постановление Правительства Республики Казахстан от 4 февраля 2008 г. № 96
|
6
|
Требования к безопасности синтетических моющих средств и товаров бытовой химии
|
Постановление Правительства Республики Казахстан от 4 марта 2008 г. № 217
|
7
|
Требования к безопасности лакокрасочных материалов и растворителей
|
Постановление Правительства Республики Казахстан от 29 декабря 2007 г. № 1398
|
1
|
2
|
3
|
8
|
Требования к безопасности парфюмерно-косметической продукции
|
Постановление Правительства Республики Казахстан от 19 февраля 2008 г. № 159
|
9
|
Требования к упаковке, маркировке, этилированию и правильному их нанесению
|
Постановление Правительства Республики Казахстан от 21 марта 2008 г. № 277
|
10
|
Требования к безопасности зерна
|
Постановление Правительства Республики Казахстан от 8 апреля 2008 г. № 337
|
11
|
Процедуры подтверждения соответствия
|
Постановление Правительства Республики Казахстан от 04 февраля 2008 г. № 90
|
12
|
Требования к безопасности мяса и мясной продукции
|
Постановление Правительства Республики Казахстан от 8 апреля 2008 г. № 336
|
13
|
Требования к безопасности молока и молочной продукции
|
Постановление Правительства Республики Казахстан от 11 марта 2008 г. № 230
|
14
|
Требования к безопасности кормов и кормовых добавок
|
Постановление Правительства Республики Казахстан от 18 марта 2008 г. № 263
|
15
|
Требования к безопасности соков и соковой продукции
|
Постановление Правительства Республики Казахстан от 27 февраля 2008 года № 199
|
16
|
Требования к эмиссиям в окружающую среду при сжигании различных видов топлива в котлах тепловых электрических станций
|
Постановление Правительства Республики Казахстан от 14 декабря 2007 г. № 1232
|
17
|
Требования к безопасности продукции и изделий, предназначенных для детей
|
Постановление Правительства Республики Казахстан от 27 февраля 2008 года № 201
|
18
|
Требования к безопасности лекарственных средств и биологических препаратов, используемых в ветеринарии
|
Постановление Правительства Республики Казахстан от 23 апреля 2008 г. № 380
|
19
|
О требованиях к безопасности продуктов мукомольно-крупяной промышленности, крахмалов и крахмала продуктов
|
Постановление Правительства Республики Казахстан от 26 апреля 2008 г. № 392
|
Таблица 2 — Информация о разрабатываемых технических регламентах
№ п/п
|
Наименование технического регламента
|
Разработчики
|
1
|
Требования к безопасности автотранспортных средств
|
МВД (свод), МИТ, МТК
|
2
|
Требования к сигнальным цветам, разметкам и знакам безопасности на производственных объектах
|
МЧС
|
3
|
Требования к безопасности водогрейных и паровых котлов
|
МЧС (свод), МИТ
|
4
|
Требования к безопасности трубопроводов горючих, токсичных, сжиженных газов
|
МЧС (свод), МЭМР
|
5
|
Требования безопасности к подъемным шахтным установкам
|
МЧС (свод), МЭМР, МИТ
|
6
|
Требования к безопасности процессов производства взрывчатых материалов
|
МЧС (свод), МЭМР, МИТ
|
7
|
Требования по оборудованию зданий, помещений и сооружений системами автоматического пожаротушения и автоматической пожарной сигнализацией, оповещения и управления эвакуацией людей при пожаре
|
МЧС
|
8
|
Требования к безопасности процессов разработки рудных, нерудных, угольных и россыпных месторождений подземным способом
|
МЧС (свод), МЭМР, МООС
|
9
|
Требования к безопасности процессов разработки рудных, нерудных, угольных и россыпных месторождений открытым способом
|
МЧС (свод), МЭМР, МООС
|
10
|
Требования к безопасности подъемно-транспортных средств
|
МЧС (свод), МИТ МТК
|
11
|
Требования к безопасности оборудования, работающего под давлением
|
МЧС (свод), МИТ
|
12
|
Требования к безопасности лифтов
|
МЧС (свод), МИТ
|
13
|
Требования к безопасности пестицидов (ядохимикатов)
|
МСХ (свод), МЗ, МООС, МИТ
|
14
|
Требования к безопасности питьевой воды для населения
|
МЗ (свод), МСХ
|
15
|
Требования к безопасности плодов, овощей, корнеплодов и продуктов их переработки
|
МСХ
|
16
|
Требования к безопасности нефтебаз и автозаправочных станций
|
МЭМР (свод), МЧС
|
17
|
Требования к безопасности продуктов детского питания, диетического и лечебно-профилактического питания
|
МЗ
|
18
|
Требования к безопасности питьевой воды, расфасованной в емкости
|
МЗ
|
19
|
Требования к безопасности хлеба и хлебобулочных, кондитерских изделий
|
МЗ (свод), МСХ
|
20
|
Требования к безопасности пищевых добавок, их производства и оборота
|
МЗ
|
21
|
Требования к безопасности пиротехнических составов и содержащих их изделий
|
МИТ (свод), МЧС МВД
|
страница 1
|